Discalation of commitment

Turning around Troubled Software Projects: An Exploratory Study of the Deescalation ofCommitment to Failing Courses of ActionAuthor(s): Mark Keil and Daniel RobeySource: Journal of Management Information Systems, Vol. 15, No. 4 (Spring, 1999), pp. 63-87Published by: M.E. Sharpe, Inc.Stable URL: http://www.jstor.org/stable/40398405 .

Accessed: 12/02/2015 07:25

Your use of the JSTOR archive indicates your acceptance of the Terms & Conditions of Use, available at .http://www.jstor.org/page/info/about/policies/terms.jsp

.JSTOR is a not-for-profit service that helps scholars, researchers, and students discover, use, and build upon a wide range ofcontent in a trusted digital archive. We use information technology and tools to increase productivity and facilitate new formsof scholarship. For more information about JSTOR, please contact [email protected].

.

M.E. Sharpe, Inc. is collaborating with JSTOR to digitize, preserve and extend access to Journal ofManagement Information Systems.

http://www.jstor.org

This content downloaded from 134.148.104.3 on Thu, 12 Feb 2015 07:25:37 AMAll use subject to JSTOR Terms and Conditions

http://www.jstor.org/action/showPublisher?publisherCode=mes

http://www.jstor.org/stable/40398405?origin=JSTOR-pdf

http://www.jstor.org/page/info/about/policies/terms.jsp


Turning Around Troubled Software Projects: An Exploratory Study of the Deescalation of Commitment to Failing Courses of Action

MARK KEIL AND DANIEL ROBEY

Mark Keil is an Associate Professor in the Department of Computer Information Systems at Georgia State University. His research focuses on software project management, with particular emphasis on understanding and preventing software project escalationcases in which projects seems to take on lives of their own, continuing to absorb valuable resources without ever reaching their objectives. His research is also aimed at providing better tools for assessing software project risk and removing barriers to software use. He serves as an associate editor for the MIS Quarterly and is coeditor of The Data Base for Advances in Information Systems,

Daniel Robey holds a joint appointment as Professor in the Departments of Computer Information Systems and Management at Georgia State University. His current research deals with the consequences of information systems in organizations, and the processes of system development and implementation. He serves on editorial boards for MIS Quarterly; Accounting, Management and Information Technologies; Information Systems Research; Organization Science, Canadian Journal of Administrative Sciences; Information Technology & People, and Journal oj Information Technology Management.

Abstract: Project failure in the information systems field is a costly problem and troubled projects are not uncommon. In many cases, whether a troubled project ultimately succeeds or fails depends on the effectiveness of managerial actions taken to turn around or redirect such projects. Before such actions can be taken, however, management must recognize problems and prepare to take appropriate corrective measures. While prior research has identified many factors that contribute to the escalation of commitment to failing courses of action, there has been little research on the factors contributing to the deescalation of commitment. Through deescalation, troubled projects may be successfully turned around or sensibly abandoned. This study seeks to clarify the factors that contribute to software project deescalation and to establish practical guidelines for identifying and managing troubled projects. Through interviews with forty-two IS auditors, we gathered both quantitative and qualitative data about the deescalation of commitment to troubled software projects. The interviews sought judgments about the importance of twelve specific factors derived from a review of the literature on deescalation. Interviews also generated qualitative data about specific actors and actions taken to turn troubled projects around.

The results indicate that the escalation and deescalation phases of projects manifest different portraits. While there were no factors that always turned projects around, many actors triggered deescalation, and many specific actions accounted for de-

Journal of Management Information Systems I Spring 1999, Vol. 1 5, No. 4, pp. 63-S7

© 1999 M.E.Sharpe, Inc. 0742-1222 / 1999 $9.50 + 0.00



64 MARK KEIL AND DANIEL ROBEY

escalation. In the majority of cases, deescalation was triggered by actors such as senior managers, internal auditors, or external consultants. Deescalation was achieved both by managing existing resources better and by changing the level of resources committed to the project. We summarize the implications of these findings in a process model of project deescalation.

Key words and phrases: escalation of commitment, information systems auditing, information system development, project management.

One of the most pressing problems affecting information system (IS) executives is controlling the amount of corporate resources consumed by IS projects. A recent survey of 365 executives conducted by the Standish Group [20] revealed that as many as half of all IS projects exhibited significant cost and schedule overruns. In 1995, American companies spent an estimated $59 billion in cost overruns on such "runaway" IS projects and another $81 billion on canceled software projects [20]. Funds expended in this manner earn no return unless projects can be turned around, completed, or otherwise salvaged. Information systems simply cannot contribute to corporate performance if they are not delivered or used [28].

The surveys above are complemented by detailed accounts of major IS project failures. For example, Drummond [10, 11] documented the events leading up to the collapse in 1993 of the Taurus project, an expensive long-term project designed to replace antiquated settlement procedures on the London Stock Exchange. At the time of its abandonment, Taurus had received resources in excess of £80 million over a three-year period. Myers [32] provided a comparable account of the abandonment of a centralized payroll system in the New Zealand Education Department in 1989. In other cases, major systems have been implemented as designed only to engender public outrage. Mitev declared that the French Railways' computerized reservation system in 1993 was "perhaps the first software system which provoked nationwide strikes when it was introduced" [3 1 , p. 10]. Failures such as these have become regular embarrassments for IS executives responsible for designing and implementing systems effectively. Many of the above projects reflect a certain irony because they manifest strong

commitments. In each of the cases mentioned above, resources continued to be committed despite the presence of public controversy and strong opposition. Although the IS literature has emphasized the importance of commitment to IS projects as a key factor in their success [13, 18], strong commitment is not warranted in projects that are failing. Clearly, IS management must strike an appropriate balance between obtaining commitment and resources for promising IS projects and withdrawing commitment or redirecting projects that are failing. Yet, this rather obvious insight seems to have escaped the managers of the many organizations in which patterns of excessive commitment have been documented [1, 3, 14, 17, 25, 36, 38, 45]. In many of these cases, resources were expended long after the first signs of danger were recognized. Thus, it appears that troubled projects often attract additional resources despite clear warning signs.



TURNING AROUND TROUBLED SOFTWARE PROJECTS 65

The social phenomenon manifest in these examples is known as the escalation of commitment to a failing course of action [4]. A considerable body of research has

investigated escalation of commitment in a wide variety of field and laboratory settings, and the resulting theory has been used to explain excessive commitments to IS projects that ultimately failed [21]. However, a theory of escalation is not neces-

sarily a theory about how commitment to failing courses of action can be reversed. In this paper, we define the deescalation of commitment as the reversal of escalating commitments to failing courses of action, either through project termination or redirection. In fact, little is known about how troubled projects can be eventually terminated or successfully turned around. One study of abandoned IS projects, for

example, found that 35 percent of them were not abandoned until the implementation stage of the life cycle [15]. This suggests that IS managers need to identify troubled

projects earlier and to terminate or redirect them before they consume additional resources.

This paper reports on a research project to investigate the deescalation of commitment to runaway software projects. We were specifically interested in the factors that can facilitate movement from a state of escalation to a state of deescalation, ultimately leading to the termination or successful turnaround of escalating IS projects. Some of these deescalation factors have been identified in the literature, but their existence and effects have seldom been observed in field-based investigations of project deescalation. While investigating such factors was one of our objectives, we also sought to

