Cutting Your Losses: Extricating Your Organization When a Big Project Goes Awry

We’ve all heard the parable of the frog that is placed in a pot of water and then boils to death as the water is gradually heated. Though the parable has since been debunked, it still serves as a rich metaphor for describing how our finest organizations and executives sometimes get themselves into trouble.1 To extend the metaphor further, many of our most popular business articles and books can be said to have focused, in one way or another, on how to avoid getting boiled to death. Leavitt’s “Marketing Myopia” is a classic in this regard.2 How could buggy whip manufacturers be so shortsighted as to not see that the age of the automobile would wipe out their market? Why did they stubbornly refuse to think more broadly about the market they served? More recently, Clayton Christensen advances the idea that “disruptive technologies” can catch successful companies off guard, causing them to fail.3 Overcommitment to a course of action (even one that has worked in the past and now may be working) is likely to make executives miss certain warning signs or misinterpret them when they do appear. Returning to the frog parable, executives are apt to ignore the fact that the temperature around them is gradually rising. Like real frogs, however, executives can escape from their pot of hot water.

The problem is that, in many cases, executives become so strongly wedded to a particular project, technology, or process that they find themselves continuing when they should pull out. Instead of terminating or redirecting the failing endeavor, managers frequently continue pouring in more resources.4 Management scholars call this escalation of commitment to a failing course of action.5 While escalation of commitment is a general phenomenon, it is particularly common in technologically sophisticated projects with a strong information technology (IT) component. The special nature of these projects—including the high complexity, risk, and uncertainty they involve—makes them particularly susceptible to escalation. Consider the following example.

In 1992, California’s Department of Social Services (DSS) began a project to develop the Statewide Automated Child Support System (SACSS). The development work was contracted out to Lockheed Martin under a $75.5 million contract and was scheduled to take 3 years to complete. But by 1995, the estimated cost of the still unfinished project had grown to $260 million. Though the project was plagued by cost overruns, a flawed procurement process, and political struggles, the state’s Department of Information Technology continued it as though nothing was wrong. In January 1997, a report filed by an independent firm assessing the project concluded that it was unlikely the project’s problems could ever be solved. In April 1997, the California Assembly Information Technology Committee issued its oversight report on the project asking: “How bad does a particular project need to become before the state’s information technology czar considers termination?” Finally, in November 1997, the SACSS project was cancelled by John Thomas Flynn, California’s chief information officer, after more than five years of work. Final costs were estimated to be as high as $345 million.6

If the above example were an isolated case, there would be no cause for concern. Unfortunately, many such IT projects fail each year. Moreover, press coverage of IT project escalation is growing.7 A recent survey of information systems auditors revealed that 30% to 40% of all IT projects exhibit some degree of escalation.8 While much is known about the factors that can cause managers to become locked into a cycle of escalating commitment to a failing course of action, comparatively little attention has been paid to de-escalation, or the process of breaking such a cycle.9 Only a dozen or so studies have been published on de-escalation, and of these only a handful have examined actual projects in real organizations.10

During the past 8 years, we have examined more than 40 cases of IT project escalation, seeking to understand how and why escalation occurs and, more importantly, how troubled projects can be brought back under control.11 These studies provide many insights into how executives can successfully turn around troubled projects or abandon them entirely, if necessary. Many lessons were learned about the process of de-escalation from an in-depth case analysis of the computerized baggage-handling system that was to be a central part of the Denver International Airport (DIA).12

More importantly, the de-escalation process derived from the Denver International Airport suggests a framework that can be used to understand other cases involving project escalation—for example, the London Stock Exchange’s Taurus project. Executives who understand and apply this framework will be better able to extricate themselves and their organizations from failing courses of action.

Denver’s Baggage-Handling Boondoggle

