misq2000v24n03p0417

Montealegre & Keil/De-escalating IT Projects

MIS, ,arterly RESEARCH ARTICLE

DE-ESCALATING INFORMATION TECHNOLOGY

PROJECTS: LESSONS FROM THE DENVER

INTERNATIONAL AIRPORT^

By: Ramiro MontealegreCollege of Business and AdministrationUniversity of Colorado at BoulderCampus Box 419Boulder, Colorado [email protected]

Mark KeilDepartment of Computer Information

SystemsJ. Mack Robinson College of BusinessGeorgia State UniversityP.O. Box 4015Atlanta, Georgia [email protected]

Abstract

Project failure in the information technoiogy areais a costiy problem, and troubled projects are notuncommon. In many cases, these projects seemto take on a life of their own, continuing to absorbvaluable resources, while failing to deliver any realbusiness value. While prior research has shown

that managers can easily become locked into acycle of escalating commitment to a failing courseof action, there has been comparatively littleresearch on de-escalation, or the process ofbreaking such a cycle. Through de-escaiation,troubled projects may be successfully turnedaround or sensibly abandoned. This study seeksto understand the process of de-escalation and toestablish a model for turning around troubledprojects that has both theoretical and practicalsignificance. Through a longitudinal case study ofthe IT-based baggage handling system at DenverInternational Airport (DIA). we gathered qualitativedata on the de-escalation of commitment to afailing course of action, allowing us to inductivelydevelop a model of the de-escalation process asit unfolded at DIA. The model reveals de-escalation as a four-phase process: (1) problemrecognition, (2) re-examination of prior course ofaction, (3) search for alternative course of action,and (4) implementing an exit strategy. For eachphase of the model, we identified key activitiesthat may enable de-escalation to move fon/vard.Implications of this model for both research andpractice are discussed.

Keywords: Information systems (IS) projectmanagement, escalation, de-escalation, IS projectfailure, systems implementation, field study

'Sirkka Jarvenpaa was the accepting senior editor forthis paper.

ISRL Categories: EE,EL0201,EL0202. FD05

EE0101, EE0504.

MIS Quarterly Vol. 24 No. 3, pp. 417-447/September 2000 417

Monteategre & Keil/De-escalating IT Projects

Introduction

Twice the size of Manhattan, the DenverInternational Airport (DIA) at 53 squaremiles was designed to be the USA'slargest airport. By 1992, there was agrowing realization that baggagehandling would be critically important inan airport of this size and that this issuecould not be off-loaded to the airlinesthat would be operating out of DIA.Consequently, commitment began togrow forthe inclusion of an airport-wide,information technology (IT) based bag-gage handling system that could drama-tically improve the efficiency of luggagedelivery. BAE Automated Systems, Inc.,a world leader in the design and imple-mentation of material handling systems,was commissioned by the City of Denverto develop the system. An informationsystem composed of 55 networkedcomputers, 5,000 electric eyes, 400radio frequency receivers, and 56 bar-code scanners was to orchestrate thesafe and timely arrival of every suitcaseand ski bag at DIA. Problems with thebaggage system, however, kept the newairport from opening as originallyscheduled in Qctober 1993. Soon thenational and international media beganto pick up the story, and the DIA cameunder investigation by various federalagencies. By the time the airport openedin late February 1995. it was 16 monthsbehind schedule and close to $2 billionover budget. Additionally. DIA mightnever have opened at all if Mayor Webbhad not found a way for the City ofDenver to abandon its previous commit-ment to build an airport-wide automatedbaggage handling system. When DIAdid eventually open, it did so with twoconcourses served by a manualbaggage system and one concourseserved by a scaled-down semi-auto-mated system.

Although dramatic in terms of its size, complexity,and visibility, the multi-million dollar IT-basedbaggage handling system at DIA is but one of

many such IT project failures that occur each year(Gibbs 1994). Project failure in the IT area is acostly problem, and troubled projects that seem totake on a life of their own are not uncommon (Kailand Mann 1997). Escalation literature has beensuggested as a promising theoretical base forunderstanding how managers become entrappedin a failing course of action on certain IT projects(Keil 1995; Newman and Saberwal 1996).

While escalation of commitment is a generalphenomenon that can occur with any type ofproject, the literature (e.g., Abdel-Hamid 1988;Brooks 1975; DeMarco 1982; Zmud 1980)suggests that IT projects may be particularlysusceptible to this problem. The intangible natureof software makes it difficult to obtain accurateestimates of the proportion of work completed,which may promote escalation of commitment bygiving a false perception that successful com-pletion of the project is near. To add to thedifficulty of measuring progress, IT projects aredynamic and tend to have volatile requirements(Abdel-Hamid and Madnick 1991; Zmud 1980)that cause project scope to change frequently.Almost certainly, projects that exhibit suchvolatility are especially difficult to manage andcontrol. For these reasons, it is not surprising thatescalation occurs with high frequency among ITprojects. Keil and Mann report that 30% to 40% ofIT projects exhibit some degree of escalation.

This paper takes a broad view of the process ofde-escalation, which we define to include projectredirection as well as abandonment. De-escala-tion occurs whenever there is reduced commit-ment to a failing course of action. While such areduction in commitment may manifest itself asproject abandonment, it may also manifest itselfas a significant movement away from someprevious course of action (i.e., redirection). Whileredirection cannot guarantee that the project willbe successful, it does signal a reduction incommitment in response to a failing course ofaction. Thus, we consider redirection (which caninclude a radical rescoping or redefining of theproject) to be a form of de-escalation.

White an analysis of what went wrong at DIA (i.e.,the escalation of commitment to build an airport-wide computerized baggage handling system)

418 MIS Quarterly Vol. 24 No. 3/September 2000

Montealegre & Keil/De~escalating IT Projects

would be interesting in itself, this is not our aimhere. The primary purpose of this study was togain a better understanding of the de-escalationprocess, whereby commitment to the airport-widecomputerized baggage handling system wasreduced, allowing the airport to be opened usingan alternative baggage handling system. Thereare at least two important reasons for studying theDIA case. First, the computerized baggagehandling system at DIA was one of the largest ITfailures of the decade. For this reason alone, thecase is worth studying to determine if there areany de-escalation lessons that can be learned andapplied to other cases. Second, since we knowthat managers can {and will continue to) becomeoverly committed in some instances, it is importantto identify strategies and tactics that can be usedto break the escalation cycle, allowing suchprojects to be redirected if possible or abandonedif necessary.

In this paper, we use the DIA case as the basis fordeveloping a process model of de-escalation. Tomotivate the need for such a model and to providesome additional context for our work, we beginwith a review of the existing literature on de-escalation. Next, we describe the researchapproach used to study the DIA case to induc-tively develop a process model of de-escalation.We then present the de-escalation process of thecomputerized baggage-handling system at DIAorganized around the phases that were observedand incorporated in our model. In the followingsection, we further develop the model bydiscussing the key de-escaiation triggeringactivities that occurred within each phase. Here,we draw upon our analysis and interpretation ofthe case data, as well as prior literature, to explorethe key activities of the de-escalation process.We conclude with a discussion of the implicationsof our model for both research and practice,followed by a brief summary.

Background

While prior research has shown that managerscan easily become locked into a cycle ofescalating commitment to a failing course ofaction (see, for example, Brockner 1992), therehas been comparatively little research on de-

escalation, or the process of breaking such acycle. As a starting point for our research, weundertook a review of this literature aimed atidentifying triggering activities or conditions thatmight be useful in building a process model of de-escalation. Research on de-escalation of com-mitment is relatively limited. In fact, we identifiedonly about a dozen studies that are relevant to thede-escalation of IT projects, which yield factorsthat could potentially be used to explain thisphenomenon. Two of these are case studies (Keil1995; Ross and Staw 1993), one is a field survey(Keil and Robey 1999), and the others are alllaboratory experiments (most frequently con-ducted with student subjects). Table 1 sum-marizes the de-escalation triggering activities orconditions we identified from this review andprovides references to relevant studies.

The results of our review revealed that there hasbeen comparatively little research on de-escaiation, and that which does exist has notgenerally been grounded in actual organizationalsettings.^ The review also underscored the factthat prior research has followed a factor-oriented.or variance theory, approach in seeking tounderstand de-escalation.^ Process theories,which complement variance theories, are lesscommonly found in the literature and have yet tobe developed for explaining de-escalation.Process theories focus on sequences of activitiesin order to explain how and why particularoutcomes evolve overtime (Abbott 1983: Markusand Robey 1988; Mohr 1982; Newman and Robey1992; Shawand Jarvenpaa 1997). Ideally, a goodprocess theory should go beyond simply namingthe phases that occur in a process. It should alsoinclude some notion of the triggering activities thatdrive the movement from one phase to another(Mohr 1982).

there are a few other published studies on de-escalation, they tend to manipulate treatments (e.g..self-awareness training) that have little connection to anIT context (e.g., Nathanson et al. 1982). We havetherefore excluded these studies from Table 1.

V variance theory deals with variables and seeks toexplain Ihe variance in some dependent variable (Mohr1982).

MIS Quarterly Vol. 24 No 3/September 2000 419


1 Table 1. Triggering Activities and Conditions That Can Promote De-escalation

TriggeringActivity orCondition

Changes in topmanagement orprojectchampionship

Publicly statedlimits

Availability ofalternativeinvestments

Setting minimumtarget levels

Making negativeoutcomes lessthreatening

Regularevaluation ofprojects

Separation ofresponsibility forinitiating andevaluatingprojects

Appeals tostakeholders

Externalpressure on theorganization

Description of Why the Triggering Activity orCondition Can Promote De-escalation

For a variety of psychological, social, and organizationalreasons, top management may sustain its commitment toprojects that are deeply troubled. Changes in topmanagement or in project championship may allow a freshappraisal of the project and a chance to reconsider howresources should be allocated.

A way to promote de-escalation is to state limits beyondwhich a project will cease to receive support, especially tostate such limits publicly.

Project escalation carries potentially high opportunity costs;the inability to apply allocated funds to other projects thatmay enjoy higher return on investment. Several laboratoryexperiments provide evidence that the availability ofalternative investments or consideration of alternative usesof the funds supporting a project (i.e., opportunity costs)can promote de-escalation.

One explanation for escalation is a lack of clarity aboutwhat constitutes success and failure. When minimum targetlevels are established as threshold criteria for success,troubled projects are more likely to be de-escalated.

Reducing the threat posed by negative outcomes has beenfound to be a useful de-escalation strategy. By not im-posing severe punishment for failures, it is argued, organi-zations can encourage de-escalation.

Many escalating projects proceed with little monitoring orreview. Where regular project reviews and evaluations areconducted, de-escalation of commitment to failing projectsis likely to be encouraged.

Escalation studies have demonstrated that escalationtendencies are heightened under conditions of highpersona! responsibility. To combat this tendency, respon-sibility for initiating projects should be separated fromresponsibility for evaluating projects.

Large projects that extend outside the organization'sboundaries and involve external constituencies may appearto present obstacles to de-escalation. However, de-escala-tion studies have shown that external parties can play asignificant role in the de-escalation process by helping tomake the economics of withdrawal more favorable.

External events, perhaps unrelated to a particular troubledproject, may also trigger a general reassessment ofresource allocation and allow de-escaiation to proceed.

Relevant Studies

Keil 1995; RossandStaw 1993

Brockner et al.1979; Heath 1995;Keil and Robey1999; SimonsonandStaw 1992

Keil etal. 1995;McCain 1986;Northcraft andNeale 1986

Keii and Robey1999; SimonsonandStaw 1992

Keil and Robey1999; Simonsonand Staw 1992

Drummond 1995;Keil and Robey1999

Barton etal. 1989;Keil and Robey1999

Ross and Staw1993

Keil 1995; RossandStaw 1993



Table 1. Continued

TriggeringActivity orCondition

Unambiguouslynegativefeedback