identify relevant actors and actions most commonly associated with deescalation. By actors, we mean the individuals responsible for triggering the transition from escalation to deescalation. By actions, we refer to specific actions taken by individuals to

place such projects under control. Our three research questions were:

1 . In the context of IS projects, what factors are associated with the transition from escalation to deescalation?

2. Which actors most commonly trigger the transition from escalation to deescalation?

3. What actions are most commonly taken to bring troubled projects under control?

Answers to these questions can inform managers and other responsible actors how to turn runaway projects around, thereby improving the productivity of IS development, reducing IS costs, and increasing IS effectiveness.

Background and Theoretical Framework

The Escalation of Commitment Phenomenon

Escalation (or escalation of commitment) behavior has been defined as continued commitment in the face of negative information about prior resource allocations

coupled with "uncertainty surrounding the likelihood of goal attainment" [4]. Under this definition, project escalation can be said to occur when there is continued




commitment to a course of action and negative information concerning the viability of the previously chosen course. X

Many researchers have historically viewed escalation as the result of flawed and irrational decision-making processes. Staw and Ross [41, p. 52], for example, have characterized escalation as "a dysfunctional response." Brockner and Rubin [6, p. 7], however, distinguished between a flawed decision process and a flawed decision outcome, observing that "it is not necessarily the case that the decision to escalate, that is, the behavioral outcome of this process, is irrational." Whyte [48] similarly observed that whether flawed decision processes ultimately lead to rational or irrational outcomes was open to question. Keil and Flatto [22] contended that the decision-

making process that leads to escalation decisions may be perfectly rational, based on the theory of real options. Regardless of one's position on the rationality or irrationality of escalation, there is general agreement that at times, "the tendency for decision makers to continue allocating resources to an ineffective course of action can be

extremely maladaptive, both for individuals and organizations" [5, p. 122]. Several recent studies have shown that escalation of commitment is a promising

theoretical framework for explaining why troubled IS projects continue to receive

support when redirection or termination would be more appropriate [10,21,23,34]. Keil [21] conducted a case study of a system (given the pseudonym CONFIG) that foundered for more than ten years before it was ultimately terminated. The study revealed that a combination of factors drawn from the escalation literature, including project, psychological, social, and organizational factors, helped to prolong CONFIG's troubled existence. Newman and Sabherwal [34] applied escalation theory to explain changes in the level of commitment to a large materials management system project. Their longitudinal case study revealed a sequence of decisions that delayed the implementation of functional system modules for fifteen years following project initiation, at a cost that was

substantially over budget. Once again, a combination of project, psychological, social, and

organizational factors was identified as contributing to the level of commitment. If escalation of commitment occurred only rarely in IS projects, there would be little

cause for concern. Unfortunately, this appears not to be case. In a survey of several hundred information systems auditors conducted by Keil and Mann [23], 81 percent of respondents indicated that one or more of the last five projects they had been associated with involved some degree of project escalation. Keil and Mann defined escalation as unwarranted continuation when redirection or termination would have been the more appropriate response. Respondents were also asked questions designed to produce an estimate of the percentage of IS projects that could be classified as cases of escalation. Based on a subsample of 361 experienced IS audit and control professionals, responses to these questions indicated that escalation occurs in approximately 30-40 percent of all IS projects.

Deescalation of Commitment to Troubled IS Projects

Although less commonly studied, deescalation is potentially a more important research issue because deescalation provides remedies for the ills of escalation. While




escalation studies seek to understand why decision makers increase commitments to failing courses of action, deescalation studies examine how decision makers extricate themselves from escalating commitments. Unfortunately, most of the published studies on deescalation are laboratory experiments rather than field studies, and this raises concerns about the generalizability of their results to organizational settings. Moreover, few published studies on deescalation are relevant to IS project management because researchers manipulate treatments (e.g., self-awareness training) that have little connection to an IS context (e.g., [33]). Our search of the literature identified twelve studies that included factors that were potentially useful for explaining the deescalation of commitment to failing IS projects. Two of these are case studies [21, 37]; the remainder are laboratory experiments. Given the small number of studies available, the literature offers little guidance on

designing a study about the deescalation of commitment to runaway IS projects. Accordingly, the theoretical framework developed for this study is exploratory and

uncomplicated. It identifies twelve factors drawn from prior empirical research and posits an expected relationship to the deescalation of commitment to troubled IS projects. Table 1 summarizes the factors drawn from the literature and the supporting studies. Each of the factors is discussed in more detail below.

1. Change in Top Management Support

The support of top management is frequently considered an important factor in the successful implementation of technological initiatives, including IS projects. The literature also identifies top management support as a factor contributing to the escalation of commitment to projects that are failing [37]. For a variety of psychological, social, and organizational reasons, top management may maintain its commitment to projects that are deeply troubled. Changes in top management may be needed to deescalate commitment to a previously chosen course of action [37]. The change in management allows a fresh appraisal of the project, perhaps along with other assessments, and a chance to reconsider how resources should be allocated. Whether or not the change in top management is precipitated by the troubled project itself, such a change could facilitate deescalation.

2. External Shocks to the Organization

External events, perhaps unrelated to a particular troubled project, may also trigger a general reassessment of resource allocation and allow deescalation to proceed. For example, Keil [21] traced a company's decision to "pull the plug" on a failing project to a financial crisis. Changes in ownership, natural disasters, public scandals, and other events beyond the control of organizational members all qualify as external shocks to the organization.

3. Change in Project Champion

Like changes in top management, changes in project championship may be associated with project redirection. Like top managers, project champions are prone to overcom-




Table 1. Factors Potentially Relevant to IS Project Deescalation

Factors affecting deescalation Supporting studies

1. Change in top management support [37] 2. External shocks to the organization [21 ] 3. Change in project champion [21] 4. Organizational tolerance for failure [40] 5. The presence of publicly stated resource limits [7, 19, 40] 6. Consideration of alternative uses of funds supporting a [24, 29, 35]

project 7. Awareness of problems facing the project [1 6] 8. Visibility of project costs [7] 9. Clarity of criteria for success and failure [40]

10. Organizational practices for evaluating decision [40] makers: process vs. outcome

11. Regular evaluation of projects [9] 12. Separation of responsibility for approving and [2]

evaluating projects

mitment to courses of action [21]. When project champions leave, or are removed, it is often easier for commitments to be reassessed and deescalated.

4. Organizational Tolerance for Failure

Escalation theorists have long argued that reducing the threat posed by negative outcomes could be a useful deescalation strategy [42]. By not imposing severe punishment for failures, it is argued that organizations can encourage deescalation. A laboratory study by Simonson and Staw [40] offers some empirical evidence in support of this notion. These authors found that a threat-reduction manipulation resulted in deescalation of commitment. In an organizational environment, threat reduction can be implemented in many different ways. Theoretically, any threat-reduction strategy that decreases an individual's tendency to engage in self-justification can help promote deescalation. One approach, therefore, would be to increase an organization's level of tolerance for failure.

5. The Presence of Publicly Stated Resource Limits

One way to induce deescalation is to publicly state limits, beyond which a project will cease to receive support. This is more easily said than done. Many cases of escalation begin with stated budgets and targeted completion times, but these are changed or ignored as the project heads into troubled waters. However, Brockner, Shaw, and Rubin [7] found that, when such limits were publicly stated, decision makers were more likely to follow them. Heath [19] supports this finding with reference to the "mental budgets" that decision makers set for themselves.




6. Consideration of Alternative Uses of Funds Supporting a Project

