Research and Advances
Computing Applications Virtual extension

De-Escalating IT Projects: The DMM Model

Posted
  1. Introduction
  2. Approach 1—The Crisis Management Approach
  3. Approach 2—The Change Management Approach
  4. Approach 3—The Problem Solving Approach
  5. Comparing the Three Approaches
  6. References
  7. Authors
  8. Footnotes
  9. Figures
  10. Tables

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.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 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.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.

Back to Top

Approach 1—The 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.

Back to Top

Approach 2—The 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.

Back to Top

Approach 3—The 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.

Back to Top

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.

Back to Top

Back to Top

Back to Top

Back to Top

Figures

F1 Figure 1. Integrated De-escalation Management Model

Back to Top

Tables

T1 Table 1. De-escalation Actions Based on Crisis Management Approach

T2 Table 2. De-escalation Lessons Based on Change Management Approach

T3 Table 3. De-escalation Phases Based on Problem Solving Approach

T4 Table 4. De-Escalation Management Maturity (DMM) Model

Back to top

    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.

    a. The DMM is not designed to compete with or substitute for the more broad-based capability maturity model (CMM). The DMM is designed with a much narrower focus on de-escalation management.

    DOI: http://doi.acm.org/10.1145/1562764.1562797

Join the Discussion (0)

Become a Member or Sign In to Post a Comment

The Latest from CACM

Shape the Future of Computing

ACM encourages its members to take a direct hand in shaping the future of the association. There are more ways than ever to get involved.

Get Involved

Communications of the ACM (CACM) is now a fully Open Access publication.

By opening CACM to the world, we hope to increase engagement among the broader computer science community and encourage non-members to discover the rich resources ACM has to offer.

Learn More