Visibility ofproject costs

Efforts to de-institutionalizethe project

Description of Why the Triggering Activity orCondition Can Promote De-escalation

IT projects may be particularly prone to escalation becausesoftware is invisible and intangible. Problems associatedwith such projects may remain unknown for long periods oftime, or there may be a tendency to discount their severity.De-escalation will not occur until the gravity of the problemmanifests itself unambiguously.

In laboratory experiments researchers have found that de-escalation was more likely when information about costswas more salient. Field settings may hide or distortknowledge of problems and associated costs.

De-escalation can be facilitated when an organization de-institutionalizes a project, removing it from the core of thefirm, either by moving it physically away from the centrallocation of the company or by emphasizing its peripheralnature.

Relevant Studies

Garland etal. 1990

Brockner et al.1979

Ross and Staw1993

Table 2: Formal Interviews

Institution

City of Denver

DIA project

DIA consultants

BAE, Inc.

Airlines

TOTAL

Number of peopleinterviewed three times

2

2

-

2

3

9

Number of peopleInterviewed two times

4

3

1

2

2

13

Number of peopleinterviewed one time

3

6

5

3

4

21

While a handful of temporal models have beenproposed to explain how escalation of commit-ment builds up over time (see, for example. Staw1997; Staw and Ross 1987), our review did notidentify a single process model of de-escalation.*

^While Staw and Ross (1987) articulate a "withdrawalprototype" that depicts de-escalation as a process, theirconceptualization of de-escalation is somewhat differentfrom ours. They envision de-escalation as a processthat is driven by the receipt of increasingly negativefeedback, "making it economically clear that persistence

Indeed, the prevailing wisdom seems to be thatde-escalation occurs almost instantaneously uponreceipt of feedback that is unambiguously nega-tive and that it takes the form of project aban-donment. Based on an analysis of the events that

is more costly than withdrawal' (p. 69). The phases ofttieir process are not named and there is no clear senseof how or why the process unfolds in the mannerdepicted, other Ihan the fact that feedback becomesincreasingly negative.

MIS Quarterly Vol. 24 No. 3/September 2000 421


transpired at DIA. we present a grounded processmodel of the phenomenon that reveals de-escalation to be a more complex and gradualprocess than previously described. Our modelclearly shows that an escalated project is notsimply abandoned or immediately de-escalatedupon receipt of unambiguously negative informa-tion. Instead, our findings suggest that a projectgoes through several distinct phases along theroad to de-escalation and that there are keytriggering activities associated with each of thesephases. This Inductively derived model serves asour central contribution.

Research Approach

Consistent with the focus of our research, wefollowed an in-depth case research approach.Case research is particularly appropriate forexploratory research of this type. This approachallowed us to focus on studying de-escalation in anatural setting. Moreover, case research affordedus an opportunity to engage in theory-building inan area in which there has been relatively littleprior research and theory (Benbasat et al, 1987).

From a site selection standpoint, the computerizedbaggage handling system at DIA proved to be anideal case to study. The tremendous mediacoverage of this particular IT failure, the extensivedocumentation that was publicly available, and thefact that key actors could be located forinterviewing all argued in favor of pursuing thisparticular case site. Moreover, since one of theresearchers lived in close proximity to the casesite, we were in a position to conduct alongitudinal case study at relatively low cost.

In following a theory-building approach, we tried tobegin "as close as possible to the ideal of notheory under consideration and no hypotheses totest" (Eisenhardt 1989, p. 536). In accordancewith the approach advocated by Eisenhardt, weformulated the research problem and reviewed theexisting literature on de-escalation in order to"specify some potentially important variables." butwe avoided "thinking about specific relationshipsbetween variables and theories as much aspossible, especially at the outset of the process."

Throughout the study, we followed a strategy ofassigning specific roles to the two researchersinvolved. All of the interviews were conducted bythe first author, while the second author stayedout of the field altogether and played the role ofdevil's advocate (Eisenhardt 1989). This strategyenabled the second author to avoid becomingoverly immersed in case details and to "bring adifferent and possibly more objective eye to theevidence" (Eisenhardt 1989, p. 538).

To begin our data gathering, we first consultedpublished reports on DIA and the baggagesystem. We found more than 100 articlespublished in national and local newspapers aswell as numerous pamphlets, memoranda, anddocuments in the public domain. We negotiatedresearch access with the City of Denver in August1994; over the next 18 months we conducted fieldresearch (on-site observations, interviews, andfurther documentation reviews). A total of 74interviews were conducted with 43 employees ofDIA, the City of Denver, the airlines, BAE (thebaggage system contractor), and severalconsulting companies that played a significant rolein the project, as summarized in Table 2. Thus.the research involved a longitudinal study of thede-escalation period (1994-1995).^ The longitu-dinal focus allowed us to study the key activitiesand decisions that occurred during the course ofthe project, while the collection of multiple types ofdata from different sources provided triangulationand increased the reliability of the study. Theappendix provides additional information on ourmethodology and discusses some of itslimitations.

The Computerized BaggageHandling System at DIA

This section presents background informationabout DIA and the computerized baggagehandling system. It highlights the process thatMayor Webb followed to extricate himself and the

During the course of our research, we also undertookan historical reconstruction of the escalation period(1989-1994). This was useful because it gave us adeeper understanding of the project context prior to de-escalation.

422 MIS Quarterly Vol 24 No. 3/September 2000


City of Denver from a failing course of action andidentifies the key decisions that punctuated thede-escalation process. First, the antecedentcondition is introduced as a high level ofcommitment to a previously chosen course ofaction that has failed to produce the desiredresults (i.e., a condition of escalation). Then, thecase facts are presented in four phases: problemrecognition, re-examination of prior course ofaction, search for alternative course of action, andimplementing an exit strategy. Finally, the conse-quence or outcome of the de-escalation processis discussed.

Antecedent Condition

In the early 1980s, plans began to take shape forconstruction of DIA. The new airport was to befinanced through a combination of revenue bonds,federal grants, and a sizable investment by theCity of Denver.̂ Located 25 miles from downtownDenver, DIA was designed to grow withoutcompromising efficiency and to maintain a steadyair traffic flow in all weather conditions. Thedesign included five parallel 12,000-foot runwayson which as many as 1,750 planes could take offand land daily. The initial ground-breaking fortheproject occurred in late 1989 and the original plancalled for completion by fall 1993.' The initialproject design did not incorporate an airport-widebaggage handling system; the airport plannersexpected the individual airlines to build their ownsystems as they did in most other Americanairports (Rifkin 1994). In 1991. United Airlines(one of the airlines to commit early to leasinggates at DIA) did exactly that, commissioning BAEAutomated Systems, Inc., to develop an auto-mated baggage handling system for itsB Concourse.

^ h e revenue bonds assumed the "Date of BeneficialOccupancy' (DBO) to be January 1, 1994. with bondrepayments to begin on that date.

'The ultimate buildout. projected for the year 2020. was»o include up to 12 full-sen/ice runways, more than 200gates, and a capacity of 110 million passengersannually.

By 1992. two years into the construction of thenew airport and with BAE Automated Systems,Inc., already working on United's baggage system,the project's top managers began to recognize thepotential benefits of an airport-wide IT-basedbaggage handling system. As a result, airportplanners and consultants began to developspecifications for an airport-wide automatedbaggage handling system and the city sent out arequestfor a proposal. While 16 companies (bothdomestic and foreign) were contacted, only threeresponded. A consulting firm recommendedagainst all three submitted designs on thegrounds that the configurations would not meetthe airport's needs. A member of the DIA man-agement team commented, "All had the sameresponse: 'there was not enough time to buildsuch a system.'" BAE Automated Systems, Inc.,was one of the 13 companies contacted thatelected not to bid on the airport-wide system.Although BAE's Telecar system, with its laserbarcode readers and conveyor belts, had beeninstalled in other airports, the DIA request forproposal represented a system of much greatersize and complexity than anything BAE had builtbefore.

The consultant's report. BAE's failure to bid on thesystem, and the several analyses coming fromother neutral observers—including the technicaladvisers to the Franz Josef Strauss Airport inMunich—represent what now appear to beobvious warning signs. Nevertheless, the City ofDenver proceeded with its plan to build an airport-wide automated baggage system.

Since BAE had already begun constmcting anautomated baggage handling system to serveUnited and had an established reputation as asuperior baggage system builder, the DIA projectmanagement team approached the companyagain about building an airport-wide automatedbaggage handling system. This time, BAEresponded with a proposal to develop the "mostcomplex baggage handling system ever built."The proposed system was to include 3,100independent "telecars" to route and deliverluggage among the counters, gates, and claimareas of 20 different airlines. A total of 55personal computers would be networked to oneanother and to 5,000 optical detectors, 400 radioreceivers, and 56 bar-code scanners in a central


Montealegre & Keil/De~escalating IT Projects

control system. The system would move apassenger's bag from any injection point to anydestination in the airport in less than 15 minutesand would process more than 1,000 bags perminute—two to three times faster than a conven-tional conveyor belt. Faster baggage handlingwould translate into increased ground timeefficiency, thus reducing enplanement turnaroundtime for hub operations and improving services topassengers (Bouton 1993). In April 1992, afterviewing a prototype of the proposed system,Denver officials awarded BAE a $175.6 millioncontract to build the automated baggage systemfor the entire airport.

First construction problems, then difficulties withthe baggage system kept the new airport fromopening as originally scheduled in October 1993.The national and international media began topick up the story and the DIA project came underintense investigation by various federal agencies.

Phase 1: Problem Recognition

