Runaway Information Technology Projects: A Punctuated Equilibrium Analysis

Runaway Information Technology Projects: A Punctuated Equilibrium Analysis

M. Keith Wright, Charles J. Capps
DOI: 10.4018/978-1-4666-0930-3.ch015
OnDemand:
(Individual Chapters)
Available
$37.50
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

This paper presents an in-depth insider’s case study of a “runaway” information systems (IS) project in a U.S. State government agency. Because such projects are politically sensitive matters and often obscured from public view, details of how such projects operate are not well understood. This case study adds new details to the body of knowledge surrounding IS project escalation and de-escalation. The authors’ resulting project narrative details how this project went out of control for so long, raising important questions for future research in theory development for both IS project escalation and de-escalation. The paper argues that a punctuated equilibrium approach to analyzing “runaway” IS projects are a more fruitful area to explore than are “stage models.”
Chapter Preview
Top

Introduction

Information Systems (IS) project failure is a costly problem, and it is well known that failing projects can seem to take on a life of their own without adding business value (Zmud, 1980; DeMarco, 1982; Abdel-Hamid & Madnick, 1991; Johnson, 1995). A study of over 8,000 IS projects by Johnson (1995) revealed that only 16 percent were completed on time and within budget. The most studied projects are those that wasted hundreds of millions of dollars, and attracted lots of press. Examples are the FBI Trilogy project (Knorr, 2005; US GAO, 2006), the California Motor Vehicles Driver Licensing System (Bozman, 1994), and the Denver airport baggage handling system (Montealegre & Keil, 2000). These cases of IS projects going wildly over time and budget are called “runaways” (Glass, 1998; Mann, 2003). The management behavior that underlies runaway projects resembles what psychologists have called “escalation of commitment to a failing course of action” (Brockner, 1992; Keil, 1995). IS project de-escalation, on the other hand, has been defined as the reverse of this process (Keil & Robey, 1999; Montealegre & Keil, 2000; Royer, 2003; Heng et al., 2003) (see Table 1).

Table 1.
Proposed information system project de-escalation triggers
Recognizing unambiguous negative feedback Garland and Conlon (1998); Ross and Staw (1993);Montealegre and Keil (2000)
Clarifying the magnitude of the problem Rubin and Brockner (1975); Brockner (1992)
Separation of duties Barton et al. (1989)
Redefining the problemTversky and Khaneman (1981); Montealegre and Keil (2000)

Complete Chapter List

Search this Book:
Reset