How Big Things Get Done – Book review

The book was a strong recommendation from a colleague and is rated as “probably the most important management book of the decade”.

  All in all, when thinking about and writing this review, the book contained more interesting and relevant points to me than I had thought after the “first go”.

Also, the second half of the book was more interesting to me than the first 3 or 4 chapters. Many examples in the book are highly infrastructure- and construction focussed, though the research and findings refer to a broad range of project classes – including software. The “planning is active!” imperative of the book makes it compatible to iterative, agile working.

  At many points, the book describes practices that have been central to “good Lean” for decades. Especially the way companies like Toyota with their TPD – Toyota Product Development approach develop and deliver new products and models.

The  book does not mention Lean at any point, but you can see that some of the project sponsors come from a Lean background. And others probably don’t, but found important practices that you can also find in good Lean management and thinking.

On the plus side, I did take away several guidelines and insights on project failure or raising the success of projects significantly that were new to me, or at least in this form. Jump 3 paragraphs down to the bullets below to see the summary of my take-aways, and to the bottom of the post for the “11 heuristics for project success” from the book.

 Primarily, I listened to the full audio version, but also looked through the written book plus the PDF material from the audio book.

… As is always the risk with audio books, it may be that the narrator lessened my impression of the books’ contents. I did not like the audio narrator much, and felt I did not like the style of the book very much either. At some points the book appeared somewhat arrogant to me, and although I am all for concrete examples and stories, with some I could have done with a shorter description. After all, it’s not a novel.

