Three scoping anti-patterns that kill AI transformation projects

Most AI transformation projects don't fail during development. They fail in the scoping document, weeks before anyone writes code.

We've reviewed hundreds of AI transformation briefs from London and UK teams over the last two years. The projects that ship cleanly almost always have clean scopes. The ones that stall, pivot three times, or die quietly in month four? They share the same three structural problems.

By Uwa Ujam, founder of Autore — we design and ship AI transformation systems for ambitious teams across London and the UK.

Phantom accuracy targets in AI transformation briefs

The brief says: "The system must achieve 95% accuracy."

We ask: "How are you measuring that?"

Silence. Or: "We'll figure that out once we see the data."

This isn't pedantry. Accuracy means nothing without a measurement strategy. 95% accuracy at what? Precision, recall, F1? Against which baseline? On which slice of the data? Measured how often?

A model that's 95% accurate on average cases and 60% accurate on edge cases is a production incident waiting to happen. A model that hits 92% in week one and plateaus there for six months looks like failure, even if 92% was the right target all along.

The worst version of this is when the number comes from a competitor's marketing site or a research paper. Those numbers are cherry-picked, often measured on clean academic datasets, and rarely reproducible in production.

A clean brief names the metric, the test set, the measurement cadence, and the acceptable range. "We need 90-95% precision on invoice line-item classification, measured weekly against a human-labelled holdout set of 500 invoices, with per-category breakdowns." Now we can actually build something.

Deferred success criteria

The brief says: "We'll know it's working when users are happy."

This defers the hard conversation. What does "happy" mean? How do we measure it? What's the threshold?

Vague success criteria feel collaborative in the scoping phase. They're not. They're a way to avoid disagreement by pushing conflict into delivery, where it's ten times more expensive to resolve.

The project starts. The team builds. Three months later, someone says: "This isn't what I expected." The brief didn't lie — it just never committed to anything falsifiable.

We see this most often when stakeholders don't agree internally. The brief smooths over the disagreement with language like "stakeholder alignment" or "iterative refinement". Then the disagreement resurfaces in user testing, or worse, after launch.

A clean brief has success criteria you could, in theory, check on day one. Not because you will, but because the forcing function of "could we check this today?" makes you define terms. "Users are happy" becomes "support ticket volume drops 40% within three months" or "task completion time drops from 12 minutes to under 5".

If you can't define it in the brief, you won't be able to measure it in production.

No exit clause

The brief says nothing about stopping. There's a start date, a delivery date, and a payment schedule — but no defined point where either side can walk away.

The best scoping documents we've seen include a kill switch: a point, usually four to six weeks in, where both parties can stop if the early results don't justify continuing.

This sounds obvious. Almost nobody does it.

Instead, briefs assume the first idea will work. Fixed price, fixed scope, fixed outcome. Then the team is locked into building something it already knows won't hit the target, because stopping means admitting failure and probably not getting paid.

An exit clause forces honesty. If you're promising 90% accuracy, you need to hit 70% in the first phase or the project stops. If you're promising a conversion lift, you need to see 5% in the pilot or you call it.

This protects both sides. The client doesn't pay for a full buildout of a system that won't work. You don't spend three months polishing something nobody will use. And the conversation about what's realistic happens while you can still do something about it.

What a clean brief looks like

A clean brief has six sections, no more:

1. Problem: one paragraph, concrete, with a current-state number.
2. Success criteria: two to four measurable outcomes, with thresholds and timelines.
3. Scope: what's in, what's explicitly out, what happens if we finish early.
4. Constraints: budget, timeline, data availability, compliance requirements.
5. Decision point: the date, the threshold, and what happens if we miss it.
6. Handoff: what we deliver, in what format, and who owns it after launch.

That's it. No vision statements. No alignment decks. No roadmap to 2027. It's the shape we hold ourselves to on every custom AI build.

The brief should be dull. If it's exciting, you're probably over-promising.

This matters because AI projects fail differently from web projects. A web project with vague scope ships late. An AI project with vague scope ships something that technically works but doesn't solve the problem, and no one notices until month six.

If your brief has phantom accuracy targets, deferred success criteria, or no way to stop, stop. Rewrite it. The two days you spend now will save you two months later.

Scoping an AI transformation project and want a second pair of eyes on the brief before it goes out? Talk to us.