How to Scope an AI Project Before You Hire an Agency

Every week a leadership team sends out an RFP for "an AI solution" and gets back five proposals that look identical and behave nothing alike. The problem isn't the agencies. The problem is the scope. If you scope well, the rest is procurement. If you don't, you're buying lottery tickets.

This post is the checklist we run with clients before they take a single proposal seriously.

Why scope kills more AI projects than tech does

Most failed AI projects don't fail because the model didn't work. They fail because the project shipped something nobody could use or that didn't actually move a metric anyone cared about. The technology was fine. The scope was wrong.

A wrong scope shows up as:

• A prototype with no business owner.
• A workflow nobody integrates with daily operations.
• A metric that "improves" but doesn't change a decision.
• A model that's accurate on test data and useless on Tuesday morning.

The fix isn't a better model. It's a better question.

The minimum scope brief

Before you hand anything to an agency, freelancer, FDE, or vendor, you should be able to answer these on one page.

1. Who owns the outcome?

Name a person. Not a team. Not a steering committee. A single person whose number changes if this works.

If you can't name one, stop. You're not scoping a project — you're funding a hobby.

2. What metric moves, and by how much?

Pick one primary metric. Examples that work:

• "Reduce time to draft a customer proposal from 4 hours to 30 minutes."
• "Increase qualified pipeline from inbound by 25%."
• "Cut manual CRM enrichment time per rep from 6 hours a week to 1."

Examples that don't:

• "Improve productivity." Whose?
• "Use AI for marketing." Doing what, exactly?
• "Become more data-driven." Compared to what?

If you can't put a number next to the verb, you're not ready.

3. What's the smallest version that's still useful?

Most AI scopes are 3x too big. Ask: if we could only build one workflow, what would it be? That's your v1. Everything else is v2.

4. What does failure look like at 90 days?

If at day 90 the team isn't using it, why might that be? Write three honest answers. They will be the assumptions you need to test in the prototype.

5. Which data do you actually have?

Not which data you wish you had. Which data lives in your systems today, with reasonable quality, that someone can grant access to in two weeks.

If the answer is "we'll need to do a data project first," that's a different project. Scope it separately.

6. What's the constraint that's actually binding?

Time? Budget? Compliance? Internal politics? Pick one. The proposals you'll get are radically different depending on the answer. If you can't name the binding constraint, you'll get the proposal each vendor wanted to sell, not the one your situation needs.

The questions agencies should ask you

If an agency lands a proposal without asking these, treat the proposal as guesswork:

• Who owns the outcome internally?
• What does success look like in numbers at day 90?
• Which systems are in scope vs explicitly out of scope?
• What's the data state today?
• What's the buying process and timeline?
• What's been tried before, and why didn't it stick?

A vendor that skips these and goes straight to platform features is selling, not scoping.

Comparing proposals after they arrive

Once proposals land, score them on five things. Not capabilities — scope.

• Scope clarity. Can you read it and predict exactly what gets built?
• Assumption transparency. What did they assume? Are those assumptions correct for your reality?
• Risk surface. What could derail this — integrations, data, security, change management — and how do they handle it?
• Pricing logic. Is the price tied to outcome, time, or scope? Mismatches are red flags.
• Exit path. What does it cost to leave after v1? Vendor lock-in is a real expense.

Score each proposal 1–5 across these. The one that scores highest is rarely the one with the lowest price or the prettiest deck.

Common mistakes

• Treating discovery as a free phase. Real discovery is paid work. If a vendor offers it free, they're either subsidising sales or skipping the rigorous version.
• Adding scope during procurement. Every "and also" doubles risk. Resist.
• Letting the vendor scope itself in. If the same vendor scopes and bids, you're paying for biased scope.

Key takeaways

• Most AI projects fail on scope, not tech.
• A real scope brief names the owner, the metric, the v1, and the binding constraint.
• Good agencies ask the same questions before they bid. Bad ones pitch features.
• Compare proposals on scope clarity, not on capability lists.

If you want a sharper scope before you take a single proposal seriously, that's exactly what the ScopeRight Workshop is built for.

---

Already received AI proposals? Let ScopeRight review the scope before you commit. Independent, fast, and we'll flag what's missing.