This factor acknowledges that project escalation carries potentially high opportunity costs: the inability to apply allocated funds to other projects that may enjoy higher return on investment. Awareness of alternative uses is typically hidden during esca-

lation, but increased costs and/or delays may bring this factor into greater awareness

[29]. Several laboratory experiments provide evidence that the consideration of alternative uses of the funds supporting a project (i.e., opportunity costs) can promote deescalation [24, 29, 35].

7. Awareness of Problems Facing the Project

IS projects are often characterized by very complex problems. During escalation of commitment to projects, potential problems are often hidden by the expectations of

project benefits. When more realistic assessments of a project's technical and social

complexities are made, however, deescalation of commitment may follow. Garland, Sandefur, and Rogers [16] found that experimental subjects chose to deescalate commitment when they received unambiguously negative feedback about project progress. Thus, when the perceived costs of proceeding with a project outweighed the

benefits, deescalation was chosen over continued escalation.

8. Visibility of Project Costs

When costs are more visible or salient, this is believed to promote deescalation. In a

laboratory experiment, Brockner et al. [7] showed that, when subjects were assigned to a condition in which continuation occurred unless a decision to terminate was made

(self-sustaining condition), they were more likely to escalate commitment than sub-

jects assigned to a condition in which continuation required an active decision

(self-terminating condition). Their interpretation was that forcing subjects into an active decision made the costs of continuation more salient. These findings are consistent with an earlier study by Rubin and Brockner [39] in which escalation was more likely when information about costs was less salient. Unfortunately, field settings may hide or distort knowledge of problems and associated costs. Thus, an additional factor is the visibility of project costs [7].

9. Clarity of Criteria for Success and Failure

One explanation for escalation is the lack of clarity about the criteria for success and failure. If a project's participants do not know that they are failing, they may be more likely to

expend resources. In a laboratory experiment, Simonson and Staw [40] found that goal setting had a significant impact on deescalation behavior. This finding suggests that clear statements of threshold criteria for success may lead to the deescalation of commitment.

10. Organizational Practices for Evaluating Decision Makers: Process Versus Outcome

Some organizations emphasize the attainment of outcomes rather than the means for

obtaining outcomes. Simonson and Staw [40] found that deescalation was promoted




by removing the threats of negative outcomes and by rewarding decision makers on the basis of their decision processes rather than their outcomes. In this way, some of the psychological pressures faced by decision makers could be mitigated and sustained commitment in the face of problems reduced. While it is similar to factor 4, factor 10 focuses on the type of measure for which actors are held responsible but does not imply either a high or low tolerance for failure.

11. Regular Evaluation of Projects

Many escalating projects proceed with little monitoring or review. Reviews may be irregular and inconsequential, giving project champions and managers the sense of a free rein. Where regular project reviews and evaluations are conducted, deescalation of commitment to failing projects is likely to be encouraged [9].

12. Separation of Responsibility for Approving and Evaluating Projects

A time-honored principle of auditing is to separate the responsibility for allocating resources from the responsibility for evaluating projects. Decision makers are not likely to be objective in evaluating projects that they have championed or to which they have harnessed their own careers. An independent audit is more likely to produce objective evidence and to lead to the deescalation of commitment to runaway projects [2].

Each of these twelve factors offers a partial explanation for the deescalation of commitment to troubled IS projects. In the supporting research, a variety of theories have been used to explain both rational and nonrational decision processes. Our purpose is not to test these particular theories but, rather, to use the findings generated to explore project deescalation in the context of IS.

To date, we know of only a few studies that have explicitly examined the withdrawal processes that have followed episodes of escalation [10, 21, 34, 37]. Since each of these studies involves a single case study, the deescalation models presented may be highly idiosyncratic. For example, Ross and Staw's [37] study of the Shoreham nuclear power plant presented a model in which deescalation was achieved through changes in top management, efforts to deinstitutionalize the project, appeals to organizational constituencies, and threats to persevere. While each of these factors was observed in the Shoreham case, we do not know the extent to which they generalize to other cases. What is needed is a more generalizable, process-oriented model of deescalation that is not so case specific.

Method

The research design was a field survey of IS auditors who had experience with IS projects that had gone through both a period of escalation and a period of deescalation. Respondents were drawn from a population of seventy-five IS auditors who indicated a willingness to participate in a followup study when they completed




an earlier mail survey in 1995 [27]. The earlier study investigated the frequency and

severity of IS project escalation and included more than five hundred respondents. IS auditors were chosen for study because of their role in monitoring IS projects. Auditors are a preferred source of information about troubled IS projects because they are likely to be more objective than IS managers or project team members. All data for the

present study were collected through telephone interviews. Rather than specify a precise sample size in advance, we followed the principle of

purposive sampling recommended for research that is exploring new ground instead of testing established theories. In contrast to random sampling, purposive sampling calls for collecting data until meaningful patterns and relationships are detected and until "no new information is forthcoming from newly sampled units" [26, p. 202]. This

point was reached after forty-two interviews, yielding thirty-nine usable cases. Three cases were excluded from analysis because the projects involved were still escalating and therefore inappropriate for our sample.

The unit of analysis for this study is the project; each respondent was asked to choose a single project for the interview. In most cases, the project was the same as the one identified in the earlier survey. The projects selected represented a broad range of

system applications, including major accounting systems, enterprise resource planning packages, human resources/payroll systems, a catalog sales system, a contract-

compliance tracking system, and numerous others. The companies in which these

systems were developed also represented a broad range of organizations and indus-

tries, thus ensuring a diverse sample. The interviews were conducted using a protocol that consisted of two unstructured

portions and one structured portion. The initial unstructured portion prompted the

respondent to tell a story of the events surrounding the project. During this portion of the interview, the respondent was encouraged to identify the point in the project where escalation ceased and deescalation began, and to recollect the actions that led to deescalation of commitment. The escalation phase was defined as the period during which the respondent believed that the project needed to be terminated or redirected but instead continued to receive resources. The deescalation phase was defined as the

period after which a decision was made either to terminate or to redirect the project. The structured portion asked questions developed to measure the degree to which each of the factors was present, in both the escalation and deescalation phases of the project. Responses were recorded on a five-point scale (1 = low, 5 = high).

The interview protocol was refined after the initial five interviews to bring explicit attention to the identification of individual factors as either causes or consequences of

project deescalation. Respondents who identified a difference between the phases for a given factor were, therefore, asked to clarify the role of the factor as either a cause or a consequence of deescalation. At the end of the structured portion of the interview, a second unstructured portion allowed the respondent to identify and discuss any other factors or events that may have accounted for the deescalation of commitment to the

project. Interviews typically lasted between thirty and sixty minutes.

Responses to the structured portion of the interviews were subjected to paired Mests for each factor. The tests compared the mean responses on each factor during the




escalation phase of the project with the mean responses on each factor during the deescalation phase. Moreover, the frequency with which each factor was identified as either a cause or a consequence of deescalation was recorded. The unstructured

portions of all interviews, including digressions in response to the structured questions, were tape-recorded and transcribed for analysis. The researchers also recorded notes

during the interviews. The qualitative analysis proceeded iteratively. Both researchers were engaged in

every iteration, reaching agreement on all assigned codes.2 First, we "open-coded" each case to capture the events that caused the project to move from the escalation

phase to the deescalation phase. In open coding, the researchers operate without

