How to Scope an AI Project So the Timeline Doesn't Slip

Most AI projects slip on scope, not modelling

The model is rarely the long pole. Timelines slip because the ask was "add AI to support" and the team discovered the real work — the integrations, the data pipeline, the escalation tooling — halfway through. Good AI project scoping is turning that vague ask into a spec someone can build against, with the risky parts named up front.

Start from the non-functional constraints

The requirements that actually shape the build are usually not "it should be accurate." They're the constraints:

• Latency. Does this sit in a request path with a budget (a fraud score inside a 200ms authorization window, a support chat that feels broken past three seconds) or can it run async?
• Reconstructability. Does a regulator or a disputes team need to rebuild a decision months later?
• Concurrency. Ten simultaneous sessions or a thousand?
• Failure behaviour. What happens when the model API is down — fail open, fail closed, degrade to rules?

Each of these forces an architecture decision, and each one you skip is a rebuild waiting to happen. The pipeline write-ups in our portfolio start with exactly this — the non-functional requirements that ruled options out before any model was chosen.

Name the one hard requirement

Most projects have a single non-negotiable. On a support agent it was that every tool call be schema-valid, no exceptions — a malformed refund is a support ticket about you. On a fraud engine it was that decisions stay reconstructable. Write that down, because it's the thing every design decision gets checked against.

Define the first release as a cut, not a phase

"We'll do returns and refunds and address changes and cancellations" is not a first release. A first release is the smallest scope that deflects real volume at low risk — order status plus one write tool, say — with everything else explicitly deferred. Each thing you add is a new failure mode to watch; adding them one at a time keeps the blast radius small.

Write down what's out of scope

The out-of-scope list prevents the mid-project "while we're in here…" that eats the timeline. Per-shopper personalization, multi-region, a second language, the exotic edge case — if it's not in this release, say so in the doc, so adding it later is a decision, not a surprise.

Budget the boring parts

The feature pipeline, the schemas, the eval harness, the escalation console, the audit logging — this is where the weeks go. If the plan says "week 1: build the model, weeks 2-6: polish," the plan is wrong.

A scoping checklist

Before a timeline is committed, the doc should answer all of these:

• Latency budget — request-path with a number, or async?
• Reconstructability — does a decision need to be rebuildable months later?
• Concurrency — peak simultaneous sessions?
• Failure behaviour — fail open, fail closed, or degrade to rules, per dependency?
• The one hard requirement — the single non-negotiable every design decision is checked against.
• First-release scope — specific inputs, specific tools, specific fallback behaviour.
• Out of scope — named explicitly, so adding it later is a decision.
• Data readiness — is the data reachable, fresh, and labelled? (Often the real project.)
• Who owns the estimate — the person accountable for the timeline wrote the scope.

A doc missing three of these isn't a scope, it's a wish.

Where this stops being right

• A throwaway prototype doesn't need this — you're exploring, and the scope is "learn something."
• A tiny, well-bounded feature with no integrations and no compliance angle can be scoped in a paragraph.
• When the constraints genuinely aren't known yet, the first deliverable is a spike to find them, not a build plan.

FAQ

What's the most common scoping mistake? Scoping the model and treating the integrations, the eval harness, and the escalation tooling as "polish." They're the bulk of the work.

How detailed should the first-release scope be? Detailed enough that "done" is unambiguous — specific ticket types, specific tools, specific fallback behaviour. Vague scope is how a two-month build becomes four.

Who should own the scope doc? Whoever will defend the timeline. If it's written by someone who won't be accountable for the estimate, it drifts.

ISTRALLEN scopes AI projects around the non-functional constraints and a first-release cut before any code — see what we do.