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

I call this pattern “Think fast, act slow,” for reasons I’ll explain later. It is a hallmark of failed projects.

In a 1931 publication, the corporation boasted that before any work had been done on the construction site “the architects knew exactly how many beams and of what lengths, even how many rivets and bolts would be needed. They knew how many windows Empire State would have, how many blocks of limestone, and of what shapes and sizes, how many tons of aluminum and stainless steel, tons of cement, tons of mortar. Even before it was begun, Empire State was finished entirely—on paper.”[14] The first steam shovel clawed into the Manhattan dirt on March 17, 1930. More than three thousand workers swarmed the site, and construction advanced rapidly, beginning with the steel skeleton thrusting upward, followed by the completed first story. Then the second story. The third. The fourth. Newspapers reported on the skyscraper’s rise as if it were a Yankees playoff run.

I call the pattern followed by the Empire State Building and other successful projects “Think slow, act fast.”

The record of big projects is even worse than it seems. But there is a solution: Speed up by slowing down.

But it was that project that nudged me to start a big project of my own—a database of big projects. It continues to grow. In fact, it is now the world’s largest of its kind.

Cities and towns are complex systems. Markets are complex systems. Energy production and distribution are complex systems. Manufacturing and transportation are complex systems. Debt is a complex system. So are viruses. And climate change. And globalization. On and on the list goes. If your project is ambitious and depends on other people and many parts, it is all but certain that your project is embedded in complex systems.

“For want of a nail, the shoe was lost. For want of a shoe, the horse was lost. For want of a horse, the rider was lost. For want of a rider, the battle was lost. For want of a battle, the kingdom was lost.” This version was published by Benjamin Franklin in 1758, and he introduced it with the warning that “a little neglect may breed great mischief.” The key word is may.

From the dramatic to the mundane to the trivial, change can rattle or ruin a project—if it occurs during the window of time when the project is ongoing. Solution? Close the window. Of course, a project can’t be completed instantly, so we can’t close the window entirely. But we can make the opening radically smaller by speeding up the project and bringing it to a conclusion faster. That is a main means of reducing risk on any project. In sum, keep it short!

To understand the right way to get a project done quickly, it’s useful to think of a project as being divided into two phases. This is a simplification, but it works: first, planning; second, delivery. The terminology varies by industry—in movies, it’s “development and production”; in architecture, “design and construction”—but the basic idea is the same everywhere: Think first, then do.

That is, sadly, typical. On project after project, rushed, superficial planning is followed by a quick start that makes everybody happy because shovels are in the ground. But inevitably, the project crashes into problems that were overlooked or not seriously analyzed and dealt with in planning. People run around trying to fix things. More stuff breaks. There is more running around. I call this the “break-fix cycle.” A project that enters it is like a mammoth stuck in a tar pit.

Purposes and goals are not carefully considered. Alternatives are not explored. Difficulties and risks are not investigated. Solutions are not found. Instead, shallow analysis is followed by quick lock-in to a decision that sweeps aside all the other forms the project could take.

“Lock-in,” as scholars refer to it, is the notion that although there may be alternatives, most people and organizations behave as if they have no choice but to push on, even past the point where they put themselves at more cost or risk than they would have accepted at the start. This is followed by action. And usually, sometime after that, by trouble; for instance, in the guise of the “break-fix cycle” mentioned in chapter 1.

One is what I call “strategic misrepresentation,” the tendency to deliberately and systematically distort or misstate information for strategic purposes.[5] If you want to win a contract or get a project approved, superficial planning is handy because it glosses over major challenges, which keeps the estimated cost and time down, which wins contracts and gets projects approved. But as certain as the law of gravity, challenges ignored during planning will eventually boomerang back as delays and cost overruns during delivery. By then the project will be too far along to turn back. Getting to that point of no return is the real goal of strategic misrepresentation. It is politics, resulting in failure by design.

After debating in print, Kahneman invited me to meet and discuss matters further. I also arranged for him to visit megaproject planners so he could study their experiences firsthand. Eventually each of us came to accept the other’s position: psychology for me and politics for Kahneman.[7] Which factor is most important depends on the character of decisions and projects. In Kahneman’s laboratory experiments, the stakes are low. There is typically no jockeying for position, no competition for scarce resources, no powerful individuals or organizations, no politics of any kind. The closer a project is to that situation, the more individual psychology will dominate, which is what Kahneman, Amos Tversky, and other behavioral scientists have found. But as projects get bigger and decisions more consequential, the influence of money and power grows. Powerful individuals and organizations make the decisions, the number of stakeholders increases, they lobby for their specific interests, and the name of the game is politics. And the balance shifts from psychology to strategic misrepresentation.[8]