predetermined codes and allow the data to suggest categories [43] . To facilitate coding, portions of the interview text were located in which the respondent answered the direct

question: "What caused the project to move from the escalation phase to the deescalation phase?" From the responses, we constructed paraphrased narratives for use in later analysis. Typical narratives consisted of approximately 150 words, which, although constructed by the researchers, contained the essence of the respondent's language. In most cases, the narrative captured both the actor(s) and actions that

triggered deescalation. Constructing case narratives is a recommended practice for

becoming "intimately familiar" with each case before cross-case analysis is undertaken [12, p. 540]. With thirty-nine cases of deescalation to consider, this approach to

writing narratives greatly facilitated our analysis. The open coding produced seven groups of deescalation scenarios, summarized in

the appendix. Although the researchers agreed with the assignment of cases to these

categories, we were dissatisfied with the classification scheme. Categories were not

mutually exclusive, they mixed factors and processes, and they were not uniform in

specifying actors and actions. Therefore, we coded each case twice more, first

identifying actors who triggered deescalation and second specifying the actions that were taken. In effect, these coding steps allowed the data analysis to correspond more

directly with our research questions.

Results and Discussion

The presentation of results and discussion is organized around the three research questions. For each research question, we have chosen to integrate results with discussion instead of separating them into distinct sections.

Factors Associated with Deescalation

To address the first research question, we undertook a quantitative analysis of the data collected in the structured portion of our interview protocol, testing for differences between the escalation phase and deescalation phase levels of the various factors believed to be associated with deescalation. This analysis, based on paired /-tests, identified the factors that changed as projects moved from a state of escalation to a state of deescalation. The results of the analysis, shown in Table 2, reveal that seven




of the twelve factors manifest significant differences between the escalation and deescalation phases. Table 2 also reports the frequency with which each factor was identified as either a cause or a consequence of the deescalation phase and the cause-to-consequence ratio for each factor.

The evidence presented in Table 2 shows that the profile of the deescalation phase of a project differs from the profile of the escalation phase. Specifically, the deescalation phase is associated with significantly less tolerance for failure and significantly more publicly stated limits, more awareness of problems, more clarity of criteria for success or failure, more outcome-oriented evaluations, more regular evaluation of projects, and more separation of responsibility for approving and evaluating projects. Overall, project management in a period of deescalating commitment is somewhat "tighter" than when commitment to projects is escalating.

However, it is important to note that the factors explored in this study were not always identified as causes of deescalation; instead they were often seen as consequences of a decision to redirect a troubled project. As the data in Table 2 indicate, all of the factors in our study were mentioned at least once as a cause of deescalation and as a consequence. Overall, eighty-four mentions of cause and fifty-nine mentions of consequence were reported. Several, such as evaluation (factor 1 1), are seen almost equally as causes and consequences. Thus, we conclude that several different factors contribute to deescalation and that a factor that is causal in one context may be a consequence in a different context.

Several observations can be made from these results. We begin with an examination of the factors that did not exhibit significant changes as projects moved from escalation to deescalation. While the absence of a significant difference does not prove that a factor is unimportant, it does suggest some interesting possibilities for further investigation. In this light, we find it interesting that the shift from escalation to deescalation was not associated (on average) with a change in the level of top management support or championship. One explanation for this result is that management support and championship are needed as much during the deescalation phase as they are during the escalation phase, but that support and championship take a different form in each phase. In other words, the support and championship shift to a new course of action but are still present. When changes in support and championship did occur, they were viewed as consequences of deescalation as often as they were viewed as causes of deescalation.

Likewise, consideration of alternative uses of the funds supporting a project and the visibility of project costs did not change significantly when the projects moved from escalation to deescalation. This suggests that decision makers are at least somewhat aware of the costs associated with the project during the escalation phase and that the shift to deescalation does not result from a consideration of alternative uses of the funds supporting a project. Neither of these factors was frequently mentioned as a cause of deescalation. Visibility of project costs, in particular, was cited as a consequence of deescalation far more frequently than it was cited as a causal factor.

Another interesting observation is that the shift from escalation to deescalation was not associated with a change in the level of external shocks to the organization. This does not mean that external shocks do not trigger deescalation. In fact (in contrast to



74

2 Q

!

§ I 1 g

I Co

I S

f2

III 8 8 8¡C 8 8 8 33 8 S8 ogÇi-odi-o^T- evi d T-" evi os

o « 8.1 t?8 SS

•g ed e

m S S "co <o °° o>oo co m o ^o ^- or^

£ ® ° « u. E xi

o)iôo>«j§§<õ S »88 88 OTcccddc ÖCÖÖ dö

Î 8 S8 S^ S| 8 SSB» ?S| |

^ o ^oi c|i ^

^ ^^ ^ ^

CÜCOCNÍCOCVÍCÜt- COCOCOCO COCO

4- <D ^ "O

2 c §1 S !? SS 8 S 2 §S S SS C(öcoc'icoc'ic'ic'i co coevi cj evi evi CD 0)

i |§ >• li» 1 »§ «-S lì?

I 1 il I il I 11 t|l||1 t Jgi| 8».i| o il llã|-sl §,|l| |,|| 15 j"8|. iff U ¡ili li f

2 üoluoüO-Si- Bü3ig<£>ü<tO*iiDl(i)itiu.

^ r «i o * i« d s nioi o t^c'¡




the other nonsignificant factors discussed above), external shocks exhibited a high cause-to-consequence ratio (see Table 2), implying that, when they do occur, they are far more often seen as a cause, rather than as a consequence, of deescalation. The combination of these two findings suggests that external shocks can indeed contribute to deescalation, but that the level of turmoil in the external environment is not

appreciably different between escalation and deescalation periods. Having discussed the factors that did not change, we now examine the seven factors

that exhibited significant differences between escalation and deescalation. The first such factor in Table 2 involves the organization's tolerance for failure. The level of tolerance for failure showed a significant decrease as projects moved from a state of escalation to a state of deescalation. The direction of movement is opposite to the direction suggested in the escalation literature. The data indicate that organizations did not reduce the threat posed by negative outcomes; instead they increased it. Consistent with this observation, organizational practices for evaluating decision makers tended to shift from process- to outcome-based measures as projects moved from escalation to deescalation. However, organizational tolerance for failure was not

frequently mentioned as a cause of deescalation and was more frequently seen as a

consequence. Similarly, organizational practices for evaluating decision makers were not often seen as a cause of deescalation.

All of the remaining factors exhibited changes that were consistent with prior literature. Among these factors, however, the separation of responsibility for approving and evaluating projects had the highest cause-to-consequence ratio, followed by the presence of publicly stated limits, an awareness of problems facing the project, and the clarity of success criteria. Regular evaluation of projects was the only other factor that exhibited a significant change from escalation to deescalation. This factor, however, was more often seen as a consequence of deescalation as opposed to a cause.

Actors Responsible for Triggering Deescalation

Seven categories of actor, shown in Table 3, were generated from the qualitative analysis. Table 3 also includes excerpts from the interviews to illustrate the specific types of actors involved.

Top management was most frequently mentioned as the actor who triggered deescalation. Other frequently cited actors included internal IS auditors and external auditors/consultants. Collectively, these three categories of actors accounted for 63

percent of the cases in our sample, suggesting that actors who are not directly involved in projects are more likely to trigger deescalation. By comparison, users, project team

members, and I S managers were cited less frequently, suggesting that these actors may be too committed or too close to projects to turn them around.

