Where AI delivery speed comes from

Clients ask for speed and brace for the catch. They assume “fast” means skipped tests and a prototype dressed up as production, so they negotiate for safety: a longer planning phase, a thicker up-front spec. Those defences are pointed at the wrong risk. The delivery record ties failure to project size, and the wreckage of big projects is full of finished, signed-off features that nobody ever used.

Typing was never the expensive part of software. The money goes on direction: teams spend months, sometimes years, building a confident answer to a question nobody had verified, then spend more time discovering the answer was wrong. Speed comes from shortening the gap between placing that bet and learning how it landed.

The bigger the bet, the worse the odds

The intuition says a large, carefully planned project is safer than a series of small ones. It is almost exactly backwards. The Standish Group’s CHAOS data, which tracks project outcomes by size, is blunt about it: small software projects come in successful about 61% of the time, while the largest (“grand”) projects succeed only 6% of the time and fail outright 43% of the time.¹ Size, in their words, has been the single most important factor in how a project resolves, and the larger the project, the less valuable the return.¹

How a big project misses matters as much as whether it misses. Across a sample of 1,471 IT projects, the average cost overrun was 27%, but that average hides a fat tail. One in six projects was a “black swan” with an average cost overrun of 200% and a schedule overrun of almost 70%.² Later work on a much larger sample of 5,392 projects found cost overruns follow a power-law distribution, which means managers who reason about averages are quietly underestimating the chance of a catastrophic one.³

The average cost overrun is 27%. For one project in six, it is 200%.

Most of what gets built is never used

Even when a large project ships, much of what it shipped sits idle. In a Standish analysis, roughly 64% of features were rarely or never used (about 45% never, 19% rarely), while only around 20% were often or always used.⁴ That figure deserves a caveat: it came from a study of four internal applications, so treat it as suggestive rather than a law of nature.⁴ But the direction holds, and Standish’s own later research restates the point plainly: most features and functions of software are not used, and those extra features add cost, risk, and quality burden without adding value.⁵

Count what each of those idle features cost. Someone specified it, designed it, built it, reviewed it, tested it, and documented it, and someone else is maintaining it now. That is pure waste: work that consumed a quarter and returns nothing. The commitment came from the up-front spec. It locked in answers months before anyone could watch them fail.

Rework is the tax you pay for finding out late

The second cost of building the wrong thing is fixing it once it is wired in. Boehm and Basili’s long-standing finding is that fixing a defect after delivery is often about 100 times more expensive than fixing it during requirements and design; the 100:1 ratio comes from large, critical systems, and for small, non-critical ones it is closer to 5:1.⁶ They also estimate that current projects spend roughly 40 to 50% of their effort on avoidable rework.⁶ A NIST study put a national price on the same dynamic: inadequate software testing infrastructure was estimated to cost the US economy around $59.5 billion a year, with about $22.2 billion of that recoverable through earlier defect detection.⁷

A misjudged feature is a requirements defect, and it sits on the same cost curve: the longer it survives undetected, the more it costs to remove. On a multi-year plan, surviving undetected is the default condition. Nobody can catch a wrong requirement until a user meets the built feature, and the users are years away.

What actually correlates with going fast

If speed came from cutting quality, the fastest teams would be the least stable. The data says the opposite. In the 2019 Accelerate State of DevOps research, elite delivery teams deployed 208 times more frequently than low performers, with lead time from commit to deploy 106 times faster; they were not paying for it in stability either, recovering from incidents 2,604 times faster with a change failure rate 7 times lower.⁸ Elite teams deploy on demand, multiple times a day, with lead times under a day; low performers deploy somewhere between monthly and twice a year, with lead times measured in months.⁸

The mechanism is batch size. A problem shipped inside a one-week change is a week of work to understand and reverse. The same problem inside a one-year change is buried under a year of entangled decisions. Frequent small releases look reckless from the outside. The Accelerate numbers say otherwise: the teams that release most often are the same teams that recover fastest and fail least.

How we translate this

Everything in our method follows from one reading of the numbers above: the cost of a mistake is set by how long it goes undetected. So we run short loops against the client’s real workflow rather than a slide about it.

1. 01

   Immerse in the real work. We embed and watch the actual workflow before proposing anything. The features nobody uses get designed in conference rooms, far from the task.

2. 02

   Spot the one bet worth making. We look for the narrowest slice that, if it works, changes how someone’s day goes: one workflow, end to end, governed from the first commit. We do not open with a platform build or a roadmap.

3. 03

   Execute against reality, fast. We put that slice in front of real users in days, on onshore infrastructure with row-level isolation and zero retention from the start. There is no later governance phase waiting to slow us down; governance is part of what ships.

4. 04

   Let the loop correct the bet. Real usage tells us what to keep and what to drop. A wrong call surfaces inside a week, while it is still cheap to unwind.

None of this is rushing. We are not skipping the work that makes a system safe to own; the engagement ends with a documented, governed system the client runs without us. The cut falls on the speculative features and on the grand plan that the data says will overrun and underdeliver. Fast delivery involves no heroics, only the discipline to find out, before the money is spent, what was never going to ship.