How to Scope an AI Project: A Practical Method

Most AI projects fail before a single line of code is written. They fail in the scoping phase, when a vague ambition ("we want to use AI for customer support") gets translated into a budget request without anyone defining what success looks like, what data exists, or what the system actually has to do on Tuesday morning at 09:47 when a customer asks an awkward question. A 2024 RAND study of enterprise AI deployments found that more than 80% of AI projects fail, roughly double the failure rate of comparable IT projects, and the most common root cause was poor problem framing rather than technical limitations.

Scoping is the cheapest place to fix a project. A week spent properly defining the problem saves months of rebuilds. This article walks through the method we use on every engagement: how to frame the problem, audit the data, pick the right success metrics, decide build vs buy, surface the risks early, and produce a budget and timeline that survive contact with reality.

Start With the Decision or Action, Not the Technology

The single biggest mistake in AI scoping is starting from the technology. "We want to use generative AI" is not a scope. It is a vendor's wish list. The right starting point is a specific decision or action that a person or system currently makes, where the cost, speed, accuracy or consistency of that decision is a problem.

Write the scope as a sentence in this form: "Today, [role] does [task] by [current process], which takes [time] and costs [money] / produces [error rate]. We want a system that [new behaviour], measured by [metric]."

A real example from a recent engagement: "Today, our customer success team manually reviews each incoming support ticket and routes it to one of seven queues. This takes a CS rep about 90 seconds per ticket, across roughly 600 tickets a day, and we mis-route around 12% of them, which adds an average 4-hour resolution delay. We want a system that classifies and routes tickets automatically with under 5% mis-routing."

That sentence is doing real work. It names the decision, the current cost, the desired behaviour, and the success metric. Everything downstream in the scope - data requirements, model choice, evaluation, integration points - falls out of it. If your team cannot write that sentence, you are not ready to scope an AI project. You are ready for a discovery workshop.

Audit the Data Before You Promise Anything

An AI system is a function of its data. Before committing to any timeline or budget, you need an honest audit of what data you have, where it lives, what state it is in, and what you are legally allowed to do with it. McKinsey's 2024 State of AI report flagged data quality and availability as the top barrier to AI value capture for the third year running.

Run through this checklist before you write a statement of work:

• Volume. How many labelled examples, documents or records exist? For a RAG system, 500 well-structured documents is often enough. For a classifier, you typically want at least 1,000 labelled examples per class, ideally more.
• Quality. Is the data accurate, consistent and de-duplicated? Pull a random sample of 50 records and read them. If you find errors in 10, you have a data project before you have an AI project.
• Access. Where does the data physically live? CRM, data warehouse, SharePoint, someone's laptop? How will the production system get to it - API, scheduled export, direct database read?
• Freshness. Does the system need real-time data or is daily refresh fine? This changes the architecture significantly.
• Legal basis. Under UK GDPR, you need a lawful basis for processing personal data, and Article 22 places restrictions on solely automated decisions with legal or similarly significant effects. Check the ICO guidance on AI and data protection before you scope anything involving customer or employee data.

If the audit reveals that the data does not exist, is not accessible, or is not lawful to use as planned, that is a scoping outcome. It is not a failure. It tells you that phase one is a data project, not an AI project, and you scope accordingly.

Define Success in Numbers, Not Adjectives

"Better customer support" is not a success metric. "Reduce average first-response time on tier-1 tickets from 4 hours to under 30 minutes, while maintaining CSAT at or above 4.2/5" is a success metric. The discipline is to define both a primary metric (what you are trying to improve) and at least one guardrail metric (what you are not allowed to break).

For AI systems specifically, you usually need three categories of metric:

1. Business metric. The thing the project is justified by. Revenue per rep, cost per ticket, hours saved per week, leads qualified per day.
2. Model metric. The technical measure of whether the model is doing its job. Precision, recall, F1, accuracy at top-k, hallucination rate on a held-out evaluation set.
3. Operational metric. What it takes to run. P95 latency, cost per inference, uptime, fallback rate to human.

Scope the evaluation method at the same time as the metric. For a classifier, you need a labelled test set held back from training. For a RAG system or an LLM-driven workflow, you need an evaluation harness with curated questions and expected behaviour, scored either programmatically or by a human reviewer on a defined rubric. We typically aim for at least 100 evaluation cases for a first build, growing to 500+ as the system matures. If the scope does not include building this evaluation set, the project has no way to prove it works.

Decide Build, Buy or Configure - With a Real Comparison