Actions Taken to Bring Troubled Projects Under Control

Following the identification of actors, we developed codes for the types of action taken to turn around escalating projects. The eight categories of action are shown in Table 4. These




Table 3. Coding of Projects by Actor Who Triggered Deescalation

Actor code and (frequency) Sample excerpts and case number (in parentheses)

Top management (1 3) It just became untenable, where they were so far behind schedule and so far over budget that senior management . . . intervened finally and said: "Look, we're not going to keep pouring money into this thing." It just ended up being a huge, huge albatross that kept sucking money and it was like there was no end to it. Kind of like Vietnam, we just declared victory. (044)

Internal IS auditor (6) Once they continued to try to escalate and weren't getting anywhere, audit came in and looked at it and found out what the true actual money spent on the project was, how many problems there were, how much testing still needed to be done in order to meet their projected dates. (503)

External auditor/ We came in as external auditors as part of our annual work, consultant (5) working with their internal auditors, and found that the

project really was off track ... We took a look at it just kind of ballpark numbers and originally said: "Why is management not coming in here and not kicking your butts? It's way over budget already." (174)

IS users (4) So, they built their database, and they got all their programs all designed and they actually implemented that and the performance was less than satisfactory. So they went along with it for, oh probably, six to nine months and just decided it was such a problem that they were going to go back to doing it manually, and basically stopped using the system for the billing part of it. (331)

IS project team The project team themselves approached the steering members (4) committee, if you will, that was set up for this project, and

told them that no way, about 30-60 days prior to the original implementation date that, no way could they possibly make this particular project. (459)

IS management (3) A new Chief Technology Officer was brought into the chain. His marching orders were most specifically to get that system installed. He took, obviously, not day-to-day ownership, but clearly executive ownership of the system. (337)

Unspecified (4) Total (39)

actions are grouped into two larger categories: project management and resource management, with the former more commonly observed than the latter. The total number of codes for this analysis, fifty-nine, exceeds the number of projects, thirty- nine, because several projects included multiple actions. There is no claim or reason




Table 4. Coding of Projects by Action Taken to Cause Deescalation

Types of actions and

(frequency) Sample excerpts and (case numbers)

Project management Redefine the There were moves to get it to a smaller product or project, get it project (17) to a highly defined thing they could deliver with not a bunch of

bells and whistles. All the bells and whistles were going to be add-ons. (125)

The Executive VP in charge of IS asked if there were things that folks had asked for that weren't in the original project. They had already spent $1 million on design but had nothing to show for it really Folks were told to go back to the drawing board and see if they could remove some functionality that wasn't in the original plan. They decided to build an Olds or a Buick instead of a Cadillac. (209)

We spent all the money and they had to continue to go back to the board asking for more and indicating why the initial time frame didn't get met. But, they carved it up, they redid the project, resubmitted new numbers, and got a recommitment from both internal and external sources to get it back on track, to deliver what needed to be done and make it work. (348)

Improve project The executives requested a weekly update meeting so we started management (1 0) meeting weekly ... We would update them on what had

happened, what hadn't, where the original schedule was, where we were . . . (200)

The "concept of processes" was applied to this and then also the concept of building the infrastructure for the rollout was put in place. As they were able to develop the tools and the standards that would be applicable to all those stages and also to develop the process for conversion . . . [this] started to bring things back into a more orderly form. (500)

Change in project They replaced the project manager with someone more leadership (8) knowledgeable in the tools and techniques. (283)

[As consultants] we were asked to do an assessment of the architecture and assist them in their design phases We decided that this could not continue the way it was being managed. [Ultimately] we became the complete controller of the project and we still had the project manager from the user community report to us on the project. But, we reported directly to the CFO and the CIO, so the project was really basically turned over to us. (1 61 )

why the actions taken to cause deescalation should be mutually exclusive. Included in Table 4 are excerpts from the interviews to illustrate the specific types of action taken.




fable 4. Continued

Types of actions and

(frequency) Sample excerpts and (case number) Subdivide the We actually dissected the project in order to meet a portion of the project (5) target date. We took just our residential customers. (1 09) We put

out about a three-year rollout schedule to get this project in and that seemed to work out well because we were up front with everyone about what was going to happen. [Before] they were almost trying to deliver everything at once so, by delivering pieces of the project everyone started feeling better because things were starting to be delivered. (161)

Resolve specific The company who we purchased let [the vendor] read the specs problems (5) but not copy over the coding and anything else. So they had to look

at screens, look at output reports, as opposed to looking at the programs, which made the conversion and calculations for the fields a lot more complicated than what they thought originally. (459) The project was redirected in terms of a couple of things, first, they considered what kind of technology they could get, what kind of hardware they were going to get in the future, would they buy second hand equipment, would they lease, would they purchase. . . (80) [They] moved it down to a client-server platform because the software package that we had used on the mainframe was no longer being supported. (44)

Resource management

Adding and/or They put in new management and there was additional staffing in removing both permanent [positions] and contractors that were hired. And a resources (8) more organized effort was put into place to build the infrastructure

behind it to: (1 ) support the existing network that had been put into place, and (2) go forward and make sure there was adequate project development resources in place as they went forward with the deployment. (500) They didn't go out and get external assistance, but they brought the right people in to do the project and took an additional two years. (306)

Layoff and hiring (4) The head IS person at the company was fired They brought in another guy, same thing happened to him ... at least two of the MIS directors were dismissed. (418) One year after the original target completion date the project was only about 50 percent complete, so top management fired the director of the user group. (86)

Training (2) They also tried to escalate the removal of the legacy system and remove the dependency on that system as quickly as possible and to improve training to get those users off those systems. (80) We also, other than just coding, testing, we had training, how to use this thing, and that had to be coordinated statewide. (109)

Total: 59




As Table 4 indicates, the project management category included five actions that were taken to bring troubled projects under control. Most common among these actions were a redefinition of the project, an improvement in project management, and a change in leadership. Project redefinition includes reducing the scope of projects, rejustifying them financially, and focusing on the most important features and deliv- erables. The excerpt drawn from case no. 1 25, for example, shows how the respondent reported the redefinition of a very large database project that had escalated for a very long period. By removing the "bells and whistles," a less complex system could be delivered sooner. Case no. 348 illustrates a financial rejustification in which previous budget overruns were incorporated into a new plan for continuing a project at a reduced

funding level.

Improvement in project management includes more regular meetings and reviews, more precise scheduling of delivery for system modules, and other means for exercis-

ing tighter control over projects. In case no. 200, for example, which involved the

development of a system to support catalog sales, the senior executives of the company instituted weekly update meetings in order to keep closer tabs on the project. Improve- ment in project management also includes more careful adherence to system devel-

opment methodologies and processes, as illustrated by case no. 500.

Change in project leadership involves the replacement of project leaders associated with the escalation of the project with new leadership, either from inside or from

outside an organization. In many cases, this means replacing the project manager, as illustrated in the excerpt from case no. 283. In some instances, project management responsibilities are handed over to an external consultant, as illustrated by case no. 161 .

Another action that occurred in five cases is the subdivision of the project into

manageable portions. Similar to project redefinition, subdivision identifies pieces of a larger project that can be worked on separately from the entire project. Language used by respondents to describe this action included reference to pieces, chunks, and dissection. For example, the excerpt drawn from case no. 109 concerns a project undertaken by a natural gas utility serving both residential and commercial customers. This project involved the modification of packaged software for automated meter

