An Introduction to Catastrophe Disentanglement, Page 4
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 lifesaving 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
- 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 occurin 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.
Footnotes:(1) Hal was the wayward computer in Stanley Kubricks movie 2001: A Space Odyssey.
(2) Unless, of course, the project cannot be saved and gets cancelled.
(3) The most common argument is that organizations that permit overruns of more than 50%, or the release of products with severe quality problems, have little chance of survival.
(4) Without the need to speculate further, we can state that the 45% is a low figure; there are certainly more successful project rescues within the 30% who responded that some are saved and some are not. So the overlap may look even better.
About the AuthorE.M. Bennatans extensive hands-on management experience stems from many years as senior director at Motorola Inc., developing large software systems and leading multinational design centers. He has also been vice president of engineering at Midway Corporation, where he managed several hundred software and hardware engineers. A frequent lecturer and speaker on software project management, he is author of On Time Within Budget: Software Project Management, Practices and Techniques, Third Edition (Wiley, 2000). Mr. Bennatan is currently president of Advanced Project Solutions, Inc. (www.AdvancedPS.com) and senior consultant for the Boston Cutter Consortium.
About the BookCatastrophe Disentanglement: Getting Software Projects Back on Track
By E. M. Bennatan