In late April 1994. as BAE was preparing the firsttest of the system, the City of Denver invitedreporters to observe the test: 7,000 bags were tobe moved to Continental's Concourse A andUnited's Concourse B. So many problems werediscovered that testing had to be halted-Reporters saw piles of discarded clothes andother personal items lying beneath the telecar'stracks. After the test. Mayor Webb delayed theairport's opening for an indefinite period of time."Clearly, the automated baggage system nowunderway at DIA is not yet at a level that meetsthe requirements of the city, the airlines, or thetraveling public," the mayor stated. "There is onlyone thing worse than not opening DIA...[and] thatis opening the airport and then having to shut itdown because the [baggage] system doesn'twork." Initially, Mayor Webb reconfirmed his com-mitment to the computerized baggage handlingsystem by stating that that DIA would not openuntil "milestones are met and I have seen thebaggage system operate successfully" (O'Driscoll1994c).

After the failed tests in April 1994. however, cityofficials began to question whether the designer

and builder of the baggage system could get thesystem up and running. "The growing frustrationin city people is due to the lack of a sense ofsteady progress being made," said one memberofthe project management team. Airline executiveswere also taking a pessimistic view at that time."We used to be more naive." said an airlineexecutive. "We would think, 'well, of course theseguys know what they are doing and somehow,miraculously Di Fonso [who headed up BAE] andhis merry men will pull this thing out." Now, beliefin miracles is waning."

Shortly after Webb's decision to delay the openingof the airport until the automated baggagehandling system was fully operational, externalpressure on the City of Denver began to mount asit faced investigations from multiple agencieswithin the federal government. A federal grandjury was conducting an investigation concerningthe use of government funds for DIA. At the sametime, the Securities and Exchange Commission(SEC) was investigating the sale of $3.2 billion inmunicipal bonds used to finance DIA and theadequacy of the city's disclosure of informationwith respect to the automated baggage systemand related delays in opening the airport. By con-gressional request, the Government AccountingOffice (GAO) was investigating DIA constructioncost growth (Flynn 1994b). The Federal AviationAdministration (FAA) had also initiated an investi-gation for fraud.

A letter sent by an FAA commission to a Denverofficial in May 1994 stated.

Rather than continuing to be part of astampede mentality, the brakes need tobe put on the funding stream becausethe American taxpayers are fed up with...continuing the game even when thereare red penalty flags all over the field.

The letter also called for a meeting with Denverofficials to discuss problems with the project andto consider totally revamping the airport'smanagement, "including placing the new airportunder...an independent regional authority." Inaddition, DIA vendors were expressing interest infiling a class-action lawsuit against the citybecause of repeated delays in the new airport's



opening. One vendor told the Rocky MountainNews, "the delays have cost concessionairesabout $75 million in lost sales" (Flynn 1994a).

Decision 1: Hire outside consultants. In May1994, under grovi'ing pressures from a variety ofstakeholders. Mayor Webb announced that hewas hiring the German firm Logplan to helpassess the state of the automated baggagesystem. Logplan's report was "the firstindependent, outside opinion related to [BAEbaggage] system design," according to the DenverPublic Works director.

Phase 2: Reexamination of PriorCourse of Action

Once the problems began to be recognized.Mayor Webb and the City of Denver re-examinedfor the first time their previous course of action.To evaluate whether the airport opening delaysand added cost would materially affect theairport's ability to meet operating costs and debtservices when it opened, Hickling Corporation, aconsulting firm specializing in risk assessment forairport investment projects, was hired {GAO1994). According to this consulting firm, keepingDIA closed was costing the city $33.3 million amonth, or a little more than $1 million a day. Mostof the money, about $21 million, was needed topay the interest on bonds that the city had issuedto build the airport. As the Denver manager ofrevenue explained, "opening the airport as fast aspossible and ending $33 million a month in delaycosts are what the investors care about."Moreover, since the airport was partially fundedthrough federal grants, not only bondholders butalso federal agencies like the FAA wantedassurances that the airport project could be putback on track.

To cope with the added costs. Mayor Webb andthe City of Denver began to consider twoalternative financing plans. The first involveddipping into emergency bond or capital improve-ment reserve funds, while the second involvedadding the delay cost to a $180 million bond issuethat Denver had already planned for the summerof 1994. The bond rating agencies and analystswere watching closely to see how Denver was

planning to finance the delay. On May 2 1994,Moody's dropped its ratings of the bonds onegrade to Baa, just one step above no-investmentstatus (Svaldi 1994).

Ultimately, financial considerations led to a betterunderstanding of the magnitude of the problem.With this came a growing realization that it wastime to begin thinking about other options thatwould prevent further delays and allow the airportto open as soon as possible. Political consi-derations also played a role here in that MayorWebb was expected to run for re-election thefollowing year. Although he expected "to bejudged on more than just DIA" (O'Driscoll 1994b),after delaying the opening of the airport four times,he was aware that his reputation was at stake. Ashe told the Rocky Mountain News, "Politically, howcan you go out and tell people that you're going todelay the project by a year" (Flynn 1995)-

Decision 2: Establish a task force. MayorWebb created a high-level task force charged withfinding a short-term alternative to the BAE systemthat would allow the airport to open as soon aspossible- Led by Mayor Webb's chief of staff, theteam included the chairman of the Denver MetroChamber of Commerce, a consultant from theDenver engineering firm O'Brien-Kreitzber,Denver's manager of revenue, the assistant cityattorney, the director of public works, and a DIAproject engineer.

Phase 3: Search for AlternativeCourses of Action

The task force immediately began the explorationof alternative courses of action. As the DenverBusiness Journal reported.

City officials and consultants decided tochannel their energies toward devisingPlan B—an interim baggage handlingsystem—that could be in place for up totwo years, while engineers continue towork out the bugs in the permanentsystem. (Steers 1994)

The move represented a significant point of depar-ture in the management of the project. For the



first time since the automated baggage handlingsystem had been conceived, the city acknow-ledged the existence of possible alternativecourses of action and expressed a willingness toexplore their feasibility. This was corroborated bythe director of public works;

We believe that the success of theairport rests in efficient operations, not inthe completion of the automated sys-tem....lf BAE fixes [the baggagesystem's] problems while the alternativesystem is being built, that would begreat. DIA could open with a combina-tion of the two systems....We'd tike to getthe automated system working, but...itmay not be possible to do that in a shortenough time.

In July 1994, as the task force began to consideralternative courses of action, Logplan beganevaluating the automated baggage system. To doso, Logplan isolated a loop of track that containedevery feature of the automated baggage system,intending to run it for an extended period to testthe reliability of the telecars, but jams on theconveyor belts and collisions between carscaused the test to be halted. The system did notrun long enough to determine whether there wasa basic design flaw or to analyze where theproblems were. By August 1994. Logplan issuedan 11 page report that characterized BAE's sys-tem as "highly advanced" and "theoretically"capable of living up to its promised "capacities.services, and performances." but acknowledgedthat software and mechanical problems "make itmost improbable to achieve a stable and reliableoperation." Logplan recommended constructing aconventional tug-and-cart backup baggage sys-tem that could be built in less than five monthsand opening DIA with it and whatever parts of theBAE system could be ready (Booth and O'Driscoll1994).

Decision 3: Authorize construction of analternative system. On August 4 1994. MayorWebb announced a plan to develop "a temporary,low-tech alternative system for the DenverInternationalAirport's high-tech baggage system."He also declared that it was "financially irres-ponsible" to continue delaying DIA's debut until

the automated system was operational. Webbconcluded the announcement by asserting that"the alternative baggage system's role as futurebackup after BAE's system is running will boostDIA from a Grade A airport to an A-plus airport"(O'Driscoll 1994c). Just one week after MayorWebb announced the plan to develop thealternative baggage system, the Denver CityCouncil approved the hiring of the Michigan-basedRapistan Demag firm to design, engineer, andinstall a conventional baggage handling system.

At the same time. Mayor Webb notified BAE of a$12,000-a-day penalty for not finishing thebaggage system by DIA's original October 29.1993, completion date. Webb also demandedthat BAE pay for the $50 million conventional tug-and-cart baggage system. Di Fonso, reviewingMayor Webb's letter, summed up the situation asfollows:

We have gotten to the point with the citythat we are literally not talking to eachother. Consultants recommended abackup baggage system, and the minutethat the decision was made, the city hadto defend it. We are left out in limbo.

Phase 4: Implementingan Exit Strategy

Immediately after Mayor Webb's decision toauthorize the construction of an alternativemanual baggage handling system. United andContinental Airlines as well as BAE geared up forprotracted negotiations and possible litigation.Continental maintained that the Mayor's actionsconstituted a breach of contract for which it couldsue the city or choose to cancel its lease of DIAgates. United urged the city to bring in mediators"because of the deteriorating relationship withBAE."

United Airlines objected to the manual system,saying it would not accommodate the airline'sheavy schedule. A United Airlines official told aDenver Post reporter that, "Webb's choice wouldgridlock the DIA baggage movement disastrously."United feared that a traditional system would hurt



its huge Denver hub—with 284 flights a day^byslowing luggage transfers and lengthening thetime needed to send bags from ticket counters toairline gates. As United's senior vice president forcustomer service put it, "the alternative-systemplan will take us back 30 years" (Mark 1994). Shesuggested that the temporary system woulddouble connecting times between flights.

Since the time that United signed to use DIA as itssecond-largest hub airport, it had understood theneed for an automated baggage system to turnaircraft around quickly and it was committed toimplementing such a system. That was whyUnited had commissioned BAE to develop anautomated system for its B Concourse evenbefore the DIA planners had decided on includingan airport-wide baggage system. Then, when theCity of Denver made the decision to provide sucha system, and the BAE-United Airlines contractwas frozen. United included in its contract withDenver a clause requiring delivery of a functionalbaggage system. Therefore, it objected to theproposal to develop a manual system.

United's reaction led Mayor Webb, representingthe City of Denver, to appeal to organizationalconstituencies. Specifically, a negotiation processwas initiated that reopened the possibility ofmodifying, instead of withdrawing, the plan toopen DIA with an operational automated baggagesystem. After three straight days of intense,closed-door talks among United, city officials, andBAE, an agreement was finally reached. OnAugust 31. 1994. the Rocky Mountain Newsreported that, in an effort to avoid legal action, theCity of Denver had proposed a "stand still"agreement whereby major parties (the city. UnitedAirlines, and BAE) would waive certain previousagreements and rights until the new airport wasopened and operational. "Of course," the reporteremphasized, "the legal departments of theseparties are going to be busy until the end of thiscentury with this case" (Amole 1994).

After the negotiations took place. Mayor Webbwas quoted as saying:

It is my hope that United, as our largesttenant, would clasp my hand as I offeredit today, and send engineers to help...I

believe, in that spirit, that they will sendtheir technical people here, not theirlawyers. (Leib and Mark 1994)

United replied with a plan to modify the automatedsystem for transporting departing passengers'baggage to the planes while relying on traditionaltugs and carts to deliver most of the baggage forarriving passengers.

According to George Dougherty, who served asDenver Airport director until June 1992:

[Throughout the project. United] appliedsignificant pressure and had previouslymade contributions to [Mayor Webb's]political campaign and sponsored fund-raising events- He was not in a positionto make a decision counter to theirwishes. (Dempsey et al. 1997, p. 405).

Under the new agreement that was reached withUnited and BAE, city officials and the DIA projectmanagement team effectively relieved themselvesof any responsibility for the implementation of theautomated baggage system, which became thesole responsibility of United Airlines and BAE.

Decision 4: Restructure the baggage systemcontract. On September 1, 1994, the City ofDenver, United Airlines, and BAE, followingintensive talks, struck a deal to break the baggagesystem contract and implement two separatesystems. As a result of these negotiations, theoriginal contract was divided into two parts:United was left managing the implementation of asimplified version of BAE's automated system toserve its Concourse B, and the City of Denver wasleft managing the implementation of a traditionalbaggage system to serve other airlines operatingon Concourses A and C. Under the new arrange-ment, airlines other than United would not haveaccess to the automated system unless BAEinstalled new telecar track and United grantedrights for access.

Consequence: The End of the Crisis

When the airport finally opened in late February1995, it was 16 months behind schedule and



close to $2 billion over budget. By this time, theairport-wide computerized baggage handlingsystem had effectively been abandoned, leavingtwo concourses served by a manual baggagesystem and one concourse served by a scaled-down semi-automated system.

As a consequence of the fourth decision, twoseparate baggage handling strategies emerged: asemi-automated approach to serve United'sconcourse and a manual approach for the otherconcourses. The idea of a single automatedbaggage system to service the entire airport wasno longer on the table. Instead, the City of Denvermanaged the implementation of an alternativebaggage system designed around conveyor beltsand propane-powered tugs and carts to serveConcourses A and C. In order to accommodatethe alternative system, warning lights wereinstalled in the baggage tunnels to guide the tugsand other airport modifications were made toaddress security and baggage sorting Issues.

Meanwhile, United Airlines assumed full respon-sibility for managing the implementation of asimplified automated baggage system to serve itsConcourse B. It used, at reduced speed, twoloops of track that served Concourse C and itisolated its operations from the BAE equipmentthat had been installed to service Concourse A.United's goal was to salvage as much as possiblefrom the work that BAE had completed and toconstruct a simpler automated baggage systemthat would be used only for handling baggageassociated with United's outbound passengers.This goal represented a significant reduction in thescope and complexity of the project.

The relatively smooth opening of the airport meantthat the immediate crisis concerning the auto-mated baggage system was over. Along with theairport's opening came the possibility of politicalrelief for Mayor Webb, as he was preparing hisrace for re-election that spring. The airportopened, however, with five runways and 88 gates(20 fewer than the old Stapleton airport that DIAwas designed to replace), at a cost of $5.2 billion(close to $2 billion over budget), and with an$18.80 average per-passenger airline fee (thenation's second highest). Additionally, significantsums in legal fees had to be spent to counter thelawsuits and related investigations, which led thecity auditor to remark:

I didn't realize when everyone talkedabout DIA was going to mean fullemployment that what that would meanwas full employment for lawyers. I neverdreamed that when the airport wascompleted that we would exchangeconstruction workers for lawyers. (Leib1995).

Discussion: Revisiting theDIA Findings in Light ofDe-escaiation Literature

Based on the DIA case study and the findings thatemerged, we developed a process model of de-escalation, as depicted in Figure 1. Given thatthis model was inductively derived from the DIAcase study data, it is appropriate to ask whetherthe existing literature on de-escalation corro-borates the model and in what ways our modelenriches our present understanding of de-escalation. To begin addressing these issues, wemust revisit the case data in light of existingliterature on de-escalation.

De-escalation as anEmergent Process

As noted earlier, most of the prior work on de-escalation has had a variance theory orientationand has been conducted in controlled laboratorysettings. Much of this work has suggested thatde-escalation occurs almost instantly when certainconditions, such as unambiguously negativefeedback, are present (see, for example. Garlandet al. 1990). Although one might expect de-escalation to occur instantly upon receipt ofunambiguously negative information, the DIA casesuggests it is difficult to change direction suddenlybecause of the build-up of commitment thatoccurs during the escalation process. Ourresearch on DIA's computerized baggagehandling system reveals that de-escalation is agradual process rather than a sudden event.Thus, while there may be a turning point at whichescalation can be retrospectively seen as havinggiven way to de-escalation, there is no single pointin time at which de-escalation magically occurs.Rather, it is a process that unfolds gradually over



isio

nD

ec

u

truc

tR

esth

e

e

syst

ract

con

1/3

(*iuGnafCb

o

' P

has

Si

• C

lenti

"a.E

ch fo

' Sea

111

u

O

• ;

Oi

e

nativ

u

, alte

eo•-C_E

1 ex

air

ition

cMO

St

1 st

rise

of

1 C

OU

I

_2'^9

CO

1 ac

ti.

o

coun

1 ac

tio

ngto

ali

ua.a.<

•a

n tif

yi

V

.£

larif

U

1 1

ing]

N

ecog

n

U•a"3j =u

litim

l

Sr

3

agni

B

egflt

ivi

,Q

lati

itter

n

EES

ep

r•e

dbac

•as•H

' in

srs

e 01

OU

ac

UB

•3

espo

m

'

ect

5*f i

so=

E

oble

Q .

ISs

1 ex

ter

(̂

u

nagin

!

ress

ur

a

\

c

iress

K

E

co

%«a

,3L.O

3

Ce•swak.ca

B

e

ac1 .

fB

EVtn

sion

2:

Q

blis

h

CB

u

e

forc

esb

ort

•a E

na

tive

a

sion

1

u

a X

e

ulta

nt

o

s th

e

at

mat

ed

o3m

age

a CB

E

•3eo

U

M/S Quarterly Vol. 24 No. 3/September 2000 429


1•1•

g th

e

• 2

cisi

on

s A

H ̂

r••I•111•••BlHEl

Ei_

mes

ou

Out

tion

(0

to D

e-es

c

__

o

CA0

' * ';>

<O)_c"C

Trig

gei

ilatio

nD

e-es

ca

>•

tf]«tf)CO

COCO

3mag

w

Q

'ista

n

CO

ona

tho

riz

3<

<*>

COjS

I

De

cict

ion. L

ogpl

an

(D

"oaCA

3O

) ne

w c

1 izin

g!

d l

egit

in*

cO)

c

Iden

t

to

Q.

sign

, en

• •

o•o

ire'

0)