reading using hand-held computers. Among the key problems with the project were an unrealistic target date, inadequate project planning, and software that was still being tested. In order to make the project more manageable, a decision was made to focus solely on the company's residential customers during the first phase of the project. As a result, "serious problems that would have caused cancellation of the project were resolved."

The final project management category is resolving specific problems. Most often, such problems involved external relationships or technical issues, as illustrated in the

excerpts shown in Table 4. External relationships could involve software licensing issues (as in case no. 459) or other problems with software vendors. Technical issues include the resolution of hardware or software problems and the difficulties that are

frequently associated with migration to new hardware and software architectures (as in case no. 44).

The resource management category included three actions that were taken to bring troubled projects under control. The first group, adding and/or removing resources,




mostly includes cases where projects were brought under control by adding resources. Although this may seem like continued escalation, additional resources that were more carefully managed were essential to bringing redefined projects to completion. Both cases no. 500 and no. 306 indicate added resources, which in the latter case were better managed.

Similarly, layoff and hiring involve a change in resources but extend to human resources outside the project. In some cases (e.g., no. 418), the head of IS was fired; in other cases users were fired (e.g., no. 86). In addition to layoffs, there were cases in which more qualified human resources were brought onto a project. Finally, training is an action undertaken in two cases to turn projects around. Similar

to hiring additional resources, training enhances existing resources and requires additional investment.

Toward a Process Model of Deescalation

AS STATED EARLIER, THE EXAMINATION OF THE THREE RESEARCH QUESTIONS was not

guided by any specific theory. Our research model simply identified twelve factors believed to contribute to project deescalation. On the basis of our quantitative analysis, we could offer a more parsimonious model of the factors that contribute to deescalation. That is, five of the twelve factors studied would be eliminated based on the nonsignificant differences reported in Table 1 . Unfortunately, such a model does little to advance our understanding of how deescalation is triggered and how it proceeds. Thus, we propose a more ambitious, process model of deescalation that builds on our qualitative findings. The model presented in figure 1 introduces new concepts and data not used above in addressing the three research questions.

The model proposes that deescalation begins with the detection of negative information about a project by an actor either observing or engaged in a project. On the basis of results related to the second research question, the actor is most likely to be a senior manager or an external or internal auditor. But the actor may also be a user, an IS manager, or anyone else who is in a position to observe that the project is in serious trouble. The model suggests that detection of negative information is insufficient to trigger deescalation. Indeed, the literature on escalation of commitment demonstrates consistently that negative information (by itself) is insufficient to deter escalation, even when a project is in serious jeopardy. In most cases, negative information needs to be transmitted to another actor who is authorized to take corrective action, as depicted in figure 1. Following the receipt of this information, the actor in authority responds either by continuing to commit resources to the failing project or by taking corrective action to either terminate or redirect it.

The model does not specify the conditions under which detecting actors will communicate a message to an actor in authority. Clearly, the mere presence of squandered resources does not provide the incentive for actors to signal that trouble exists, especially where implicit penalties exist for conveying bad news. Many actors are reluctant to transmit bad news, instead choosing to remain mum. Research on the "mum effect" [44] and its logical inverse, whistleblowing [30], has identified numer-




Continued commitment to failing course of action

(escalation) Actor

observing or , - 1 ^* f. , Actor with ^^ roiect Message responsibility and ^^

detects roiect * authority to take <JJesponse

negative detects

| corrective action

| '^^ information i - 7-. - , /* + t- - : 1 I i Action taken , + to redirect t- : or terminate troubled project

(de-escalation)

Figure 1. A Process Model of Project Deescalation

ous factors that may affect one's willingness to transmit bad news. Despite its noble aims, whistleblowing is not seen as a legitimate activity in most organizations [8], and publicized stories such as that of Karen Silkwood provide tangible evidence of the risks to the whistleblower [46] .4 The first implication of the model, therefore, is that deescalation can only occur when the mum effect is overcome and negative information is passed along to an appropriate authority.

Our interviews revealed just how difficult it was, even for an auditor, to overcome the "mum effect." The following remarks were typical:

[Blowing the whistle would] probably be career suicide to be honest Me as a little staff auditor, I'm going to go to the Executive VP of the company and tell him that this is a worthless project and he should pull the plug on it? I sure wouldn't want to march into this guy's office and tell him the project that he had been championing for all these years should be put to death. [Case no. 44]

It would have been political suicide to go and to speak up for those of us that had bills to pay and all ofthat other good stuff- you do what you're asked to do. And, I wasn't asked to. I had some pretty candid conversations with the man that I worked for, and told him, I said that there are so many things here that are going wrong, how can we continue to do this? Because we have to do it, that's our job. And, maybe if I had had the support of my manager, I would have felt more comfortable going to the next level to tell him. But, I wasn't going to go in there by myself. . . . I've been the whistleblower once in my life, and wound up standing on the unemployment line, and I decided with a house and a family there was no way I was going to put myself in that position. [Case no. 14]

Despite the difficulties and risks involved, there were a significant number of cases in which whistleblowing did occur and was seen as instrumental in bringing about deescalation. In many cases, bad news was detected and conveyed by an individual investigating problems in IS projects, often an IS auditor or an external consultant. One such example involved an IS audit manager who took the case to the company's




board of directors, which ultimately canceled the project:

I went to the audit director and I said "we have to stop this, it can crash our core business processes." So, we made some calls and we stopped the project. [Case no. 182]

In another case (no. 1 74), the project escalated out of control until the external auditor detected problems during an invited project review. Likewise, in case no. 4 1 7, an external consultant was brought in to review the design of a system and ended up in a whistleblowing role:

We were actually asked to look at the design, but we found that it was a very difficult task to do because the project management was so shoddy that we could not. We just were not comfortable at all with anything that we were seeing. So, what we ended up doing was providing comments to the controller, and essentially to the executive management of the company, that the project management was very poor. [Case no. 418]

The passing of information may be a necessary condition for deescalation, but it is not sufficient for deescalation to occur. Actors in authoritative positions must also be

receptive to such signals and be willing to take corrective action. Many times they are

not, and turn a deaf ear to signs of trouble. We call this the "deaf effect" and, although it is not as well understood as the mum effect, we believe that it is equally important in explaining why deescalation is often so difficult to achieve. By remaining deaf in the presence of trouble, actors may hope to avoid dealing with difficult problems. They may also remain deaf to disassociate themselves from a failing endeavor. The deaf effect is illustrated by one respondent who, in the role of internal auditor, failed in his

attempt to get the attention of the vice president of IS and eventually went over his head to top management:

The VP of IS, who was since fired, was kind of a hear-no-evil, see-no-evil. He was really covering up for ... the big leaks that he dealt with. And, while us lowly peons were saying, we've got a problem, we got a problem, the head guy was saying to [company] IS and to [company] executives, the CEO and all those people, there's no problem. Those of us who were working on the team, and I was like the auditor on the team, we started to issue memos to higher ups, our executives. [Case no. 200]

Another auditor recounted an experience in which management turned a deaf ear to

negative information:

I wrote a lot of reports. I escalated things as much as I could but in the end, they basically said, "we really appreciate your efforts, but thanks but no thanks." They took me out to lunch and said, "We really appreciate what you've done, but we really won't be needing you anymore."

The deaf effect is also evident in published reports of other escalating projects. For

example, the Taurus project had become so institutionalized that it was extremely difficult for the chief executive of the London Stock Exchange to persuade key decision makers to scrap the project:

