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 23 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.2
Runaway projects are frequently the result of escalating commitment to a failing course of action,11 a phenomenon that occurs when investments fail to work out as envisioned and decision-makers compound the problem by persisting irrationally.1 Keil, Mann, and Rai7 reported that 3040% 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.5 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.
Approach 1The Crisis Management Approach
Iacovou and Dexter4 follow a crisis management approach in formulating their de-escalation management guidelines. Their work is based on the results of a 3-round Delphi survey of 38 IT consultants, who ranked 10 actions to pursue in response to tackling a runaway project. They emphasize three objectives that underlie a successful turnaround strategy: operational containment, credibility restoration, and organizational learning. The de-escalation actions they advocate are shown in Table 1.
Approach 2The Change Management Approach
Pan et al9,10 follow a change management approach in formulating their de-escalation guidelines. Their work is based on a case study of UKCouncil, a U.K. local government organization that proposed an electronic procurement system for efficiency reasons and a desire to be the first such organization to purchase goods and services electronically. During project testing, the project stalled due to a disagreement between the users and the vendor, who demanded an additional £150,000 for "redesigning the software again". Payment was made and the project continued until the problems resurfaced and project development was halted. By examining how project individuals surrendered their commitment to the previous failing course of action and accepted a joint agreement to a turnaround strategy, they formulated five important lessons for managing de-escalation as shown in Table 2.
Approach 3The Problem Solving Approach
Montealegre and Keil8 follow a problem solving approach in formulating their de-escalation management guidelines. Their work is based on the results of a case study involving the computerized baggage handling system at Denver International Airport. Based on their analysis of this case, they described a four-phase model that captures the process of de-escalation and includes key triggering activities for each phase. This model was later applied to the well-known Taurus case involving the London Stock Exchange and was found to fit that case as well.6 The four phases of the de-escalation process, as seen from the problem solving perspective, are described in Table 3.
Comparing the Three Approaches
Both the problem solving and the change management approaches focus only on de-escalating the project at hand. Neither of these approaches is likely to result in the organizational learning that is necessary to avoid future mishaps. In contrast, the crisis management approach, while it addresses organizational learning, does not cover detection, and tends to focus on the technical, rather than people, issues associated with implementing a new project plan. So what approach should a manager use? Figure 1 presents an integrated model that incorporates the best features of the three approaches and can guide managers.
The two first steps of the model (prevent and detect) are about working proactively to minimize the risk for escalation and exposing any escalation that does occur as early as possible. For prevention, advanced project management practices (reporting and control measures, project ownership, a project office) are essential. For detection, norms and rewards for reporting bad news about a project are key. The following three steps (disrupt, re-evaluate and implement) concern wholesale rethinking of the project plan and development of a new plan, and constitute a continuous effort to manage change that helps move stakeholder commitment from a failing course of action to a new and viable course. Finally, the step learn and the feedback loop, implement improved practices, move the focus of de-escalation management from the runaway project at hand to organizational learning and improvement of project management and de-escalation management practices.
Most organizations will not be in a position today to follow the integrated model because they lack the de-escalation discipline and maturity needed to fully adopt the model. To provide a roadmap for managers who want to implement the model in their organizations, we provide a de-escalation management maturity (DMM) model (see Table 4) that is based on the familiar CMM model, and which captures the progressive levels of preparedness needed to manage de-escalation.a
Level 1 of the DMM model requires that organizations have people who know how to apply basic project management tools and techniques, especially those that focus on project planning. Moreover, the culture of the organization must support the application of these techniques. The project plan must be regarded as changeable and it must be updated frequently so that it provides a true reflection of project status.
Level 2 of the DMM model requires that organizations maintain a project baseline that allows for detection of deviations from the project plan. Task status must be tracked regularly and compared against the project plan, as this is the best way to prevent project escalation. Prevention also involves the pre-appointment of external advisors capable of reviewing the entire project or specific vendors. Note that achieving levels 1 and 2 involve nothing more than building and exercising basic project management skills. Yet, these skills provide the foundation for reaching higher levels on the DMM model. As we move up through Levels 3, 4, and 5, the organization must focus more on soft skills that improve change management and project status reporting capabilities.
Level 3 of the DMM model requires that organizations have experienced project managers who not only possess the technical skills needed to be a good project manager, but also the communication and change management skills needed to execute project plans in environments where they lack direct authority over those who must be on board in order for the project to be successful.
Level 4 of the DMM model requires that organizations develop a culture where it is not only permissible to communicate bad news but where bad news reporting is actually encouraged. Some organizations have made progress in this regard by reminding participants that project review meetings are for "bad news only" reporting. While there are a number of both simple and sophisticated approaches to project monitoring that can be brought to bear at Level 2, the ultimate effectiveness of these approaches hinges on reaching Level 4. The organizational culture must be supportive of bad news reporting so that task and project level status updates are honest.
Level 5 of the DMM model requires that organizations pay more than lip service to the value of organizational learning. Cross-project learning needs to be facilitated, for example through work sessions where experiences are shared and new ideas for de-escalation management are generated. In addition, people in roles outside project teams (such as methodology experts, project owners, and project management office personnel) need to learn about experiences and insights that can help improve project management practices in a systematic way.
How should an organization decide on the DMM level that is appropriate for them? In our view, this depends on the nature of the organization, the frequency and criticality of complex IT projects, and the skill base of its managers. While attaining high levels on the DMM may be desirable, doing so requires a significant investment of effort. Level 4 requires an open culture for discussing problems (which may have unintended consequences for organizational life) and level 5 requires a learning culture and potentially expensive procedures such as post-mortems. Soft skills are required on both these levels to persuade internal and external stakeholders to change set ways of thinking and embedded procedures. Ultimately there is no free lunch here and organizations must weigh the costs of instituting de-escalation management procedures against the costs associated with runaway projects.
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), 11401153.
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), 6387.
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), 11391160.
©2009 ACM 0001-0782/09/1000 $10.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2009 ACM, Inc.