We are a deeply optimistic species. That makes us an overconfident species.[9] The large majority of car drivers say that their driving skills are above average.[10] Most small-business owners are confident that their new business will succeed even though most small businesses fail.[11] Smokers believe that they are at less risk of lung cancer than other smokers.[12] There are countless more illustrations like these in the psychological literature.

That’s perfectly reasonable. It is also inapplicable to many decisions on big projects because they are so difficult or expensive to reverse that they are effectively irreversible: You can’t build the Pentagon, then knock it down and build it elsewhere after you discover that it ruins the view. When this bias for action is generalized into the culture of an organization, the reversibility caveat is usually lost. What’s left is a slogan—“Just do it!”—that is seemingly applicable in all situations. “When we surveyed participants in our executive education classes, we found that managers feel more productive executing tasks than planning them,” observed business professors Francesca Gino and Bradley Staats. “Especially when under time pressure, they perceive planning to be wasted effort.”[22] 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] Executives everywhere will recognize that attitude. It 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.

Money, time, and effort previously spent to advance a project are lost in the past. You can’t get them back. They are “sunk.” Logically, when you decide whether to pour more resources into a project, you should consider only whether doing so makes sense now. Sunk costs should not be a factor in your thinking—but they probably will be because most people find it incredibly hard to push them out of their minds. And so people commonly “throw good money after bad,” to use the old phrase.

The process I lay out is anti-Somervell. It finds the flaws and the opportunities. If you feel the urge to commit—and you probably will—commit to completing that process before you draw conclusions about your big project.[39] At first, commit to having an open mind; that is, commit to not committing.

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.

Frank Gehry, arguably the world’s most acclaimed architect, never starts with answers. “I grew up with the Talmud,” he told me when I interviewed him in 2021, “and the Talmud starts with a question.” That’s typical of Judaism, he says. “Jews question everything.”[1]

Frank Gehry’s most celebrated building—the one that elevated him from the ranks of rising stars to the pinnacle of the architecture world—is the Guggenheim Museum Bilbao. A gallery of contemporary art in Bilbao, Spain, it is a spectacular, glowing building unlike anything seen before, as much of an artwork as those on display inside.

Projects are not goals in themselves. Projects are how goals are achieved.

That’s a simple and self-evident idea, but it is easily and commonly forgotten when the WYSIATI fallacy from chapter 2 rushes us to a conclusion that seems so obvious it’s not even worth discussing. If I had asked David and Deborah at the start of their project what their goal was, they likely would have shrugged and said something like “To have a nice kitchen.” That is what people say when they confuse means and ends.

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.

Caro is the greatest living American biographer, famous for long, deeply researched, massively complex books about President Lyndon B. Johnson and Robert Moses, the man who built New York, which take as much as a decade or more to write. He starts all his mammoth projects the same way: He fills in the box on the right. “What is this book about?,” he asks himself. “What is its point?” He forces himself to “boil the book down to three paragraphs, or two, or one.”[16] These paragraphs express the narrative theme with perfect simplicity.

Remove the words custom and bespoke from your vocabulary. They’re a desirable option for Italian tailoring if you can afford it, not for big projects.

When something works, keep it. When it doesn’t, get rid of it. Try, learn, again. And again. And again. Let the plan evolve.

A good plan, as I said, is one that maximizes experience or experimentation; a great plan is one that does both. And the best plan? That’s one that maximizes experience and experimentation—and is drafted and delivered by a project leader and team with phronesis.

But even with all that in hand, you still have to answer some of the toughest questions in any project: How much will it cost? How long will it take? Even superb plans delivered by excellent leaders and teams can be undone if those forecasts are off. And thanks to a ubiquitous bias, they routinely are. Let’s look at that bias—and how to overcome it.

SO YOU THINK YOUR PROJECT IS UNIQUE? Think again. Understanding that your project is “one of those” is key to getting your forecasts right and managing your risks.

On it went. Combined, those factors had created a chain of delays followed by failed efforts to catch up, followed by more delays and more failed efforts. Staff had become demoralized, further dragging down performance. The situation had steadily worsened.

Caro and his wife “watched our savings run out, and we sold our house to keep going, and the money from the sale ran out.”[4] They struggled on somehow. It took Caro seven years to finish his book. But a story that seemed destined to be a tragedy ended in triumph. When The Power Broker: Robert Moses and the Fall of New York was finally published in 1974, it won the Pulitzer Prize and became an improbable bestseller. Not only is the book still in print, it is considered one of the greatest dissections of political power ever written.

