How Big Things Get Done: The Surprising Factors That Determine the Fate of Every Project, from Home Renovations to Space Exploration and Everything In Between

by Bent Flyvbjerg

To put that in more general behavioral terms, people in power, which includes executives deciding about big projects, prefer to go with the quick flow of availability bias, as opposed to the slow effort of planning.[23]

isn’t the bias for action promoted by Jeff Bezos; it’s a bias against thinking.

Planning is working on the project. Progress in planning is progress on the project, often the most cost-effective progress you can achieve. We lose sight of these facts at our peril. Let’s see why.

In the world of civic projects, the first budget is really just a down payment.

If people knew the real cost from the start, nothing would ever be approved”

Final Cut: Art, Money, and Ego in the Making of Heaven’s Gate, the Film That Sank United Artists, which is one of the most detailed and startling looks at a Hollywood production ever written.[31]

Consider two friends with tickets for a professional basketball game a long drive from where they live. On the day of the game, there is a big snowstorm. The higher the price the friends paid for the tickets—their sunk costs—the more likely they are to brave the blizzard and attempt driving to the game, investing more time, money, and risk. In contrast, the rational approach would be to disregard what they have already invested and stay home. The sunk-cost fallacy applies to individuals, groups, and whole organizations.

We should be careful not to see psychology and politics as separate forces; they can be mutually reinforcing and typically are in big projects.[37] When they align in favor of a superficial plan and a quick start, that’s probably what will occur—with predictable consequences.

In contrast, good planning explores, imagines, analyzes, tests, and iterates. That takes time. Thus, slow is a consequence of doing planning right, not a cause. The cause of good planning is the range and depth of the questions it asks and the imagination and the rigor

of the answers it delivers. Notice that I put “questions” before “answers.” It’s self-evident that questions come before answers. Or rather, it should be self-evident. Unfortunately, it’s not. Projects routinely start with answers, not questions.

In contrast, Gehry assumes that there must be more to learn. By making that assumption, he avoids the trap of the fallacy. In this frame of mind, the first thing Gehry does when he meets with potential clients is engage in long conversations. This isn’t chitchat or Gehry being personable, and it doesn’t involve his delivering lectures about architectural theory or dwelling on the visions bubbling in his imagination.

Instead, he asks questions. With no motive but curiosity, he explores the client’s needs, aspirations, fears, and everything else that has brought them to his door. The whole conversation starts with a simple question: “Why are you doing this project?”

Few projects start this way. ...

The officials told Gehry that they wanted a building that could do for Bilbao and the Basque Country what the Sydney Opera House had done for Sydney and Australia: put them on the map and bring back growth.

Projects are not goals in themselves. Projects are how goals are achieved. People don’t build skyscrapers, hold conferences, develop products, or write books for their own sakes. They do these things in order to accomplish other things.

That’s a simple and self-evident idea, but it is easily and commonly forgotten

At the beginning of a project, we need to disrupt the psychology-driven dash to a premature conclusion by disentangling means and ends and thinking carefully about what exactly we want to accomplish.

Developing a clear, informed understanding of what the goal is and why—and never losing sight of it from beginning to end—is the foundation of a successful project.

Many people consider the Sydney Opera House and the Guggenheim Museum Bilbao the greatest buildings of the past century. I agree.

What sets good planning apart from the rest is something completely different. It is captured by a Latin verb, experiri. Experiri means “to try,” “to test,” or “to prove.” It is the origin of two wonderful words in English: experiment and experience.

As the old Latin saying goes, “Repetitio est mater studiorum”—“Repetition is the mother of learning.”

starts with time. Pixar gives its directors months to explore ideas and develop a concept for a movie.

A Pixar movie usually goes through the cycle from script to audience feedback eight times.

The amount of change between versions one and two “is usually huge,” said Docter. “Two to three is pretty big. And then, hopefully, as time goes on, there are enough elements that work that the changes become smaller and smaller.”

First, iteration frees people to experiment, as Edison did with such success. “I need the freedom to just try a bunch of crap out. And a lot of times it doesn’t work,” Docter

“If I knew I have to do this only once and get it right, I’d probably hew to the things that I know work.” And for a studio built on creativity,

Such failure is so common in Silicon Valley that there is even a name for it. “Vaporware” is software that is publicly touted but never released because developers can’t figure out how to make the hype real.

Vaporware typically isn’t fraud, or at least it doesn’t start that way, as there is

