A note on the numbers before the tables. We lead with the hard anchors: the Standish CHAOS data on project success, Flyvbjerg and Budzier on cost overruns, the BLS loading factor, and the DORA four-metric framework. Where a figure comes from a vendor's own report, we say so and attribute it to the vendor rather than dressing it up as independent fact. Every dollar figure is in US dollars. Where a source published in another currency, the conversion basis is recorded in the right-hand column so you can redo the sum yourself.
The spine of the task-based argument is here. Small, scoped work succeeds far more often than big-bang projects, and the rare disaster is what bankrupts a budget, not the average.
| Claim used in the book | Source | Where to find it |
|---|---|---|
| Modern projects resolve 29% successful / 52% challenged / 19% failed | Standish Group, CHAOS Report 2015 | infotech.com/agile/CHAOSReport2015-Final.pdf |
| Small projects succeed 61% of the time vs 6% for "grand" projects; size is the dominant driver | Standish Group, CHAOS Report 2015 | same as above |
| Across 1,471 IT projects, average cost overrun 27% | Flyvbjerg & Budzier, "Why Your IT Project May Be Riskier Than You Think," HBR 2011 | arxiv.org/pdf/1304.0265 · ssrn.com/abstract=2229735 |
| One in six IT projects is a "black swan": ~200% cost overrun, ~70% schedule overrun | Flyvbjerg & Budzier, HBR 2011 | same as above |
| 80% of features are rarely or never used; ~12% drive 80% of usage | Pendo, 2019 Feature Adoption Report | go.pendo.io (2019 Feature Adoption Report) |
The Pendo figure is a vendor's own product-analytics report. We quote it as Pendo's and attribute the spec-graveyard point to it directly, not to anyone else.
The five accountabilities aren't ours alone. They map cleanly onto how authoritative role descriptions define the job, which is why the spine holds. The reading below is where the mapping comes from.
| The book's accountability | How public descriptions frame it | Source |
|---|---|---|
| Roadmap & business alignment | "Aligning technology investment with business strategy" | Splunk; edstellar |
| Team performance | Structure, capability and culture of the technical organisation | Splunk |
| Operational reliability | Accountable for system uptime and reliability at scale | edstellar |
| Technical quality | Target architecture, build-vs-buy, security and compliance | Splunk; edstellar |
| Software delivery | Under-emphasised in most public CTO descriptions, which skew to vision | observed across the sources below |
Further reading on the role:
On the fractional model specifically, one vendor describes it as leaning "toward strategic guidance, oversight, and experience while eschewing the leadership role of managing teams." That is the execution gap stated in a fractional provider's own words. Read it as a vendor's framing, which is how we used it.
The KPI scorecard rests on a framework that has held up across a decade of industry research. We use the four metrics as the measurement frame. We do not quote a specific "Nx faster" gap between elite and low performers, because that multiplier wasn't something we could verify against the report itself.
| Used as | Source | Where to find it |
|---|---|---|
| The four key metrics: deployment frequency, lead time for changes, change-failure rate, time to restore | DORA, 2024 State of DevOps | dora.dev/guides/dora-metrics-four-keys/ |
| Conceptual anchor for the four metrics | Forsgren, Humble & Kim, Accelerate | IT Revolution Press, 2018 |
Download the full PDF for free?