Caro introduced himself, and they talked. Inevitably, Caro was asked the question he had learned to dread: “How long have you been working on your book?” Reluctantly, he answered, “Five years.” But the other authors weren’t shocked; far from it. “Oh, that’s not so long,” one said. “I’ve been working on my Washington for nine years.” The other said that his book about Eleanor and Franklin Roosevelt had taken seven years. Caro was ecstatic. “In a couple of sentences, these two men—idols of mine—had wiped away five years of doubt.”[5] Caro’s work was not to blame; his forecast was. So how had Caro convinced himself that a book that would take seven years to write could certainly be done in one? As an investigative reporter, he had been used to taking a week or two to research and write an article, a generous amount of time by newsroom standards. He might spend three weeks writing a particularly long article or series of articles, the word count of which would be roughly equivalent to that of a book chapter. A book may have twelve chapters. So the estimate was easy: 12 × 3 = 36 weeks, or nine months. It was not clear at the start how many chapters the book would have, but even if it went as high as seventeen, the book could still be finished in less than a year. For a newspaper reporter, a year is an almost incomprehensibly long period of time to devote to one piece of writing. It’s small wonder then that Caro was confident.

I started with an obscure phrase found within a paper that Daniel Kahneman and Amos Tversky published in 1979—not the famous 1979 paper on “prospect theory” that won Kahneman the Nobel Prize in Economic Sciences in 2002 but another paper the prolific duo published the same year. 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. Even if the project isn’t something as wildly creative as making a Pixar film, going to Mars, or fighting a pandemic, even if it’s as mundane as remodeling a suburban house or as common as building a small bridge, developing a software program, or hosting a conference, at least some aspects of the project will be unique. Maybe it’s the people who will do the work or how they will do it. Or the location. Or current economic circumstances. Or a unique combination of these factors. There will always be something that makes this project different from all others.

You start the project by tearing out the existing flooring. And you discover mold in the floorboards. Then you tear out drywall. And you discover old wiring that violates the current building code. Later, your prized granite countertops are delivered. You slip while carrying a slab, breaking it in two. Just like that, your estimate goes up in flames. You are on your way to a major cost overrun. Maybe you think I’m being unreasonable with this illustration. After all, each of the nasty surprises I imagined is unlikely. That is true. But even with a project as simple as a kitchen renovation, the number of possible surprises, each unlikely, is long. Many small probabilities added together equal a large probability that at least some of those nasty surprises will actually come to pass. Your forecast did not account for that. That means your forecast, which seemed perfectly reasonable and reliable, was actually a highly unrealistic things-will-go-according-to-plan best-case scenario, like the best-case scenarios I described in chapter 2. And things almost never go according to plan. On big projects, they don’t even come close.

If you’re a professional at a large organization, you should do better than this rough-and-ready approach. You need to get serious about gathering enough data to allow you to statistically analyze the distribution and determine if it’s normal or fat-tailed. If it’s normal or near normal, do a reference-class forecast using the mean. This would still give you an approximately 50 percent risk of a small cost overrun. If you want to reduce this risk further, add a 10 to 15 percent contingency (reserve), and you’re done.[24]

BLACK SWAN MANAGEMENT Some tails are simple to cut. Tsunamis are fat-tailed, but if you build well inland or erect a high enough seawall, you eliminate the threat. Earthquakes are also fat-tailed, but build to an earthquake-proof standard, as we did with the schools in Nepal, and you are covered. Other tails require a combination of measures; for a pandemic, for instance, a blend of masks, tests, vaccines, quarantines, and lockdowns to prevent infections from running wild.[25] That’s black swan management.

The critical next step is to stop thinking of black swans the way most people do. They are not bolt-from-the-blue freak accidents that are impossible to understand or prevent. They can be studied. And mitigated.

In October 2014, before a crowd of thirty thousand people, including the mayor and the governor, Lasko held up a walkie-talkie and gave the order to light the fire. Nothing happened. He waited. Still nothing. The ignition system had failed. There was no backup and no contingency plan. All the effort had gone into mitigating the risk of the fire spreading, not the risk of the fire not igniting in the first place. A politician later called the festival “the fiasco on the river,” and the name stuck. The event became a punch line. The theater company ultimately folded, and Lasko lost his job.[29]

