Information Technology Project Escalation: A Process Model

Decision SciencesVolume 39 Number 2May 2008

C© 2008, The AuthorJournal compilation C© 2008, Decision Sciences Institute

Information Technology Project Escalation:A Process Model∗

Magnus Mahring†Department of Marketing and Strategy, Stockholm School of Economics, P.O. Box 6501,SE-113 83 Stockholm, Sweden, e-mail: [email protected]

Mark KeilDepartment of Computer Information Systems, J. Mack Robinson College of Business, GeorgiaState University, P.O. Box 4015, Atlanta, GA 30302-4015, e-mail: [email protected]

ABSTRACT

Information technology (IT) project escalation is a common and costly problem. Whilemuch is known about the factors that promote escalation behavior, little is known aboutthe actual escalation process. This article uses an in-depth case study to construct aprocess model of escalation, consisting of three phases: drift, unsuccessful incrementaladaptation, and rationalized continuation. Each phase encompasses several within-phaseescalation catalysts and the model also identifies triggering conditions that promotetransition from one phase to the next: project framing (antecedent condition), problememergence, increased problem visibility, and imminent threat to project continuation(triggering the outcome deescalation). The results show that escalation is not necessarilythe result of collective belief in the infallibility of a project. Rather, escalation results fromcontinued unsuccessful coping with problems that arise during a project. Furthermore,the results suggest that the seeds of escalation are sown early: the very manner in which aproject is framed contributes to whether or not the project will become prone to escalation.As problems ensue, repeated mismatches between attempted remedies and underlyingproblems contribute to fueling the escalation process. Implications for research andpractice are discussed.

Subject Areas: Case Study, Escalation of Commitment, IT Projects, ProcessModel, and Project Management.

INTRODUCTION

Information technology (IT) project escalation is a common and costly problemthat has been well-documented in the information systems (IS) literature (Keil,1995; Drummond, 1996; Newman & Sabherwal, 1996; Keil, Mann, & Rai, 2000a).Escalation “refers to the tendency for decision makers to persist with failing coursesof action” (Brockner, 1992, p. 39).

∗We sincerely thank the senior editor, the associate editor, and the anonymous reviewers for their helpfulcomments. Financial support from the Sweden–America Foundation, the Carl Silfven Scholarship Fund andthe L.E. Lundberg Foundation is gratefully acknowledged.

†Corresponding author.

239

240 Information Technology Project Escalation

While escalation of commitment is a general phenomenon that can occurwith any type of project, the literature (Brooks, 1975; Zmud, 1980; DeMarco,1982; Abdel-Hamid, 1988) suggests that IT projects may be particularly proneto escalation. IS development is a highly complex task with low task observ-ability and decision makers exercising oversight often have limited knowledgeof the work process (Kirsch, 1996; Tiwana, forthcoming). Furthermore, the in-tangibility of the work process and its output promotes optimistic bias in statusreporting (Brooks, 1975; Snow, Keil, & Wallace, 2007), increasing the propen-sity for the “90% syndrome,” the erroneous belief that project completion isat hand (Abdel-Hamid, 1988). The inherent complexity and uncertainty as-sociated with IT projects, together with the need to combine different typesof knowledge that resides with different stakeholders, makes effective gover-nance of IT projects a highly challenging task both for IT departments andtheir clients (Mahring, 2002; Henry, Kirsch, & Sambamurthy, 2003; Tiwana,forthcoming).

Escalation research has provided a promising theoretical base for understand-ing the factors that can cause managers to become entrapped in failing courses ofaction. Unfortunately, little is known about the actual process of escalation (Staw& Ross, 1987; Staw, 1997; Royer, 2002). Given that escalation is consistently de-scribed as a process that unfolds over time (Staw & Ross, 1987; Brockner, 1992),we argue that an improved understanding of escalation as a process not only bringsus closer to the nature of the phenomenon, but also increases the chances of dis-covering effective counter-measures.

The primary purpose of this study is therefore to develop a process modelof escalation. Unlike factor models, which are designed to predict variance inoutcome variables given a set of independent variables, process models focus onthe sequences of events in processes and include theorizing about how and whythe process evolves in a certain way (Mohr, 1982; Newman & Robey, 1992; Vande Ven & Poole, 1995; Langley, 1999; Cule & Robey, 2004).

We use an in-depth case study of a multiyear IT project, the New De-posit System (NDS) project in a mid-sized European bank, as the basis for de-veloping the escalation process model. The NDS project was a mission criticalsystems development project aimed at replacing the core transaction processingsystem in the bank’s retail division. Over a 3-year period, the project suffereda number of setbacks and budget increases, and negative feedback on projectviability was repeatedly reported to decision makers. This extended period ofescalation was ultimately halted through a successful redirection of the project.While redirection from a failing course of action does not guarantee an ulti-mately successful project outcome, the NDS project was ultimately judged to besuccessful.

In the sections that follow, we review existing literature on the process of es-calation and describe the research approach. We then present the escalation processin the NDS case, organized around the phases that were observed and incorporatedin our model. Thereafter, we present the escalation process model and discuss it inlight of the existing literature. We conclude with a discussion of the implicationsof our model for both research and practice.

Mahring and Keil 241

BACKGROUND

Since 1995, research on IT project escalation has explored factors promoting es-calation (Keil, 1995; Newman & Sabherwal, 1996), cultural influences on esca-lation behavior (Keil, Tan, Wei, Saarinen, Tuunainen, & Wassenaar, 2000b), themerits of different theoretical lenses in explaining escalation (Keil et al., 2000a;Mahring, Holmstrom, Keil, & Montealegre, 2004), and procedures for deescalation(Montealegre & Keil, 2000; Pan, Pan, Newman, & Flynn, 2006).

In spite of the fact that escalation is essentially a process phenomenon, therehas been little evidence of process theorizing (Langley, 1999) on escalation eitherwithin or outside the IS literature. Indeed, a review of the escalation literature by oneof its founders (Staw, 1997) suggests that research in the field has failed to developan adequate process model of escalation. Since process theorizing on deescalationhas been successfully conducted within the IS field (Keil & Montealegre, 2000;Montealegre & Keil, 2000; Pan, Pan, & Flynn, 2004; Pan et al., 2006), developmentof a process model of escalation should also be possible.

Process models do not have the direct causality of factor models. Instead, theyexplain the dynamics by which a certain outcome comes about, helping us under-stand the transformation process that factor models treat as a black box (Newman& Robey, 1992). To do so, process models need to explain what drives the process,in the form of triggers (Mohr, 1982) or through a conceptual “motor” that operatesin accordance with a certain logic (Van de Ven & Poole, 1995).

At the outset of our research, we were aware of two prior attempts to developan escalation process model: a literature review by Staw and Ross (1987) thatdescribed an “escalation prototype” subsequently relabeled a “temporal model ofescalation” (Ross & Staw, 1993), and a conference article presented by Royer(2002) that described an eight phase process-oriented model of escalation anddeescalation. Several elaborate database searches, including keyword and citedreference searches, yielded no additional process-oriented models of escalation.

Staw and Ross (1987, p. 44) introduced a temporal model (Figure 1) thatdistinguishes between four types of factors that can promote escalation: project,psychological, social, and structural (or organizational) factors. Their model grewout of the analysis of British Columbia’s decision to host the 1986 world’s fair(Ross & Staw, 1986), where it was observed that escalation began because ofproject-related factors and then was reinforced by psychological, then social, andfinally structural (or organizational) factors.

The model has not been well supported in subsequent case research (Ross &Staw, 1993; Newman & Sabherwal, 1996), which suggests that the sequencing offactors is not nearly as straightforward as the model suggests. After applying themodel to the analysis of the Shoreham nuclear power plant case, Ross and Staw(1993, pp. 722–723) concluded that the “case does not fit perfectly the a priorimodel,” principally because “organizational determinants of escalation appeared asan early influence on Shoreham” and because “contextual influences became a verypowerful force in the Shoreham case in ways the a priori model did not anticipate.”

Newman and Sabherwal (1996) applied the Staw and Ross model to theCENTCO case, a multiyear effort to implement an inventory control and materialsmanagement system within a division of a large North American firm. They found


Figure 1: The Staw and Ross temporal model of escalation (Staw & Ross, 1987;Ross & Staw, 1993).a

PHASE 1 PHASE 2 PHASE 3 PHASE 4

Promise of Future Outcomes (+)

Psychological Determinants (0)

Social Determinants (+)

Project Determinants (+)

Organizational Determinants (+)

Psychological Determinants (+)


Project Determinants (-)


Project Determinants (0)


Receipt of QuestionableOutcomes (0)

Receipt of NegativeOutcomes (-)

Receipt of Highly Negative Outcomes (--)

COMMITMENT TO A COURSE OF ACTION

PHASE 1 PHASE 2 PHASE 3 PHASE 4

Promise of Future Outcomes (+)




















Receipt of QuestionableOutcomes (0)

Receipt of NegativeOutcomes (-)

Receipt of Highly Negative Outcomes (--)

COMMITMENT TO A COURSE OF ACTION

aThe +s, −s and 0s in the figure depict the influence of different types of escalation factorsduring various points of time.

that “project and structural determinants are crucial in obtaining initial commitmentfor the IS project, social and structural determinants influence whether commitmentto the project is withdrawn, and psychological and project determinants influenceescalation of commitment” (Newman & Sabherwal, 1996, p. 45). These resultssuggest that sequencing different types of factors is not a fruitful way to developa generalizable escalation process model. Furthermore, as Royer (2002) notes,the Staw and Ross model fails to provide an understanding of the dynamics ofescalation. It does not explain what really distinguishes one phase from another orwhat triggers the movement from one phase to another phase and thus it falls shortof constituting a true process model (Mohr, 1982; Langley, 1999).

In an unpublished conference article, Royer (2002) proposed an eight phaseprocess-oriented model of both escalation and deescalation based on two casestudies. One project involved a new lens developed by Essilor (the Phileas project)and the other involved a mineral fillers project, called MiFi, undertaken by Lafarge.Royer’s model (Figure 2) includes four escalation phases: (i) blindly going on, (ii)relentlessness, (iii) diagnosis, and (iv) verification. Table 1 summarizes these fourphases.

Royer’s model is an improvement over the Staw and Ross model in that itrepresents a true process model with phases and transitions. That being said, theRoyer model raises several questions that warrant further process theorizing. First,the notion of collective belief is central to Royer’s view of the escalation process:“escalation is driven by a collective belief in the success of the project” (2002, p. 2).Royer describes collective belief as a “deep conviction” (Royer, 2002, p. 16) heldby actors that have “no doubt” about the ultimate success of the project (Royer,2003). While this is an interesting notion, the heavy emphasis on this one factor de-tracts from the process-orientation of the model and its ability to explain dynamics


