All stories

Scoping an AI project: define what it must prove

Ask how to scope an AI project and most of what you will find describes how to plan one: workshops, maturity assessments, a roadmap with swim lanes. Scoping is a different act. A scope is a falsifiable claim: this system, applied to this workflow, will move this number, and here is the date we check. Most AI projects that fail were already dead at scoping; the code just took months to find out.

So the method fits in a sentence: define what the project must prove, to whom, by when, before anyone writes a line. Everything below is the practice of holding that line.

One workflow, one metric, one owner

The workflow must be a real process that exists today, with volumes and a current cost. Not a theme ("customer service") but a slice ("first-response drafts for order-status tickets, about 900 a week"). Themes produce platforms; slices produce results.

The metric must be measured before the project starts. Hours per week, error rate, cycle time, backlog age: pick the one the workflow’s economics turn on, and record the baseline now, because without a before, the after is a matter of opinion and the steering meeting becomes a debate club. Baseline discipline is the core of measuring AI ROI without lying to yourself.

The owner must be one named person whose team lives inside the workflow, and who will say, with the numbers in hand, whether it works. Not a sponsor: sponsors fund projects, owners catch them. A project with executive sponsorship and no operational owner has an audience and no landing strip.

If you cannot fill in all three, the project is not scoped, whatever the deck says.

The smallest system that proves value

Scope the thinnest path through the real workflow, running on real data, and resist every enlargement until the claim is proven. Real data from day one is non-negotiable: production samples carry the mess (scans, abbreviations, exceptions, missing fields) that demo data politely omits, and finding the mess in week two is the entire point of a prototype. A first working version on real data should take 2 to 4 weeks; if the plan says a quarter, the scope is too big.

Write the graduation criteria before the build starts: what accuracy, what adoption by the owner’s team, what cost per task would justify going to production. Deciding this in advance, while nobody is attached to the outcome, is what keeps a promising prototype from joining the graveyard between POC and production.

The anti-patterns that sink AI projects at scoping

Platform ambitions. "An AI layer for the whole company" is a scope with no falsifiable claim, and it fails slowly, expensively and without a lesson. Platforms are earned: build the second use case on the first one’s plumbing, not the platform before the first use case.

Six use cases at once. Attention, data access and goodwill are finite; spread across six fronts, none reaches proof. Rank the candidates with explicit criteria and start with the one that scores best, which is rarely the most exciting one, the argument of boring beats impressive.

Success by demo. A demo is choreography: chosen inputs, a rehearsed path, an impressed room. If the exit review is a demo, the project will optimize for the demo, and the workflow will stay untouched. The exit review should be the metric against the baseline, shown by the owner, not by the builders.

Tool-first scope. "We bought the licenses, find something to do with them" inverts the question and produces projects whose only requirement is using the purchase. Workflows first, tools second.

How we scope an AI project on one page

Our scope document fits on a single page, and the constraint is the feature:

  1. The workflow, with its boundaries: what is in, what is explicitly out.
  2. The metric and its measured baseline.
  3. The owner, by name.
  4. Data sources, and who grants access in week one.
  5. Graduation criteria, agreed before the build.
  6. The decision the result triggers: scale it, iterate once with a named change, or stop.
  7. The budget, in weeks, not quarters.

If it does not fit on one page, the scope is not finished, and the build will finish it for you at ten times the price.

One last defense of the stop outcome. Killing a prototype in week four, for a stated reason, against pre-agreed criteria, is scoping working exactly as designed, and it is dramatically cheaper than the alternative: the zombie pilot that nobody uses and nobody dares to end. Teams that stop cleanly get to try again with their credibility intact.

Scoping is where our custom AI engagements always begin, before any commitment to build, and the first working session usually produces that one page. If a vendor is willing to start without one, that tells you something too.