Most AI projects fail at the scoping phase, not the build. We’ve seen it enough times to recognize the pattern: the vendor knows what they’re doing, and the scope is written to protect them, not deliver you a working system. A vague scope isn’t sloppy work. For some agencies, it’s the product.
Why AI Scoping Is Different From Regular Project Scoping
A website has a known output. A custom AI integration doesn’t. That asymmetry creates real complexity, and real opportunities for vendors to obscure accountability.
The data problem
40–50% of AI project effort is data work: cleaning, labeling, structuring, and validating the inputs the model will actually use. A vendor who doesn’t surface this in the scoping phase isn’t being optimistic. They’re being dishonest. Informatica’s 2025 CDO survey found that 43% of companies cited data quality and readiness as their top obstacle to AI success, not technology, not budget.
If your scope document doesn’t include a data audit, you don’t have a scope. You have a proposal for a bill.
Why “AI is inherently uncertain” is sometimes an excuse
Uncertainty is real. But experienced practitioners scope around it, with milestone gates, prototype requirements, and clear recourse language. When a vendor leads with “AI timelines are unpredictable” and follows it with an open-ended engagement, that phrase isn’t an explanation. It’s liability protection. The uncertainty is real; using it to avoid commitment is a choice.
What Bad AI Scoping Looks Like
These are specific patterns, not abstractions. If you recognize them in a proposal you’re reviewing, treat each one as a red flag.
Vague success metrics and “we’ll define KPIs in Phase 2”
Success criteria belong in Phase 1. If a vendor can’t tell you what “working” looks like before you sign, they can’t tell you when they’ve failed. “We’ll define metrics once we understand the data better” means you have no recourse if the project delivers nothing useful.
Good scoping names the metric, the baseline, and the target. Example: “Reduce manual invoice processing time from 4 hours/week to under 30 minutes within 90 days of deployment.” Vague scoping says: “Improve operational efficiency through AI-assisted document workflows.”
Discovery phases that cost $20K–$50K with no working code
A discovery phase that produces only a requirements document is not a deliverable, it’s a delay tactic. We’ve seen $40K scoping engagements that resulted in a 30-page PDF and a recommendation to proceed to Phase 2 at additional cost. The client is now $40K poorer and no closer to a working system.
A legitimate discovery engagement for an SMB AI project should take 2–4 weeks and produce at minimum a working proof of concept or a functional prototype, not just words about what could be built.
No milestone gates or recourse language
If the contract has no defined check-ins where progress is evaluated and payment is conditional, you are pre-funding the vendor’s entire engagement. You should be able to stop a project after Phase 1 and receive proportional value. If the contract makes that difficult, the scope was written to protect the vendor, not deliver you a working system.
Technology-first framing with no business problem anchor
“We’ll implement a RAG pipeline with vector embeddings and fine-tune a foundational model on your data” is not a scope. It’s a technology menu. A proper scope starts with the business problem: what decision or process is broken, who is affected, and what measurable outcome would constitute a fix. Technology comes third, after problem definition and data assessment.
Timelines that ignore data preparation
A 6-week AI build timeline with no data preparation window is not a plan. It’s a fiction. Organizations that skip data preparation pay 2.8x more in remediation costs downstream. If the timeline has no dedicated data cleaning, validation, and normalization phase, the vendor hasn’t scoped the real work.
What Good AI Scoping Looks Like
Good scoping is a trust signal. It shows the vendor has done this before and isn’t afraid of accountability.
Problem definition before solution
The first deliverable of a well-scoped engagement is a clear, agreed problem statement, not a technology recommendation. Before any tool or model is named, good scoping answers: What is the specific workflow or decision this AI will support? Who uses it daily? What does failure look like today, in measurable terms?
A vendor willing to say “AI isn’t the right tool for this” in the scoping phase is a vendor you can trust. That call costs them revenue. They’re making it anyway because it’s the right answer.
Measurable success criteria agreed upfront
Before development starts, both parties should sign off on a success definition that includes a metric, a baseline, and a target date. This isn’t bureaucracy, it’s the only way to evaluate whether the project worked. Without it, a vendor can always argue partial success.
Data audit as a scoping deliverable
The scoping phase should include a formal review of the data the AI will use: where it lives, what format it’s in, how complete it is, and what remediation is required before model training or integration. This audit is often where the real project risk sits. A vendor who skips it is either inexperienced or not planning to be accountable for the outcome.
Working demo before full contract
For any AI engagement over $15K, you should receive a proof of concept, something that processes real (or representative) data and produces a real output, before you sign the full build contract. This doesn’t have to be production-ready. It has to demonstrate that the core technical assumption holds. If the vendor won’t build a POC before contract, ask why.
Ownership, change management, and compliance documented upfront
Who owns the trained model? What happens to the integration if you change your CRM? Who is responsible for retraining if the data drifts? Are there GDPR or CCPA implications for the data being processed? These questions have answers. A good scope documents them before the build. A bad scope leaves them for “later.”
Side-by-Side: Good vs. Bad Scoping Signals
| Dimension | Bad Scoping | Good Scoping |
|---|---|---|
| Success metrics | ”Improve efficiency” | Named metric, baseline, target date |
| Data assessment | Assumed sufficient | Formal audit as Phase 1 deliverable |
| Discovery cost | $20K–$50K, doc only | 2–4 weeks, includes working POC |
| Timeline | Tight, no data prep window | Realistic, includes data work |
| Milestone gates | Lump-sum contract | Payment tied to phase completion |
| Technology framing | Tools named first | Business problem defined first |
| Uncertainty handling | ”AI is unpredictable” | Milestone recourse language |
| Ownership | Not addressed | Explicitly documented |
| Vendor risk language | ”Best efforts” | Named deliverables with acceptance criteria |
| Exit provision | None or buried | Clear refund trigger if POC fails |
Frequently Asked Questions
What should be in an AI scoping document?
At minimum: a clear problem statement, measurable success criteria with a baseline and target, a data audit or assessment, the proposed technical approach and why it fits the problem, a phase-by-phase delivery plan with milestone gates, a timeline that includes data preparation, and explicit ownership terms for models, data, and integrations. If any of these are absent, the scope is incomplete.
How long should an AI scoping phase take for a small business?
For most SMB AI projects, 2–4 weeks is sufficient for scoping if the vendor comes prepared. That window should produce a problem definition, data assessment, and a working proof of concept. Longer scoping phases are justified when data infrastructure is complex, but they should still produce code, not just documents. A 90-day discovery phase for an SMB project is almost always over-engineered or padded.
Is a $20,000–$50,000 discovery phase normal for AI projects?
For enterprise projects with complex data environments and multiple stakeholders, yes. For SMB AI integrations, a customer support bot, a document classifier, an internal search tool, no. A $30K discovery phase that produces only a requirements document, with no working prototype and no refund trigger, is not standard practice. It’s a red flag. Legitimate scoping for SMB-scale AI work typically runs $5K–$15K and includes a functional POC.
What questions should I ask an AI vendor before signing?
Ask: What does success look like in measurable terms, and will you put it in the contract? What does the data audit process look like, and what happens if my data isn’t ready? Will I receive a working proof of concept before I sign the full build? Who owns the trained model and what happens to it if I leave? What’s the recourse if the project doesn’t meet the agreed success criteria? A vendor who deflects or hedges on any of these has told you something important.
How do I know if an AI vendor is overpromising?
Watch for technology-first pitches that name models and frameworks before identifying the business problem. Watch for timelines that don’t account for data preparation. Watch for “AI can do anything” framing with no discussion of constraints, failure modes, or limitations. A credible vendor will tell you what the system won’t do, what the risks are, and under what conditions they’d recommend a different approach. Optimism about AI is cheap. Specificity about your problem is what you’re paying for.
What happens if the scoping reveals AI isn’t the right solution?
A reputable vendor will tell you this during scoping, before the build contract. That outcome is more common than vendors admit: 42% of companies abandoned most of their AI initiatives in 2025 after starting them, often because the initial scoping was inadequate. If your vendor identifies during scoping that a simpler automation, a workflow change, or a off-the-shelf tool would solve the problem better, that’s the right answer. You want a vendor who will say it.
If you’re evaluating an AI proposal and aren’t sure whether the scoping is solid, we’ll look at it. We scope and build AI integrations for operations that are ready to move, not a $30K discovery engagement, but a clear-eyed assessment of whether what you’re looking at is built to deliver or built to protect the vendor. See how we work at designodin.com/ai, or tell us what you’re working on and we’ll be direct about whether we can help.