Figure 2: Royer’s (2002) eight phases of escalation and deescalation.a

Birth of the Idea

Organization of the Project

Implementation

Blindly Going On

Relentlessness

Diagnosis

Verification

Implementation of Withdrawal

Positive Feedback(Breakpoint)

(Phase)

Positive Feedback

Negative Feedback

Revealers

Revealers

Negative Assessment

Negative Assessment

(Escalation Period)

Birth of the Idea

Organization of the Project

Implementation

Blindly Going On

Relentlessness

Diagnosis

Verification

Implementation of Withdrawal

Positive FeedbackPositive Feedback(Breakpoint)

(Phase)

Positive FeedbackPositive Feedback

Negative FeedbackNegative Feedback

RevealersRevealers

RevealersRevealers

Negative AssessmentNegative Assessment

Negative AssessmentNegative Assessment

(Escalation Period)

aShaded parts of the model represent the escalation process according to Royer.

throughout the escalation process. In addition, current escalation research remainsinconclusive on the effects of success beliefs on escalation and the idea that collec-tive project success beliefs would have a decisive impact on escalation is not wellsupported (Arkes, 1991; Boulding, Morgan, & Staelin, 1997; Schmidt & Calan-tone, 2002; Whyte & Fassina, 2007). Furthermore, the model blurs the distinctionbetween escalation and deescalation as the latter two of Royer’s four escalationphases have previously been identified as part of deescalation (Montealegre & Keil,2000). Similar to the Staw and Ross model, the cases that Royer analyzed exhibiteddistinct differences and fit her model to varying degrees: “the MiFi case does notinclude the relentlessness phase and the Phileas case includes successive identicalphases” (2002, p. 6).

RESEARCH APPROACH

Research Design and Data Collection

An in-depth case study served as the empirical basis of this research and wasused to develop the process model of escalation. Case studies are especially useful


Table 1: Summary of escalation phases in Royer’s (2002) model.

Escalation Phase Description

Blindly Going On In this phase, “negative feedback is not enough to make decisionmakers aware of the situation” (Royer, 2002, p. 27). Consequently,“the project enters a state typical of groupthink in which decisionmakers have an illusion of invulnerability despite negativefeedback” (Royer, 2002, p. 27).

Relentlessness Several instances of unambiguous negative feedback (“revealers”)begin to make people aware of the “badness” of the situation,generating doubts among some individuals. During this phase,however, the collective belief outweighs any individual doubts thathave arisen.

Diagnosis The “revealers” generate awareness and negative emotions for“believers.” Group cohesiveness begins to degenerate asnewcomers join the group without the previous beliefs about theproject. Newcomers’ interpretation of events is different and thisgenerates more debate within the group leading to a decline incollective belief. While the project continues largely due to inertia,this phase is a turning point as individuals press for an evaluationof the project.

Verification This phase is characterized by an exit proposal that is defended by aparticular individual. This results in a conflict between believersand nonbelievers and results in an agreement for conducting a newevaluation with “a different procedure able to provide decisionmakers with unambiguous information to make a decision” (Royer,2002, p. 28).

for exploratory research where an in-depth understanding of a phenomenon in itscontext is desired (Benbasat, Goldstein, & Mead, 1987; Yin, 2003). Case studies arealso suitable for theory building in areas where existing theory is limited (Benbasatet al., 1987; Eisenhardt, 1989). Theory and model development can be based on asingle case study (Lee, 1989; Lee & Baskerville, 2003; Yin, 2003) and case studiesrepresent a preferred approach for process-oriented studies (Langley, 1999).

The case chosen for this study was the NDS project in “MiddleBank” com-pleted in the 1990s. (All names, including names of people, are pseudonyms.) Thiscase was selected because it had experienced an extended escalation period, mostinvolved actors who were still employed in the company or otherwise reachable forinterviews at the time of data collection, documentation was extensive and avail-able, and access to data, interviewees, and the case site was provided generouslyand without limitation.

Data collection included interviews (31 interviews, average duration1.5 hours); studies of documents, corporate records, annual reports, and exter-nal press coverage (several thousand pages); study of two corporate informationvideos (37 minutes); and observation of the implemented information system inuse. Because most of the data were collected retrospectively, direct observation wasconfined to practices, behaviors, and artifacts observed during visits to the com-pany to conduct interviews or collect other data. In accordance with Yin (2003) acase study database was used to keep track of and organize data.


Bias is always a concern in retrospective data collection. This risk was ad-dressed in several ways. For documents and similar sources, general measures ofsource critique were taken (Glick, Huber, Miller, Doty, & Sutcliffe, 1990; Golden,1997), including assessment and documentation of the time-proximity (or con-temporaneousness) of a document to the events described in the document andeach document’s authenticity. Risks for biases in retrospective interviewing werecountered by triangulation within and between different data sources, the use of atime-line to arrange data and build a coherent story, source critique, and formula-tion and assessment of alternative explanations (Glick et al., 1990; Golden, 1997;Mason, McKenney, & Copeland, 1997; Yin, 2003).

Data Analysis and Model Development Approach

We employed a combination of two process theorizing strategies: narrative andvisual mapping (Langley, 1999). The narrative strategy, with its emphasis on timeas an anchor point and its focus on stories and meanings, is well suited to make useof complex and rich data. This approach was used to organize the voluminous casedata and to gain an in-depth understanding. To facilitate the analysis, a timeline wasused to arrange data chronologically (Mason et al., 1997). This provided the basisfor writing an extensive case narrative (a condensed version of which follows in thenext section). In doing so, we followed Pentland’s (1999) guidelines for processnarratives: identifiable sequence in time, focal actor or actors (key actors influencingthe NDS project), an identifiable narrative voice (“the researcher”), an evaluativeframe of reference (escalation as an undesirable phenomenon), and other indicatorsof content and context. Thereafter, visual mapping was used to identify key eventsand phases in the NDS project. Visual mapping, which focuses on events andorderings, achieves high generality and simplicity at the expense of some accuracy.Visual mapping and narrative strategies complement each other particularly wellwhen a generalized model grounded in rich data is sought (Langley, 1999).

Van de Ven and Poole (1995) identified four-process model archetypes—lifecycle, teleology, dialectics, and evolution—that differ in event sequences, orga-nizational levels and “conceptual motor”; the underlying logic of what drives theprocess. A good process model should be based on an archetype that is consistentwith the studied process (Van de Ven & Poole, 1995). Escalation is frequentlydescribed as a lifecycle phenomenon that has a beginning, develops over time andhas a limited set of outcomes (Brockner, 1992; Montealegre & Keil, 2000). There-fore, we chose the lifecycle archetype as the one that was most consistent with thephenomenon. This archetype is frequently used in process studies (Pentland, 1999;Van de Ven, Polley, Garud, & Venkataraman, 1999; Montealegre & Keil, 2000).

Our view of processes was also informed by the punctuated equilibriummodel (Tushman & Romanelli, 1985; Gersick, 1991; Newman & Robey, 1992). Indeveloping our process model, we distinguished between phases and events. Theformer represent periods of stability (or states) that are relatively long-lasting, whilethe latter are characterized by shorter periods (or transitions) in which one or moreevents occur that trigger movement to the next phase. One of the characteristicsof a good-process model is that it should articulate both the phases as well as thetriggers that promote movement between phases (Mohr, 1982).


In developing our process model, we examined the case data and identifiedkey events in the NDS project. We then asked ourselves how and why the flow ofevents developed and where “shifts” in the flow of events could be detected. Overtime, we identified and named discreet phases, based on our analysis of the data.Identification and delineation of phases was determined by detection of periodswithin which the patterns of behaviors and events were more uniform than acrossphases (Langley & Truax, 1994). To further verify and support the delineation ofphases, we searched for and identified key decisions that punctuated the end ofone phase and marked the transition to the next phase. We then asked the question:what moves the process of escalation from one phase to the next? This helpedus to identify how certain events triggered changes in the process of escalation.Identification of triggers was determined by detecting key events that initiated a shiftin how the project was viewed, managed, and controlled. Subsequently, we alsoanalyzed for each phase what the “mechanisms” were that sustained the uniformbehavior patterns that “produced” escalation within that phase. Ultimately, thisled to the identification of specific conditions and activities called “within-phaseescalation catalysts.”

With the case chronology at our side, we used an open coding approach inconjunction with a visual mapping strategy to understand the case at a higher levelof abstraction and to graphically depict early conceptualizations of phases andtransitions between phases. Moving iteratively between the emerging model andthe case chronology, we checked for fit while experimenting with concept labelsthat would most accurately characterize the phases and transitions in the emergingmodel. Throughout this work process, we followed the recommendation of Elsbachand Sutton (1992) to move back and forth between the empirical data and alternativeconceptualizations thereof. Over time, we also related our emerging process modelto previous work in the area, in accordance with the recommendations for processtheorizing by Orton (1997) and Langley (1999). In total, we developed twelve visualmaps before our iterative process resulted in a model that accurately captured thedynamics of the case, used general concepts, was parsimonious, and yet containedenough richness to convey the dynamics of the escalation process.

During the analysis, we utilized a strategy of assigning specific roles to thetwo involved researchers (Montealegre & Keil, 2000); the first author had collectedall the data and structured it for analysis, while the second author played the roleof “devil’s advocate,” bringing a fresh view to the analysis (Eisenhardt, 1989).

THE NEW DEPOSIT SYSTEM PROJECT

In this section, we describe the NDS project, highlighting the phases, resulting trig-gering conditions, and key decisions identified throughout the escalation process.Figure 3 provides a schematic overview of events in the case, related to phases andtriggering conditions. The figure also contains a line that depicts approved projectexpenditures over time. The pattern of expenditures in the case, coupled with thenegative feedback received during the period, provides confirmatory evidence ofescalation.

The NDS project was a large IT project undertaken by a mid-sized Europeanbank during the 1990s. Developed in-house, NDS was viewed as “mission-critical,”


Figure 3: Schematic visual map of key events in the NDS project with processphases, triggers and approved project expenditures.

Backlog of functionality improvement requests from branch offices increasing. Pre

his

tory

…Y

ear

0 (E

nd

s)

An

tece

den

t C

on

dit

ion

: P

roje

ct F

ram

ing

Severe problems in production (data processing) block customer transactions on several occasions. Problems highlight the bank’s vulnerability to malfunction of mission-critical legacy systems, foremost the deposit system.

Feasibility study for New Deposit System completed. Proposed project budget: ¤ 5 million. Report focuses overall functionality improvements compared to existing system and technical issues.

