10decoders
Why scoping is where most AI money is lost
An AI project that is well-scoped can survive a mediocre model. A poorly scoped project cannot be saved by an excellent one. The scope document, or the absence of one, determines whether the team is building something that will work in the real environment, integrate with the systems that need to consume it, be evaluated against criteria that match actual business goals, and be maintained after the vendor leaves. 37% of organizations cite inaccurate requirements as the primary reason for project failure, per PMI's project management survey. In AI projects, inaccurate requirements nearly always trace to the same six failures.
The most expensive version of each failure is not the one that kills the project at launch. It is the one that lets the project run for six to twelve months before the organization realizes the scope was wrong from the start. 42% of firms abandoned their primary AI initiative between 2025 and 2026 because they could not prove a path to ROI. In 56% of failed cases, executive sponsorship collapsed within six months. By the time sponsorship collapses, the organization has spent the full build budget and is looking at a rework scope that is often larger than the original project.
The six failures below are not exotic mistakes. They show up in AI project proposals and SOWs regularly, often worded in ways that make them look like responsible planning. The tell is knowing what to look for: where the scope stops short of the real problem, where the data assumptions are not validated, and where the definition of "done" will not match the definition of "working" once the system is live.
"A well-scoped AI project can survive a mediocre model. A poorly scoped one cannot be saved by an excellent one."
The 6 AI project scoping failures and their downstream cost
The first two failures happen in the problem definition phase, before any technical work begins. They set the wrong target and the wrong data assumptions. The next two failures happen in the architecture and integration phase of scoping, where the work gets underestimated in ways that only become visible at build time. The last two are evaluation and maintenance failures that let a project be declared done before it is actually working. Most proposals that end in failed projects carry at least three of the six.
| Scoping Failure | What Was Skipped | What It Produces | Risk |
|---|---|---|---|
| Scoping around the model, not the business workflow | The project is defined by which AI technology will be used rather than which business decision or workflow will change. The scope document names the model or architecture before it defines what problem is being solved for which person in which process step | The team builds something technically correct that does not fit the real workflow. Integration work gets discovered late, the model solves the wrong version of the problem, and the business stakeholder who has to use the output cannot. RAND found this pattern in the majority of failed enterprise AI initiatives | Critical |
| Treating the demo scope as the production scope | A working proof of concept on clean sample data is treated as evidence that a production deployment is straightforward. The gap between demo data and production data, demo environment and production environment, and demo user and actual end user is not scoped | 55% of AI projects experience scope creep significant enough to contribute to total failure to deliver. Most of that creep is the production gap appearing after the demo impressed stakeholders. A prototype that took six weeks becomes an 18-month production project because the original scope only covered the demo | Critical |
| Skipping the data readiness audit | The scope assumes the data needed to train, fine-tune, or provide context to the AI is available, accessible, and clean. No one has actually confirmed data location, format, completeness, quality, or the legal permissions needed to use it for AI training | Data problems surface after the architecture is built and the vendor is billing. Average cost of AI data quality rework in enterprise projects is $1.2 million per incident, per RAND's analysis. The data that exists is rarely in the format the AI needs it in, and getting it there is frequently larger than the original model development work | Critical |
| Underestimating integration surface area | The AI system's connections to upstream data sources and downstream consuming applications are listed but not scoped. API contracts, authentication requirements, data transformation layers, latency constraints, and failure modes are not documented before the build starts | Integration work routinely accounts for 40 to 60% of total project effort in enterprise AI but is commonly scoped at 10 to 20% of the estimate. Projects hit integration issues at the end of the build cycle when there is no budget left to address them, and the AI sits in staging rather than production | High |
| No evaluation criteria defined before build starts | The project has no agreed definition of what "good enough to ship" means. There are no benchmark tasks, no accuracy thresholds, no latency requirements, no human review protocols for edge cases, and no acceptance criteria that map to actual business outcomes | Without predefined evaluation criteria, any output can be argued into acceptability. The project team ships when they run out of budget, not when the system meets a standard. 56% of executive sponsors withdraw support within six months of launch when they cannot see measurable results, which requires evaluation criteria to exist in the first place | High |
| Scoping for delivery but not for maintenance | The scope covers build and initial deployment. It does not cover model monitoring, retraining cadence, prompt version control, data pipeline maintenance, user feedback loops, or the operational cost of keeping the AI performing at the level it was built to perform at | Year-two costs regularly exceed year-one build costs for enterprise AI. An AI system that is not maintained degrades. The 80% failure rate includes a significant share of projects that "succeeded" at launch and then quietly stopped working 12 months later because maintenance was never funded or staffed | High |
Not sure where your AI project scope has gaps?
Most scoping gaps are invisible until build time, when fixing them costs 5 to 10 times more than defining them upfront. Our discovery workshop maps the real problem, the data state, the integration surface, and the evaluation criteria before any development budget is committed.
Book a Free AI Assessment →What a well-scoped AI project looks like before the build starts
A complete AI project scope works backward from a business outcome, not forward from a technology choice. It starts with a single, testable problem statement: which specific decision, task, or output currently requires a person to spend time on it, and what would change about that person's workflow if the AI handled it? The answer to that question defines the use case, the user, the inputs the model will receive, and the outputs it needs to produce. Everything else in the scope flows from that starting point.
The data section of a complete scope is a statement of what data has been confirmed to exist in what state, not an assumption about what data should exist. This requires a data readiness audit before the scope is written, not after the architecture is designed. The audit checks whether the data is accessible, whether it is in a usable format, whether it is complete enough for the intended use, and whether there are any privacy, licensing, or compliance constraints on using it for AI training or inference. Skipping the audit and writing "client will provide training data" is a common scope placeholder that turns into a six-month delay.
The evaluation section defines the acceptance criteria: specific tasks the model must perform above a defined accuracy threshold on a defined test set, with defined escalation paths for outputs that fall below the threshold. At 10decoders, our discovery workshop produces this definition as its primary output before any build work begins. The evaluation criteria become the contract between the build team and the business stakeholder. Without that contract, "done" is a negotiation that happens when one side runs out of budget or patience.
Technology-First Scope
Proposal names the model and architecture before defining the business problem. Data is assumed available. Integration listed at 10% of effort. No evaluation criteria. No maintenance plan. Sponsorship collapses within six months when results are not measurable.
Problem-First Scope
Business problem defined before technology is selected. Data readiness confirmed by audit. Integration surface fully mapped. Evaluation criteria agreed before build starts. Year-two maintenance costs included in the business case. Build proceeds against a verified baseline.
Compounding AI Program
First project scoped correctly and delivered on time delivers ROI. That ROI funds the next scope. Evaluation data from project one informs the baseline for project two. The AI program grows because each project was defined to succeed, not because the models got better.
The AI project scoping checklist: what a complete scope covers
"37% of organizations say inaccurate requirements are the primary reason their projects fail. In AI, those inaccurate requirements are almost always written at scoping time."
What to do this week
01Read your current AI project scope document as a critic
Pull the scope document or statement of work for any AI project currently in planning or early build. Check for the six failures: Does it name the model before the business problem? Does it assume data without confirming it? Does it list integrations without mapping them? Does it have evaluation criteria that predate the build? Does it include a production scope separate from any demo? Does it include maintenance costs in the business case? Count how many of the six are present. If the answer is four or more, the project is carrying the conditions that produce the average 80% failure rate.
02Run a one-hour data inventory session with your data team
Before the next AI project proposal is written, spend one hour with whoever owns the data the AI will need. Ask three questions: Does the data actually exist in the format the AI will need? What work is required to get it into that format? Are there any legal or compliance constraints on using it for AI training or inference? The answers will either confirm the scope assumption or surface a scoping failure that would cost months and hundreds of thousands of dollars to fix during build. One hour now is worth considerably more than that.
03Write the acceptance criteria before the vendor writes the proposal
Before you send a brief or RFP to any AI development vendor, write down what success looks like in concrete terms: which tasks the AI must complete, at what accuracy threshold, against what test data, and within what latency. This definition serves two purposes. It tells the vendor exactly what to scope. And it commits the business stakeholder to a definition of success before the build team has any incentive to argue about it. Any proposal that does not include these acceptance criteria in its definition of done should be sent back with a request to add them.
04Get a discovery workshop on the calendar before the next project kickoff
The six scoping failures are prevented by a structured discovery workshop that produces a problem statement, a data readiness assessment, an integration map, evaluation criteria, and a production gap plan before any build work is authorized. Most AI projects skip this step because it feels like delay. In practice, a two-to-three day workshop saves four to six months of build-time rework. At 10decoders, every engagement starts with this workshop, because the alternative, writing a scope based on assumptions and fixing it during build, is the standard path to the 80% failure rate.
Let 10decoders scope your AI project before the build starts
Our discovery workshop produces the problem statement, data readiness assessment, integration map, and evaluation criteria that every AI project needs before development begins. We run it in two to three days. It costs a fraction of the rework it prevents. And it is the difference between the 20% of AI projects that deliver and the 80% that do not.