- Overview of the Catastrophe Disentanglement Process
- A Closer Look at the Data
- Tips Before You Proceed
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.2 A Closer Look at the Data
We have seen in Figure 1.1 that software catastrophes are not rare, but the data in Figure 1.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).
){kind=link}
The data in Table 1.2 is based on a broad software development survey [8] 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 1.2 The Proportion in Software Development Organizations of Software Projects with Severe Problems (Source: The Cutter Consortium, 2005)
|
Severe Schedule Problems |
Severe Budget Problems |
Severe Quality Problems |
|||
|
More than 10% of projects were very late |
25% |
More than 10% of projects were greatly over-budget |
24% |
More than 10% of projects had critical quality problems |
35% |
|
More than 25% of projects were very late |
13% |
More than 25% of projects were greatly over-budget |
8% |
More than 25% of projects had critical quality problems |
15% |
After a severely troubled project is completed or cancelled, there is, of course, no way of telling whether the outcome could have been different. However, we speculate that many of these severely troubled projects could have been rescued. At the very least, such projects would have greatly benefited from an early warning system. The survey findings are from projects that were more than 50% over-schedule or over budget or had critically severe quality problems. The warning system, which is further discussed in Chapter 12, "Step 10—Create an Early Warning System," is designed to trigger an alarm whenever such conditions begin to develop.
Interestingly, the survey found that 50% of software development organizations do implement some type of project rescue process. These companies reported that they handle early indications of project failure by initiating a formal project reevaluation process resulting in possible changes to goals, plans, and the development team. These are precisely the elements of the catastrophe disentanglement process presented in this book. Furthermore, according to another survey finding shown in Figure 1.2, 45% of organizations almost always succeed in getting troubled projects back on track. We can speculate that they overlap the 50% that conduct rescue processes.4 These, then, are organizations that have independently developed catastrophe disentanglement processes, and have apparently applied them to great effect.
)
Figure 1.2 How frequently are troubled projects saved?
The survey also looked at the cost of catastrophes. When asked to assess the impact of software project failures on their organization, the most common response lamented the waste of funds, time, and other resources. Others reported a decline in the organization’s motivation and prestige and the loss of customers and business opportunities. Clearly, the high cost of project catastrophes goes way beyond the cost of the failed project itself. With an effective disentanglement process, it is practically certain that much of these costs could have been avoided.