Pulling the Plug: Software Project Management and the ... · study of IT project escalation is discussed and analyzed. The results suggest that escalation is promoted by a combination

Software Project Escalation

Pulling the Plug:Software ProjectManagement and theProblem of ProjectEscalationI

By: Mark KeilDepartment of Computer Information

SystemsCollege of Business AdministrationGeorgia State UniversityP.O. Box 4015Atlanta, GA [email protected]

Abstract

Information technology (IT) projects can fail forany number of reasons and in some cases canresult in considerable financial losses for theorganizations that undertake them. One patternof failure that has been observed but seldomstudied is the IT project that seems to take on alife of its own, continuing to absorb valuableresources without reaching its objective. A sig-nificant number of these projects will ultimatelyfail, potentially weakening a firm’s competitiveposition while siphoning off resources thatcould be spent developing and implementingsuccessful systems. The escalation titeratureprovides a promising theoretical base forexplaining this type of IT failure. Using a modelof escalation based on the fiterature, a casestudy of IT project escalation is discussed andanalyzed. The results suggest that escalation ispromoted by a combination of project, psycho-logical social and organizational factors. Themanagerial implications of these findings arediscussed along with prescriptions for how toavoid the problem of escalation.

Keywords: Software project management, ISfailure, escalation, escalating commitment,implementation

ISRL Categories: EE, EE06, EE0101, EE0504,EL0201, EL0202

Some projects never seem to termi-nate... "rather, they become like Moses, con-demned to wander till the end of their dayswithout seeing the promised land."

-- Stephen P. Keider (1974)

Introduction

By 1994, annual U.S. spending on the develop-ment of information technology (IT) applicationsreached $250 billion (Johnson, 1995). Thestrategic importance that IT now plays, coupledwith the burgeoning costs of developing sys-tems, has raised the stakes associated withproject failure. Despite the costs involved, pressreports suggest that such failures occur withalarming frequency (Betts, 1992; Cringely,1994; Ellis, 1994; Gibbs, 1994; Kindel, 1992;Kull, 1986; McPartlin, 1992; Mehler, 1991;Neumann and Hoffman, 1988; Rothfeder,1988). While it is difficult to obtain statistics onthe actual frequency of IT failures, varioussources suggest that at least half of all IT pro-jects are not as successful as we would likethem to be (Gladden, 1982; Lyytinen andHirschheim, 1987).

While there are undoubtedly many differentmodes of IT failure, one pattern of failure thathas been observed but seldom studied is the ITproject that seems to "take on a life of its own,"continuing to absorb valuable resources withoutever reaching its objective (Keider, 1974;Lyytinen and Hirschheim, 1987; Meredith,1988). Eventually, these projects are aban-doned (or significantly redirected), but the costof having funded them can represent a tremen-dous waste of organizational resources. Whyare troubled projects allowed to continue for solong before they are ultimately abandoned orbrought under control?

MIS Quarterly/December 1995 421


Traditional wisdom holds that information sys-tems projects get "out of control" because ofpoor project management practice~. It would behard to argue otherwise. But what is meant by"poor project management?" This phrase hasbecome a dumping ground for explanations ofIT failure that range from a chronic tendency tounderestimate the cost or scope of an IT project(Boehm, 1981; Brooks, 1975; Kemerer, 1987)to failure in managing the risks associated withIT projects (Alter and Ginzberg, 1978;Ginzberg, 1981; McFarlan, 1981). While thereis merit behind these traditional views, they donot explain why projects that get out of controlseem to stay that way.

Many IT projects that seem to take on a life oftheir own represent what can be described asescalation. Escalation has been defined as contin-ued commitment in the face of negative informa-tion about prior resource allocations coupled with"uncertainty surrounding the likelihood of goalattainment" (Brockner, 1992). Project escalationcan therefore be said to occur wheh there is con-tinued commitment and negative information.2

In order to both explain this phenomenon andprevent its occurrence, it is necessary to lookbeyond traditional explanations of poor projectmanagement and to consider possible psycho-logical, social, and organizational factors thatmay promote project escalation.

Background

One of the most difficult management issuesthat can arise in connection with. iT projects is

deciding whether to abandon or continue a pro-ject that is in trouble. Unfortunately, there isvery little information available on the subject ofIT project abandonment. One study found that35 percent of these projects were not aban-doned until the implementation stage of the lifecycle (Ewusi-Mensah and Przasnyski, 1991).This suggests that IT managers are doing apoor job of identifying or terminating projectsthat are likely to fail. While there may be sever-al reasons why such a high fraction of aban-doned projects are not terminated earlier in thelife cycle, one explanation may be that man-agers have a natural tendency toward escala-tion or continued commitment to a failingcourse of action (Brockner, 1992).

Factors that can promote escalation

Previous research suggests that escalation is acomplex phenomenon that may be influencedby many different factors. Based on a review ofthe literature, Staw and Ross (1987a) provide useful taxonomy that groups these factors intofour categories: project factors, psychologicalfactors, social factors, and organizational fac-tors. 3 Using this typology as a basis, Figure 1represents a model of project escalation.

Project factors are the objective features of theproject itself and how it is perceived by man-agement (Ross and Staw, 1993). These factorsinclude the costs and benefits associated withthe project as well as the expected difficulty andduration of the project. Other things beingequal, projects are more prone to escalationwhen they involve a large potential payoff,when they are viewed as requiring a long-term

Project Factors

IPsychological Factors

Social Factors

I0 rganizational Factors

ProjectEscalation

Figure 1. Model of Project Escalation

422 MIS Quarter/y/December 1995


investment in order to receive any substantialgain, and when setbacks are perceived as tem-porary problems that can be overcome.

Psychological factors are those that causemanagers to convince themselves that thingsdo not look so bad and that continuation willeventually lead to success (Brockner, 1992).These factors include the manager’s previousexperience with similar projects, the degree towhich the manager feels personally responsi-ble for the outcome of the project, as well aspsychological and cognitive biases that canaffect the way in which information concerningthe project is perceived or processed. Projectsare more prone to escalation when there is aprevious history of success and when there isa high level of personal responsibility.

Escalation is also more likely to occur whenmanagers make errors in processing informa-tion. Previous research shows, for example,that human decision making is subject tonumerous biases, many of which operate at asubconscious level (Kahneman and Tversky,1982). One such bias can lead to "throwinggood money after bad" in an effort to turnaround a failing project (Garland, 1990). Priorresearch also suggests that managers mayengage in a type of self-justification behavior inwhich they commit additional resources inorder to turn a project around rather than termi-nating the project and admitting that their earli-er decisions were incorrect. Self-justificationcan lead managers to "bias facts in the direc-tion of previously accepted beliefs and prefer-ences," resulting in project escalation (Rossand Staw, 1993, p. 716).

Social factors can also promote escalation.These factors include competitive rivalry withother social groups, the need for external justi-fication, and norms for consistency (Ross andStaw, 1993). Projects are more prone to esca-lation when competitive rivalry exists betweenthe decision-making group and another socialgroup, when external stakeholders have beenled to believe that the project is (or will be) suc-cessful, and when norms of behavior favor"staying the course."

Finally, organizational factors involve the struc-tural and political environment surrounding a

project. These factors include political supportfor the project and the degree to which the pro-ject becomes institutionalized with the goals andvalues of the organization. Projects are moreprone to escalation when there is strong politicalsupport at the senior management level andwhen the project has become institutionalized.

Prior research on escalation

Prior research on escalation has been basedalmost exclusively on laboratory experimentsthat have focused on individual decision mak-ing. While these studies have generated usefulinformation concerning factors that may pro-mote or impede escalation at an individuallevel, there is a growing recognition of the needfor more field-based studies that capture theorganizational dynamics of the phenomenon(Garland, et al., 1990; Ross and Staw, 1993).To date, there have been only a handful offield-based studies of escalation (Newman andSabherwal, 1994; Ross and Staw, 1986; 1993).For these reasons, this research focuses onthree research questions: (1)Does escalation.occur in actual IT projects? (2)What are thefactors that seem to promote escalation? and(3) What are the course of events that canbreak a cycle of escalation?

Methods

Since the objectives of this research were todetermine whether the escalation phenomenoncould be observed in an actual IT project and,if so, to understand more about the reasonswhy it occurs, this research employed a longi-tudinal case study approach. Given theexploratory nature of the research, an in-depthcase study of a single project named CONFIG"was conducted in a company calledCompuSys.5

Three different kinds of data were collected:interview data (obtained from talking withusers, developers, and managers), observa-tions (recorded from meetings that took placeinvolving users, developers, and managers),



Table 1. Scope of the Research

Number of Interviews Conducted6 197Number of Individuals Interviewed 111Number of Meetings Observed7 19Number of Documents collected8 > 350

and historical documents (in the form of meet-ing minutes, memos, and reports concerningCONFIG). Table 1 gives some indication of the

scope of the research.

Table 2 provides an indication of the numberof individuals who were interviewed by jobfunction.

Figure 2 presents a schematic diagram of the

research design, showing the chronology of theCONFIG project, along with separate timelinesshowing when various types of data were gen-erated or collected in relation to the history ofthe project.

Appendix B provides additional information onthe methodology and discusses some of thelimitations associated with the approach takenin this study.9

Table 2. Number of Individuals InterviewedBy Job Function

