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
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.
Footnotes:
(1) Hal was the wayward computer in Stanley Kubrick’s 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 Author
E.M. Bennatan’s 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 Book
Catastrophe Disentanglement: Getting Software Projects Back on Track
By E. M. Bennatan
Add www.developer.com to your favorites Add www.developer.com to your browser search box IE 7 | Firefox 2.0 | Firefox 1.5.xReceive news via our XML/RSS feed
Catastrophe Disentanglement: Getting Software Projects Back on Track
IE 7
Firefox 2.0
