Home > Articles > Programming > Java

An Introduction to Catastrophe Disentanglement for Software Projects

📄 Contents

  1. Overview of the Catastrophe Disentanglement Process
  2. A Closer Look at the Data
  3. Tips Before You Proceed
  4. Summary
Just as the smart thing to do when a ball of twine seems hopelessly entangled is to stop whatever we are doing with it (otherwise, the tangle gets worse), so it is with a disastrous project; the longer we keep at it, the worse it gets. At some point, we need to halt all activity and reassess what we are doing. This chapter introduces you to the concept of catastrophe disentanglement.
This chapter is from the book

In Spencer Johnson’s Who Moved My Cheese [9], the little people keep coming back to where the cheese used to be even though it’s not there anymore. It’s a natural tendency to continue doing what we did before even when, to an outside observer, it no longer makes sense. This behavior is quite common when software projects get into trouble. We keep plodding away at the project hoping that the problems will go away and the "cheese" will miraculously reappear. In all too many cases, it doesn’t.

Just as the smart thing to do when a ball of twine seems hopelessly entangled is to stop whatever we are doing with it (otherwise, the tangle gets worse), so it is with a disastrous project; the longer we keep at it, the worse it gets. At some point, we need to halt all activity and reassess what we are doing.

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. They are by no means rare; 44% of surveyed development organizations report that they have had software projects cancelled or abandoned due to significant overruns, and 15% say that it has happened to more than 10% of their projects (see Figure 1.1).

Figure 1.1 Percentage of surveyed organizations’ software projects that have been abandoned or cancelled due to significant cost or time overruns in the past three years (source [12])

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? 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.

One of the best-known attempts to disentangle a multi-hundred-million-dollar catastrophe ended recently, more than a decade after it began. In August 2005, the plug was finally pulled on the infamous Denver airport baggage handling system, in a scene reminiscent of Hal’s demise in the memorable Kubrick space odyssey movie.1 This was a project that had gained notoriety for costing one million dollars a day for being late. One of the interesting questions about the Denver project is why didn’t the repeated efforts to save it succeed?

Of all the problems that plagued the project (see [3], [4]), probably the most formidable was the project’s unachievable goals. It is unlikely that anyone associated with the project could have brought about a significant change to the goals because the project’s extravagant functionality had, in fact, become part of its main attraction. But the ability to define achievable goals is a cornerstone of any catastrophe disentanglement process, without which the process cannot succeed, and that is one of the main reasons the Denver system could not be disentangled.

As indicated by the above survey data, cases like the Denver project are not rare (although few are as extreme). Most development organizations know this even without seeing the survey data. This frustrating reality was expressed in a famous quote from Martin Cobb of the Canadian Treasury Board: "We know why projects fail, we know how to prevent their failure—so why do they still fail?" [10].

Cobb’s quote highlights the conventional approach of software engineering. The objective of existing software engineering practices is to prevent the occurrence of software catastrophes—that is, to prevent the project from spiraling out of control. As such, the practices have an important role to play in software development. However, more than five decades of experience show that despite these methods, software catastrophes will continue to be around for a while.

When a software project is out of control, there is no PMI, IEEE, SEI, or ISO rescue process to follow because these organizations offer preventive, rather than corrective, solutions. But is such a project necessarily doomed? Will it inevitably collapse in failure? The following chapters will show that this is far from inevitable.

This book fills the void for corrective solutions in software engineering. It deals with projects that are already in serious trouble. In fact, this book is less concerned with how we got into trouble; it is more concerned with how we get out.

1.1 Overview of the Catastrophe Disentanglement Process

Before the first step in disentangling a project can be taken, we must first establish that the whole process is necessary. This means deciding that the project, as it is currently proceeding, has little chance of success without taking drastic measures.

Many software organizations have difficulty making this decision, and some avoid it entirely. In fact, there is a general tendency to let troubled projects carry on way too long before appropriate action is taken [6]. Keil [7] uses the term "runaways" to describe software projects that continue to absorb valuable resources without ever reaching their objective. Keil’s runaways are, in effect, undiagnosed catastrophes that went on unchecked for much too long. Indeed, the ability to save a project is usually dependent on how early in the schedule a catastrophe is diagnosed. Furthermore, organizations that permit a runaway project to continue are wasting valuable resources. This reality is well demonstrated in the following case.

1.1.1 A Case Study