Exec. VP chairs steering committee. Project described as necessary and urgent. Project budget is set to ¤ 8 million.

Project scope and approach challenged by members of project team.Y

ear

1 (E

nd

s)

PH

AS

E 1

: D

RIF

T

As project work commences, project team members experience uncertainty concerning how to interpret project guidelines and the requirements described in the feasibility study.

Discussions about project scope and approach intensify in project team and IT department.

Recurrent, inconclusive discussions between users, the business development department and system developers about the actual meaning of the stated requirements.

Several senior analysis and design experts, brought into the project during late fall, become strong proponents of expanding the scope of the project.

Concerned with the reports from the project, the systems development manager initiates a project review by external consultants.

* Decision 1: Steering committee decides to intensify monitoring and control, requesting improved project control and reporting from project manager.

Review delivers critique of project management; stresses need to clarify project charter.

First NDS project manager replaced, but new project manager’s competence profile is similar, mandate is unchanged.

Pro

blem

E

mer

gen

ce

New head of user representatives in NDS appointed (external recruitment). New user representatives are recruited, but organization of requirements and design work remains unchanged.

PH

AS

E 2

: U

NS

UC

CE

SS

FU

L

INC

RE

ME

NT

AL

A

DA

PT

AT

ION

Project manager reports projected cost increases. Steering committee renews requests for improved project control measures and reporting.

Project manager reports upwards revisions of cost estimates and work progress below plan.

Consultant hired to support new project manager, but other assignments limit time available for the NDS project.

Increasing concerns in IT and Business Development departments about deposit system maintainability and potential malfunction.

Feasibility study for a new deposit system initiated. Urgency of replacing old system stressed by several actors.

Conflict emerges in steering committee around project cost.

* Decision 0: CEO (chairing Corporate IT Board) approves start of NDS project.

Tim

e

Yea

r 1

Yea

r 2

Approved project expenditures (million Euro)

25 520 1015

(a)

Continued


Figure 3: (Continued)

Conflict in project team around scope and development approach continues. Continued effort to clarify requirements.

Business development department and users continue to stress system flexibility in discussions with developers. Developers adapt by aiming for system design solution able to subsume future functionality requirements.

Steering committee approves goal study report. Exec. VP resigns from chairmanship of steering committee over cost dispute, business development managers takes over. Projected project cost is now 18 million.

Yea

r 3

Project manager again reports cost increases and receives orders to improve project planning. Conflict in steering committee continues, mainly between executive VP and the IT director and systems development manager.

PH

AS

E 2

(C

ON

T.)

: U

NS

UC

CE

SS

FU

L

INC

RE

ME

NT

AL

AD

AP

TA

TIO

N

CEO approves new NDS project plan at Corporate IT Board meeting. Strong general guideline from CITB to reduce/postpone functionality in case budget limit is threatened.

Project plan now fully reflects ambition to build a new deposit system from scratch, rather than basing the system on the old system s functionality.

Project manager reports delays in project work and increases in projected costs. Steering committee stresses need to control costs.

Project management reports that project phases need to be revised: substantially more development work has to be included in the first of two project phases. Steering committee reaffirms and extends demands for improvements in project planning and reporting.

Second project review criticizes lack of fit between characteristics of business processes and chosen development method, calls for substantial improvements in project planning and strengthened project leadership.

Steering committee discuses review. Viability of project and of current project plan questioned by several committee members. Committee members openly question whether it is at all possible to continue the project as planned. Response stresses improvements and states that the worst is over in terms of delays and cost overruns.

Incr

ease

d

Pro

ble

m

Vis

ibili

ty

Yea

r 2

(co

nt.

)

IT director proposes canceling NDS and renovating old system. Heated, inconclusive discussion in steering committee, protests from users and executives. Project budget is now 25 million.

Incoming CEO launches hearing process after having been briefed on crisis in NDS steering committee.

Incoming CEO approves continuation of NDS after an extensive hearing process and on the basis of a reassessment of project plans, project management and project governance. The decision is reaffirmed by the Corporate IT Board.

Backed by business Development manager, project manager reorganizes project, revamps project management procedures, initiates operation platform to target and solve key project challenges, changes staffing.

PH

AS

E 3

: R

AT

ION

AL

IZE

D C

ON

TIN

UA

TIO

N

Imm

i-n

ent

Th

reat

Ou

tco

me:

D

e-es

cala

tio

n

Major project review by steering committee. Two consecutive meetings discuss renovation vs. continuation of current project. Analyses and presentations emphasize continuation as superior alternative. Steering committee reaffirms commitment to continuing NDS project according to newly revised plan, which includes a project budget increase to 22 million.

Second project manager replaced with consultant working in project management team.

New project manager improves project planning and steps up to face project leadership challenges. Criticism towards project cedes in anticipation of revised project plan.

Intensified and improved systems analysis and project planning activities reveal that NDS is much larger than previously estimated.

Incoming CEO stresses need to reduce total IT costs at CITB meeting.

Project manager reports revised project figures to steering committee. After heated discussion it is decided to revisit projectplans at the subsequent meeting.

The awareness of the project s troubled state spreads in the organization, as does skepticism towards NDS.

Approved project expenditures (million Euro)

* Decision 2: Steering committee decides to review and reassess the project.

* Decision 3: New CEO calls a hearing to decide on termination or redirection of the project.

Tim

e

Yea

r 2

(En

ds)

25 520 1015

(b)


since it concerned the replacement of the legacy transaction processing system forall payments and transfers for consumer as well as corporate customers. The ITinfrastructure and development tools included client server architecture, a relationaldatabase management system, and a third-generation programming language; inshort, a typical and still very common IT environment and development approachin many retail banks.

The bank was present in one national market and had competed successfullyfor many years. However, an intensified emphasis on service development andincreasing competition from new entrants into the banking and insurance sectorcreated the need for greater agility. In order to make that happen, internal systemshad to be modified to accommodate new service offerings.

Antecedent Condition: Project Framing

In the years directly preceding the NDS project, the bank’s existing legacy depositsystem was increasingly difficult to maintain and there were mounting concernsthat it would malfunction as a result of the patchwork of modules added to thesystem over a 10-year period. As a result, a feasibility study for a NDS was initiated(Year 0, see Figure 3). The feasibility study included management and experts fromthe IT department as well as from the business development department, whichwas responsible for business IT planning and for interfacing between branch officesand the IT department. During the feasibility study, concerns regarding the legacysystem were elevated by repeated problems that left customers unable to deposit orwithdraw money due to unscheduled downtime. These circumstances reinforcedthe idea that a NDS was a necessity.

When the NDS project proposal was introduced to the corporate IT board,which was chaired by the CEO, the NDS project was framed as being “necessaryand urgent” in order to avoid failure of the existing mission critical deposit system.The emphasis on urgency led to a scramble to get going and a compressed timelinefor the project. This framing of the project created momentum, but it soon wouldbecome apparent that the project plan provided insufficient guidance to channelthis momentum.

In my opinion we rushed into the project too quickly, with staffing, organization,analysis and data modeling work. We should have done a more thorough study[before starting the full-scale project]. [But] it was an IT project. It was startedaccording to the existing model [for IT project work], the project manager wasfrom the IT department and they said that it was urgent (Karen Martin, headof business development).

Result: The project was framed as necessary and urgent, which contributed to a“ready-fire-aim” mentality in and around the project and prompted a hasty approvalby the corporate IT board and the CEO.

Decision 0: The CEO’s decision to approve the start of the project, outside of theapproved IT budget, punctuated the start of the project as well as the first phase ofescalation.


Phase 1: Drift

Without a clear sense of direction, the first phase of the project was characterizedby drift and confusion. Neither the goals nor the work approach were sufficientlyspecified to guide the project adequately.

Design decisions were changed all the time, several times . . . . We weren’t readyto take decisions when they were taken (Elisa Leonard, head of user represen-tatives).

At the outset of the NDS project, a case had been made that the currentdeposit system needed to be replaced and that this was to be done through in-housedevelopment. However, as the project unfolded, differences of opinion developedbetween key project participants regarding the development approach and scopeof the project.

[A senior analyst recruited early] pushed hard for doing a major analysisof business processes. I, on the other hand, advocated approaching this asa major upgrade, not as [clean slate] development (Albert Linder, head ofsystems architecture).

Not only were there diverging views concerning the overall approach toanalysis and design work in the project, the idea of using the existing depositsystem as a basis for the new system was also introduced. Three different views ofthe project charter emerged:

(i) Build a new system based on an analysis of the functionality of theexisting deposit system (sometimes referred to as “reverse-engineering,”this would result in a system that performed very similar to the existingsystem, but with increased reliability and maintainability);

(ii) Build a NDS from scratch (aimed to result in a deposit system “for the21st century,” flexible to future functionality demands and that wouldserve as a cornerstone of the future systems infrastructure of the bank);or

(iii) Retain and use the core of the old system and limit new developmentto new system modules interfacing between the existing “transaction-processing engine” and the user interface.

The disparate views of the project charter opened the door for drifting re-quirements as discussions commenced between analysts, user representatives andthe business development department:

There was no agreement on what kind of system [we were going to build] (IreneBerger, sub-project manager, design).

Within the project team, conflict ensued as people aligned themselves withdifferent interpretations of the charter. The issue remained unresolved for a con-siderable time period, hampering progress. Initially, the intentions as expressed inthe feasibility study were to build a new system based on the functionality of theold system (option 1 above). Throughout the drift phase, there were also those whoadvocated renovating the old system (option 3 above). Over an extended period oftime, however, the approach and ambition level gradually drifted toward the mostambitious alternative, building a new system from scratch (option 2 above).


As time went by, the focus of the project changed . . . this took [about] a year(Irene Berger, sub-project manager, design).

Result: (Problem Emergence). Less than 1 year into the project, the project managerreported steadily increasing resource expenditures, while progress remained quitelimited. To senior IT managers, it seemed like nothing was happening in the project.This problem emergence meant that difficulties within the project became apparentto observers, including the project steering committee.

A review by external consultants, initiated by the IS development manager,confirmed the growing concerns of managers involved with the project, pointing tosubstantial shortcomings in project planning and project management and stress-ing the need to end the drift in development approach and project charter. Theemergence of problems required response, triggering the next escalation phase,unsuccessful incremental adaptation.

Decision 1: The key decision that punctuated the move from the drift phase to theunsuccessful incremental adaptation phase was the project steering committee’sdecision to request improved project control and reporting practices.

Phase 2: Unsuccessful Incremental Adaptation

