Most "slow" AI rollouts aren't slow. Instead, they were never scoped against a real business number to begin with. Four questions that fix this.
Ask any leader why their AI rollout is taking six, nine or twelve months, and you get the same answers. “Our data is messy.” “We need buy-in across departments.” “It’s the nature of enterprise IT.” All of that might be true. Almost all of it is also an excuse.
Because here is the truth nobody on the project wants to hear. Most slow AI rollouts are not slow. They are unscoped: nobody wrote down, before the work started, which business number the project was supposed to move.
Why the rollout feels long
Teams get excited about a capability, a demo goes well, and the project moves to “approved” without ever confirming whether there is a specific number it is supposed to change, who owns that number, and what counts as done. Three months later the team is stuck in “let’s also look at” territory, adding scope because there was never a fixed target to say no against.
That is not a long rollout. It is an unscoped one wearing a long rollout as a disguise, and the disguise is convincing because everyone involved is genuinely busy the entire time.
No number to move, no project. Everything else is activity.
Four questions that expose an unscoped rollout
What number is this supposed to move? Not “improve efficiency.” A specific number: hours per case, cost per ticket, conversion rate, error rate. If the room cannot name one number in one sentence, the project has not been scoped, it has been approved.
Who owns that number today? If nobody currently owns the metric the project claims to move, there is nobody who will notice, six months from now, whether it actually moved. The project will complete and the improvement will remain a claim rather than a measurement.
What is explicitly out of scope? A rollout without a written “not this” list absorbs every adjacent request that arrives during the build, because there is no document to point to that says no. Scope creep is not a discipline failure. It is the predictable result of never writing the boundary down.
What does done actually look like? “Live in production” and “the number moved” are two different definitions of done, and most rollouts quietly use the first while promising the second. If the acceptance criteria is a working demo rather than a measured result, the project can succeed by every internal metric and still not deliver the outcome it was funded for.
What changes once the scope is real
A properly scoped rollout is not necessarily smaller. It is bounded. Everyone involved can say, in one sentence, what number moves and how they will know. Requests that fall outside that boundary get logged for later instead of silently expanding the current build. And the project has an actual finish line, instead of a rolling horizon that recedes every time someone has a good idea in a meeting.
That discipline feels slower on day one, because it means saying no to good ideas before the work even starts. It is the only version of fast that produces a project which actually ends.
The ODB Way
At ODB Growth, every engagement starts with the number that has to move, before any architecture or technology gets discussed. Objective first, then the process, then the technology. Run that order backwards and you get a rollout that demos well and never quite finishes, because there was never a finish line to reach.
Fix the scope, and the timeline usually fixes itself. Not because the work gets easier, but because everyone finally knows what they are building toward.
Onno de Bel
AI Engineer & Architect | ODB Growth
Ready to build something
that moves a number?
Let's find out where AI actually pays in your process, and build it.
Plan a Growth Call