Take aways & summarization:

  • The Empire State Building 1931 was a positive example: planned in detail and then executed very fast – under time, under budget
    • The architect had already had great experience with a very similar, smaller skyscraper before, and they hired skyscraper-experienced contractors. The building- and floor-design was very modular, allowing rapid learning
    • (vs. e. g. Sidney Opera Hall – massive fiasko, badly planned)
  • Most types of big projects have a fat tailed distribution – that means that if they go wrong, they tend to go wrong very much
    • This has not been researched much before, is not emphasized in much of project management literature but has massive impact on project failure
  • Our fast estimates usually are best case guesses – extremely unlikely
  • Lots of biases: psychology plus power/politics screw our assumptions and planning. Read Kahnemann (and Tversky) etc.
  • Our “fast system” acts as if the first halfway plausible solution were the only (and best) solution
  • So: “make haste slowly” or “think slow, then act fast
  • Planning is comparatively cheap, but the longer execution takes, the more vulnerable the project gets to changes in the environment (markets etc. ) – means: the plan must then enable fast execution
  • Quick decisions are (only!) smart when the decisions and consequences are reversible, not “fatal” or a lock-in
  • Black Swans: with project duration, any one unexpected event happening becomes more and more likely 
  • “Black Swan management” – Black Swan events of other projects of this type can be studied and plans developed to “cut off the tail”
  • Planning is doing (not a boring, passive, written-only, low-value activity): experimenting and learning, iterating (and again, and again, and again, and …)
  • Experience + Experimentation!
  • When the type of project allows for iteration and MVPs, do it!
  • If it doesn’t, then go for a Maximum Virtual Product (buildings, infrastructure,  … often a very detailed digital twin.
  • Often: start low-tech and cheap first, with a script and improve on it iteratively many times, or with mock-ups, cardboard etc. 
  • Get a thoroughly tested plan!

  • Ask Why – what are the driving motivations,  the goals of the proponents (politics!)?
    What is supposed to be the end result? (“think from right to left”)
    • Examples in the book: “Pixar Planning” and Amazon’s “start with an FAQ and a Press Release Statement” (as if the project were already finished) – then work backwards from there. The FAQ and PR are thoroughly challenged and often changed several times (iteratively).

  • Go for people with experience and proven technology as much as you can!
    • The book makes a strong case for experience in the subject field – including the project  managers! (A “Master Builder” – being very much like Toyota’s Shusa/Chief Engineer system … being the role model for J. Sutherland on how he wants a (Chief) PO to be in Scrum)
    • Flyvbjerg refers to Aristotle’s concept of phronesis practical wisdom that allows us to see what is good for people and make it happen (get it done), which Aristotle saw as the highest virtue. “for the possession of the single virtue of phronesis will carry with it the possession of them all [i.e., all the relevant virtues]”
    • Aristotle said that experience is the “fruit of years” and the source of phronesis.
    • It requires more than explicit knowledge; it requires tacit knowledge that can be gained only through long experience (and cannot be fully made explicit and explained with words – like riding a bike) —a view supported by Michael Polanyi and a great deal of psychological research in recent years.
    • Therefore, a project leader with abundant phronesis is the single greatest asset a project can have.

Get a real team! People who really work well together – often people who are a stable team already for a long time (= experience)

  • RCF – Reference Class Forecast is interesting!
    • What is the kind or class of projects this project falls in? What is their average cost, length etc.? (“Ah – it’s one of those projects”-thinking) 
    • Not only for the whole project, but also for parts of the project
    • Example in the book: the Hong Kong High Speed Underground Rail project, where they introduced “Inchstones” – small forecasts below the milestone level “powered” by RCF estimates and Flyvbjergs database
  • Don’t fall for low anchor/best case fallacy in estimation

  • Modularize your project whereever you can
    • “What is your building block”? (“Your Lego’)
    • One positive example: building thousands of earthquake-proof schools in Nepal
    • Several more examples, like subway built in Madrid at low cost
    • Or the Cupertino Apple headquarter, the Tesla factories and others
    • And the few non-fat tailed project types: small scale hydro power, and especially wind power and solar power, being very modular and overtaking “big energy” fast in terms of cost

  • A key in construction is to go away from creating the parts at the construction site and going for a “Design for manufacturing and assembly” approach instead, where the parts are built in factories, under efficient conditions
  • Another example of very good planning and execution: London Heathrow Terminal 5 (“T5”, vs. new-building of Wimbledon-Stadium) – especially important was the thorough team-building, plus the contract-incentives to work together, experienced contractors and unusual well-treatment of the construction crews
    • Heathrow T5 used the manufacturing and assemble approach a lot.
      The CEO of the private airport ownership company was a former Jaguar CEO, who brought the manufacturing approach from the automotive sector to construction (well, the book doesn’t talk about LEAN, but …)
    • Already the construction of the Empire State Building had been called a “vertical assembly line” with many prefabricated parts
  • Fiasko example: The Japanese Mandru “Fast breeder” reactor project, started in 1985 and “buried” unfinished with about $ 15 Billion cost in 2016 …
  • Flyvbjerg and Gardner end the book with exemplifying how the researched success factors for better planning and execution of projects could provide much more than enough financial resources to realize the extremely many necessary projects to counter climate change and speed them up.
  • As a positive example, they name the transformation of Oersted (formerly DONG Energy), going from 85 % fossile energy production to more than 85 % renewables. The plan had been to reach this – then impossible seeming – goal until 2039, starting in 2009 – but experience and prices developed so quickly that it was reached already in 2019 – in 10 years, not 30. The cost of wind power had reduced by 60 % in just 4 years.
  • Jutland being a very small area in the small country of Denmark, but it developed into a leading agglomeration of wind-power related companies – from turbines to control software companies. 

  • To me, the findings in the book again make very sensible why e.g. Toyota spends so much time planning and uses rigorous A3 thinking, visual PDCA problem solving, Set Based Design (SBD), catchball communication etc. – it counteracts all the bad failure-mechanisms prevalent in most projects. 

  • Success rates of 16000 projects in 20 fields (Flyvbjergs database):
Source: How Big Things Get Done
Fat-tailed and thin-tailed project classes – Source: How Big Things Get Done

Mitigating risk:

  • If your project’s probability distribution is 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.
  • (Most project categories are fat-tailed, though!)
  • If you face a fat-tailed distribution, shift your mindset from forecasting a single outcome (“The project will cost X”) to forecasting risk (“The project is X percent likely to cost more than Y”), using the full range of the distribution.
  • In a typical fat-tailed distribution in project management, about 80 percent of the outcomes will make up the body of the distribution.
  • That’s pretty normal; nothing really scary there. For that portion of the distribution, you can protect yourself the usual way with affordable contingencies that will fit into a budget. But the tail outcomes—the “black swans”—cover about 20 percent of the distribution. That means a 20 percent chance of ending up in the tail, which is too much risk for most organizations.
  • So what can you do about the tail? Cut it off.
  • You can do that with risk mitigation. Flyvbjerg calls it “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 the authors 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.

That’s black swan management.

For big projects, black swan management typically requires a combination of measures. The book started with one: “Think slow, act fast.” We saw that delivery is when things can go horribly and expensively wrong. Exhaustive planning that enables swift delivery, narrowing the time window that black swans can crash through, is an effective means of mitigating this risk.

  • Black Swans can be studied and mitigated!
  • Analyze why other projects of this kind blew up – what where the reasons?
  • Mostly you’ll find that it were standard risks that every project has on it’s risk register
  • “We identified roughly a dozen of those and found that projects were undone by the compound effects of these on a project already under stress. We found that projects seldom nosedive for a single reason.”
  • Interestingly, early delays are not seen as a big deal by most project leaders.
  • They figure they have time to catch up, precisely because the delays happen early. That sounds reasonable. But it’s dead wrong. Early delays cause chain reactions throughout the delivery process. The later a delay comes, the less remaining work there is and the less the risk and impact of a chain reaction.
  • So they advise measures that would cut the probability of early delays and chain reactions

  • Modularization may be the most effective way to reduce risk and “cut the tail” (and is faster, and cheaper!)
  • “many small things” are a lot better than “one huge thing”
  • Modular technology scales. Big, complex one-chance technology does not:
Source: How Big Things Get Done

Link to the book (2023) on Google books: How Big Things Get Done


Advice: don’t use these heuristics thoughtlessly

  1. Hire a Master Builder
    • this person has the phronesis (practical experience) to make the project happen! (Plan, hier an experienced team, make validly anchored estimates, ask the right questions etc.)
  2. Get your team right
    • “Give a good idea to a mediocre team, and they will screw it up. Give a mediocre idea to a great team, and they will either fix it or come up with something better. Picking this team is the Master Builder’s most important job.
  3. Ask Why
    • Do your current actions effectively contribute to the ultimate result (the “right side” – never lose sight of the “true north”)?
  4. Build with “Lego” – Modular
    • Big is best built from small (building blocks)
  5. Think slow, act fast
    • almost any nightmare can and has happend during delivery. Limit your exposure to this. Create a detailed, tested plan (or work very iteratively, depending on the type of project?) 
  6. Take the outside view
    • Really never-been-done kinds of project are highest risk. Most projects belong to a reference class of projects. Gather data, learn from their experience and study the risks and counter measures of “those projects”
  7. Watch your downside
    • Risks can kill your project. For fat-tailed risk (most types of project), forget forecasting risk – go directly to spotting and eliminating dangers
  8. Say no and walk away
    • Say no to projects with insufficient resources, untested technology, uniqueness bias and anything that does not contribute to the ultimate goal! “I’m actually as proud of the things we haven’t done as the things we have done” (Steve Jobs)
  9. Make friends and keep them friendly
    • When something goes wrong, it’s too late to build relationships. Communicating and building understanding and support of stakeholders is risk management!
  10. Build climate mitigation into your project
    • Nothing is more urgent or important than mitigating the climate crisis – it is the main motivation of Flyvbjerg to write the book and provide ways to scale and improve projects!
  11. Know that your biggest risk is you
    • the biggest risk are our own behaviours and biases

If you liked this post, rate and like it! Leave a comment or follow my blog.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.