AI Project Rescue
Your AI project failed. The next one shouldn’t have to be an act of faith.
We diagnose why it failed, then rebuild one component of it at our own risk: if the rebuild misses the success metric we agree in writing, you pay nothing for the build. Proof first, fees after. That is the whole offer.
You are not the outlier. You are the norm.
By the estimates RAND assembled from prior research and 65 expert interviews, more than 80% of AI projects fail — roughly twice the rate of IT projects without AI. S&P Global’s 2025 survey found the share of companies abandoning most of their AI initiatives jumped from 17% to 42% in a year. BCG puts the share of companies achieving AI value at scale at about 5%. The numbers vary because they measure different things — we take them apart here — but the direction is not in dispute.
A failed project is not evidence that AI cannot work for you. It is usually evidence of one of six specific, fixable failure modes.
01
The problem was never defined
Business and technical teams described success in incompatible terms, so the system solved a problem nobody had.
02
The data was not there
The volume, quality or permissions the model needed did not exist — and nobody checked before procurement did.
03
Technology went looking for a problem
The tool was chosen first and the use case retrofitted. Fit was presumed, not established.
04
The demo never survived production
It worked in isolation, then broke against real workflows: approvals, legacy systems, exceptions, people.
05
The problem was too hard for the tools
The use case needed reliability current models cannot give — and no confidence floor was set to catch it.
06
Nobody owned the decision
No named owner, no success metric, no kill criteria, no evidence trail. The governance vacuum: the failure mode we see most.
How it works
Four steps. The risk sits with us.
The diagnosis is free and honest — including when the honest answer is that the project should stay dead.
01
Diagnose
A working session with the people who lived it, plus a structured review of what was built. You get a written diagnosis: which failure mode killed the project, and whether it is rescuable. We tell you plainly if it is not.
02
Scope
One component, defined in writing: the deliverable, the success metric, the timebox. You confirm you intend to continue on normal terms if the metric is met. No metric, no sprint.
03
Rebuild
A time-boxed sprint, governance built in: human approval gates, audit trail, confidence floors. The people who scope it are the people who build it.
04
Decide
Metric met: the work continues on normal commercial terms. Metric missed: you keep the diagnosis, owe nothing for the build, and we part as adults.
We take a small number each quarter.
An at-risk rebuild only works when the conditions for success exist. We can say yes when:
- The project reached at least a proof of concept before it stalled or was abandoned
- An executive sponsor with decision authority will be in the room
- The data the system needs exists and can be accessed
- The failure is recent enough to learn from — within the last 24 months
And we will say no when:
- The data the system needs does not exist and cannot be obtained
- A regulatory or legal constraint prohibits the use case — rebuilding it would be malpractice
- Nobody senior owns the outcome
Saying no is part of the offer. A rescue that cannot succeed wastes your year and our reputation, and we are not in the business of either.
The questions people ask first
Is the rebuild really free?
If the sprint misses the success metric we agreed in writing, you pay nothing for the build — that is the offer, and it is in the scope document, not just this page. If it meets the metric, the work continues on normal commercial terms. We work this way because a rebuilt component is better proof than any brochure.
What counts as 'one component'?
Something with a hard edge: the document pipeline that hallucinated, the triage model nobody trusted, the integration that never shipped, the governance layer that was missing. One workflow, one defined output, one metric. Not the whole programme.
Who owns what we build?
You do. The code, the documentation and the evidence trail are yours whichever way the sprint ends.
Why do you limit how many you take?
Because the same senior people who scope a rescue deliver it. We take a small number each quarter; a rescue we cannot staff properly is a rescue we decline.
Our project failed for governance reasons, not technical ones. Is that in scope?
Especially in scope. The most common failure mode we see is the governance vacuum: no owner, no metric, no evidence. Sometimes the right rebuild is the control layer — approval gates, audit trail, confidence floors — that makes the existing system defensible.
Bring us the post-mortem.
Fifteen minutes. Tell us what was promised, what was built, and where it died. You will leave knowing which failure mode you are looking at — whatever you decide to do next.