The steering committee’s request for improved project control and reporting prac-tices prompted project management to address and report back on problems. How-ever, while some improvement in project monitoring could be observed, no effectiveremedies to problems were implemented and the same problems persisted. As ac-tual and projected resource expenditures continued to increase, the next step forthe steering committee was to replace the project manager. However, the changeof project manager did not take into account that a substantially different skill setwas needed to lead this troubled and increasingly complex project; the new projectmanager was generally considered a “good person,” but his project managementskills were quite similar to those of his predecessor.

The [managers in the] IT department said “There is no one else” . . . But hewas not the right person to lead that kind of project (Karen Martin, head ofbusiness development).

Furthermore, the replacement was not accompanied by any change in orclarification of the project charter, initiating a pattern of unsuccessful incrementaladaptation, in which each attempted remedy failed to change the approach tomanaging the project or the project trajectory. The next attempt to remedy thesituation was to bring in an external consultant to support the project managementfunction. However, this consultant was also engaged in other projects in the bankand had limited time to devote to the NDS project.

At the end of the first year of the project, the project steering committeerepeatedly requested improvements in project management and control, includingcost control. Several plan revisions were made, leading to higher cost estimates,but there was no reassessment of the underlying course of action or the projectgoals. As the project manager reported problems to the committee, he regularlyoffered explanations that stressed the temporary nature of problems.


Continued problems in the area of requirements determination led to a deci-sion to bring in a new head of user representatives who, in turn, insisted on bringingadditional users into the project. Even as the new user representatives were broughtinto the project, however, their supervision, work tasks and role in the project werenot changed.

Over time, however, an executive vice president who was the highest-rankingmember of the steering committee grew increasingly concerned and upset aboutthe cost revisions. Over the course of several steering committee meetings that tookplace at the beginning of the second year of the project, arguments between theexecutive vice president and the IT and ISD managers were heated:

I tried to talk with them like: “We have this much money, so I want us to dividethe project into different phases, like with a building loan, and you get moneyfor each phase.” . . . But [the IT director] Eric Osgood said “That’s not howwe work,” so I said “Well, you had damn well better start then!” and Erik said“It doesn’t work that way” and I said that [in that case I didn’t want to be partof it] (Fred Trent, executive vice president).

Result: (Increased Problem Visibility). Toward the end of the second year of theproject, a new review was carried out. The results highlighted the persistent prob-lems with lack of project management capability, deficiencies in project controland reporting procedures, and the lack of visible results. The NDS project was atthis point in time also increasingly noticed in other parts of the organization:

I was so furious because I just wondered what the hell they were doing. I usedto go around saying “Damn NDS” (Neil Hofmann, project manager, businessdevelopment).

At two subsequent steering committee meetings, the project manager pre-sented substantial increases in project cost figures (projected cost was now €15 mil-lion, three times the initial estimate and twice the approved budget). Doubts in-creased in the steering committee and concerns were now quite widespread in theorganization. Direct questions about the viability of the project were being raisedboth in the committee and elsewhere. As the IT director recalled:

Well, now we are in the spring [at the end of the second year of theproject] . . . and at this time we started to hesitate . . . [because we] saw howcomplex it was (Eric Osgood, director, IT).

The increased problem visibility toward the end of this phase triggered a shiftin how problems were addressed: for continuation of the project to be defensi-ble, further justification was necessary and the escalation process advanced fromunsuccessful incremental adaptation to the next phase, rationalized continuation.

Decision 2: As a result of the increasingly visible and mounting problems, thesteering committee decided to review and reassess the project.

Phase 3: Rationalized Continuation

At the steering committee meeting that took place at the end of the project’s secondyear, the project managers reported that resource use in systems design exceededthe last estimate from 6 months earlier by 70%. There was also a 6-month delaycompared to the previous project plan. Several committee members questioned the


credibility of the project plans. In an exchange quoted in the meeting minutes, theproject manager downplayed the plan revisions by arguing that the original figureswere only “desired” objectives:

Karen Martin, head of business development: “The deadline was well substan-tiated in the latest major project report. It is important that we are in agreementon this.”

Albert Linder, project manager (responds): “The deadline [in the report] wasa ‘desired’ endpoint considering the need to avoid implementation aroundyear-end. . .”

Subsequently, committee members questioned whether it was at all viable toproceed with the project as currently planned. The project manager rationalizedcontinuation of the project by arguing that project planning had now advanced to apoint where further delays were unlikely and that there was now “light at the end ofthe tunnel.” He also presented a newly developed plan designed to reduce systemmigration risks. Persuaded by the arguments and the migration plan, the steeringcommittee refrained from taking any further corrective action on the project.

Soon after this steering committee meeting, however, further technical prob-lems surfaced. Therefore, in the beginning of the project’s third year, the steeringcommittee assembled for a full-day meeting about the state of the project. Newproject plans were presented and for the first time since the feasibility study, thequestion of alternative development strategies was included on the steering com-mittee’s agenda, including renovation of the existing deposit system. The viabilityof continuing to move forward with the current approach was debated and severalcommittee members expressed frustration with the project situation and a lack ofconfidence in the project manager. They also explicitly asked “is it at all possibleto continue on the current path?”

However, a closer examination of the meeting reveals that while dissent waspresent, the set up of the meeting was not as much designed to offer alternatives, asto recommit key actors to the current course of action. At the outset of the meeting,the project manager explained the state of the project:

NDS is a project in which we have achieved good work results so far andacquired considerable systems development competence and business knowl-edge, but failed in planning and control. Actions have been taken to improveplanning/control, decision process and coordination (Albert Linder, projectmanager, quoted in the meeting minutes).

During the day, several activities promoted staying the course and facilitatedrecommitting the steering committee to the project. First, experts from the ITdepartment presented potential problems and unavoidable shortcomings associatedwith renovating the existing system. Second, the complexity and importance of theNDS project were extensively explained (e.g., the centrality of the NDS to thefuture systems architecture of the bank). Third, the drawbacks of the alternativesto the current plan, such as dividing the project into several consecutive parts,were thoroughly explained. Throughout the meeting, alternative courses of actionwere positioned as equally or more problematic, thus providing rationalization forstaying the course. In other words, the information presented to the committee wasgeared toward facilitating a decision to continue the project.


Toward the end of the day, an individual vote on how to proceed was carriedout. The tally leaned in favor of NDS but was not unanimous. The chairpersondecided to reconvene the group two days later and asked for additional analyses to bemade in the interim. In the day between the meetings, cost estimates for renovatingthe legacy system were adjusted upward (from €4.5 million to €9 million) andthe hardware costs for NDS were reduced. In the follow-up meeting, the decisionto continue the NDS project was unanimous, as confirmed by a second roundof voting. This elaborate decision process led to rationalized continuation of theproject in spite of the visibility and severity of the project’s problems at this time.

Directly after the prolonged steering committee meeting, the project managerwas replaced with the consultant brought in earlier to support the project. Two andone-half years into the project the projected cost had reached €25 million.

Result: (Imminent Threat to Project Continuation). At this time, the IT directorfaced continued cost increases on the NDS project coupled with intense pressurefrom the CEO-to-be to curtail overall IT costs. He therefore decided to proposecancellation of the NDS project in favor of renovation of the existing legacy system.When this recommendation was presented to the steering committee, it createdsurprise and astonishment and the rationalizations that had sustained escalationbroke down. The momentum of the escalation process was halted as project workcame to a standstill and the issue was transferred to the incoming CEO. There wasnow an imminent threat to project continuation.

Decision 3: In response to the situation, the incoming CEO called a hearing todecide on termination or redirection of the project.

Outcome: Deescalation

Normally, it would have been the IT department’s [responsibility] to handlethe issue. But as it was, I happened to have the time since I hadn’t taken officeyet, and it was a large and important project, and there were quite stronglyconflicting opinions about what should be done . . . . There was a need to listento all these people who had been involved in the project, to listen to them beforewe decided on what to do (Stuart Vale, CEO-to-be).

The hearing process ultimately resulted in a decision by the incoming CEOto redirect the project. Over the following months, the setting for the continuedwork, the priorities and the work practices changed dramatically. Soon after thedecision to redirect the project, regular project work was halted for 1 month toallow a major reassessment of the project and all its problems, and an action planfor getting the project on track was crafted. The redirection of the project includedmajor changes in project governance, project organization and staffing, as wellas changes to project management procedures, practices, and norms. Furthermore,nonessential functionality was cut from the system specifications. The redirection ofthe project also benefited from the increasing dedication of project participants anda budding partnership between the project manager and the business developmentmanager on project management and project sponsorship, which included that thebusiness development manager helped ensure acceptance of the revamped projectthroughout the retail banking organization. Through this joint effort by the businessdevelopment manager, the project manager, and an increasingly dedicated team


leading the project, the project was turned around to produce a reliable depositsystem that is still in operation.

A PROCESS MODEL OF ESCALATION

Based on the NDS case study, we developed a process model of escalation. In thissection, we introduce and discuss the model, enfolding relevant literature. Consis-tent with guidelines for process models (Mohr, 1982; Langley, 1999), our modeldescribes the phases associated with a complex phenomenon (in this case, escala-tion of IT projects), substantiates the characteristics of each phase and articulatesthe triggering events that promote movement between phases. Also consistent withprocess theorizing guidelines, the model does not predict the specific outcome orthe time scale over which escalation will occur.

The model (Figure 4) represents escalation as a sequence of three separatephases with distinct characteristics. Phase transition triggers push the process fromone phase to the next (Mohr, 1982) and within-phase escalation catalysts promoteescalation within each phase. An antecedent condition precedes the first phase andan outcome concludes the process.

The antecedent condition is project framing, which concerns the rationale forthe project and how it is viewed. The first phase is drift, in which the project isallowed to continue and consume resources as ambiguity concerning the projectcharter and conflicts concerning project goal and direction emerge. Problem emer-gence then triggers the shift to the second phase, unsuccessful incremental adap-tation. During this phase, problems are seen as remediable without change in goal

Figure 4: An escalation process model.


or direction and there is a continued mismatch between underlying problems andattempted remedies. Together, these two escalation catalysts produce continuedescalation. Over time, the consequences of ineffective incremental adaptation leadto increased problem visibility. As problems mount, both in terms of magnitudeand visibility, the viability of the project begins to be questioned. The increasedproblem visibility triggers movement to the third phase, rationalized continua-tion. During this phase, escalation is sustained with the help of rationalizationsfor experienced problems and for why the project cannot be abandoned. Specifi-cally, domain experts provide credible explanations for past troubles and alternativecourses of action are depicted as equally or more problematic. When rationaliza-tions lose their credibility, an imminent threat to project continuation triggers thetransition to deescalation, the outcome of the process, which, in turn, ultimatelyresults in either project termination or redirection.

Antecedent Condition: Project Framing