ern

ativ

"to

ion

of

an

* ;

>tru

cco

ns

em

s "m

ake

obi

Q .

lica

l

CD.C

ind

mec

wa

re £

that

sofi

"S0

s

CD

Q

x:

CDCD

0r -

inst

all

t

• n

r,

am

00

._

CD

O l

ugus

t 4,

1

<

EOl

syst

iopera

tion."

ble

CD

0

CDn i

a st

abit

chie

ve

o

COXIo

Ein

it m

o!

>•—.

CDC

0

0CT)

1 bagga

CO^'

entio

coo

o

plan

t

CO

nounce

d

to

XI

Web

ug-a

nd-c

art

lalti

L_,o

1oo

J clin

g a

const

nim

ended

Logpl

13

oo

B"to>.[A

low

-tec

> .

"tem

pora

l

en

lop

1d

eve

s th

an

fiv

e

to

Bc

luilt

±j

could

1m

th

at

ge s

yste

CDO)O)CO

-Q

back

i

<

•

gi

_C0

a

syst

em

fo

0

nativ

alte

rt

f -

montl

o

3S o

bje

ctlin

<e

dA

irin

it

C

jge

sys

te r

m

bagi

tech

-

lai

syst

e

cto

E

it's

repo

rt t

oIta

nco

n;3 b

use

ds.

We

i)r

e5S

ion

cO)

Man

a

.»-

2

wou

ld

rng

it

"ra(O

squ

are

ly o

n

E_0

jro

b

OJ

leh

an

dl

laggag

e fo

r the

t

E

0

£

pla

ce

0

late

tl

o

om

m

CD

rt

baggage

CD

TD

cu

man

ua3d

th

eposi

tion*

X I

" 0

BA

E.

he

a'

CO

lin

e'

. ^

to

a rr

ass

ment

I0

1

lus

avo

ism

pora

r^

CO

E

syst

e

3dul

e.

•gCO

take

.m

is

CD

de s

ysti

port

-wi

at t

he a

ir

£

tti

"F

ofa

di

0O>

e b

agga

CO

CD

i0)

Lire

th

u3

4.

Res

tn

co'w

Dec

ire

par

e

the

Q .

o

p

0

c0Q

old

ers

sta

ke

h

o

_c"(5

Ap

pe

t r

^^a.

CO0

5tra

tegi

c '

cCO

on

trac

syst

em

1

bag

cth

e m

anual

idA

irlin

ijr U

nite

x:1

0

sta

ke

O lc"c0E

—

COCD

Intte

d w

- '

irged:

0

.-\

J C

ity c

r 1,

19

94,

0

cu

Sept

August

30,

cO

isio

r

o0T3

iider

its

reco

n s

y ha

d t

oci

t

0

* -

E"

syst

e

• • ^

LLIcz

0_cr

gin

g

tl

(0

CO

-

I l l

an

dB

A

m

litedA

iriin

iD

en\.

i th

ree

-da

y

O l

LU<

ed,

an

d3r

, U

nit

of D

enve

b0

1994

,

>^

CO

CD

ion

of

COU8U

J8-

0

3ak

th

X)

deal

toCD

Stru

cF m

odify

ing.

o

issi

b

u

0

en

ed

that

reop

iatio

nst

h

o0^

o

roun

c

o

yste

m

CO

gage

CD

O

act

int

_^c

syst

em

ctage

bagg

opera

tional

CO

x;

Aw

i

Q

c

n to

ope

the p

lai

jra

win

g.

"o"O

inst

ee

cCD

OD

'eC

on

0</)

• o

tom

ate

CD

: a

sem

i

to

part

two

ste

m.

jgage

sy

C?

• o

Btor—

auto

n

0>c0Q

City

0

to

Jnite

d'

:o

serv

e

E

systt

CD

he

imp

"^

lage

d

i-CD

E

1 sys

tem

CD

(-

and a

mai

a)

ours

'OU

OO

negotia

tion

x:

"1_!1—

o

:he

pr(

I*c_o'S3* ;

1A

De-

in

0

a bagga'

o

itatio

n

t.;0E

to

3r c

onco

ui

"o0

fort

hId

th

e D

IA

I D

) ffic

i.

•-/• & •

ged.

C

t em

ergre

em

en

CD

Cto

(0in

pro

ce

0

0 s

er'

tem

> ,w

mse

lves

of

the

leve

0

fect

iveli

a^

E

em

ent

te

O)tocCO

E

pro

jet

Aa

nd

C

CO

cours

iauto

mate

d0J=•"-•

"ocoCO

Die

men

iIh

e

im|

Ility

fo

r 1

%c

Q.to

an

y r

insi

biti

ty

of

Q .CO0

ole

to

0

a m

e

th;h

bee

3m,

whi

(

"co>>CO

too>in

bagg

;

Oi 0N CCO * "

0 O

£ >«

— 0)

uct

ion

com

f3C

t.

(jj ^ Oc t TO Q.

I l l

and

BAE

CO<D

•lin

-a

Uni

tei

M/S Quarter/y Vo/. 24 No. 3/September 2000 431

Montealegre & Keil/De-escalatir)g IT Projects

time, leading to a reduction in commitment to apreviously chosen course of action, and theenactment of an alternative plan of action.

While some of the actions that were key inreducing commitment at DIA were deliberate andintended, others evolved as a response tounanticipated events. This does not mean,however, that actions to de-escalate a situationoccur in a random fashion; there does appear tobe a patterned sequence of phases and actionsthat occur along the road to de-escalation.Indeed, the DIA case revealed a pattern of phasesto the de-escalation process in which contex-tualized actions and decisions made by DIAmanagement proceeded over time with no pre-determined endpoint. What was observed in theDIA case is characteristic of an emergent process,the outcome of which is unpredictable.

As theory suggests, the de-escalation at DIAappeared to be promoted by a wide variety ofdecisions and actions that reduced the com-mitment to a failing course of action, makingchanges in project direction or withdrawal morelikely. The general form of the model derived hererepresents de-escalation as a sequence of fourdistinct phases, each of which involves certaintriggering activities that are associated withcontext-specific decisions that foster further de-escalation. The antecedent for de-escalation is, ofcourse, escalation of commitment to some courseof action. The model depicts de-escalation as adynamic process that is simultaneously con-strained by actions in the antecedent episode, yetcapable of constructing new patterns of com-mitment to alternative courses of action.Triggering activities are the basic theoreticalconstructs of the model and are measured byobservations of incidents. A phase consists ofone or more triggering activities that stand apartfrom the others. The key decisions discussedearlier mark the end of one phase and thebeginning of another. Like other process models,this one describes the phases associated with acomplex phenomenon (in this case, de-escalationof IT projects), but makes no attempt to provideprecise predictions concerning the outcome ortime scale over which de-escalation will occur(Mohr 1982).

The categories and concepts that we developedfrom the case data and which form the basis forour model are shown in Table 3, which sum-marizes the case data presented earlier andprovides a roadmap for the discussion of key de-escalation triggering activities that occurred ineach phase.

Key Triggering Activities inPhase 1: Probiem Recognition

Phase 1 of the modal involves problem recog-nition. De-escalation requires a clear under-standing that something is wrong with the presentcourse of action. Nothing of consequence canhappen until decision makers in positions ofresponsibility and authority recognize that there isindeed a problem. Often, what can appear to out-siders as an obvious case for withdrawal may notoutweigh the accumulated commitment of thoseinside the organization, particularly those whohave played a role in championing the project.Given the psychological, social, and organi-zational forces that can promote and reinforceescalation behavior, the literature suggests thatde-escalation is more likely to occur in thepresence of unambiguously negative feedback{Garland et a!. 1990) and when there is externalpressure on the organization {Keil 1995; Ross andStaw 1993). In the DIA case, these two conditionswere both present and seemed to play asignificant role in this phase, as we discuss below.

Recognizing negative feedback. IT projectsmay be particularly prone to escalation due to theinvisible and intangible nature of software com-ponents {Abdel-Hamid and Madnick 1991).Problems associated with such projects mayremain unknown for long periods of time or theremay be a tendency to discount their severity.Under such circumstances, de-escalation will notoccur until the gravity of the problem manifestsitself unambiguously. In a laboratory experiment.Garland etal. {1990) found that subjects chose tode-escalate commitment when they receivedunambiguously negative feedback about projectprogress and the perceived costs of proceedingoutweighed the benefits.


Montealegre & Keil/De-escalatmg IT Projects

