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

Important to understanding this book is knowing the (main) author’s background. Bent Flyvbjerg is a Danish expert on large projects. Mostly infrastructure projects, but also large IT projects. He particularly specializes in examining project failures.

He has a database of thousands of large projects in which he examines how well they were executed and delivered. He’s been maintaining this database for years, and he can tell you exactly what types of projects go well, what types go poorly, and by how much they tend to overrun schedule or budget.

He is the world’s foremost expert on large project failures.

Introduction

This is basic scene-setting. He discusses the two “universal drivers” that cause project failure:

• Psychology: people often make decisions based on ego
• Power: people often make decisions to gain or preserve their power

This is where he first introduces the concept of “think slow, act fast” (discussed below, and throughout the book).

Projects mentioned –

• California high-speed rail, which continues to be a disaster
• The Empire State Building, which was built extremely quickly
• A Danish project to build schools in Nepal
• The Hoover Dam (in passing; very good; see also Colossus: Hoover Dam and the Making of the American Century)
• The invention of the iPod, which went very quickly

Chapter 1: Think Slow, Act Fast

This chapter introduces one of the core ideas in this book: plan meticulously, then move quickly to “close the window” of the project.

He states that any ongoing project is an “open window” into which problems can fly: pandemics, changing economics, etc. So long as the window is open, problems can happen. The window doesn’t open until the project starts. Keep the window open for as short a span as possible (he returns to this idea later when he discusses project modularity).

This reminds me a bit of continuous delivery and agile development practices. Keep your changes small and deploy them often. Most big projects are a collection of smaller projects, and you should seek to deliver the smaller ones fully to production as they are finished.

(Later in the book, again when he talks about modularity, he will return to the problem of “one big thing” projects, where everything has to happen at once for the project to deliver. These, he explains, rarely work well.)

He takes a considerable detour in the middle to talk about the problem of “fat-tailed distributions.” Project failure is a normal distribution, but with very fat tails. The example he gives is that the tallest human in the world is about 1.6x the height of the average human – a very “thin tail” on height distribution.

But project failures have incredibly fat tails: the average overrun on IT projects is 4.5x. So, the stakes for project failures is very high, and trying to pad your project numbers by 2x or 3x is often not enough, but because the degree of failure skews wildly.

The overriding message of this chapter is plan while the stakes are low. When you actually start the project, run like hell. But until then, check, re-check, and check again.

Projects mentioned –

• The tunneling portion of the Danish “Great Belt” project
• HealthCare.gov
• Berlin’s Brandenburg Airport, which finally opened after sitting empty for about a decade
• Switzerland’s Lötschberg Base Tunnel
• The Big Dig
• The James Webb Telescope
• Canada’s firearms registry
• Scotland’s Parliament Building
• A couple of IT projects by Kmart, one of which he claims materially contributed to the company’s bankruptcy filing
• An IT project by Levi Strauss
• A power plant in South Carolina
• Two home renovation projects that he says he’ll return to later
• The Ever Given in the Suez Canal, which was not a project, but an example of small events – a gust of wind – having huge consequences
• The Copenhagen Opera House, which I personally love, but I guess it’s very controversial in some circles
• A 2021 overpass collapse in Mexico City
• California High Speed Rail (again…)

Chapter 2: The Commitment Fallacy

Avoid committing to a plan too quickly. Usually, the goal is to get a plan or a solution approved and underway quickly, so that it cannot be canceled.

This is endemic in public works projects. The book cites former San Francisco mayor Willie Brown when he said that if people knew how much projects were really going to cost, they would never be approved. The only way to get anything underway is through “strategic misrepresentation” where a project is purposely underbid.

The key is that people want to avoid sunk costs. We don’t cancel projects because then the money has been “wasted.” So we waste more and more money to not appear that we have thrown money away.

Flyvbjerg goes back to the prior point about psychology and power. In many cases, projects are considered as some kind of proxy to ourselves and our value as professionals. We don’t like to be second-guessed, because then someone is casting doubt on us personally.

