Most software projects do not deliver.
We read this literature because clients ask us to do hard things on serious budgets. The honest answer is that the industry's track record on these engagements is bad, has been bad for decades, and improves only when a small set of practices is in place. We study that record because we refuse to expose our clients to those risks. Below: the base rates worth knowing, the curve worth respecting, the seven rules in consensus across the field's authorities — and how we apply them.
Nothing here is original. That is what makes it load‑bearing.
The numbers everyone avoids quoting.
Four headline findings from four named studies — Oxford, McKinsey, PwC, Flyvbjerg at HBR. Each one large‑sample, each one decades‑deep. Hover any card to roll the count again.
- § 01 / 041 in 0
large IT projects deliver benefits on time and on budget.
McKinsey × Oxford Global Projects2024 · Expanded dataset - § 02 / 041 in 0
is a Black Swan: 200% cost overrun, ~70% schedule overrun.
Flyvbjerg & Budzier · HBRSept 2011 · 1,471 projects - § 03 / 040%
less value delivered than the business case predicted on large IT.
Bloch · Blumberg · Laartz · McKinseyOct 2012 · 5,400+ projects - § 04 / 040.0%
of organizations finish every project on time, in budget, to scope, with the right benefits.
PwC · Programme & Project Management10,640 projects · 30 countries
Success collapses with size.
The Standish CHAOS reports — 50,000+ projects over three decades — show the most reliable predictor of project success isn't methodology, talent, or industry. It is size. Small projects succeed roughly nine times in ten. Large ones, less than one in ten.
Cap the scope. Then cap it again.
Source: Standish Group · CHAOS Reports 1994–2020 (Jim Johnson et al.) · indicative percentages drawn from the published bands.
The risk curve is not a bell.
Most project budgets are sized as if cost overruns followed a tidy normal distribution. They don't. Flyvbjerg's data — and the McKinsey–Oxford update — shows that IT overruns are fat‑tailed: a lower peak around the average, then a long brass tail that stretches well past 100% overrun, where Black Swans live.
Source: Flyvbjerg & Budzier · HBR 2011; Bloch et al. · McKinsey 2012; Flyvbjerg & Gardner · How Big Things Get Done (2023). Curves are stylized; the tail shape is the empirical finding.
The probability of an IT project spinning out of control is roughly twenty times greater than standard risk models predict. That is the gap between the two curves. It is the part most contingency budgets ignore.
What every authority quietly agrees on.
Seven recurring findings across the literature — Standish, McKinsey, BCG, Deloitte, PMI, MIT CISR, Brooks, Flyvbjerg. The remarkable thing is how little disagreement there is. The stamps under each rule are the named sources that back it.
- § 01
Active, accountable executive sponsorship.
One named sponsor with budget authority and meaningful time on the engagement. CHAOS 2020 elevated Good Sponsor to one of three master factors. McKinsey attributes half of all cost overruns to weakness on strategy and stakeholders.
- Standish CHAOS 1994–2020
- McKinsey 2012
- BCG 2020
- Deloitte ERP
- PMI Pulse 2017
- § 02
Clear business objectives — and benefits realization, not just an iron triangle.
PMBOK 7 (2021) and 8 (2025) anchor success in value, not scope/time/cost alone. MIT CISR's prerequisite is operating‑model clarity: Diversification, Coordination, Replication, or Unification. Without it, you execute the wrong system flawlessly.
- PMI PMBOK 7/8
- MIT CISR · Ross · Weill
- McKinsey value assurance
- Flyvbjerg
- § 03
Aggressively reduce scope and schedule. Deliver in small modules.
The most over‑determined finding in the literature. Brooks's Law, Standish's 90/10 split, McKinsey's ≤ 4 weeks / ≤ 20 person‑days rule, Flyvbjerg's Build with Lego. Every additional year of duration adds roughly 15% to cost overruns.
- Brooks · Mythical Man-Month
- Standish CHAOS
- McKinsey 2012
- Flyvbjerg · How Big Things Get Done
- DORA / Accelerate
- § 04
Use the outside view: reference‑class forecasting.
Replace inside‑view point estimates with the empirical distribution of comparable completed projects. Endorsed by the American Planning Association in 2005 and adopted by HM Treasury, the Danish Ministry of Transport, and others. The fat tail is the reason this matters.
- Flyvbjerg · Oxford / Saïd
- Kahneman · Nobel 2002
- APA 2005
- HM Treasury
- § 05
Secure and retain a good team.
Standish: Good Team — skilled, emotionally mature, low decision latency — is a master success attribute. Brooks documents order‑of‑magnitude productivity differences among engineers. McKinsey: staffing dominates process. Treat the implementation team as the single largest variable.
- Standish CHAOS 2020
- McKinsey 2014 · talent
- Brooks
- BCG 2020
- Deloitte ERP
- § 06
Continuous stakeholder involvement. Requirements as a flow, not a phase.
User involvement has been a top‑five Standish factor in every report since 1994. PMI Pulse 2017 ranks inaccurate requirements as the second‑largest cause of failure. MIT CISR's demand shaping replaces annual budgeting with continuous portfolio reshaping.
- Standish CHAOS
- PMI Pulse 2017
- McKinsey value assurance
- MIT CISR · Ross & Beath
- § 07
Disciplined process maturity plus agile delivery — not either/or.
The standards that govern enterprise software — Carnegie Mellon's CMMI and ISO/IEC/IEEE 12207 — explicitly accommodate hybrid lifecycles. The choice of methodology matters less than the discipline of execution: PMI's 2024 Pulse finds no significant performance gap among predictive, agile, and hybrid approaches.
- Carnegie Mellon SEI / CMMI
- ISO/IEC/IEEE 12207:2017
- ISO 21502:2020
- PMI Pulse 2024
Three thresholds we do not cross.
Concrete triggers, set ahead of time, written into the engagement. When any one of them fires, the work halts and is re‑baselined. The gauges are calibrated against the empirical distributions above.
- § 01
Budget breach.
If projected total cost crosses 130% of the original baseline, the project halts and is re‑baselined before any further commitment. This is roughly Flyvbjerg's empirical median uplift at a Category B gate — past it, we are flying blind into the tail.
- § 02
Quality drift.
If user‑acceptance defect density rises for three consecutive sprints, new scope is frozen and the team stabilizes the existing surface. Brooks's regression toward chaos — when defects grow faster than they are closed, more features make the slope steeper.
- § 03
Authority change.
If the named sponsor leaves the role, the engagement is treated as a restart — discovery, alignment, contract review. Continuity is not assumed. The single most leveraged failure mode in the literature is the silent loss of executive air cover.
What the studio does differently.
We do not pretend to outperform the base rates by being smarter than McKinsey or harder‑working than the SEI. We outperform by refusing the engagements where the rules cannot be respected — and structuring the rest of the work so the rules are followed by default, not by heroism.
- § 01Reference‑class forecasting on every proposal.
Inside‑view estimates get an outside‑view uplift drawn from comparable completed engagements. If the client's expected budget sits below the 30th percentile of the reference class, we restructure scope or decline. We refuse the engagement we cannot honestly deliver.
- § 02≤ 4 weeks · ≤ 20 person‑days per increment.
Every deliverable is decomposed to fit the McKinsey rule. ERP and procurement work ships module by module — vendor management, requisitioning, catalogs, approvals, analytics — never as a big bang. The cadence is the constraint that prevents the fat tail.
- § 03One named sponsor. One named architect.
Refused to start without both. The sponsor protects the work from political drift. The architect protects it from feature drift — Brooks's conceptual integrity. Two single points of accountability instead of a committee of intentions.
- § 04Benefits realization in the business case, not just go‑live milestones.
We instrument what the work is supposed to cause, not what it ships. Where commercially possible, a portion of fees is tied to measured outcomes. The metric belongs in the contract; otherwise the engagement is shipping diagrams.
Read the primary literature.
Every claim above traces back to a named, large‑sample study. The convergence is what matters. Pull the originals — the studio keeps internal annotations against each.
- Flyvbjerg & Budzier · Why Your IT Project May Be Riskier Than You Think · HBR Sept 2011
- Bloch · Blumberg · Laartz · Delivering large‑scale IT projects on time, on budget, and on value · McKinsey 2012
- Flyvbjerg & Gardner · How Big Things Get Done · Currency / Penguin 2023
- Standish Group · CHAOS Report 2020: Beyond Infinity (Jim Johnson)
- BCG · Flipping the Odds of Digital Transformation Success · Oct 2020
- PMI · A Guide to the Project Management Body of Knowledge (PMBOK), Seventh Edition · 2021
- PMI · Pulse of the Profession 2017 · Success Rates Rise
- Brooks · The Mythical Man‑Month: Essays on Software Engineering · Addison‑Wesley 1975 / 1995
- Ross · Weill · Robertson · Enterprise Architecture as Strategy · MIT CISR / HBR Press 2006
- Carnegie Mellon SEI / CMMI Institute · CMMI Model v3.0 (2023)
- ISO/IEC/IEEE 12207:2017 · Software life cycle processes
- PwC · Boosting Business Performance through Programme and Project Management (3rd Ed.)
Got a serious project on the table?
Bring us the engagement before the contract is signed. We can stress‑test scope against the reference class, structure the increment cadence, and tell you honestly whether the work as scoped sits inside the safe zone — or the tail.