At DIA, the presence of unambiguously negativefeedback marked a key turning point, leading thecity to engage a consultant to evaluate theautomated baggage system Negative feedbackon the automated baggage system was receivedthroughout the project—even at its outset, the cityhad been warned by another municipality, as wellas the contractor, that the deadline was notrealistic for a project of such complexity. AlthoughBAE had significant experience implementing thistechnology in smaller scale projects, it had neverimplemented a system at the level of complexitythat was required for DIA. This fact, however, wasnever questioned by DIA planners. The aviationdirector, for example, told a luncheon forum at theDenver Press Club, "No one [in the DIAmanagement team] realized the complexity of thetechnology as it relates to this baggage system"(O'Driscoll 1994a). A project manager for UnitedAirlines recalled: "BAE told them from thebeginning that they were going to need at leastone more year to get the system up and running,but no one wanted to hear that." The City ofDenver was getting the same story from thetechnical advisers to the Franz Josef StraussAirport in Munich, but apparently chose not tolisten (Rifkin 1994). The Munich airport had anautomated baggage system far less complex thanDIA's. Nevertheless, Munich's technical advisorshad spent two years testing the system and thesystem had been running 24 hours a day for sixmonths before the airport opened.

It is easy to argue (in 20/20 hindsight) that thesesignals, coupled with other warning signs, such asthe constant changes in specifications, shouldhave received some attention. As is typical ofescalation cases, however, the negative feedbackwas either ignored or downplayed for a significantperiod of time. In fact, it was not until the baggagehandling system test in April 1994 that unam-biguously negative feedback became available,casting serious doubt on the wisdom of pursuingthe project further.

Responding to external pressures. Externalevents, perhaps unrelated to a particular troubledproject, may also trigger a general reassessmentof resource allocation and allow de-escalation toproceed. In a case study of a multi-million dollarsoftware project that involved more than a decade

of development, Keil (1995) found that thedecision to "pull the plug" was driven, in part, byexternal pressure. In this particular case, asudden downturn in the industry created afinancial crisis for the company, forcing managersto reevaluate priorities. Of course, externalpressure can take many other forms as well. Inthe Shoreham nuclear power plant case describedby Ross and Staw (1993), the growing popularopposition to nuclear power contributed to de-escalation. In that case, the accident at ThreeMile Island on March 28, 1979, triggered anantinuclear demonstration directed againstShoreham on June 4, 1979, in which more than15,000 people participated. While Ross and Stawdo not explicitly include external pressure in theirmodel of de-escalation, it appears clear that de-escalation of commitment would not haveoccurred in the Shoreham case without theincreased pressure resulting from local and stateresistance to the project. At DIA, outside pres-sures forced a closer examination of the course ofaction and appear to have been instrumental inprompting the city to conduct an independentexamination of the computerized baggagehandling system and its prospects for success.

Key Triggering Activities in Phase 2:Reexamination of Prior Courseof Action

Phase 2 involves reexamining the previouslychosen course of action. In the DIA case, thisreexamination involved two key de-escalationtriggering activities: clarifying the magnitude ofthe problem with the previously chosen course ofaction and fundamentally redefining the problem.During this phase in the process model, managersbegin to question the wisdom of the previouslychosen course of action, but their commitmenthas not dropped so precipitously as to dictateimmediate withdrawal. Generally, what holdsdecision makers to the course of action is a lackof understanding of the true magnitude of theproblem. During this phase, managers begin toanalyze the extent of the problems associated withthe current course of action and reframe theproblem they are seeking to address.



Clarifying the magnitude of the problem. Whencosts are more visible or salient, they maypromote de-escalation. In a laboratory experi-ment, Brockner et al. (1979} showed that subjectsassigned to a condition in which continuationoccurred unless a decision to terminate was made(self-sustaining condition) were more likely toescalate than subjects assigned to a condition inwhich continuation required an active decision(self-terminating condition). Their interpretationwas that forcing subjects into an active decisionmade the costs of continuation more salient, thusreducing escalation behavior. These findingswere judged to be consistent with an earlier studyby Rubin and Brockner (1975) in which escalationwas found to be more likely when informationabout costs was less salient. Unfortunately, fieldsettings may hide or distort knowledge ofproblems and associated costs. Thus, anadditional consideration is the visibility of projectcosts (Brockner et al. 1979).

At DIA, what highlighted the cost of escalationwas the mounting cost of servicing the debt. Itappears that the bond repayment schedule forceddecision makers to confront the costs associatedwith a decision to escalate. It is unlikely that theCity of Denver and Mayor Webb would even havelooked at short-term alternatives if they had notbeen facing a million-dollar-per-day cost ofdelay—a cost that would not have appeared if theautomated baggage system had performed asexpected, allowing the airport to open onschedule.

Redefining the problem. While the notion ofredefining the problem has not been discussed inprevious studies of de-escalation, the concept ofproblem redefinition, or reframing, is a well-knownaspect ofprospect theory {Kahneman and Tversky1984). Framing effects occur "when individualsalter their choice among decision alternatives inresponse to changes in the frame of reference ofthe alternatives" (Diamond and Lerch 1992, p.1050)- Various authors (e.g., Davis and Bobko1986; Garland and Newport 1991; Whyte 1986)have invoked prospect theory and the effects ofproblem framing to explain escalation of com-mitment. Thus, it is not unreasonable to concludethat reframing, or redefining, the problem could bea useful tactic for promoting de-escalation.

Redefining a problem, however, is seldom easy,for it requires creativity and openness to newideas. New ideas may emerge after intensiveconscious wrestling with a problem (Arnheim1954, Weisberg 1986). The key to problem rede-finition, and creativity in general, is encouragingmanagers to consider a wide range of solutionpaths (Couger 1996).

In the DIA case, the mounting cost of servicingdebt led to a fundamental redefinition of theproblem, allowing de-escalation to proceedfurther. A critical reexamination of the priorcourse of action was suddenly made easier whenit was recognized that the real problem wasgetting the airport open and that continuedcommitment to the IT-based baggage handlingsystem would lead only to further delays. Beforethis point, the problem had been defined as "howto complete the automated baggage system asoriginally planned," whereas the new goal became"do whatever it takes to make the airportoperational so that it can be opened as soon aspossible." That is, the focus at DIA shifted fromtrying to repair the baggage system to finding analternative that would allow the airport to open.

A key decision that occurred during this phasewas the creation of a task force to find a short-term alternative that would allow the airport toopen. It is interesting to note that no member ofthe baggage system task force assigned by MayorWebb had been involved in the initial decision toconstruct the airport-wide automated baggagesystem, so task force members' reputations werenot at stake in the decision to de-escalatecommitment. The literature suggests that separa-tion of responsibility for initial and subsequentdecisions can be an important factor in promotingde-escalation (Barton et al. 1989). Thus, It ispossible that Webb's creation of such a task forcemade it easier to accept a reframing of theproblem and a search for alternative solutions.

Key Triggering Activities in Phase 3:Searching for Aiternative Courseof Action

With an increased understanding of the problemsassociated with the previously chosen course of

434 MIS Quarterly Vol. 24 No 3/September 2000


action, managers begin to search for an alter-native course of action. The decision to embarkon a new course of action can be a bitter pill toswallow. Not only does it require the decisionmaker to engage in face-saving behavior, but italso requires convincing other stakeholders (whomay also have grown committed to the previouslychosen course of action) of the need to changecourse. For the DIA case, this phase of the de-escalation process involved identifying andlegitimizing a r)ew course of action, along withmanaging impressions so as to allow Mayor Webband the City of Denver to embrace the new courseof action without losing face.

Identifying and legitimizing a new course ofaction. In the DIA case, the costs of delaying theairport opening prompted a redefinition of theproblem and a search for alternative courses ofaction. In the process, an outside consultant(Logplan) was engaged to identify and legitimizean alternative course of action. Given that MayorWebb had already reframed the problem asfinding a means to open the airport as soon aspossible, this independent third-party assessmentmade it easier for city officials to further reducetheir commitment to the automated baggagehandling system.

From the literature, we know that the salience ofalternatives can play a role in promoting de-escalation of commitment. Laboratory experi-ments by Keii et al. {1995), McCain (1986), andNorthcraft and Neale {1986) have shown that thepresence of an alternative can greatly reduce thetendency toward escalation. These studies sug-gest that providing subjects with an alternativecourse of action encourages them to consider theopportunity costs associated with a decision toescalate, thereby raising the cost salience.Interestingly, in the case of DIA, cost salienceoccurred well before any alternative courses ofaction were seriously considered.

Managing impressions. Impression manage-ment theory posits that individuals aim tomaximize social rewards and minimize punish-ments by influencing the perceptions that othersform about them (Giacalone and Rosenfeld 1989,1991; Leary 1995; Leary and Kowalski 1990;Schlenker 1980), The impression management

literature provides numerous techniques that canbe used to help managers save face in the midstof a project fiasco (lacovou and Dexter 1996).While impression management tactics have notsurfaced in previous studies of de-escalation, theidea that individuals may pursue a failing courseof action to avoid admitting their errors to others isa theme that is discussed in the escalationliterature. As Staw and Ross (1987, p. 55) remindus, "One social determinant of commitment is thedesire not to lose face or credibility with others."In theory, this suggests that decision makers aremore likely to de-escalate their commitment to afailing course of action under conditions in whichit is possible to save face. In a laboratoryexperiment, Leatherwood and Conlon (1987)suggest that diffusability of blame can have asignificant impact on escalation behavior.Specifically, they found that when subjects weregiven an opportunity to blame problems (in thiscase, a labor strike) on a third party (in this case,the union), their tendency to escalate was lowerthan when blame could not be so easily diffused.

In the DIA case, the consultant's report allowedMayor Webb to place the blame for the baggagehandling problems squarely on the contractor,BAE, even though it was the city that had initiatedand pursued the project so vigorously. Blamingthe failure on BAE's own faulty management andlack of technical expertise was a recurring themein public statements by city officials and membersof the project management team. By using thisand other impression management techniques.Mayor Webb was able to save face in dealing withthe media and other stakeholders.

In public statements. Mayor Webb was alwayscareful to label the alternative baggage system asa "temporary" fix. The alternative system wasnever labeled as a replacement per se, but ratheras the "future backup system." This, too, was animpression management tactic because themanual baggage system implementation requiredmodifications to physical spaces and equipmentthat would make it impossible to ever integrate itwith the BAE's system, according to a Unitedofficial. By never admitting (at least not publicly)that the alternative system would likely becomepermanent, city officials avoided admitting that amistake might have been made in the original


Moritealegre & Keil/De-escalating IT Projects

decision to pursue an airport-wide automatedbaggage system.

The behavior observed in the DIA case isconsistent with iacovou and Dexter's investigationon patterns of communication behavior by ITmanagers to reduce, redress, or avoid damage totheir credibility from perceived responsibility for ITproject failures. While we have no definitive dataon this point, we speculate that saving facethrough the use of impression managementtactics may be easier in outsourced, as opposedto in-house, development projects. In the DIAcase, for example, it appeared that the outsourcer(in this case, BAE) served as a convenientscapegoat, facilitating the de-escalation of theproject. Such scapegoats may be harder to find inin-house development projects.

Key Triggering Activities in Phase 4:implementing an Exit Strategy

Phase 4 involves implementing an exit strategy.In the DIA case, this involved appealing tostakeholders to reach a mutually agreeableimplementation strategy and de-institutionalizingthe project. This phase begins with operationalplans that emerge as a way to resolve a perceivedcrisis, but subsequently provide a way to retreatfrom the failing course of action. On the surface,implementing the new course of action appears tosimply be a matter of articulating and thenexecuting a new project plan. However, in pro-jects with external constituencies, implementingthe alternative course of action is anything butsimple. External stakeholders may have a vestedinterest in blocking implementation of the chosenexit strategy. Likewise, once a project is struc-turally embedded in an organization, it may beextremely difficult to change the previously chosencourse of action.

Appealing to stakeholders. Large projects thatextend outside the organization's boundaries andinvolve external constituencies can presentgreater obstacles to de-escalation. In a casestudy of the Shoreham nuclear power plant. Rossand Staw (1993) examined the decision by LongIsland Lighting Company (LILCO) to abandon a23-year-old project that cost an estimated $5

