De-escalating IT projects: the DMM model

ABSTRACT

Introduction

Taming runaway Information Technology (IT) projects is a challenge that most organizations have faced and that managers continue to wrestle with. These are projects that grossly exceed their planned budgets and schedules, often by a factor of 2--3 fold or greater. Many end in failure; failure not only in the sense of budget or schedule, but in terms of delivered functionality as well.

Runaway projects are frequently the result of escalating commitment to a failing course of action, a phenomenon that occurs when investments fail to work out as envisioned and decision-makers compound the problem by persisting irrationally. Keil, Mann, and Rai reported that 30--40% of IT projects exhibit some degree of escalation. To break the escalation cycle, de-escalation of commitment to the failing course of action must occur so that valuable resources can be channeled into more productive use. But, making de-escalation happen is neither easy nor intuitive.

This article briefly examines three approaches that have been suggested for managing de-escalation. By combining elements from the three approaches, we introduce a de-escalation management maturity (DMM) model that provides a useful framework for improving practice.

REFERENCES

• 1: Drummond, H. Deescalation in decision making: a case of a disastrous partnership. J. of Management Studies 32, 3, (1995), 265--281.
• 2: Ewusi-Mensah, K. Critical issues in abandoned information systems development projects. Comm. ACM 40, 9, (1997), 74--80.
• 3: Iacovou, C.L. and Dexter, A.S. Managing runaway projects: a Delphi survey. Proceedings of the 6th European Conference on Information Systems, W.R.J. Baets (ed.), Aix-en-Provence, France, (1998), 1140--1153.
• 4: Iacovou, C.L. and Dexter, A.S. Turning around runaway information technology projects. California Management Review 46, 4, (2004), 68--88.
• 5: Keil, M., and Robey, D. Turning around troubled software projects: an exploratory study of the deescalation of commitment to failing courses of action. J of Management Information Systems 15, 4, (1999), 63--87.
• 6: Keil, M., and Montealegre, R. Cutting your losses: extricating your organization when a big project goes awry. Sloan Management Review 41, 3, 2000, 55--68.
• 7: Keil, M., Mann, J., and Rai, A. Why software projects escalate: an empirical analysis and test of four theoretical models. MIS Quarterly 24, 4, (Dec. 2000), 631--664.
• 8: Montealegre, R., and Keil, M. De-escalating information technology projects: Lessons from the Denver international airport. MIS Quarterly 24, 3, (2000), 417--447.
• 9: Pan, G., Pan, S., Newman, M., and Flynn, D.J. Escalation and de-escalation of commitment to information systems projects: Insights from a project evaluation model. European Journal of Operational Research 173, 3, (2006a), 1139--1160.
• 10: Pan G, Pan S, Newman M, and Flynn D.J. Escalation and de-escalation of commitment: A transformational analysis of an e-government project. Information Systems Journal 16, (2006b), 3--21.
• 11: Staw, B., and Ross, J. Knowing when to pull the plug, Harvard Business Review. March-April, (1987), 68--74.

INDEX TERMS

Primary Classification:
  K. Computing Milieux
  K.6 MANAGEMENT OF COMPUTING AND INFORMATION SYSTEMS
      K.6.1 Project and People Management

Additional Classification:
  K. Computing Milieux
  K.6 MANAGEMENT OF COMPUTING AND INFORMATION SYSTEMS
      K.6.3 Software Management
      K.6.4 System Management