I placed the following on the Earned Value Management Board yesterday without a response. This deals with a system acquisition on a task order contract. Multiple projects are managed under the overall contract and they also are acquired in the same manner. Anyone here with an opinion?

The article being acquired is a fairly complicated software/hardware item worth about $400 million. It is being acquired under an overall contract by task orders.

Each task order represents a system acquisition phase of the project. For example, a phase must be completed and a decision point passed to get the next task order for the next phase of the project.

Would you set the baseline on the individual task order or would you set it on the overall project? I have my own ideas. I am looking for a second or more opinions.

By Vern Edwards on Thursday, October 05, 2000 - 11:24 am:

I would say for each task order, unless you can find some way to estimate the effect on cost and schedule of the Government's performance in making the phase decisions and issuing the task orders. That effect would have to be included in the budgeted cost of the work scheduled (BCWS). Those actions could take weeks or even months and have a significant effect on the budgeted cost of the work performed (BCWP) and the actual cost of the work performed (ACWP) for the overall project.

By Eric Ottinger on Thursday, October 05, 2000 - 11:50 am:

Bob,

I don't think we have much agreement on what a "task order" is or should be. That makes it hard to say that there is a "right" answer to your question.

If the "task order" has a completion character and and some coherence, it should line up with the WBS and the earned value work packages.

I wouldn't bet that is always the case.

Eric

By bob antonio on Friday, October 06, 2000 - 08:45 am:

Eric:

The task orders are for the phases of the acquisition process. It appears the intent is to use them as separate segments between decision points. Once a decision point is passed, a new task order is awarded for the next phase. The overall contract is for an integrator to manage many projects. So multiple projects will be moving forward concurrently.

By Vern Edwards on Friday, October 06, 2000 - 09:45 am:

Bob:

I think Eric's point is that the application of an earned value approach on a task order basis will be difficult if the agency's program manager does not structure the tasks so as to represent clear and distinct "work packages." I agree with him.

Are you talking about the Customs Service modernization project?

By bob antonio on Friday, October 06, 2000 - 10:19 am:

Vern:

No, this is not customs.

The tasks are planned to be structured according to phases of the acquisition process. Once design is completed, the task order ends. The next one is issued. Once initial fielding and testing is done, that task order is completed. Once the decision point has been passed to move towards full deployment, the next task order for that phase will be issued. After that, the possibility is that there will be four separate task orders representing the overall project.

I chatted with a fellow that is well-versed in this area on the EVMS board and his opinion is that the task orders should be separately baselined if they are separate parts. However, if the task orders are not separate, the overall project should be baselined.

In the current scenario, which has not been placed in practice, I believe individual task orders should be baselined. After experience is accumulated, then the organization can move towards an overall project baseline with the phases under the overall WBS.

By Vern Edwards on Friday, October 06, 2000 - 10:23 am:

Bob:

I agree with you that the agency should baseline the individual tasks. Even though they are all directed at toward a common end, they are effectively being managed as separate projects.

By bob antonio on Friday, October 06, 2000 - 10:33 am:

Vern:

The one problem I have with the individual task order baselines is that the organization may lose sight of the overall objective--the project.

However, it is more important that the organization succeeds with a couple of task orders.

By Ramon Jackson on Friday, October 06, 2000 - 10:50 pm:

Bob, the risk you mention seems compounded by "multiple projects will be moving forward concurrently." I read that as indicating multiple streams (each a TO), each phasing according to the acquisition process, eventually intended to converge into one operating system within a "complicated software/hardware" development. Am I correct in reading into this that the hardware might be in one stream at phase "x" while the software for the system is at phase "y" in a separate stream?

This, earned value issues aside, seems to present some fairly high risk synchronization issues. If any stream gets into trouble impacts in others would seem to be amplified. We used to worry about "marching army" and integration issues within one contract when one element within a phase appeared to be having schedule problems. The issues seemed exponential in others where large interacting systems were in separate developments, but at least individual systems could achieve success independently.

This scheme may offer some potential, but my first reaction based on this brief description is it also offers unusual system integration and schedule hazards. What is the mitigation plan for hardware being at an advanced stage and a software hitch then driving major changes in the hardware end? Somehow I have these little twinges about severe interstream impacts and lots of rework. There are advantages to making sure everything is integrated at the milestones.

The PM sure will need to be an expert ringmaster running something akin to several major circus shows at once in separate tents and driving toward a grand super duper end of show on the parade ground. Oops! The elephants from the red tent are supposed to charge into that space on the parade ground but the clowns from the blue tent haven't moved yet -- poor clowns.

Somehow I can't get the picture of another large, expensive disintegrated and probably dysfunctional system out of mind. My feeling is that this could happen even with the EV looking reasonably good in the separate streams. Nobody is showing crash and burn profiles, but the little problems compound into a systemic disaster.

By bob antonio on Saturday, October 07, 2000 - 06:53 am:

Ramon:

The project has high potential for failure for more than one reason.

The individual projects which will include software only or software and hardware together will move through the process concurrently. Several different project officers will be responsible for the individual projects as they move. The projects are supposed to be done in accordance with an enterprise architecture. Of course, the enterprise architecture is not complete and the projects are moving.

Currently, I believe that "hope" is the dominant project management technique being applied to the overall system of projects.

I assume this or something similar is taking place at a variety of organizations.

By Ramon Jackson on Saturday, October 07, 2000 - 10:27 am:

Bob, after sleeping on this the only positive thing that comes to mind is that the structure would allow contractual flex to adjust to schedule difficulties. For example, if one of the elements falls behind the TOs for dependent work are not executed. You have no "marching army" to pay. You probably lose experience in the wait.

My feeling (too little info to do much more) is the contractual structure advantage is bought at great price of increased risk of technical execution failure. If "hope" is the dominant PM approach hopeless is the best way to describe the prospects.

I expect you are correct in thinking this is going on elsewhere. It should bother us. We keep using the term "this isn't rocket science" and know what we intend. Actually this is "rocket science." The basic "science" for rockets was done long ago. How to get to Mars or place a warhead over a city block is a matter of money and engineering -- not science. Much of the complex work in today's rocket engineering is hardware-software integration.

A $400M enterprise hardware-software development is most definitely comparable to rocket engineering. Left to people who don't have the discipline to learn what we already know of its risks and mitigation techniques we have a familiar result -- fire and destruction at lift off.

I'll be unpopular. There is a body of experience on how and how not to do these things. People in an agency who willfully ignore the engineering knowledge available and cause a crash are negligent. We repeatedly have ego driven management saying they can defy sound engineering practices and burning tax dollars for little result. Until we enforce some real and individual penalties this will continue.

In no way do I mean we should punish someone for venturing into innovation and failing as long as they are providing a new datum in our collective learning curve. Doing 70, weaving through 50 mph traffic is not innovative driving -- it is reckless driving. Someone defying what we know about success and failure in large, complex developments without sound analysis and reasons for change are not innovators. They are reckless. They should be made into examples.