Bibliography of articles on project risk management and escalation of commitment

I wanted to note some interesting articles that I found useful in my work with IT over the past few years, including Risk Management and Escalation of Commitment.

These articles deal with Project Risk Management. Admittedly, I focus on RM for IT projects, so this is heavily skewed towards development and implementation projects that are computer-related.

• Noor, Iqbal and Thomas J. Rye (2000). “Guidelines for successful risk facilitating and analysis”. Cost Engineering, 42(4): 32-37.
• Schmidt, Roy; Kalle Lyytinen; Mark Keil; and Paul Cule (2001). “Identifying software project risks”. Journal of Management Information Systems, 17(4): 5-36. One of the three things that I read that helped me make a pretty big leap beyond others. I used some of their classifications for our risk taxonomy at BIG.
• McManus, John (2002). “The influence of stakeholder values on project management”. Management Services, 46(6): 8-15.
• Pyra, Jim and John Trask (2002). “Risk management post analysis: Gauging the success of a simple strategy in a complex project”. Project Management Journal, 33(2): 41-48.
• Noor, Iqbal; Terry Joyner; and Robert J. Martin, Jr (2002). “Challenges of implementing risk management processes”. AACE International Transcations. [RI41RI46] Interesting account of the cultural issues in implementing a risk management process at Entergy Corporation of New Orleans, LA.
• Smith, Preston G. and Guy M. Merritt (2002). “Managing consulting project risk”. Consulting to Management, 13(3): 7-13.
• Hulett, David T. (1996). “Schedule risk analysis simplified”. PM Network, July 1996: 23-30.
• Bernstein, Peter L. (1997). “How we take risks”. Across the Board, February 1997: 23-26. Article about general theory of risks. Great introduction to it for managers.
• Jiang, James J.; Gary Klein; and T. Selwyn Ellis (2002). “A measure of software development risk”. Project Management Journal, 33(3):30-41.
• Collier, Bonnie; Tom DeMarco; and Peter Fearey (1996). “A defined process for project postmortem review”. IEEE Software, July 1996: 65-72. [0740-7459/96] I’m sure that my primary interest in this was to see DeMarco’s thinking over time.
• March, James G. and Zur Shapira (1987). “Managerial perspectices on risk and risk taking”. Management Science, 33(11): 1404-1418. This got me reading Shapira’s work and is an excellent perspective on what managers really think about risk.
• Freimut, Bernd; Susanne Hartkopf; Peter Kaiser; Jyrki Kontio; and Werner Kobitzch (2001). An industrial case study of implementing software risk management (IESE Report No. 016.01/E, Version 1.0). Fraunhofer IESE, Fraunhofer Gesellschaft, Kaiserslautern, Germany.

On escalation of commitment, a problem that troubles all projects but seems to take a nice chunk about of IT project performance:

• Newman and Sabherwal (1996). “Determinants of commitment to information systems development: A longitudinal investigation”. MIS Quaterly, 20(1): 23-54.
• Keil, Mark; Joan Mann; and Arun Rai (2000). “Why Software Projects Escalate: An Empirical Analysis and Test of Four Theoretical Models”. MIS Quarterly, 24(4): 631-664.
• Keil, Mark and Daniel Robey (2001). “Blowing the whistle on troubled software projects”. Communications of the ACM, 44(4): 87-93.
• Montealegre, Ramiro and Mark Keil (2000). “De-escalating Information Technology Projects: Lessons from the Denver International Airport”. MIS Quarterly, 24(3): 417-447.

The DIA was DOA and the IT project fiasco is second only to the London stock exchange quicksand. Here’s Montealegre’s and Keil’s abstract:

ABSTRACT: Software projects can often spiral out of control to become “runaway systems” that far exceed original budget and schedule projections. The behavior that underlies many runaway systems can best be characterized as “escalation of commitment to a failing course of action.” The objectives of this study were to:

(1) understand the extent to which IS projects are prone to escalate,

(2) compare the outcomes of projects that escalate with those that do not, and

(3) test whether constructs associated with different theories of escalation can be used to discriminate between projects that escalate and those that do not.

A survey was administered to IS audit and control professionals and, to establish a baseline for comparison, the survey was designed to gather data on projects that did not escalate as well as those that did escalate.
    The results of our research suggest that between 30% and 40% of all IS projects exhibit some degree of escalation. Projects that escalated had project outcomes that were significantly worse in terms of perceived implementation performance and perceived budget/schedule performance, as compared to projects that did not escalate. Using constructs from theories that have been used to explain the escalation phenomenon, we were able to test various logistic regression models for their ability to discriminate between projects that escalate and those that do not. To construct our models, we explored constructs derived from self-justification theory, prospect theory, agency theory, and approach avoidance theory.

While constructs derived from all four theories were significant in logistic regression models, the completion effect construct derived from approach avoidance theory provided the best classification of projects, correctly classifying over 70% of both escalated and non-escalated projects.

Image Credit: Unknown.