The initial ground breaking for the DIA project occurred in late 1989, and the original plan called for completion of the airport by fall 1993. Ironically, the initial project design did not incorporate an airport-wide baggage-handling system; the airport planners expected the individual airlines to build their own systems as they did in most other U.S. airports. In 1991, United Airlines (one of the airlines to commit early to leasing gates at DIA) did exactly that, commissioning BAE Automated Systems, Inc. to develop an automated baggage-handling system for its B Concourse. Not until 1992, two years into the construction of the new airport, did the project’s top managers recognize the potential benefits of an airport-wide, IT-based baggage-handling system. As a result, airport planners and consultants developed specifications for such a system. The proposed system was to include 3100 independent “telecars” to route and deliver luggage among the counters, gates, and claim areas of 20 different airlines. Plans called for 55 personal computers networked to each other and to 5000 optical detectors, 400 radio receivers, and 56 bar-code scanners in a central control system. The system was designed to move a passenger’s bag from any injection point to any destination in the airport in less than 15 minutes and would be able to process more than 1000 bags per minute—two to three times faster than a conventional conveyor belt. Faster baggage handling would translate into increased ground-time efficiency, reducing turnaround time for hub operations and improving services to passengers.13 In April 1992, after viewing a prototype of the proposed system, Denver officials awarded a $175.6 million contract to BAE Automated Systems to build the computerized baggage system for the entire airport.

First construction problems, then difficulties with the baggage system kept the airport from opening on schedule in October 1993. The national and international media picked up the story, and the project came under intense investigation by various federal agencies. In April 1994, as the computerized baggage system contractor, BAE, was preparing for the first test of its system, the city of Denver invited reporters to observe the test. There were 7000 bags to be moved to Continental’s Concourse A and United’s Concourse B. So many problems were discovered that testing had to be halted. Reporters saw piles of discarded clothes and other personal items lying beneath the telecar tracks.

After the test, Denver Mayor Wellington Webb delayed the airport’s opening for an indefinite period. “Clearly, the automated baggage system now underway at DIA is not yet at a level that meets the requirements of the city, the airlines, or the traveling public,” he said. “There is only one thing worse than not opening DIA…[and] that is opening the airport and then having to shut it down because the [baggage] system doesn’t work.”

Initially, Webb reconfirmed his commitment to the baggage-handling system, saying DIA would not open until “milestones are met and I have seen the baggage system operate successfully.”14 Eventually, however, he withdrew his commitment to the system. Dealing with the costs of further delays meant redefining the problem and finding an expedient way to open the airport as soon as possible. Ultimately, DIA implemented a manual baggage-handling system based on propane-powered tugs and carts.

When the airport finally opened in late February 1995, it was 16 months behind schedule and close to $2 billion over budget. By this time, the airport-wide computerized baggage-handling system had effectively been abandoned, leaving two concourses served by a manual baggage system and one concourse served by a scaled-down semi-automated system. By examining the process that Mayor Webb followed to extricate himself and the city of Denver from this failing course of action, we present a framework for understanding the process of de-escalation and, in the accompanying table, outline the events that transpired in the DIA case and their relationship to our framework.

The framework’s first phase involves problem recognition. Clearly, no corrective action can be taken unless or until executives in a position of authority see the problems and begin to perceive their seriousness. Executives can move through this phase by being mindful of the warning signs indicating that a project is in trouble. In an ideal world, this should be possible without pressure from outside the organization, but, in the case of DIA, managerial action was not possible until the executives involved began to both recognize negative feedback and respond to external pressure. Of course, the challenge lies in being able to recognize the difference between the normal level of setbacks that inevitably occur in large and technologically complex projects and the level of negative feedback that necessitates rethinking a previously chosen course of action.

While recognizing that the problem is often said to be 80% of the solution, the remaining 20% can be especially difficult to resolve for escalating projects. In order to reduce the commitment to a previously chosen course of action, it is necessary to objectively reexamine the previously chosen path. The problem in this phase is that project data is often convoluted. There may be too little information or there may be too much, with no way to sift out the important issues. In addition, escalation tends to be accompanied by conflicting advice—with some stakeholders having a vested interest in maintaining the status quo while others exert pressure to change direction. Executives themselves sometimes find it difficult to step back and think “outside the box,” although it’s desperately needed during this phase. In the case of DIA, managerial action during this phase only became possible when the executives involved were able to both clarify the magnitude of the problem and redefine it.

The third phase of our framework involves searching for an alternative course of action. The executive’s focus during this phase should be to contain the damage associated with the current course of action, while identifying alternatives. In this phase, executives must begin to convince others within (and, sometimes, outside) the organization that it is necessary to change course. Part of the work here involves obtaining independent evidence of problems with the existing course of action while identifying and legitimizing a new course of action. Given the political nature of escalating projects, merely identifying an alternative course of action is insufficient to bring about change. The alternative course must be legitimized and sold to stakeholders.

