Most AI projects fail. The failure rate cited across studies and industry reports varies, but it consistently lands somewhere between sixty and eighty percent of projects not delivering their intended value. The framing in most of those reports focuses on implementation issues, change management challenges, or technology limitations. The framing is wrong. Most AI projects fail before any technology gets deployed, before any implementation challenges arise, before any change management work happens. They fail at the moment they're scoped, because the scoping itself was built on assumptions that the organization's actual operational reality couldn't support.

The failure is structural, and it's almost always invisible at the front end. The project gets approved, funded, and launched with leadership confidence. The team assembles, the vendor gets selected, the implementation plan gets built. Months in, the project is struggling, and nobody can quite say why. The technology works. The team is competent. The vendor is delivering. And the project is producing outcomes that don't match what was promised at the front end. The diagnosis usually focuses on execution. The actual cause was the scoping.

Here's what's happening in scoping that produces these failures consistently.

The project is scoped against the organization's documented operational reality, not its actual operational reality. The team building the project specification reviews the policies, the processes, the system documentation, and the data dictionaries. They build the AI project around what those artifacts describe. The artifacts describe an organization that doesn't exist operationally. The actual operations are running on patterns that have drifted from the documentation, accumulated workarounds, and human discretion that handles the gaps. The AI project gets scoped against the organization on paper. The deployment encounters the organization in operation. The two don't match, and the project becomes an exercise in either forcing operations to match the documentation or rebuilding the project to match operations. Either path consumes the budget without delivering the original value proposition.

The data the project assumes is available isn't available in the form the project requires. AI projects operate on data. The project specification assumes specific data types, specific levels of granularity, specific structures, and specific quality levels. The team assumes these assumptions are reasonable because the data exists in the organization's systems. The data exists in those systems in forms that satisfied historical requirements and don't satisfy the AI project requirements. Cleaning, restructuring, and supplementing the data to match the project requirements becomes a major effort that wasn't scoped, takes significant time, and consumes resources that were budgeted for the AI work itself. The project enters a period that looks like delay and is actually undisclosed foundation work.

The processes the AI is supposed to enhance or automate aren't documented at the level of detail the AI requires. AI implementations require detailed process documentation. The current state has to be specified rigorously. The future state has to be designed with operational specificity. The mapping between current and future has to be explicit. Most organizations have process documentation that describes processes at a high level. The actual operational detail lives in the heads of the people performing the processes, in informal documentation, and in patterns of practice that have evolved over time. The AI project encounters this gap during implementation and either has to invest significantly in process documentation work that wasn't scoped or has to deploy AI on processes that aren't fully understood, which produces suboptimal results.

The decision-making authority the AI project requires hasn't been clarified. AI implementations change how decisions get made. They embed rules in systems that previously lived in human judgment. They require explicit articulation of decision criteria that were previously implicit. They reveal disagreements about how decisions should be made that were previously masked by individual variation. The project specification doesn't usually account for the time and political work required to resolve these disagreements, articulate the criteria, and secure the decision-making authority changes the AI implementation requires. The implementation surfaces the disagreements, the disagreements consume project capacity, and the project gets characterized as struggling with change management when the actual issue is decision authority that was never resolved before implementation began.

The integration with existing systems is more complex than the specification assumes. AI implementations rarely operate in isolation. They have to integrate with financial systems, operational systems, reporting infrastructure, and security frameworks. The integration complexity is usually understated in project scoping, because the team doing the scoping doesn't have detailed knowledge of all the systems being integrated. Integration work expands beyond the original estimate. Resources get consumed by integration that were budgeted for AI capability. The deployed AI ends up being more constrained than the specification suggested, because the integration limitations forced reductions in what the AI could actually do.

The success criteria are specified in ways that can't be measured. AI projects are usually justified through projected gains in efficiency, accuracy, or capability. The projections are reasonable on their face and become impossible to validate in operation, because the baseline against which the gains would be measured wasn't established with the precision required to detect the gains. The project produces outputs. The outputs may or may not represent improvements over the prior state. The organization can't tell, because the measurement infrastructure to make the comparison wasn't built. The project's value gets debated rather than evaluated, and the debate usually goes badly because the burden of proof falls on the people who advocated for the project.

These conditions are present in the majority of AI projects, and they're present at scoping. The project is approved with assumptions about operational documentation, data availability, process clarity, decision authority, integration scope, and measurement infrastructure that aren't being tested before approval. The testing happens during implementation, and by then, the project has commitments, deadlines, and visibility that make graceful course correction nearly impossible. The project either delivers a compromised version of the original vision, gets significantly extended and over-budget, or quietly fails and gets repositioned as something different than what was originally promised.

The organizations that produce successful AI projects do specific work at the scoping stage that most organizations skip.

They examine the operational reality of the area being targeted, separate from the documentation. They look at how things actually work, not how they're described. They identify the gaps between documentation and practice and decide whether the project will address those gaps or work around them. The decision is explicit and costed.

They assess data availability rigorously. They examine whether the data the project requires actually exists in usable form. They identify the cleaning, restructuring, and supplementation work required. They include that work in the project scope and budget, rather than discovering it during implementation.

They invest in process documentation as a precondition for AI work, not as a parallel track. They document the current state at the level of detail the AI implementation will require. They design the future state explicitly. They resolve the gaps and ambiguities before the AI project enters implementation, when resolution is much cheaper.

They surface the decision authority changes the AI will require and resolve them as part of project initiation. They identify the disagreements about decision criteria and address them through the appropriate organizational channels. The AI implementation doesn't have to absorb those conversations during execution.

They specify integration scope with detail. They engage IT, security, and the owners of the systems being integrated at the front end. They map the integration work and budget for it specifically. The integration doesn't surprise the project mid-implementation.

They build measurement infrastructure before the AI is deployed. They establish baselines with the precision required to detect the projected gains. They specify the metrics, build the data collection mechanisms, and validate the measurement approach. When the AI deploys, the measurement infrastructure is ready to evaluate it.

This kind of scoping is more expensive than what most organizations do at the front end. The expense is small compared to the cost of project failure, which is the predictable outcome of the cheaper scoping approach. Organizations that invest in rigorous scoping produce AI projects that deliver. Organizations that don't produce AI projects that join the sixty to eighty percent failure rate, and the failures consume resources that could have been deployed against work that would have actually produced value.

If your organization is moving on AI without examining whether the operational foundation can support what's being scoped, the project is already failing. The visible failure is months away. The structural failure has already happened.