Project Recovery

Case Studies and Techniques for Overcoming Project Failure

Harold Kerzner

• Publisher: Wiley
• Year: 2014
• Print ISBN: 9781118809198
• eBook ISBN: 9781118809174
• Edition: 1
• Topic: Business
• Subtopic: Project Management
• Index: Business

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.

CHAPTER 1
UNDERSTANDING 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 wi...

Table of contents

• Cover
• Contents
• Title
• Copyright
• Dedication
• Preface
• Chapter 1: Understanding Success and Failure
• Chapter 2: Causes of Project Failure
• Chapter 3: Business Case Failure
• Chapter 4: Sponsorship/Governance Failures
• Chapter 5: Project Politics and Failure
• Chapter 6: Software Failures
• Chapter 7: Safety Considerations
• Chapter 8: Scope Creep
• Chapter 9: Project Health Checks
• Chapter 10: Techniques for Recovering Failing Projects
• Index
• End User License Agreement