Also, in the current political environment, it’s just not fashionable to say you don’t know. You should always pretend like you have a plan, and should never go slowly to develop one, test one, and – horrors! – reject one and start over.

He makes the point that:

Planning is working on the project. Progress in planning is progress on the project, often the most cost-effective progress you can achieve.

Projects mentioned –

• The building of The Pentagon
• The filming of Heaven’s Gate

Chapter 3: Think from Right to Left

If you conceive of a project’s progression and moving from left-to-right (an Anglo-centric view of reading), then you should really start on the right side. Ask yourself: why do we want to do this project in the first place?

Flyvbjerg says that we get too fixated on how to solve a problem, without first identifying the problem or goal itself. Too often, we start putting building blocks together with some vague idea of what the tower will look like, but not what we want to get out of the tower in the first place.

This goes back to commitment. Too often we think that we need to commit to a plan – commitment equals progress. Flyvbjerg says we need to avoid committing for as long as possible, and we should always assume there’s something we don’t know.

I do struggle with this one a bit, because too often, people want to revisit the goals of a project mid-stream. Once you do commit to a plan, you need to make sure not everything wants to “take a step back” and redefine the right side.

I used to encounter this a lot at a certain company. We’d be progressing through some plan to do something, and inevitably we’d need to bring new people into it, and they’d always say something like, “Can we just take a step back and define the goals of this project?”

…NO!

My analogy for this was if a friend was driving from Los Angeles to New York and stopped to pick you up in Denver. You don’t get to say, “Hey, can we first drive back to Los Angeles so I can make sure you took the right route to get to Denver?”

There’s a point where you just gotta say, “this the plan and we’re moving forward.” But it’s a natural human tendency to want to be involved at the foundational level. Everyone wants to be part of the planning because everyone has some strategic bias – they all want to say they had a hand in the strategy.

Sometimes the strategy is set, and you just need to execute. It’s hard to “think slow, act fast” when everyone wants to go back and reconsider the goals.

Also worth mentioning: the advice to consider the goals only matters if you have a say in it. In many cases, you are presented with a goal, and your only option is to execute against it.

Projects mentioned –

• A disastrous kitchen renovation for a family in Brooklyn
• The Guggenheim Museum in Bilbao, Spain
• The Amazon Fire Phone

Chapter 4: Pixar Planning

It’s so much cheaper to make mistakes when planning, so plan like your life depends on it. Experiment – make mock-ups, prototypes, and digital twins. Be prepared to throw a lot of stuff away, which is a victory.

Flyvbjerg discusses the Latin word experiri, which means “to try, test, or prove.” It’s the source of two words in English: experience and experiment.

Iterate, iterate, iterate. Follow hunches and prosecute ideas to their absolute end (shades of The Tacit Dimension). Assume nothing. Flyvbjerg defines “MVP” as “Maximum Virtual Product.” Stop thinking of planning a bureaucracy. Rather, planning is productive work.

Thomas Edison provides a quote:

I have not failed ten thousand times. I’ve successfully found ten thousand ways that will not work.

Projects mentioned –

• The Sydney Opera House
• The Guggenheim Museum in Bilbao
• The making of the Pixar movie Inside Out, the Pixar method of project devilery are also discussed in Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration.

Chapter 5: Are You Experienced?

Experience is not considered as valuable as it should be. It exists in two quantities:

1. The experience of people
2. Accumulated experience of trial and error embodied in technology

Over and over, we marginalize experience.

For public projects, we hire people to score points with constituents. We hire with an eye to future votes, not because the person or company is best suited for the job. Additionally, we eschew older technology to do something new and amazing – we want to be the “first” or the “biggest”, because that draws attention.

Going first is dangerous

We tend to see our projects as ground-breaking unique little snowflakes, when in reality, someone, somewhere has no-doubt done our project before. We need to find that person or copy that process, or both.

Projects mentioned –

