Article Preview
TopIntroduction
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 problem | Tversky and Khaneman (1981); Montealegre and Keil (2000) |