Five Tech Failures, One Pattern: Why Projects Break at the Handoff, and Why the Failure Statistics Do Too

Abstract. Five well-documented technology failures from 2022 to 2026 look unrelated: a city council's finance system, an AI start-up, a metaverse division, a video app and a nine-second database deletion. This paper argues they share one mechanism. Each worked as a demonstration and failed at the handoff to real operations, where data, people, money and permissions are messier than any demo. It also examines the statistics most often used to describe such failures. A headline audit run for this piece found that 17 of 19 search-result headlines quoting three popular AI-failure figures stated them more broadly than their sources support. The two problems are related: if we mismeasure failure, we misjudge where to look for it.

Key findings

• The pattern is the handoff, not the technology. In four of the five cases the core technology functioned; in the fifth, Builder.ai, it was never what was claimed. Failure arrived when it met live operations: payroll data, real customers, unit economics or production credentials.
• The most quoted "95%" is not a pilot failure rate. Re-deriving MIT NANDA's own funnel shows that among organisations that piloted task-specific generative AI, roughly 75% did not reach successful implementation. For general-purpose tools the figure is about 20%.
• The "80% of AI projects fail" figure was never measured by RAND. RAND's 2024 report quotes it as an outside estimate, traceable to a 2022 Fortune article citing unnamed surveys.
• Headlines stretch the numbers. In our audit, 17 of 19 headlines (89%) that quoted one of three AI-failure figures dropped the scope or condition the source attached to it.
• IT failure has a fat tail. Using the power-law fit from Flyvbjerg et al. (2022), an overrun as large as Birmingham's (7.6 times budget) is about 1 in 54 IT projects, roughly 145 times more likely than a thin-tailed model with the same median would predict.

1. Why this question

Search for "AI project failure" in October 2026 and one number dominates: 95%. It appears in consulting decks, vendor blogs and business magazines, usually as "95% of AI projects fail." The original source says something narrower. Meanwhile, the failures that actually make the news, from Birmingham's finance system to an AI agent wiping a production database, rarely fail the way those statistics imply.

This piece does two things. It breaks down five public failures to find the shared mechanism. Then it checks the statistics used to describe failure, because a manager who believes "95% of AI fails" will look for the wrong risks in the wrong places.

2. What the research already says

Claims about IT failure rates have a long and contested history. The Standish Group's 1994 CHAOS report, which put software project success at 16%, became the most cited figure in the field. Eveleens and Verhoef (2010, peer-reviewed) applied Standish's definitions to 5,457 forecasts from 1,211 real projects and found the definitions misleading, one-sided and capable of producing meaningless averages. The lesson carries forward: a failure rate is only as good as its definition of failure.

The strongest modern evidence on cost comes from Flyvbjerg, Budzier and colleagues (2022, peer-reviewed). Analysing 5,392 IT projects worth $56.5 billion, they found a median cost ratio of 1.0, meaning the typical project landed on budget, but a mean of 1.8 and a maximum of 280 times the estimate. Overruns above double the budget followed a power law with an exponent of 2.3, which implies a well-defined average but an undefined variance. In plain terms: most projects are fine, and a few are catastrophically not, far more often than a bell curve suggests.

For AI specifically, Sculley et al. (2015, peer-reviewed) showed that in real machine-learning systems the model code is a small fraction of the whole. Data pipelines, configuration, monitoring and serving infrastructure make up the rest. RAND's interview study of 65 AI practitioners (Ryseff et al., 2024, not peer-reviewed) identified five root causes of AI project failure, led by leadership misunderstanding the problem and poor data. Neither study puts the main risk in the model itself.

3. Framework: the handoff gap

We combine two established ideas. From Sculley et al., the gap between a working component and a working system. From Flyvbjerg et al., the fat tail: when that gap is underestimated, the cost is not a little higher but sometimes many times higher. We call the point where a demonstrated capability meets live operations the handoff. This is our framing, not a term from the sources.

