Trap 3 - The planning

The most beautiful overrun in the world

In 1957, a young Danish architect, Jørn Utzon, won the competition to design Sydney’s new opera house: white shells rising over the harbor like sails. The plan promised 7 million Australian dollars and an opening in January 1963.

Construction started in 1959, before anyone knew how to build the shells. Part of the podium had to be torn down and rebuilt to carry a roof nobody had designed when it was poured. Utzon left in 1966 and never came back.

The Opera House opened in October 1973, ten years late, at 102 million dollars: more than fourteen times the estimate, and still the Guinness record for the largest proportional cost increase on a building. Today it is one of the most admired buildings on Earth. Nobody remembers the plan. The people who lived through it never forget.

A hypothesis dressed as a promise

Every program starts with a plan: a scope, a date, a budget. At that moment, it is the best guess a group of capable people can make about a future nobody can see.

Then something subtle happens. The guess goes into a business case. The business case gets approved. The date gets announced to the board, the regulator, the clients. And the hypothesis quietly becomes a promise.

From then on, reality has two ways to meet the plan. It can confirm it, which is rare. Or it can contradict it, and people have to choose between changing the plan, which feels like breaking a promise, and protecting it, which feels like loyalty. Most choose loyalty. That’s not dishonesty; it’s how organizations reward people.

That is the planning trap: committing to a guess as if it were a fact, and then defending it instead of updating it.

The ten faces of the trap

Ten shapes, in three families: how we estimate, how we commit, and how we adjust. Most late programs show four or five of them.

How we estimate

“Our program is different.” Every program feels unique from the inside, so nobody looks at how similar programs actually went. Daniel Kahneman called it the inside view: we plan from our own story, not from the evidence of everyone else’s.
The estimate as negotiation. The first honest number is “too high,” so it gets reworked until it fits the budget envelope. Then the negotiation runs the other way: teams blamed for “missed points” learn to pad, and estimates quietly inflate. Either way, the number stops being a forecast and becomes a defense.
No room for the unknown. The plan covers every known task and nothing else. Contingency is either missing or quietly spent in the first quarter on things that were known all along.

How we commit

Scope, date and budget, all fixed. Locking all three leaves quality as the only variable. It gives way silently, and the bill arrives after go-live.
The date came first. The deadline was announced before anyone planned the work, and the plan was then built backward to fit. Everything looks feasible, because it was designed to.
Building before designing. Like the Opera House podium, work starts before the key unknowns are solved, to show progress or to secure funding. Early speed becomes late rework.
The long window. Years of build before the first real user. The longer the window, the more time the world has to change underneath the plan: new regulations, new leaders, new technology.

How we adjust

False precision. A Gantt chart detailed to the day for month eighteen. The precision suggests a certainty nobody has, and makes every deviation look like a failure.
Plans per team, not per program. Each team has a credible plan. The integration between them, where most of the risk lives, belongs to no one’s plan.
Sunk cost. “We’ve spent too much to stop now.” The money already spent becomes the reason to keep spending, long after the business case stopped making sense.

Agile was supposed to dissolve this: short iterations, measured velocity, a backlog instead of a Gantt chart. At team level, it often works. At program level, culture usually wins. For a decade, the State of Agile surveys have named culture as the top barrier to scaling, and in a recent edition only 11% of respondents said they were very satisfied with agile.

Worse, “agile” often becomes a joker. A program that can’t decide what it wants calls its indecision agility: “we’ll figure it out in the sprints.” Look closer, and the classic program is still there. The date was announced to the board. The budget envelope is fixed. Integration and data migration still happen in one big bang at the end. The only thing that disappeared is the specification. Thin user stories nobody challenged replaced real requirements, and acceptance criteria get written after the code. Specifications are weaker than ever, while scope, date and budget are as fixed as before.

That isn’t agile. It’s waterfall without the documents: all the commitments of a classic program, none of its upfront thinking. Real agility flexes scope in order of value. Joker agility flexes nothing, except clarity.

Once velocity becomes a target, teams do what any measured system does: they adapt to the measure. More than once, I have seen a team estimate the exact same story at 13 points, then at 34. I have also seen the opposite move. Teams challenged for not having a predictable delivery rate slowed down on purpose: they set their pace at the lowest level they were certain to reach, and never went beyond it. Velocity became perfectly stable, and perfectly useless as a forecast.

Padding doesn’t even buy safety. A buffer hidden in a team estimate tends to get consumed, so the program still overruns while every team looks safe. Safety belongs in one visible, pooled contingency, not in fifty private ones.

The iron law

If this sounds pessimistic, look at the data. Bent Flyvbjerg, an Oxford professor, has spent decades building a database of more than 16,000 large projects. In How Big Things Get Done, he and Dan Gardner report that only 8.5% came in on both budget and schedule, and just 0.5% also delivered the promised benefits. One project in two hundred.

The second finding matters even more. Overruns don’t spread evenly around a small average. A significant share of projects don’t miss by 10% or 20%; they miss by multiples, like the Opera House. Planning for the average leaves you defenseless against the tail.

IT is the worst case

In 2025, Flyvbjerg and four co-authors went further. They compared 11,011 projects across 23 types, from roads and wind farms to nuclear power and IT. The question was simple: is IT really riskier than everything else, or does it just feel that way?

It is riskier. IT has the fattest tail of all 23 types. It is the only one whose tail is so heavy that, mathematically, its mean and variance are infinite: there is no “typical overrun” to plan around. And among IT projects that overrun by more than 50%, the average overrun is 453%.

Their explanation will sound familiar. Two drivers stand out: bespoke builds instead of modular components, and “think-fast” decision-making that leaves projects underprepared. The antidotes they propose are modularity and thinking slow.

