Halt the Train Wreck

At times a project is deemed to be "out of control", "a train wreck", or a "catastrophe". A time-out is required to assess the project, the team, and the management, and to see if the project can be salvaged.

While it may seem reasonable to some that project development could continue in some way while these evaluations are being made, it is best to stop the project.

Evaluation of a project disaster requires the full involvement of the key team members (stakeholders, development staff, key management), and if project development is taking place in parallel you will not get the time and focus from them required to salvage it.

Unraveling the project will require decisions that may not be pleasant. These decisions can affect the team and project significantly. Allowing the project to limp along in catastrophe mode absorbs valuable resources without any real benefit to the project, and will allow important decisions to be put off. Halting the project will hopefully "light a fire" and drive home the point that the sooner decisions are made, the sooner the project can continue.

Halting the project also sends the message that top level management is serious about the disentanglement process.

Is Your Project A Budget Catastrophe?

E.M. Bennatan states that "a project is a budget catastrophe if the remaining projected cost far exceeds what the development organization is willing to pay for it". Or as it often is, what the sponsoring department or customer has allotted for the project.

Project overruns are often the result of schedule overruns, or of attempting to reduce these overruns (e.g., adding staff), so usually a schedule overrun is evaluated first.

A budget alarm is usually triggered if the expected remaining cost far exceeds its break-even value, however, many times this value is not given enough consideration up front.

Should the project be canceled if the remaining projected cost far exceeds what the development organization is willing to pay for it? Not always, since it was the projected cost that set off the alarm. Reducing the project scope may be an alternative, thus reducing the projected cost and allowing the project to continue. This is one of the key objectives in disentangling a software catastrophe.

Being Out Of Control

Managing a software project that is out of control is a miserable experience. It seems as everyone looks at you with anger or pity.

Many times senior management does not know when a project is out of control, or why. Too often they think that it is the project manager's fault, even when it is not. A project can be out of control for many reasons: senior management, appeasing the stakeholders, no rigor to the development cycle, etc.

Determining if a project is out of control is not always easy for in-house personnel to do. Many times it is best to bring in an outsider, much like a marriage counselor, to help evaluate and pose emotionally neutral conclusions and suggestions.

Once this has been done, the project can either be sorted out and re-started with a fresh set of goals and a new focus, or it can be shut down entirely.

Having a solid set of criteria with which to evaluate an out of control project, and the right evaluator, are paramount to the success of this process.