How to scope an AI project in a week

A one-week scoping process for an AI project — what to map each day, what to evaluate, and how to land on a sensible first build by Friday. The shape we use with every Liverpool client before we write a line of production code.

Most failed AI projects we get called in to rescue failed in scoping, not in execution. The eval set was wrong, the metric was vague, the integration points were missed, the regulatory line was crossed by accident. A disciplined week of scoping prevents almost all of those failures at very low cost.

Here is the version we run.

Day 1: Frame the problem, not the solution

The first day is not about AI. It is about the operational problem you want AI to address. The temptation is to walk into day one with a solution in mind ("we want a chatbot") — resist it. Spend the day with the people doing the work.

Concrete activities for day one:

• Sit with the operations team or fee earners or analysts doing the work today. Watch what they actually do.
• Trace where time, cost and errors accumulate in the current process. Look for the bottlenecks.
• Identify the metric that actually matters — the one that, if it moved, would make this project worth doing.
• Write down what success looks like in operational terms, not technical ones.

End of day one you should be able to state, in one sentence, the operational problem and the metric that has to move. If you cannot, you do not yet know what to build.

Day 2: Define what success looks like

Take the operational problem from day one and turn it into a quantified, measurable target. This is the day the scope gets sharp.

• State the single named metric the project will move. Time saved per case, tickets deflected per week, accuracy on a defined extraction task, hours of analyst time reclaimed — pick one.
• Quantify the target. "Faster" is not a target. "30% reduction in claims processing time per case" is.
• Agree the measurement method. Who measures the baseline? Who measures success? When? Get this in writing.
• Identify what is explicitly out of scope. The list of things the project will not do is as important as the list of what it will.

If multiple metrics are in play, pick the primary one and rank the others. AI projects with three equally-weighted success metrics fail because the team optimises for the wrong one.

Day 3: Check the data and the feasibility

The middle of the week is the technical reality check. The question is not "is this AI problem solvable in theory" — it almost always is. The question is "is it solvable on your data, in your environment, at the quality your business needs".

• Get hold of a representative sample of the actual data the production system will see. Not curated examples. Real data, including the edge cases.
• Build a small evaluation set — 50 to 200 items, with the correct outputs labelled. This is the artifact that decides whether the project works.
• Test the obvious AI approach on the eval set. If it works at 60% accuracy out of the box, you have a build. If it works at 5%, you may have the wrong approach.
• Identify the failure modes — where does the model fall over? Edge cases, format variations, domain-specific terms, low-quality scans, ambiguous inputs.

Questions worth answering on day three

Is the data clean enough? Is there enough of it? Are the labels reliable? Can we improve performance with retrieval grounding, or do we need fine-tuning, or both? What is the minimum-viable accuracy that makes the system useful? What is the maximum-acceptable error rate beyond which we have to refuse to ship?

Day 4: Map the build and the risks

Day four is the system design day. With the metric known and the feasibility checked, sketch the production system end to end.

• Sketch the architecture: model layer, retrieval layer, integration points (which systems the AI will read from and write to), monitoring, refusal behaviour.
• Identify the top three risks. For each, decide how you will mitigate it.
• Map the human-in-the-loop boundary. What does the AI decide, what does a human review, where does the escalation go?
• Decide the eval cadence in production. How often does the eval set get re-run after deployment? Who looks at the results?

If the system needs to be regulated (healthcare, financial services, legal advice) — explicitly map the regulatory boundary and which decisions require human sign-off. Do not assume; document.

Day 5: Cost it and write the one page summary

The final day is the artifact day. By the end of Friday you should have:

• A costed build estimate — hours of senior engineering and strategy time, third-party model and infrastructure costs, expected running cost per month after launch.
• A sequenced plan: what gets built in week one, week two, week three. Where the prototype ends and the production build begins.
• A one-page summary the sponsor can read in five minutes. Problem, metric, approach, cost, risk, decision required.
• A clear next-step decision: prototype, defer, or kill.

Why a week is enough

Some consultancies will tell you a project of this kind needs four to six weeks of "discovery" before any commitment. In our experience that is sometimes true for very regulated or very integration-heavy projects — but for the vast majority of AI engagements, a week is the right ceiling. Anything longer dilutes the decision and gives the project space to drift.

The discipline of one week forces you to be honest about scope. You cannot do everything in five days, which means you have to pick the most important thing — and that is usually the right choice anyway.

If you would like an outside opinion on whether a specific AI project is worth pursuing, or how to scope your first one, book a 30-minute discovery call. We will tell you, honestly, whether AI is the right tool for the problem in front of you, and what a sensible first week of scoping would look like.

Related reading

• AI projects we ship most often for Liverpool businesses (and what they cost) — the budget shape that follows a good scope.
• Hiring an AI consultancy: a buyer's checklist — how to evaluate the firm doing the scoping.
• Why most AI pilots fail — the failure modes scoping is meant to prevent.