Time is the multiplier

Flyvbjerg’s explanation for the tail is beautifully simple: the longer a project runs, the wider its window of vulnerability. Every extra month is another month for something to go wrong. A key person leaves, a vendor changes strategy, a regulation moves, a sponsor is replaced.

An earlier McKinsey and Oxford study of more than 5,400 large IT projects put a number on it: each additional year of schedule raised cost overruns by 15%. On average, those projects ran 45% over budget and delivered 56% less value than predicted. Delay doesn’t just cost money. It buys more risk.

The consequence is a vicious circle. An optimistic plan creates a long build. A long build creates exposure. Exposure creates surprises. Surprises create delay. And delay, once more, lengthens the window.

Early signals

You can see a planning trap forming in the very first weeks:

Nobody can say how comparable programs went, inside or outside the company.
The estimate went down between two versions of the business case, while the scope didn’t.
The go-live date was announced before the plan existed.
The plan has a single date, not a range.
The budget is a single number, with no idea of what a bad case looks like.
There’s no contingency line, or it’s already half spent.
The first real user is more than a year away.
The riskiest part of the work is scheduled last.
Every team is on track, and nobody owns the integration plan.
“We’ll figure it out in the sprints” is the answer to every open design question.
“We can’t stop now” is said more often than “is this still worth it?”

How to plan honestly

The answer isn’t to stop planning. It is to plan like a scientist and commit like an engineer: slowly while thinking is cheap, fast once building is expensive. Flyvbjerg sums it up as “think slow, act fast.”

Start from the outside view. Before estimating your program, look at how similar programs actually went: their real duration, cost and overrun. Flyvbjerg calls it reference class forecasting. Then adjust for what is genuinely different, which is usually less than you think.
Give ranges, not points. “Between 14 and 20 months, most likely 16” is more honest and more useful than “go-live on March 3.” Commit externally to the cautious end of the range.
Solve the unknowns before building. Spend the early months on the riskiest questions: prototypes, spikes, a slice through the hardest integration. Planning and testing on paper are cheap; rework in concrete, or in production, is not.
Fix two, flex one. Choose what is fixed among scope, date and budget, and let the third adjust openly. Usually the date and budget hold, and scope is negotiated in order of value.
Shorten the window. Deliver to real users within months, not years. Every early release reduces exposure and replaces assumptions with facts. Given the 2025 data, this matters more in IT than anywhere else.
Protect the contingency. Size it from the reference class, not from hope. In a fat-tailed world, budget to a pessimistic percentile of comparable projects (P80 or higher), not to the median. Keep the reserve visible, owned by the sponsor, held at portfolio level where you can, and spent only on true surprises.
Plan the program, not just the teams. One integrated plan that shows the dependencies and integration points between teams, with a named owner for each.
Replan on a rhythm. Every quarter, re-estimate from what the team has actually delivered, and show the new forecast next to the original. Replanning is not failure; hiding the gap is.
Define success and kill criteria in advance. Decide at the start what success looks like, and what results would justify stopping or reshaping the program. It pays: PMI’s 2025 Pulse of the Profession reports that projects with success criteria defined upfront, and a mature system to measure them, succeed at nearly twice the rate of those without. Money already spent is not part of the decision.

What to avoid

Announcing a date before the plan exists.
Negotiating the estimate down without changing the scope.
Fixing scope, date and budget all at once.
Starting to build before the riskiest questions have answers.
Scheduling the hardest part last.
Day-level precision for work more than a quarter away.
Budgeting to the average in a fat-tailed world.
Calling indecision “agile” while date, budget and scope stay fixed.
Letting money already spent decide whether to spend more.

The AI twist

AI is changing the inputs of every plan, but nobody yet knows by how much.

In early 2025, the research group METR ran the most rigorous test so far: a randomized trial with 16 experienced open-source developers working on 246 real tasks in codebases they knew well. With AI tools, they took 19% longer. Before starting, they had predicted AI would make them 24% faster. That’s the inside view, measured.

A year later, the picture had moved. METR’s follow-up, with 57 developers and more than 800 tasks, pointed toward a speedup instead: about 18% for the returning developers, with a confidence interval running from 38% faster to 9% slower. And METR itself called the new data unreliable, because too many developers now refused to work without AI for the control group.

If the people who measure this for a living can’t pin the number down, your plan shouldn’t pretend to.

Coding is also only one part of a program. Google’s 2025 DORA report, based on nearly 5,000 practitioners, found AI adoption at 90%. Its central conclusion is that AI acts as an amplifier: it magnifies an organization’s strengths and weaknesses alike, and stability has become a real concern as teams ship faster. Meanwhile decisions, integration, data migration and adoption move at the same speed as before. A plan that assumes everything gets faster will be as wrong as one that assumes nothing does.

There is a real opportunity, too. AI makes the outside view far cheaper. It can help gather comparable programs, analyze past estimates against actuals, and simulate ranges instead of single dates. And it makes “think slow” cheaper: prototypes and spikes that took weeks now take days, so there is less excuse to start building before the unknowns are solved.

Plans are for learning

The best programs I have worked on did not have the most detailed plans. They had the most honest ones: ranges instead of dates, the riskiest work first, and a sponsor who said “thank you” when the forecast changed, rather than “who’s responsible?”

So next time you’re handed a plan, ask one gentle question: what did similar programs actually take, and how far is this plan from that? The answer will tell you more than the Gantt chart.

Have you lived through your own Opera House, beautiful in the end but painful on the way? I would genuinely love to hear your story.

All situations described here are composites, drawn from many programs over 25 years.