• California High-Speed Rail, yet again
• A Danish project to computerize real estate records
• Seattle’s Route 99 tunnel
• The Olympic Games, which suffer from “Eternal Beginner Syndrome” because they’re always somewhere new, and to get them, a city has to promise to use local resources to prepare, meaning there’s never any experience brought to bear on them
• The Empire State Building, Flyvbjerg framed it as 102 one-story buildings stacked on each other (he talks more about modularity later on)
• The Sydney Opera House, again
• The Walt Disney Concert Hall, which was an example of a bad Frank Geary project in contrast to the Bilbao museum

Chapter 6: So You Think Your Project is Unique?

We estimate projects poorly. Most projects don’t actually exceed a reasonable schedule – the problem is that we’re very bad at estimating what a reasonable schedule should be.

We “anchor” on arbitrary numbers, then adjust up or down based on how we feel the project differs. But we often anchor on the wrong numbers.

We tend to look at our projects from the “inside.” We consider all the work that needs to be done, and estimate based on that. What should really do is what Flyvbjerg called “reference class forecasting.” Every project is part of a “reference class” of projects – kitchen remodels, train station construction, etc. We should look at the actual time other projects like those have taken and modify our estimate based on that. We should estimate from the “outside” of the project.

Lots of companies will resist this, because they need us to commit on poor information. Remember the prior statements that if people knew the real costs of projects, nothing would ever get started. Companies will forecasting from the “inside,” ignoring the actual time that similar projects have taken, because the inside forecast is more palatable.

We also need to manage risk better. We should examine reference class projects and determine what strange risks or problems they ran into, and then proactively “manage away” those risks. Flyvbjerg called this “black swan management,” which means conceding that, in every project, something strange and unpredictable will happen, and we should try and predict those in advance and pre-mitigate them, even at our own expense – the expense of them happening might be low, but might be catastrophic (their impact is “fat-tailed”).

Projects mentioned –

• The Hong Kong high-speed rail system called “XRL”
• Robert Caro’s biography of Robert Moses, The Power Broker
• A project to decommission Swedish nuclear power plants
• A English high-speed rail project called “HS2”
• The 2014 Chicago Fire Festival

Chapter 7: Can Ignorance Be Your Friend?

This chapter is a long argument against survivor bias. Flyvbjerg takes exception to an essay from 1967 by economist Albert Hirschman called “The Principle of the Hiding Hand (PDF).”

In this essay, Hirschman argues that planning is a bad idea and that we should just charge into projects because it sparks our creativity. He provided 11 cases studies that he claimed proved his point.

Hirschman wrote:

…the only way in which we can bring our creative resources fully into play is by misjudging the nature of the task, by presenting it to ourselves as more routine, simple, undemanding of genuine creativity than it will turn out to be… since we are apparently on the trail here of some sort of Invisible or Hidden Hand that beneficially hides difficulties from us, I propose “The Hiding Hand.”

By this point in the book, that quote should utterly horrify you. Flyvbjerg spends an entire chapter basically arguing that Hirschman was wrong.

Flyvbjerg’s point is that Hirschman has cherry-picked stories of legendary seat-of-your-pants projects that ended well. Flyvbjerg has a database of thousands of similar projects that crashed and burned.

Survivor bias says that the history is written by the victors. We hear about the projects that succeeded, and those that succeeded in a way that proves the value of spontaneously human creativity and overcoming of obstacles are stories we just love.

Flyvbjerg writes:

They follow the perfect Hero’s Journey with a narrative arc from great promise to near ruin to an even greater accomplishment and celebration. We seem hardwired to love such stories. We create the in all cultures and times.

So we hear about these stories, not the boring ones that ended up exactly like Flyvbjerg predicts they would. Flyvbjerg constantly argues that stories are not data. His data shows the good and the bad; the interesting and the boring. And the boring failures are the ones that show how things usually go terribly wrong when you don’t plan.

I think a lot of this comes down to whether or not we consider planning to be a creative exercise. I think Hirschman is saying we need to get to it – we need to get to work, because that’s when our creative juices flow.

However, a lot of this could be avoided by embracing what Flyvbjerg has said throughout the book: planning is the work. If you can plan your project in a way that doesn’t involve the risk of an actual living, breathing project, then how is that any less creative than getting to work under the harbinger of massive risk?