For most AI use cases in 2026, there is a credible off-the-shelf option, a credible no-code or low-code configuration route, and a credible custom build. Scoping means choosing deliberately, not defaulting.

The decision usually comes down to four questions:

• Is the use case differentiating? If it is core to how you compete (proprietary scoring, unique data, brand-defining experience), lean build. If it is a commodity capability (transcription, generic chatbot, meeting notes), lean buy.
• How specific are the integrations? Off-the-shelf tools handle Salesforce and HubSpot. They struggle with your bespoke 2008 ERP. The integration surface often forces the decision.
• What is the volume and unit economics? At 200 inferences a day, a per-seat SaaS tool wins. At 200,000 a day, a custom pipeline on your own infrastructure often costs an order of magnitude less.
• What is the regulatory profile? If you are in financial services or healthcare, data residency and auditability constraints often rule out shared SaaS and push you toward self-hosted or private deployments.

Document the comparison in the scope. Three options, scored on cost (year one and year three), time to value, fit to requirements, and risk. The point is not to find the "right" answer in the abstract - it is to make the trade-off visible so the buyer can sign off on it knowingly. We have seen too many projects where the buy decision was made implicitly because someone had used the tool before, and the team discovered six months in that it could not handle the integration the business actually needed.

Identify Risks Early, Especially the Boring Ones

AI project risk is not mostly about the model. The model is, in 2026, usually the most predictable part of the system. The risks that kill projects are operational and organisational.

In the scoping phase, force a conversation about each of these:

• Change management. Who has to change their daily behaviour for this to work? Have they been involved in the design? A correctly built system that nobody uses returns zero.
• Failure modes. What happens when the AI is wrong? What is the cost of a false positive vs a false negative? Is there a human in the loop, and if so, what is their workload at peak volume?
• Vendor and model lock-in. If you build on a specific model API, what is your exit if the vendor doubles pricing or deprecates the model? Abstracting the model layer adds two weeks of work and saves nine months of rebuild later.
• Security and data exfiltration. Where does data go at inference time? The NCSC guidelines for secure AI system development are a useful checklist here, particularly around supply chain and prompt injection.
• Drift and monitoring. Models degrade as the world changes. Who is responsible for noticing? What triggers retraining or prompt updates?

The scope document should name an owner for each risk and a planned mitigation. Risks without owners do not get managed.

Phase the Work and Set an Honest Budget

Almost every AI project we have seen go wrong was scoped as one monolithic deliverable. Almost every one that went well was scoped in phases with explicit go/no-go gates.

A workable phasing pattern for most mid-market AI projects:

1. Discovery and scope (1-2 weeks, £8k-£20k). The work this article describes. Output: a written scope with metrics, data audit, options comparison, risks, and a costed plan for phase two.
2. Proof of value (3-6 weeks, £15k-£40k). A working prototype against real data, evaluated against the metrics defined in phase one. Output: a go/no-go decision with evidence.
3. Production build (8-16 weeks, £40k-£150k). Hardening, integrations, monitoring, evaluation harness, handover documentation. Output: a system in production with named owners.
4. Operate and iterate (ongoing, typically £3k-£15k/month retainer). Monitoring, evaluation, prompt and model updates, new use cases.

Be honest about what each phase costs. The single most damaging behaviour in AI sales is quoting a low headline build figure and burying the operational cost. A well-scoped project shows the three-year total cost of ownership, including model API spend, infrastructure, monitoring tools, and the internal headcount required to keep it running. For a typical mid-market RAG-based assistant, expect £40k-£80k build plus £2k-£8k/month run cost including model inference at moderate volume.

Timelines depend on data readiness more than model complexity. If the data audit is clean, an AI-powered workflow automation can be in production in 6-8 weeks. If the data needs cleaning, integration work, or new collection, add 4-12 weeks before the AI work starts. Bake that into the scope rather than discovering it in week three.

What a Good Scope Document Contains

By the end of scoping, you should have a single document, typically 8-15 pages, containing:

• The problem statement in the sentence form above
• The data audit with named systems, volumes, quality assessment and legal basis
• Primary, guardrail and operational metrics with target values
• The evaluation method and who builds the evaluation set
• Build vs buy vs configure comparison with scored options
• Named risks with owners and mitigations
• Phased plan with budgets, timelines and go/no-go gates
• Architecture sketch at the level of "what talks to what"
• Roles and responsibilities, including the internal product owner

If your scope document does not contain these sections, it is a pitch, not a scope. The difference matters because the scope is what you build against, evaluate against, and disagree against six months in when priorities shift.

FAQ

How long should scoping an AI project take?