billion. Their findings indicated that externalparties (e.g., proponents of nuclear power withinthe federal government, representatives of thenuclear power industry, and the state of NewYork) played a significant role in the de-escalationprocess. Specifically, Ross and Staw suggest thatLILCO was able to extricate itself from this failingcourse of action, in part, by appealing to externalconstituencies in an attempt to make theeconomics of withdrawal more favorable.

At DIA, external constituencies also had apowerful influence on the de-escalation process.United Airlines played an important role inattempting to prevent the City of Denver fromabandoning the automated baggage handlingsystem. This action on the part of United wasconsistent with Ross and Staw's (1993, p. 725)hypothesis that "when there is not readyreplacement for the services or products of anorganization, external parties...will attempt toprevent the organization's withdrawal." Ross andStaw (p. 726) go on to suggest that if "the conse-quences of persistence in a losing course ofaction are dire enough, there is room for theorganization to negotiate with external consti-tuencies," which is exactly what happened in theDIA case.

De-institutionalizing the project. Patterns ofescalation are believed to be more difficult tobreak when projects become institutionalized. Inthe Shoreham nuclear power plant case, forexample, Ross and Staw(1993)observed that theproject was inextricably linked to LILCO"s strategicplan for power generation, which called forbuilding not one but several nuclear power plantson Long Island. Escalation theorists have argued(see, for example, Staw and Ross 1987) that de-escalation can be facilitated

when an organization de-institutionalizesa project, removing it from the core of thefirm either by moving it physically awayfrom the central location of the companyor by emphasizing its peripheral nature .(Ross and Staw 1993, pp. 727-728)

In the DIA case, city officials ceased to considerthe automated baggage system as a definingcharacteristic of the new airport, tn doing so, they



were able to de-institutionalize the project,effectively transferring all remaining responsibilityforthe automated baggage system to a committedthird party, namely United Airlines. In effect,United's opposition to the aiternative manualbaggage handling system created an opportunityfor Mayor Webb and the city to further distancethemselves from the project.

Implications for Research ^ ^ H

The de-escalation process model developed herehas important implications for both research andpractice. For researchers, this study is significantin that it represents one of the first in-depth casestudies of de-escaiation. While there are ahandful of other case studies involving projectsthat have escalated (e.g., Keii 1995; Newman andSabhenwal 1996; Ross and Staw 1986, 1993),previous studies have tended to focus primarily onescalation rather than de-escalation processes.While there have been about a dozen or sostudies of de-escalation, they have tended tofollow a variance theory approach toward under-standing this domain- The result has been that anumber of factors are now believed to be causallyrelated to de-escalation, but there is no overallmodel of how some of these factors fit together toinfluence the overall process. This study comple-ments the existing variance research stream byshowing how certain triggering activities help topromote the process of de-escalation. As corro-boration for our findings, we note that the priorliterature on triggering activities and conditionsassociated with de-escalation is largely consistentwith what we observed In the case of DIA. Ourcontribution is in the development of a groundedmodel that adds a process perspective, allowingus to tie together a disparate set of factors into amore coherent framework that can serve as thebasis for further investigation.

While the de-escalation model presented here isgrounded in the processes that unfolded at DIA,we believe that aspects of this model willgeneralize to other cases of de-escalation. Thedecisions that we documented are obviously casespecific, but the phases and activities that wereobserved may generalize to other cases of de-

escalation. Further de-escalation studies areclearly needed, however, in order to test theapplicability of the model in other contexts. It maybe the case that the de-escaiation process unfoldsdifferently in different circumstances, or that de-escalation is more difficult to achieve in certaintypes of projects (e.g., large projects with highlevels of investment). Many natural settingscontain a balance of forces that are neither simplenor unidirectional. Such situations producebehavior that is very unpredictable and can lead tocomplex patterns involving multiple cycles ofescalation and de-escalation. We have provideda few of the most likely or feasible actions that caneither enhance de-escalation tendencies orreduce preexisting forces for commitment. As ourunderstanding of de-escalation grows, we may beable to provide a greater number of de-escalationtactics as well as more knowledge about when(i.e., what phases in the de-escalation cycle)specific tactics will be most effective. Both the ITproject risk literature as well as the outsourcingliterature may offer guidance in refining the modelpresented here.

Implications for Practice

By providing a better understanding of thesequence of actions/decisions associated with de-escalation, this study provides managers withuseful insights on redirecting troubled projects sothat they can be salvaged, sensibly abandoned, orsuccessfully completed. For practitioners, the DIAcase underscores the need for managers to beaware of the risks associated with projectescalation and to avoid these risks wherepossible. Having said this, it is unlikely thatmanagers will be able to avoid escalation in allcases. Hence, it is important that managers havesome awareness of strategies and tactics that canbe used to bring troubled projects back on track.The phases depicted in our process modelprovide the basis for a set of normative sug-gestions that managers could follow to promotede-escaiation. These are discussed below andsummarized in Table 4.

Although one might expect individual andorganizations to flee from such a losing situation.



Table 4. Suggested De-escalation Strategies and Tactics for Practitioners

De-escalationPhase

Phase 1.Problemrecognition

Phase 2.Reexamination ofprior course ofaction

Phase 3.Search foralternativecourse of action

Phase 4.Implementing anexit strategy

Normative Suggestions

• Be aware of existing biases in the interpretationof project feedback.

• Engage the services of an outside consultant toevaluate a project whenever it is suspected thata project may be in trouble.

• Get close to the project.

• Form a task force to conduct a full-blown reviewof the project and the viability of the previouslychosen course of action.

• Examine the root cause of the business problem(for which the IT project was the proposedsolution) so that an alternative means ofaddressing the problem can be identified.

• Legitimize the alternative course of action.

• Engage in a consensus building process withthe various internal and external constituenciesof the project.

• Make direct appeals to internal and externalconstituencies in order to negotiate andimplement an exit strategy with their help, ifpossible.

Pitfalls to Avoid

• Ignoring or downplaying badnews.

• Discouraging those who try toreport the bad news.

• Relying on filtered viewpoints.

• Intertwining the project with thefuture of the organization.

• Fixating on the original problemdefinition or the original pro-posed solution path.

• Viewing the original problemthrough technology-centriclenses.

• Surrendering to the influence ofinternal and external consti-tuencies, instead of carefullymanaging them.

• Assuming that a rational pre-sentation of a new course ofaction by itself will promptothers to follow.

prior escalation research has shown that counter-vailing forces tend to build up overtime, making itmore difficult to withdraw than would be expectedif only economic results were considered. As wenoted here, the process of de-escalation Is agradual one in which the forces for commitmentare progressively reduced.

This study suggests that actions that tend tohasten problem recognition tend to be mostinfluential at the early phase of the de-escalation.To promote problem recognition, managersshould be aware of their existing bias toward inter-preting information. It is common for managers to

delude themselves into thinking that a project willpull through—that success is around the corner.This can cause managers to ignore or downplay"bad news," a phenomenon that Keil and Robey(1999) call the "deaf effect." Managers inauthoritative positions must learn to be morereceptive to bad news and they must exhibit awillingness to take corrective action. Many timesthey are not and turn a deaf ear to signs oftrouble. To further aid in problem recognition.managers could engage the services of an outsideconsultant to evaluate a project whenever theysuspect that a project may be in trouble.Managers should not initiate projects and then



leave it up to the IT department or outsouroer tomonitor the project. Managers who want torecognize problems must get close to the projectand avoid the temptation of relying on the viewfrom the executive suite.

Once a problem has been identified, the challengeis to ascertain the extent of the problem and toreexamine the viability of the previously chosencourse of action in light of this new information.Here, the manager should not hesitate to conducta full-blown review of the project and should avoidperceiving the project as intertwined with thefuture of the organization. Forming an in-housetask force to examine the problem and to beginformulating solutions will go a long way towardcontaining the damage.

In the search for altemative solutions, themanager must try to reframe the problem in a waythat unfreezes commitment to the failing course ofaction, rather than fixating on the original problemdefinition or the original proposed solution path.The root cause of the business problem (for whichthe IT project was the proposed solution) must beexamined so that alternative means of addressingthe problem can be identified. It may be that thebusiness problem can be addressed in an entirelydifferent way. Reoonceptualizing the problemspace in this manner requires thinking outside thebox. Managers will often have a tendency to thinkof technological solutions when the problem maybe solved by other means. Finally, it should beremembered that legitimizing a new course ofaction may be facilitated if it has an outside stampof approval from an independent third party.

In the final phase of de-escalation, once analternative course of action has been selected,managers need to marshal support from internaland external constituencies. Managers cannotsimply assume that by declaring a new course ofaction and presenting it in a rational way, allinterested parties will necessarily want to follow.Given that people have almost an uncanny abilityto bias facts in the direction of previously acceptedbeliefs and preferences, it is possible for variousconstituencies in the IT project environment to tryto prevent an organization from de-escalating.Forces controlled by internal and externalconstituencies, especially those substantially

involved in the escalation episode, can turn thedecision to move away from the present course ofaction into a political battle. Managers should notsurrender to the influence of stakeholders, butcarefully manage them. To help the variousstakeholders overcome their commitment to thepresent course of action, managers should buildconsensus toward the alternative course of action.They should begin by asking the question: "Whowill be disenfranchised or likely to exhibitresistance if I attempt to implement the proposedexit strategy?" Direct appeals to internal andexternal constituencies may be needed tonegotiate and implement an exit strategy that allparties will find acceptable.

Summary and Conclusions ^ H

Given that escalation is a common and costlyprobiem among IT projects {Johnson 1995; Keiland Mann 1997), there can be no doubt about thevalue of understanding how managers can de-escalate their commitment to failing courses ofaction. While there have been about a dozen orso studies of de-escalation, they have tended tofollow a variance theory approach toward under-standing this phenomenon. This study representsa contribution to research in that it articulates, forthe first time, a process model that complementsthe existing variance research stream by showinghow certain triggering activities can help promotethe process of de-escalation.

In contrast to much of the existing literature, thede-escalation that occurred at DIA was neithersudden, nor in direct response to unambiguouslynegative feedback (although such feedbackunquestionably played an important role at theoutset of the process). The DiA case quite clearlyshows that de-escalation is not a one act playstaged by inefficient project managers whobelatedly realize that they are pursuing a failingcourse of action. Rather, it is a drama in whichmanagers struggle to demolish one view of realityand substitute another {Drummond 1996). In thisstruggle, there are no predefined scripts andchoreographed moves; instead, actions anddecisions emerge as the situation unfolds. Thisstudy has shown that de-escalation is a complex,emergent process.



In the DIA case, de-escalation was a gradualprocess in which solutions emerged as managersbegan to understand the magnitude of theproblem and to enact changes in problemdefinition. This was not the end of the story, as analternative solution path had to be identified and asignificant effort was then required to shift theorganization and its various constituencies to anew course of action. The model derived fromthis case suggests that de-escalation is a processconsisting of four phases and that there is atemporal ordering of these phases. Moreover, themodel suggests that there are certain triggeringactivities associated with these phases and thatthese also exhibit a temporal pattern. Actions thathelp to increase awareness about the problem(such as recognizing negative feedback andresponding to external pressures) seem tocontribute the most in the initial phase of a de-escalation process. Actions that help prompt anexamination of the previously chosen course ofaction and the identification of alternative coursesof action (such as clarifying the magnitude of theproblem, redefining the problem, identifying andlegitimizing alternative courses of action, andmanaging impressions) seem to contribute themost during the middle phases. Actions thatenable the redirection or withdrawal to take place(such as appealing to project constituencies andde-institutionalizing the project) seem to contributethe most in the final phase of the de-escalationprocess.