The fourth and final phase of our framework involves implementing an exit strategy. Again, merely identifying an alternative course of action is akin to strategy formulation without any regard for how that strategy can best be put into practice. No matter how sound the strategy may be, we will fail to realize the benefits of it without a cogent plan for implementation. Successful implementation requires preparing key stakeholders and managing impressions.

While the framework was derived in the context of the DIA case, it can be used to understand other cases of de-escalation as well, including the Taurus project at the London Stock Exchange. While the Taurus and DIA cases differ in many respects (i.e., they involve different project contexts and very different kinds of systems and organizations), the underlying processes used to reduce commitment were quite similar.

Taurus Comes Crashing Down

Settlement of share transactions involves two phases: clearance and settlement. Clearance is the process of identifying the parties and what they owe. Settlement is the process of ensuring that shares and payments are properly transferred to buyers and sellers. Beginning in 1979, the London Stock Exchange had come to rely on a system known as Talisman for the task of clearance, but the settlement process was still paper-based. Further reform of the settlement system would require a new system that could handle book entry transfer, eliminating paper from the process. In May 1986, the London Stock Exchange began the Taurus project, a computerized system for equities settlement, but at the time there was little agreement concerning the requirements of the system. The project was initially expected to take three years and cost £6 million. But with the London Stock Exchange scheduled to undergo deregulation in October 1986 and the pressure to complete nine other IT projects—all scheduled to go live on “Big Bang” day—the Taurus project was forgotten.

Following deregulation in 1986, there was a growing recognition that share settlement procedures were outdated and inefficient and that, in order to remain competitive, the stock exchange would need to improve its offerings of value-added services to the securities industry, with settlement being one such service. Moreover, the October 1987 stock market crash, which wiped out £50 billion in U.K. share values, exposed the weakness of the existing settlement system.15 In 1988, the Taurus project was resurrected when a citywide commission agreed on the basis of a book entry system, envisioning a central register of share ownership to be maintained by the stock exchange. Taurus was to replace London’s antiquated paper-based procedures with a state-of-the-art system of electronic transfer. By autumn 1988, as the scope and complexity of the proposed system mounted, so too did the cost estimates for completing the project: Cost estimates to complete the system had increased by a factor of 10 to £60 million. The revised cost estimate, coupled with concerns over technical feasibility and resistance from the clearing banks, caused the project to be scuttled in March 1989. By 1989, the recently formed Securities Industry Steering Committee on Taurus (known as Siscot) began to play a significant role in establishing a new design for Taurus that would be acceptable to all stakeholders (e.g., retail brokers, market makers, clearing banks, international custodians). Finally, by the end of 1989, after considering 17 different designs for Taurus, agreement was reached. The resulting design welded together the various options that had previously been proposed, yielding a compromise solution of great complexity. As one observer noted: “It was like starting to plan a dinner for two and finishing up with sixteen.”16 The projected cost to implement the new Taurus dropped to £50 million and the schedule for implementation was October 1991.17 Even so, a number of individuals were by now quietly voicing their opposition to the project, but “no one was prepared to speak out publicly, however, for Taurus had become sacrosanct and vital, it was said, to London’s continued preeminence as a world financial centre.”18

Meanwhile, the role of the London Stock Exchange itself was being redefined in the wake of deregulation. In November 1989, Peter Rawlins was appointed chief executive of the exchange and was directed to implement a drastic program of reforms. He inherited a stock exchange whose influence had waned with the onset of deregulation and whose bloated cost structure was no longer sustainable. Ironically, while deregulation had revolutionized the equities market, the stock exchange had continued to conduct itself as though little had changed. Member firms—whose profits had been squeezed by the ending of fixed commissions—saw the stock exchange as costing them a lot of money, but doing little to promote the financial services industry.

In assuming his new position, Rawlins also inherited Taurus. Rawlins said that he had been skeptical about the direction of the Taurus project and its prospects for success from the moment of his arrival and that he had raised his concerns with the exchange chairman and leading members of the banking community. However, he said that he quickly concluded that the project had taken on a life of its own and that there was little he could do to stop or redirect it. As a result, he took a hands-off approach toward Taurus. In doing so, Rawlins contributed to further escalation of commitment to a failing course of action. As Rawlins recalled in an interview:

“There was a full-time partner of Coopers overseeing the project. Funds had been voted, budgets had been set, the parameters were away, we had monitoring committees…. I fought my corner for a while and thought, ‘Fine, if you are all happy with this, that’s fine. Let’s get on.’”19