Project framing concerns the emerging rationale for a project. This includes notonly the arguments or “business case” for the project, but also the view of theproject emerging in the organization prior to and as part of project initiation.

The idea that framing could influence the process of escalation is not new.Prior work (Davis & Bobko, 1986; Whyte, 1986; Rutledge & Harrell, 1993) hassuggested and empirically shown that framing effects (Kahneman & Tversky, 1982)can influence decision making in escalation situations. These studies, however, haveexamined how positive and negative framing of information influences decisionmaking. In our model, we suggest that the concept of framing can be extended toencompass an overall rationale for pursuing a particular course of action. In thissense, the project framing provides a sufficiently compelling argument to justifyembarking on a certain path. This is consistent with what Keil (1995) observedin analyzing the CONFIG case. In that particular case, it was the prior history ofsuccess with another system and the desire to leverage that experience that setthe stage for escalation. How the project is viewed and discussed at the outsetestablishes a framing that shapes subsequent actions and can promote escalation.While the concept of project framing may bear some similarity to Royer’s (2002)idea of collective belief, they are separate and distinct concepts: project framingdoes not imply collective belief about a project’s infallibility.

Drift

In the first phase of the model, drift occurs. The link between drift and escala-tion has not been explicitly described in the prior literature. However, our readingof documented cases of IT project escalation indicates that drift commonly oc-curs in the early stages of projects that ultimately exhibit escalation (Sauer, 1993;Drummond, 1996; Newman & Sabherwal, 1996). Drift is fueled by ambiguityconcerning the project charter and conflict concerning project goal and direction.These two within-phase escalation catalysts are discussed below.

Ambiguity concerning the project charter

Uncertainty and ambiguity are key prerequisites for escalation (Bowen, 1987;Brockner, 1992) and insufficient goal specificity has been shown to further


contribute to escalation (Bragger, Bragger, Hantulaand, & Kirnan, 1998; Bragger,Hantula, Bragger, & Kutcher, 2003). The ambiguity typically inherent in IT projectsmakes them particularly prone to exhibit escalation (Keil & Flatto, 1999). Here, weconnect this ambiguity specifically to the project charter. The project charter is arationale for what the project is to accomplish, why it is important, and how it willbe done. A good project charter includes clear objectives and measurable goals, aswell as important assumptions and constraints to guide the project (Young & Clark,1994). The lack of a clear project charter fuels uncertainty (lack of information),ambiguity (the absence of clarity), and confusion in a project (Whyte & Bytheway,1996) and thus functions as a catalyst for drift. Project charter ambiguity also posesa challenge for requirements analysis and raises the probability of project failure(Kydd, 1989; Marakas & Elam, 1998; Kirsch & Haney, 2006). Failure to managerequirements has also been identified as raising the probability of escalation (Keil,Rai, Mann, & Zhang, 2003). Consequently, in our model, ambiguity concerningthe project charter leads to drift and thus acts as a catalyst for escalation.

Conflict concerning project goal and direction

Earlier work on escalation has pointed out that ambiguity allows for divergentbeliefs about a project and its future and also provides opportunities for politicalmaneuvering (Staw & Ross, 1987), which may lead to conflict. Conflict has beenshown to have a negative impact on IS development outcomes, even when conflictmanagement is ultimately successful (Barki & Hartwick, 2001). While conflict inIS development has long been considered an important problem (Markus, 1983;Robey, Farrow, & Franz, 1989; Bergman, King, & Lyytinen, 2002), we are hereable to specifically connect conflict in IS development to the very early stages ofescalation.

Result (problem emergence)

As drift continues, problems begin to emerge, and the project team and the orga-nization must wrestle with how to respond. We theorize that problem emergenceleads to changes in the interactions and relationship between the project and itsmembers and the actors involved in controlling the project. The nature of thesechanges are likely to be influenced by the location of decision rights and relevantknowledge amongst these actors (Tiwana & Keil, 2007; Tiwana, forthcoming) butwill most likely include inquiries about the causes for problems and demands onproject managers to remedy problems. Responses will also depend on whether acontingency plan has been prepared or not (Barki, Rivard, & Talbot, 1993). Theemergence of problems in the project triggers the next phase.

Unsuccessful Incremental Adaptation

In response to the emerging problems, the organization engages in unsuccessfulincremental adaptation, the next phase of the escalation process. While problemsare acknowledged to exist in this phase, they are generally viewed as being man-ageable and temporary (Staw & Ross, 1987; Keil, 1995). The prevailing wisdomduring this phase is that the problems that have emerged can be addressed withoutmaking major changes to the previously chosen course of action. That problems


are seen as readily surmountable is the first within-phase escalation catalyst duringthis phase. Unfortunately, in escalation situations this proves not to be the case, andrepeated, unsuccessful attempts by stakeholders to address problems can be ob-served. Consequently, the second within-phase escalation catalyst is the continuedmismatch between underlying problems and attempted remedies. The combinationof these two catalysts fuels the escalation process during this phase.

The notion of incremental adaptation is consistent with a broad body of lit-erature dating back to Cyert and March (1963), that focuses on organizationaladaptation in response to environmental uncertainty. It should be noted that incre-mental adaptation to project goals and plans need not in itself be problematic. Infact, incremental adaptation is not uncommon in IS development projects (Truex,Baskerville, & Kelin, 1999; Boehm & Turner, 2005; Ramesh, Cao, Mohan, &Peng, 2006). It becomes problematic only when the scope or nature of the prob-lems facing a project does not lend itself to incremental adaptation—the projectthen experiences unsuccessful incremental adaptation.

Problems are seen as readily surmountable

In the escalation literature, it has been suggested that decision makers are morelikely to engage in escalation when they perceive problems to be temporary andeasily overcome (Staw & Ross, 1987). When this occurs, decision makers are morelikely to engage in incremental adaptation in response to problems.

A fundamental problem for decision makers facing emerging problems is thatescalating IT projects look deceptively similar to “normal” IT projects in this phase.This highlights the emergent nature of the escalation process and is consistent withDrummond (1996), who observed that discrete individual decisions may have anunderlying rationality, while the cumulative effect of these decisions over time leadto escalation.

Continued mismatch between underlying problems and attempted remedies

The innovation literature provides evidence that organizations often fail when theyengage in incremental innovation practices during a period in which more radicalinnovation is required (Christensen, 1997; Benner & Tushman, 2002). In escala-tion theory, the mismatch between actions (attempted remedies) and underlyingproblems is often depicted as an information processing problem (Staw & Ross,1987). This view suggests that individuals facing a complex situation will havebiased perception in favor of information that fits their current interpretations andpreferences, and in favor of positive interpretations of new information (Bouldinget al., 1997). As a consequence, reported problems will be underestimated, correc-tive actions will be ineffective and adaptations to the project will be incremental.In addition to rendering corrective actions ineffective, preventive actions (ProjectManagement Institute, 2000) are less likely to occur. Underestimation of prob-lems may also stem from biased reporting or nonreporting of problems. Biasedreporting can result from the fact that systems developers are prone to introduce apositive bias in project reporting (Snow et al., 2007). Nonreporting of problems,also known as organizational silence or “mum effect,” often takes place as a resultof fears of being punished for bringing bad news about a project (Morrison & Mil-liken, 2000; Keil & Robey, 2001; Keil, Im, & Mahring, 2007). Each of these types


of information processing errors lead to underestimations of the scale and scopeof remedies needed to address problems and thereby contribute to unsuccessfulincremental adaptation.

Result (increased problem visibility)

Toward the end of the unsuccessful incremental adaptation phase, problems in-crease in magnitude and visibility. Through this, pressure mounts to address prob-lems differently; sustainment of unsuccessful incremental adaptation becomes un-tenable. The increased problem visibility triggers the movement to the next phaseof escalation, because there is now a need for decision makers to justify furthercontinuation, for example, by providing elaborate rationalizations for project con-tinuation in order to sustain legitimacy of the project (Brown, 1998).

Rationalized Continuation

In the rationalized continuation phase, recurrent actions serve to explain, or ra-tionalize, why problems are acceptable although they are clearly visible and of amagnitude beyond what organizational norms, procedures, and rules would nor-mally allow (Vaughan, 1996). This means that established procedures, safeguardsand limits must be set aside as a consequence of rationalization. This is in contrastto the previous escalation phase, unsuccessful incremental adaptation, in whichproblems are viewed as manageable.

The rationalized continuation phase of the escalation process is thereforecharacterized by statements and actions that defend the previously chosen course ofaction and reinforce or reinvent the rationale for continuation (Staw & Ross, 1987).In contrast to the previous phase, actors by now go to great lengths to rationalizetheir continued support of a project that is visibly in dire straits. Referring toproblems as temporary no longer suffices. Instead, within-phase escalation catalyststhat help retain the legitimacy of the project and block project redirection becomeprominent: credible explanations are provided for past troubles and alternativecourses of action are depicted as equally or more problematic. These are discussedsubsequently.

Credible explanations are provided for past troubles

In order to retain the credibility and legitimacy of an escalating project that hasreached the rationalized continuation phase, there is a need to explain what hashappened so far in a more positive light as well as to make it credible that pasttroubles have been put behind. This can be understood as an exercise in partiallydecoupling a project’s past from its future: by credibly explaining why thingshave happened a certain way—and explaining how and why project continua-tion will not exhibit the same troubles—project legitimacy can be sustained orresurrected.

The escalation literature provides several partial explanations for these ac-tivities. Staw and Ross (1987) point to norms for staying the course and the heroeffect (organizational values that encourage undertaking challenging turnarounds)as contributing to escalation. Face saving, the sunk cost effect and the propensity toincrease risk-seeking behavior when faced with a certain loss (prospect theory) arealso seen as contributing to escalation by making decision makers more inclined


to downplay (or disregard) past troubles and instead focus on the possibility of aturnaround (Whyte, 1986; Staw & Ross, 1987; Keil et al., 2000a). Reconsiderationof past troubles also bears resemblance to Vaughan’s (1996) identification of theimportance of “normalization of deviance” at NASA that ultimately resulted in the1986 Challenger space shuttle disaster. When problems have persisted for a longtime period, people begin to find explanations for why these problems are not asbad as they seem. In general, we envisage the catalysts of rationalized continuationto be instantiated “as needed” to sustain escalation throughout this phase.

Alternative courses of action are depicted as equally or more problematic

Closely interconnected with explaining that earlier problems have been overcomeis the activity of portraying alternative courses of action as unpalatable. Together,these two activities reinforce the momentum of the project while preventing projectredirection. As a result, escalation is sustained. Through carrying out these actions,decision makers engage in psychological and social justification whereby they seekto persuade themselves and others that there is no better choice but to continue thepreviously chosen course of action in spite of the obstacles.