The study also contributes to practice by providingnormative suggestions to managers concerningtactics that may prove useful during the variousphases of the de-escalation process. Furtherresearch into the process model described hereholds the promise of providing even moremeaningful guidance to managers who seek toturn around troubled projects. In this light, the DIAcase study and the de-escalation model derivedhere represent a first step toward a betterunderstanding of how managers can cope withand finally extricate themselves from a failingcourse of action. Further work is needed in orderto understand more fully the dynamics of de-escalation and the extent to which the findingsobserved in the DIA case can be generalized.Thus, while this study represents an importantstep toward understanding de-escalation, addi-

tional research is needed to understand both howorganizations are drawn into losing courses ofaction and, perhaps even more importantly, howthey may be able to extricate themselves fromthese predicaments.

Acknowledgements

We are indebted to the employees of the City ofDenver, BAE, other contractors who worked onthe Denver International Airport, and the airlinesfor their willingness to discuss the circumstancessurrounding the computerized baggage handlingsystem. We would like to acknowledge thesupport of the J. Mack Robinson College ofBusiness at Georgia State University for providinga summer research grant to pursue this project.We would also like to thank the Senior Editor,Associate Editor, the three anonymous reviewersat the MIS Quarterly, and Jeff Smith for theirconstructive comments and feedback on thismanuscript. An earlier version of this paperreceived the "1998 Best Paper" Award of theOrganizational Communication and InformationSystems (OCIS) Division of the Academy ofManagement, and a shortened version waspublished in the Academy's Best PapersProceedings.

References

Abbott, A. "Sequences of Social Events; Con-cepts and Methods for the Analysis of Order inSocial Processes," Historical Methods (16:4),1983, pp. 129-147.

Abdel-Hamid, T. K. "Understanding the '90%Syndrome' in Software Project Management: ASimulation-Based Case Study," Journal ofSystems and Software (8:4), 1988, pp. 319-330.

Abdel-Hamid, T. K., and Madnick, S. E. SoftwareProject Dynamics: An Integrated Approach.Prenticie Hall, Englewood Cliffs, NJ, 1991.

Amole, G. "Don't Blame Rat for Deserting DIA,"Rocky Mountain News, August 31, 1994, p.A40.

Arnheim, R. Art and Visual Perception: ThePsychology of the Creative Eye. University ofCalifornia Press, Berkeley, CA, 1954.



Barton, S. L., Duchon, D., and Dunegan, K, J. "AnEmpirical Test of Staw and Ross's Prescriptionsfor Management of Escalation of CommitmentBehavior," Decision Sciences (20), 1989. pp.532-544.

Benbasat, I., Goldstein, D, K.. and Mead, M. "TheCase Research Strategy in Studies of Infor-mation Systems," MIS Quarterly {11;3), 1987.pp, 369-386,

Booth, M., and O'DriscotI, P. "DIA Pushes BagPlan: United Support Sought." Denver Post,August 3, 1994, p. 1,

Bouton, J. "State-of-the-Art Baggage System forDenver," Airport Forum, February 1993.

Brockner. J. "The Escalation of Commitment toa Failing Course of Action: Toward TheoreticalProgress," Academy of Management Review{17:1), January 1992, pp. 39-61,

Brockner, J., Shaw, M. C. and Rubin, J. Z,"Factors Affecting Withdrawal from anEscalating Conflict: Quitting Before It's TooLate," Journal of Experimental Social Psycho-logy {^5), 1979, pp. 492-503,

Brooks, F. P. The Mythical Man-Month: Essaysof Software Engineering, Addison-Wesley.Reading, MA, 1975.

Campbell, D. T. "'Degrees of Freedom' and theCase Study," Comparative Political Science (8),1975, pp. 178-193.

Couger, J. D. Creativity and Innovation ininformation Systems Organizations, Boyd &Fraser, Danvers, MA, 1996.

Davis, M., and Bokko, P. "Contextual Effects onEscalation Processes in Public Sector DecisionMaking," Organizational Behavior and HumanDecision Processes {37:1), February 1986, pp.121-138.

DeMarco. T. Controlling Software Projects,Yourdon Press. New York. 1982.

Dempsey, P. S., Goetz, A. R., and Szyliowicz. J.S. Denver international Airport: LessonsLearned, McGraw-Hill, New York, 1997.

Diamond, L,, and Lerch, F. J. "Fading Frames:Data Presentation and Framing Effects,"Decision Sciences {23:5), September/October1992, pp. 1050-1071.

Drummond, H, "De-escalation in DecisionMaking: A Case of a Disastrous Partnership,"Journal of Management Studies (32:3). 1995.pp. 265-281.

Drummond, H. Escalation in Decision-Making:The Tragedy of Taurus, Oxford UniversityPress, Oxford, UK, 1996.

Eisenhardt, K. "Building Theories from CaseStudy Research." Academy of ManagementReWew{14:4), 1989, pp. 532-550,

Elsbach, K. D,, and Sutton, R, I. "AcquiringOrganizational Legitimacy Through IllegitimateActions: A Marriage of Institutional andImpression Management Theories,''Acac:/em>'ofManagement Journal (35:4), December 1992,pp. 699-738.

Flynn. K. "Slow Bag System Bugs AirlineConcourse C Carriers Say Makeshift SystemProhibits Competition," Rocky Mountain News,September 14, 1994a, p. 6A.

Flynn, K. "Webb Told to Keep DIA Delay Secret."Rocky Mountain News, October 23, 1994b, p.4A.

Flynn, K, "Airport Proves Too Much for Webb."Rocky Mountain News, February 23.1995.

GAO. "New Denver Airport: Impact of theDelayed Baggage System," GAO Report,October 14, 1994.

Garland, H., and Newport. S. "Effects of Absoluteand Relative Sunk Costs on the Decision toEscalate Commitment to an Ongoing Project,"Organizational Behavior and Human DecisionProcesses {48). 1991. pp. 55-69.

Garland, H., Sandefur, C. A., and Rogers, A. C."De-escalation of Commitment in Oil Explora-tion: When Sunk Costs and Negative FeedbackCoincide," Joumal of Applied Psychology (75:6).1990, pp. 721-727.

Giacalone, R. A,, and Rosenfeld, P. ImpressionManagement in the Organization, LawrenceEribaum Associates, Hillsdale, NJ, 1989.

Giacalone, R. A., and Rosenfeid, P. AppliedImpression Management. Sage, Newbury Park,CA, 1991.

Gibbs,W.W. "Software'sChronicCrisis,"Sc/en(/-fic American {271:3), September 1994, pp. 86-95.

Glaser. B, G., and Strauss, A. L. The Discovery ofGrounded Theory: Strategies for QualitativeResearch, Aldine Publishing Company, NewYork, 1967,

Heath, C. "Escalation and De-escalation ofCommitment in Response to Sunk Costs: TheRole of Budgeting tn Mental Accounting."

MIS Quarteriy Vol. 24 No. 3/September 2000 441


Organizational Behavior and Human DecisionProcesses (62:1), 1995. pp. 38-54.

iacovou, C. L., and Dexter, A. S. "ExplanationsOffered by IS Managers to Rationalize ProjectFailures," Working Paper 96-MIS-003, Manage-ment Information Systems Division, Universityof British Columbia, August 1996.

Johnson. J. "Chaos: The Dollar Drain of ITProject Failures," Application DevelopmentTrends (2:1), 1995, pp. 41-47.

Kahneman, D., and Tversky, A. "Choices, Valuesand Frames," American Psychologist (39),1984, pp. 341-350.

Keil, M. "Pulling the Plug: Software ProjectManagement and the Problem of ProjectEscalation," MIS Quarterly (19:4). December1995, pp. 421-447.

Keil, M., and Mann, J. "The Nature and Extent ofInformation Technology Project Escalation:Results from a Survey of IS Audit and ControlProfessionals," IS Audit & Control Journal (1),1997, pp. 40-48.

Keil, M., Mixon, R., Saarinen, T., and Tuunainen,V. "Understanding Runaway InformationTechnology Projects: Results from an Inter-national Research Program Based onEscalation Theory," Journal of ManagementInformation Systems {^^:3), 1995, pp. 67-87).

Keil, M., and Robey, D. "Turning Around TroubledSoftware Projects: An Exploratory Study of theDeescalationofCommitmentto Failing Coursesof Action," Journal of Management InformationSystems (15:4), 1999, pp. 63-87.

Leary, M. R. Self-Presentation: ImpressionManagement and Interpersonal Behavior,Brown & Benchmark Publishers, Madison, WI,1995.

Leary, M. R., and Kowalski, R. M. "ImpressionManagement: A Literature Review and Two-Component Model," Psychological Bulletin(107:1), 1990, pp. 34-47.

Leathenwood, M. L., and Conlon, E. J. "Diffus-ibility of Blame: Effects on Persistence in aProject," Academy of Management Journal(30:4), 1987, pp. 836-847.

Leib, J. "DIA Now in United's Hands GreenwaldDefends Fare Increases," Denver Post, Febru-ary 28, 1995. p. C-1.

Leib. J., and Mark. E. "DIA Date Now Set forFebruary?" Denver Post, August 20, 1994. p.B-1.

Mark, E. "It Will Never Work," Denver Post.August 24, 1994. p. A-1.

Markus. M. L., and Robey. D. "Information Tech-nology and Organizational Change: CausalStructure in Theory and Research." Manage-ment Science (34:5), 1988. pp. 583-598.

McCain, B. E. "Continuing Investment UnderConditions of Failure: A Laboratory Study of theLimits to Escalation," Journal of Applied Psych-ology (71:2), 1986, pp. 280-284.

Miles, M. B., and Huberman. A .M. QualitativeData Analysis: A Sourcebook of New Methods,Sage, Beverly Hills. CA, 1994.

Mohr, L. Explaining Organizational Behavior.Jossey-Bass, San Francisco. 1982.

Montealegre, R., Knoop. C. Nelson, J., andApplegate. L. M. "BAE Automated Systems (A):implementing the Denver International AirportBaggage-Handling System," Case Study No. 9-396-311, Harvard Business School Press,Boston. MA. 1996a.

Montealegre, R., Knoop, C. Nelson, J., andApplegate, L. M. "BAE Automated Systems (B):Implementing the Denver International AirportBaggage-Handling System." Case Study No. 9-396-312, Harvard Business School Press,Boston. MA, 1996b.

Nathanson, S., Brockner. J.. Brenner, D.,Samuelson. C. Countryman, M., Lloyd. M.. andRubin. J. Z. "Toward the Reduction of Entrap-ment," Journal of Applied Social Psychology(12). 1982, pp. 1111-1118.

Newman, M., and Robey, D. "A Social-ProcessModel of User-Analyst Relationships." M/SOt;arter/y(16:2). 1992, pp. 249-265.

Newman, M.. and Sabherwal. R. "Determinantsof Commitment to Information Systems Devel-opment: A Longitudinal Investigation," MISQuarteriy (20:1), March 1996. pp. 23-54.

Northcraft, G. B.. and Neale, M. A. "OpportunityCosts and the Framing of Resource AllocationDecisions," Organizational Behavior and HumanDecision Processes (37). 1986. pp. 348-356.

O'Driscoll. P. "DeLong Remains Bullish on DIA."Denver Post, May 12, 1994a. p. A-16.

O'Driscoll, P. "Poll: DIA Would Lose Vote,"Denver Post, July 19, 1994b. p. A-1.

O'Driscoll, P. '"Low Tech' Salvation: WebbOrders Backup Bag System," Denver Post,August 5, 1994c, p. A-1.



Rifkin, G. "What Really Happened at Denver'sAirport," Forbes. SAP Supplement, August 29,1994.

Ross, J., and Staw, B. M. "Expo 86: AnEscalation Prototype," Administrative ScienceQuarterly {3^). 1986, pp. 274-297.

Ross, J., and Staw, B. M. "OrganizationalEscalation and Exit: Lessons from theShoreham Nuclear Power Plant," Academy ofManagement Journal{36:4).^S9Z.pp.7Q^-732.