Job FunctionSales RepresentativeSales ManagerDeveloperDevelopment ManagerUser/developer LiaisonSenior ManagersOtherTOTAL

#48

767

2O8

15111

A Brief History of the CONFIGProject and Why It Failed

In the early 1980s, CompuSys, a large comput-er company, began developing an expert sys-tem called CONFIG. CONFIG was designed tohelp the company’s sales representatives pro-duce error-free configurations prior to pricequoting. The system was intended to reducecostly "allowances" in which the company hadto supply hardware without charge to customerswhen price quotations were found to have beenbased on inaccurate product specifications. Inaddition to the tangible costs associated with"allowances," configuration errors caused sev-eral more significant, but less tangible, prob-

1CONFIG

X X X X --X.X ....... -X

I CONFIGProjectBegins

1980 1981 1982 1983 1984 1985 1986I1987

Time

Project isTerminated

1988 1989 1990 1991 1992 1993 1994

LEGEND

x User design team meeting minutes (13 in total)

[] Face-to-face interviews (173 in total)and on-site observation

["-] Telephone interviews (24 in total)

Figure 2. Schematic Diagram of the Research Design

424 MIS Quarterly~December 1995


lems for CompuSys. These problems includeddelays in the order fulfillment process and dis-gruntled customers who threatened the reputa-tion of the company.

From the very beginning, the CONFIG projectfaced serious challenges including a lack ofsponsorship within the Sales organization,problems of software accuracy and perfor-mance, and an unrealistic project schedule.Later, many implementation difficulties wereexperienced as the system was deployed withinthe Sales organization. As a result, very fewsales representatives actually used the system.While numerous attempts were made toimprove the system, the level of usage amongsales representatives remained disappointinglylow. Nevertheless, the CONFIG project wasfunded for a period of more than a decade dur-ing which it was continually adapted andrefined, resulting in a series of redeploymentsto the field. During this period, both the size andcomposition of the project team varied, but thecommitment to the project was unwavering.The last major effort to adapt and redeployCONFIG took place during 1989-1990. Despitea long and troubled history, the CONFIG projectwas continually funded until the end of 1992when financial support was withdrawn and allfurther development and support for the projectwas terminated. A brief description of the pro-ject’s history and why it failed is providedbelow.

The business problem and theorigins of CONFIG

Throughout its history, CompuSys had prideditself on the almost limitless number of differentconfigurations it offered to customers. Thisrequired putting together, or configuring, agroup of components that were compatible withone another and that, when combined, wouldresult in a complete and functioning system forthe customer. By the 1970s, the growing sizeand complexity of CompuSys’ product linemade it increasingly difficult to insure that sys-tems were properly configured when they leftthe factory. Despite manual efforts to verify thatall the necessary components were present,

incorrectly configured systems would frequentlybe shipped to the customer.

In 1975, CompuSys established a task force tostudy the problem and develop better solutionsfor verifying system configurations before ship-ping the goods. In 1978, CompuSys funded thedevelopment of an expert system known asVERIFIER that would be capable of verifyingand correcting system configurations. As VERI-FIER moved through the proof of conceptstage, Tom Jones, who later became managerof the company’s Artificial IntelligenceTechnology Center, was recognized as itschampion. During the early 1980s, Jonesrecruited a growing number of individuals tohelp develop and maintain VERIFIER and toexplore other business applications of expertsystems. One of the key individuals he broughtinto the group was George Smith, who wasappointed program manager for VERIFIER in1982 and was heavily involved in managing itstransition from a prototype into an evolving pro-duction system.

By the early 1980s, VERIFIER was in produc-tion use and reportedly saving the companymillions of dollars per year, with performancethat exceeded some of the company’s besthuman configurers. As a result of both this pro-ject and his previous contributions, Jones hadsecured a high level of status and respect with-in CompuSys. Having gained some confidencein building VERIFIER, Jones and his group ofmanagers and developers began to search forother opportunities where they could apply thetechnology. As shown in Figure 3, this was thebeginning of a cascading sequence of eventsthat set the stage for project failure in the caseof CONFIG.

Prior history of success promptsdevelopment of CONFIG

The very success of VERIFIER, which wasdeveloped and funded by the Manufacturingorganization, led to the realization that the con-figuration problem originated in the sales officesand that, while VERIFIER helped Manufactur-ing, it did nothing to assist Sales.~o With this



IPrior history of success with VERIFIER

Confidenceon the part ofthe developers

Developers’ limitedunderstandingof the sales process

Unrepresentativesales reps providinginput to developers

Desire to leverage Iinvestment in Verifleds Iknowledge base

Design concept of CONFIGas a standalone support toolfor sales reps

Lack of organizational ~ System that fails to gainincentives to use CONFIG

Realization thatconfiguration errorsoriginate in sales

I

Sales repe not inposition to drivedevelopment process

Stovepipe organization;lack of cross-functionalcoordination

~~_~Belief by Sales organizationthat configuration errors are anon-problem

acceptance among salesreps

Figure 3. Events That Set the Stage for Project Failure in the Case of CONFIG

realization, the idea for CONFIG was born.Unlike VERIFIER, which was a batch-orientedtool used by Manufacturing for configuration val-idation, CONFIG was to be an interactive toolthat would aid sales representatives in creatingand validating configurations prior to quotation.

By 1981, the group that developed VERIFIERhad begun funding the initial prototype of CON-FIG. The CONFIG program manager formed a"user design team" (UDT) composed of about dozen representatives from the Sales organiza-tion. This group typically met twice annually withthe developers; its charter was to’ provide guid-ance and feedback as additional features andfunctions were added to the evolving prototype.The UDT met with the developers on 13 occa-sions between November 1981, and August1988, when the group ceased to meet regularly.

Initially, there were only a few de’velopers whowere assigned to work on CONFIG, but theresources devoted to the project increased sub-stantially during the 1980s.11 Although the com-position of the project team assigned to CONFIGchanged over time, both Jones and Smith main-

tained a high level of involvement.12 The develop-ment activity was funded primarily out ofManufacturing, where the group was housed untilthe late 1980s. Figure 4 represents a partial orga-nization chart for CompuSys, showing the struc-ture as it existed in 1990 and some of the individ-uals who were interviewed as part of this study.

A flawed design concept

CONFIG’s original design concept called for astandalone support tool for sales representa-tives. As the project unfolded, the need for inte-gration between CONFIG and the company’squoting system became increasingly apparent,and the standalone design concept proved tobe fatally flawed. Ironically, at the same timethat the CONFIG project was getting underway,another group of developers that was moreclosely aligned with the Sales organization wasjust beginning to develop a new computerizedprice quotation system (PQS).



Strategic Resources

Info. Mgrn~. &Technology

President J

Executive Committee

I

v.P. I M’~" IU.So Manufacturing US. Sales Administration

Engineedng, Technclogy, I

Tom Jones, ManagerAdificial IntelligenceTechnology Center

[ Configuration Systems

IDevelopment Group

Architectures & Know~edge Engineedng Tools & Integration Quality AssuranceAdvanced Technology Enginoodng

Note: The Configuration Systems Devefopment Group (CSDG) included other functions (not shown here) such as: businessplanning, finance, personnel, program management, new product management, and Information management. As of 1990the total CSDG headcount was approximately 115.

Legend

interviewed for this study interviewed for this study

Figure 4. Partial Organization Chart for CompuSys, 1990

While the connection between the configurationprocess and the price quotation process seemsobvious now, at the time, these two systems werebeing developed and managed as entirely sepa-rate processes. This was largely due to a compa-ny culture that promoted the creation of"stovepipe organizations," resulting in a lack ofcross-functional coordination. As a result, twostandalone systems that did not talk to oneanother were created--one for generating config-urations and one for generating price quotations.

The basic design concept of CONFIG--as astandalone support tool for sales representa-tives-emerged and remained intact for severalreasons. First, because the development groupresided in Manufacturing, they had a limitedunderstanding of the sales function. Their modelof the sales process was one in which configur-

ing and quoting were seen as two separateprocesses (Keil, et al., 1995a; Markus and Keil,1994); this model led them to believe that it wasnot necessary to have accurate price informa-tion during the configuration process. The salesforce did not operate this way, however; mostrepresentatives found that pricing informationoften drove the configuration process. Thus, itwas necessary to work back and forth betweenthe system’s technical configuration and whatthe customer was willing to pay.

As early as 1982, some of the more vocal salesrepresentatives on the UDT had begun to arguethat CONFIG and PQS had to be in.tegrated.The developers, however, contended that thiswould be too challenging technically and madeintegration a "non-goal" for CONFIG’s firstrelease. Since the UDT served only in an advi-

MIS Quarter/y/December 1995 427


sory capacity, the sales representatives werenot in a position to drive the developmentprocess. Consequently, the integration of CON-FIG and PQS remained a low priority until 1984when it became more obvious that there wouldhave to be at least some level of integrationbetween these two systems.

By that time, however, the composition of theUDT had shifted and the group was no longerrepresentative of the salesforce at large; asmore novice sales representatives lost interestin the process and left the group, the UDT hadbecome dominated by a relatively small numberof experienced, technically oriented sales rep-resentatives. As a group, they tended to bemore forgiving of the software and were willingto compromise on such items as "ease of use"in exchange for a system that was accurate andfunctional. Rather than arguing for completeintegration between CONFIG and PQS, theUDT was willing to settle for a non-interactiveone-way linkage. The establishment of such acrude linkage was predicated on a model of thesales process in which CONFIG was still seenas a viable standalone system so long as itsoutput could be passed on to PQS.

While this linkage was made operational in1985, it was not enough to drive significantusage of CONFIG. In fact, those who used thesystem found it more time consuming to pro-duce price quotes than those who did not. Inthe words of one sales representative:

When you get done with CONFIG and want toprint a quote, you create a file, transfer a file,you go into PQS, you import it. It’s very cum-bersome. The turnaround time is way too long,so I’ve started not to use the system [CONFIG]because when I need to do a quote, generallythe customer is waiting. They’ve asked forsomething, and you can’t wait a day or two toget stuff back.

System fails to gain acceptanceamong sales reps

In addition to the fact that the tool was basedon a flawed design concept, there were otherreasons why CONFIG failed to gain acceptance

among sales representatives. One reason wasa lack of organizational incentives to use CON-FIG. Quite simply, sales reps were not motivat-ed to produce error-free configurations; theywere rewarded on the basis of sales volume,not configuration accuracy. In the words of onesales rep:

It’s not that anyonewants to be inaccurate andmake a lot of errors, it’s just not something weare measured on, and we will work towardwhat we are measured on.

A sales manager who was asked to explainhow reps’ performance was evaluated said:

You won’t see anything [in the performanceappraisal form] about quote accuracy. I’m notmanaged, nor is my manager managed, to"dirty" orders. So it doesn’t really matter. It’snot one of my metrics. It’s not a critical suc-cess factor for me or for the sales reps. Thereare no kudos if they get it right, no scolding ifthey get it wrong.

Under this type of reward system, the costsassociated with inaccurate configurations werenever factored into the sales reps’ compensa-tion. Therefore, most of the people in sales(from district managers on down) thought thatthe configuration error problem was too minorto justify the effort of using CONFIG (Markusand Keil, 1994):

We never miss the big stuff... CPU, etc ....only cables. Who cares about a $50 cable? It’snot worth the time it takes to run it throughCONFIG. Ninety percent of the time, the cus-tomer will authorize a modification anyway.

Was CONFIG an Example ofProject Escalation?

As stated before, escalation can be defined ascontinued commitment of resources in the faceof negative information (Brockner, 1992). order to investigate whether these conditionsactually existed, a detailed chronology of theproject was reconstructed using the UDT meet-ing minutes and, in some cases, actual tran-scripts of UDT meetings as a foundation. The13 UDT meetings that took place during the life



of the project, along with the decisions to initi-ate and terminate the project, were chosen asnatural decision points for analysis.13 Wherepossible, the information from the UDT meetingminutes was supplemented by examination ofagenda items, priority lists, and presentationslides associated with each meeting. Interviewand historical data were then used to recon-struct events that occurred between UDT meet-ings. The resulting chronology was then validat-ed by several individuals who were familiar withthe project’s history.

Using this chronology of events, two indepen-dent raters were then asked to assess the char-acter of the information that was available todecision makers during the course of the CON-FIG project. Based on their assessment, projectinformation was coded as positive, negative, orambiguous. Excerpts of the project’s chronolo-gy and the raters’ coding of project informationcan be found in Appendix A.14 As shown inFigure 5, the CONFIG project continued for aperiod of more than a decade despite the factthat information concerning the project was pre-dominantly negative during this period of time.Therefore, the CONFIG project satisfies thedefinition of project escalation.

Objective usage data as well as the subjectiveopinions of individuals closely associated withthe project offer confirmatory evidence of esca-

lation. Figure 6, which shows CONFIG usageas a percent of system quotations, reveals apattern of declining use during the last severalyears of the project’s history.Is

The fact that CONFIG was used for a verysmall percentage of system quotations and thatits usage declined steadily during a four-yearperiod represents significant negative informa-tion concerning the project. This informationwas readily available to decision makers withinthe company.

Qualitative interview data gathered during 1990provides additional evidence. As one managerobserved: "1 think the thing may have taken ona life of its own." By 1990, many sales repre-sentatives who were interviewed expressed abelief that the CONFIG project should be aban-doned. The following remarks were typical:

Based on the usage patterns, I don’t think any-body would miss [CONFIG] very much if weturned it off tomorrow.

If [CompuSys] has spent millions on this productwe have really missed [the boat]. [We should]pull the plug on this effort immediately.

The people responsible for developing [CONFIG]are trying to breathe life into something thatshould be allowed to die... We have proof todaythat [CONFIG] is not successful. It has failed mis-erably. The problem is nobody is willing to kill it.

Negative

1980 1981

2 3 4 5 6 "/ 8 9 I0

1982 1983 1984 1985 1986 1987 1988 1989 1990

Time

Figure 5. Mapping CONFIG Project Informationls

14(project termination)

1991 1992 1993



Percent

2.5

t.5

0.5

Time (Fiscal Quarters)

Figure 6. CONFIG Usage as a Percent of System Quotations

Given what appears to be such a clear patternof negative information one would have expect-ed the project to be terminated or redirectedmuch earlier than 1992, the year in which theproject was finally halted. How, then, can theescalation that occurred be explained?

continued investment could produce a largepayoff, (2) the project was regarded as investment in research and development, and(3) project setbacks appeared to be temporaryproblems.

Discussion of Factors ThatPromoted Escalation

As suggested by the model presented earlier(see Figure 1), there were four different types factors that seemed to contribute to the escala-tion of the CONFIG project: project factors, psy-chological factors, social factors, and organiza-tional factors.

Project factors

Some factors associated with the characteris-tics of the project and how it was viewed bymanagement were: (1) there was evidence that

Evidence That Continued Investment CouldProduce Large Payoff

Three separate financial analyses of the CON-FIG project conducted in 1982, 1985, and againin 1987 provided evidence that a successfullydeveloped and deployed system could haveyielded a positive and significant net presentvalue for the company.

The 1982 analysis indicated a net present valueof $43.9 million (20 percent discount factor) forthe five-year period FY82-FY86. Operating anddevelopment costs for the project were project-ed at $10.4 million between FY82 and FY86. Asecond financial analysis conducted in 1985projected a net present value of $55.7 million(20 percent discount factor) for the five-year



period FY85-FY89. A third financial analysisconducted in 1987 indicated a net present valueof at least $41.1 million (20 percent discountfactor) for the five-year period FY87-FY91.

in each of the analyses, it was argued thatunder virtually all scenarios, CONFIG had avery large potential value. Since all three finan-cial analyses revealed a positive and significantNPV, the potential payoff associated with suc-cessful completion of the project may haveserved as a strong justification for continuation.It is important to note that there were otherintangible benefits that were thought to beattainable as well and that these may have hadan effect on escalation that was equal orgreater than the tangible economic benefits thatco, uld be obtained.

Project Regarded as an Investment inResearch and Development

Within CompuSys, there was a strong beliefthat artificial intelligence held great promise asa technology that could be used to solve com-plicated problems both within the company andfor the company’s customers as well. One man-ager who was closely associated with the pro-ject explained the escalation in these terms:

I think it was a combination of optimism whichyou could call undue or not and a sense thatthis was a new technology that we were apply-ing to this problem and that experimenting withit could yield the results that we wanted even ifwe couldn’t see them in front of us at themoment. So there was a kind of technologicaloptimism...

There was always a sense that [Jones] wouldfind a way to keep the project going. I thinkthat [Jones] took for granted that the problemwas real and that the technology held promiseto solve it. He never wavered on that. Eventhough we sometimes got a cold receptionfrom Sales, it continued to be funded anywayas an R&D project.

In the words of one executive:

Senior management had developed so muchfaith in the technology that they continued tofund it regardless of what the data said.

Project Setbacks That Appeared to beTemporary Problems

The limited acceptance among sales representa-tives was always regarded as a temporary problemthat could be overcome with additional resources.Several user surveys that were conducted (in 1984,1985, and 1986) seemed to suggest that the salesrepresentatives did have need for better configura-tion support tools in the field and that they mightuse CONFIG more if issues such as lack of avail-ability, lack of training, poor ease-of-use, and poorresponse time were resolved (CompuSys internalmemorandum, 1987).

To the development team, this feedback impliedthat the tool could be made acceptable to thesales force with some additional developmentwork and more emphasis on providing the avail-ability, training, and support needed for a suc-cessful implementation. This led not only to thecontinuation of the project but to a massive effortin 1989 to improve the tool’s user interface (Keil,et al., 1995a) and to redeploy it with "the neces-sary infrastructure to ensure optimization of theconfiguration creation process" (CompuSys inter-nal memorandum, 1989). But despite introducinga far more usable tool with a near textbookimplementation program, this multimillion-dollarredeployment effort failed to have a significantimpact on sales reps’ willingness to use CONFIG(Keil, et al., 1995a; Markus and Keil, 1994).

Psychological factors

Some psychological factors apparently causedthe key decision makers, Jones and Smith, toconvince themselves that continuation wouldeventually lead to success (Brockner, 1992).These factors included the following: (1) priorhistory of success, (2) high degree of personalresponsibility for the outcome of the project,(3) errors in information processing, and(4) emotional attachment to the project.

Prior History of Success

The success or failure of previous projects is apsychological factor that can influence a man-



ager’s decision frame for identifying, interpret-ing, and acting on project information. Prior his-tory of success was evident in the case ofCONFIG. The prior success of VERIFIER natu-rally caused the managers responsible forCONFIG [Jones and Smith] to be confidentabout its prospects for success. As one individ-ual who was close to the project observed:

What I saw were [Jones and Smith] buildingupon a previous success with [VERIFIER] andsaying we can hit that home run again.

Staw and Ross’ (1987a) model of the psychologi-cal determinants of commitment suggests that aprior success may inhibit a decision maker’s will-ingness to re-examine the current course ofaction, thus promoting escalation. Psychologicalliterature on selective perception (e.g., Allen andMarquis, 1964; Hastorf and Cantril, 1954;Hogarth, 1979) provides additional support forthis notion. One would expect decision makers toignore negative information or to downplay its sig-nificance when there is a prior history of success.

High Degree of Personal Responsibility forthe Outcome of the Project

Based on interviews conducted with a widerange of individua!s throughout the company, itwas clear that Jones and Smith were perceivedto be the managers most responsible for thecontinuation of the CONFIG project. Historicaldata gleaned from company memos andreports confirmed that both Jones and Smithwere closely associated with the CONFIG pro-ject for a decade or more. Furthermore, manyinterviewees were quick to point out that CON-FIG was Jones’ "baby," implying that he wasthe individual responsible for having initiatedthe project.

According to escalation theory, individuals witha high degree of personal responsibility willhave a tendency to engage in self-justification;they will convince themselves that it is better tocontinue than abandon because they want toshow that their original decision to pursue theproject was "correct." The need to self-justify isheightened when prior expenditures are irrevo-cable, public, freely chosen, and repeated--all

conditions that existed in the case of CONFIG.The net effect of self-justification is to lower theprobability that questionable projects will bereconsidered.

Errors in Information Processing

Managers who reported to Jones and Smithsuggested that neither one of these two individ-uals wanted to hear negative information.Instead, Jones and Smith apparently sought outpositive information about the project. As onemanager who was closely involved recalled:

I don’t think they [Jones and Smith] ever per-ceived any problem with the product. If they did,they never shared it with me or as far as I knowanybody in the group. They certainly neverwanted to hear that there was any problem.

Another individual explained how Jones andSmith would react when presented with nega-tive information:

When we did surveys of people in the field theinformation we got wasn’t what they [Jonesand Smith] wanted, but you know denial is sopowerful . . . Their response was: "Wronganswer, we don’t like that answer." Theynever listened to [negative] feedback.

When I approached [Smith] with negative feed-back from the field, he would get defensiveabout it. He would always say: "Well, that’shearsay." And we would have to go out andconduct additional surveys.

He seemed to be exercising denial. [He’d say]’q’here must be something wrong with your sur-vey process. Talk to these people individually."Sometimes we would be asked to go back andsurvey the same individuals again.., and evenif the information was still negative, [Jones andSmith] would find some way to put a positivespin on it.

The type of behavior described above is consis-tent with escalation theory. As Staw and Ross(1987a, p. 54) observe: "If the objective factsdisconfirm one’s opinion, the individual will workhard to find reasons to discredit the source ofinformation or the quality of the data itself."



Emotional Attachment to the Project

Several key members of the development teamexpressed a strong bond with the project. In thewords of one manager:

I’m trying to be very objective and pull myselfaway from being so attached to [CONFIG].After you’ve had blood, sweat, and tears over itfor the last three years, you get very attachedto [CONFIG] and very defensive of it (empha-sis added).

Another individual who had been one of theoriginal CONFIG developers explained hisreluctance to abandon CONFIG:

I don’t think we want to get rid of [CONFIG]. Idon’t want to just throw out 10 years of work...

Given the level of emotional attachment dis-played by various members of the developmentorganization, it is reasonable to assume thatJones and Smith were also emotionallyattached to the project. Several sales managerswho were in a position to observe the develop-ment process commented on the emotionalattachment that existed on the part of the devel-opment organization in general. As one manag-er observed:

Some of these guys had five or six years oftheir life in that project. Their life was inthat.., the emotional baggage of hanging onto it... not being able to say: "this isn’t goingto work" and walking away from it...

Social factors

There also appeared to be some social factorsthat contributed to escalation: (1)competitiverivalry between Sales and Manufacturing,(2) need for external justification, and (3) normsfor consistency.

Competitive Rivalry Between Sales andManufacturing

Within CompuSys, the competitive rivalry thatexisted between Sales and Manufacturing waslegendary. It is in the context of such rivalry that

CONFIG’s developers never seemed to consid-er that their basic design concept might beflawed. While many in Sales viewed CONFIGas a "turkey" of a system, Jones and Smithrepeatedly attempted to blame the Sales orga-nization for CONFIG’s low acceptance. As twodifferent managers observed:

They [Jones and Smith] kept saying: "the salesforce doesn’t understand the tool. They don’twant to take the time to learn it."

The spin that they [Jones and Smith] wouldalways put on the project was that the field justdidn’t understand . . . that the field just didn’tsupport it.

As research on self-serving biases has shown,individuals are much more likely to attributenegative outcomes to external rather than inter-nal causes (Staw and Ross, 1978). In the caseof CONFIG, there is considerable evidence thatdecision makers sawthe failing outcome as theresult of ignorant or obstructionist behavior onthe part of the sales force. Seen in this light,continuation of the project may have beenviewed as the only way for Manufacturing tojustify its investment and at the same time exertits will over Sales. For Manufacturing, the alter-native of terminating the project would havebeen tantamount to admitting that Sales was"right" and that manufacturing was "wrong."

Need for External Justification

The need to justify a course of action can beheightened when a decision maker seeks to ratio-nalize his/her behavior to other parties. In thecase of CONFIG, there were extemal constituen-cies~such as customers and shareholders--thatwere led to believe that CompuSys was success-fully pursuing artificial intelligence both to improveintemal processes and as the basis for new ser-vice offerings to its customer base.

As early as 1982, journal articles and booksbegan to appear describing the efforts thatwere underway at CompuSys to build expertsystems such as CONFIG. In these writings,CONFIG was typically, portrayed as a success-ful example of how CompuSys had embraced

MIS Quarterly~December 1995 433


new technology to develop a leading-edge sys-tem that would improve customer service.Ironically, there were some sales representa-tives who never embraced the tool but saw thevalue in it from a public relations standpoint andreferred to it in discussions with customers.

political) in nature and included the following:(1) strong advocates who provided continuedfunding and protection, (2) empire building, and(3) slack resources and loose managementcontrols.

Norms for Consistency

Norms for consistency represent another socialvariable that may have promoted escalation. Inthe U.S., for example, substantial rewards areoften given to managers "who can turn thingsaround or convert a losing project into a winner"(Staw and Ross, 1987a, p. 58). Prior researchhas shown that managers who exhibit consistentcommitment to a course of action are pemeivedas strong leaders, suggesting that "persistence isa socially valued style of leadership" (Staw andRoss, 1987a, p. 59). This combination of socialnorms suggests that there may be a kind of"hero effect" in which society reserves specialpraise and admiration for leaders who "stick totheir guns" and are able to turn things aroundeven when there is a low likelihood of success.

In addition to societal norms that may havefavored persistence, there were also strongsocial norms within CompuSys that favored con-tinuation. During the 1980s, it was not part of thecompany culture at CompuSys to kill projects;instead, failing projects were allowed to die fromnatural causes. In the words of one manager:

Part of the culture then was that it was okay tolet things linger before someone actually wentout and killed them. That was not unusual.

In the case of CONFIG, this meant that man-agers were unwilling to terminate the project.As another manager observed:

Nobody wanted to kill it. We;re a h’umanitartanorganization. Nobody wanted to shoot it in thehead.

Organizational factors

The fourth and final set of factors that may havepromoted escalation were organizational (or

Strong Champions Who Provided ContinuedFunding and Protection

According to one senior manager:

There were always signals that CONFIG was-n’t being embraced [by the field], but therewere some very strong champions insideManufacturing--largely [Vigilant] and [Jones].[Vigilant, who was the Manufacturing VP] keptfunding it out of his discretionary funds...This was a classic example of how[CompuSys] would continue to invest in a pro-ject when there were strong advocates--regardless of whether or not it made financialor market sense to do so.

Because of these strong advocates and theirhigh position within the organization, othersenior managers within Manufacturing whowere critical of CONFIG had only a weak voice.In the words of one senior manager inManufacturing:

As long as [Vigilant] and [Jones] had controlover it, there was nothing that I or anyone elsecould do.

While some senior managers outside ofManufacturing argued that CONFIG should beterminated, these arguments seem to have fall-en on deaf ears. As one manager recalled:

I wrote three whistle-blowing memos to threevice presidents ... I couldn’t stop it. It was asacred cow project.

The presence of such strong advocates clearlypromoted escalation. This is consistent withStaw’s observation, "If advocates of a projectare represented on governing bodies and bud-get committees charged with the fate of a ven-ture, one may expect substantial persistence inthe course of action" (Staw and Ross, 1987a,p. 61).

434 MIS Quarterly/December 1995


Empire Building

During the 1980s, Jones and Smith had createdand staffed an entire organization whose exis-tence was at least partially dependent on theCONFIG project. Many felt that Jones andSmith had a disincentive to abandon CONFIGbecause such an action would have threatenedthe growth of their "empire," thus diminishingtheir status. The following remarks from threedifferent individuals were typical:

They [Jones and Smith] were always trying togrow. The staffing level for [CONFIG] neverwent down. It only went up... [CompuSyswas] in a period of relative growth and buildingempires was the thing to do because that wasan indicator of how powerful you were... Itwas like: ’Hey, we’re going to have our ownbuilding.’

It was kingdom building--people preservingtheir kingdom and building their power base inorder to sustain what they wanted to do inorder to make themselves important.

CompuSys is rea~ good at creating fiefdoms.It’s pretty typical throughout the corporation.And I think this was a classic case.

A reasonable interpretation of the above evi-dence would suggest that Jones and Smithmay have had reason to believe that terminat-ing the CONFIG project would diminish theirstatus within. CompuSys.

Slack Resources and Loose ManagementControls

During the early 1980s, when CONFIG wasbeing developed, CompuSys had plenty ofcash, and project justification mechanisms wereloose or non-existent. One manager offered thefollowing explanation of how projects were initi-ated at CompuSys:

In the early 1980s you’d sort of go tin-cuppingto different parts of the organization. When yougot enough money raised you went into devel-opment. Hopefully while you were tin-cuppingyou were still in some sort of needs analysisand design. But at some point you reached acritical mass of support and you built it. Oddly

enough, you probably never asked the peoplewho were going to use it if they wanted it...you went to people who you thought wouldwant to see this nice thing made. You didn’thave to go to any board or council or group ormanagement committee.

In addition to the unusually loose way in whichprojects were initiated and justified, once a pro-ject was started, formal reviews were seldomperformed. In the words of one manager whowas closely associated with the CONFIG project:

[CONFIG] was subject to review in a some-what haphazard way. Sometimes it seemed tome that decisions about this kind of thing weremade almost in an off-hand way.

Another senior manager explained how theCONFIG project continued to be funded out ofdiscretionary R&D funds without undergoingany type of formal review process:

[As along as Tom Jones was in charge] itnever got reviewed. It didn’t get into the officialbudget review process until 1992.

The combination of slack resources and loosemanagement controls that existed atCompuSys during the 1980s led to an environ-ment that actually promoted escalation.

Summary mode/of factors thatpromoted escalation

Figure 7 represents a summary model of thefactors that promoted escalation in the case ofCONFIG. Consistent with theory, the escalationappeared to be promoted by a wide variety ofvariables including project, psychological,social, and organizational factors. While most ofthese factors have been discussed in the esca-lation literature, the case study revealed severaladditional factors that have not been widely dis-cussed in previous studies. These factorsinclude: emotional attachment to the project,empire building, and slack resources and loosemanagement controls.



Reasons for the EventualTermination of CONFIG

After more than a decade of development andtens of millions of dollars, the CONFIG projectwas eventually terminated at the end of 1992.The pattern of escalation was ultimately brokenby two factors: (1) the passing away of the pro-ject’s primary champion, and (2) an externalshock to the company.

Project’s primary champion dies

In 1992, Tom Jones, the project’s primarychampion, died abruptly of cancer. As onesenior manager recalled: "When [Jones] died,there ceased to be enough support to keep itgoing." Another manager reflected:

[Jones] could always find a way to pull themoney that he needed to keep it alive.

Because he believed in the thing. It was thething he had staked his career on. After[Jones] died he wasn’t around to protect it. Hewasn’t there to influence the funding.

External shock to the company

By the end of the 1980s, CompuSys was con-fronted with a downturn in the U.S. computer mar-ket. Faced with mounting losses during the early1990s, the company was fomed to begin laying offemployees and restructuring its operations.Suddenly, a company that was used to operatingin a growth mode found itself fighting to regainprofitability. This chain of events represented anexternal shock to the company that appears tohave contributed to the cancellation of the CON-FIG project. In the words of one manager:.

After [Jones] passed away, there were a lot oforganizational changes and [several of] theManufacturing VPs who had supported [CON-

Project Factors¯Evidence that contJnued investment could produce large payoff¯Project regarded as an investment in research and development¯Project setbacks appeared to be temporary problems

ical Factors¯Prior history of success¯High degree of personal responsibility for the outcome of the project¯Errors in information processing¯Emotional attachment to 1he project *

Social Factors¯Competitive rivalry between Sales and Manufacturing¯Need for external justif’mation¯Norms for consistency

ProjectEscalation

Organizational Factors¯Strong advocates who provided continued funding and protection¯Empire building *¯Slack Resources and loose management controls *

’Indicates factor that has not been widely discussed in the escalation literature

Figure 7. Summary Model of Factors That Promoted Escalation



FIG] left the company. Then a new guy camein to a situation where resources were scarcebecause we were in a cost-cutting and down-sizing mode... He’s like: ’What am I doing?We’re spending this on something that nobodyreally wants. Stop.’ He wasn’t invested person-ally in it...

Other managers offered similar views, suggest-ing that the external shock to the organizationwas a contributing factor in the eventual termi-nation of the project. The following remarksfrom three different individuals were typical:

I firmly believe that if we had not run into thefinancial problems that we ran into as a corpo-ration that [CONFIG] would still be alive andwell.

At this point in our history we are killing pro-jects left and right unless they start producingfairly quickly. I think this is due .to the cash con-straints that we now face...

Management and controls placed on every-thing are much more stringent now. There arebetter established program guidelines now.Projects and programs are much tighterdefined.

Summary model of organizationalexit from escalation

Figure 8 summarizes the events that set thestage for organizational exit in the case of

CONFIGo

Consistent with an earlier model (Ross andStaw, 1993), changes in top management werejudged to be an important factor in breaking thepattern of escalation. In the case of CONFIG,however, the death of the project’s primarychampion was also observed to be a key factor

in the eventual withdrawal.

Implications

Given that escalation occurs in IT projects, itis important to understand why it occurs andhow it can be avoided. Though the findingsreported here are based on a single casestudy, they have significant implications forpractice.

IExternal shock to the organization I

I Major changes in management and organizaUon

IDeparture of key executives who had supported CONFIG

Pdmary projectchampion passes away Erosion of political support for CONFIG project

of resources and termination of CONFIG project

Figure 8. Events that Set the Stage for Organizational Exit



Implications for IT managers

For IT managers, the knowledge that escalationcan occur in IT projects underscores the impor-tant role that psychological, social, and organi-zational factors can play in the successful man-agement and control of IT projects. In the past,IT managers have relied upon traditional projectmanagement techniques to manage and controlIT projects. While the traditional approachesare useful, it should be noted that they arebased on a rational approach to project man-agement and thus tend to ignore some of theother dimensions that seem to be associatedwith project escalation. The research resultsreported here suggest the need for a broaderview of project management and control thatencompasses both the rational approach forcontrolling projects and a more psychological orbehavioral perspective.

To avoid the escalation trap, IT managers cantake actions as individuals to minimize theirown risk of becoming overcommitted, and theycan also institute organizational policies andpractices to reduce their organization’s expo-sure to escalation. The first step in avoiding ITproject escalation is for managers to recognizethat there is a natural tendency to escalatewhen one becomes too committed to a courseof action. Although there is often a fine linebetween "an optimistic, can-do attitude andovercommitment," there are several questionsmanagers can ask themselves to help deter-mine whether they have crossed the line (Stawand Ross, 1987b, p. 72):

¯ Am I unable to clearly define what would con-stitute failure for this project? Has my defini-tion of what would constitute success or fail-ure changed as the project has evolved?

¯ Do I have trouble hearing other people’s con-cerns about the project?

¯ Am I more concerned about the welfare ofthis project than I am about the organizationas a whole?

If the answer to one or more of these questionsis "yes," then the manager is probably too com-

mitted to the project and needs to re-evaluatethe project before committing any additionalresources. Managers can also take steps toavoid becoming overcommitted to a project inthe first place. One approach is to periodicallyevaluate the project from an outsider’s perspec-tive. A good question to ask oneself is: "If I tookover this job for the first time today and foundthis project going on, would I support it or getrid of it" (Staw and Ross, 1987b, p. 72)?Another approach is to always consider alterna-tive courses of action in deciding whether toabandon or continue a prior course of action(Keil, et al., 1995b; Northcraft and Neale,1986). In the case of CONFIG, this approachmight have prompted the managers and devel-opers to consider either alternative solutions tothe configuration problem or alternative devel-opment projects more worthy of resources.

Implications for organizations

While individuals play an important role in theescalation process, "much of what causesescalation is in the nature of organizations, notpeople" (Staw and Ross, 1987b, p. 72). Withoutthe right structures and incentives it is naive toexpect that all managers will be motivated toask the above questions. There are severalsteps, however, that organizations can take tocreate an environment in which managers areforced to raise the kind of questions that canavoid project escalation. The prescriptions thatfollow are meant to be suggestive of the typesof actions that organizations can take, alone orin combination, to help minimize the risk of pro-ject escalation.

Know the Stage of the Project and Manage ItAccordingly

Organizations should create systems to insurethat project management is appropriatelymatched to the stage of the project. Projectsthat are initiated to explore applications involvingnew information technologies need to be man-aged very differently once they are moved fromresearch mode into full-scale development.



One of the problems with the CONFIG projectwas that it was regarded as an R&D projecteven after it had been fully developed andimplemented. To avoid this problem, compa-nies should create a tracking system that givessenior management a full accounting of all ITprojects and their current stages. Clear guide-lines should be established to mark the point atwhich projects move from one stage to another.In the case of CONFIG, this would have pre-vented its supporters from using available "dis-cretionary funds" to continue their so-called"R&D project" at the company’s expense.

Assess Risks Early (and Often) During theDevelopment Process

As in the case of industrial research and devel-opment, IT projects typically progress througha number of defined stages (e.g., analysis,design, development, implementation) betweeninitiation and "commercialization." At the earli-est possible stages of this process, managersneed to begin asking whether there are any"red flags" or serious exposures they will facein continuing to pursue a project.

Unfortunately, for most IT projects, risk assess-ments are usually conducted on an infrequentand informal basis if they are even conductedat all (Ropponen and Lyytinen, 1993).However, since most organizations followsome type of software development methodol-ogy, it would be a relatively easy matter toinclude a formal and periodic risk assessmentas part of the overall methodology for develop-ing systems. While the precise implementationof such an approach will vary from company tocompany, the two critical areas that should beincluded in any risk assessment are: (1)theprobability of technical success, and (2) theprobability of customer acceptance(Balachandra and Raelin,~1980).

In assessing the probability of technical suc-cess it is important to consider both the currentstate of the technology (i.e., how mature it is)and the prior experience of the project team indealing with the technology (McFarlan, 1981).Given the pace of change in information tech-

nology and the constant evolution of new hard-ware and software platforms, technical successshould never be taken for granted. This is par-ticularly true in the case of large, cutting-edge,projects. That being said, the more significantrisk often lies in the area of customer accep-tance. In assessing this risk, it is important toask whether there is sufficient "demand" for asoftware application before investing hugesums of money to fully develop it. Like goodmarketers, IT managers need to conduct mar-ket research in the form of focus groups, sur-veys, and observational studies. While suchresearch is costly, it is necessary to insure thatthe system design concept is appropriate. Aspart of the overall evaluation process, IT man-agers must also consider whether the rightorganizational incentives exist for people towant to use a proposed system. In the case ofCONFIG, this type of analysis would havehighlighted the exposures that the project teamwould later face when they found out that thedesign concept was flawed and that sales rep-resentatives had no incentive to use the sys-tem. Finding out about these problems early inthe process might have avoided project escala-tion by allowing the project to be terminated orredirected at an earlier stage.

Conduct Serious Project Audits

No development methodology--even one thatincludes risk assessment--will prevent escala-tion unless managers are motivated to followthe methodology. Therefore, to provide theproper incentives, every major IT projectshould be subjected to a periodic audit processled by someone who is appointed to serve asthe organization’s devil’s advocate. This indi-vidual should be charged with protecting theinterests of the organization as a whole andshould not have a stake in the projects that arebeing audited. The devil’s advocate should besomeone who is not only experienced in thearea of project management, but who has beentrained to ask tough questions and to recog-nize escalation situations. To insure thathis/her recommendations will carry clout and toavoid recrimination, the devil’s advocate should



report directly to senior management (prefer-ably the CEO).

The devil’s advocate would be responsible forassembling a review board. The board shouldconsist of six to eight individuals; some of themembers should be selected on a project byproject basis, while others should be appointedto serve the board for a fixed number of years.Three or four individuals representing the com-pany’s accounting, IS, and human resourcemanagement areas should be appointed toserve on the board for three-year terms thatcould be staggered to provide some continuity.In reviewing projects, this group would then beresponsible for including representation fromthose areas of the business that will be mostaffected by the system under review.

The review board should normally meet toreview projects on a quarterly basis, althoughthe exact review interval will vary with the sizeand importance of the project. The review itselfshould be focused on whether or not the pro-ject has achieved specific and measurablegoals that are tied to system use and businessvalue. Continued support for the project shouldbe withheld if the goals are not specific or ifthey are specific but are not being achieved.The review should also involve a careful exam-ination of project risks and exposures. Any sig-nificant deterioration in the risk profile of theproject should trigger a re-examination of theproject to determine if support should be with-drawn. In the case of CONFIG, the approachoutlined above would have insured that theproject was not subject to "haphazard reviews"and might have led decision makers to ques-tion their continued commitment to the projectat a much earlier stage. In addition, it wouldhave prevented the Manufacturing organizationfrom continuing to fund a sales support toolthat the Sales organization did not want andrefused to use.

Reduce the Need for Self-Justification

In order to reduce the psychological need forself-justification, organizations can separateinitial and subsequent decision-making con-

cerning a particular course of action (Staw andRoss, 1987a). Subsequent funding decisionsshould not be made by those who have vestedinterests in justifying the initial course of action.A more radical approach is to rotate managersin and out of projects to insure that those whoinitiated the project are periodically replaced byindividuals who have more objectivity. In thecase of CONFIG, either of these techniqueswould probably have caused the project to beterminated much earlier.

Another way of reducing the need for self-justi-fication is to reduce the consequences associ-ated with failure (Brockner and Rubin, 1985). many organizations, key mistakes can have anadverse effect on one’s career or lead to jobtermination. Such a climate is likely to heightenthe need for self-justification. Organizationsthat are more tolerant of failure, however, areless likely to experience project escalation(Staw and Ross, 1987a). It is important, how-ever, to create an appropriate balance. Anenvironment of infinite tolerance could prove tobe just as prone to escalation.

Conclusion

This research has shown that escalation canoccur in an IT project and has highlightedsome of the factors that may contribute to theproblem. A company that continues to "throwgood money after bad" on an IT project is mak-ing a very bad business investment for threereasons. First, the infusion of additional dollarsis not solving the business problem for whichthe system was intended. Second, escalationmeans that the company is continuing to wastevaluable resources. Third, there is an opportu-nity cost because the company is missing thebenefits from alternative uses of theseresources. Thus, preventing IT project escala-tion can be critical in determining whether firmsare obtaining real value from their investmentsin information technology (Markus and Keil,1994). For researchers and practitioners alike,escalation offers a new perspective on soft-ware project management that holds thepromise of improving our ability to successfullymanage IT projects.



Acknowledgements

I would like to thank Jeff Smith, Lynne Markus,Kalle Lyytinen, Eph McLean, Detmar Straub,and Duane Truex, for their helpful comments onearlier drafts of this paper. I would also like tothank the associate editor and four anonymous

referees for their constructive feedback. Thispaper is based on research that was conductedas part of my doctoral dissertation, and I wouldlike to acknowledge the advice and supportreceived from thesis committee members: JimMcKenney, Dorothy Leonard-Barton, JohnSviokla, and Benn Konsynski. Research fund-ing from the Harvard Business School’sDivision of Research is also gratefully acknowl-

edged. Finally, this work would not have beenpossible without the participation of CompuSysand its employees.

Endnotes

An earlier version of this paper was presented at the 1995Academy of Management Conference and published in itsproceedings (Keil, 1995a). An earlier formulation of someof the ideas presented here also appeared in Keil (1995b).

Escalation does not necessarily imply an increasing rateof investment over time, but rather, refers to a growth inthe cumulative amount of resources invested over time.Thus, escalation can be thought of as continued commit-ment.

Staw and Ross (1987a) initially used the term "structuraldeterminants," which they subsequently relabled as "orga-nizational determinants" (Ross and Staw, 1993).

One of the reasons for choosing this particular project wasthat the history of CONFIG had been well documentedand could be studied by reviewing a variety of historicalmaterial. The author is particularly indebted to DorothyLeonard-Barton for sharing data that she collected on theCONFIG project from 1984-1987.

The company name, project names, and the names of theindividuals involved have all been disguised to provideanonymity.

Includes multiple interviews with the same subject.

Includes six conference calls.

8Includes 13 user design-team meeting minutes, threecostJbenefit analyses, six inter .nal reports conceming bar-riers to CONFIG usage, and more than 275 problemreports filled out by users.

Since portions of Appendix B make reference to some ofthe individuals involved in the project, readers who areinterested in this material will find it more meaningful to

consult the appendix after reading about the history of theCONFIG project and why it failed.

10By the early 1980s, CompuSys managers had determinedthat roughly 25 percent of the orders coming out of Salesexhibited some type of configuration error.

11Because the two systems were based on the same under-lying knowledge base, it is difficult to separate out theresources that went into CONFIG versus the resourcesthat were directed toward VERIFIER. From 1981 to 1991,the size of the development group in which the two pro-jects were housed grew from 21 people to 115 people. By1991, the group’s annual operating budget had reachedapproximately $45 million. By this point, approximately$15-20 million was being spent annually on maintainingVERIFIER and CONFIG, with an estimated 40-50 percentof these funds being spent on CONFIG.

12The history and analysis presented here focuses onJones and Smith because they were identified by manyindividuals within CompuSys as being the primary deci-sion makers responsible for the escalation of the CONFIGproject.

13It should be noted that the UDT was not a decision-mak-ing body in the sense that it was not vested with theauthority to decide whether to continue funding the CON-FIG project. However, the UDT meeting minutes did con-tain critical information concerning the status and ultimateviability of the project. In many cases the decision makerswho had the authority to abandon or continue the projectwere in attendance at these UDT meetings and in allcases, the minutes were widely distributed and availableto the key decision makers.

14The complete project chronology is available uponrequest.

15The mapping of CONFIG project information was inspiredby the work of Newman and Robey who have proposed asimilar type of process mapping for analyzing the socialcharacter of user-analyst relationships (Newman andRobey, 1992).

16The numbers plotted in Figure 6 represent the ratio of thenumber of times CONFIG was used to generate a quotedivided by the number of system quotes generated overthe same time period. Information concerning the numberof quotes and the number of times CONFIG was used togenerate a quote was collected automatically by the com-pany’s quoting system. The totals were tallied each monthand tracked on a quarterly basis. These figures were sup-plied to the researcher by CompuSys for the years duringwhich they were available.

References

Allen, T.J. and Marquis, D.G. "Positive and

Negative Biasing Sets: The Effects of PriorExperience on Research Performance,"

IEEE Transactions on Engineering



Management (11:4), December 1964,pp. 158-161.

Alter, So and Ginzberg, M.’"ManagingUncertainty in MIS Implementation," SloanManagement Review (20:1), Fall 1978, pp.23-31.

Balachandra, R. and Raelin, J.A. "How toDecide When to Abandon a Project,"Research Management (23:4), July 1980, pp.24-29.

Betts, M. "Feds Debate Handling of Failing ISProjects," Computerworld, November 2,1992, p. 103. =.

Boehm, B.W. Software Engineering Economics,Prentice Hall, Englewood Cliffs, N J, 1981.

Brockner, J. "The Escalation of Commitment toa Failing Course of Action: TowardTheoretical Progress," Academy ofManagement Review (17:1), January 1992,pp. 39-61.

Brockner, J. and Rubin, J.Zo Entrapment inEscalating Conflicts: A Social PsychologicalAnalysis, Springer-Verlag, New York, NY,1985.

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

Cohen, J. "A Coefficient of Agreement forNominAl Scales," Educational and Psycho-logical Measurement (20:1), Spring 1960, pp.37-46.

Cringely, R.X. "When Disaster. Strikes IS,"Forbes ASAP, August 29, 1994, pp. 60-64.

Ellis, V. "Audit Says DMV Ignored Warning," LosAngeles Times, August 18, 1994, pp. A3,A24.

Ewusi-Mensah, Ko and Przasnyski, Z.H. "OnInformation Systems Project Abandonment:An Exploratory Study of OrganizationalPractices," MIS Quarterly (15:1), March1991, pp. 67-85.

Garland, H. "Throwing Good Money After Bad:The Effect of Sunk Costs on the Decision toEscalate Commitment to an OngoingProject," Journal of Applied Psychology(75:6), December 1990, pp. 728-731.

Garland, H., Sandefur, C.A., and Rogers, A.C."De-Escalation of Commitment in OilExploration: When Sunk Costs and NegativeFeedback Coincide," Journal of AppliedPsychology (75:6), December 1990, pp.721-727.

Gibbs, W.W. "Software’s Chronic Crisis,"Scientific American (271:3), September1994, pp. 86-95.

Ginzberg, M.J. "Early Diagnosis of MISImplementation Failure: Promising Resultsand Unanswered Questions," ManagementScience (27:4), April 1981, pp. 459-478.

Gladden, G.R. "Stop the Life-Cycle, I Want toGet Off," ACM SIGSOFT SoftwareEngineering Notes (7:2), April 1982, pp.35-39.

Hastorf, A.H. and Cantril, H. "They Saw aGame: A Case Study," Journal of Abnormaland Social Psychology (49:1), January 1954,pp. 129-134.

Hogarth, R.M. Judgement and Choice: ThePsychology of Decision, John Wiley & Sons,New York, 1979.

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

Kahneman, D. and Tversky, A. ’q’he Psychologyof Preferences," Scientific American (246:1),January 1982, pp. 160-173.

Keider, S.P. "Why Projects Fail," Datamation(20:12), December 1974, pp. 53-55.

Keil, M. "Escalation of Commitment inInformation Systems Development: AComparison of Three Theories," Academy ofManagement Best Papers Proceedings, 55thAnnual Meeting, Vancouver, BritishColumbia, August,4-8, 1995a,pp. 348-352.

Keil, M. "Identifying and Preventing RunawaySystems Projects," American Programmer(8:3), March 1995b, pp. 16-22.

Keil, M., Beranek, P.M., and Konsynski, B.R."Usefulness and Ease of Use: Field StudyEvidence Regarding Task Considerations,"Decision Support Systems (13:1), January1995a, pp. 75-91.

Keil, M., Mixon, R., Saarinen, T., andTuunainen, V. "Understanding RunawayInformation Technology Projects: Resultsfrom an International Research ProgramBased on Escalation Theory," Journal ofManagement Information Systems (11:3),Winter 1995b, pp. 67-87.

Kemerer, C.F. "Ar~ Empirical Validation ofSoftware Cost Estimation Models,"Communications of the ACM (30:5), May1987, pp. 416-429.


Sof~vare Project Escalation

Kindel, S. "The Computer That Ate theCompany," Financial World (161:7), March31, 1992, pp. 96-98.

Kull, D. "Anatomy of a 4GL Disaster," ComputerDecisions, February 11, 1986, pp. 58-65.

Landis, J.R. and Koch, G.G. ’q’he Measurementof Observer Agreement for CategoricalData," Biometrics (33:1), March 1977, pp.159-174.

Lyytinen, K. and Hirschheim, R. "InformationSystems Failures--A Survey andClassification of the Empirical Literature," inOxford Surveys in Information Technology(4), P. I. Zorkoczy (ed.), Oxford UniversityPress, Oxford, 1987, pp. 257-309.

Markus, M.L. and Keil, M. "If We Build It, TheyWill Come: Designing Information SystemsThat Users Want To Use," SloanManagement Review (35:4), Summer 1994,pp. 11-25.

McFarlan, F.W. "Portfolio Approach toInformation Systems," Harvard BusinessReview (59:5), September-October 1981,pp. 142-150.

McPartlin, J.P. "The Collapse of Confirm,"Information Week, October 19, 1992, pp.12-19.

Mehler, M. "Reining in Runaways," InformationWeek, December 16, 1991, pp. 20-24.

Meredith, J. "Project Monitoring For EarlyTermination," Project Management Journal(19:5), November 1988, pp. 31-38.

Neuman, M. and Robey, D. "A Social ProcessModel of User-Analyst Relationships," MISQuarterly (16:2), June 1992, pp. 249-266.

Neumann, P.G. and Hoffman, R. "Risks to thePublic in Computers and Related Systems:Details of BofA’s Costly Computer Foul-up,"Software Engineering Notes (13:2), April1988, pp. 6-7.

Newman, M. and Sabherwal, R. "Determinantsof Commitment to Information SystemDevelopment: A Longitudinal Investigation,"MIS Quarterly, 1996 (forthcoming).

Northcraft, G.B. and Neale, M.A. "OpportunityCosts and the Framing of ResourceAllocation Decisions," OrganizationalBehavior and Human Decision Processes(37:3), June 1986, pp. 348-356.

Ropponen, J. and Lyytinen, K. "How SoftwareRisk Management Can Improve SystemDevelopment: An Explorative Study," working

paper, University of Jyvaskyla, Jyvaskyla,Finland, 1993.

Ross, J. and Staw, B.M. "Expo86: An EscalationPrototype," Administrative Science Quarterly(31:2), June 1986, pp. 274-297.

Ross, J. and Staw, B.M. "OrganizationalEscalation and Exit: Lessons From theShoreham Nuclear Power Plant," Academyof Management Journal (36:4), August 1993,pp. 701-732.

Rothfeder, J. "It’s Late, Costly, Incompetent--But Try Firing a Computer System," BusinessWeek, November 7, 1988, pp. 164-165.

Staw, B.M. and Ross, J. "Commitment to aPolicy Decision: A Multi-TheoreticalPerspective," Administrative ScienceQuarterly(23:1), March 1978, pp. 40-64.

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

Staw, B.M. and Ross, J. "Knowing When to Pullthe Plug," Harvard Business Review (65:2),March-April 1987b, pp. 68-74.

Yin, R.K. Case Study Research: Design andMethods, Sage, Beverly Hills, CA, 1984.

About the Author

E, lark I(eil is an assistant professor of computerinformation systems in the College of BusinessAdministration at Georgia State University. Hereceived his D.B.A. in management informationsystems from the Harvard Business School in1991. His research focuses on the area of soft-ware project management, and his articleshave appeared in Sloan Management Review,Communications of the ACM, Journal ofManagement Information Systems, andDecision Support Systems.



Appendix A

Excerpts From the Chronology of the CONFIG Project

Date/Decision

Point Project Information Coding

11/81 Ambiguous1 :UDT #1

1/822:UDT #2

7/823:UDT #3

1/834:UDT #4

7/835:UDT #5

First user design team (UDT) meeting is held. Users areenthusiastic about being involved in the system’sdevelopment. At the same time, however, they observemany limitations with the prototype system. Observeddeficiencies include: no link to company’s quoting system,no sizing capability to match customer needs with Compu-Sys hardware/software, and inadequate price information.

Members of the UDT complain that CONFIG’s performanceis too slow, that the system lacks sufficient explanationcapability, and that the interface is not user-friendly.

Members of the UDT raise concerns regarding: timelinessof the product information contained in CONFIG, slow~erformance of the software, cumbersome user interface,and the need for additional functionality.

Members of the UDT complain that CONFIG is slow,inaccurate, and prone to software crashes. They suggestthat the developers put more attention on software testingbefore they consider releasing it to the field. Users reiteratethe need for additional functionality including some type oflinkage between CONFIG and price quotation system (PQS).

Users complain that the development team is notresponding to their criticisms of CONFIG. The issue of thetimeliness of the product information in CONFIG is againraised. Additional functionality is again requested includinga link between CONFIG and PQS.

Negative

Negative

Negative

Negative

Decision/Action

Continue. Users are givenremote access to the systemand encouraged to providefeedback to the developersas new features are added.

Continue. Developers beginto put emphasis on makingthe software more robust.Plans are made to haveCONFIG operating in Salesoffices by 1983.

Continue. Developers agreeto do a better job of keepingthe knowledge base up to datewith new products. They alsoacknowledge that the softwareis slow and that the perfor-mance needs some "fine-tuning." Agreement is reachedto load a "production" versionof the CONFIG software on anarea mini-computer, thusmaking the software availableto approximately 40-60 salesreps outside of the UDT.

Continue. Developersacknowledge many of the~ssues raised by the usersand agree to improve theaccuracy and reliability of thesoftware. Other enhancementrequests are placed in thecategory of "ongoing develop-ment." Program leader reiteratesthat "from the [CONFIG] paro-chial point of view, we will posta non-goal of linking to [PQS]in the first release of [CONFIG]."

Continue. Make additionalrefinements to the software.Plans made to graduallyallow additional users to haveaccess to the CONFIGsoftware.



11/836:UDT #6

7/847:UDT #7

When asked about the "quality/readiness" of the software,the users indicate that CONFIG is not yet ready to bereleased.

Heated discussion between" users and developers. Usersaccuse developers of not taking their input seriously enoughThey continue to complain about the speed and accuracy ofthe software. Users also continue to raise questionsregarding the basic functionality of CONFIG and its ability tocommunicate with the company’s automatic quoting system.

Users express concern over whether U.S. Sales manage-ment will support a full-scale implementation of CONFIG.They also complain about the accuracy of the system andobserve that there is insufficient hardware in the salesdistricts for running the CONFIG software. Transcripts of themeeting revealed the following typical comments from users:

My perception is that [CONFIG] is totally unused... Is itworth continuing with this product? Is this tool helping tosolve a problem? The answer is NO.

[CONFIG] is not fully developed yet. That’s why I feelcritical toward it. There was a little bit of support for theproduct at first but since the implementation process hastaken so long people have become discouraged.

We are not there yet. There has been improvement butwe are not ready yet.

Negative

Negative

Continue. A six-month freezeis put into effect on softwareenhancements, allowingdevelopers to focus onimproving the speed andaccuracy of the software.

Continue. Project managermeets with district salesmanagers to drum upsupport. Certain members ofthe UDT agree to meet withthe U.$. Sales ManagementCommittee to ask for theirsupport. The committee givesits blessing for a full-scaleimplementation of CONFIG.

Developers acknowledge thatthe software is slow andinaccurate. Plans are madeto equip the districts withdedicated computer hardwarefor running CONFIG.

Appendix B

Additional Information on Methodology

Data Collection

On-site observations and interviews were conducted during an 11-month period that began in January 1990and extended through November of the same year. During this period, the developers of CONFIG were inthe process of deploying a new version of the software that was designed to be easier to use. This effortmarked the last major attempt to adapt and redeploy CONFIG.

Many of the interviews conducted during this period were used to obtain historical details concerning theproject. A wealth of historical data on the project was also collected including user design-team meetingminutes as well as other memos and reports documenting various aspects of the project (e.g., systemusage reports and cost/benefit analyses).

Following the termination of the project, two additional rounds of interviews were conducted (by tele-phone) to obtain detailed information regarding why the project was canceled and to understand moreabout why the project was allowed to continue for as long as it did. These interviews, which were con-ducted from July through September of 1993 and from April through May of 1994, included discussionswith senior managers, sales representatives, sales managers, development project managers, and oneof the two key managers who shared responsibility for CONFIG’s continuation.



Interview Methodology

The interviews in this research were semi-structured. Before each interview, an interview protocol was con-structed and" consisted of a list of questions that would be asked of the interviewee. The specific list depend-ed, of course, on the individual’s position in the organization and his/her association with the CONFIG pro-ject. Most interviews were tape-recorded (except when interviewees requested otherwise) and in all casescopious notes were taken during the interviews. Additional observations were noted immediately after eachinterview was concluded, and key interviews were then transcribed along with any additional observations.

Most individuals--especially those who had been associated with the CONFIG project during much of itslife were able to offer considerable information regarding why the escalation occurred. In some instances,individuals indicated that they were not well-informed, but were willing to offer their speculation. When aninterviewee prefaced his or her remarks with: "1 don’t know for certain, but my sense is that this is what hap-pened," one could be reasonably certain that the information being offered was of a speculative nature. Inthese cases, the interviewee was asked to provide the names of individuals who might be better informedon the particular issue at hand. By conducting additional interviews in this way, different respondents’answers could be used for corroboration.

Data Analysis

An analysis of project information that was available to decision makers served as the principle means ofestablishing that CONFIG was indeed a case of project escalation (i.e., one that involved continued commit-ment of resources despite negative information concerning the project). As a first step in this analysis, tran-scripts of interviews and meetings were used to create a detailed history of the project in narrative form.That history was then summarized in the form of a table showing the key project information that was avail-able to decision makers and the resulting decisions or actions that were taken during the course of the pro-ject (see Appendix A). After validating this table with several individuals who were familiar with the project’shistory, the project information available to decision makers was coded as positive, negative, or ambiguous.

To avoid researcher bias, the project information contained in the table (along with the date field and blank coding field) was shown to two IS doctoral students with project management experience who agreedto serve as independent raters. Neither of the two raters were familiar with the case, and the informationthey received did not include any reference to decisions or actions taken in response to the project informa-tion that was available. For each row in the project information field, the raters were asked to code the infor-mation as either purely positive or purely negative. In cases where it was difficult to code the information aspurely positive or purely negative, the raters were instructed to use their own judgment and to assign thecode that best seemed to fit the information presented and to indicate possible ambiguity by placing a ques-tion mark next to the code.

As a measure of interrater agreement, the coefficient Kappa was calculated (Cohen, 1960). A Kappa 0.72 was obtained, indicating that the strength of agreement between the two raters was "substantial"(Landis and Koch, 1977, p. 163). For the purposes of creating the table that is illustrated in Appendix project information was coded as positive when both raters agreed that it was positive, negative when bothraters agreed that it was negative, and ambiguous when one rater coded it as positive and the other ratercoded it as negative or when either rater indicated that it was hard to classify as .either purely positive orpurely negative. The result of this analysis showed that the majority of the project information was negative,thereby indicating that the CONFIG project satisfied the definition of project escalation.

The next step of the analysis was to determine the set of factors that seemed to promote escalation andthose that seemed to be associated with the eventual termination of the project. In the case of CONFIG, a



model of escalation based on the categorization of factors discussed by Staw and Ross (1987a) was usedas the basis for identifying and organizing the factors that seemed to promote escalation. The first step inthis analysis involved comparing and contrasting the CONFIG case against the array of factors that havebeen discussed in the escalation literature and noting which of these factors seemed to be present in thecase. The next step involved the identification of additional factors that were present in the CONFIG casebut had not been widely discussed in the escalation literature.

The entire analysis process was highly iterative. Before a factor was identified as a possible cause of theescalation, a considerable amount of cross-checking of interview transcripts was performed to verify thatthere were at least two or more sources of evidence in support of that factor. This approach was a variationon the pattern matching technique for case analysis advocated by Yin (1984). A similar approach was usedto identify the factors that seemed to be associated with the eventual termination of the project. After identi-fying a set of factors associated with both the escalation and eventual termination of the project, the respec-tive factors were reviewed with several contacts at the case site as a means of validation.

Limitations of the Research Approach Used Here

While the general approach described above has some clear strengths, there are also some limitations thatshould be noted. The most significant limitations concern generalizability and the inability of knowing whatwent on inside the heads of key decision makers such as Jones and Smith.

Clearly, there is a limitation concerning the generalizability of a single case study. As a general rule, it ispreferable to use a multiple case-study design in which theoretical and/or literal replication is possible.Given the sensitivity that surrounds most failing projects, however, the researcher may seldom have theopportunity to structure the type of multiple case-study design that would be desirable. Instead, one mustsometimes follow a more opportunistic approach even if that means settling for a single case study.

The second major limitation of this study is the inability of knowing what went on inside the heads of keydecision makers such as Jones and Smith. Without knowing this, it is impossible to determine the relativestrength of the various factors that may have contributed to the escalation. A more robust analysis wouldrequire: (1) better access to those most responsible for the escalation, and (2) the ability to read their inner-most thoughts and motivations concerning the project. In this study, the researcher had only limited accessto key decision makers such as Jones and Smith, the two individuals who were among CONFIG’s strongestadvocates and therefore most able to provide insight concerning its escalation.

In order to ovemome this limitation, this reseamh relies heavily on the observations and insights of individu-als who were closely associated with the project and in a position to comment on the motivations andbehaviors of Jones and Smith. The triangulation used in the study, which included extensive discussionswith the managers to whom Jones and Smith reported, allowed the researcher to develop a rich under-standing of the factors that promoted project escalation.

In summary, while there are some limitations associated with the approach used here, the results of thisresearch still provide some useful, if tentative, findings that should be of interest to both reseamhers andpractitioners.
