How to scope an AI project in a week

AI projects do not usually fail at the build stage. They fail at the scoping stage, and the failure just shows up later. A vague brief produces a vague prototype, an unclear success metric produces an unclear result, and an unvalidated assumption produces a nasty surprise in week eight.

The good news: scoping an AI project does not take months. It takes a focused week. Here is the five day framework we use to turn a rough ambition into a costed, derisked plan a board can actually sign off.

Day 1: Frame the problem, not the solution

Most AI briefs arrive as solutions: "we want an AI chatbot", "we should use agents". Day one is about reversing that, getting back to the problem underneath. What process is slow, costly or inconsistent? Who feels the pain, and how often? What does it cost today in hours or money?

By the end of day one you should have a single problem statement and a baseline number: the current cost of the problem. Everything that follows is measured against that baseline.

If you cannot describe the problem without naming a technology, you have not finished scoping.

Day 2: Define what success looks like

A project without a success metric cannot be judged. Day two fixes the target before any building begins. A good metric is specific, measurable and tied to the baseline from day one:

• Reduce average handling time from 12 minutes to under 5.
• Extract invoice data at 95%+ field accuracy with review.
• Deflect 30% of tier one support tickets without a human.

Vague goals like "improve efficiency" or "explore AI" are not metrics. They are how projects drift. Pin the number down now, while it is cheap to argue about.

Day 3: Check the data and the feasibility

Day three is a reality check, and it is the day that most often saves a project. AI runs on data, so look hard at what you actually have. Does the data exist? Is it accessible? Is it good enough? Is there a labelled set to evaluate against?

This is also where you separate what is genuinely feasible from what is wishful. Some problems are a great fit for current AI; some are not. It is far cheaper to learn that on day three than in month three.

Questions worth answering on day three

• Where does the data live, and who controls access to it?
• Is it complete and clean enough, or does it need work first?
• Can we measure quality, and is there ground truth to compare against?
• Are there privacy, security or compliance constraints to design around?

Day 4: Map the build and the risks

With the problem, metric and data understood, day four turns to delivery. Sketch the architecture at a high level: the approach, the integrations, the touchpoints where a human stays in the loop. You are not designing in detail; you are sizing the work and surfacing the risks.

List every meaningful risk and assign each one a mitigation: a technical unknown to spike, an integration to confirm, a stakeholder to align. Risks written down are manageable. Risks left implicit become the reasons a project slips.

Day 5: Cost it and write the one page summary

The final day produces the deliverable: a single page a decision maker can act on. It should contain the problem and its baseline cost, the success metric, the proposed approach, the main risks and mitigations, and a costed, time boxed plan, typically a short prototype phase with a clear decision point on whether to proceed.

Crucially, build the gate into the plan. The prototype phase should end with an honest measurement against the day two metric, and a real decision: ship, iterate, or stop. That single checkpoint is what keeps a project accountable.

Why a week is enough

A week of disciplined scoping is not a delay. It is the cheapest risk reduction available on the entire project. It costs five focused days and can save months of building the wrong thing. The teams that ship AI successfully are not the ones that start building fastest. They are the ones that scope sharply, then build with confidence.