1. “Next Time, What Say We Boil a Consultant?” Fast Company, November 1995, p. 20.
2. T. Levitt, “Marketing Myopia,” Harvard Business Review, volume 53, September/October 1975, pp. 26–28, 33–39, 44, 173–181.
3. C.M. Christensen, The Innovator’s Dilemma (Boston: Harvard Business School Press, 1997).
4. B.M. Staw and J. Ross, “Knowing When to Pull the Plug,” Harvard Business Review, volume 65, March–April 1987, pp. 68–74.
5. See, for example:
J. Brockner, “The Escalation of Commitment to a Failing Course of Action: Toward Theoretical Progress,” Academy of Management Review, volume 17, January 1992, pp. 39–61.
6. T. Newcombe, “Big Project Woes Halt Child Support System,” Government Technology, February 1998, pp. 34–35.
7. For an overview of the software project failure problem, see:
W.W. Gibbs, “Software’s Chronic Crisis,” Scientific American, volume 271, September 1994, pp. 86–95.
The following articles provide examples of software project escalation:
G.H. Anthes, “IRS Project Failures Cost Taxpayers $50B Annually,” Computerworld, 14 October 1996, p. 1;
M. Betts, “Feds Debate Handling of Failing IS Projects,” Computerworld, 2 November 1992, p. 103;
V. Ellis, “Audit Says DMV Ignored Warning,” Los Angeles Times, 18 August 1994, pp. A3, A24;
J. Johnson, “Chaos: The Dollar Drain of IT Project Failures,” Application Development Trends, volume 2, January 1995, pp. 41–47;
S. Kindel, “The Computer That Ate the Company,” Financial World, volume 161, 31 March 1992, pp. 96–98;
J. Rothfeder, “It’s Late, Costly, Incompetent—But Try Firing a Computer System,” Business Week, 7 November 1988, pp. 164–165;
R. Tomsho, “Real Dog: How Greyhound Lines Re-Engineered Itself Right Into a Deep Hole,” Wall Street Journal, 20 October 1994, pp. A1–A6; and
T. Newcombe, “Big Project Woes Halt Child Support System,” Government Technology, February 1998, pp. 34–35.
8. M. Keil and J. Mann, “The Nature and Extent of Information Technology Project Escalation: Results from a Survey of IS Audit and Control Professionals,” IS Audit & Control Journal, volume 1, 1997, pp. 40–48.
9. De-escalation can be said to have occurred whenever there is reduced commitment to a previously chosen course of action. In the case of project failure, such a reduction in commitment could manifest itself as project abandonment, but it could also be manifested in the form of significant changes made in relation to some previous course of action. Thus, we take a broad view of de-escalation in this paper, defining it so as to include abandonment as well as project redirection.
10. For references to prior studies, see:
M. Keil and D. Robey, “Turning Around Troubled Software Projects: An Exploratory Study of the Deescalation of Commitment to Failing Courses of Action, Journal of Management Information Systems, volume 15, Spring 1999, pp. 63–87.
11. This research was conducted through a combination of surveys, in-depth case studies, and an examination of published accounts of IT project escalation. See:
Keiland Mann (1997);
Keil and Robey (1999);
M. Keil, “Pulling the Plug: Software Project Management and the Problem of Project Escalation,” MIS Quarterly, volume 19, December 1995, pp. 421–447;
R. Montealegre and M. Keil, “Denver International Airport’s Automated Baggage Handling System: A Case Study of De-escalation of Commitment,” Academy of Management Best Papers Proceedings 1998, pp. D1–D9 (www.aom.pace.edu);
R. Montealegre and M. Keil, “De-Escalating Information Technology Projects: Lessons from the Denver International Airport,” MIS Quarterly, forthcoming; and
H. Drummond, Escalation in Decision-Making: The Tragedy of Taurus (New York: Oxford University Press, 1996).
12. The results of this study have been reported elsewhere and will only be summarized here. See:
Montealegre and Keil (1998); and
Montealegre and Keil (forthcoming).
For additional information on the Denver International Airport case, see:
R. Montealegre, C. Knoop, J. Nelson, and L.M. Applegate, “BAE Automated Systems (A): Implementing the Denver International Airport Baggage-Handling System” (Boston: Harvard Business School Case 9-396-311, 1996); and
R. Montealegre, C. Knoop, J. Nelson, and L.M. Applegate“BAE Automated Systems (B): Implementing the Denver International Airport Baggage-Handling System” (Boston, Massachusetts: Harvard Business School Case 9-396-312, 1996).
13. J. Bouton, “State-of-the-Art Baggage System for Denver,” Airport Forum, February 1993, pp. 10–13.
14. P. O’Driscoll, “ ‘Low Tech’ Salvation: Webb Orders Backup Bag System,” Denver Post, 5 August 1994, p. A-1.
15. Under normal circumstances, two to three weeks would often elapse between the buying and selling of shares and the actual exchange of money and stock certificates, making the market both riskier and less efficient than desirable. When the 1997 stock market crash occurred, there was a settlements crisis resulting in nearly one million unsettled share transactions. Trades remained unsettled for months.
16. H. Drummond, “ ‘It Looked Marvellous in the Prospectus’: TAURUS, Information and Decision Making,” Journal of General Management, volume 23, Spring 1998, pp. 73–87.
17. It was projected that Taurus would save the equities industry $225 million over 10 years. The Taurus project has been well documented by H. Drummond, and we draw heavily upon her work in the analysis presented here. See:
H. Drummond, Escalation in Decision-Making: The Tragedy of Taurus New York: Oxford University Press, 1996).
18. Ibid., p. 64.
19. Ibid., p. 74.
20. Vista refused to enter into a fixed-price contract for the modifications.
21. Drummond (1996), p. 60.
22. Drummond (1998), p. 76.
23. H. Drummond, “Are We Any Closer to the End? Escalation and the Case of Taurus,” International Journal of Project Management, volume 17, February 1999, pp. 11–16.
24. Drummond (996), p. 138.
25. Ibid., p. 137.
26. Ibid., p. 141.
27. Ibid., p. 138.
28. Ibid., p. 139.
29. Ibid., pp. 147–148.
30. Ibid., p. 69.
31. Ibid., p. 70.
32. Ibid., p. 114.
33. Ibid., p. 148.
35. Ibid., p. 150.
36. Ibid., p. 151.
38. Ibid., p. 155.
39. Ibid., p. 152.
40. Ibid., p. 151.
41. Staw and Ross (1987).
42. This finding is consistent with previous literature. See, for example:
J.Z. Rubin and J. Brockner, “Factors Affecting Entrapment in Waiting Situations: The Rosencrantz and Guildenstern Effect,” Journal of Personality and Social Psychology, volume 31, June 1975, pp. 1054–1063;
J. Brockner, M.C. Shaw, and J.Z. Rubin, “Factors Affecting Withdrawal from an Escalating Conflict: Quitting Before It’s Too Late,” Journal of Experimental Social Psychology, volume 15, September 1979, pp. 492–503;
B.E. McCain, “Continuing Investment Under Conditions of Failure: A Laboratory Study of the Limits to Escalation,” Journal of Applied Psychology, volume 71, May 1986, pp. 280–284;
G. B. Northcraft and M. A. Neale, “Opportunity Costs and the Framing of Resource Allocation Decisions,” Organizational Behavior and Human Decision Processes, volume 37, June 1986, pp. 348–356; and
M. Keil, R. Mixon, T. Saarinen, and V. Tuunainen, “Understanding Runaway Information Technology Projects: Results from an International Research Program Based on Escalation Theory,” Journal of Management Information Systems, volume 11, Winter 1995, pp. 67–87.
43. R. Arnheim, Art and Visual Perception: The Psychology of the Creative Eye (Berkeley, California: University of California Press, 1954); and
R. Weisberg, Creativity: Genius and Other Myths (New York: W.H. Freeman, 1986).
44. D. J. Couger, Creativity & Innovation in Information Systems Organizations (Danvers, Massachusetts: Boyd & Fraser, 1996).
45. B.M. Staw and J. Ross, “Behavior in Escalation Situations: Antecedents, Prototypes, and Solutions,” in Research in Organizational Behavior, volume 9, B.M. Staw and L.L. Cummings, eds. (Greenwich, Connecticut: JAI Press, 1987), p. 55.
46. One means of saving face in the midst of such a crisis is to exercise various impression management techniques. See, for example:
C. L. Iacovou and A.S. Dexter, “Explanations Offered by IS Managers to Rationalize Project Failures” (Vancouver: University of British Columbia, Management Information Systems Division, Working Paper 96-MIS-003, August 1996); and
M.L. Leatherwood and E.J. Conlon, “Diffusibility of Blame:Effects on Persistence in a Project,” Academy of Management Journal, volume 30, December 1987, pp. 836–847.
47. Drummond (1996), p. 151.
48. J. Ross and B.M. Staw, “Organizational Escalation and Exit: Lessons from the Shoreham Nuclear Power Plant,” Academy of Management Journal, volume 36, August 1993, pp. 701–732.