How Big Things Get Done
A book by Bent Flyvbjerg & Dan Gardner
Have you ever wondered how many projects from various fields around the world make it to a happy ending — that is, hitting their mark on cost, schedule, and scope (benefits)?
Wonder no more! Bent Flyvbjerg and his team created a database of roughly 16,000 (mega)projects, covering 20+ fields and 136 countries. And the results are… alarming! That’s still putting it mildly.
Of all the projects Flyvbjerg analyzed, only 8.5% hit the mark on cost and time. Can it get worse, you ask?
Yes, it can! Just 0.5% hit the mark on all three—that’s 80 successful deliveries on 15,920 nightmares. A breathtaking ratio of 1:200.
Imagine trying to land a plane and succeeding only once in 200 attempts. Yikes!
Can the score be even worse for us, IT project managers?
Sadly, yes.
• 18% of IT projects had cost overruns above 50%.
• For these projects, the average overrun was a staggering 447%.
Putting things into perspective, we’re close to the ‘failure’ bottom, narrowly beating nuclear storage, Olympic venues, and nuclear power projects. Even aerospace, defense, bridges, tunnels, and mining projects perform better.
Contrasting Flyvbjerg’s research with PMI’s Pulse of the Profession or McKinsey’s published data, the results are still far from desirable, but they offer a more optimistic view:
• Around 55% of IT projects meet their initial goals and business intent.
• Budget overruns remain common, with IT projects exceeding planned budgets by an average of 27%.
• Project delays are prevalent, with roughly one in three IT initiatives reported as late and many delayed by up to 50% or more.
It’s important to note that Flyvbjerg’s research focuses on large-scale, high-stakes, complex megaprojects, whereas PMI’s data aggregates projects of varying sizes and complexity, including smaller projects, which statistically perform better in terms of time, budget, and benefit delivery. PMI also doesn’t (at least to my knowledge) assess long-term value delivery. The same project that meets PMI’s metrics for success might fail Flyvbjerg’s stricter criteria.
Since less complex projects typically meet their metrics more reliably, it’s clear that everything depends on perspective, criteria, and sample size.
Tools, Strategies, and Suggestions
1) Start with WHY
One of the first lessons I learned as a project manager was: always focus on your goal and endgame. This mantra still guides me when assessing options or strategies. Mentally stepping back from the nitty-gritty, visualizing the goal, and asking myself, “What’s the bigger picture here? How does this contribute to or hinder achieving the goal?” almost never fails.
Flyvbjerg suggests a similar approach: develop a clear, informed understanding of WHAT and WHY the project goal is—and never lose sight of it. From the very beginning to the very end.
Takeaway:
Regularly ask yourself: “Do my actions contribute to the ultimate goal of the project?”
2) Think Slow, Act FAST
Regardless of project size, one universal truth emerges: everyone is always too eager to get started! Especially when contract talks drag on, the pressure to execute builds, fueled by excitement and executive pressure. Been there, done that.
Flyvbjerg’s advice: think slow—reframe planning from a theoretical tabletop exercise into something way more tangible (we’ll get to planning details shortly). Once you’ve built a solid, tested foundation, move into execution and act fast.
Why? The longer the execution phase, the larger the window of opportunity for risks, Black Swans, and other unwanted surprises to creep in.
Takeaway:
“Projects often don’t go wrong so much as they start wrong.”
3) Planning Fallacy and Cognitive Biases
Optimism and overconfidence are deeply ingrained in us. We’re inherently prone to cognitive biases, often convincing ourselves we’re too smart to make basic mistakes.
Daniel Kahneman’s Thinking, Fast and Slow provides ample examples. One of them is the WYSIATI fallacy (What You See Is All There Is)—our tendency to make decisions based on immediately available information, ignoring gaps or uncertainties.
This leads to:
• Underestimating risks and unknowns.
• Overlooking external factors.
• Jumping to answers instead of asking questions.
• Falling victim to confirmation bias—often resulting in watermelon projects (green on the outside, red inside) or similar disasters. Happy days!
It’s all too easy to blame delivery teams for missed milestones, but the truth is those milestones were likely flawed from the start.
So, elevate your planning game and confront your cognitive biases!
Takeaway:
1. “Best-guess does not equal best-case scenario.”
2. Familiar with Hofstadter’s Law? “It always takes longer than you expect, even when you account for Hofstadter’s Law.”
4) Planning Process
Traditional planning, especially in Waterfall environments, often feels like a theoretical exercise: define scope, create a WBS, document assumptions, and develop a course of action... Sounds familiar, right?
Flyvbjerg advocates for a more hands-on, Agile-like planning approach:
• Test your assumptions in real-world scenarios.
• Build prototypes, conduct PoCs, and iterate, iterate and iterate some more
• Solve problems during planning when the stakes are low, rather than during execution when reputations and budgets are on the line.
“The planning process ensures that literally every part of the plan, from the broad strokes to the fine details, is scrutinized and tested. Nothing is left to be figured out when the project goes to delivery.”
Takeaway:
Avoid turning the planning phase into a mere theoretical exercise. Planning is DOING.
5) Reference Class Forecasting
Flyvbjerg also advocates for the use of Reference Class Forecasting. While there may not be a centralized, publicly available database exclusively dedicated to IT project data, your organization likely maintains historical records of past projects, including lessons learned.
The strength of reference classes lies in their ability to reflect real-world outcomes, encompassing a wide range of scenarios. Unknown unknowns, Black Swans—they’re all captured within this data. To disregard such insights, with the mindset that “this could never happen to us; we’re smarter than that,” is nothing short of hubris.
Be cautious, though—don’t let arrogance lead you to adjust the data to fit your expectations. That’s a surefire way to reintroduce biases.
Takeaway:
Leverage history, and don’t assume you’re exempt from its lessons.
6) Experienced Team
This one’s simple: hire the right people and put them in the right roles. Flyvbjerg emphasizes the value of a “masterbuilder” and their team—someone with deep expertise and a proven track record. The right team can make magic happen.
That’s a key ingredient in the recipe for successful project delivery.
Takeaway:
“You want someone with deep domain experience and a proven track record of success in whatever you're doing.”
7) Modularity
Stepping on a Lego piece at night, barefoot, can be excruciating—but the concept behind Lego is nothing short of brilliant. Can we apply this idea to our projects, using it to construct large, complex systems from small, manageable pieces? After all, isn’t a server just a Lego brick in the larger structure of a data center?
Flyvbjerg’s research revealed that projects grounded in the concept of modularity—such as solar or wind power initiatives—consistently emerged as the top performers by a significant margin.
Let’s take a quick dive into the concept of modularity, where breaking a complex system into smaller modules provides numerous benefits:
• Scalability: Build a single module as a building block, integrate it into the system, and use the tested and proven blueprint to replicate it. Repetition at its best.
• Flexibility: Modularity allows for changes or repurposing of individual modules without disrupting the entire system.
• Resilience: Issues within a single module are less likely to jeopardize the operation of the entire system.
• Efficiency: Modularity enables faster learning, quicker iterations, and lower costs.
Takeaway:
Flyvbjerg’s research shows that modular projects are significantly less prone to disaster. They are faster, cheaper, and inherently less risky.
Final Thoughts
If you made it this far and still want a summary, I can only say this: go and buy the book—it’s 100% worth it. I couldn’t include everything here, so you’ll find plenty more insights to mine.
And if you do read it, I’d love to hear what resonated with you the most!