As the Taurus development process unfolded, one problem after another began to surface. To shave time off the development process and to avoid having to hire additional staff, in-house development was rejected, and the Exchange instead began to look for packaged software that could be modified to provide the required functionality. By June 1990, a development contract was signed with Vista Corporation, which agreed to modify its package, charging the Exchange on a time-and-materials basis.20 The stock exchange team that evaluated the software estimated it would take about a year and cost £1 million to customize Vista’s software. These estimates, however, were based on a set of high-level requirements for Taurus (since there was no detailed design at that time) and a superficial understanding of Vista’s software. By the end of 1990, it had become clear that the software would require far more modification than originally anticipated. In January 1991, unforeseen legal and security issues began to emerge, forcing further changes to the existing set of requirements and pushing back the scheduled launch of Taurus from October 1991 to April 1992. By May 1991, the scheduled implementation was again delayed until May 1992, reflecting the continued difficulties of keeping the project on track.

Taurus continued to slip. In August 1991, three months after the latest delay was announced, the stock exchange commissioned Coopers & Lybrand to conduct a review of the Taurus project. The consultant’s report concluded that, while the project was still feasible, the earliest possible implementation date would be April 1993, a full year later than the most recent estimate. Rawlins continued to have his doubts about the project and said that he once again considered stopping it. Instead, he followed the path of least resistance. The stock exchange board approved continued funding of the project until March 1993. In October 1991, the stock exchange announced May 1993 as the new implementation date for Taurus. By this time, the projected final cost of Taurus had escalated to £80 to £90 million.

By January 1993, only three months before Taurus was to be launched, press reports began to appear predicting that Taurus would not be completed until spring 1994. Finally, on 11 March 1993, Rawlins met with the stock exchange board and, on 12 March 1993, the exchange publicly announced that the Taurus project had been canceled. In the end, the stock exchange had spent over £80 million, and securities firms within the city of London had collectively spent an estimated £400 million developing their own system in preparation for Taurus. All of this spending was for naught as Taurus came crashing down.

Mapping the Four-Phase Framework to Taurus

Phase 1: Problem Recognition

Recognizing Negative Feedback.

Rawlins and the board had many indications that Taurus was not only escalating but failing miserably. The initial Taurus project began in 1986 and had already missed its first deadline by the time Rawlins joined the exchange in 1989. Resurrected in 1988 and then abandoned in 1989, this initial attempt to develop Taurus was such a disaster that the stock exchange was already under criticism for having spent considerable time and resources without ever delivering a system. Following this failed attempt, Taurus was redesigned by a committee and relaunched later in 1989, but even the project director had “grave concerns” about the viability of the project.21 Many observers believed that Taurus should have been stopped in mid-1991, when legal and security problems became recognized as major obstacles.22 By October 1991, the timetable had slipped by 100% and the £50 million budget had been spent.23 In short, Rawlins had plenty of warning signs that Taurus was off track. While Rawlins may have sensed negative feedback from the moment he joined the exchange, for a long period of time he chose to ignore this feedback.

The first public sign that the new Taurus was in trouble had come in January 1991, when implementation was postponed for six months, from October 1991 to April 1992. Only four months later, in May 1991, a second delay was announced. Three months later, in August 1991, the schedule for Taurus was extended yet again when Coopers & Lybrand concluded the project was still feasible but could not be completed until April 1993 at the earliest. In addition, Rawlins and the board were privy to many other signs of impending failure. For instance, in June 1992, the prototype communications server, supplied by another vendor, failed to work. As one observer noted:

“You realized that you were increasingly operating at the edge of available technology. We were constantly moving out to a point where not even the major suppliers could guarantee that what they were supplying would work.”24

In July 1992, more troubling news emerged when consulting firm Touche Ross published the results of a survey claiming that the equities market was “plagued by doubts” because of all the delays and changes to the design.25 Their report also indicated that leading executives within the securities industry were having second thoughts about the wisdom of going forward. Still more damaging news arrived in the middle of 1992, when Rawlins was told that only 50% of the Vista software had been modified at a cost of £14 million, 14 times more than originally estimated.

Responding to External Pressure.