This behavior is consistent with prior literature that has suggested self-justification as an underlying driver of escalation behavior (Staw, 1976; Brockner,1992). Also, earlier studies have shown that the availability of viable alternativecourses of action lowers perceived sunk cost, thus reducing the propensity to sus-tain a failing course of action (McCain, 1986; Northcraft & Neale, 1986; Keil,Truex, & Mixon, 1995). Consistent with this, studies on deescalation have shownthat the opposite behavior—identification and legitimization of a new course ofaction—is critical to effectuating deescalation (Montealegre & Keil, 2000).

The act of depicting alternative courses of action as undesirable is also inline with the management of impressions: by influencing other people’s percep-tions, social punishments can be avoided or alleviated (Giacalone & Rosenfeld,1989; Leary, 1995). Earlier IS research has shown that impression managementcan be used to help managers save face in the midst of a project fiasco (Iacovou &Dexter, 1996) or to avoid this fiasco by effectuating deescalation in a timely manner(Montealegre & Keil, 2000). Here, we can observe that impression managementcan also fill the purpose of sustaining escalation by alleviating concerns about pasttroubles and decoupling the impression of these troubles from the projected futureof the project. Consequently, an interesting aspect of this phase is that when orga-nizational actors appear to question the current path and consider alternatives, thismight be done at a superficial level. Activities that appear designed to reconsiderthe current course of action may in fact be designed to rationalize why it makessense to press forward.

Result (imminent threat to project continuation)

Rationalized continuation can continue until there is an imminent threat to projectcontinuation. By this we mean a distinct event that jeopardizes or destroys the legiti-macy of the current course of action. The concept of an imminent threat is consistentwith prior escalation literature, which suggests that internal or external shocks candisrupt the escalation process (Ross & Staw, 1993; Keil, 1995; Montealegre & Keil,


2000). Such threats can originate from inside or outside the organization and areof sufficient magnitude to trigger the initiation of the deescalation process.

Outcome: Deescalation

The imminent threat triggers movement toward deescalation, which is the finaloutcome of all escalation processes. By this point, the previously chosen course ofaction has lost legitimacy. Deescalation can thus take the form of either redirec-tion (which may or may not ultimately lead to a successful outcome), or projecttermination (Montealegre & Keil, 2000).

IMPLICATIONS

This study provides a fresh conceptualization of escalation and complements theexisting factor research stream by introducing a process model of escalation that hasimportant implications for both research and practice. As noted previously, little isknown about the actual escalation process, there have been few attempts to buildprocess-oriented models of escalation, and those that do exist are problematic. Priorresearch (Royer, 2002, 2003) has suggested that the escalation process was largelydriven by collective belief. In contrast, we found in the NDS case that escalationdid not result from denial of problems, blind faith, or collective belief about theinfallibility of the project. Thus, in our process model collective belief is not seenas a necessary condition for escalation.

In the NDS case, problems were observed and acknowledged, the projectwas seriously criticized by the most senior executive involved and there were re-current discussions about how to remedy problems. Rather than being driven by acollective belief in infallibility, escalation was characterized by drift, unsuccessfulincremental adaptation, and rationalized continuation. There were many unsuccess-ful attempts to remedy the situation and there was both uncertainty and differencesof opinion about the viability of the project.

Our study, of course, has limitations. A single-case study cannot demonstratethat its results will prove valid across any number of additional cases. However, asLee and Baskerville (2003) point out, theory-informed “rich insight” from single-case analysis constitutes a valid form of generalized knowledge. The results froma case-based research study are not statistical generalizations, but analytical gener-alizations (Yin, 2003). Since our analysis incorporates empirical observations andcontributions from earlier studies, the resulting escalation process model is likelyto apply in other cases, with the minor variations commonly expected for processmodels (Mohr, 1982; Langley, 1999).

Implications for Research

Our contribution is in the development of a grounded escalation process model thatenriches our understanding of how this complex phenomenon unfolds over time.Many insights emerge from our study. First, the model highlights that escalationis a gradual process. Projects do not enter into a state of escalation overnight; theyget there one day at a time. The emergent nature of escalation explains why it maysometimes be difficult to detect and take appropriate action at an early stage.


Second, to understand the process well, we need to go back to the very earlystages of a project and examine closely how it was framed, for the seeds of escalationappear to be sown early. This suggests that more research is needed on the processby which a shared consensus develops (or fails to develop) around both the goal fora project and the approach that will be followed to reach that goal. It is also criticalto expand our knowledge of how a rationale or framing of the project develops andimpacts a project. The relationship between escalation and the process by whichorganizations move from a project charter to a detailed project plan (Shenhar,1998; Keil et al., 2003) may also be a fruitful area for future research, as maythe relationship between escalation and the requirements determination process(Kirsch & Haney, 2006), since escalation may result from a failure to negotiate aspecific set of requirements that all stakeholders can commit to.

Third, while there may be cases in which collective belief plays an importantrole in escalation, this study suggests that collective belief in the infallibility ofa project is not a prerequisite for escalation to occur. More work is needed todetermine the role that collective belief or collective self-efficacy plays in theescalation process (Royer, 2002; Whyte & Fassina, 2007).

Fourth, while it might be tempting to assume that escalation results froma failure to perceive and respond to problems that emerge during a project, ourstudy suggests that organizations do respond to problems when they emerge, butthey may do so ineffectively. Our depiction of the escalation process suggests thata recurrent mismatch between responses to problem symptoms and underlyingproblems contributes to escalation. Our research suggests that the question is not“why don’t organizations respond to problems?” but, rather, “why are organiza-tional responses sometimes repeatedly ineffective in addressing the problems thatemerge during the course of a project?” One reason is that the larger the complexityand uncertainty of a course of action, the higher the risk that responses to problemsymptoms do not match underlying problems. Another reason is that organizationstend to follow a path of “logical incrementalism” (Quinn, 1978), which favors con-tinuation of an escalation process rather than the “radical” responses that wouldbe needed to break escalation. In addition, once a considerable amount of timeor effort has been invested in a given course of action, powerful forces includingthe sunk cost and completion effects (Garland, 1990; Keil et al., 1995; Garland &Conlon, 1998), biased belief updating (Boulding et al., 1997), and the motivationto save face (Staw & Ross, 1987) can result in a rationalization process that favorscontinuation.

Given the role unsuccessful incremental adaptation plays in furthering theescalation process, the importance of employing solid monitoring and control tech-niques cannot be overstated. Several studies have been conducted in the area ofproject control (Kirsch, 1997; Mahring, 2002; Kirsch, 2004; Tiwana & Bush, 2007)and status reporting (Snow & Keil, 2002; Snow et al., 2007; Thompson, Smith, &Iacovou, 2007), but the relationship between control practices and the escalationprocess represents a unexplored, promising area for future research.

It also is of interest to further explore whether the constitution and effective-ness of project governance (Mahring, 2002; Tiwana, forthcoming) is (inversely)related to escalation. For example, does the organization’s ability to adapt con-trol practices to the changing nature of complex projects over time (Kirsch, 2004)


reduce the probability and duration of escalation episodes? Keil et al. (2003) foundthat good project management practices reduce the likelihood of escalation. Itwould seem plausible that effective project governance would have similar effectsand this warrants further study.

Implications for Practice

From a practitioner perspective, we offer a simple and uncomplicated model that canhelp practitioners understand the dynamics of escalation processes. The escalationprocess model provides guidance for when and how to stage interventions that candisrupt escalation.

Looking more closely at each phase of the model, the earliest point at whichmanagers can proactively prevent escalation is in the initial framing of the project.Consistent with the project management literature, this study highlights the impor-tance of establishing a clear project charter before embarking on a project (Deane,Clark, & Young, 1996). Failure to establish a clear charter may contribute to driftdue to a lack of consensus about the ends (i.e., the project’s scope and objectives)and the means of achieving those ends. Therefore, before embarking on any project,senior management should assess the clarity and viability of the project charter notonly from a business perspective, but from a political perspective to insure that allstakeholders are on the same page and have bought into the charter.

While a clear charter is important, it is a relatively high level documentand cannot substitute for a more detailed scope of work and a complete set ofrequirements. To prevent projects from entering into the drift phase, managersshould do everything in their power to insure that the scope of work is clear sothat everyone has a handle on what is inside the project scope and what is outsidethe scope. Similarly, requirements must be specific, documented, understood, andagreed to by all key stakeholders. At the first hint of drift, managers should ensurethat the project team understands both the technical and business environment,and that requirements have been appropriately identified. Such proactive behaviorrequires involved executives to have a broad conception of their role and sufficientdomain knowledge to assess the situation (Mahring, 2002; Tiwana, forthcoming).For projects that involve multiple sites with different requirements, a process ofnegotiation is needed to reach agreement on a manageable set of requirementsthat satisfy the win conditions of the stakeholders involved (Boehm & Ross, 1989;Kirsch & Haney, 2006).

If the project has been drifting for an extended period of time, senior man-agement should be prepared to temporarily halt the project and form a task forceto clarify the project charter and reassess project feasibility. This could be doneeither as a separate effort or by reducing headcount on the project and reshaping theproject itself into a small, highly qualified team charged with this task. With a rede-veloped project charter and a verified “proof of concept,” regular project activitiescan then recommence. Another option is to continue the project but form a taskforce charged with reshaping the project without halting regular project activities.This approach has proved effective for remedying urgent and difficult problems inproduct development projects (Engwall & Svensson, 2001; 2004) and is likely tobe effective also with IT projects.


Once a project progresses to the unsuccessful incremental adaptation phase,escalation is sustained by continued unsuccessful coping with emerging problems.Incremental adaptation by itself is a normal characteristic of most projects, as noproject plan can anticipate all contingencies. The subtlety of intervening effectivelyduring this phase lies in determining whether or not the incremental adaptation isdysfunctional. As mentioned above, being able to detect a pattern of unsuccessfulincremental adaptation is thus an important skill for managers controlling a project.A “problem history” could be maintained that helps managers interpret new prob-lems in light of earlier problem symptoms that might no longer be visible but thatmight help detect a problem pattern.

Additionally, corporate IT governance arrangements that specify actions thatare required whenever a project’s status indicators suggest trouble can help providea basis for detecting problems. For example, project dashboards that convey projectstatus along a number of key dimensions can be used as the basis for discussion atproject review meetings. Traffic light reporting can be used for this purpose. Such asystem is likely work best when there is independent validation and verification ofthe dashboard. Discussion of the project dashboard and the challenges facing theproject is an excellent means of surfacing problems and making certain that seniormanagement is in a position to intervene if a project gets off track. Action items andplans for resolving problems should be recorded and carefully monitored in orderto determine their effectiveness. Projects that repeatedly exhibit a yellow or redstate would trigger more intense discussions and a pattern of recurring problems inthe same area would be indicative of unsuccessful incremental adaptation. At thispoint, it should become clear that more radical measures are needed if the projectis to be successfully turned around.