often honest optimism at work and every intention of delivering. But past a certain p...

Third, an iterative process such as Pixar’s corrects for a basic cognitive bias that psychologists call the “illusion of explanatory depth.”

“People feel they understand complex phenomena with far greater precision, coherence, and depth than they really do,”

When people try and fail to explain what they mistakenly think they understand, the illusion dissolves.

That cost difference is important for the simple reason that in a big project problems are inevitable. The only question is, When will they arise? An iterative process greatly increases the probability that the answer to that question is “in planning.” That can make all the difference.

This simple distinction applies in most fields: Whatever can be done in planning should be, and planning should be slow and rigorously iterative, based on experiri.

to release a product quickly, even if it is far from perfect, then continue developing the product in response to consumer feedback. This is the “lean startup” model

made famous by the entrepreneur Eric Ries in his 2011 book of the same name.[25] It sounds an awful lot like the rush to get projects under way before they have been slowly and carefully planned—the very thing I have condemned as a key cause of project failure from the first page of this book.

Planning, as I see it, is not merely sitting and thinking, much less a rule-based bureaucratic exercise of programming. It is an active process. Planning is doing: Try something, see if it works, and try something else in light of what you’ve learned. Planning is iteration and learning before you deliver at full scale, with careful, demanding, extensive testing producing a plan that increases the odds of the delivery going smoothly and swiftly.

“We must learn what customers really want,” he advised, “not what they say they want or what we think they should want.” The only way to do that is to “experiment.” Create a “minimum viable product,” put it in

front of consumers, and see what happens. With lessons learned, change the product, ship again, and repeat the cycle.

The “minimum viable product” model comes close to the impossible ideal by doing enough testing to bring the product up to the “minimum viable” standard before releasing it into the real world to get that valuable feedback. But it can be done with only a limited range of projects.

because they commonly suffer yet another behavioral bias, “uniqueness bias,” which means they tend to see their projects as unique, one-off ventures that have little or nothing to learn from earlier projects.[5] And so they commonly don’t.

that we too often think that only people can be experienced, not things, and that therefore using new technology is not like hiring an inexperienced carpenter. That’s a mistake—because it is.

As brutal as the experience was, the process of building the Disney Concert Hall taught Gehry a host of lessons that he used in building the Guggenheim Bilbao and has used in projects ever since. Who has power, and who doesn’t? What are the interests and agendas at work? How can you bring on board those you need and keep them there? How do you maintain control of your design? These questions are as important as aesthetics and engineering to the success of a project. And the answers can’t be learned in a classroom or read in a textbook because they are not simple facts that can be put fully into words. They need to be learned as you learn to ride a bike: try, fail, try again.

When planning, remember the Latin word experiri, the origin of the English words experiment and experience. Whenever possible, planning should maximize experience, both frozen and unfrozen.

Testing is all the more critical for those very rare big projects—such as finding solutions to the climate crisis, getting people to Mars, or permanently storing nuclear waste—that must do what has never been done before because that is the heart of the project. They start with a deep deficit of experience. To deliver their vision, on time and budget, that deficit must be turned into a surplus with the relentless application of experiri.

When delivery fails, efforts to figure out why tend to focus exclusively on delivery. That’s understandable, but it’s a mistake, because the root cause of why delivery fails often lies outside delivery, in forecasting, years before delivery was even begun.

If those forecasts were fundamentally unrealistic, a team expected to meet them would fail no matter what they did. The delivery would be doomed before it started. That should be obvious. But when things go wrong and people get desperate, the obvious is often overlooked, and it’s assumed that if delivery fails, the problem must lie with delivery, when in fact it lies with forecasting.

The mistake the planners made is as basic as it is common: When we experience delays and cost overruns, we naturally go looking for things that are slowing the project down and driving up costs. But those delays and overruns are measured against benchmarks. Are the benchmarks reasonable? Logically, that should be the first question that is asked, but it rarely comes up at all. Once we frame the problem as one of time and money overruns, it may never occur to us to consider that the real source of the problem is not overruns at all; it is underestimation. This project was doomed by a large underestimate. And the underestimate was caused by a bad anchor.

To create a successful project estimate, you must get the anchor right.

The phrase is “reference class.”[8] To understand what a reference class is, bear in mind that there are two fundamentally different ways to look at a project. The first is to see it as its own special undertaking. All projects are special to some degree.