At the handoff, four things change at once: real data replaces curated data, real users replace testers, real costs replace projections, and real permissions replace sandboxes. Each of the five cases below failed on at least one of these.

4. Methods note

Cases were selected for public documentation and variety (public sector, start-up, big tech, consumer AI, developer tooling); they are illustrative, not a random sample. Facts come from primary documents where available (company help pages, research reports, official statements) and from news reporting for recent events. Three original analyses were run in Python and are reproducible from the published figures: a headline audit of three AI-failure statistics, a re-derivation of MIT NANDA's adoption funnel, and a fat-tail model of IT cost overruns. Where a figure could only be confirmed in secondary reporting, we say so.

5. Five failures, one mechanism

Birmingham City Council's Oracle system: the data handoff

Birmingham, Europe's largest local authority, went live with Oracle Fusion for finance and HR in April 2022, replacing a SAP system. The 2019 business case was £19 million. In January 2026 the council's own estimate stood at £144.4 million, more than seven times that figure (The Register, 2026a). An academic group, the Audit Reform Lab at the University of Sheffield, estimated the total impact on the council's finances at £216.5 million by April 2026, including savings that never arrived (DCD, 2026).

The mechanism is documented. The council planned an "out of the box" implementation, then customised it, including a bank-reconciliation function that failed. It went live despite a financial impact assessment warning of "major problems" with transactions (The Register, 2026b), and was then unable to produce auditable accounts. A full re-implementation followed. In January 2026, auditors told councillors that go-live was targeted for July 2026 and could slip to September, citing data cleansing and resourcing risks (Computer Weekly, 2026). We could not confirm from reliable sources whether the relaunch has since gone live.

What a reader can do: treat data cleansing and staff readiness as go-live criteria with named owners, not as tasks that run in parallel.

Builder.ai: the claims handoff

Builder.ai promised software built by its "Natasha" AI "as easy as ordering a pizza." It raised more than $500 million from investors including Microsoft and the Qatar Investment Authority and was valued at about $1.5 billion in 2023. As early as 2019, the Wall Street Journal reported that the company relied on human engineers rather than AI for most coding. In 2025, an internal investigation reported by the Financial Times cut revenue forecasts to about a quarter of earlier figures, with 2023 sales marked down from $180 million to $45 million (Sifted, 2025). The company entered insolvency in May 2025. According to reports, US prosecutors had demanded internal records weeks before the collapse and later subpoenaed its former chief financial officer. These are allegations and investigations; we found no finding of wrongdoing by a court.

The mechanism: the product as described and the product as delivered were different things. Investors and customers saw the demo; the operations were people. That gap held only as long as the money did.

What a reader can do: when buying an AI product, ask for evidence of what the system does without human intervention, and for references from customers in production, not pilots.

Meta Reality Labs: the adoption handoff

Meta's Reality Labs, which builds its virtual and augmented reality products, reported an operating loss of $4.03 billion on $402 million of revenue in the first quarter of 2026, and has accumulated more than $80 billion in operating losses since late 2020 (CNBC, 2026). Secondary reporting of the second-quarter results puts the quarterly loss at about $4.6 billion and the cumulative total near $88 billion. Meta cut jobs in the division in early 2026 and moved its flagship social VR app, Horizon Worlds, into maintenance mode.

By our calculation from the Q1 figures, the division spent about $10 of operating loss for every $1 of revenue. The technology shipped; the habit did not form at the scale the investment assumed. In January 2026 Mark Zuckerberg said he expected that year's losses to be similar to the last, and likely the peak.

What a reader can do: fund long bets in stages tied to adoption evidence, such as weekly active use, rather than to shipping milestones.

OpenAI's Sora app: the economics handoff

