Turning around Troubled Software Projects: An Exploratory Study of the Deescalation of Commitment to Failing Courses of Action
- 1 March 1999
- journal article
- research article
- Published by Taylor & Francis in Journal of Management Information Systems
- Vol. 15 (4) , 63-87
- https://doi.org/10.1080/07421222.1999.11518222
Abstract
Project failure in the information systems field is a costly problem and troubled projects are not uncommon. In many cases, whether a troubled project ultimately succeeds or fails depends on the effectiveness of managerial actions taken to turn around or redirect such projects. Before such actions can be taken, however, management must recognize problems and prepare to take appropriate corrective measures. While prior research has identified many factors that contribute to the escalation of commitment to failing courses of action, there has been little research on the factors contributing to the deescalation of commitment. Through deescalation, troubled projects may be successfully turned around or sensibly abandoned. This study seeks to clarify the factors that contribute to software project deescalation and to establish practical guidelines for identifying and managing troubled projects. Through interviews with forty-two IS auditors, we gathered both quantitative and qualitative data about the deescalation of commitment to troubled software projects. The interviews sought judgments about the importance of twelve specific factors derived from a review of the literature on deescalation. Interviews also generated qualitative data about specific actors and actions taken to tum troubled projects around. The results indicate that the escalation and deescalation phases of projects manifest different portraits. While there were no factors that always turned projects around, many actors triggered deescalation, and many specific actions accounted for deescalation. In the majority of cases, deescalation was triggered by actors such as senior managers, internal auditors, or external consultants. Deescalation was achieved both by managing existing resources better and by changing the level of resources comrmtted to the project. We summarize the implications of these findings in a process model ofproject deescalation.Keywords
This publication has 31 references indexed in Scilit:
- Determinants of Commitment to Information Systems Development: A Longitudinal InvestigationMIS Quarterly, 1996
- Pulling the Plug: Software Project Management and the Problem of Project EscalationMIS Quarterly, 1995
- DE‐ESCALATION IN DECISION MAKING: A CASE OF A DISASTROUS PARTNERSHIP*Journal of Management Studies, 1995
- Escalation and De-escalation of Commitment in Response to Sunk Costs: The Role of Budgeting in Mental AccountingOrganizational Behavior and Human Decision Processes, 1995
- Software's Chronic CrisisScientific American, 1994
- De-escalation of commitment in oil exploration: When sunk costs and negative feedback coincide.Journal of Applied Psychology, 1990
- An Empirical Test of Staw and Ross's Prescriptions for the Management of Escalation of Commitment Behavior in Organizations*Decision Sciences, 1989
- Opportunity costs and the framing of resource allocation decisionsOrganizational Behavior and Human Decision Processes, 1986
- Continuing investment under conditions of failure: A laboratory study of the limits to escalation.Journal of Applied Psychology, 1986
- Factors affecting entrapment in waiting situations: The Rosencrantz and Guildenstern effect.Journal of Personality and Social Psychology, 1975