SurfingBear ToolsSurfingBearTools
Skip to content

Home › Blog › Restarting after a failure

Restarting AI adoption after it failed once

The second attempt is harder than the first for reasons of trust, not technology. Budget and organisational attention were already spent once.

Classifying the cause Second attempt Rebuilding trust

The short answer

The first step in restarting is classifying the failure accurately. Most "AI adoption failures" are not AI failures but target-selection failures, data failures or operational failures.

Misclassify the cause and you repeat it. Change the tool while the target process stays the same and the result stays the same.

Classifying the failure — from symptom to cause

Symptom Real cause What to change next time
Nobody used it No integration, or unclear use cases Inside a tool they already use, with three named uses
The output was not usable The target process was unsuitable Move to work with stable rules and consistent input
Review took longer Output format and prompts never fixed Fix the format first, then re-measure
It was confidently wrong Stale or unorganised data Narrow the document scope and restart
Security review blocked it Terms checked too late Move terms checking into candidate selection
We could not prove the benefit No baseline recorded Record the baseline numbers first

Design principles for the second attempt

Halve the scope — Smaller than the first attempt. The purpose of the second is not a big result but a proven one. A small, certain result restores trust.
Choose reversible work — A second failure removes the third chance. Pick low-risk work.
Record the numbers first — Monthly volume, minutes per item, error rate — recorded before starting this time. A benefit you cannot prove is not counted as a benefit.
Publish the stop condition — Announce "if this result does not appear, we stop". That earns trust rather than losing it, because it is a promise not to push indefinitely.
Use the first attempt’s record — What did not work is an asset. Stating "last time the cause was this, and here is what changed" makes approval much easier.

Rebuilding organisational trust

Start by writing the first failure up explicitly. Pass over it quietly and all the organisation retains is "AI does not work here". Documenting the cause turns that into "that approach did not work".

Then a small result. Scope it so something measurable appears within four to six weeks. Returning with another large plan simply overlays the memory of the first attempt.

And report the result in the language of the people who do the work. "Month-end can start two days late and still hit the deadline" travels further inside an organisation than "40% reduction in processing time".

Frequently asked questions

Can we reuse the tool that failed?

If the tool was not the cause, yes. Where the target process or the data was the cause, the same tool produces a different result. But if organisational perception is poor, the same tool carries a persuasion cost.

Leadership will not approve another attempt.

Present a small scope, an explicit stop condition, and the cause analysis of the first failure together. "Last time the cause was this; this time we confirm it against this number within four weeks" passes more often than a budget request.

We have no record of the failure.

You can reconstruct it through interviews: what was tried, where it stopped, why users did not adopt it. Mark it as reconstructed, but write it down.

What if the second attempt fails too?

If the cause is repeatedly in target selection, a process assessment comes before tool adoption. You are most likely skipping the step that establishes which work suits automation.

Diagnose the cause

Find which axis failed

The AX readiness assessment scores work, data, technology and organisation. It shows which axis the first failure came from — and that is where the second attempt starts.

Check readiness