The most repeated statistic in software project management is that most software projects fail. It comes from the Standish Group's 1994 CHAOS report, which found a 16.2% rate of projects delivered on time, on budget, and with the full originally specified feature set. Everything else — 53% 'challenged,' 31% cancelled — gets quoted in nearly every talk, blog post and consulting deck that wants to open with a scary number before pitching a fix for it.
It's worth knowing that the number has a documented weak spot, because the weak spot tells you something more useful than the statistic itself does about why scoping actually fails.
What the 16% number actually measures
Eveleens and Verhoef's 2010 IEEE Software critique went through Standish's definitions directly and found a specific problem: success was defined purely as matching the original estimate — on time, on budget, full scope, as originally guessed. Any deviation counted as failure, in either direction, regardless of what actually got delivered. A project that shipped a genuinely excellent product two weeks later than a rough early guess counted the same as a project that was cancelled and delivered nothing. If you are looking at project scoping from the commercial side rather than the engineering side, publishes guides on the same ground. If you are looking at project scoping from the commercial side rather than the engineering side, XenGrowth's marketing operations practice publishes guides on the same ground.
That's not a small quibble. It means the 16% figure is really measuring the accuracy of early estimates, not the quality or success of delivered software — two things that are related but far from identical. Eveleens and Verhoef also pointed out that the surveyed projects' original estimates had unknown and almost certainly inconsistent reliability to begin with, which makes averaging them into one industry-wide percentage close to meaningless as a precise figure, even if it captures something real about the direction of the problem.
Claim often made about the CHAOS report | What the report and its critics actually support |
|---|---|
"84% of software projects fail" | 16.2% hit the original estimate exactly; the rest varied in ways the report calls failure but a client might not |
"This proves software estimation is impossible" | It proves 1994-era projects in this specific survey deviated from their original guesses often — a narrower claim |
"The industry hasn't improved since 1994" | Later CHAOS editions changed their own definitions repeatedly, per Eveleens and Verhoef, making trend comparisons across years unreliable |
"A late or over-budget project is automatically a bad one" | Not supported — the report's definition can't distinguish 'shipped something worse than expected' from 'shipped something better, just later' |
Why the real problem survives the criticism anyway
None of this means scope discipline doesn't matter. It means the 16% figure is the wrong tool for arguing that it does. The actual mechanism by which a project eats you alive doesn't need a 1994 survey to explain it: you scope the full solution first, produce a number, and then discover the number is too big — for the client's budget, for your own time, or for the deadline everyone agreed to before anyone had actually designed anything. By the time that mismatch surfaces, you're already committed, and cutting scope after commitment reads as failure even when it's the right call.
The reversal: appetite instead of estimate
Basecamp's Ryan Singer, in Shape Up, names the fix precisely by naming the order of operations that causes the problem. An estimate starts with a design and ends with a number: you figure out what to build, then find out how long it takes. An appetite starts with a number and ends with a design: you decide how much time a problem deserves, then design the smallest thing that solves it inside that boundary. Same two ingredients, reversed order, and the reversal is the whole trick. works through the operations side of this in more operational detail. The XenGrowth resource library works through the operations side of this in more operational detail.
An estimate begins with a design and ends with a number. An appetite begins with a number and ends with a design. — Ryan Singer, Shape Up
This matters because it changes what "no" looks like during scoping. Under the estimate model, the only way to hit a tight budget is to argue the number down after the design is already fixed in everyone's head — which reads as cutting corners, because in a sense it is. Under the appetite model, the constraint is set first and the feature that doesn't fit inside it was never promised, so leaving it out isn't a concession, it's the plan working as designed. There's a worked example of turning an appetite into a number a client can actually sign in how to price a fixed-scope automation project.
Estimate-first scoping | Appetite-first scoping |
|---|---|
Design the full feature, then find out the cost | Set the cost, then design the feature that fits it |
Cutting anything after the fact reads as a broken promise | What doesn't fit was never promised, so cutting it isn't a break |
The number is a discovery, and often a bad surprise | The number is a decision, made deliberately before design starts |
Scope grows to fill however much time is available | Scope is bounded by a fixed window, forcing real prioritization |
What this looks like on a real engagement
Ask the appetite question first, out loud, in the scoping call: how much time or money does this problem actually deserve, independent of what a full solution might cost? Clients almost always have an implicit number in mind even when they've never stated it
Write down what's explicitly out of scope, not just what's in. A one-line 'this does not include X' is worth more than three paragraphs describing what's included, because it's the sentence you point back to later
Design the smallest version that solves the real problem inside the stated appetite, and present that as the plan — not as a compromise from some larger version nobody agreed to pay for
Treat any mid-project addition as a new appetite decision, not an extension of the old one. "That's a separate scope, here's roughly what it would cost" keeps the original boundary intact
Revisit the appetite once, briefly, at roughly the halfway point. Shape Up's own practice is to kill or radically cut projects that are eating their time budget without a clear path to done, rather than letting them run past the boundary quietly
The three places scope actually leaks
Scope rarely blows up in one dramatic moment. It leaks in three small, specific places, and each one has a different fix. The first is discovery: the client describes the problem in a sentence, you hear a much bigger project than they meant, and nobody notices the gap until the invoice. The fix is restating the scope back in writing before work starts, in language boring enough that disagreement would be obvious immediately rather than three weeks in.
The second is mid-project drift, where a dozen individually reasonable small additions accumulate into a project that's twice the size nobody agreed to pay for. Each one alone looks too small to negotiate, which is exactly why they need to be logged and totalled rather than absorbed silently — a single running list, visible to the client, turns invisible drift into a visible number. On AI agents and marketing automation specifically, is worth reading. On AI agents and marketing automation specifically, XenGrowth on AI agents and marketing automation is worth reading.
The third is the handoff gap: the point where the person who scoped the work isn't the person delivering it, and the appetite that was set in a sales conversation never makes it into the document the engineer actually works from. This is the leak the appetite framing is most useful for closing, because 'here is the number we set and why' travels through a handoff far better than an unstated assumption does.
When you don't get to set the appetite
A lot of engineers scoping client or internal work don't have the authority Basecamp's own product teams have — the budget or deadline is handed down, not negotiated. The appetite framing still helps here, just in reverse: instead of setting the number, you're being handed one, and your job becomes translating it explicitly into what fits and what doesn't, rather than silently trying to deliver an unstated full-scope version inside a budget that was never sized for it. The failure mode this avoids is the worst one in scoping — not a disagreement about scope, but a shared illusion that everyone agreed to the same scope when nobody ever said it out loud.
It also helps to say what appetite-based scoping is not. It isn't a way to avoid ever giving a client a number — clients still need a price, and this post's companion piece on fixed-scope pricing covers that directly. It isn't a license to under-deliver either; a solved smaller problem beats an unsolved larger one, but 'smaller' still has to mean something the client actually needed, not whatever was easiest to finish inside the window. And it isn't unique to six-week cycles — Basecamp's specific cadence is one implementation of the idea, not the idea itself. The part worth taking is the ordering: decide the boundary, then design inside it, rather than designing first and discovering the boundary was already crossed. covers the AI search, GEO and discovery side of this. XenGrowth on AI search, GEO and discovery covers the AI search, GEO and discovery side of this.
The honest caveat here: there is no controlled study proving appetite-based scoping outperforms estimate-based scoping across a large sample of real projects. What exists is a well-documented internal methodology from one company, a widely repeated but methodologically contested industry statistic, and the logical argument connecting them. That's not nothing, but it's not a settled science either, and pretending otherwise would be exactly the kind of overreach this post is arguing against in the CHAOS report itself. On operational scoping at a larger scale, is a useful complement to this argument.
Scope discipline isn't a statistic you can quote your way into. It's a habit of deciding the boundary before you fall in love with the design, and defending that boundary once the project is underway and everyone involved has quietly forgotten it was ever agreed to.
Further reading from XenGrowth
Where this work meets go-to-market
Setting the boundary before the design starts matters just as much on the commercial side of a project. publishes operator guides on scoping and pricing that work.
Further reading from XenGrowth
Where this work meets go-to-market
covers the go-to-market side of project scoping, which this piece deliberately leaves alone.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
XenGrowth's operator guides covers the go-to-market side of project scoping, which this piece deliberately leaves alone.
Five questions on the actual research behind the scoping statistics people repeat, and the alternative to estimating that this post argues for.