Rubin, J. Z., and Brockner, J. "Factors AffectingEntrapment in Waiting Situations: TheRosencrantz and Guildenstern Effect," Journalof Personality and Social Psychology (31),1975, pp. 1054-1063.

Schlenker, B. R. Impression Management,Wadsworth, Belmont, CA, 1980.

Shaw, T., and Jarvenpaa, S. "Process Models inInformation Systems," in Information Systemsand Qualitative Reseach, A. S. Lee, J.Llebenau, and J. I. DeGross (eds.). Chapman &Hall, London, 1997, pp. 70-100.

Simonson, I., and Staw, B. M. "DeescalationStrategies: A Comparison of Techniques forReducing Commitment to Losing Courses ofAction," Journal of Applied Psychology (77:4),1992, pp. 419-426.

Staw, B.M. "The Escalation of Commitment: AnUpdate and Appraisal," Chapter 9 inOrganizational Decision Making. Z. Shapira(ed.), Cambridge University Press, Cambridge,UK, 1997, pp. 191-215.

Staw, B. M., and Ross, J. "Behavior in EscalationSituations: Antecedents, Prototypes, andSolutions," in Research in OrganizationalBehavior. T. G. Cummings and B. M. Staw(Eds), JAI Press Inc., Greenwich. CT, 1987, pp.39-78.

Steers, S. "DIA Resorts to Plan B," DenverBusiness Joumal (45:45), July 22,1994.

Svaldi, A. "Each New Airport Delay ReducesFinancing Options for Bonds," Denver Sus/nessJournal. May 6, 1994, p. 5.

Weisberg, R. Creativity: Genius and OtherMyths, W. H. Freeman and Co., New York,1986.

Whyte, G. "Escalating Commitment to a Courseof Action: A Reinterpretation," Academy ofManagement Review (^ 1:2), 1986, pp. 311-321.

Yin, R. K. Case Study Research: Design andMethods (2"^ ed.). Sage, Newbury Park, CA,1989.

Zmud, R. W. "Management of Large SoftwareEfforts," MIS Quarterly (4:2). 1980, pp. 45-55

About the Authors

Ramiro Montealegre is an assistant professor ofInformation Systems at the University of Colorado,Boulder. He received his doctorate in businessadministration from the Harvard Business Schoolin the area of management information systems.His master's degree in computer science is fromCarleton University, Canada. He holds a Bachelorin Engineering degree from the FranciscoMarroquin University, Guatemala. He has beenInvited Lecturer at Case Western ReserveUniversity in Ohio, instituto de Altos EstudiosEmpresariales in Argentina, Inslituto de CentroAmerica de Administracion de Empresas (INCAE)in Costa Rica, the Instituto Tecnologico y deEstudios Superiores de Monterrey in Mexico, andUniversidad Pablo Olavides in Spain. ProfessorMontealegre's research focuses on the interplaybetween information technology and organizationtransformation in highly uncertain environments.He has been involved in studying projects oforganizational change in the United States,Canada, Mexico, and the Central and SouthAmerican regions. His research findings havebeen presented internationally.

Mark Keil is an associate professor In theDepartment of Computer Information Systems atGeorgia State University. His research focuseson software project management, with particularemphasis on understanding and preventing soft-ware project escalation. His research is alsoaimed at providing better tools for assessingsoftware project risk and removing barriers tosoftware use. Professor Keil's research has beenpublished in MIS Quarterly. Sloan ManagementReview, Communications of the ACM. Journal ofManagement Information Systems. IEEE Trans-actions on Engineering Management. DecisionSupport Systems. Information & Management.and other journals. He has served as an associateeditor for MIS Quarterly and currently serves onthe editorial board of IEEE Transactions onEngineering Management. He also serves as co-editor of The Data Base for Advances in Infor-mation Systems.



Appendix

Additional Information on Methodology

Data Collection

Data collection began with an examination of publicly available documentation on the project includingnewspaper clippings and other articles appearing in the mass media, as well as historical informationconcerning Denver's political and economic environment (which was instrumental in understanding thedecision to build a new Denver airport). By examining these data, we were able to reconstruct the project'shistory and to identify the key players in the project for subsequent interviewing. Data collection in the fieldbegan with a visit to the DIA public relations office to obtain additional documentation (memoranda andinternal status reports) and archival records (organizational charts as well as lists of names and phonenumbers of individuals associated with the project). By collecting multiple sources of evidence like thisthroughout the study, we were able to use one source of evidence to corroborate another {Yin 1989).

In visiting the DIA public relations office, by good fortune the first author happened to meet with a managerwho appreciated the importance of documenting the project's history. This manager helped to put theresearcher in contact with some of the individuals who were closely involved in the project and frequentlymentioned in the newspaper articles that had been gathered. In this way, the visit led to an initial scheduleof interviews with participants in the DIA project and informed observers,

On-site observations and interviews were conducted during an 18 month period that began in August 1994and extended through December 1995. During this time, the City of Denver received the report fromLogplan (the German firm hired to evaluate the progress of the automated systems) and decisions weremade to construct an alternative manual baggage handling system and to restructure the baggage systemcontract. The time period during which interviews and observations were conducted included some of thekey de-escalation decisions associated with the project, providing an opportunity to study the de-escalationprocess longitudinally. Interviews were arranged with individuals who either had been frequentlymentioned in published reports or played a key role in choosing, designing, or implementing the baggagesystem.

Following the opening of the airport, additional interviews were conducted from March through Decemberof 1995 to obtain detailed information from participants of the project who had been unavailable during themonths before the opening. These interviews not only further illuminated the project, but also provided anopportunity to review the initial draft of the case study report with certain subjects, thus allowing us tovalidate our research findings. The interviews included discussions with the mayor of Denver, the directorof aviation, the chief airport engineer, the president of BAE, the DIA project manager at BAE, and theDenver manager for United Airlines. In total. 74 interviews were conducted with 43 different people duringthe course of the study.

To manage this voluminous data we used a case study database, following the suggestion of Yin. Thedatabase was organized for easy storage and retrieval of documents, archival records, and interview data.One file, for example, stored newspaper articles, organized in chronological order. Another section of thedatabase was devoted to the interviews, with a separate file for each individual, listing contact information,describing the role that s/he played in the project, and containing a dated, typed interview transcript. Theactual interview tapes were also stored in the database, along with an index of who was interviewed and



when- Another section stored project documentation (including actual blueprints of the airport showing thelocation of the baggage handling system). Most of these documents were gathered during the interviewsand stored in chronological order. Finally, the database included a separate file containing quarterlyreports to bondholders (organized chronologically). As Yin notes, a case study database allows otherresearchers to review the data directly rather than being limited to a published paper based on inferencesdrawn from the data, thus increasing the reliability of the entire study.

Interview Methodology

Before each interview, we compiled a list of questions depending on the individual's position in theorganization and his/her association with the DIA project in general and the baggage system in particular.The interviews were semi-structured, with a standard set of questions that were designed to help initiateand guide the interview process. Some typical questions were: "When did you become involved with DIA?""What was the nature of your involvement?" "Was the automated baggage system initially a good idea?"and "When if at all, did it stop being a good idea?" The material discussed invariably stretched beyondthese initial inquiries. All interviews were tape-recorded, and copious notes were taken during theinterviews. Additional observations were noted immediately after each interview was concluded.

At the end of each interview, the subject was asked to suggest other Individuals who would be importantsources for understanding the implementation of the baggage system. There was a high degree ofconsensus among both baggage system advocates and opponents about who were the important actors.

Most individuals—especially those who had been associated with the DIA project during much of itslife—were able to offer considerable historical information regarding the baggage system project. In someinstances, individuals indicated that they were not well-informed, but were witling to speculate. When aninterviewee prefaced his or her remarks with "I don't know for certain, but my sense is that this is whathappened," the interviewee was asked to provide the names of individuals who might be better informedon the particular issue at hand. Additional interviews with these individuals provided corroboration.

Data Analysis

As Glaser and Strauss (1967) and Elsbach and Sutton (1992) recommend, we moved back and forthbetween the empirical data and possible theoretical conceptualization. First, we used publicly availableinformation, background documents, and transcripts of interviews and meetings to create a detailednarrative history of the project. This narrative was then written up more formally in the form of two HarvardBusiness School teaching cases (Montealegre et al. 1996a, 1996b). Though the cases are descriptive innature, they provided a mechanism for sorting the large volume of data and moving toward a more in-depth, within-case analysis (Eisenhardt 1989).

In both our case study database and our case write-up, we endeavored to create what Yin (1989, p. 84)calls a "chain of evidence" allowing others to "follow the derivation of any evidence from initial researchquestions to ultimate case study conclusions." Of course, in the case of DIA, the many publicly availablereports on the implementation of the baggage handling system make it even easier for other researchersto examine the data for themselves and determine whether they would draw the same or differentconclusions.

A key step in our analysis was to create an event listing, a technique that can provide insight into "what ledto what, and when" (Miles and Huberman 1994, p. 110). From the event history, we derived a critical



incident chart (Miles and Huberman 1994) depicting the sequence of key activities and decisionsassociated with the de-escalation phases of the project. The key activities and decisions represent theresearchers' interpretation based on evidence gathered from interviewees.

As a means of triangulation on the key decisions, we plotted the number of newspaper articles appearingeach month in the Denver Post on the subject of DIA's baggage system, reasoning that the key de-escalation decisions would be associated with above-average media coverage. Figure Al maps thedecision points we had independently identified against this analysis. We also used follow-up interviewsto check our perceptions of the key decisions against the perception of severai individuals who werefamiliar with the project's history.

4035302520

V 15

cn

ur<o

Num

1050

D-1 & D-3

^fflffiiTTrrh

to

>

-93

Oo z ao <o

. • 5 ?to JO (O to< * » * * » C*> Cd*

> s^ *<to tb

c

to

>c

CO O<D oto w

zoto

o9o I S- ? 7

to U> U3 tocn cn cn cn

Time (Month-Yr)

Figure A l . Number of Articles Appearing in Denver Post on DIA's Baggage System,July 1993-April 1995

The final step in our analysis involved a variation on qualitative pattern matching between theory and data(see Campbell 1975; Yin 1989). First, we compared and contrasted the activities that appeared to haveinfluenced de-escalation at DIA with the array of triggering activities or conditions that have been discussedin the de-escalation literature. Before identifying a possible de-escalation triggering activity, we cross-checked interview transcripts to verify that at least two or more sources of evidence supported that activityas a trigger. We then mapped the sequence of activities and reviewed the map with several contacts atthe case site.

The entire analysis was highly iterative and involved moving back and forth between the data, the existingliterature, and the concepts that emerged as salient at the research site. This process continued until wehad developed enough categories and associated concepts to explain what had been observed and noadditional data were being collected, developed, or added to the set of concepts and categories—asituation Glaser and Strauss refer to as "theoretical saturation."

Limitations of the Research Approach Used Here

The most significant limitations of our approach concern generalizability and the impossibility of knowingwhat went on inside the heads of key decision makers such as Mayor Wellington Webb, Gene Di Fonso,and Walter Slinger (who managed the DIA project for the City of Denver). To compensate for our limited



access to key decision makers such as Webb. Di Fonso, and SItnger, we relied heavily on the observationsand insights of other individuals who were closely associated with the project and in a position to commenton their motivations and behaviors. Extensive discussions with the managers who reported to themallowed us to develop a rich understanding of the de-escalation process. As a general rule, it is preferableto use a multiple case study design in which theoretical and/or literal replication is possible. Given thesensitivity that surrounds most failing projects, however, the researcher may have to settle for a single casestudy. Even a single case can be useful in theory building (Eisenhardt 1989).


misq2000v24n03p0417

Documents

process of deescalation

deescalation of commitment

information systems

deescalation process

usaslargest airport

material handling systems

important inan airport

systems implementation