Book notes: How Big Things Get Done by Bent Flyvbjerg and Dan Gardner

Bent Flyvbjerg   is an economics professor at IT University of Copenhagen. He maintains a database of megaprojects (power plants, opera halls, tunnels, airports) and their planned and realized timelines and budgets. He researches the reasons why modern megaprojects often fail to deliver on time and on budget. It has recently become quite popular to discuss   the apparent decrease in speed with which large-scale projects are realized. Examples are easy to find, e.g. the delayed High Speed Rail 2 (HS2)   project or the time and cost overruns of the Berlin Brandenburg Airport (BER)   . Counter-examples are less common (or less newsworthy), e.g. the 2023 Notre-Dame Reconstruction.

In their book Flyvbjerg/Gardner explain the common reasons for cost and time overruns of megaprojects and how to mitigate them. I think we can apply the majority of their learnings for smaller home (kitchen renovation) and work projects (cloud migration) as well.

Planning is cheap, building is expensive

In large construction projects, planning is a lot cheaper than building. Once a badly planned project is underway, unforeseen problems will be discovered. Delays tend to cause further delays. The total project time can be in itself a source of additional risk and cost.

When politicians plan prestigious infrastructure projects, they have a bias for strategic misrepresentation of the cost and time to get support for it. Therefore, the government and the public need to scrutinize the project’s goal and its planning to ensure that the plan is realistic and enough alternatives have been considered. Only get involved in such a project if it has the people and funds, including contingencies, to succeed.

Since planning is a lot cheaper than building for large projects, Flyvbjerg/Gardner advise investing significant time into the planning phase:

• understand the objective behind the proposed project (assume an outside view)
• explore alternatives and don’t commit to the first available solution (resist quick action bias)
• don’t forecast using the best-case scenario, instead use similar past projects to anchor your estimate
• experiment and iterate in the planning phase using digital modelling and simulations

Understand the why

The project is not a goal in itself, it is how the goal is achieved. We want to talk to the stakeholder to understand the goal. Is the project even the right approach? Good planning needs to explore the problem before jumping to the solution. This includes considering alternatives.

There is a good example in the book about a bridge project. The original goal of the project is to connect an island with the mainland. By jumping to the bridge idea, the stakeholders ignored alternatives, e.g. a tunnel, ferries, a helipad. Or maybe a physical connection is not required. If it’s about improved communication, maybe a high-speed broadband connection achieves the goal.

Another framing of this idea in product development is to work backwards from the customer. Understand their needs and problems, before coming up with any solution.

Reduce uncertainty via experimentation

A crucial part of the planning phase is to experiment with the solution. Ideally, we can simulate and iterate on the project, e.g. use 3D models of the building, low fidelity designs to show customers, or low effort versions of the animation movie we are trying to produce.

The simulation ensures that the majority of aspects of our project are scrutinized before the building phase begins. We can assume that the project will run into problems, so we want most of the problems to occur during the cheap planning phase.

Experience in people and technology

To maximize the chance of a successful project we should maximize experience. Flyvbjerg/Gardner consider both experience in key people and in technology. We should try to ensure that key people have experience in similar projects. Ask: “Have they done it before?”.

“Technology is ‘frozen experience’.”

All things being equal, we should use tried and tested off-the-shelf technology instead of shiny new technology. If we can, we should use existing designs and operational processes.This is the same idea behind McKinkley’s advice to Choose Boring Technology   .

The construction of the Empire State Building is used throughout the book as a positive example. One reason for this was the architect William Lamb who insisted to only use proven technology, and who created a design that allowed repeatable non-custom work steps. Moreover, the construction company Starrett Brothers and Eken had built several similar skyscrapers on time and budget before.

Reference-class forecasting

After the project is planned we need to forecast the project duration and its cost. Unfortunately, planners often forecast too optimistic. Instead of deriving it from the project alone, the authors suggest to use reference-class forecasting. The idea is to find a set of comparable projects, and to anchor our forecast based on their outcomes. Then adjust from that anchor.

However, good forecasting can not protect the project from fat-tailed risks. Since those risks can kill our project, we need to identify the (known) high risk events and try to mitigate them.

“Successful project leaders focus every day on not losing, while keeping a keen eye on the […] goal they are trying to achieve.”

After the planning is done, build quickly

The project duration is in itself is a source of budget and time risk. After planning, simulating, and forecasting, we therefore need to act fast once the building phase starts. To do this we should ideally use an experience team and a modular building pattern.

Build with an experienced team

If possible, hire, what the authors call, a masterbuilder. That is someone who has experience in similar projects and can pick the right team. If such a team doesn’t exist, you or them need to create it.

Moreover, we need to ensure that the incentives of participating contractors are aligned with ours by sharing risks and rewards, e.g. pay a bonus for early completion. Don’t always pick the contractor that submits the lowest bid, because the lowest bid doesn’t necessarily lead to the lowest cost. Moreover, we will try to choose companies that we have successfully collaborated with before.

What’s our Lego?

Nuclear power plant constructions belong to the class of projects that most likely exceed cost and time budgets. Flyvbjerg/Gardner argue that you are building one large thing that has few repeatable, standardized parts. Solar power plants are the opposite. The core ingredient, the solar modules, can be produced rapidly and repeatedly in factories, and then assembled in a modular fashion.

When possible we should try to build modules. We can then produce and assemble the modules in a repeatable process. This delivers value in stages. After we have completed a module, we can use the learnings to iterate on the module’s design and assembly process. So we should always ask ourselves:

“What’s our basic building block, the thing we will repeatedbly make, becoming smarter and better each time. What’s our Lego?”

Additional thoughts about the book

Incentives and identity

There is a section in the book that discusses why the Heathrow Terminal 5 project was completed on time. The authors argue that a large part was the alignment of incentives between the project managers, the contractors, and the workers. Contractors were aligned via contractual bonuses and established working relationship. Workers were treated well, their feedback was actively encouraged, and they felt like they are contributing to a historic project in their country. Not part of the book, but the Notre-Dame reconstruction after the fire, was also accomplished on time. I believe that the history of the building, and the feeling of being part of a national project are very powerful motivators that aligned the participants of the project.

Cost overruns by project type

I found the table in the book that shows the mean cost overrun by category interesting.

The table shows the mean (base rate) cost overrun for each project type. The fat-ness of the distribution (% projects in the upper tail), and the (base rate) cost overrun for projects in the upper tail.

It makes sense that (non-standard, non-modular) nuclear projects have the highest base rate for cost increase. On the opposite side are wind energy and solar power projects, that can be pre-produced in factories and assembled on-site. Organizing Olympic Games suffers from the fact that they are highly complex, and usually held in a city that hasn’t hosted them before (inexperience). As a tech worker, I am intrigued to see IT projects at the top of the list. Moreover, when IT projects overrun they incur a 447% cost overrun, the highest among all project type.

Learnings for software projects

How applicable is the advice for day-to-day data and software projects? I think much of the advice applies. I found that chunking larger projects into small value-delivering modules is a great way to ensure continuous progress (especially in large refactoring projects).

The emphasis on planning vs. building is probably not as relevant in normal day-to-day software projects. There is less of a cost difference between planning and building a feature (in both cases mostly the software engineers’ time) compared to construction projects.