By summer 1992, external pressure mounted as a sense of impending crisis enveloped the market. The securities industry was becoming acutely aware that Taurus was not going to deliver the functionality that had been promised. In the words of one broker: “It was all starting to blow up.”26 Feedback was becoming increasingly negative and “some city observers were now suggesting to the press that Taurus was destined never to appear.”27 The press was beginning to publish articles questioning whether the project would ever be finished. At the same time, John Watson, the Taurus project manager, requested funding for another 18 Coopers & Lybrand consultants to complete development and testing of the software. Ultimately, Rawlins and the board could no longer ignore the increasing pressure from the press, the securities industry, and the Taurus monitoring group, which consisted of senior representatives of the securities industry. Rawlins responded to the pressure by reasserting his control over Taurus.

Managerial Action.

By autumn 1992, Rawlins recognized he had a problem that could no longer be ignored and, under mounting external pressure, he began to take action. Rawlins denied Watson’s request for additional resources. His answer: “No more staff and no more money. This is what we are going with.” In October 1992, Rawlins commissioned Andersen Consulting to examine the Taurus project. By November, he was referring to Taurus as “his albatross,” a “bottomless pit,” and a “brick ‘round his neck.’”28

Phase 2: Reexamination of the Prior Course of Action

Clarifying the Magnitude of the Problem.

In December 1992, Andersen had issued an eight-page report indicating that the system was “not designed, let alone built” and that core elements of Taurus “had been classified as peripheral requirements and were therefore not due to be built until late 1993.” Rawlins was “horrified to discover that as late as December 1992, three years after building had commenced, the design was still incomplete.”29 The Andersen report estimated three years would be needed to complete the Taurus project—two years to complete development and a third to test the system.

Redefining the Problem.

Rawlins recalled that, when he became head of the exchange in 1989:

“I had all sorts of warning bells flying around in my head. I was writing to people asking them about Taurus, and it just wasn’t ringing straight. The answer that came back to me was, ‘Look, this has been a heartache for everybody way before you arrived… Just leave that alone, that’s now in good hands.’”30

It seemed no matter who Rawlins spoke with, the answer was always the same: “Don’t bother about Taurus. It’s the one thing that’s OK. Don’t touch it, please. Just let that happen.’”31

Although Rawlins says he had reservations about Taurus from the moment he joined the exchange, he chose to focus his attention on other areas, believing that he was hired to implement a drastic program of organizational change aimed at restructuring the exchange. For three years, Rawlins did not take steps to turn Taurus around. Rawlins seemed to be more interested in restructuring the exchange. As one observer noted: “It was very difficult to get him to focus on Taurus. He always seemed to want to wash his hands of it.”32 For years, he distanced himself from the project and was genuinely surprised by the gravity of the situation as outlined in the Andersen report. The Andersen report caused Rawlins to question once again the viability of Taurus and to redefine his role vis-à-vis the project:

“I was now completely satisfied…that there was not an ice-cream’s chance of it [Taurus] being built in less than another three years. It was then I decided to stop it….”33

For years, Rawlins had defined his job as how to implement change at the exchange without getting too involved with the Taurus project. But finally he was forced by circumstance and irrefutable evidence of repeated failure to admit that his chief mission had to be canceling the Taurus project and containing the damage already done.

Managerial Action.

With the Andersen report in hand, Rawlins decided to kill the project. He began gathering the kind of data he would need to convince the stock exchange board of directors to cancel the project. Rawlins knew that he could not recommend cancellation based on the Andersen report alone. In January 1993, Rawlins hired a senior partner of Coopers & Lybrand to examine the project in more detail, anticipating that Coopers might dispute Andersen’s findings without a thorough investigation of their own. Besides gathering more information, Rawlins believed that it was critical to have Coopers’ opinion of the project before he went to the board:

“I needed them [Coopers & Lybrand] to agree because I knew my board would turn round and say, ‘Coopers have been running this thing. This is Rawlins throwing a wobbly. He’s lost his bottle.’”34

Phase 3: Search for Alternative Courses of Action

Obtaining Independent Evidence of Problems with the Existing Course of Action.

Coopers & Lybrand completed its investigation in early February 1993. Its report was fairly consistent with the earlier assessment performed by Andersen: Taurus was at least 15 months away from completion, and another year beyond that would be required for testing.

Identifying and Legitimizing a New Course of Action.

By this point, Rawlins had already decided to cancel the project. But he knew that he could not recommend canceling the project without offering a viable alternative that the board and the securities industry would accept. He needed to search for other alternatives in order to buttress his argument to the board that Taurus was unnecessary and that the stock exchange could get most of its benefits by implementing a less complex system. For Rawlins, the search for alternatives was a necessary step before he could go to the board and recommend that Taurus be canceled:

