45% over budget, half the value: the base rate for big IT

On a large IT project, the honest prior is failure. McKinsey and Oxford studied more than 5,400 projects with budgets above $15 million and found the average one ran 45 percent over budget, 7 percent over schedule, and delivered 56 percent less value than promised. Those are averages, not outliers. Before you plan a route-to-market platform program, that is the base rate you are betting against — and the size of the bet is the real problem.

What did McKinsey and Oxford actually measure?

The study, run with Oxford's BT Centre for Major Programme Management, is the largest of its kind: more than 5,400 IT projects, each with an initial budget above $15 million, spanning software, hardware and infrastructure. Its point is not that some projects fail spectacularly — everyone knows that. Its point is that the average, unremarkable, sensibly-governed large project already misses badly. Four numbers carry the argument.

Read the value line twice. A project can land close to its schedule — 7 percent late is almost punctual by enterprise standards — and still return barely half the benefit that justified funding it. The overrun you can see on the finance dashboard is the smaller failure. The value that never arrives is the larger one, and it is the one nobody reconciles after go-live, because the business case has long since been filed. Across the sample, the aggregate cost overrun came to $66 billion — more, the authors note, than the GDP of Luxembourg.

Why do the odds get worse as the project gets bigger?

Because scale and duration are not neutral. The same McKinsey data shows that every additional year a project runs adds roughly 15 percent to its cost overrun. Duration is not a container for risk; it is a multiplier of it. A three-year program is not three times a one-year program — it is a one-year program compounding its own overrun annually while requirements, staff and the market underneath it all keep moving.

The Standish Group's CHAOS research, for all its methodological baggage, points the same way. Its 2020 figures split projects into 31 percent successful, 50 percent challenged and 19 percent outright failed. Break that down by size and the gradient is brutal: small projects succeed roughly 90 percent of the time, while large ones succeed less than 10 percent. Size is the single strongest predictor of failure in the dataset — stronger than technology, methodology or team.

The mechanism is not mysterious. A bigger project has more people, more hand-offs and more boundaries to coordinate across, and each boundary adds queue time rather than work. Most of a feature's life on a large program is not spent being built; it is spent waiting in a queue for a review, an environment or a decision. Add years and you pay the tax twice: a longer ramp before anyone is productive — the productivity loan you take out at the start of every large staffing effort — and a wider coordination surface once they are. Duration does not just cost more; it converts more of your spend into overhead.

Can you trust numbers this old and this convenient?

Partly, and the caveats matter more than the punchline. The Standish figures in particular have been challenged hard: Eveleens and Verhoef argued the definitions are so strict — a project counts as "successful" only if it hit its original cost, schedule and scope exactly — that they systematically understate real outcomes and can be gamed by adjusting estimates rather than performance. Take the absolute percentages as directional, not gospel.

But the direction is what survives scrutiny, and it is remarkably stable: large projects miss more than small ones, and long projects miss more than short ones. The McKinsey study, built on real budgets rather than survey self-reports, lands in the same place by a different method. When two datasets with different biases and a decade between them agree on the gradient, the gradient is the finding. You do not have to believe in exactly 45 percent to plan around the fact that big-and-long is the risk factor you can actually control.

What does the base rate mean for a route-to-market platform program?

A multi-country order-capture, stock, loyalty and delivery program is, structurally, exactly the thing the McKinsey study measured: an initial budget comfortably above $15 million, a multi-year timeline, several vendors and a governance stack to match. Plug it into the base rate and the expected outcome is a program that lands roughly half-short on value, over on cost, and — for 17 percent of large IT projects in the study — at a scale that threatens the company's existence. That last figure is the one to sit with: nearly one in five large IT projects does not merely disappoint, it endangers the business that commissioned it.

None of this argues for less ambition. It argues that the program shape — one large, long, multi-vendor effort — is the specific thing the numbers punish, independent of how good the plan or the people are. Much of the cost is structural before a line of code is written: the coordination overhead of a standing governance stack, the estimating optimism every business case carries, and the compounding penalty of a timeline measured in years.

The one lever the base rate hands you is size, because it is the variable you fully control. Shrink the project, not the ambition: run the platform as a sequence of pilot-scale slices — one capability, one operating company, live in weeks — each small enough to sit at the 90-percent-success end of the curve rather than one program-scale bet sitting at the 10-percent end. The ambition is delivered by accumulation; the risk is spent in increments you can absorb. That is the whole case for a pilot-first shape, and it deserves its own longer argument.

The base rate will not improve on its own; if anything, as platforms grow more entangled and the vendor count climbs, the average large program has further to fall. What is changing is that the alternative is now credible — a small team with modern tooling can ship a working capability in the time a traditional program spends chartering its steering committee. The organisations that internalise the McKinsey number will not be the ones who plan large projects more carefully. They will be the ones who stop starting them.