Is your project turning into a black hole?

California Management Review

Volumn 53, Issue 1, 2011, Pages 6-31

  Keil, Mark ^a   Mähring, Magnus ^b,c  

^a GEORGIA STATE UNIVERSITY   (United States)

^b STOCKHOLM SCHOOL OF ECONOMICS   (Sweden)

^c Ecole de Management de Strasbourg   (France)

Author keywords

[No Author keywords available]

Indexed keywords

EID: 78651316330     PISSN: 00081256     EISSN: None     Source Type: Journal    
DOI: 10.1525/cmr.2010.53.1.6     Document Type: Article

References (80)

1. J. Brockner, "The Escalation of Commitment to a Failing Course of Action: Toward Theoretical Progress," Academy of Management Review, 17/1 (January 1992): 39-61.
2. J. Best, "Avis Cancels Peoplesoft ERP System," ZDNet UK, October 22, 2004.
3. D. Eggen and G. Witte, "The FBI's Upgrade That Wasn't: $170 Million Bought an Unusable Computer System," Washington Post, August 18, 2006;
4. H. Goldstein, "Who Killed the Virtual Case File? How the FBI Blew More Than $100 Million on Case-Management Software It Will Never Use," IEEE Spectrum, September 2005.
5. E. Connors, "Qantas Grounds Its Eq Project," The Australian Financial Review, January 31, 2006;
6. M. Krigsman, "Qantas Airways: A Perfect Storm for IT Failure?" ZDNet, February 29, 2008.
7. S. Goldfinch, "Pessimism, Computer Failure, and Information Systems Development in the Public Sector," Public Administration Review, 67/5 (September 2007): 917-929;
8. Standish Group, "Chaos Summary 2009," Boston, MA, 2009.
9. Brockner, op. cit.;
10. B.M. Staw and J. Ross, "Behavior in Escalation Situations: Antecedents, Prototypes, and Solutions," in B.M. Staw and L.L. Cummings, eds., Research in Organizational Behavior (Greenwich, CT: JAI Press Inc., 1987), pp. 39-78.
11. C.L. Iacovou and A.S. Dexter, "Turning around Runaway Information Technology Projects," California Management Review, 46/4 (Summer 2004): 68-88.
12. M. Keil and R. Montealegre, "Cutting Your Losses: How Executives Can Extricate Their Organizations When Big Projects Go Awry," Sloan Management Review, 41/3 (Spring 2000): 55-68.
13. These factors are often divided into project factors (long-term investment required, high abandonment cost), psychological factors (strong personal attachment to project, prior history of success), social factors (face saving, rewards for staying the course), and organizational factors (side-bets, influential backers, loose controls). See, for example, Brockner, op. cit.;
14. H. Garland, "Throwing Good Money after Bad: The Effect of Sunk Costs on the Decision to Escalate Commitment to an Ongoing Project," Journal of Applied Psychology, 75/6 (December 1990): 728-731;
15. M. Keil, "Pulling the Plug: Software Project Management and the Problem of Project Escalation," MIS Quarterly, 19/4 (December 1995): 421-447;
16. B.M. Staw, "Knee-Deep in the Big Muddy: A Study of Escalating Commitment to a Chosen Course of Action," Organizational Behavior and Human Performance, 16/1 (June 1976): 27-44;
17. Staw and Ross, op. cit.;
18. B.M. Staw and J. Ross, "Knowing When to Pull the Plug," Harvard Business Review, 65/2 (March/April 1987): 68-74.
19. J. Ross and B.M. Staw, "Organizational Escalation and Exit: Lessons from the Shoreham Nuclear Power Plant," Academy of Management Journal 36/4 (1993): 701-732,
20. I. Royer, "Escalation in Organizations: The Role of Collective Belief," Academy of Management Annual Meeting, Denver, Colorado, 2002,
21. G. Pan, S.L. Pan and M. Newman, "Managing Information Technology Project Escalation and De-Escalation: An Approach-Avoidance Perspective," IEEE Transactions on Engineering Management 56/1 (2009): 76-94,
22. S.L. Pan, G.S.C. Pan, M. Newman and D. Flynn, "Escalation and De-Escalation of Commitment to Information Systems Projects: Insights from a Project Evaluation Model," European Journal of Operational Research, 173/3 (September 2006): 1139-1160.
23. Keil, op. cit.;
24. M. Keil, J. Mann, and A. Rai, "Why Software Projects Escalate: An Empirical Analysis and Test of Four Theoretical Models," MIS Quarterly, 24/4 (December 2000): 631-664,
25. Keil and Montealegre, op. cit.;
26. M. Keil, A. Rai, J. Mann, and G.P. Zhang, "Why Software Projects Escalate: The Importance of Project Management Construas," IEEE Transactions on Engineering Management, 50/3 (August 2003): 251-261;
27. 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, 15/4 (Spring 1999): 63-87;
28. M. Mähring, J. Holmström, M. Keil, and R. Montealegre, "Trojan Actor-Networks and Swift Translation: Bringing Actor-Network Theory to IT Project Escalation Studies," Information Technology & People, 17/2 (2004): 210-238;
29. M. Mähring and M. Keil, "Information Technology Project Escalation: A Process Model," Decision Sciences, 39/2 (May 2008): 239-272;
30. R. Montealegre and M. Keil, "De-Escalating Information Technology Projects: Lessons from the Denver International Airport," MIS Quarterly, 24/3 (September 2000): 417-447.
31. M. Mähring, IT Project Governance (Stockholm: Economic Research Institute (EFI), Stockholm School of Economics, 2002).
32. Mähring and Keil, op. cit.
33. M.A. Barton and K.M. Sutcliffe, "Learning When to Stop Momentum," MIT Sloan Management Review, 51/3 (Spring 2010): 69-76.
34. Vivid examples of this can be found in cases reported in studies by Keil, op. cit.,
35. and by Royer, op. cit.
36. Staw and Ross, op. cit.
37. This implies a tradeoff: typically, a framework's ability to capture details and idiosyncrasies is reduced when simplicity and generality are prioritized. In other words, since our framework is designed to capture the general nature of escalation in a way that is practically useful, it is likely that any one troubled project may experience twists and turns that are not captured by the framework.
38. California State Auditor, "The Department of Motor Vehicles and the Office of Information Technology Did Not Minimize the State's Financial Risk in the Database Redevelopment Project," Sacramento, CA, State Auditor of California, 1994;
39. V. Ellis, "Audit Says DMV Ignored Warning," Los Angeles Times, August 18, 1994, pp. A3-A24, 〈http://articles.latimes.com/1994-08-18/news/ mn-28612-1-state-auditor〉, accessed October 9, 2009;
40. S. Petersen, "Past Tense," Government Technology, August 2004;
41. C. White, "DMV Hits Pothole," Byte Magazine,- February 1996.
42. F. Zolin, Director, California Department of Motor Vehicles (March 1991-November 1995), interview. May 16 2005.
43. Zolin, op. cit.
44. Zolin, op. cit.
45. California State Auditor, op. cit., p. 13.
46. California State Auditor, op. cit., p. 50.
47. Zolin, op. cit.
48. Zolin, op. cit.
49. Zolin, op. cit.
50. California State Auditor, op. cit.
51. Zolin, op. cit.
52. V. Ellis, "Embattled Director of DMV to Step Down-Government: Frank Zolin, Criticized for Costly Computer Snafu, Cites Differences with Wilson Administration," Los Angeles Times, October 11, 1995, 〈http:// articles.latimes.com/1995-10-11/news/mn-55830-1-frank-zolin〉, accessed October 9, 2009.
53. Zolin, op. cit.
54. California State Auditor, op. cit.
55. E.M. Bennatan, Catastrophe Disentanglement: Getting Software Projects Back on Track (Upper Saddle River, NJ: Addison-Wesley Professional, 2006);
56. A.P. Snow, M. Keil, and L. Wallace, "The Effects of Optimistic and Pessimistic Biasing on Software Project Status Reporting," Information & Management, 44/2 (March 2007): 130-141.
57. M. Keil, G.P. Im, and M. Mähring, "Reporting Bad News on Software Projects: The Effects of Culturally Constituted Views of Face-Saving," Information Systems Journal, 17/1 (January 2007): 59-87.
58. M. Keil and D. Robey, "Blowing the Whistle on Troubled Software Projects," Communications of the ACM, 44/4 (April 2001): 87-93.
59. Mähring, op. cit.
60. Montealegre and Keil, op. cit.;
61. Mähring, Holmström, Keil, and Montealegre, op. cit.
62. M. Engwall and C. Svensson, "Forethought: Cheetah Teams," Harvard Business Review, 79/2 (February 2001): 20-21;
63. M. Engwall and C. Svensson, "Cheetah Teams in Product Development: The Most Extreme Form of Temporary Organization?" Scandinavian Journal of Management, 20/3 (September 2004): 297-317.
64. Mähring, op. cit.;
65. Mähring and Keil, op. cit.
66. This happened in the case of Denver International Airport, where the Mayor of Denver made a commitment not to open the new airport until the Automated Baggage Handling System was operational. See Keil and Montealegre, op. cit.
67. The actions described above can most likely be executed in sequence. In contrast, as the escalation process gains momentum, actions might have to become more forceful and be executed concurrently in order to be effective.
68. H. Drummond, Escalation in Decision-Making: The Tragedy of Taurus (Oxford: Oxford University Press, 1996),
69. Keil and Montealegre, op. cit.
70. This has been observed not only in managerial contexts but also for example in the context of firefighting: Barton and Sutcliffe, op. cit.
71. Iacovou and Dexter, op. cit.
72. Prior research has shown external reviews prevent escalation more effectively when consultants are instructed to make specific termination/continuation recommendations in review reports,
73. see K. Kadous and L.M. Sedor, "The Efficacy of Third-Party Consultation in Preventing Managerial Escalation of Commitment: The Role of Mental Representations," Contemporary Accounting Research, 21/1 (Spring 2004): 55-82.
74. In the EuroBank case, the reviews that were conducted were mishandled in several ways and thus failed to play any pivotal role in the turnaround of the NDS project. None of the reviews had the explicit instructions described above. In addition, the first review was botched when the ineffective change of project manager was conducted in parallel with the review. The second review did stir emotions and raise concerns in the steering committee, but members let themselves be temporarily appeased by the project manager's assurances of better times ahead. To be effective, reviews need to answer pointed questions and be part of a coherent strategy rather than single shots in the dark.
75. Staw and Ross, op. cit.
76. Mähring, Holmström, Keil and Montealegre, op. cit.
77. M. Mähring, M. Keil, L. Mathiassen, and J. Pries-Heje, "Making IT Project De-Escalation Happen: An Exploration into Key Roles," Journal of the Association for Information Systems, 9/8 (August 2008): 462-496,
78. Montealegre and Keil, op. cit.
79. Mähring, op. cit.;
80. Mähring and Keil, op. cit.