“I had my people looking at what the position would be if we stopped it dead, because if we stop it, we stop it…. I didn’t want anyone panicking. I wanted it all trussed, tied up, and done.”35

Managerial Action.

In exploring his decision to cancel the project, Rawlins concluded that the legacy system known as Talisman (implemented in 1979) that handled the task of clearance was indeed adequate for getting the job done, given the paper-based processing that was currently being used for share settlement. At the same time, Rawlins began paving the way for the creation of a much simpler system—an alternative to Taurus that would eventually be known as Crest.

Phase 4: Implementing an Exit Strategy

Preparing Key Stakeholders.

By February 1993, Rawlins had gathered enough data to begin implementing his strategy to cancel Taurus. During February and early March, Rawlins began “secretly preparing key players including the chairman of the stock exchange, trusted members of the board, leaders of the securities industry, and the Bank of England” for the possibility that Taurus would have to be canceled.36

Managing Impressions.

Rawlins says he knew that it would be difficult for the board to simply cancel the Taurus project after all this time, because it would create the impression that the board itself was responsible for the debacle. He realized the board would need a scapegoat to deflect the inevitable criticism that would be directed its way. Rawlins says an essential element of his cancellation strategy was to offer himself up as that scapegoat: “Don’t worry, I’ll take the rap for this,” Rawlins told the board.37

“I thought the best thing to do was go. Indeed, it was instrumental in my strategy of getting the board to stop it,” stated Rawlins.38

End Result.

During the first week of March, Rawlins sent a three-page confidential memorandum to board members recommending Taurus be canceled. On 11 March 1993 he met with the board and presented his case for canceling the project. During his meetings with board members and other key stakeholders, he emphasized the ambiguity and futility of continuing to fund Taurus:

“I know it [Talisman] is archaic, but it is cheap, cheerful, and it bloody well works. Don’t tell me you want Taurus.”39

“Of course we can carry on if you are prepared to vote the money, but I am telling you the issue is not the money. It is the time. …The only way to go forward now is to say, ‘Stop! Spend not one further penny.’”

“Forget the money. …It is the time. And no guarantees that in 15 months’ time everything would just plug in.”40

In making his case for abandonment, Rawlins underscored the opportunity costs and ambiguity involved in continuing to fund Taurus, contrasting this against the certainty that would be gained by canceling the project. On 11 March 1993, the stock exchange publicly admitted that the Taurus project had been canceled. On the same day, Rawlins resigned.

As the table that follows shows, the four phases of the framework match with the key managerial decisions and events occurring in the Taurus case.

Clearly, the Taurus case fits the framework derived from the DIA case, evidence that the framework can be generalized across a range of projects. Together, the Taurus and DIA cases provide us with seven core strategies for de-escalating commitment to failing projects.

Seven Ways to De-Escalate Commitment to Failing Projects

1. Don’t Ignore Negative Feedback or External Pressure

Executives tend to be biased toward escalation because of both human nature and societal norms.41 Executives need to be aware of this bias toward escalation and pay close attention to negative feedback and external pressure, because these represent warning signs that can aid in problem recognition. It is common for executives to delude themselves into thinking that a project will pull through—that success is just around the corner. It usually takes enthusiasm, effort, and even passion to get projects off the ground and running. The project depends on these responses for vitality. Consequently, the line between an optimistic, “can-do” attitude and overcommitment is very thin and often difficult to discern. In the case of IT projects, problems may remain unknown for long periods of time or, if known, there may be a tendency to discount their severity. Under such circumstances, de-escalation will not occur until the gravity of the problem manifests itself in an unambiguous way or external pressure to reexamine the project can no longer be ignored.

Clearly, executives will more readily recognize problem projects if they are attuned to negative feedback and external pressure. In both the DIA and Taurus cases, the executives involved could have done a much better job of moving more swiftly through the problem recognition phase of our framework. Negative feedback should have been relatively easy to detect in both cases, in part because both experienced significant external pressure. External pressure may be lacking in projects that are internal to an organization and do not involve external parties. In such projects, managers must be proactive in channeling internal feedback in a way that creates sufficient pressure to trigger problem recognition.