These were big men . . . [yet] the plain fact of the matter is that they were terrified. "What do you mean we might have to stop this? How can you say that now?" . . . They didn't believe it They wanted to believe I was wrong. They were fighting to find some reason to carry on. [ 1 0, p. 151]




Drummond [10] argues that the transmittal of unambiguously negative information is insufficient to trigger deescalation because key decision makers remain convinced that project completion is critical. Thus, the would-be whistleblower must wield sufficient power to challenge this conviction. According to Drummond [10], there can be no deescalation until the prevailing myth that the project must be completed is

replaced with a new myth. Once again, this suggests that overcoming the mum effect is a necessary, but not sufficient condition, to produce deescalation. Indeed, as our model implies, it is necessary to overcome both the mum effect and the deaf effect to

bring about deescalation.

Summary and Conclusions

Through interviews with forty-two IS auditors, we gathered both quantitative and qualitative data about the deescalation of commitment to troubled software

projects. The interviews sought judgments about the importance of twelve factors derived from a review of the literature on deescalation. Data analysis revealed that seven of these factors showed a significant difference between the escalation and deescalation periods of a project's history. Many of these factors were seen as direct causes of deescalation. A qualitative analysis of our interview data provided a

categorization of actors involved in triggering deescalation along with the actions taken to turn troubled projects around. In the majority of cases, actors such as senior

managers, internal auditors, or external consultants triggered deescalation. Deescala- tion was achieved both by managing existing resources better and by changing the level of resources committed to the project. The most common actions used to turn troubled projects around were (1) redefining the project, (2) improving project management, and (3) changing project leadership.

We developed a process model of project deescalation that captures two essential features that we observed among many of the cases we studied. Central to our model is the notion that "bad news" on a project must be communicated from the

actor(s) who are in a position to observe it to the actor(s) who are in a position to do something about it. This means overcoming the "mum effect," a reluctance to transmit bad news. But transmittal alone is not always enough, for in many cases the bad news is communicated to those who are unwilling to listen, a phenomenon we call the "deaf effect." Deescalation requires overcoming both the deaf effect and the mum effect.

Once both the mum and deaf effects are overcome, our research demonstrates that a large variety of specific actions may bring troubled projects under control. Managers described by our respondents were quite resourceful in finding ways to deescalate the commitment to troubled projects, often salvaging valuable work and delivering a

functioning system soon after problems were recognized. Our analysis shows, coun-

terintuitively, that deescalation sometimes involved an increase of resources. It also shows unequivocally that deescalating projects were managed quite differently than

escalating projects. Among other things, there were more reviews, clearer criteria established for what constitutes success, and less tolerance for failure. None of these




actions can be introduced, however, unless organizations provide mechanisms that will ensure that bad news will be delivered when detected and will guide action when delivered.

Limitations

Several limitations in our research should be noted. Obviously, our

findings are affected by the source of our data, a sample of internal IS auditors. Auditor roles are created in organizations to overcome mum and deaf effects, and

many of our respondents portrayed their roles favorably. This may have cast other

participants in projects in a more negative light, as guilty parties whose indiscre- tions were uncovered by diligent auditors. Despite the possibility of a self-righ- teous bias from our respondents, we believe the sample also has distinctive

strengths in a study of project management. Auditors do not have directly vested interests in project outcomes; their careers are unlikely to be made or broken by a

project's success or failure. Thus, they may report more objectively than managers and participants in projects. Auditors also have access to objective data on project performance, and they have experience with multiple projects and formal standards for judging projects. These considerations make auditors a reliable source of information about projects. With rare exceptions (e.g., [47]), IS auditing is not

given much attention in the IS research literature. It is hoped that this study will stimulate future research into the audit function.

It is also conceivable that the auditors in our sample introduced bias by choosing projects of particular interest to them. Perhaps these were the biggest horror stories

they could tell, or perhaps these were the stories in which the auditors played the most heroic roles. While this method of sampling introduces such possibilities, we were

impressed by the great variety of story lines told. Indeed, many auditors candidly revealed their own reluctance to blow the whistle on runaway projects by remaining mum. Projects also varied in scope and complexity, suggesting that a representative sample of projects was obtained.

Future research should provide a more direct test of the model shown in figure 1 . Because this model is derived inductively from the qualitative data in this study, we cannot perform a rigorous test of it with the same data. However, a new study could examine project deescalation as a process in which bad news is sent and received and in which actors take various actions to turn troubled projects around. Future research could also address the question of when deescalation actions should be taken. The

present study does not address the question of timing of the deescalation effort, but it provides the necessary groundwork for examining such questions in the future.

Based on the research presented here, managers should be better informed about the actions available to them in preventing project escalation. Overcoming the mum and deaf effects is not easy, according to many of our respondents. Nor are the actions useful in turning projects around easy to initiate. Nonetheless, project escalation is a serious problem that prevents much of the potential benefit from IS projects from ever being realized. Consequently, it is essential for IT managers to direct attention to this




interesting phenomenon, understand it, and take the actions necessary to regain control of troubled projects. Research that extends the knowledge claims in this paper can support management's quest for more successful IS projects.

NOTES

Acknowledgments: This research was supported by a grant from the David D. Lattanze Center for Executive Studies in Information Systems. The authors also acknowledge the support of Marie-Claude Boudreau, David Gefen, Perry Lamb, and Joan Mann in conducting this research. An earlier version of this paper was presented at the International Conference on Information Systems, 1997.

1. Previous research suggests that escalation is a complex phenomenon that may be influenced by many different factors. Based on a review of the literature, Staw and Ross [42] provide a useful taxonomy that groups these factors into four categories: project factors, psychological factors, social factors, and structural factors.

2. It is common for multiple researchers first to establish a high degree of interrater reliability in coding text, then to code text independently. The relatively small number of respondents and the shortness of the narratives permitted us to discuss each narrative together and to agree upon its classification.

3. Although our study utilized qualitative analysis methods that are often applied to case study research, we do not claim that the design is a comparative case study. The relatively large number of cases in our sample prevents a detailed analysis of individual cases. Nonetheless, analysis methods drawn from case study research are appropriate.

4. Karen Silkwood was a worker in the Kerr-Mcuee Company s plutonium plant. She was critical of the plant's health and safety procedures and was preparing to present evidence to a reporter for the New York Times when she was found murdered. The evidence was never recovered, although Silkwood's cause was championed in a major motion picture about her.

REFERENCES

1 . Anthes, G.H. 1RS project failures cost taxpayers $50B annually. Computerworld (Octo- ber 14, 1996), 73-74.

2. Barton, S.L.; Duchon, D.; and Dunegan, K.J. An empirical test of Staw and Ross s prescriptions for the management of escalation of commitment behavior in organizations. Decision Sciences, 20 (1989), 532-544.

3. Betts, M. Feds debate handling of failing IS projects. Computerworld (November 2, 1992), 103.

4. Brockner, J. The escalation ot commitment to a tailing course ot action: toward theoretical progress. Academy of Management Review* 17 A (1992), 39-61.

5. Brockner, J.; Houser, R.; Birnbaum, G.; Lloyd, K.; Deitcher, J.; Nathanson, S.; and Rubin, J.Z. Escalation of commitment to an ineffective course of action: the effect of feedback having negative implications for self-identity. Administrative Science Quarterly, 31 (1986), 109-126.

