Guide to AI project scoping
Write a brief your business and engineering teams can use.
Describe one piece of work from its trigger to an accepted result. That gives business reviewers and engineers a common starting point before they choose models, tools or deployment.
What should an AI workflow brief contain?
Name the task owner, trigger, current process and intended result. Identify the information and systems involved, permitted actions, human decisions and acceptance criteria. Add operating requirements and unresolved questions. Keep the initial brief focused on the work, with technical choices recorded as assumptions until they are assessed.
Use these prompts for the first draft.
Write enough detail for another person to understand the process without sitting beside its current operator.
Owner and purpose
Who owns the work, who uses the result and why does the task need to change?
Trigger and current process
What starts the task? What does a person or existing system do from that point?
Inputs and connections
Which information and systems are required? Who can authorise access, and which sources change?
Result and acceptance
What should exist when the task finishes? Who checks it, and what makes it unacceptable?
Authority and exceptions
Which actions may happen automatically? Which need approval, and what should happen when information is missing?
Operation and open questions
Where must it run, who operates it and what remains unknown about demand, access or dependencies?
A completed example: prepare a service-response draft.
This illustrative brief describes a proposed workflow. It is not a customer case study.
Owner and purpose
The service operations lead owns the workflow. Service staff need a response draft and a clear list of missing information for each request.
Trigger and current process
A new request enters the service queue. Staff currently read it, find the relevant guidance, look up a business record and prepare a reply.
Inputs and connections
Use the request, approved service policies and read access to the relevant business record. The knowledge owner maintains policy content; the system owner approves record access.
Required result
Return an issue summary, the policy reference, a draft response and any missing information. A service specialist reviews the result before sending anything.
Decision boundary
Prepare a draft only. Do not send messages, issue refunds or change account records. Refer missing, conflicting or restricted information to the reviewer.
Acceptance and open questions
Review whether the draft uses the right source and record without inventing facts. Confirm the queue trigger, access permissions, expected demand and how the draft reaches the reviewer.
Separate business decisions from implementation choices.
The business owner should decide what the work is allowed to do and what a useful result means. Engineers assess the model, retrieval, tools and workflow needed to deliver it.
In the example, draft-only operation is a business boundary. Choosing a model or connection method is a technical decision. Record an untested technical choice as an assumption, with a person responsible for resolving it.
Review the brief with the people it depends on.
Ask the task owner, a current operator, the system owner and the intended reviewer to read it. Use these questions to expose missing work.
- Could another team member recognise where this task begins and ends?
- Does each required source have an access owner?
- Is a wrong result distinguishable from a useful one?
- Are approval, failure and handover decisions assigned?
- Does every important unknown have a next action and owner?
Share a description before sharing the data.
For an initial enquiry, describe the workflow and use synthetic examples. Keep customer records, credentials and confidential datasets out of the enquiry form. Agree an appropriate route for any source material needed during scoping.
Questions and answers
No. Define the task and acceptance criteria first. Model choice can then be assessed against the work and operating requirements.
Name one owner for the overall result and record the system, information and approval owners for the individual parts.
Include targets your organisation has agreed and evidence for the current baseline. Mark unknowns for measurement rather than inventing thresholds.
Yes. Keep a versioned record of changed assumptions, scope and acceptance criteria so reviewers know which process they are assessing.