As is the case with any complex undertaking, IT projects are typically managed through a number of stages between initiation and completion. At the earliest possible stage, managers need to ask themselves whether any “red flags” such as early warnings about the project and failed tests are serious enough to warrant project termination or significant redirection. By institutionalizing such an early warning system, organizations can save considerable sums of money simply by identifying failing projects while they are still in the early stages of development. Another useful mechanism—often delayed or overlooked—is to hire an external auditor.

2. Hire an External Auditor to Provide a More Objective Assessment

During project escalation, executives often sense that the project is not going well or that things could be bet ter, but they do not have the objective evidence needed to translate their vague feelings into concrete action. The notion of bringing in an external auditor—a fresh set of eyes—to conduct a project assessment is a technique that can promote de-escalation by providing an independent third-party perspective. There are, of course, costs associated with using independent experts, but, as the old adage goes, “If you think an expert is expensive, try hiring an amateur.”

In both the DIA and Taurus cases, hiring an external consultant was instrumental in assessing the severity of the problem and in helping the executives respon sible for these projects to extricate themselves and their organizations from failing courses of action. In the DIA case, the external consultant helped facilitate the search for alternative courses of action by legitimizing the use of a traditional manual baggagehan dling system. In the Taurus case, the external consul tants provided valuable ammunition that Rawlins was later able to use in persuading the board to cancel the project. Very often, a consultant is in a position recommend actions that might otherwise be difficult to voice internally. Consultants can be a powerful way to identify and legitimize alternative courses of action, while at the same time reducing an executive’s exposure to internal politics.

3. Don’t Be Afraid to Withhold Further Funding

In an escalation situation, it seems only natural that executives are inclined to keep pouring more resources into the project. The Taurus case illustrates that it may be more prudent to withhold further funding until more information can be gathered to decide whether to continue the project Rawlins pursued this course in 1992 as negative feedback mounted, even though he was being asked to channel additional resources into the project. This action proved to be a significant move toward withdrawal. By refusing to spend more money for additional staff, Rawlins not only minimized further investments while seeking a way out, he also highlighted the difficulties facing the project His action was also symbolic, because it represented his first serious attempt to assert control over Taurus and began to shape how others viewed it. Rawlins was too removed from Taurus and waited far too long to take action. But when he finally did take control of the project, he moved effectively to cancel it and prevent further harm.

4. Look for Opportunities to Redefine the Problem

Redefining the problem was a central element in both the DIA and Taurus cases. At DIA, the bond repayment schedule for the airport forced decision-makers to confront the costs associated with continuing to pursue the airport-wide automated baggage-handling system. It is unlikely that the city of Denver and Mayor Webb would have considered short-term alternatives if they had not been facing a $1 million per day cost of delay. The DIA case teaches that the visibility of project costs can play an important role in promoting problem redefinition.42

Redefining a problem, however, is seldom easy. It requires creativity and openness to new ideas. New ideas may emerge after intensive and conscious wrestling with a problem,43 but, in general, the key to problem redefinition and creativity is an approach that encourages executives to consider a wide range of solutions.44 To promote problem redefinition, executives should implement project review procedures that encourage creative thinking. By encouraging such thinking, executives can raise alternatives to accomplish the project’s goals. Executives should also work at creating a culture that encourages individuals to openly question whether an IT system solution is the best (or even a viable) approach toward a given problem. In the DIA case, escalation continued until it was recognized that the real problem was getting the airport open and that continued commitment to the IT-based baggage-handling system would only lead to further delays.

5. Manage Impressions

One of the most powerful forces that can promote escalation is the human need to save face. Nobody wants to be associated with a failing course of action. There is a natural tendency to want to continue a failing project in the hope of turning it around and vindicating oneself. As Staw and Ross remind us, “One social determinant of commitment is the desire not to lose face or credibility with others.”45 Executives are more likely to extricate themselves and their organizations from failing courses of action when conditions allow them to manage impressions and save face in the process.46

In the DIA case, Mayor Webb employed several impression-management techniques, making it easier for city officials to reduce their commitment to the automated baggage-handling project and consider an alternative course of action. The consultant’s report made it relatively easy to place the blame for the baggage-handling problems squarely on BAE, allowing Mayor Webb and other city officials involved in the DIA project to save face. Allegations that the failure was caused by BAE’s own faulty management and lack of technical expertise were a recurring theme in public statements by city officials and members of the project management team. Furthermore, Mayor Webb was careful to label the alternative baggage system as a “temporary” fix. The alternative system was never labeled as a replacement per se, but rather as the “future backup system.” By not admitting that this alternative system would become permanent, city officials avoided the embarrassment of admitting that a mistake was made in the original decision to pursue an airport-wide automated baggage-handling system.

