In August 2024, RAND Corporation published one of the more rigorous looks yet at why enterprise AI initiatives stall: structured interviews with 65 experienced data scientists and engineers, across "The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed." The finding: more than 80% of AI projects never reach meaningful production deployment. And the root causes RAND's researchers identified weren't technical — they were organizational.
That conclusion — organizational, not technical — matches the pattern we've seen across the rollouts we've run. Model capability can genuinely be a limiting factor in specialized, high-precision use cases — that's real and worth naming. But in the projects we've watched fail, that wasn't the story. The same handful of structural things kept showing up, and they failed before anyone opened a chat window.
Where most of these projects go wrong
1. They started with the tool, not the workflow. "Let's get everyone using AI" is not a plan — it's a vibe. Teams roll out a license, run a lunch-and-learn, and wait for adoption to happen organically. It doesn't, because nobody translated "use AI" into "here is the specific, repeatable task this replaces or accelerates." Without a named workflow, there's nothing to measure and nothing to hold anyone accountable to.
2. There was no owner. AI initiatives that live in "everyone's responsibility" die in "nobody's job." The projects that stuck had a single named person accountable for the outcome — not the tool's adoption rate, the business outcome it was supposed to move. No owner means no one notices when it stalls, and no one is positioned to fix it when it does.
3. They tried to automate a broken process. AI amplifies whatever process you feed it. If the underlying workflow is undocumented, inconsistent, or exists only in one person's head, automating it just produces inconsistent output faster. Most failed projects skipped the unglamorous step of mapping the process before asking a model to run it.
4. No feedback loop. Teams ship a first version and never revisit it. There's no mechanism catching where the output was wrong, where a human had to intervene, or where the workflow itself needed to change. Without that loop, "good enough for a demo" quietly becomes "still running six months later, still wrong the same way."
5. Success was never defined. "See if AI can help with X" isn't a success criterion — it's a hope. If nobody wrote down what "working" looks like before starting, nobody can tell whether the project is working, stalling, or should be killed. Most zombie AI projects aren't failing loudly; they're just never being evaluated.
What we've seen the successful minority do differently
In the rollouts that actually stuck, a consistent sequence showed up — and notably, most of it happened before any AI was involved:
- They picked one narrow, painful, well-understood workflow — not "customer service," but "drafting the first response to a refund request." Scoped enough to document fully and measure honestly.
- They documented the current process end-to-end — inputs, decision points, exceptions, who does what — before touching a model. If you can't write the workflow down, you can't hand it to AI.
- They named an owner with authority to change the process, not just report on it.
- They defined what "working" meant in advance — a specific metric (time saved, error rate, throughput) with a number attached, not a feeling.
- They built in a review loop from day one — a standing checkpoint to look at real outputs, catch drift, and adjust the workflow itself, not just the prompt.
None of this guarantees success on its own — a well-scoped project can still fail for reasons outside the workflow itself, like budget or org change. But absent these five things, we haven't seen a rollout survive contact with reality for long.
The takeaway
If your organization is stuck in pilot purgatory, the fix probably isn't a better model or a different vendor — RAND's own research backs that up. It's going back one step further than most teams are willing to go: pick one workflow, document it properly, name an owner, define success in a number, and build the feedback loop before you scale anything.
That's the whole premise behind how we run Workflow Sprints at Framework Friday — we don't start with "which AI tool should we use." We start by mapping the actual workflow, finding where it breaks, and only then deciding what (if anything) AI should touch. It's slower on day one, and it's the entire reason some organizations stay in the minority that makes it work.
Sources:
