An Introduction to Catastrophe Disentanglement
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% overschedule or over budget or had critically severe quality problems. The 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 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 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 organizations 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.
Tips Before You Proceed
There is no magic or mystery in the ten steps of the catastrophe disentanglement process. They are all familiar steps that many software developers will have used at various times in their careers. The strength of the process is in combining the steps together, implementing them as a single aggregate with each step building on the previous ones, and doing so within a short, fixed schedule.
Before proceeding with the implementation of the process, here is a summary of several of the tips that are provided throughout the discussion of the ten disentanglement steps.
- Work in parallel.
Though the ten steps of the process need to be completed in sequence, they do not need to start in sequence. In fact, parts of some of the steps can be implemented in parallel to others (this can save time). For example, step 8 (risk analysis) can begin as soon as step 3 (evaluate project status) is complete, and much of steps 5 and 6 (define and evaluate the feasibility of minimum goals) can be implemented in parallel.
- Expect resistance.
Expect resistance to change; it is natural. The best way to deal with resistance is by enlisting the support of allies from among the project stakeholders and the project team. In cases where resistance is particularly high, enlist the support of senior management.
- Be sensitive to the team and to the stakeholders.
Be sensitive to the emotional concerns of the project team and stakeholders. Team members will have legitimate job security and career concerns. Some of the stakeholders will have personal interests in the project that will not necessarily be financial or business related. Before proceeding, become familiar with the key stakeholders and team members.
- Keep within the schedule.
The process can easily slip well beyond the allocated two weeks; this will happen one day at a time, and at some point the delay is no longer manageable. Treat any delay (even of a half day) as a problem that needs to be immediately corrected.
Overcome delays by working whenever possible at a high level (leaving details to be filled in by the team after the project resumes), by using a project evaluation team, and implementing the disentanglement steps in parallel. If delays are caused by a lack of cooperation, enlist the immediate help of the organizations senior management.
- Do not proceed without senior management support.
The disentanglement process cannot succeed without firm visible support from senior management. The process requires significant cooperation from all involved parties, and this will not be assured without such senior management support.
The process also involves activities that will generate resistance from the project stakeholders and the development team. In some cases, it will be difficult or even impossible to overcome the resistance without the support of senior management.
- Encourage all involved parties to review the disentanglement process.
The disentanglement process is more likely to succeed if all involved parties understand how it works and why each step is being implemented. Thus, while the description in the following chapters is directed toward the project evaluator and the initiating manager, all parties involved in the effort to rescue the project will benefit by understanding the process.
- Document decisions and findings.
All key decisions and all major findings should be documented. This will save time, should the decisions need to be reevaluated or explained. The decisions and findings document should be maintained by the project evaluator and submitted to the initiating manager at the end of the process.
- Be open and accessible.
Many of the concerns and much of the reluctance to cooperate can be overcome by conducting the disentanglement in an open and candid manner. This means no clandestine decisions and no behind-closed-doors meetings except in rare occasions when topics of a purely personal nature are discussed (they should be kept to a minimum).
- Listen to arguments.
Be prepared to listen to arguments before decisions are finalized, provided they are of a professional nature (exclude political and personal interest viewpoints). After decisions have been made, be prepared to re-open them only if significant new information becomes available that was not previously considered. Be resolute about preventing undue delays in finalizing discussions and decisions.
- Not all problems discussed will occur.
The following chapters provide guidelines for resolving many problems that may arise during the disentanglement process. This can be alarming. Remember, not all problems will actually occurin fact, most will not. The guidelines are like a first aid kit; just because you carry anti-venom serum doesnt mean that you will be bitten by a snake.
- The key to success is a good evaluator.
Of all the factors that affect the disentanglement process, the two that most contribute to its success are senior management support (discussed earlier) and a good project evaluator. Start the search for evaluator candidates even before a final decision has been made to proceed with the disentanglement process.
- Read through the entire process.
Read through the entire process before proceeding. Many of the steps are inter-dependent. You can better implement each step if you understand the steps that follow.
One final point: There are no shortcuts. The disentanglement process is designed
to be implemented in its entirety. Each step relates to the evaluation or resolution
of a problem that, if left unsolved, is likely to disrupt the entire disentanglement
process. Furthermore, several of the steps are inter-dependent. In fact, the final
step (install an early warning system), which ensures that the project does not slip
back into catastrophe mode, is dependent on the preceding nine steps.
Page 3 of 4