The FINALIST case, described next, demonstrates how difficult it is to acknowledge that a project is in serious trouble, even when the problem is obvious to almost anyone looking in from the outside. It is an interesting case because it is by no means unique; it demonstrates just how easy it is to become committed to a failing path.

After the year 2000 passed, and the software prophets of doom faded away, a Canadian software company found itself with almost no customers for one of its small business units. The unit’s main expertise was in supporting Cobol programs (where many of the bug-2000 problems were expected to be), and suddenly there wasn’t enough Cobol work to support it.

So the company decided to rewrite one of its core products, FINALIST, a large financial analysis system, but it chose to write it again in Cobol in order to retain the company’s unique expertise for solving bug-2000 problems (which it still thought would materialize). The new project, appropriately named FINALIST2, was given a 30-month schedule and a team of 14 developers, eight of whom were veteran Cobol programmers.

At the beginning of the second year of the project, two Cobol programmers retired and, soon after, three more moved to another company. With only three veteran Cobol programmers left, the FINALIST2 project began to experience serious problems and schedule delays. The company’s management repeatedly resisted calls to reevaluate the project and attempted to get it back on track by conducting frequent reviews, adding more people to the team, providing incentives, and eventually, by extending the schedule.

Finally, 28 months into the project, a consultant was brought in, and his first recommendation was to halt the project immediately. This drastic advice was based on the conclusion that little or no meaningful progress was being made and the project, as it was defined, would probably never be completed. There were not enough experienced Cobol programmers around to do the work, and it was unlikely that new ones would be hired. Furthermore, it was unlikely that the new recruits would become sufficiently proficient in Cobol within any reasonable time frame.

The final recommendation was to either restart the project in a modern programming language or to cancel it entirely.

One of the key points in this case is that management failed to notice that what was once a strength (Cobol) had ceased to be one—a classic example of "who moved my cheese." This failure was clearly fostered by a strong desire to preserve Cobol expertise within the company, but it was also the result of a natural reluctance to acknowledge a mistake (resistance to reevaluate the project). These two factors obscured the solution. And so management attempted to fix almost everything (process, team, schedule) except the problem itself.

This case illustrates the difficulties decision makers have in accepting the need for drastic measures and is reminiscent of a gambler who cannot get up and walk away. First, there is the natural tendency to put off making the difficult decision in hope that conventional methods will eventually get the project back on track. A second difficulty involves over-commitment to previous decisions, prompting the investment of more resources to avoid admitting mistakes (this is known as escalation [6]).

But troubled projects are never a surprise, and even those most committed to a failing path know that something is severely wrong. But how severe is "severely wrong"? How can we know that it is time for drastic measures? Ideally, there would be a decision algorithm (a kind of software breathalyzer) to which managers could subject their projects, and which would make the decision for them.

1.1.2 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 in-depth 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. Chapter 2, "When Is a Project a Catastrophe?," covers this subject in detail and also discusses the tricky question of what quality 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.

1.1.3 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:

  1. Stop: Halt all project development activities and assign the team to support the disentanglement effort.
  2. Assign an evaluator: Recruit an external professional to lead the disentanglement process.
  3. Evaluate project status: Establish the true status of the project.
  4. Evaluate the team: Identify team problems that may have contributed to the project's failure.
  5. Define minimum goals: Reduce the project to the smallest size that achieves only the most essential goals.
  6. 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.
  7. Rebuild the team: Based on the new project goals, rebuild a competent project team in preparation for re-starting the project.
  8. Perform risk analysis: Consider the new goals and the rebuilt team, identify risks in the project, and prepare contingency plans to deal with them.
  9. Revise the plan: Produce a new high-level project plan that includes a reasonable schedule based on professionally prepared estimates.
  10. 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:

  1. Step 4: The team overview document

  2. 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.

  3. Step 6: The midway report

  4. 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.

  5. At the end of the disentanglement process: The final report

  6. 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.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.1 Logical Flow of the Ten Disentanglement Steps



Launch the process

1, 2

Evaluate the status

3, 4

Introduce changes

5, 6, 7

Prepare to resume

8, 9, 10

Each one of these steps is described in detail in the following chapters. Their success 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 (see the disentanglement timeline in Figure 13.1 of Chapter 13, "Epilogue: Putting the Final Pieces in Place"). This also represents the maximum amount of time that the project will remain halted.2

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020