Project Success Rate by Project Size

The full resolution table, by size band

The CHAOS 2015 report splits every software project into five size bands and reports the share that were successful, challenged (late, over budget, or under-scoped), or failed (cancelled or never used). The trend is monotonic: success falls and failure rises at every step up in size.

Resolution of all software projects by size, Standish Group CHAOS Report 2015, page 3 (Modern Resolution: OnTime, OnBudget, with a satisfactory result; FY2011–2015). Each row sums to 100%. Figures read directly from the primary report.

Why size dominates the outcome

Standish has argued since the first CHAOS Report in 1994 that project size is the single most important factor in project outcome, ahead of technology, methodology, or team. The 2015 breakdown is the clearest statement of it: a grand project is more than seven times as likely to fail outright as a small one, and roughly ten times less likely to succeed. Three mechanisms drive the pattern:

• Complexity rises faster than size. Stakeholders, interfaces, and dependencies multiply as a project grows, so coordination cost climbs faster than the headline budget. The system that has to work grows non-linearly with the money spent on it.
• Feedback arrives later. A large project accumulates more scope before anything ships, so estimation errors, integration problems, and requirement misunderstandings are discovered late, when they are most expensive to fix. Small projects deliver working increments sooner and surface the same risks early.
• Decision latency compounds. The CHAOS 2020 "Beyond Infinity" report names slow decision-making as the root cause of failure. Large projects have longer decision chains, so latency accumulates across every choice, and the cost of a delayed decision scales with the size of what is waiting on it.

The practical lesson is the most actionable one in the whole dataset: size is the variable most under a sponsor's control. Breaking a large programme into small, independently deliverable pieces moves work from the 6% column toward the 61% column.

The same shape appears outside IT

The size-risk relationship is not a quirk of software. Bent Flyvbjerg's database of more than 16,000 projects shows the same shape across physical megaprojects: larger and more novel projects carry fatter cost-overrun tails, and only about 0.5% of large projects come in on budget, on time, and with the promised benefits. The McKinsey-Oxford study of large IT projects found they run 45% over budget on average and deliver 56% less value than predicted. Different samples, different sectors, same direction: scale is a risk multiplier.

It also compounds with delivery method. The CHAOS 2015 agile-versus-waterfall breakdown shows waterfall barely scaling (3% success on large projects) while agile degrades more gracefully (18%). Small size and incremental delivery are the same lever pulled in two ways.

What the numbers do not say

Two caveats travel with these figures. First, the definition is strict: a project counts as successful only if it was on time, on budget, and delivered a satisfactory result. Under a looser "did it ship" test every band would be higher; the interesting part is the gap between bands, not the absolute level. Second, CHAOS is a survey of self-reported outcomes from IT executives, not an audited dataset, and academics (notably Eveleens and Verhoef, 2010) have argued the definitions inflate failure rates. The direction, that success falls sharply with size, is robust and echoed by independent datasets; the exact percentages should carry that methodological caveat.

How to cite

Authoritative source: standishgroup.com

The full CHAOS reports are paywalled; the 2015 resolution-by-size table is widely reproduced in openly accessible secondary sources (Scrum.org, InfoQ, PM World Journal) and matches the figures above.