68,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Fachliteratur
- Sprache: Englisch
Best practices for picking up the pieces when projects fail There are plenty of books available offering best practices that help you keep your projects on track, but offer guidance on what to do when the worst has already happened. Some studies show that more than half of all large-scale project fail either fail completely, or at least miss targeted budget and scheduling goals. These failures cost organizations time, money, and labor. Project Recovery offers wise guidance and real-world best practices for saving failed projects and recovering as much value as possible from the wreckage. Since failing project cannot be managed using the same lifecycle phases employed with succeeding projects, most project management professionals are unprepared to tackle the challenge of project recovery. This book presents valuable case studies and a recovery project lifecycle to help project managers identify and respond effectively to a troubled project. * Includes case studies and best practices for saving failing projects or recovering projects that have already failed * Written by experience project manager Howard Kerzner, the author of Project Management Best Practices, Third Edition * Features proven techniques for performing project health checks and determining the degree of failure and the recovery options available * Includes a new recovery lifecycle that includes phases and checklists for turning around failing projects With comprehensive case studies, checklists, worksheets, and cross listings to the appropriate project management body of knowledge, Project Recovery offers a much needed lifeline for managers facing the specter of failure.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 628
Veröffentlichungsjahr: 2014
Ähnliche
Contents
Preface
Chapter 1: Understanding Success and Failure
1.0 Introduction
1.1 Success: Historical Perspective
1.2 Early Modifications to Triple Constraints
1.3 Primary and Secondary Constraints
1.4 Prioritization of Constraints
1.5 From Triple Constraints to Competing Constraints
1.6 Future Definitions of Project Success
1.7 Different Definitions of Project Success
1.8 Understanding Project Failure
1.9 Degrees of Project Failure
1.10 Other Categories of Project Failure
1.11 Summary of Lessons Learned
Chapter 2: Causes of Project Failure
2.0 Introduction
2.1 Facts about Project Failure
2.2 Causes of Project Failure
2.3 Schedule Failure
2.4 Failures due to Unknown Technology
2.5 Project Size and Success/Failure Risk
2.6 Failure due to Improper Critical Failure Factors
2.7 Failure to Establish Tracking Metrics
2.8 Failing to Recognize Early Warning Signs
2.9 Improper Selection of Critical Team Members
2.10 Uncertain Rewards
2.11 Estimating Failures
2.12 Staffing Failures
2.13 Planning Failures
2.14 Risk Management Failures
2.15 Management Mistakes
2.16 Lacking Sufficient Tools
2.17 Failure of Success
2.18 Motivation to Fail
2.19 Tradeoff Failures
2.20 Summary of Lessons Learned
Chapter 3: Business Case Failure
3.0 Introduction
3.1 Changing Stakeholders
3.2 Revalidation of Assumptions
3.3 Managing Innovation
3.4 Examples of Changing Business Cases
3.5 PROLOGUE TO THE Iridium Case Study
3.6 Rise, Fall and Resurrection of Iridium
3.7 Summary of Lessons Learned
Chapter 4: Sponsorship/Governance Failures
4.0 Introduction
4.1 Defining Project Governance
4.2 Project versus Corporate Governance
4.3 Roles, Responsibilities and Decision-Making Authority
4.4 Governance Frameworks
4.5 Governance Failures
4.6 Why Projects Are Hard to Kill
4.7 Collective Belief
4.8 Exit Champion
4.9 When to Give Up
4.10 Prologue to the Denver International Airport Case Study
4.11 Denver International Airport
Appendix A
Appendix B: Jokes about the Abbreviation DIA
4.12 Denver International Airport Baggage-Handling System: Illustration of Ineffective Decision Making
4.13 Summary of Lessons Learned
Chapter 5: Project Politics and Failure
5.0 Introduction
5.1 Political Risks
5.2 Reasons for Playing Politics
5.3 Situations Where Political Games Will Occur
5.4 Governance Committee
5.5 Friends and Foes
5.6 Attack or Retreat
5.7 Need for Effective Communications
5.8 Power and Influence
5.9 Managing Project Politics
5.10 Prologue to the Space Shuttle Challenger Disaster Case Study
5.11 Space Shuttle Challenger Disaster
5.12 Summary of Lessons Learned
Chapter 6: Software Failures
6.0 Introduction
6.1 IT’s Biggest Failures
6.2 Software Bugs
6.3 Causes of Failure in Software Projects
6.4 Large-Scale IT Failure
6.5 Worst Possible Failure: FoxMeyer Drugs
6.6 London Heathrow Terminal
6.7 Summary of Lessons Learned
Chapter 7: Safety Considerations
7.0 Importance of Safety
7.1 Boeing 787 Dreamliner Battery Problems
7.2 Airbus A380 Problems
7.3 Summary of Lessons Learned
Chapter 8: Scope Creep
8.0 Understanding Scope Creep
8.1 Creeping Failure
8.2 Defining Scope
8.3 Scope Creep Dependencies
8.4 Causes of Scope Creep
8.5 Need for Business Knowledge
8.6 Ways to Minimize Scope Creep
8.7 Sydney Opera House
8.8 Summary of Lessons Learned
Chapter 9: Project Health Checks
9.0 Need for Project Health Checks
9.1 Understanding Project Health Checks
9.2 Who Performs Health Checks?
9.3 Health Check Life-Cycle Phases
9.4 Project Management Failure Warning Signs
9.5 Summary of Lessons Learned
Chapter 10: Techniques for Recovering Failing Projects
10.0 Understanding Troubled Projects
10.1 Root Causes of Failure
10.2 Definition Phase
10.3 Early Warning Signs of Trouble
10.4 Selecting Recovery Project Manager (RPM)
10.5 Recovery Life-Cycle Phases
10.6 Understanding Phase
10.7 Audit Phase
10.8 Tradeoff Phase
10.9 Negotiation Phase
10.10 Restart Phase
10.11 Execution Phase
10.12 Project Recovery versus Project Rescue
10.13 Recovery Decision
10.14 Summary of Lessons Learned
Index
List of Tables
Table 1-1 Components of Client’s Value/Success Constraint
Table 1-2 PMBOK® Guide Alignment to Lessons Learned
Table 2-1 PMBOK® Guide Alignment to Lessons Learned
Table 3-1 Assumption Validation Checklist
Table 3-2 PMBOK® Guide Alignment to Lessons Learned
Table 4-1 Project Governance Approaches
Table 4-2 Current Service Characteristics: United Airlines and Continental Airlines, December 1993 and April 1994
Table 4-3 Airlines Serving Denver, June 1994
Table 4.4 Top Ten Domestic Passenger Origin-Destination Markets and Airline Service, Stapleton International Airport (for 12 months ending September 30, 1993)
Table 4-5 Enplaned Passengers by Airline, Stapleton International Airport
Table 4-6 Airline Agreements
Table 4-7 Total Construction Costs for Denver Airport
Table 4-8 Outstanding Debt at Denver Airport
Table 4-9 Total Average Airline Costs per Enplaned Passenger
Table 4-10 PMBOK® Guide Alignment to Lessons Learned
Table 5-1 Risk Classification System
Table 5-2 Abort options for the shuttle
Table 5-3 Erosion and Blow-by History (temperature in ascending order from coldest to warmest)
Table 5-4 PMBOK® Guide Alignment to Lessons Learned
Table 6-1 PMBOK® Guide Alignment to Lessons Learned
Table 7-1 PMBOK® Guide Alignment to Lessons Learned
Table 8-1 PMBOK® Guide Alignment to Lessons Learned
Table 9-1 Audit vs. Health Checks
Table 9-2 PMBOK® Guide Alignment to Lessons Learned
Table 10-1 Differences between Recovery and Rescue
Table 10-2 Project Recovery Worksheet
Table 10-3 PMBOK® Guide Alignment to Lessons Learned
List of Illustrations
Figure 1-1 Project success boundary box
Figure 1-2 Project success defined as customer satisfaction
Figure 1-3 Competing constraints
Figure 1-4 Future PMBOK® Guide and metrics
Figure 1-5 Area of knowledge metric handouts
Figure 1-6 Components of value success constraint
Figure 1-7 Some projects will fail
Figure 2-1 Typical success rate curve versus project costs
Figure 2-2 Project organization
Figure 2-3 Failures due to optimistic planning
Figure 2-4 Failures due to pessimistic planning
Figure 2-5 Risk management’s contribution to failure
Figure 2-6 Tradeoff risks
Figure 3-1 Typical satellite communication architecture
Figure 4-1 Difference in responsibilities
Figure 4-2 Differences in decision-making authority
Figure 4-3 Typical project governance structure
Figure 4-4 U.S. airports served nonstop from Denver
Figure 4-5 Comparative United Airlines service at hub airports, June 1983 and June 1994
Figure 4-6 Enplaned passenger market shares at Denver Airports
Figure 4-7 Connecting passenger market shares at Denver Airports
Figure 5-1 Stakeholder mapping
Figure 5-2 Solid rocket booster
Figure 5-3 Location of O-rings
Figure 5-4 Cross section showing leak test port
Figure 5-5 Field joint rotation
Figure 8-1 Project boundary
Figure 10-1 Recovery life-cycle phases
Figure 10-2 Tradeoff options
Pages
iii
iv
v
vi
xi
xii
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
Guide
Cover
Table of Contents
Begin Reading
PROJECT RECOVERY
Case Studies and Techniques for Overcoming Project Failure
Harold Kerzner, PH.D.
Cover design: Wiley
Cover image: ©iStockphoto.com/Studio-Pro
Copyright © 2014 by International Institute for Learning, Inc., New York, New York. All rights reserved.
Published by John Wiley & Sons, Inc., Hoboken, New Jersey
Published simultaneously in Canada
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at www.wiley.com/go/permissions.
Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with the respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor the author shall be liable for damages arising herefrom.
For general information about our other products and services, please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.
Wiley publishes in a variety of print and electronic formats and by print-on-demand. Some material included with standard print versions of this book may not be included in e-books or in print-on-demand. If this book refers to media such as a CD or DVD that is not included in the version you purchased, you may download this material at http://booksupport.wiley.com. For more information about Wiley products, visit www.wiley.com.
Library of Congress Cataloging-in-Publication Data
Kerzner, Harold.
Project recovery : case studies and techniques for overcoming project failure / Harold Kerzner.
pages cm
Includes index.
ISBN 978-1-118-80919-8 (cloth); ISBN 978-1-118-80917-4 (ebk); ISBN 978-1-118-80919-8 (ebk); ISBN 978-1-118-84161-7 (ebk)
1. Project management. I. Title.
HD69.P75K4955 2013
658.4'04—dc23
2013035013
To our children Jackie, Andrea, Jason, Lindsey, Jason Berk, and our first grandchild, Stella Harper Berk. The title of this book was in no way created with our children in mind.
PREFACE
Having spent nearly five decades involved in project management, my greatest frustration has been how little we have learned over the years from project failures. Newspaper and journal articles thrive on project disasters. The greater the disaster and the larger the financial investment or loss, the greater the number of articles that appear.
We also have a poor definition of what constitutes a failure. When something fails, you generally assume that it cannot be corrected. Articles have been written that describe the opening day of terminal 5 at London Heathrow as a failure. Rather, it should be called a disaster because the opening day problems were corrected. Had it been a failure, terminal 5 would never have opened.
The same holds true for the problems with Boeing’s 787 Dreamliner and the Airbus A380. These two projects are not failures. History will show that they will be regarded as successes. The problems that they have had may be regarded as glitches or partial disasters but not failures as they are sometimes called in the literature.
The book discusses several large project case studies where there are multiple causes for the problems that happened. There are also shorter or condensed cases and smaller situations. The smaller situations generally focus on just one cause. Even though some of the cases and situations are more than a decade old, what is important are the lessons that were learned.
After reading through these cases and situations, you probably recall having lived through many of these situations. Project management has existed for more than half a century. During that time, we have documented mistakes that led to more than a trillion dollars wasted just in IT alone. Every year, many of us read the latest Chaos Report prepared by the Standish Group which lists the causes of IT failures. Then we must ask ourselves: If we know what the causes are, then why do the same causes repeat themselves every year? Why aren’t we doing anything about it? Why are we afraid of admitting that we made a mistake? Why don’t we try to prevent these problems from happening again?
Some industries are more prone to these mistakes than others. But we are learning. We have university degrees in project management where these case studies are prime learning tools. The people coming through these courses will be the project management leaders of tomorrow. Wishful thinking says that we would like books like this not to be necessary in the future.
What is important about many of the case studies identified in this book is that effective recovery techniques may have been able to reduce the impact of or even eliminate many of these disasters. Usually there are early warning signs of disaster that signal us to begin the recovery process. In each of the case studies and situations are lessons learned that provide us with insight in techniques we should use to recover failing projects. There are tools that can be used as well to support the techniques.1 The first nine chapters of this book are designed as feeders for Chapter 10, which focuses directly on techniques for the recovery process.
Harold Kerzner
The International Institute for Learning
1.
An excellent reference for some tools that can support the techniques discussed in this book can be found in Cynthia Stackpole Snyder,
A Project Manager’s Book of Forms: A Companion to the PMBOK® Guide
, Second Edition, Wiley, Hoboken, NJ, 2013.
CHAPTER 1UNDERSTANDING SUCCESS AND FAILURE
1.0 INTRODUCTION
Most people have a relatively poor understanding of what is meant by project success and project failure. As an example, let’s assume you purchase a new car that contains a lot of electronic gadgetry. After a few days, some of the electronics fail to work correctly. Was the purchase of the new car a success or a failure? Most people would refer to this as a glitch or small problem that can be corrected. If the problem is corrected, then you would consider the purchase of the new car as a success.
But now let’s assume you purchase a $10 million software package for your company. The software fails to work correctly and your company loses $50 million in sales before the software bugs are removed and the system operates as expected. In this example, the literature would abound with stories about the failure of your software package and how much money your company lost in the process. But if the software package is now bug free and your company is generating revenue from use of the package, then why should the literature refer to this as a failure? Was the purchase and eventual use of the software package a success or a failure? Some people might consider this as a success with glitches along the way that had to be overcome. And we all know that software development rarely occurs without glitches.
Defining success and failure is not clear cut. We all seem to understand what is meant by total success or total failure. But the majority of projects fall into the grey area between success and failure where there may not be any clear definition of the meaning of partial success or partial failure.
Project success has traditionally been defined as completing the requirements within the triple constraints of time, cost and scope (or performance). This is the answer that had been expected of students on most exams. In the same breath, project failure had been defined as the inability to meet the requirements within time, cost and scope. Unfortunately, these definitions do not provide a clear picture or understanding of the health of the project and whether or not success has been achieved. And to make matters worse, the definition of success or failure is treated like the definition of beauty; it is in the eyes of the beholder. Today, we are finally beginning to scrutinize the definitions of project success and project failure.
1.1 SUCCESS: HISTORICAL PERSPECTIVE
The complexities with defining project success and failure can be traced back to the early days of project management. The birth and initial growth of project management began with the Department of Defense (DOD) in the United States. With thousands of contractors, the DOD wanted some form of standardization with regard to project performance reporting. The earned value measurement system (EVMS) was created primarily for this purpose.
For the EVMS to be effective, metrics were needed to track performance and measure or predict project success. Everybody knew that measuring success was complicated and that predicting project success correctly required several metrics. Unfortunately, our understanding of metrics and metric measurement techniques was relatively poor at that time. The result was the implementation of the rule of inversion. The rule of inversion states that the metrics with the highest informational value, especially for decision making and measuring success, should be avoided or never measured because of the difficulty in data collection. Metrics like time and cost are the easiest to measure and should therefore be used. The result was that we then spent too much time on these variables that may have had the least impact on decision making and measuring and predicting project success or project failure. The EVMS, for all practical purposes, had two and only two metrics: time and cost. Several formulas were developed as part of the EVMS, and they were all manipulations of time and cost.
The definition of success was now predicated heavily upon the information that came out of the EVMS, namely time and cost. The triple constraints of time, cost and scope were established as the norm for measuring and predicting project success.
Unfortunately, good intentions often go astray. DOD contracts with the aerospace and defense industry were heavily based upon the performance of the engineering community. In the eyes of the typical engineer, each of the triple constraints did not carry equal importance. For many engineers, scope and especially technical achievement were significantly more important than time or cost. The DOD tried to reinforce the importance of time and cost, but as long as the DOD was willing to pay for the cost overruns and allow schedule slippages, project success was measured by how well performance was achieved regardless of the cost overruns, which could exceed several hundred percent. To make matters worse, many of the engineers viewed project success as the ability to exceed rather than just meet specifications, and to do it using DOD funding. Even though the triple constraints were being promoted as the definition of success, performance actually became the single success criterion.
1.2 EARLY MODIFICATIONS TO TRIPLE CONSTRAINTS
The DOD’s willingness to tolerate schedule slippages and cost overruns for the sake of performance gave the project management community the opportunity to consider another constraint, namely customer acceptance. Projects, by definition, are most often unique opportunities that you may never have attempted before and may never attempt again. As such, having accurate estimating databases that can be used to predict the time and cost to achieve success was wishful thinking. Projects that required a great deal of innovation were certainly susceptible to these issues as well as significant cost overruns. To make matters worse, the time and cost estimates were being established by people that knew very little about the complexities of project management and had never been involved in innovation activities.
People began to realize that meeting the time and cost constraints precisely would involve some degree of luck. Would the customer still be willing to accept the deliverables if the project was late by one week, two weeks or three weeks? Would the customer still be willing to accept the deliverables if the cost overrun was $10,000, $20,000, or $100,000?
Now it became apparent that success may not appear as just a single point as shown in Figure 1-1. The small circle within the cube in Figure 1-1 represents the budget, schedule and scope requirements defined by the customer. However, given the risks of the project, success may be identified as all points within the cube. In other words, if the schedule were to slip by up to two weeks, and the budget was exceeded by up to $50,000, and the client was able to receive up to 92% of the initial requirements, then the project might still be regarded as a success. Therefore, success is not just a single point. The hard part is identifying the size and boundaries of the success cube.
Figure 1-1 Project success boundary box.
Using Figure 1-1, the only definition of success was now customer satisfaction or customer acceptance. For some customers and contractors, time and cost were insignificant compared to customer satisfaction. Having the deliverables late or over budget was certainly better than having no deliverables at all. But customers were not willing to say that success was merely customer acceptance. Time and cost were still important to the customers. As such, the triple constraints were still used but surrounded by a circle of customer satisfaction, as shown in Figure 1-2.
Figure 1-2 Project success defined as customer satisfaction.
Figure 1-2 made it clear that there may be several definitions of project success because not all constraints carry equal importance. On some projects, customer acceptance may be heavily biased toward cost containment whereas on other projects the scheduled delivery date may be critical.
1.3 PRIMARY AND SECONDARY CONSTRAINTS
As projects became more complex, organizations soon found that the triple constraints were insufficient to clearly define project success even if the constraints were prioritized. There were other constraints that were often more important than time, cost and scope. These “other” constraints were referred to as secondary constraints with time, cost and scope being regarded as the primary constraints. Typical secondary constraints included:
Using the customer’s name as reference at the completion of the project
Probability of obtaining follow-on work
Financial success (i.e., profit maximization)
Achieving technical superiority (i.e., competitive advantage)
Aesthetic value and usability
Alignment with strategic planning objectives
Maintaining regulatory agency requirements
Abiding by health and safety laws
Maintaining environmental protection standards
Enhancing the corporate reputation and image
Meeting the personal needs of the employees (opportunities for advancement)
Supporting and maintaining ethical conduct (Sarbannes-Oxley law)
The secondary constraints created challenges for many companies. The EVMS was created to track and report only the primary constraints. To solve the tracking problem, companies created enterprise project management methodologies (EPMs) that incorporated the EVMS and also tracked and reported many of the secondary constraints. This was of critical importance for some companies because the secondary constraints could be more important than the primary constraints. As an example, consider the following situation:
Situation: A vendor was awarded a contract from a new client. The vendor had won the contract because they underbid the job by approximately 40%. When asked why they had grossly underbid the contract, the vendor stated that their definition of success on this contract was the ability to use the client’s name as a reference when bidding on other contracts for other clients. Completing the contract at a loss was not as important as using the client’s name as a reference in the future.
LESSON LEARNED
It is important to have a clear definition of success (and failure) at the beginning of the project.
Even though we now had both primary and secondary constraints, companies still felt compelled to use the traditional triple constraints of time, cost and scope as the primary means for defining success. As shown in Figure 1-3, all of the secondary constraints were inserted within the triangle representing the triple constraints. In this example, shown in Figure 1-3, image/reputation, quality, risk and value were treated as secondary constraints. Discussions over the secondary constraints were made by analyzing the impact they had on the primary constraints, namely whether the secondary constraints elongated or compressed any of the primary constraints.
Figure 1-3 Competing constraints.
1.4 PRIORITIZATION OF CONSTRAINTS
As the number of constraints on a project began to grow, it became important to prioritize the constraints. Not all constraints carry the same weight. As an example, many years ago I had the opportunity to work with some of Disney’s project managers at Disneyland and Disneyworld. These were the project managers responsible for creating new attractions. At Disney, there were six constraints on most projects:
Time
Cost
Scope
Safety
Quality
Aesthetic value
At Disney, safety was considered as the single most important constraint, followed by quality and aesthetic value. These three were considered as the high-priority constraints never to undergo any tradeoffs. If tradeoffs were to be made, then the tradeoffs must be made on time, cost or scope. The need for prioritization of the success criteria was now quite clear.
1.5 FROM TRIPLE CONSTRAINTS TO COMPETING CONSTRAINTS
When the Project Management Institute (PMI) released the fourth edition of the PMBOK® Guide, the use of the term triple constraints was replaced with the term “competing constraints.” Defining project success was now becoming significantly more complicated because of the increasing number of constraints and their importance in defining project success. Everybody knows and understands that “what gets measured, gets done.” Therefore, there were three challenges that soon appeared:
Each new constraint has to be tracked the same way that we traditionally tracked time and cost.
In order to track the new constraints, we need to establish metrics for each of the constraints. You cannot have a constraint without having a metric to confirm that the constraint is being met.
Metrics are measurements. We must understand the various measurement techniques available for tracking the new metrics that will be used to predict and report success.
Project success, metrics and measurement techniques were now interrelated. Historically, success was measured using only two knowledge areas of the PMBOK® Guide, namely time management and cost management. Today, success metrics can come from any of the 10 knowledge areas in the fifth edition of the PMBOK® Guide. It is entirely possibly that, in the future, we will modify the inputs, tools and outputs discussed in the PMBOK® Guide to include a metric library as shown in Figure 1-4. In future editions of the PMBOK® Guide we may even have supplemental handouts for each knowledge area describing the metrics that are available and how they can be used to track and predict project success. This is shown in Figure 1-5.
Figure 1-4 Future PMBOK® Guide and metrics.
Figure 1-5 Area of knowledge metric handouts.
1.6 FUTURE DEFINITIONS OF PROJECT SUCCESS
Advances in metrics and measurement techniques have allowed us to change our definition of project success and failure. Previously, we stated the importance of customer acceptance as a success criterion. But today, even the term “customer acceptance” is being challenged. According to a study (“Customer Value Management: Gaining Strategic Advantage,” The American Productivity and Quality Center [APQC], © 1998, p. 8):
Although customer satisfaction is still measured and used in decision-making, the majority of partner organizations [used in this study] have shifted their focus from customer satisfaction to customer value.
Advances in measurement techniques have now allowed us to measure such items as value, image reputation and goodwill. Therefore, we can now establish a rather sophisticated and pin-pointed approach to defining project success. Value may become the most important term in defining project success. Having a significant cost overrun and/or schedule slippage may be acceptable as long as business value was created. During the selection of the projects that go into the portfolio of projects, value may become the driver for project selection. After all, why work on a project if the intent is not to create some form of business value? Value may also change the way we define a project. As an example, consider the following:
PMBOK® Guide
—Fifth Edition
, definition of a project: A temporary endeavor undertaken to create a unique product, service or result.
Future definition of a project:
A collection of sustainable business value scheduled for realization.
Value can also be used to define project success. As an example:
Traditional definition of project success:
Completion of the project within the triple constraints of time, cost and scope.
Future definition of project success:
Achieving the desired business value within the competing constraints.
The above definitions make it clear that there is now a business and/or value component added to our definition of project success. Value may very well become the driver for how we measure success or failure in the future. Success or failure is no longer being measured solely by time and cost.
Measuring value by itself is extremely difficult. To overcome the potential problems, it may be easier to define the value success constraint as a composition of other constraints or attributes as shown in Figure 1-6. In other words, constraints from all or part of the six interrelated components in Figure 1-6 will make up the value success constraint.
Figure 1-6 Components of value success constraint.
To illustrate how this might work in the future, let’s consider the following scenario. The project manager will meet with the client and possibly the stakeholders at project initiation to come to an agreement as to what is meant by value since value will be perhaps the primary measurement of project success. You show the client the six success constraint categories as listed in Figure 1-6. You and the client must then agree on which constraints will make up the success or value constraint. Let’s assume that the client defines project value according to a mixture of the four constraints listed in Table 1-1.
TABLE 1-1 Components of Client’s Value/Success Constraint
CLIENT’S VALUE FACTORS
SUCCESS CONSTRAINT
WEIGHTING FACTOR, %
Quality
Quality
20
Delivery date
Time
30
Usability
Performance
35
Risk minimization
Risk
15
Once the client’s value factors are known, you and the client jointly determine which constraints can be used for measurement purposes, the metrics that will be used and how points will be assigned for staying within each constraint. You and the client must then agree on the weighting factor importance of each of the constraints.
Using this method, success is being measured by the ability to meet the value constraint even though the value constraint is composed of four other constraints. It is entirely possible that you are not maintaining performance within one of the constraints, such as the time constraint, but your performance within the other three constraints more than makes up for it to the point where the client perceives that value is still being accomplished and the project is a success.
You will also notice in this example that cost was not selected as a component of the success criteria or the value constraint. This does not mean that cost is not important. Cost is still being tracked and reported as part of the project management activities but the client does not consider cost as that critical and as part of the success criteria.
As our projects become larger and more complex, the number of constraints used to define success can grow. And to make matters worse, our definition of success can change over the life of the project. Therefore, our definition of success may be organic. Companies will need to establish metrics for tracking the number of success constraints.
The importance of a project success criterion that includes a value component is critical. All too often, projects are completed just to find out that no business value was created. You can end up creating products that nobody will buy. As an example, consider the following example:
Situation: The Iridium Project1 was designed to create a worldwide wireless handheld mobile phone system with the ability to communicate anywhere in the world at any time. Executives at both Motorola and Iridium LLP regarded the project as the eighth wonder of the world. But more than a decade later and after investors put up billions of dollars, Iridium had solved a problem that very few customers needed solved.
The Iridium Project was both a success and a failure at the same time. As a success, the 11-year project was completed just 1 month late and more than 1000 patents were created. As a failure, investors lost more than $4 billion because the marketplace for the product had changed significantly over the life of the project. In retrospect, it appears that project success was measured solely by technical performance and the schedule. Had there been a more complete definition of success, including value constraints based upon a valid business case, the project would have been cancelled due to eroding business value well before billions of dollars were wasted.
LESSON LEARNED
Revalidation of the business case is a necessity especially on long-term projects.
1.7 DIFFERENT DEFINITIONS OF PROJECT SUCCESS
The use of a value constraint to define success can work well as long as everyone agrees on the definition of success. But on large complex projects involving a governance committee made up of several stakeholders, there can be many definitions of success. There can also be more than one definition of success being used for team members working on the same project. As an example:
Situation: During a project management training program for the R&D group of a paint manufacturer, the question was asked: “How does the R&D group define project success?” The answer was simple and concise: “The commercialization of the product.” When asked what happens if nobody purchases the product, the R&D personnel responded, “That’s not our problem. That headache belongs to marketing and sales. We did our job and were highly successful.”
LESSON LEARNED
The business case for a project must have a clearly understood definition of success and hopefully be agreed to by all participants.
1.8 UNDERSTANDING PROJECT FAILURE
Most companies seem to have a relatively poor understanding of what is meant by project failure. Project failure is not necessarily the opposite of project success. Simply because we could not meet the project’s success criteria is not an indication that the project was a total failure. Consider the following example:
Situation: During an internal meeting to discuss the health of various projects undertaken to create new products, a vice president complained that less than 20% of the R&D projects were successful and reached the product commercialization stage. He then blamed poor project management for the failures of the other 80% of the projects. The director of the Project Management Office then spoke up asserting that most of the other 80% of the projects were not failures. They had in fact created intellectual property that was later used on other R&D projects (i.e., spinoffs) to create commercially successful products.
LESSON LEARNED
Projects that create intellectual property, perhaps for future use, should not always be regarded as a total failure.
The above example should make it clear that the definition of project failure is more of a grey area than pure black and white. If knowledge and/or intellectual property is gained on the project, then perhaps the project should not be considered as a complete failure. All project managers know that things may not always go according to plan. Replanning is a necessity in project management. We can begin a project with the best of intentions and prepare a plan based upon the least risk. Unfortunately, the least risk plan usually requires more time and more money. If the project must be replanned using least time as the primary success criterion, then we must be willing to incur more risk and perhaps additional costs.
There is no universally accepted diagnosis as to why projects fail because each project has its own set of requirements, its own unique project team and its own success criteria and can succumb to changes in the enterprise environmental factors. Failures can and will happen on some projects regardless of the company’s maturity level in project management. As seen in Figure 1-7, it often takes companies two years or longer to become reasonably good at project management and perhaps another five years to reach some degree of excellence. Excellence in project management is defined as a continuous stream of projects that meet the company’s project success criteria.
Figure 1-7 Some projects will fail.
But as seen in Figure 1-7, even with a high degree of project management excellence, some projects can and will fail. There are three reasons for this:
Any executive that always makes the right decision certainly isn’t making enough decisions.
Effective project management practices can increase your chances of project success but cannot guarantee that success will be achieved.
Business survival is often based upon how well the company is able to accept and manage business risks. Knowing which risks are worth accepting is a difficult process.
1.9 DEGREES OF PROJECT FAILURE
One of the most commonly read reports on why IT projects fail is the Chaos Report prepared by the Standish Group. The Chaos Report identifies three types of IT project outcomes:
Success:
A project that gets accolades and corporatewide recognition for having been completed on time, within budget and meeting all specification requirements.
Challenged:
A project that finally reaches conclusion, but there were cost overruns and schedule slippages, and perhaps not all of the specifications were met.
Failure:
A project that was abandoned or cancelled due to some form of project management failure.
It is interesting to note how quickly IT personnel blame project management as the primary reason for an IT failure. Although these categories may be acceptable for IT projects, it may be better to use the following breakdown for all projects in general:
Complete success:
The project met the success criteria, value was created and all constraints were adhered to.
Partial success:
The project met the success criteria, the client accepted the deliverables and value was created although one or more of the success constraints were not met.
Partial failure:
The project was not completed as expected and may have been cancelled early on in the life cycle. However, knowledge and/or intellectual property was created that may be used on future projects.
Complete failure:
The project was abandoned and nothing was learned from the project.
The following situations provide examples of each of these categories.
Situation: A company undertook a 1-year R&D project designed to create a new product. Assuming the product could be developed, the company had hoped to sell 500,000 units over a 2-year period. During the R&D effort, the R&D project team informed management that they could add significant value to the product if they were given more money and if the schedule were allowed to slip by about 6 months. Management agreed to the schedule slippage and the cost overrun despite resistance from sales and marketing. More than 700,000 units were sold over the first 12 months after product release. The increase in sales more than made up for the cost overrun.
LESSON LEARNED
In this situation, the project was considered as a complete success even though there was a schedule slippage and a cost overrun. Significant value was added to the business.
Situation: A company won a contract through competitive bidding. The contract stipulated that the final product had to perform within a certain range dictated by the product’s specifications. Although there were no cost overruns or schedule slippages, the final product could meet only 90% of the specification’s performance requirements. The client reluctantly accepted the product and later gave the contractor a follow-on contract to see if they could reach 100% of the specification’s performance requirements.
LESSON LEARNED
This situation was considered as a partial success. Had the client not accepted the deliverable, the project may have been classified as a failure.
Situation: A company had a desperate need for software for part of its business. A project was established to determine whether to create the software from scratch or to purchase an off-the-shelf package. The decision was made to purchase an expensive software package shortly after one of the senior managers in a software company made an excellent presentation on the benefits the company would see after purchasing and using the software as stated. After purchasing the software, the company realized that it could not get the expected benefits unless the software was custom designed to its business model. The software company refused to do any customization and reiterated that the benefits would be there if the software was used as stated. Unfortunately, it could not be used as stated, and the package was shelved.
Situation: A hospital had a policy where physicians and administrators would act as sponsors on large projects even though they had virtually no knowledge about project management. Most of the sponsors also served on the committee that established the portfolio of projects. When time came to purchase software for project management applications, a project team was established to select the package to be procured. The project team was composed entirely of project sponsors that had limited knowledge of project management. Thinking that they were doing a good thing, the committee purchased a $130,000 software package with the expectation that it would be used by all of the project managers. The committee quickly discovered that the organization was reasonably immature in project management and that the software was beyond the capabilities of most project team members. The software was never used.
LESSON LEARNED
In the above situation, the company considered the project as a total failure. No value was received for the money spent. Eventually the company committed funds to create its own software package customized for its business applications.
Situation: A company was having difficulty with its projects and hired a consulting company for project management assistance. The decision to hire the company was largely due to a presentation made by one of the partners that had more than 20 years of project management experience.
LESSON LEARNED
The above situation, just like the previous situation, was considered as a complete failure.
After the consulting contract was signed, the consulting company assigned a small team of people, most of which were recent college graduates with virtually no project management experience. The consulting team was given offices in the client’s company and use of client’s computers.
The consulting team acted merely as note-takers in meetings. The quarterly reports they provide to the client were simply a consolidation of the notes they would take during project team meetings. The consulting team was fired since they were providing no value. The client was able to recover from the company’s computers several of the e-mails sent from the consultants to their superiors. One of the e-mails that came from the headquarters of the consulting company stated, “We know we didn’t give you a qualified team, but do the best you can with what you have.” The client never paid the consulting company the balance of the money due on the contract.
LESSON LEARNED
In the above example, the client eventually sued the consulting company for failure to perform and collected some damages. The client considered the consulting project as a complete failure.
Situation: A company worked on an R&D project for more than a year just to discover that what it wanted to do simply would not happen. However, during the research, the company found some interesting results that later could be used in creating other products.
LESSON LEARNED
Although this project was a partial failure, it did create intellectual property that could be used later.
1.10 OTHER CATEGORIES OF PROJECT FAILURE
Rather than defining failure as either partial or total failure, some articles define failure as preimplementation failure and postimplementation failure. With preimplementation failure, the project is never completed. This could be the result of a poor business case, inability of the team to deliver, a change in the enterprise environmental factors, changing business needs, higher priority projects or any other factors which mandate that senior management pull the plug. The result could be a partial or total failure.
With postimplementation failure, the project is completed and everyone may have high expectations that the deliverables will perform as expected. However, as is the case in IT, postimplementation is when the software bugs appear sometimes causing major systems to be shut down until repairs can be made. The larger and more complex the software package, the less likely it is that sufficient test cases have been made for every possible scenario that could happen in implementation. If daily business operations are predicated upon a system that must be shut down, the failure and resulting losses can run into the hundreds of millions of dollars. Consider the following examples:
In 2008, the London Stock Exchange’s clients were trading more than $17 billion each day. On what was expected to be one of the busiest trading days in months largely due to the U.S. government’s takeover of Fannie Mae and Freddie Mac, 352 million shares worth $2.5 billion were traded in the first hour of trading right before the system shut down. For more than 7 hours, investors were unable to buy or sell shares.
In October 2005, British food retailer Sainsbury scrapped a $528 million investment in an automated supply chain management system that was unable to get merchandise from its warehouses to its retail stores. Eventually, the company was forced to hire 3000 additional employees to stock the shelves manually.
In May 2005 Toyota recalled 160,000 Prius hybrid vehicles because warning lights were illuminating unexpectedly and the cars’ gasoline engines began stalling. The culprit was a software bug that was in the car’s embedded code.
On April 16, 2013, a glitch in the reservation system at American Airlines grounded all flights leaving thousands stranded for hours. American Airlines has 3500 flights daily on a worldwide basis and an estimated 100,000 passengers were affected by the delays. Approximately 720 flights were cancelled. Although American Airlines rebooked passengers on other flights, American Airlines also warned that delays could continue for several days, thus affecting future flights. A similar situation occurred at Comair Airlines a few years earlier where more than 1000 flights were cancelled. The glitch was also in the reservation system.
Postimplementation failures can become so costly that a company may find itself on the brink of bankruptcy.
1.11 SUMMARY OF LESSONS LEARNED
It is much more difficult than people believe to have a clear understanding of success and failure. Project complexity will force us to better understand those constraints that have a direct bearing upon the project’s success criteria. Advances must be made in the use of metrics and metric measurement techniques to assist us with a better understanding of success and failure.
A checklist of techniques that might be used for a better understanding of success and failure includes:
Work with the client and the stakeholders to see if an agreement can be reached on the definition of success and failure.
Work with the client and the stakeholders to identify the critical success factors.
Establish the necessary metrics for each of the critical success factors.
Prioritize the critical success factors and the metrics.
Throughout the project, revalidate the business case and the accompanying critical success factors.
Project failures will happen and it may not be the result of poor project management practices.
Project complexity will force us to better understand those constraints that have a direct bearing upon the project’s success criteria.
Advances must be made in the use of metrics and metric measurement techniques.
Table 1-2 provides a summary of the lessons learned and alignment to various sections of the PMBOK® Guide where additional or supporting information can be found. In some cases, these sections of the PMBOK® Guide simply provide supporting information related to the lesson learned. There are numerous sections of the PMBOK® Guide that could be aligned for each lesson learned. For simplicity sake, only a few are listed.
TABLE 1-2PMBOK® Guide Alignment to Lessons Learned
LESSONS LEARNED
PMBOK® GUIDE
SECTIONS
Defining success and failure is not easy.
1.3, 1.4, 2.2.3
Definitions can change from project to project.
2.2.3
Defining success and failure requires a combination of metrics that can be unique for each project and program.
1.3, 1.4, 2.2.3, 8.1.3.3, 8.2.1.3, 8.3.1.2
Not all success and failure constraints carry the same level of importance.
1.4, 2.2.3, 8.3.3.3
There must be a clear definition of success at the beginning of a project and all parties must agree to it.
1.3, 1.4, 2.2.3, 3.3
A project value success factor, which is a combination of several constraints, may be used rather than reporting on all of the constraints.
1.6, 8.1.3.3, 8.2.1.3, 8.3.1.2
Every project should have a business and/or value constraint.
1.6
Revalidation of the business case must be done periodically to make sure that we are still creating business value.
1.4.3, 1.6
There are degrees of project success and failure.
1.3, 1.4, 2.2.3
Project replanning can change the definitions of project success and failure.
2.2.3
The expectation that all projects will be successful is unrealistic.
2.2.3
1.
For information on the Iridium Project, see Harold Kerzner, “The Rise, Fall and Resurrection of Iridium: A Project Management Perspective,”
Project Management Case Studies
, Wiley, Hoboken, NJ, 2013, pp. 327–366. A modified version of the case study appears in Section 3.6.
CHAPTER 2CAUSES OF PROJECT FAILURE
2.0 INTRODUCTION
Projects can fail in any life-cycle phase. When analyzing where failures can occur, we most frequently look at three phases: the project formulation phase, the project implementation phase and the postimplementation phase. Not very many projects fail in the formulation stage. More often than not, the failure occurs during the execution or postimplementation phase. This is particularly true for IT implementation when companies do not spend sufficient time understanding how implementation actually works. During project formulation we assume that the business case is correct. The mistake we make is that we lack an understanding of what questions to ask and to whom the questions should be asked during project formulation. This relates to users not being involved early enough or even throughout the project.
2.1 FACTS ABOUT PROJECT FAILURE
Over the years, we have recognized several facts related to project failures. They include:
Very few projects fail by themselves; rather, it’s the people that fail and the decisions that people make are the wrong decisions.
Even the most reliable systems will fail during implementation—It’s just a matter of when the bugs will appear.
Project failures are more common than most people believe.
There’s no clear definition of project failure.
The line between success and failure is not clear; it is a grey area.
There’s no clear magic bullet to guarantee success or prevent failure.
Failure can occur after successful execution of a project plan because of changing market conditions or the inability to fill an auditorium for a concert.
Factors we use to define success or failure include time, cost, safety, revenue, profits, promotions, loss of employment, customer satisfaction, product deployment and business value.
We can have R&D success and marketing launch failure, i.e., different definitions of success and failure on the same project.
2.2 CAUSES OF PROJECT FAILURE
There are numerous causes that lead to project failure. The causes are not necessarily restricted to specific industries. However, IT projects that fail seem to include many of the causes on the list. For almost 17 years, the Chaos Report has blamed project management for the failure of IT projects. Even though many of these causes are the result of poor project management practices, the real question should be: “Why have these same causes of failure appeared year after year, and we persist in doing nothing to correct the situation?”
Knowing the causes of project failure does not help a company unless the company plans on taking action. Most companies simply do not know what to do to recover a failing project. Other companies do not have sufficient metrics on many of their projects that can be used as early warning indicators and then failure occurs too late for any corrective action to take place.
When a project is completed successfully, we go through excruciating pain to capture best practices and lessons learned. Everyone wants to broadcast to the world what they did well on the project to achieve success. But the same is not true for project failures. For personal reasons, people are reluctant to discuss failures even though more best practices can be learned from failures than from successes. People fear that failures may be used against them during performance reviews.
The list of reasons why projects fail is quite large. Yet most companies either do not recognize the symptoms of failure or disregard the symptoms when they do appear. Even if they see the symptoms, they do not know what actions to take. Typical reasons for failure include:
End-user stakeholders not involved throughout the project
Minimal or no stakeholder backing; lack of ownership
Weak initial business case
Business case deterioration
Business case requirements that changed significantly over the life of the project
Technical obsolescence
Technologically unrealistic requirements
Lack of a clear vision
New executive team in place with different visions and goals
Corporate goals and/or vision not understood at the lower organizational levels
Plan that asks for too much in too little time
Poor estimates, especially financial
Unclear stakeholder requirements
Passive user stakeholder involvement after handoff
Unclear or unrealistic expectations
Unrealistic assumptions, if they exist at all
Plans based upon insufficient data
No systemization of the planning process
Planning performed by a planning group
Inadequate or incomplete requirements
Lack of resources
Assigned resources that lack experience or the necessary skills
Resources that lack focus or motivation
Staffing requirements that are not fully known
Constantly changing resources
Poor overall project planning
Established milestones not measurable
Established milestones too far apart
Environmental factors that have changes causing outdated scope
Missed deadlines and no recovery plan
Budgets exceeded and out of control
Lack of replanning on a regular basis
Lack of attention provided to human and organizational aspects of project
Project estimates that are best guesses and not based upon history or standards
Not enough time provided for estimating
Exact major milestone dates or due dates for reporting not known
Team members working with conflicting requirements
People shuffled in and out of project with little regard for schedule
Poor or fragmented cost control
Each stakeholder uses different organizational process assets, which may be incompatible with each other
Weak project and stakeholder communications
Poor assessment of risks, if done at all
Wrong type of contract
Poor project management; team members possess a poor understanding of project management, especially virtual team members
Technical objectives that are more important than business objectives
Assigning critically skilled workers, including the project manager, on a part-time basis
Not all of the causes of failure are the result of actions taken by the project manager. As an example, procurement often selects the lowest bidder without verifying that the bidders know what the work entails and whether their bid is realistic. After go-ahead, we end up with scope changes that result in cost overruns and schedule delays.
Although any single cause can induce failure, it is more likely that the actual failure is caused by a combination of these causes. Several of the important causes of failure are discussed in the remainder of this chapter. Some of the critical causes of failure are discussed separately in some of the chapters that follow.
2.3 SCHEDULE FAILURE
The literature abounds with causes of project failure and authors are very quick to blame project management. Unfortunately, not all of the causes are or should be attributed to project management. Setting the schedule falls into this category.