I think it’s a perspective shift, mostly. We need to believe that our creative process is the same whether or not the final deliverable is at stake or not.

Projects mentioned –

• The building of Electric Lady Studios, which was embarked on a whim by Jimi Hendricks and is now legendary, but was a nightmare to create because there was little forethought
• The filming of Easy Rider
• The filming of Jaws
• The Sydney Opera House, yet again. This time, Flyvbjerg makes an impassioned case that one of the casualties of that disaster was the rest of Jorn Utzon’s career; we should mourn the other buildings that never got built because the Sydney project destroyed a promising young architect

Chapter 8: A Single, Determined Organism

This chapter is about the delivery, once the project starts. Specifically, it’s about team-building.

One piece of advice is to use known teams. It’s much easier to buy a team than build a team. Find a team that has delivered this type of project before, and re-use them.

Teams thrive on (1) identity and (2) purpose. Team members want to feel like they’re part of something, and that they’re working toward a goal of value.

Teams also thrive of open communication and psychological safety. Solicit opinions from all levels of a team. Avoid decisions that are dictated from “on high.”

The chapter was a bit odd because literally thousands of other books have been written about this. There’s only so much depth Flyvbjerg could go to in the few pages he devoted to it.

In some senses, I think Flyvbjerg was concerned he had over-indexed on planning. He might have felt some need to talk about the actual execution of the project before the end of the book.

One ancillary point he makes here, that I feel like he’s been hinting at the entire point, is that the cost of risk mitigation more than offsets the cost of fat-tailed risks. In this chapter, he says you should buy an experienced team, no matter what the cost. This sets off alarm bells in many heads because that’s a guaranteed cost, meaning we have to pay that. However, we continue to look at “black swan” risks as… possible. They might happen, or they might not. Why guarantee a payment for something that is not guaranteed to happen?

And this gets to the core of the book: bad things happen to big projects (remember the title: how big things get done…). When the “project window” stays open, something is going to fly through it, and we discount and minimize the damage those risks do. Having a large infrastructure project come in late is incredibly expensive – an expense that dwarfs the cost of an premium team that might have prevented the delay.

(He also goes off on an odd tangent about climate change here. It seems weirdly placed in the book, honestly.)

Projects mentioned –

• The T5 Terminal at Heathrow Airport, which is the core example of the chapter; Flyvbjerg uses it as an example of how to build and maintain a team comprised of dozens of contractors all working toward their own ends
• The New Wembley Stadium, as an example of the opposite

Chapter 9: What’s Your Lego?

This chapter is a call to reduce your project to the smallest reprodubile unit of work, and scale that. If you’re building a road, get a single segment of road right, then do that over and over.

Some projects are “one big thing,” meaning that cannot be reduced. Nuclear power is an example of this – nuclear reactors are big things, and they do nothing until they’re complete. Solar and wind power are the opposite – those projects are lots of small things (panels, generators) that can be reproduced over and over.

A lot of projects cannot be reduced. Take this into account when picking a project. If it cannot be reduced, then your risk is much, much higher. You can’t experiment. You can’t adjust. You just have to do the “big thing” and hope for the best.

The goal is to find a project that is “scale free,” meaning it works whether you do one or one million units. These are hard projects to find, but you should always try to drive a project to a style of execution than can take advantage of modularity and repetition.

Projects mentioned –

• The Monju nuclear reactor in Japan
• Sears Modern Homes from the early- to mid-20th century]
• The Apple corporate headquarters
• Giga Nevada
• The Madrid Metro System
• Standardized shipping containers

Coda: Eleven Heuristics for Better Project Leadership

I’ll paraphrase these, and you’ll see that they’re all recitations of what he’s said in earlier chapters. (I combined some, so there’s not eleven below.)

• Hire an experienced project leader and team
• Make sure you know the true reason you’re doing a project
• Concentrate of reusable units of work
• Plan a lot
• Estimate your project by comparing it with others
• Expect risks to happen and pre-mitigate them
• Build relationships that will help when risks happen
• If a project doesn’t seem right, don’t do it