o. BrocKner, j., ana Kuoin, j.z,. entrapment in escalating conflicts: a òociai rsycno- logical Analysis. New York: Springer- Verlag, 1985.

7. Brockner, J.; bhaw, M.C; and Rubin, J.Z. factors anectmg withdrawal from an escalating conflict: Quitting before it's too late. Journal o/Experimental Social Psychology, 75(1979), 492-503.

8. Dozier, J.B., and Miceli, M.P. Potential predictors of whistle-blowing: a prosocial behavior perspective. Academy of Management Review, 10 (1985), 823-836.

9. Drummond, H. Deescalation m decision making: a case ot a disastrous partnership. Journal of Management Studies, 32, 3 (1995), 265-281.

1 0. Drummond, H. Escalation in Decision-Making: The Tragedy of Taurus. Oxford: Oxford University Press, 1996.




1 1 . Drummond, H. The politics of risk: trials and tribulations of the Taurus project. Journal of Information Technology, 11 (1996), 347-357.

12. Eisenhardt, K. Building theories from case study research. Academy of Management Review, 14, 4 (1989), 532-550.

13. Elam, J.J., and Sabherwal, R. Overcoming the problems in information systems development by building and sustaining commitment. Accounting, Management and Information Technologies. 5. 3-^L Í1995Y 283-309.

^y 7 7 7 ' f 7 ___-

14. Ellis, V. Audit says DMV ignored warning. Los Angeles Times (August 18, 1994), A3 &A24.

15. Ewusi-Mensah, K., and Przasnyski, Z.H. On information systems project abandonment: an exploratory study of organizational practices. MIS Quarterly, 15, 1 (1991), 67-85.

16. Garland, H.; Sandefur, C.A.; and Rogers, A.C. Deescalation of commitment in oil exploration: when sunk costs and negative feedback coincide. Journal of Applied Psychology, 75, 6 (1990), 721-727.

17. Gibbs, W.W. Software's chronic crisis. Scientific American, 273, 3 (1994), 86-95. 1 8. Ginzberg, MJ. Key recurrent issues in the MIS implementation process. MIS Quarterly,

5, 2 (1981), 47-59. 19. Heath, C. Escalation and deescalation of commitment in response to sunk costs: the role

of budgeting in mental accounting. Organizational Behavior and Human Decision Processes, 62, 1(1995), 38-54.

¿A), jonnson, j. tenaos: me donar urani ui n project lauurcs. sippuccuiun ueveiupmem Trends, 2, 1(1995), 41-47.

21. Keil, M. Pulling the plug: software project management and the problem of project escalation. MIS Quarterly, 19, 4 (1995), 421-447.

22. Keil, M., and Flatto, J. Information systems project escalation: a reinterpretation based on options theory. Accounting, Management and Information Technologies (1999), in press.

23. Keil, M., and Mann, J. The nature and extent of IT project escalation: results from a survey of IS audit and control professionals. IS Audit & Control Journal, 1 (1997), 40-48.

24. Keil, M.; Mixon, R.; Saarinen, T.; and Tuunainen, V. Understanding runaway information technology projects: results from an international research program based on escalation theory. Journal of Management Information Systems, 11,3 (1995), 67-87.

25. Kindel, S. The computer that ate the company. Financial World, 161, 1 (1992), 96-98. 26. Lincoln, Y.S., and Guba, E.G. Naturalistic Inquiry. Beverly Hills, CA: Sage, 1985. 27. Mann, J. The role of project escalation in explaining runaway information systems

development projects: a field study. Ph.D. dissertation, Georgia State University, 1996. 28. Markus, M.L., and Keil, M. If we build it, they will come: designing information systems

that users want to use. Sloan Management Review, 35, 4 (1994), 1 1-25. 29. McCain, B.E. Continuing investment under conditions of failure: a laboratory study of

the limits to escalation. Journal of Applied Psychology, 71, 2 (1986), 280-284. JU. Miceli, M.F., ana Near, J.F. mowing the Whistle: lhe Organizational ana Legal

Implications for Companies and Employees. New York: Lexington Books, 1992. 31. Mitev, IN .IN. More man a failure.' ine computerized reservation systems at rrencn

Railways. Information Technology & People, 9, 4 (1996), 8-19. 32. Myers, M.D. A disaster for everyone to see: an interpretive analysis of a failed IS project.

Accounting, Management and Information Technologies, 4, 4 (1994), 185-201. 33. Nathanson, S.; Brockner, J.; Brenner, D.; Samuelson, C; Countryman, M.; Lloyd, M.;

and Rubin, J.Z. Toward the reduction of entrapment. Journal of Applied Social Psychology, 12, 3(1982), 1111-1118.

34. Newman, M., and Sabherwal, R. Determinants of commitment to information systems development: a longitudinal investigation. MIS Quarterly, 20, 1 (1996), 23-54.

35. Northcraft, G.B., and Neale, M.A. Opportunity costs and the framing of resource allocation decisions. Organizational Behavior and Human Decision Processes, 37,3 (1986), 348-356.

36. Rosenwein, M. The optimization engine that couldn't. OR/MS Today, 24, 4 (1997), 26-29.

37. Ross, J., and Staw, B.M. Organizational escalation and exit: lessons from the Shoreham Nuclear Power Plant. Academy of Management Journal, 36, 4 (1993), 701-732.




38. Rothfeder, J. It's late, costly, incompetent - but try firing a computer system. Business Week (November 7, 1988), 164-165. 39. Rubin, J.Z., and Brockner, J. Factors affecting entrapment in waiting situations: the

Rosencrantz and Guildenstern effect. Journal of Personality and Social Psychology, 5/(1 975), 1054-1063. 40. Simonson, I., and Staw, B.M. Deescalation strategies: a comparison of techniques for

reducing commitment to losing courses of action. Journal of Applied Psychology, 77, 4 ( 1 992), 419-426.

41 . Staw, B.M., and Ross, J. Commitment to a policy decision: a multi-theoretical perspective. Administrative Science Quarterly, 23, 1 (1978), 40-64.

42. Staw, B.M., and Ross, J. Behavior in escalation situations: antecedents, prototypes, and solutions. In B.M. Staw and L.L. Cummings (eds.), Research in Organizational Behavior, vol. 9. Greenwich, CT: JAI Press, 1987, pp. 39-78.

43. Strauss, A., and Corbin, J. Basics of qualitative research: grounded theory procedures and techniques. Newbury Park, CA: Sage, 1990.

44. Tesser, A., and Rosen, S. The reluctance to transmit bad news. Advances in Experimental Social Psychology, vol. 8. 1975, pp. 193-232.

45. Tomsho, R. Real dog: how greyhound lines re-engineered itself right into a deep hole. Wall Street Journal (October 20, 1 994), A 1 , A6. 46. Weinstein, D. Bureaucratic Opposition: Challenging Abuses in the Workplace. New

York: Pergamon Press, 1979. 47. Westland, J.C. Assessing the economic benefits of information systems auditing. Infor-

mation Systems Research, 1, 3 (1990), 309-324. 4». Whyte, u. bscalating commitment to a course oi action: a reinterpretation. Acaaemy oj

Management Review, 11,2(1 986), 3 1 1-32 1 .

Appendix: First Coding Categories from Narratives

Senior management responds to negative information. Efforts to reduce project complexity and scope. Whistleblowing. External review. Weakened financial situation. Political battle.

System did not meet user needs.



Discalation of commitment

Documents

Transcript of Discalation of commitment