For a well-defined single use case, expect 1-2 weeks of focused work. This usually involves 3-5 working sessions with the business stakeholders, a data audit by a technical lead, and a written scope document. For a broader programme covering several use cases or an enterprise-wide AI strategy, scoping extends to 3-6 weeks. The temptation is to compress this phase because it feels like "just talking". Resist that. A week of scoping typically saves 4-8 weeks of rework downstream, and the cost ratio is usually 1:20 or better.

Who should be in the room during scoping?

At minimum: the business owner who will be accountable for the outcome, a technical lead who understands the existing systems and data, an end user who actually does the task today, and someone with data protection or compliance knowledge if personal data is involved. For larger projects, add a finance representative for the business case and a security lead for the risk review. The most common omission is the end user, and it is the most damaging - projects scoped without input from the people doing the work routinely solve the wrong problem at the wrong layer.

Do we need a proof of concept before committing to a full build?

Usually yes, for any project over about £40k or any use case where the technical feasibility is genuinely uncertain. A proof of value (we prefer that term to PoC because it forces a value metric) of 3-6 weeks against real data tells you more than any vendor demo. Skip the PoV only when the use case is well-understood, the data is clean and accessible, and there is reference architecture for an identical problem. For genuinely novel applications, the PoV is the most important spend in the project because it converts unknown risk into known risk before you commit the full budget.

How do we estimate the budget when we have never done this before?

Anchor on comparable projects rather than first-principles estimates. For mid-market UK organisations in 2026, a workflow automation lands at £15k-£60k build. An internal AI assistant or RAG-based system lands at £40k-£120k build. A bespoke multi-agent or custom AI tool lands at £80k-£250k build. Run costs are typically 15-30% of the build cost per year, including model inference, hosting and monitoring. If you cannot anchor on a comparable, ask two or three agencies for indicative ranges before committing to a single scope. Beware quotes that are dramatically below market - they almost always mean the operational cost is being hidden.

What if our data is not ready - do we still scope an AI project?

You scope a data project first and an AI project second. This is not a failure of scoping, it is a successful outcome of scoping. The risk is doing them in parallel under the AI banner, which means the AI team waits for data and burns budget. Phase the work explicitly: weeks 1-8 are data consolidation and quality, with named acceptance criteria; weeks 9-16 are the AI build, conditional on hitting those criteria. This phasing also makes the business case more honest, because you can attribute cost to the foundation work rather than buring it inside an inflated AI budget.

How do we avoid vendor lock-in when scoping?

Three practical moves. First, abstract the model layer behind your own interface so swapping from one provider to another is a configuration change rather than a rewrite - frameworks like LangChain or a thin in-house wrapper both work. Second, keep your data and your evaluation set under your own control, in your own systems, in portable formats. Third, prefer open standards (OpenAPI, standard SQL, S3-compatible storage) over proprietary ones at integration boundaries. None of these eliminate switching cost entirely, but they reduce it from a rebuild to a migration, which is the difference between a six-month project and a two-week project.

Should we use in-house developers or an agency for the build?

It depends on three factors: whether AI engineering is a permanent capability you want to build, whether you have existing senior engineers with capacity, and how time-sensitive the first delivery is. In-house wins on long-term cost and institutional knowledge but typically takes 6-12 months to ramp from a standing start. Agencies win on time to first value and on breadth of pattern recognition across past projects. A common middle path: agency-led first build with knowledge transfer baked into the scope, followed by in-house operation and iteration. Scope the handover explicitly, including documentation, training sessions and a defined exit, or you will end up locked in by default.

What is the single most common scoping mistake?

Confusing a capability with a use case. "We want to use LLMs" is a capability statement. "We want to reduce ticket triage time by 70% on tier-1 support" is a use case. Capabilities sound strategic but cannot be built against, measured or finished. Use cases can. The fix is to refuse to start a project until you can write the problem in the sentence form described above, with a named decision, current cost, desired behaviour and success metric. If the stakeholders cannot agree that sentence, scoping is not done, regardless of how many slides have been produced.

Closing

Scoping is not the boring bit before the real work. It is the work that determines whether the real work succeeds. The discipline is unglamorous: define the decision, audit the data, set numeric metrics, compare options honestly, surface risks with owners, and phase the budget so each stage justifies the next. Skip any of these and the project becomes a slide deck with a deployment cost.

At AI Advisory we run a fixed two-week scoping engagement that produces the scope document described above, with the data audit, metrics, options comparison, risks and phased plan. If you have an AI project that needs to be scoped properly before any code is written, get in touch.

Ready to put this into production? book a discovery call.