In the case of Taurus, Rawlins claims he recognized that the board would be reluctant to cancel the project without a scapegoat. Since he, himself, was not in a position to save face, he took the extraordinary step of offering himself as a scapegoat, allowing the board to save face. Rawlins was perhaps able to do this because he says that he had been planning to leave the Exchange at the end of 1993 anyway. Whether or not one accepts Rawlins’ version of how and why he left the London Stock Exchange, one lesson is eminently clear. Pulling the plug on an expensive failure may require high-level executives to take the blame and leave the organization. De-escalation is made all the more difficult because careers may be at stake. In order to manage impressions, someone may have to take the fall.

6. Prepare Your Stakeholders

The DIA and Taurus cases show quite clearly that the decision to change course is not, in itself, sufficient to bring about the desired change. Large and complex projects often take on a life of their own and involve multiple stakeholders. Just as large ships cannot be suddenly turned around, so it is with large projects. In the case of Taurus, Rawlins spent weeks preparing stakeholders once he had made up his mind that the project would be canceled. This preparation included meeting with the key stakeholders and preparing them for the possibility that the project would have to be canceled. In doing so, he discovered that:

“These were big men…[yet] the plain fact of the matter is that they were terrified. ‘What do you mean we might have to stop this?’…They were fighting to find some reason to carry on.”47

Rawlins would have been unable to implement his exit strategy without proper preparation, including multiple consultants’ reports and a cogent argument for why, after seven years of failure, Taurus was too risky to continue and the exchange could survive with its legacy system until it could launch Crest.

One problem with the implementation of Mayor Webb’s exit strategy was that he failed to prepare key stakeholders. Instead, he proceeded to unilaterally pursue a solution that was favorable to the city of Denver, but viewed as unworkable from the perspective of key stakeholders. Mayor Webb initially made the mistake of thinking that he could dictate the exit strategy and that all the major stakeholders would accept his logic. Predictably, however, United Airlines was not happy with the prospect of abandoning the entire computerized baggage-handling system in favor of a manual one. United, after all, had plowed considerable effort into developing a computerized baggage-handling system that would at least service the concourse where it planned to operate. When United tried to block the city’s exit strategy, Mayor Webb was forced to negotiate with United and BAE to reach a settlement that was acceptable to all major stakeholders. Ultimately, these negotiations led to a decision to fragment the baggage system contract, allowing United to continue working with BAE on a semi-automated system to serve its concourse (a course of action strikingly similar to that which United had initiated originally with BAE). In the end, of course, Mayor Webb was able to extricate himself and the city of Denver from the failing course of action, but the entire process might have been smoother had he recognized the importance of preparing stakeholders.

7. Look for Opportunities to Deinstitutionalize the Project

Patterns of escalation are more difficult to break when projects become institutionalized. Ross and Staw describe deinstitutionalization as removing a project “from the core of the firm, either by moving it physically away from the central location of the company or by emphasizing its peripheral nature.”48 In the DIA case, United’s opposition to the alternative manual baggage-handling system created an opportunity for Mayor Webb and the city to further distance themselves from the project. Under the new agreement, reached by United and BAE, city officials and the DIA project-management team effectively relieved themselves of any responsibility for implementing the automated system. Seen in this light, city officials ceased to consider the automated baggage system as a defining characteristic of the new airport. In doing so, they were able to deinstitutionalize the project, effectively transferring all remaining responsibility for the automated system to a committed third party, United Airlines.

In the case of Taurus, Rawlins was able to deinstitutionalize the project by emphasizing the opportunity cost (time to market), the financial risk, and the fact that legacy and simpler follow-on systems could provide the same benefits. To successfully argue that Taurus was not necessary, Rawlins pointed to the existing system (Talisman) that handled the clearance task and to the prospect of Crest as a simplified settlement system.

Executives must be acutely aware of the risks associated with project escalation and avoid these risks when possible. Having said this, it is unlikely that executives will be able to avoid escalation in all cases. Therefore, it is important that executives have some awareness of the strategies and tactics that can be used to turn troubled projects around (if possible) or to bring them to a stop (if necessary). Our framework illustrates the phases that executives must typically go through in order to extricate themselves and their organizations from failing courses of action. To return to the frog parable, they are the steps that allow an executive to jump out of hot water before being boiled to death.