Once a project has entered into the final phase of escalation—rationalizedcontinuation—there are still actions that managers can take to break the escalationprocess. Managers can detect that they are in this phase when the sponsoringorganization provides excuse after excuse for why the project has experiencedproblems in the past and suggests that plowing forward is the only way to gobecause no other course of action would be acceptable. To counteract rationalizedcontinuation, organizational norms that promote suspicion against new rationalesfor project continuation can be helpful. Similarly, it is important to counteractefforts to reduce information dissemination about project progress as well as effortsto “spin doctor” project reporting or to revise the project history. Steps can also betaken to open the project to scrutiny, for example, by stipulating that new bloodbe brought into the project governance structures on a continual basis. Finally, itis often useful to use outside consultants to assess the project from an externalperspective, although a recent study suggests that for external consultants to beof effective help in breaking escalation, they need to be assigned the specific taskof assessing the case for project continuation or abandonment (Kadous & Sedor,2004).

In addition to within-phase interventions, phase transitions (triggering condi-tions in the model) can be used as opportunities to disrupt escalation because eachone represents a discontinuity in the escalation process, prompting a change inpatterns of action. Arguably, the chances of breaking an escalation process may behigher during shifts from one phase to the next than during the phases themselves


when action patterns are more uniform. Managers can disrupt escalation at thecritical junctures between phases by stressing the severity of identified problemsand criticizing remedies that are likely to lead to unsuccessful incremental adapta-tion or rationalized continuation.

CONCLUSIONS

Given that escalation is a common and costly problem among IT projects (Keilet al., 2000a) and little is known about the process by which it occurs, there isvalue in understanding the phases and events that characterize escalation. Thisstudy represents a contribution to research in that it articulates a model that shedsfurther light on the process by which organizations become bound to a failing courseof action. Our process model suggests that escalation consists of three phases: drift,unsuccessful incremental adaptation, and rationalized continuation. Each phase ofthe model contains within-phase escalation catalysts that further explicate howescalation is fueled within that phase (Figure 4). The phase transition triggers thatprompt changes in patterns of action are: problem emergence, increased problemvisibility, and imminent threat to project continuation. Thus, the model reveals thatescalation is not the result of collective belief or blindly going on; escalation resultsfrom continued unsuccessful coping—from dysfunctional muddling through. Inother words, IT project escalation occurs because actors that exercise influenceover an IT project repeatedly respond to indications of problems in a way that doesnot match the nature and severity of the actual underlying problems (thus failingto resolve problems) and because ongoing project activity in combination with theconstructed and reconstructed rationale for the project propel the project forward(thus preventing termination or redirection).

It is hoped that this new process model will encourage additional researchinto the complex dynamics of escalation processes so that further knowledge can begained concerning how projects go awry and how they might be rescued. [Received:August 2007. Accepted: January.2008]

REFERENCES

Abdel-Hamid, T. K. (1988). Understanding the “90% syndrome” in softwareproject management: A simulation-based case study. The Journal of Systemsand Software, 8, 319–330.

Arkes, H. R. (1991). Costs and benefits of judgment errors: Implications for debi-asing. Psychological Bulletin, 110, 486–498.

Barki, H., & Hartwick, J. (2001). Interpersonal conflict and its management ininformation systems development. MIS Quarterly, 25, 195–228.

Barki, H., Rivard, S., & Talbot, J. (1993). Toward an assessment of software de-velopment risk. Journal of Management Information Systems, 10, 203–225.

Benbasat, I., Goldstein, D. K., & Mead, M. (1987). The case research strategy instudies of information systems. MIS Quarterly, 11, 369–386.


Benner, M. J., & Tushman, M. (2002). Process management and technologicalinnovation: A longitudinal study of the photography and paint industries.Administrative Science Quarterly, 47, 676–706.

Bergman, M., King, J. L., & Lyytinen, K. (2002). Large-scale requirements analysisrevisited: The need for understanding the political ecology of requirementsengineering. Requirements Engineering, 7(3), 152–171.

Boehm, B., & Ross, R. (1989). Theory-W software project management: Principlesand examples. IEEE Transactions on Software Engineering, 15, 902–916.

Boehm, B., & Turner, R. (2005). Management challenges to implementing agileprocesses in traditional development organizations. IEEE Software, 22(5),30–39.

Boulding, W., Morgan, R., & Staelin, R. (1997). Pulling the plug to stop the newproduct drain. Journal of Marketing Research, 34(1), 164–176.

Bowen, M. G. (1987). The escalation phenomenon reconsidered: Decision dilem-mas or decision errors? Academy of Management Review, 12(1), 52–66.

Bragger, J. L., Bragger, D. H., Hantulaand, D. A., & Kirnan, J. P. (1998). Hys-teresis and uncertainty: The effect of information on delays to exit decisions.Organizational Behavior and Human Decision Processes, 74, 229–253.

Bragger, J. D., Hantula, D. A., Bragger, D., & Kutcher, J. K. E. (2003). Whensuccess breeds failure: History, hysteresis, and delayed exit decisions. Journalof Applied Psychology, 88, 6–14.

Brockner, J. (1992). The escalation of commitment to a failing course of action:Toward theoretical progress. Academy of Management Review, 17(1), 39–61.

Brooks, F. P. (1975). The mythical man-month: Essays on software engineering.Reading, MA: Addison-Wesley.

Brown, A. D. (1998). Narrative, politics and legitimacy in an IT implementation.Journal of Management Studies, 35(1), 35–58.

Christensen, C. M. (1997). The innovator’s dilemma: When new technologies causegreat firms to fail. Boston: Harvard Business School Press.

Cule, P. E., & Robey, D. (2004). A dual-motor, constructive process model oforganizational transition. Organization Studies, 25, 229–260.

Cyert, R. M., & March, J. G. (1963). A behavioral theory of the firm. EnglewoodCliffs, NJ: Prentice-Hall.

Davis, M. A., & Bobko, P. (1986). Contextual effects on escalation processes inpublic sector decision making. Organizational Behavior and Human Deci-sion Processes, 37, 121–138.

Deane, R. H., Clark, T. B., & Young, A. P. D. (1996). Linking project outcomesto customer needs. Journal of Information Systems Management, 13, 1–11.

DeMarco, T. (1982). Controlling software projects. New York: Yourdon Press.


Drummond, H. (1996). Escalation in decision-making: The tragedy of Taurus.Oxford, UK: Oxford University Press.

Eisenhardt, K. (1989). Building theories from case study research. Academy ofManagement Review, 14, 532–550.

Elsbach, K. D., & Sutton, R. I. (1992). Acquiring organizational legitimacy throughillegitimate actions: A marriage of institutional and impression managementtheories. Academy of Management Journal, 35, 699–738.

Engwall, M., & Svensson, C. (2001). Forethought: Cheetah teams. Harvard Busi-ness Review, 79(2), 20–21.

Engwall, M., & Svensson, C. (2004). Cheetah teams in product development:The most extreme form of temporary organization? Scandinavian Journal ofManagement, 20, 297–317.

Garland, H. (1990). Throwing good money after bad: The effect of sunk costs on thedecision to escalate commitment to an ongoing project. Journal of AppliedPsychology, 75, 728–731.

Garland, H., & Conlon, D. E. (1998). Too close to quit: The role of project com-pletion in maintaining commitment. Journal of Applied Social Psychology,28, 2025–2048.

Gersick, C. J. G. (1991). Revolutionary change theories: A multilevel explorationof the punctuated equilibrium paradigm. Academy of Management Review,16(1), 10–36.

Giacalone, R. A., & Rosenfeld, P. (1989). Impression management in the organi-zation. Hillsdale, NJ: Erlbaum.

Glick, W. H., Huber, G. P., Miller, C. C., Doty, D. H., & Sutcliffe, K. M. (1990).Studying changes in organizational design and effectiveness: Retrospectiveevent histories and periodic assessments. Organization Science, 1, 293–312.

Golden, B. R. (1997). Further remarks on retrospective accounts in organizationaland strategic management research. Academy of Management Journal, 40,1243–1252.

Henry, R., Kirsch, L., & Sambamurthy, V. (2003). The role of knowledge in in-formation technology project governance. Proceedings of the Twenty-fourthInternational Conference on Information Systems. Seattle, WA: Associationfor Information Systems. December 14–17, 751–758.

Iacovou, C. L., & Dexter, A. S. (1996). Explanations offered by IS managers to ra-tionalize project failures. Unpublished manuscript. Management InformationSystems Division, University of British Columbia, Vancouver, Canada.

Kadous, K., & Sedor, L. M. (2004). The efficacy of third-party consultation inpreventing managerial escalation of commitment: The role of mental repre-sentations. Contemporary Accounting Research, 21(1), 55–82.

Kahneman, D., & Tversky, A. (1982). The psychology of preferences. ScientificAmerican, 246(1), 160–173.


Keil, M. (1995). Pulling the plug: Software project management and the problemof project escalation. MIS Quarterly, 19, 421–447.

Keil, M., & Flatto, J. (1999). Information systems project escalation: A reinterpre-tation based on options theory. Accounting, Management and InformationTechnologies, 9(2), 115–139.

Keil, M., & Montealegre, R. (2000). Cutting your losses: How executives canextricate their organizations when big projects go awry. Sloan ManagementReview, 41(3), 55–68.

Keil, M., & Robey, D. (2001). Blowing the whistle on troubled software projects.Communications of the ACM, 44(4), 87–93.

Keil, M., Truex, D. P., & Mixon, R. (1995). The effects of sunk cost and projectcompletion on information technology project escalation. IEEE Transactionson Engineering Management, 42, 372–381.

Keil, M., Mann, J., & Rai, A. (2000a). Why software projects escalate: An empiricalanalysis and test of four theoretical models. MIS Quarterly, 24, 631–664.

Keil, M., Tan, B. C. Y., Wei, K. K., Saarinen, T., Tuunainen, V., & Wassenaar,A. (2000b). A cross-cultural study on escalation of commitment behavior insoftware projects. MIS Quarterly, 24, 299–325.

Keil, M., Rai, A., Mann, J., & Zhang, G. P. (2003). Why software projects escalate:The importance of project management constructs. IEEE Transactions onEngineering Management, 50, 251–261.

Keil, M., Im, G. P., & Mahring, M. (2007). Reporting bad news on software projects:The effects of culturally constituted views of face-saving. Information Sys-tems Journal, 17(1), 59–87.

