"How to scope an AI project so it doesn't drift"

Most AI projects do not fail in a dramatic way. They drift. The brief was a document-processing workflow; three months in, the team is debating chat interfaces, the demo has sprouted four features nobody asked for, and the original workflow still is not live. This is not a rare misfortune: RAND's research into why AI projects fail found they collapse at roughly twice the rate of ordinary IT projects, and the cause it ranks first is not technology, it is misunderstanding about what the project was for. If you are about to commission AI work, drift is the failure mode most likely to eat your budget, and it is preventable at the scoping stage.

AI work drifts more than ordinary software for a specific reason: the underlying model can plausibly do almost anything. When you build a payments integration, nobody suggests mid-project that it should also write marketing copy. But when a language model sits in the stack, every adjacent capability looks one prompt away. It summarises invoices, surely it could also draft the reply email? Flag anomalies? Answer supplier queries? Each marginal demo is genuinely cheap, so scope expands. Each marginal production feature is not cheap, and that gap is the trap.

The framing I use with clients is one workflow, one metric, one month. It sounds restrictive. That is the point. Restriction at the scoping stage is what lets the build stage move fast, because every "should we also" question has a ready answer: not in this scope.

One workflow means a single process, end to end, with a named start and a named finish. "Process inbound supplier invoices into the accounting system" is a workflow. "AI for the finance team" is not, it is a theme, and themes cannot be finished. If the description does not tell you what triggers the system and what it produces, keep narrowing until it does.

One metric means you agree, before building, how you will know it worked. Percentage of invoices processed without human correction. Minutes from email arrival to posted entry. Support tickets resolved without escalation. The metric should be measurable today, on the manual process, so you have a baseline to beat. If nobody can name the metric, the project is not ready to commission, that is a discovery conversation, not a build.

One month is the timebox. A month is enough to take one well-chosen workflow to production quality, or to discover a genuine blocker while it is still cheap. It also forces honest prioritisation: with four weeks, you spend them on input validation, retries and an eval set for the workflow you have, not on a second workflow. Anything that does not fit becomes a candidate for the next month, which you only commit to once the first has shipped and the metric has moved.

Within that frame, watch for the drift patterns specific to AI work. "While we're at it", the adjacent capability that seems free because the model can demo it. Accuracy chasing, the target creeping from 90 to 95 to 99 per cent without anyone pricing the fact that each point past 95 costs more than the ten before it. Model tourism, switching models mid-build because a newer release topped a leaderboard, resetting your testing to zero. And agent inflation, the request to make a working pipeline "agentic", which usually means adding autonomy nobody can specify and reliability nobody has budgeted for.

None of this means new ideas are bad. Some of the best product insight surfaces once people see a model working on their own data. The discipline is where the ideas go: into a written parked list, reviewed when the current scope ships, never into the current sprint. A parked idea costs nothing. A mid-sprint idea costs the sprint.

A well-scoped statement of work, then, is short. It names the workflow and its trigger and output. It states the metric, the baseline and the target number. It states the timebox. And, the part buyers skip most often, it lists exclusions: the plausible-sounding adjacent features you have explicitly agreed are out. That exclusions list is worth more than any architecture diagram, because it is the document you point at in week three.

If you have an AI project in mind and the scope is still fuzzy, that is normal, it is where nearly everyone starts. A one-hour conversation is usually enough to get from "AI for X" to a workflow, a metric and a month, and you will know quickly whether the project is worth commissioning at all. Get in touch via the contact form at afareed.com.