Scoping your first AI project: readiness, the variables that set price and time, and how to choose

What scoping is for

Scoping turns an idea into a decision you can hold someone to: one job, one success measure, one owner, a known list of systems, and a price and timeline that follow from those choices. It is also the cheapest moment to drop an idea. Google’s Rules of Machine Learning open with two rules that apply just as well to language models: do not be afraid to launch without machine learning, and design your metrics first. If a form, a rule or a better process would do the job, scoping should say so.

NIST’s AI Risk Management Framework makes the same point from the risk side. Its Map function comes first: understand the context, the intended purpose and the people affected before anything is built or measured.

Terms used in this guide

• Job: the task the system will do, described the way the people who do it today would describe it.
• Baseline: how the job performs today, in volume, time or errors, measured before the build.
• Write action: anything the system changes outside itself, such as a record update, a message sent or a payment.
• Human checkpoint: the point where a person reviews, approves or takes over.
• Pilot: a limited release to real users or real work, with a decision date for keeping, changing or stopping it.

Run the readiness checklist

The checklist at the top of this page covers five areas. Go through it with the people who do the work, not only with their managers, and count “not sure” as a no. Each area names one blocker. If any blocker applies, fix it before scoping a build, or scope a short discovery step whose only output is the missing piece: a written process, an agreed source of truth, an owner with time, or access to the system that matters. Gaps that are not blockers become line items in the scope, because someone will have to close them during the build.

The scope variables that move price and timeline

In the projects we scope, the choices below move effort far more than the choice of model. Each row is a dial. Turning one to the right is often justified, but it should be a decision, not something that drifts in during the build.

To bring a quote down, move rows to the left rather than lowering the quality bar. A first release that reads from one system and drafts replies for a person to send is cheap to build, quick to test and easy to switch off, and it produces the evidence for the next row to move. Our own published prices and engagement models are on the pricing and engagement pages; any vendor should be able to tell you which rows drive their estimate.

Choose the first project with a rubric

Most teams have more candidate ideas than they can build. Score each one from one to three on the six criteria below, with the same people who ran the checklist. The use-case library on this site has a quick four-question selector for the tasks we build most often; this rubric is for your own list, and adds the questions that decide whether a first project can be judged fairly.

Two rules sit on top of the totals. A candidate that scores one on owner or on contained mistakes is not a first project, whatever its total: without an owner nobody can judge it, and with uncontained mistakes the first errors are expensive. And when two candidates tie, choose the one whose mistakes are easier to undo.

Worked example: three candidates scored

An illustration with Sample data, not a client engagement. An online training company lists three ideas.

1. The help-centre assistant goes first. Its scope stays on the left of the variables table: one source, read-only, the website only, one language, sampled review and a short evaluation set.
2. Invoice extraction goes second, once the accounting system’s test environment is available and the finance lead can review a weekly sample.
3. Outbound voice calls are not a first project. Mistakes reach prospects directly, the rules on automated calls and consent need checking per market, and two systems would need writes from day one.

Write a one-page scope brief

The brief is what you send to whoever builds the project, whether that is your own team, us or another vendor. If a line cannot be filled in, that is the next thing to resolve, not something to leave to the build.

# Scope brief: <project name>

Job:              <one sentence, in the words of the people who do it today>
Users:            <who uses the output, inside or outside the company>
Baseline today:   <volume, time or error rate, and how it was measured>
Success measure:  <what changes, measured how, decided by when>
In scope:         <channels, languages, content sources, actions>
Out of scope:     <what this release will not do, even if asked>
Systems:          <system> read | write, owner <name>   (one line each)
Data sensitivity: <public / internal / personal / health or financial>
Human checkpoint: <who reviews or approves what, and when>
Evaluation:       <how many cases, written by whom, reviewed by whom>
Owner:            <name, hours per week for the first month>
Switch-off:       <how the system is turned off, and who can do it>
Decision date:    <when you will decide to keep, change or stop it>

Questions to ask whoever builds it

• Which rows of the scope-variables table drive most of your estimate?
• What will you need from our team each week, and from whom?
• What is the first thing real users or real work will see, and when?
• How will we know it works: which cases, which metric, which baseline?
• Whose accounts will the models, hosting and data sit in?
• What is explicitly out of scope, and what would adding it later involve?
• How do we switch it off, and what happens to the work in flight?