Kirsch, L. J. (1996). The management of complex tasks in organizations: Control-ling the systems development process. Organization Science: A Journal ofthe Institute of Management Sciences, 7(1), 1–21.

Kirsch, L. J. (1997). Portfolios of control modes and IS project management.Information Systems Research, 8, 215–239.

Kirsch, L. J. (2004). Deploying common systems globally: The dynamics of con-trol. Information Systems Research, 15, 374–395.

Kirsch, L. J., & Haney, M. H. (2006). Requirements determination for commonsystems: Turning a global vision into a local reality. The Journal of StrategicInformation Systems, 15(2), 79–104.

Kydd, C. T. (1989). Understanding the information content in MIS managementtools. MIS Quarterly, 13, 277–290.

Langley, A. (1999). Strategies for theorizing from process data. Academy of Man-agement Review, 24, 691–710.

Langley, A., & Truax, J. (1994). A process study of new technology adoption insmaller manufacturing firms. Journal of Management Studies, 31, 619–652.

Leary, M. R. (1995). Self-presentation: Impression management and interpersonalbehavior. Madison, WI: Brown & Benchmark.


Lee, A. S. (1989). A scientific methodology for MIS case studies. MIS Quarterly,13, 33–50.

Lee, A. S., & Baskerville, R. L. (2003). Generalizing generalizability in informationsystems research. Information Systems Research, 14, 221–243.

Mahring, M. (2002). IT project governance. Stockholm, Sweden: Economic Re-search Institute (EFI), Stockholm School of Economics.

Mahring, M., Holmstrom, J., Keil, M., & Montealegre, R. (2004). Trojan actor-networks and swift translation: Bringing actor-network theory to IT projectescalation studies. Information Technology & People, 17, 210–238.

Marakas, G. M., & Elam, J. J. (1998). Semantic structuring in analyst acquisitionand representation of facts in requirements analysis. Information SystemsResearch, 9, 37–63.

Markus, M. L. (1983). Power, politics, and MIS implementation. Communicationsof the ACM, 26(6), 430–444.

Mason, R. O., McKenney, J. L., & Copeland, D. G. (1997). An historical methodfor MIS research: Steps and assumptions. MIS Quarterly, 21, 307–320.

McCain, B. E. (1986). Continuing investment under conditions of failure: A lab-oratory study of the limits to escalation. Journal of Applied Psychology, 71,280–284.

Mohr, L. B. (1982). Explaining organizational behavior. San Francisco: Jossey-Bass.

Montealegre, R., & Keil, M. (2000). De-escalating information technologyprojects: Lessons from the Denver international airport. MIS Quarterly, 24,417–447.

Morrison, E. W., & Milliken, F. J. (2000). Organizational silence: A barrier tochange and development in a pluralistic world. Academy of ManagementReview, 25, 706–725.

Newman, M., & Robey, D. (1992). A social process model of user-analyst rela-tionships. MIS Quarterly, 16, 249–266.

Newman, M., & Sabherwal, R. (1996). Determinants of commitment to informationsystems development: A longitudinal investigation. MIS Quarterly, 20, 23–54.

Northcraft, G. B., & Neale, M. A. (1986). Opportunity costs and the framing ofresource allocation decisions. Organizational Behavior and Human DecisionProcesses, 37, 348–356.

Orton, J. D. (1997). From inductive to iterative grounded theory: Zipping the gapbetween process theory and process data. Scandinavian Journal of Manage-ment, 13, 419–438.

Pan, G. S. C., Pan, S. L., & Flynn, D. J. (2004). De-escalation of commitmentto information systems projects: A process perspective. Journal of StrategicInformation Systems, 13, 247–270.


Pan, G., Pan, S. L., Newman, M., & Flynn, D. (2006). Escalation and de-escalationof commitment: A commitment transformation analysis of an e-governmentproject. Information Systems Journal, 16, 3–21.

Pentland, B. T. (1999). Building process theory with narrative: From descriptionto explanation. Academy of Management Review, 24, 711–724.

Project Management Institute. (2000). A guide to the project management body ofknowledge. Newtown Square, PA: Author.

Quinn, J. B. (1978). Strategic change: “Logical incrementalism.” Sloan Manage-ment Review, 20(1), 7–21.

Ramesh, B., Cao, L. A. N., Mohan, K., & Peng, X. U. (2006). Can distributedsoftware development be agile? Communications of the ACM, 49(10), 41–46.

Robey, D., Farrow, D. L., & Franz, C. R. (1989). Group process and conflict insystem development. Management Science, 35, 1172–1191.

Ross, J., & Staw, B. M. (1986). Expo86: An escalation prototype. AdministrativeScience Quarterly, 31, 274–297.

Ross, J., & Staw, B. M. (1993). Organizational escalation and exit: Lessons fromthe Shoreham nuclear power plant. Academy of Management Journal, 36,701–732.

Royer, I. (2002). Escalation in organizations: The role of collective belief. Paperpresented at the Academy of Management Annual Meeting. Denver, Col-orado. August 9–14.

Royer, I. (2003). Why bad projects are so hard to kill. Harvard Business Review,81(2), 48–56.

Rutledge, R. W., & Harrell, A. (1993). Escalating commitment to an ongoingproject: The effects of responsibility and framing of accounting information.International Journal of Management, 10, 300–314.

Sauer, C. (1993). Why information systems fail: A case study approach. Henley-on-Thames, UK: Waller.

Schmidt, J. B., & Calantone, R. J. (2002). Escalation of commitment during newproduct development. Journal of the Academy of Marketing Science, 30,103–118.

Shenhar, A. J. (1998). From theory to practice: Toward a typology of project-management styles. IEEE Transactions on Engineering Management, 45,33–48.

Snow, A. P., & Keil, M. (2002). The challenge of accurate software project statusreporting: A two-stage model incorporating status errors and reporting bias.IEEE Transactions on Engineering Management, 49, 491–504.

Snow, A. P., Keil, M., & Wallace, L. (2007). The effects of optimistic and pes-simistic biasing on software project status reporting. Information & Man-agement, 44(2), 130–141.


Staw, B. M. (1976). Knee-deep in the big muddy: A study of escalating com-mitment to a chosen course of action. Organizational Behavior and HumanPerformance, 16, 27–44.

Staw, B. M. (1997). Escalation of commitment: An update and appraisal. In Z.Shapira (Ed.), Organizational decision making. Cambridge, UK: CambridgeUniversity Press, 191–215.

Staw, B. M., & Ross, J. (1987). Behavior in escalation situations: Antecedents,prototypes, and solutions. In B. M. Staw & L. L. Cummings (Eds.), Researchin organizational behavior. Greenwich, CT: JAI Press, 39–78.

Thompson, R. L., Smith, H. J., & Iacovou, C. L. (2007). The linkage betweenreporting quality and performance in IS projects. Information & Management,44, 196–205.

Tiwana, A. (forthcoming). Governance-knowledge fit in systems developmentprojects. Information Systems Research.

Tiwana, A., & Bush, A. A. (2007). A comparison of transaction cost, agency, andknowledge-based predictors of IT outsourcing decisions: A U.S.-Japan cross-cultural field study. Journal of Management Information Systems, 24(1), 259–300.

Tiwana, A., & Keil, M. (2007). Does peripheral knowledge complement control?An empirical test in technology outsourcing alliances. Strategic ManagementJournal, 28, 623–634.

Truex, D. P., Baskerville, R., & Kelin, H. (1999). Growing systems in emergentorganizations. Communications of the ACM, 42(8), 117–123.

Tushman, M. L., & Romanelli, E. (1985). Organizational evolution: A metamor-phosis model of convergence and reorientation. In B. M. Staw & L. L.Cummings (Eds.), Research in organizational behavior. Greenwich, CT: JAIPress, 171–222.

Van de Ven, A. H., & Poole, M. S. (1995). Explaining development and change inorganizations. Academy of Management Review, 20, 510–540.

Van de Ven, A. H., Polley, D. E., Garud, R., & Venkataraman, S. (1999). Theinnovation journey. New York: Oxford University Press.

Vaughan, D. (1996). The Challenger launch decision: Risky technology, cultureand deviance at NASA. Chicago: University of Chicago Press.

Whyte, G. (1986). Escalating commitment to a course of action: A reinterpretation.Academy of Management Review, 11, 311–321.

Whyte, G., & Bytheway, A. (1996). Factors affecting information systems’ success.International Journal of Service Industry Management, 7(1), 74–93.

Whyte, G., & Fassina, N. E. (2007). Escalating commitment in group decision mak-ing. Proceedings of the Academy of Management. Philadelphia: Academy ofManagement. August 3–8, 1–6.

Yin, R. K. (2003). Case study research: Design and methods (3rd ed.). ThousandOaks, CA: Sage.


Young, A. P., & Clark, T. B. (1994). Project management: A practical approachto successful project performance. Stone Mountain, GA: Young, Clark &Associates

Zmud, R. W. (1980). Management of large software efforts. MIS Quarterly, 4,45–55.

Magnus Mahring, PhD, is an assistant professor in the department of marketingand strategy, Stockholm School of Economics and associated researcher at theInstitute of Business Process Development. During 2002–2003, he was a visitingresearch scholar at the computer information systems department at the Centerfor Process Innovation, Georgia State University. His current research focuses ongovernance of large IT projects, project escalation, and deescalation processes,executive and board involvement in IT, and the dynamics and limitations of orga-nizational control. He has coedited two books and has published in InformationTechnology & People, Information Systems Journal, and Communications of theACM (in press). He has extensive teaching and consulting experience and hasconsulted with organizations including Bang & Olufsen, Microsoft, ScandinavianAirlines Systems, Svenska Handelsbanken, The Swedish Red Cross, and municipalpublic organizations. He also serves on the jury for the Swedish CIO Awards.

Mark Keil is the Board of Advisors Professor of Computer Information Systemsin the J. Mack Robinson College of Business at Georgia State University. Heholds a joint appointment in the department of computer science. His research hasbeen published in MIS Quarterly, Journal of Management Information Systems,IEEE Transactions on Engineering Management, Sloan Management Review, andmany other journals. He currently serves on the editorial boards of the Journal ofManagement Information Systems and Decision Sciences. He has also served as anassociate editor for MIS Quarterly, as co-editor of The DATA BASE for Advances inInformation Systems, and as a member of the editorial board of IEEE Transactionson Engineering Management. He earned his bachelor’s degree from PrincetonUniversity, his master’s degree from MIT’s Sloan School of Management, and hisdoctorate in management information systems from the Harvard Business School.

Documents

Information Technology Project Escalation: A Process Model