An Introduction to Catastrophe Disentanglement, Page 2
Deciding to Rescue a Project
There is no perfect breathalyzer for catastrophes. However, although it is difficult to make a completely objective decision about a project, there are methods that remove much of the subjectivity from the decision. These methods involve an indepth evaluation of the project and require significant effort. Unlike status reports or regular progress reviews, they are not designed to be applied at regular intervals throughout the development cycle. The process prescribed by these methods is to be applied only when we suspect that a project may be in serious trouble, but we are unsure whether it requires life-saving surgery.
The procedure is based on the evaluation of three basic project areas:
The procedure examines whether serious problems have existed for quite a while in any of these project areas and whether the situation is getting worse, not better. Any one of these areas can trigger a catastrophe decision, but when this happens, it is not unusual for serious problems to exist in all three. The tricky question is what quality really is (the definition will be based on the level of product defects and the degree to which customers or users are satisfied with the product).
Once the decision has been made that a project is indeed a catastrophe, the options become more clear: save it or lose it. This is the time for the ten-step disentanglement process.
The Disentanglement Process
The disentanglement process is designed to rescue a seriously troubled project, provided it can establish business or strategic justification for doing so. The process is built around two main figures: the initiating manager (who initiates the process and oversees its implementation) and the project evaluator (who leads and implements the disentanglement process). The initiating manager is an insider, a senior manager in the organization that owns the project. The project evaluator is an outsider, a seasoned professional, reliable, and impartial.
The catastrophe disentanglement process consists of the following ten steps:
- Stop: Halt all project development activities and assign the team to support the disentanglement effort.
- Assign an evaluator: Recruit an external professional to lead the disentanglement process.
- Evaluate project status: Establish the true status of the project.
- Evaluate the team: Identify team problems that may have contributed to the projects failure.
- Define minimum goals: Reduce the project to the smallest size that achieves only the most essential goals.
- Determine whether minimum goals can be achieved: Analyze the feasibility of the minimum goals and determine whether they can reasonably be expected to be achieved.
- Rebuild the team: Based on the new project goals, rebuild a competent project team in preparation for re-starting the project.
- Perform risk analysis: Consider the new goals and the rebuilt team, identify risks in the project, and prepare contingency plans to deal with them.
- Revise the plan: Produce a new high-level project plan that includes a reasonable schedule based on professionally prepared estimates.
- Install an early warning system: Put a system in place that will ensure that the project does not slip back into catastrophe mode.
There are three main reports generated by the project evaluator during the disentanglement process:
- Step 4: The team overview document The document contains a summary of the project team evaluation. It is used as input to step 7 (rebuild the team). The overview includes the main sources of information, the list of interviews, the reasoning that led to any significant findings, and any problems or incompatibles that arose during the evaluation.
- Step 6: The midway report The document is generated midway through the disentanglement process after establishing the feasibility of the minimized goals. This provides senior management and other key stakeholders with a formal update on the progress of the disentanglement process. The report documents all major decisions, evaluations, and conclusions that produced the new reduced-scope project. It also includes summaries of the discussion that led to agreement among the key stakeholders.
- At the end of the disentanglement process: The final report Producing this report is the project evaluators last task. The report summarizes all information collected and generated, all decisions made, all major project documents produced, and lists all problems that were resolved or left unresolved. This report is produced even if the disentanglement process does not succeed or if the project is cancelled.
The sequence of the disentanglement steps is organized according to the logical flow described in Table 1. It is important to complete the steps in this sequence (though parts of the steps may overlap). The following points demonstrate why the sequence is important:
Table 1 Logical Flow of the Ten Disentanglement Steps
Each step is strongly dependent on the cooperation of all involved parties and the active involvement of the project team. But the main precondition for success is the support of the organizations senior management. As we shall see in the following chapters, without effective management support, the process will fail at almost every step.
The entire process should take no more than two weeks to complete This also represents the maximum amount of time that the project will remain halted.(2)
A Closer Look at the Data
We have seen in Figure 1 that software catastrophes are not rare, but the data in Figure 1 does not tell the whole story. Could these projects have been saved if a formal disentanglement process (like the one we described earlier) had been used in time? An indication can be found by looking at additional data related to the schedule, budget, and quality of the projects (these are the factors that would have triggered the process).
The data in Table 2 is based on a broad software development survey  that defined a schedule overrun of more than 50% as severe, a budget overrun of more than 50% as severe, and the quality problems of a product with critical post-release defects as being severe. These projects are considered failures even though they were permitted to run their course to completion (and many would submit that they should not have been permitted to do so).(3)
- Schedule: The data clearly shows that severe schedule overruns are far from rare. In a quarter of the surveyed software organizations, more than 10% of the projects had severe schedule overruns. In 13% of these organizations, the situation was much worse: more than a quarter of their projects had severe schedule overruns.
- Budgets: The data for software project budgets is just a shade better. In just less than a quarter of software organizations, more than 10% of the projects were severely over budget. In 8% of these organizations, more than a quarter of the projects were severely over budget.
- Quality: The data for quality does not tell a good story. More than a third of software organizations (35%) had severe quality problems in more than 10% of their products after their release. Of these, 15% reported severe quality problems in more than a quarter of their products after their release.
Table 2 The Proportion in Software Development Organizations of Software Projects with Severe Problems (Source: The Cutter Consortium, 2005)