Motivating Managers to Kill Futile Projects

Introduction

Project failure is a well-known phenomenon to many organizations and has been a topic of great interest in academic literature. A KPMG Canadian study showed that “87% of projects exceed schedule, 56% overran budgets, and 45% did not achieve planned benefits” (KPMG, 1997 as cited in Diltz & Pence, 2006; 379). Project failure is certainly no stranger to the I(C)T sector, with much debate on how many IT project actually fail and how much these failures cost.

There are numerous examples of projects that failed even when there were clear warning signs; the Space Shuttle disaster (Frese & Sauter, 2003), Boston’s Big Dig construction project (Dahl, 2001) or the Airbus A380 project (Catalogue of Catastrophe, 2013). All were projects that should have been canceled. The Airbus A380 project, for example, illustrates this. One of the biggest challenges was the complex wiring system needed to operate the aircraft. At one point in the project it was discovered that the wires (manufactured to specification) were too short. With the 530 kilometers of wiring needed, this was a huge problem. The problem had been caused by the “fact that the different design groups working on the project had used different Computer Aided Design (CAD) software to create the engineering drawings … German and Spanish designers had used one version of the software (CATIA version 4), while British and French teams had upgraded to version 5” (idem). This problem led to design inconsistencies and mismatched calculations, which had significant implications. Chief salesman for Airbus at the time, John Leahy, commented that “people were in denial” (Clark, 2006). This denial led not only to a few years delay, but it cost Airbus a whopping 6,1 billion dollars extra. All consequences of the decision to continue the project despite the fact that two different CAD systems were in use. The Airbus A380 project, as one of many, shows how important it is to discuss how these situations can be improved.

Previous literature has written extensively on reasons why projects aren’t killed and what some of the early warning signs are (Sleesman et al., 2012; Keil & Robey, 2001) but has scarcely addressed how managers can be motivated to kill futile projects. This chapter aims to fill this gap by focusing on how managers, also referred to as decision makers, can be motivated to kill futile projects. Specifically, the following overarching research question will be addressed:

This question will be explored through several steps. First of all the definition of ‘futile project’ will be established. After this, a review of previous literature will address why managers don’t kill futile projects. Due to the lack of literature on what organizational forms and incentive structures can be used to motivate managers to kill futile projects, it is important to explore why managers don’t kill futile projects in the first place. Knowing this, this chapter can explain how and which organizational forms and incentive structures can motivate or demotivate managers to kill futile projects.

Background

In previous literature ‘futile project’ is not a familiar term. Instead, terms like “runaway project” (Keil & Robey, 2001), “escalating project” (Keil & Robey, 2001), ”throwing good money after bad (Sleesman et al. 2012) or even ‘failed’ or ‘failing project’ are used. They all, however, describe the same type of project: a project that should be cancelled, a pointless project that has “no hope of fulfilling its original objectives” (Dilts & Pence, 2006, p. 380). These type of projects often aren’t terminated, even though there are compelling reasons to do so. The responsibility of termination often falls upon the manager. A peculiar thing, Dilts & Pence (2006) argue: “while decisions to terminate a project concern the total organization, these decisions are still made by individuals” (380). Managers, however, often fail to make this decision.