The pattern
A team builds a promising prototype, shows it, gets enthusiasm, and then it stalls. Nobody cancels it — cancelling would require a decision — so it persists as a permanent pilot, consuming attention and producing nothing.
Cause 1: no definition of done
Pilots without an explicit bar cannot be passed. Agree before building what result, measured how, would mean this goes to production — and what result would mean it stops. That is precisely what writing the evaluation first produces.
Cause 2: no owner in the business
A pilot owned only by a technical team has nobody whose targets improve when it ships. Without an operational owner who wants the outcome, there is no force pushing it through the last, least interesting twenty percent.
A pilot with no one whose job gets easier when it ships will not ship.
Cause 3: the demo scope was the easy scope
Prototypes are built on clean examples. Production means the malformed inputs, the permissions questions, the escalation path, and the audit trail — work that is unglamorous and larger than the prototype. Scoping from the demo guarantees the estimate is wrong.
Cause 4: nobody agreed who is accountable when it errs
Deployment stalls at the question of who carries a bad output. Answering it early — with clear escalation on stakes and a named reviewer — removes the objection that otherwise appears at the final approval.
Ship something narrow instead
The reliable cure is a smaller first release: one workflow, one team, real traffic, in production. A narrow live feature teaches you more in a fortnight than a broad pilot does in a quarter, which is why the first jobs should be small and verifiable.