CREATIVE PROJECT MANAGEMENT

Innovative Project Options to Solve Problems On Time and Under Budget

By MICHAEL S. DOBSON, TED LEEMANN

The McGraw-Hill Companies, Inc.

Copyright © 2010 The McGraw-Hill Companies
All rights reserved.
ISBN: 978-0-07-173933-7

Contents

Acknowledgments1 Why Do 70 Percent of Projects Fail?2 What We Know and What We Think3 The Most Dangerous Word Is a Premature Yes4 Good Enough, Barely Adequate, Failure5 When the Project Appears Impossible6 Knowns and Unknowns: The Risk Factor7 Project: Intelligence8 It Takes a Village to Wreck a Project9 Framing Change10 Salvaging Project ValueAppendix A: Questions for the Creative Project ManagerAppendix B: Cognitive BiasesBibliographyIndex

Excerpt

CHAPTER 1

Why Do 70 Percent of Projects Fail?

We should be careful to get out of an experience only the wisdom that is init—and stop there; lest we be the cat that sits down on a hot stove-lid.She will never sit down on a hot stove-lid again—and that is well; but shewill also never sit down on a cold one anymore.

—Mark Twain, Following the Equator, 1897

Why Projects Fail

If project management is such a good idea, why do 70 percent of all projectsfail, including those led by experienced and capable project managers? Why doesit seem to be so difficult to get projects done within the Triple Constraints oftime, cost, and performance—or, in layperson's language, on time, onbudget, and to spec?

Here are a few instructive examples of some of the more recent spectacularfailures in project management:

* In 2006, a $400 million purchasing system for Ford Motor Company was simplyabandoned.

* Software errors in a U.K. Inland Revenue system resulted in a $3.45 billiontax-credit overpayment.

* The infamous automated baggage system at Denver International Airport burnedthrough $250 million before being abandoned as un-workable.

* The U.S. Department of Defense's $6 billion Kinetic Energy Interceptor programwas terminated in 2009 after it was determined that it would not achieve itsgoals.

That's not all. Let's look at some numbers on project performance, compiled bythe Standish Group. This organization has tracked project performance since1994. Every two years, the Standish Group issues the CHAOS Report, whichanalyzes projects primarily in the software area. In the 2009 CHAOS Report, theyreported these abysmal numbers:

* 32 percent of projects were delivered on time, on budget, and with therequired features and functions.

* 44 percent were finished either late, over budget, or only partiallycompleted.

* 24 percent failed altogether, and they were canceled or abandoned.

There's good news and bad news here. The good news is that in 1994, when theStandish Group began tracking data, only 16 percent of projects succeeded inmeeting the Triple Constraints (on time, on budget, to spec). On the other hand,the 2009 report shows that there's been a downtick in success (34 percent to 32percent) and a significant uptick in failure (from a low of 15 percent to 24percent).

For challenged projects, those that succeed in some elements and fail in others,the good news is that average budget overrun has dropped from 180 percent toonly 43 percent. On the less positive side, time overruns have gone up 30percent, and the percentage of features that have made it into the final producthas dropped from 67 percent to 52 percent.

During this time, nearly 260,000 project managers earned the prestigious ProjectManagement Professional (PMP) designation from the Project Management Institute(PMI). But the track record of improved project performance is lackluster atbest.

What's going on?

A significant amount of study and reporting going back several decades has shedlight on some of the reasons for these failures:

* The 1998 Bull survey, conducted by the French computer company Bull,identified the major causes of information technology (IT) project failure as abreakdown of communications, a lack of planning, and poor quality control.

* KPMG Canada, in 1997, identified the core project failure issues as poorplanning, weak business case, and a lack of top management involvement andsupport.

* The Standish Group's 1995 CHAOS Report named incomplete requirements and lackof user involvement as reasons for project failure.

* The OASIG Study, published in 1995 by a U.K. group studying organizationalaspects of information technology, cited lack of attention to the human andorganizational aspects, poor project management, and poor articulation of userrequirements as reasons why projects failed.

But poor planning, weak business case, and inattention to human andorganizational aspects aren't causes; rather, they are symptomsof a much large systemic shortcoming. Treating the symptoms isn't the same astreating the underlying conditions. We know some of the root causes. People withpoor interpersonal or team leadership skills create friction, as well asstakeholder conflict, in the project environment. Friction then increasesinefficiency and waste. The size and complexity of an organization increases itsmoment of inertia, and getting anything to move takes enormous effort. Peoplecome and go, missions mutate, information goes missing, and ultimately entropyincreases—we tend to move from order toward chaos.

Things fall apart. It's been said that there are only two reasons for projectfailure:

1. Things that nobody thought of or prepared for

2. Things that everybody thought of, but nobody did anything about

If you think about it, these reasons alone cover almost every potentialincident. How often have you experienced project problems because a couple ofthe people working on your project were suddenly pulled off halfway through? Howabout a major change ordered in one or more of the Triple Constraints when theproject is three-quarters completed? Perhaps there's some recurrent problem inthe project environment that manages to happen every single time. Things takelonger than you expected. Not everybody is really on board. There's always alayer of technical complexity no one expected. Stakeholders don't really knowwhat they want, or they expect you to figure it out magically. All of theseproblems have the same result: a mess.

But do you account for these situations in your project planning? For a fewoutstanding project managers, the answer is at least a partial yes. For most ofus, the answer rests somewhere between seldom and never.

Four Essential Project Questions

If you take the list of reasons from the studies mentioned previously, you canboil them down into the following four (often unasked) questions:

1. Why are we doing this? (Business case)

2. Who has an interest in what we're doing, and what do they each want and need?(Human and organizational aspects)

3. What do we have to do, and how are we going to do it? (Project management,including planning and quality control)

4. Who needs to be involved, and in what way? (Top management and userinvolvement and support)

The official standards of...