Why AI project scopes go wrong
AI projects are unusually easy to scope badly. The objective is written as an aspiration (“use AI to improve invoice processing”), acceptance is a demo on hand-picked examples, data access is assumed rather than agreed, and nobody is named to own the system afterwards. When the work is delivered, the buyer and supplier discover they had different definitions of done.
The template above forces the decisions that prevent that. It works for any supplier, including me.
The sections that matter most
Objective. One or two sentences about what changes in the business. If it contains “improve”, “enhance” or “optimise” without a number, the tool flags it.
Out of scope. For AI work, the most important exclusion is usually automated decisions: does a person review every output before it is acted on? Then input types not covered, adjacent systems that will not change, and support after handover.
Acceptance criteria. The heart of the document. Good criteria for AI work have four parts:
- An evaluation set agreed before the work starts: real inputs, correct outputs, labelled by your team.
- A threshold on that set, stated as a number.
- Non-negotiable checks that are pass or fail regardless of the threshold: human review in place, data stays in your environment, no personal data in logs.
- A named person who runs the check and signs off.
Dependencies and access. What you provide and by when. Access delays are the most common cause of slipped milestones, and listing them makes the dependency visible to both sides.
Change process. Pre-filled with a sensible default: changes requested in writing, the effect on time, cost and acceptance stated, and nothing started until both owners agree.
Handover owner. The person in your organisation who owns the system afterwards.
Illustrative example
Illustrative example, built into the tool’s placeholders; not a client project. For supplier invoice extraction, the acceptance criteria read:
- Field-level accuracy of at least 97% on the agreed 300-invoice evaluation set, measured by our AP lead
- Every extracted invoice is shown for human review before approval
- No invoice data leaves our Azure tenancy
- Runbook used successfully by our engineer to reprocess a failed batch
The first is a threshold on an agreed set, with a named checker. The second and third are non-negotiable controls. The fourth tests the handover, not just the software. Together they define done in a way both sides can verify.
Assumptions and limitations
The template produces a scope document, not a contract. Pair it with your organisation’s contract terms and legal review. It does not tell you whether a threshold is achievable; agree that with the supplier, ideally after a short baseline on your own data. The warnings are simple pattern checks, such as no number in the acceptance criteria. Clearing them does not prove the scope is complete. For regulated workflows, have the people accountable for compliance read the scope before it is signed.
What to do next
If you are unsure whether to buy a scoped outcome or an engineer’s time, use the engagement comparison. Supplier and contracting information for working with me is on the procurement page, and the engagement models, including scoped delivery with acceptance criteria, are on engagement models and pricing.
If the project is a pilot, agree in advance how it will be judged with the pilot scorecard. If the handover section is the part you are least sure of, see AI system handover. To have me quote against your scope, press “Send this to Dipankar as a brief”: it fills in the form below for you to check and submit.