This chapter is from the book
This chapter is from the book
This chapter is from the book
1.4 Summary
Disastrous software projects, or catastrophes, are projects that are completely out of control in one or more of the following aspects: schedule, budget, or quality. But obviously, not every overrun or quality problem means a project is out of control, so at what point should we define a software project as a catastrophe? What are the criteria for taking the drastic step of halting all activities, and how do we go about reassessing the project? And, most importantly, how do we go about getting the project moving again? The answers to these questions are the essence of the concept of catastrophe disentanglement.
Before the first step in the disentanglement process can be taken, we must first establish that the whole process is, indeed, necessary. This means deciding that the project, as it is currently proceeding, has little chance of success without taking drastic measures.
There are methods that can help remove much of the subjectivity from this decision. The idea is not to define an algorithm and subject projects to it every week, but rather to provide a procedure to be applied only when we suspect that a project may be in serious trouble and we are unsure if it requires drastic life-saving surgery.
The procedure is based on the evaluation of three basic project areas: schedule, budget, and quality. 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.
The disentanglement process is built around two main figures: the initiating manager, who initiates the process and overseas it as it is being implemented, and the project evaluator, who leads and implements the disentanglement process.
The ten steps of the catastrophe disentanglement process are
- Stop.
- Assign an evaluator.
- Evaluate project status.
- Evaluate the team.
- Define minimum goals.
- Determine whether minimum goals can be achieved.
- Rebuild the team.
- Perform risk analysis.
- Revise the plan.
- Install an early warning system.
The ten steps should be completed in sequence, and the entire process should take no more than two weeks to complete.
The following list summarizes several tips for the successful implementation of the disentanglement process:
- Work on the steps in parallel.
- Expect resistance from stakeholders and project team members.
- Be sensitive to the team and to the stakeholders. Before proceeding, become familiar with the key stakeholders and team members.
- Keep within the two-week disentanglement process schedule.
- Do not proceed without senior management support. The process cannot succeed without it.
- Encourage all involved parties to review the disentanglement process. The process is more likely to succeed if all involved parties understand how it works.
- All key decisions and all major findings should be documented.
- Be open and accessible. This will reduce concerns and any reluctance to cooperate.
- Be prepared to listen to arguments before decisions are finalized.
- Remember that not all problems discussed here will actually occur—in fact, most will not.
- The key to success is a good evaluator. Start the search early.
- Read through the entire process before proceeding. Many of the steps are inter-dependent.
There are no shortcuts in the disentanglement process. The 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.