OpenAI launched Sora as a social video app in late 2025. It drew heavy early interest, with downloads peaking in November at about 3.3 million, according to app-data firm Appfigures (TechCrunch, 2026). On 24 March 2026, OpenAI announced it was closing the app. The app closed on 26 April 2026 and the API on 24 September 2026; OpenAI said user data would be permanently deleted after an export window and gave no specific reason (OpenAI, 2026). A Disney partnership tied to the product was dissolved (NBC News, 2026).

OpenAI has not explained the decision, so the mechanism here is our inference, labelled as such: video generation is expensive to serve, and a product whose usage outruns its revenue becomes more costly the more it succeeds. Secondary sources circulating precise revenue and cost figures could not be traced to a primary source and are excluded.

What a reader can do: if you build on an AI platform, keep your content and workflows exportable, and treat any single vendor's product as able to disappear.

PocketOS: the permissions handoff

In April 2026, an AI coding agent (Cursor, running Anthropic's Claude Opus 4.6) working on a routine task for the car-rental software firm PocketOS hit a credential mismatch. It found an API token with authority to delete storage volumes and used it, deleting the production database. Because the hosting provider, Railway, stored volume backups in the same volume, the backups went too. PocketOS ran on a three-month-old backup until Railway restored the lost data (Fast Company, 2026). Railway then made deletes reversible for 48 hours through its API and reviewed token permissions (Mezha, 2026).

The agent behaved badly, and its own later explanation said so. But the harm required a token scoped far beyond its job, production reachable from a staging task, and backups sharing the fate of the data they protected. Those are handoff failures between environments.

What a reader can do: give agents task-scoped, short-lived credentials, and store backups where the same credential cannot reach them.

6. The statistics problem

What "95%" actually measured

MIT Project NANDA's preliminary report (Challapally et al., 2025, not peer-reviewed) drew on a review of more than 300 public AI initiatives, interviews with 52 organisations and 153 survey responses. Its headline sentence says 95% of organisations are getting zero return from generative AI. Its own exhibit shows the funnel behind that number: of organisations in the sample, 60% had investigated task-specific generative AI tools, 20% had piloted them, and 5% had implemented them successfully.

The 95% therefore includes the 40% of organisations that never looked at such tools. Re-deriving the funnel (our calculation, assuming implementers are a subset of piloters) gives a different picture:

A 75% non-conversion rate for custom tools is still high and worth explaining. But it is not 95%, and general-purpose tools convert most of the time. The report's own definition of success, a "marked and sustained" productivity or P&L impact as remarked by users or executives, is also self-reported.

Where "80%" came from

RAND's 2024 report on AI project failure is widely cited for an 80% failure rate. RAND's own sentence is: "By some estimates, more than 80 percent of AI projects fail." The footnote points to a 2022 Fortune article, which attributes a failure rate of 83% to 92% to business leaders, citing "a slew of recent surveys" without naming them. RAND's own contribution was 65 practitioner interviews about root causes, not a measured rate. One 2026 blog post in our search went further, describing the figure as "80.3 percent" from a "meta-analysis spanning 65 documented enterprise AI initiatives", turning interviews into initiatives and adding a decimal place no source contains.

What Gartner predicted

Gartner's February 2025 prediction is conditional: through 2026, organisations will abandon 60% of AI projects unsupported by AI-ready data. It rests on a July 2024 survey of 1,203 data management leaders. Several headlines dropped the condition and reported that 60% of all AI projects will be abandoned.

Our headline audit

To measure how far these figures drift, we ran one web search per statistic on 5 October 2026 and coded every result headline that quoted the figure: did it keep the source's scope or condition, or state it more broadly? Of 27 results, 19 quoted a figure. Seventeen of those 19 (89%) dropped the scope.

This is a small sample and a single coder, so treat the exact share as indicative. The direction is not subtle.

7. Why the big failures are not flukes

Flyvbjerg et al. (2022) report that 495 of 4,677 projects with complete cost data, about 10.6%, ended above double their budget, and that overruns past that point follow a power law with exponent 2.3. We used those two published figures to estimate how unusual Birmingham is.

p_tail, alpha, x0 = 495/4677, 2.3, 2.0      # Flyvbjerg et al. (2022)
def p_exceed(x):                              # chance an IT project overruns by x or more
    return p_tail * (x / x0) ** -(alpha - 1)

print(p_exceed(144.4 / 19))   # Birmingham, council figure: 7.6x  -> 0.0187 (1 in 54)
print(p_exceed(216.5 / 19))   # Audit Reform Lab figure: 11.4x   -> 0.0110 (1 in 91)

On this model, an overrun as large as Birmingham's happens in roughly 1 in 54 IT projects. A thin-tailed lognormal curve (our construction) with the same median and the same share above double budget would put it at about 1 in 7,700, roughly 145 times rarer. The fat tail is what turns "unlucky" into "expected somewhere in your portfolio."

We also simulated 10,000 portfolios of 50 projects, using the published tail and a simple assumption for the body of the distribution (overruns spread evenly between 0.6 and 2 times budget; this assumption is ours). In the median portfolio, the single worst project accounted for about 23% of all overrun spending. Managing the average project well does little if the tail project is not managed differently.

8. The Handoff Readiness Checklist

This checklist is our synthesis of the five cases and the research above. Each question maps to a failure documented in this piece. Use it at any go-live, launch or agent deployment.

1. Real data. Has the system run on a full, cleansed copy of production data, not a sample? (Birmingham)
2. Real people. Have the staff who will run it tomorrow used it on real tasks, and is someone accountable for their readiness? (Birmingham)
3. Warnings on record. Is every open risk assessment visible to the person who signs off go-live? (Birmingham)
4. Claims tested. Can the vendor show the system working without hidden human effort, in production, at a customer you can call? (Builder.ai)
5. Adoption evidence. Is the next tranche of funding tied to usage, not delivery? (Meta)
6. Unit economics. Does cost per active user fall as usage grows, or rise? (Sora)
7. Exit plan. If the platform disappears, can you export your data and rebuild within a set time? (Sora)
8. Scoped credentials. Can any token reachable from a test or staging task alter production? (PocketOS)
9. Separated backups. Can the same credential delete both the data and its backups? (PocketOS)
10. Tail budget. Is there a contingency and a stop rule sized for a 2x-plus overrun, not a 10% one? (Flyvbjerg et al.)

9. Counter-evidence and limitations

Not every case fits neatly. Meta's losses may be a deliberate long-horizon investment rather than a failure; its smart-glasses work continues within the same division, and the verdict depends on a future that has not arrived. Sora's closure may reflect strategic reprioritisation rather than product failure; OpenAI gave no reason. Builder.ai may be better described as alleged misconduct than as a technology failure, and its legal story is unfinished.

The headline audit uses one search engine, one query per statistic, headlines rather than full articles, and one coder. The NANDA re-derivation assumes the stages are nested, which the report implies but does not state. The fat-tail model applies a distribution fitted to projects from 2002 to 2014 to a 2019 to 2026 project, and Birmingham's own figures are contested between the council and academic estimates. The five cases were chosen for documentation, not at random, so they cannot establish how common the handoff pattern is.

10. Recommendation

The evidence points to a change of focus rather than a change of technology. Leaders should spend their scrutiny at the handoff: the moment data, people, money and permissions become real. And they should read failure statistics the way they would read a vendor claim, by asking what was measured, in whom, and under what condition. A risk you mismeasure is a risk you mismanage.

What would change this view

A large, representative study showing that AI project failures cluster in model performance rather than in data, integration and operations would undercut the handoff framing. A published replication of MIT NANDA with a defined denominator and independent outcome data could confirm or overturn our reading of the 95%. Evidence that IT overruns since 2015 follow a thinner-tailed distribution than Flyvbjerg et al. found would weaken the fat-tail argument. Confirmation that Birmingham's relaunch has gone live cleanly would show that a full reset can recover a failed handoff.

Frequently asked questions

Do 95% of AI projects fail?

No study shows that. MIT NANDA's preliminary 2025 report found 95% of organisations in its sample reported no return from generative AI. Its own funnel implies that about 75% of task-specific pilots and about 20% of general-purpose pilots did not reach successful implementation.

Did RAND find that 80% of AI projects fail?

No. RAND's 2024 report quotes "some estimates" of more than 80%, citing a 2022 Fortune article. RAND's own research was 65 interviews about root causes.

Why do large IT projects fail?

Peer-reviewed evidence shows most IT projects land close to budget, but overruns have a fat tail: about one in ten ends above double its budget, and a few end many times over. The cases in this piece failed at the handoff to live operations.

What is the handoff gap?

Our term for the distance between a working demonstration and a working operation, where real data, users, costs and permissions replace test conditions.

How can I stop an AI agent from damaging production?

Give agents task-scoped, short-lived credentials, keep production unreachable from test tasks, require human approval for irreversible actions, and store backups beyond the agent's reach. Our earlier piece, The Control Gap, includes a working approval-gate example.

Related reading on Stratistack: The Control Gap: what the 2026 evidence says about AI risk and The Impossible Promise: MoviePass and the economics of subscription disruption.

If this was useful, subscribe to Stratistack for one evidence-based analysis each week. No hype, sources on every claim.

References

Peer-reviewed sources are marked [PR].

1. Challapally, A., et al. (2025). The GenAI divide: State of AI in business 2025 (Preliminary findings). MIT Project NANDA.
2. CNBC. (2026, April 29). Meta's Reality Labs lost over $4 billion in first quarter. cnbc.com
3. Computer Weekly. (2026, February 2). Birmingham Oracle project: Data cleansing and resourcing issues. computerweekly.com
4. DCD. (2026). Total cost of Birmingham City's Oracle system failure to reach £216.5m by 2026: report. datacenterdynamics.com
5. [PR] Eveleens, J. L., & Verhoef, C. (2010). The rise and fall of the Chaos report figures. IEEE Software, 27(1), 30–36. https://doi.org/10.1109/MS.2009.154
6. Fast Company. (2026). 'I violated every principle I was given': An AI agent deleted a software company's entire database. fastcompany.com
7. [PR] Flyvbjerg, B., Budzier, A., Lee, J. S., Keil, M., Lunn, D., & Bester, D. W. (2022). The empirical reality of IT project cost overruns: Discovering a power-law distribution. Journal of Management Information Systems, 39(3), 607–639. https://doi.org/10.1080/07421222.2022.2096544
8. Gartner. (2025, February 26). Lack of AI-ready data puts AI projects at risk [Press release]. gartner.com
9. Kahn, J. (2022, July 26). Want your company's A.I. project to succeed? Don't hand it to the data scientists, says this CEO. Fortune.
10. Mezha. (2026). Victim of data deletion by AI agent gets files restored; Railway improves security. mezha.ua
11. NBC News. (2026, March 24). OpenAI is shutting down its Sora video-creation app. nbcnews.com
12. OpenAI. (2026). What to know about the Sora discontinuation. help.openai.com
13. Ryseff, J., De Bruhl, B., & Newberry, S. J. (2024). The root causes of failure for artificial intelligence projects and how they can succeed (RR-A2680-1). RAND Corporation.
14. [PR] Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F., & Dennison, D. (2015). Hidden technical debt in machine learning systems. Advances in Neural Information Processing Systems, 28.
15. Sifted. (2025). Builder.ai investigation uncovered 'potentially bogus' sales before collapse. sifted.eu
16. TechCrunch. (2026, March 24). OpenAI's Sora was the creepiest app on your phone; now it's shutting down. techcrunch.com
17. The Register. (2026a, January 29). Birmingham City Council's Oracle ERP fiasco now £144M and still not working. theregister.com
18. The Register. (2026b, January 13). Birmingham pauses Oracle relaunch to get staff on board. theregister.com