Why Megaprojects Fail So Often-Seven Key Mistakes

By way of introducing the reader to the strange world of megaprojects, I am starting by discussing seven critical mistakes that I have seen most often in my 40 years of studying these projects, first at The Rand Corporation, and then for the last 35 years, at Independent Project Analysis (IPA). If you are responsible for a megaproject right now, try to ask yourself, "Am I now in the process of making one of these whopper blunders?"

After outlining how to do large projects well to the executive committee of a large company, the CEO asked me an obvious question: "Given that all of this is rather straightforward [he actually said "smashingly banal"], why can't we do it?" The answer was one he anticipated and feared: "Because you are incapable of generating the kind of deep cooperation within the company that is necessary to do these projects well." Most of the big mistakes that companies make in developing and executing these projects stem from a basic lack of being able to pursue a common goal with clarity and good behavior.

This book is mostly about mistakes, often masked with the bravado of "taking daring risks," but in the end, just plain mistakes. So, I thought it appropriate to start our discussion of megaprojects with seven whopper mistakes that doomed too many of these projects from the start. For the most part, the engineers on these projects tend to make little mistakes, although some of them occasionally cascade into disaster. Most big mistakes are made by senior business managers in the sponsoring firms. The reason they make most of the big mistakes is because they have control of the things that matter most: strategy, money, and people. In most megaproject development, the most important single relationship among the many thousands of relationships involved is the one between the business director for the project and the project manager, often called the project director.

So here are my top Sorry Seven.

1. I want to keep it all!

In days of yore, greed was considered a bad thing, even in business, because greed was liable to get us into trouble. I am pleased to report that in megaprojects, greed still works that way. When companies approach these projects with a view of trying to take as much of the pie as they possibly can, they lose sight of an essential element in making the project succeed: the allocation of the project's potential value in a way that provides a stable foundation on which the project can be executed. This will be a primary subject of Chapter 5. Working a deal that will be seen as essentially unfair to other stakeholders will tend to backfire. Greed generates an imbalance in the distribution of cost and rewards of the project.

Most commonly, a project with a greedy lead sponsor falls apart in the development (Shaping) phase, so we end up with nothing rather than all of it. In other cases, the project proceeds, but those who feel they have been treated unfairly never let go of their opposition. They then add turbulence to the project environment, giving project directors more trouble than they can manage. By their nature, megaprojects often suffer with turbulent project environments. Adding to that turbulence is a recipe for failure.

2. I want it NOW!

Schedule pressure dooms more megaprojects than any other single factor. When there is pressure to quickly move along a project from the outset, corners get cut and opportunists have a field day.

A classic case was a group of difficult deepwater petroleum developments that was put on a fast track when the CEO mentioned in a meeting with the financial community that the projects would go into production on a particular date. The project community's reaction within the company was "It can't be done!" but that didn't deter an ambitious vice president who saw an opportunity to ingratiate himself with the boss. He then set up a "daring and ambitious" program with an inexperienced contractor to deliver the projects in 70% of industry average time at 70% of industry average cost. The result was a program overrun of several billions of dollars, and the largest and most important project was a fully four years late and $2 billion to $3 billion overrun. (We will never know for sure how much!)

No project should ever be deliberately slow. (If it really doesn't make any difference when the project is completed, you probably shouldn't be doing the project now anyway.) But taking risks with megaproject schedules is a fool's game. Every megaproject has an appropriate pace at which the project can be developed and executed successfully. Furthermore, that pace is known with a fair degree of confidence early on if good practice is followed. If the economics of the project require an accelerated schedule, then the appropriate conclusion is that project is uneconomic and should not be done. Unlike smaller projects, megaprojects cannot be used to "fill in a gap" in your production or "meet a market window." When the calendar rather than the needs of the project drives the schedule, the project fails. We return to the issue of fast-tracking megaprojects in numerous places in the chapters to follow.

3. Don't worry, we'll work out the details of the deal later.

As a megaproject director friend of mine likes to say: "The deal drives the project; the project can't drive the deal!" I would add that the project can drive the deal, but it never turns out to be a good deal. The business deal and the project have to develop together and inform each other, but the deal governs. The deal establishes the parameters and the priorities for the project. The deal determines the relative importance of capital cost versus operating cost and cost versus schedule. The deal also determines how big the scope can be.

Many megaprojects center on a deal between a resource holder, for example, petroleum, minerals deposit, and so on, and a company with the technical expertise to develop that resource and sell the product. The basic contours of the deal between the resource holder and the resource developer must be decided quite early in the front-end development of the project. The deal is what will ultimately shape how money will be made as well as how it will be divided. In the absence of the deal, the project is directionless. If project development continues without the deal informing its shape, the chances that the deal will never be struck increase. Furthermore, if the potential partners cannot agree fairly quickly on the shape of the deal, there may be something terribly amiss. Let me cite an egregious example.

A European company was developing a large project (~$7 billion) in the Middle East with a resource holder. The idea was that the resource holder would provide the feedstock at a discounted rate to promote industrialization and job creation; however, the negotiations over the formula for this went nowhere while the project was busy being developed and defined. When we challenged the rationality of this situation with the company executive driving the deal, we were brushed aside with a "You don't understand the Middle East." Finally, the invitations to bid were issued and over $250 million of the company's money had been spent and the board of directors finally required a deal or no authorization. When there was no deal forthcoming, the company was forced to cancel the project and eat the loss. What was going on? The resource holder didn't actually have the feedstock and exploration efforts were coming up empty. Not wanting to lose face (and make their resource situation known to the world), they dragged their feet until the sponsor quit. They then publicly blamed the sponsor for killing the project and being an unreliable and untrustworthy company! And who is it exactly who doesn't know the Middle East?

4. Why do we have to spend so much up front?

Every project professional worthy of the title knows that skimping on the front-end definition of a project is stupid. When it comes to the biggest and most important projects that we do, we routinely skimp on the front-end. Megaprojects-with so much at stake-are routinely less well defined at authorization than smaller, less important projects. The primary reasons are time (see preceding mistake No. 2) and money (see preceding mistake No. 1).

Depending on the specifics of the project, doing a thorough job defining and planning an industrial megaproject takes 3% to 5% of eventual total capital cost. Let's be clear: on a megaproject, that is a lot of money. The cost, however, of not spending the money is much, much more.

Senior managers are understandably concerned that if they spend, say, $100 million and the project is canceled, they are stuck with the bill. Even worse, from their perspective the $100 million is expense, not capital, and is therefore deducted immediately from earnings. However, when senior managers are faced with this situation as a realistic possibility, it is symptomatic of other problems.

Sometimes managers find themselves in this risk of loss position because the resource holder has deliberately set them up. Some resource holders want no decision points between the initial "memorandum of understanding" (which has no binding effect) and the full-funds authorization of the project. This is a simple bargaining ploy: if I can get them to spend enough money, they are...