In three decades of published research on the returns from maturity and process improvement programs, there is not one documented case of an organisation losing money.
Not one. The most careful review of real-world returns, published in IEEE Software by Rini van Solingen, examined twenty documented cases of software process improvement and found an average return of roughly seven to one, with a spread from 1.5:1 all the way to 19:1. The worst published outcome was a modest win.
You've sat in the meeting where a number like that gets quoted. Maybe you've quoted one yourself: the five-to-one return, the 35% productivity gain, the slide that makes the maturity uplift program feel like arithmetic. And if a perfect track record across thirty years strikes you as slightly too good, your instincts are working.
Failed improvement programs are real. Practitioners have watched them: the process initiative that consumed a year and changed nothing, the capability uplift that produced documentation instead of performance. They just don't get written up. Nobody submits a conference paper on the maturity program that quietly died; no consultancy publishes the engagement that didn't pay back. The literature isn't a record of what maturity programs return. It's a record of what the survivors returned, curated by people with wins to report.
The headline figures are worse than survivorship-biased; they're old and narrow too. The classic benchmarks (a median return near five to one, annual productivity gains around 35%) trace to a single study of thirteen organisations, software-specific, from 1994. Three decades old, from one industry, drawn from an evidence base that structurally cannot contain a failure. That's what's holding up the arithmetic slide.
The more current evidence is better, and honestly limited. Peer-reviewed research across more than a thousand US hospitals links higher digital maturity to better quality, safety, and patient experience. But the link is correlational: more mature hospitals tend to perform better, which is not proof that maturity caused the performance. More capable institutions may simply do many things well. The same caution applies to any maturity claim your organisation makes about itself.
Why this matters more than it seems
A business case built on borrowed numbers has a property nobody mentions at approval time: it can never be proven right or wrong.
If the program succeeds, the borrowed multiple takes the credit. If it disappoints, there's always an explanation: context, timing, execution, the reorganisation. Without a measured starting point, improvement can't be separated from noise, and failure can always be explained away. A case that can't be proven wrong protects the program instead of the organisation, and somewhere around the third funding renewal, a CFO notices. The cost isn't just the program's credibility. It's the sponsor's.
The honest case
None of this is an argument against investing in capability maturity. It's an argument for writing the case the way the evidence actually permits.
Expect a plausible range, not a headline multiple. The published spread runs from 1.5:1 to 19:1 among the winners alone. Present the range and the conditions, not the average.
Gather your own baseline before the program starts. Current performance, measured, per capability. This is the only evidence that can ever prove your program worked, and it's what makes the program accountable: with a baseline, the work has to earn its next funding round. Be honest about the cost, too. Baselining forty capabilities on performance evidence is a program in itself, so baseline the handful of capabilities your strategy actually depends on first, and accept coarser evidence elsewhere. (Which capabilities those are is a strategy question, not a scoring question: the capability maturity pillar covers how targets get derived from strategic choices.)
Budget for the J-curve. Adopting new process dips productivity before it raises it. A case that promises improvement from quarter one will be reporting excuses by quarter three. Judge results over years.
Say how you'd know it failed. This is the line that separates an honest case from a sales document. Name the indicator, the threshold, and the date at which not seeing movement means stopping. A case that includes its own kill condition is a case a board can trust, precisely because it's the kind the published literature never contains.
Capability maturity is a bet that pays when context, cost, and execution align. It is not a formula. The organisations that get real returns from it aren't the ones that believed the multiple; they're the ones that measured their own starting point and let the evidence argue for the next cycle.
The most credible business case in the room is the one that can say how it would fail. Write that one.