Cover Page


Case Studies and Techniques for Overcoming Project Failure


Harold Kerzner, PH.D.




Wiley Logo

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.


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