What went wrong? Lasko and his team spent ages thinking about risk, but they never shifted their perspective from thinking of the Great Chicago Fire Festival as a unique project to seeing it as “one of those”; that is, part of a wider class of projects. If they had, they would have spent time thinking about live events. How do they fail? One common way is equipment failure. Mics don’t work. Computers crash. How is that risk mitigated? Simple: Identify essential equipment, get backups, and make contingency plans. That kind of analysis is dead easy—but only after you have shifted to the outside view.

But if a project is falling behind, managers don’t want to wait until the next milestone arrives before they are alerted to the delay. They need to know and act as quickly as possible. Our data were so detailed that we could make a further set of subforecasts, so we invented “inchstones.” And we specified in detail beforehand who would be responsible for what. If MTR started falling behind under the new schedule, managers would know immediately, and they would know who must act, so no time would be wasted. With the Hong Kong government, we developed the inchstone approach into a general methodology based on artificial intelligence, which today is used on other Hong Kong projects and can be used on any project anywhere.[32]

Four years later, early on the morning of September 22, 2018, Hong Kong’s spectacular new underground railway station with its dramatically curved rooftop green spaces welcomed the first travelers. At precisely 7:00 a.m., the first bullet train slipped quietly into a tunnel and raced to mainland China. The project had been concluded on budget and three months ahead of schedule—the budget and schedule created by using the right anchor.

A SINGLE, DETERMINED ORGANISM As important as it is to do the slow thinking that produces excellent planning and forecasting, acting fast in delivery takes more than a strong plan; you need an equally strong team. How are diverse people and organizations with different identities and interests turned into a single “us”—a team—with everyone rowing in the same direction: toward delivery?

I know a highly sought-after manager of multibillion-dollar IT projects. He’s the sort of person who is brought in when everything is going wrong and executives know their careers are on the line, which happens all too often with IT projects. His condition for tackling any project? That he can bring his own team. That’s how he gets the team right. They are a tried and tested delivery force, which makes them worth every penny of the many dollars spent to hire them.

Examine any successful project, and you’re likely to find a team like that. Frank Gehry’s many successes—on time, on budget, with the vision the client wants—have depended not only on Gehry but also on the superb people who have worked with him for years; in some cases, decades. The Empire State Building had excellent planning, as we have seen, but it also had a construction firm renowned for putting up skyscrapers fast.

Because executives with experience were difficult to find. How hard can it be to deliver a big project?, the owners pondered. The oil and gas industry delivers big projects. A hydroelectric dam is a big project. Ergo, executives from oil and gas companies should be able to deliver a dam. Or so the owners reasoned—and hired oil and gas executives to build the dam. The reader will not be surprised to learn that in sharp contrast to the Hoover Dam, this project turned into a fiasco that threatened the economy of a whole province. That was when I was brought in to diagnose the problem—too late.[2]

One way to design and deliver a project on an enormous scale is to build one thing. One huge thing. Monju is one huge thing. Most nuclear power plants are. So are giant hydroelectric dams, high-speed rail lines such as that in California, and mammoth IT projects and skyscrapers. If you build like this, you build only one thing. By definition, that thing is one of a kind. To put that in the language of tailors, it is bespoke: no standard parts, no commercial off-the-shelf products, no simple repetition of what was done last time. And that translates into slow and complex. Nuclear power plants, for one, are the products of a staggering number of bespoke parts and systems that must all work, and work together, for the plant as a whole to work. Complex bespokeness alone makes huge projects hard to deliver if done in this manner. But that is compounded by several more factors. First, you can’t build a nuclear power plant quickly, run it for a while, see what works and what doesn’t, then change the design to incorporate the lessons learned. It’s too expensive and dangerous. That means that experimentation—one-half of the experiri I discussed in chapter 4—is out. You have no choice but to get it right the first time.

Exact same thing applies to software IT projects as to the bespoke(unique) software

Second, there’s a problem with experience—the other half of experiri. If you are building a nuclear power plant, chances are that you haven’t done much of that before for the simple reason that few have been built and each takes many years to complete, so opportunities to develop experience are scarce. Yet with no experimentation and little experience, you still have to get it exactly right the first time. That’s difficult, if not impossible.

Even if you do have some experience building nuclear power plants, you probably won’t have experience building this particular nuclear plant because, with few exceptions, each plant is specifically designed for a specific site, with technology that changes over time. Like Monju, it is bespoke, one of a kind. Anything bespoke is expensive and slow to make, like a tailored suit. But imagine a tailor who has little experience with suits making a bespoke suit for you and having to get it right on the fi...