I’ve spent enough time leading large-scale IT and digital transformation projects to know one thing for sure: humans are terrible at estimating how long things will take. If you’ve ever been told a project will be delivered in six months and then watched it spiral into an 18-month odyssey (with a budget that inflates like a balloon at a kids’ party), you’ll appreciate -as I did- How Big Things Get Done by Bent Flyvbjerg and Dan Gardner.
It’s a book that should be required reading for anyone who’s ever been caught between executives demanding faster results, teams promising the impossible, and the reality that big things—especially ambitious, groundbreaking projects—are almost always underestimated in time, cost, and complexity. One of the most fascinating (and, let’s be honest, depressing) ideas in the book is that we don’t just underestimate big projects: we do it systematically, predictably, and repeatedly. It’s not an occasional mistake; it’s a feature of human thinking.
We all suffer from optimism bias: the belief that, somehow, this time will be different. That this time, we’ll be more efficient. That this time, nothing unexpected will happen. Spoiler alert: something unexpected always happens. IT leaders know this pain well. The system upgrade that was supposed to take a weekend? Now on week three. That digital transformation initiative that seemed straightforward? Turns out, legacy systems don’t like playing nice. The big AI rollout? Oh, now there are ethical concerns and regulatory hurdles that no one saw coming.
Flyvbjerg makes a great point: big projects are often best run like major architectural feats, not like « move fast and break things » tech experiments. Look at the Sydney Opera Hous… what should have been a four-year project turned into a 14-year saga with a final price tag over 1,300% higher than the original estimate. On the other hand, the Empire State Building was completed ahead of schedule and under budget. Why? Because the Empire State team planned in meticulous detail before they ever started building. They modelled. They anticipated. They didn’t assume things would just magically work out.
Big projects need architects, not cowboys
In tech, we love the idea of agility, of iterating, pivoting, and figuring things out as we go. And yes, agile methods work—until they don’t. When you’re overhauling an entire IT infrastructure or implementing AI at scale, « we’ll figure it out later » is most often not a strategy: the cost of getting it wrong is always higher than the cost of slowing down and thinking first.
While we’re on the topic of misconceptions, let’s talk about Agile. Agile Is Not « Move Fast and Break Things« : It’s a rigorous process-driven approach. One of the most frustrating things I’ve had to explain (and again and again and again) is that agile is not some unstructured, cowboy-style free-for-all. In fact, Agile is one of the most process-heavy methodologies out there. Too many people think that « Agile » means working without a plan—just improvising on the go. That’s completely wrong. Agile frameworks like Scrum and SAFe are highly structured, disciplined approaches that require strict adherence to methodology. They are built around continuous feedback loops, structured sprints, and clearly defined deliverables. In my book, that is designed to mitigate risk, not increase it 😊. The irony? Agile, when done right, is actually a very solid safeguard against the kind of disastrous underestimation that Flyvbjerg warns about.
The book is full of hard truths, but here’s the biggest one: the most successful projects are the ones that take planning seriously. Not just « we made a PowerPoint and a Gantt chart » planning, but real planning: anticipating risks, stress-testing assumptions, and designing for scalability. I’ve seen too many projects go sideways because people confuse speed with progress. The reality is, moving too fast without a solid plan isn’t agility: it’s recklessness. And the cost of getting it wrong is always higher than the cost of slowing down and thinking first.
Next time someone tells me « we can definitely do this in six months« , I’ll just smile, nod, and add another six months in my head. Because experience—and this book—says that’s probably a lot closer to the truth.
