Why 199 of 200 Projects Fail: The Iron Law That Dooms Even the Smartest Ideas (#268)

What do home renovations, space exploration, and nuclear power plants all have in common?

They're ambitious projects that promise transformation, yet, more often than not, they spiral over budget, over time, and under-expectations.

From remodeling a kitchen to building a rocket, the same hidden traps appear.

So why do even smart, experienced people fall into them?

And what can you do to make sure yours is the rare project that actually delivers?

Hi everyone, I'm Lynn Toman and this is Three Takeaways.

On Three Takeaways, I talk with some of the world's best thinkers, business leaders, writers, politicians, newsmakers, and scientists.

Each episode ends with three key takeaways to help us understand the world and maybe even ourselves a little better.

Today, I'm excited to welcome Bent Flubia, widely regarded as the leading expert on why big projects fail and how to make them succeed.

He's the co-author of the bestseller, How Big Things Get Done, creator of the largest research program on major projects, and the thinker behind the iron law of megaprojects.

Bent pioneered reference class forecasting with Nobel laureate Daniel Kahneman and has advised governments, cities, and global companies on projects from infrastructure and energy to tech and culture.

I'm excited to find out why most big projects fail and what it takes to have projects actually fulfill their promises.

Bent, welcome to Three Takeaways.

Thank Thank you very much and thanks for having me.

It is my pleasure.

Bent, what's what you call the iron law of mega projects and what stands out to you as some examples of the worst failures?

The iron law very simply states that a project or projects go over budgets, they go over schedule, and they don't deliver the promised benefits over and over.

Like most things we do, it's supported by data.

And it actually turns out that only 8.5% of projects are delivered both on budget and on time.

And if you include the benefits, so like a triple requirement being on budget, on time and on benefits, only half a percent of projects are doing that.

So that's one in 200 projects.

There's the California rail project, which was supposed to connect, I think, LA and San Francisco.

And now it's many billions of dollars over budget, way behind time and it is only going to connect two cities most people have never heard of what are some other project failures that really stand out to you

recently there have been attempts at building four nuclear reactors in the US at each of two power stations and they have all gone horribly wrong two of them actually was given up on after you know billions of dollars had been spent.

They simply gave up and the others have been completed with huge cost overruns.

So nuclear power in the US and in Europe for that matter is an example of products that abide by the iron law.

A classic example of a huge cost overrun is the Sydney Opera House with a cost overrun of 1,400%, you know, which is one of the highest.

It's not the highest, but it's one of the highest in the world ever.

And 10-year delay, you know, it was delivered 10 years later than planned.

And those are not even the worst things about the project, even though they are really terrible.

Ben, your database on big projects is the largest in the world at over 16,000 projects in over 20 different fields in 100 plus countries.

How far off budget and off time are most projects?

It varies by project type, but I would say if we had to take a rough average around 30, 35 percent, that's the average cost overrun.

And that's measured in constant prices.

So no inflation included.

And it's measured from the final business case.

So quite a conservative measure.

It's the latest stage in the decision-making process before it's decided to do a project.

And these are averages, meaning that individual projects will have much larger cost overruns.

So, Ben, you walk into a billion-dollar project and within 10 minutes, you know it's doomed.

What tips you off?

I wouldn't say that I know within 10 minutes.

It takes maybe 10 hours and I would need to look at some documentation for the project.

But sometimes when I walk into a project that's already gone wrong, actually that's most often the case because people tend to call you in or call me in when things have gone wrong instead of doing what makes sense to do it before things go wrong.

So you get it right from the start, which is not all that difficult if you think about it.

But one telltale sign is that risk has not been taken into account, like we just talked about.

People have on the project have actually not made a realistic assessment of risk.

You and I both know if we go to Las Vegas and we are going to the casino to play poker and we hope to make some money, we better know the odds of the game, right?

Any professional poker player will tell you, if you don't know the odds of the game, including the individual hands and so on, don't play because you're going to lose money and not make money.

What are the odds that your budget will hold?

What are the odds that your schedule will hold, etc.

That's probably the most important telltale design and other thing of course is whether you meet competent people and that's fairly quickly if you talk to people and you have experience from this field you would quickly know whether people know what they're doing often the costs of projects don't fall on those who start them can you share some examples

This goes for most tax payer funded projects.

So lots of the infrastructure projects that actually make up the material infrastructure of the societies are funded by people who, by the vast majority, don't get to benefit from the projects.

And that can be a problem, of course, that people don't, if it's not their own money, they don't take it as seriously.

It's called skin in the game.

If you have skin in the game, you're more likely to perform better than if you don't have skin in the game.

So all these projects where there's no skin in the game because nobody has their own money involved, that's a bad sign and a bad setup.

How about the example of the Montreal Olympics?

We found that it's the worst performing Olympics of all the Olympics that we have data for with the Olympics going all the way back to 1960.

So there was a huge cost overrun and the city of Montreal had to incur debts in order to cover this.

So for 30 years they were actually paying off on the Olympics.

So the poor taxpayers in Montreal got settled with the cost of the Olympics.

It's just like this thing that takes place over two weeks at that time.

That's an example where you had a real financial disaster with one Olympic Games that had severe costs for 30 years for all the citizens in Montreal.

Just unimaginable that they were paying it off for 30 years.

Then people tend to think their project is unique, whether it's a new train line, a nuclear cleanup, or a kitchen renovation.

But you believe the uniqueness is a trap.

Can you explain?

And it's not just a belief.

It's actually well documented, research.

Psychologists have long documented something with us as individuals.

So you and me, they call uniqueness bias that we and everybody else tend to think that we are better than we are.

Like if you make a study of drivers, 80% of drivers think they are better than the average driver, which is not possible logically, right?

People think they look better than they do.

People think they are more wealthy than they actually are relative to other people and so on.

That's called uniqueness bias.

You think you're unique.

And I took that concept and translated it into management and decision making and project management and asked the question, do project managers who think their project is unique perform better or worse than other project managers?

And I did this because I'd heard this argument so many times.

You hear it over and over in practice when you talk to people who work on real projects day to day.

They will say, well, as an argument for not being able to doing something or having to do something specific, my project is unique, so I have to do this, or my project is unique, so I cannot do this.

And you hear this all the time.

And I didn't believe that.

But then we went out and did the research and studied 300 teams on 300 projects.

And we asked the project managers, do you think your project is unique?

And they ranked their project on a scale from one to 10.

And very clearly, the results showed that the people who thought their projects were unique, so the more unique they thought their project was, the worse they performed.

so uniqueness and performance are inversely related correlated in the sense that the more unique you think your project is

the worse you perform and that's why we call it a trap because it's a trap for people who think like that they get trapped in a situation where they think they cannot learn from other projects and of course if you think you don't have anything to learn from others you're going to perform badly because there's no lessons for you to draw on right so you have to invent everything for yourself and from yourself inside out on the project.

And that's one of the things that Daniel Kahneman proved that this inside view, as he called it, just results in bad performance.

So that's related.

Uniqueness bias leads to the inside view, which leads to bad performance.

So essentially, don't fall into the trap of thinking your project is unique.

Take a look at other similar projects and learn from them.

Yes, and I actually directly advise project owners and project leaders, if you hear somebody saying about a project they work on, that the project is unique, either get rid of them or retrain them because it's really, these people are dangerous to have on your project.

You also recommend what you call think slow, act fast.

Can you explain with examples?

This is inspired by Daniel Kahneman.

He actually found that fast thinking results in bad decisions and slow thinking results in good decision.

You can only get to X fast if you have first thought slow because you will not know what you're doing unless you've thought it through, you know, so you won't understand your project, what it really is, what the pitfalls are, what you need to do in order to make it succeed unless you've been thinking really slowly about it.

And once you've done that, we find that people who do that and we've studied successful project leaders, they can actually act very fast.

So you can deliver much faster if you've gone through that process.

And one example is Pixar movies.

So Pixar is very deliberate about this, about taking a long time.

They take two years to think about their films before they start shooting them, developing in more and more detail, simulating them by, of course, writing manuscripts, but also doing cards where they illustrate what is going to happen in specific scenes in the movie and so on.

First, just a few, and then in the end, hundreds and even thousands.

Then they film those to get an idea of what is the film going to look like, what is it going to sound like, etc.

All these things are done in a very inexpensive way.

It's just experimentation.

It's trial and error in order to find out what works, which storyline will actually work.

That's what they're aiming for during this process of these two years.

And then once they think they have that, that's when they start shooting.

And then they can actually finish the shooting in a relatively short time and be fairly frugal.

And this Pixar model, what you call think slow, act fast, applies to buildings.

It applies to space exploration, nuclear power plants, home renovations.

It applies to anything.

An example from New York is the Empire State Building.

It's a fantastic story.

And more than 100 years ago, we could build an iconic skyscraper, tallest in the world at the time.

on the budget, 17% on the budget, which is like in today's money, millions and millions on the budget and a few weeks ahead of schedule.

And nobody would say that this is low quality.

It was built in just 14 months because everything was thought through.

They were thinking a lot before, and everything was built in a standardized way.

Like they said, we didn't build a skyscraper with 123 stories.

We just built the same story 103 times.

Everything was pre-produced and just brought on site and assembled.

So it was actually more of an assembly site than a construction site in that sense.

Take, for example, the Sydney Opera House versus the Bilbao Museum in Spain.

Can you compare how those worked?

So one was built 3% under budget.

That's the Bilbao Guggenheim.

One was built 4,400% over budget.

That's the Sydney Opera House.

One was built 10 years later than scheduled.

So I think it took 16 years to build it.

And that was 10 years longer than the schedule said.

The other was built on schedule.

That's the difference.

And the explanation is that Frank Gehry, who was the architect of the Guggenheim Bilbao, actually used things slow and fast.

He simulated the whole museum on his computers.

And he could simulate the building, every detail, every notch, every bolt, every panel, the plumbing, the heating, everything.

And this is the explanation that he could build it on, but because he actually made all the mistakes on the computer.

So if something didn't fit, you know, in the designs, they would discover it on the computer and not on the construction side.

So that's the secret to why the Bilbao went so well.

And in contrast, again, the Sydney Opera House, they started building it before they even knew what they were building.

And later they had to go in and dynamite part of the construction.

So they had poured the concrete because they started too early before they had finalized drawings as opposed to Gary.

And because of that, they made mistakes, of course, which is to be expected.

And because of the mistake, the mistakes actually was stood there in concrete.

Instead of being on the computer, they were out there on the ground.

And they had to use dynamite to blow it all up and start again.

Now, that's expensive.

That's the way you don't want to do a project.

That's the way they did sit in your brows.

What do you recommend for any big project?

I recommend good preparation, including hiring the right people.

So basically, you want a realistic business plan.

So that means realism in your estimates, budgets, schedules, etc.

Second thing you want is a delivery team that is really competent.

And you can only know that they're competent by looking at their track record that they've actually done a project like the one that you are now delivering before.

As a third thing, around those two things, you want an incentive structure that incentivizes the team to deliver so that they actually get rewarded if they deliver what you want them to deliver and they get punished or maybe not directly punished, then at least they won't make the profit that they hope to make if they don't do what you want them to do, right?

Which is to deliver your project successfully.

Ben, how important is project management?

It's incredibly important and it's becoming increasingly important because a larger and larger part of what we do in society is delivered as projects, both in the public sector with governments, but also in private businesses.

So a larger and larger part of businesses are delivered as projects and a larger and larger part of GDP for societies as a whole is delivered as projects.

So that's why it's so important to get it right.

We simply cannot be a successful society and you cannot be a successful corporation if you don't get your project management right.

What are the three takeaways you'd like to leave the audience with today?

One is build with Legos.

So use modularity in what you're doing.

Build big from small.

Second, think from right to left.

This means think about the end point.

What is it that you want to achieve?

And then make sure that everything you do from now until you've achieved it actually aligns with that.

That will keep you on the right path.

And third, know your odds.

Just like in the casino, the odds are based on experience and the same with projects.

So your odds are based on similar projects.

How did they perform historically?

Know what your odds are for staying on budget.

Know what your odds are for delivering the benefits that you actually want to deliver and know what your odds are for staying on schedule.

Bent, thank you.

This has been great.

My pleasure.

Thanks a lot for having me.

I really really appreciate it.

If you're enjoying the podcast, and I really hope you are, please review us on Apple Podcasts or Spotify or wherever you get your podcasts.

It really helps get the word out.

If you're interested, you can also sign up for the Three Takeaways newsletter at 3takeaways.com, where you can also listen to previous episodes.

You can also follow us on LinkedIn, X, Instagram, and Facebook.

I'm Lynn Toman, and this is Three Takeaways.

Thanks for listening.