An Introduction to Catastrophe Disentanglement

Deciding to Rescue a Project

There is no perfect breathalyzer for catastrophes. However, although it is difficult
to make a completely objective decision about a project, there are methods that
remove much of the subjectivity from the decision. These methods involve an indepth
evaluation of the project and require significant effort. Unlike status reports
or regular progress reviews, they are not designed to be applied at regular intervals
throughout the development cycle. The process prescribed by these methods
is to be applied only when we suspect that a project may be in serious trouble, but
we are unsure whether it requires life-saving surgery.

The procedure is based on the evaluation of three basic project areas:

Schedule

Budget

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.
Any one of these areas can trigger a catastrophe decision, but when this happens,
it is not unusual for serious problems to exist in all three. The tricky
question is what quality really is (the definition will be based on the level of product
defects and the degree to which customers or users are satisfied with the product).

Once the decision has been made that a project is indeed a catastrophe, the
options become more clear: save it or lose it. This is the time for the ten-step disentanglement
process.

The Disentanglement Process

The disentanglement process is designed to rescue a seriously troubled project,
provided it can establish business or strategic justification for doing so. The
process is built around two main figures: the initiating manager (who initiates the
process and oversees its implementation) and the project evaluator (who leads
and implements the disentanglement process). The initiating manager is an insider,
a senior manager in the organization that owns the project. The project evaluator
is an outsider, a seasoned professional, reliable, and impartial.

The catastrophe disentanglement process consists of the following ten steps:

Stop: Halt all project development activities and assign the team to support
the disentanglement effort.

Assign an evaluator: Recruit an external professional to lead the disentanglement
process.

Evaluate project status: Establish the true status of the project.

Evaluate the team: Identify team problems that may have contributed to
the projects failure.

Define minimum goals: Reduce the project to the smallest size that
achieves only the most essential goals.

Determine whether minimum goals can be achieved: Analyze the feasibility
of the minimum goals and determine whether they can reasonably
be expected to be achieved.

Rebuild the team: Based on the new project goals, rebuild a competent
project team in preparation for re-starting the project.

Perform risk analysis: Consider the new goals and the rebuilt team, identify
risks in the project, and prepare contingency plans to deal with them.

Revise the plan: Produce a new high-level project plan that includes a
reasonable schedule based on professionally prepared estimates.

Install an early warning system: Put a system in place that will ensure
that the project does not slip back into catastrophe mode.

There are three main reports generated by the project evaluator during the disentanglement
process:

Step 4: The team overview document
The document contains a summary of the project team evaluation. It is
used as input to step 7 (rebuild the team). The overview includes the
main sources of information, the list of interviews, the reasoning that led
to any significant findings, and any problems or incompatibles that arose
during the evaluation.

Step 6: The midway report
The document is generated midway through the disentanglement process
after establishing the feasibility of the minimized goals. This provides senior
management and other key stakeholders with a formal update on the
progress of the disentanglement process. The report documents all major
decisions, evaluations, and conclusions that produced the new reduced-scope
project. It also includes summaries of the discussion that led to
agreement among the key stakeholders.

At the end of the disentanglement process: The final report
Producing this report is the project evaluators last task. The report summarizes
all information collected and generated, all decisions made, all
major project documents produced, and lists all problems that were
resolved or left unresolved. This report is produced even if the disentanglement
process does not succeed or if the project is cancelled.

The sequence of the disentanglement steps is organized according to the logical
flow described in Table 1. It is important to complete the steps in this sequence
(though parts of the steps may overlap). The following points demonstrate why
the sequence is important:

There will not be enough information to propose new goals until the project
has been evaluated (this includes both the project status and the team).

There will not be enough information to rebuild the team until the new
project goals have been established.

There will not be enough information for a new plan (schedule and estimates)
until the new project goals have been established, the team has
been rebuilt, and the risks have been identified.

Table 1 Logical Flow of the Ten Disentanglement Steps

Each step
is strongly dependent on the cooperation of all involved parties and the active
involvement of the project team. But the main precondition for success is the support
of the organizations senior management. As we shall see in the following
chapters, without effective management support, the process will fail at almost
every step.

The entire process should take no more than two weeks to complete This also represents the maximum amount of time that the
project will remain halted.(2)

A Closer Look at the Data

We have seen in Figure 1 that software catastrophes are not rare, but the data in
Figure 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).

The data in Table 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 2 The Proportion in Software Development Organizations of Software Projects with
Severe Problems (Source: The Cutter Consortium, 2005)

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

By submitting your information, you agree that developer.com may send you developer offers via email, phone and text message, as well as email offers about other products and services that developer believes may be of interest to you. developer will process your information in accordance with the Quinstreet Privacy Policy.