The pattern is always the same. A burst of enthusiasm. A promising demo. A quarter of drift. A quiet death in a planning meeting where the project isn't cancelled — just "deprioritized."
Post-mortems blame the technology, because that's the polite thing to blame. But the model worked fine in the demo. What failed is everything around it.
01The three real causes
- ▸No owner. The project belonged to a committee, an innovation function, or a vendor. The moment it needed a decision — access, budget, a process change — it waited. Waiting is how software dies.
- ▸No wiring. It lived in a separate tab. The workflow it was meant to improve kept running the old way, one browser window over, out of habit and convenience.
- ▸No number. Nobody agreed what would move. So when budget season came, the project had demos and anecdotes, and the ERP upgrade had a spreadsheet. The spreadsheet won.
02The stall timeline
Stalls feel sudden but follow a schedule. Knowing the schedule lets you intervene before the quiet death, because each phase has a visible symptom and a cheap correction.
- ▸Weeks 1–2: the demo high. The prototype impresses everyone. Danger hides here: the demo ran on curated inputs, and nobody wrote down what "working" means on real ones. Correction: define acceptance criteria while enthusiasm is cheap.
- ▸Weeks 3–6: the access stall. Real deployment needs credentials, API scopes, security review, a column someone guards. Each request waits days. Correction: a named owner with authority to grant access — decided at kickoff, not discovered mid-build.
- ▸Weeks 7–10: the parallel-process era. The tool works, but the team still runs the old way "just in case." Two processes now cost more than one. Correction: pick a cutover date and make the new path the default, with the old one as documented fallback.
- ▸Weeks 11+: the budget ambush. Planning season arrives and the project has no number to defend itself. Correction: one metric, reported weekly since week 1 — even when the early numbers are unimpressive. A boring trend line beats a great anecdote.
03The fix is boring
Give the work an owner with authority. Wire the system into the tools people already live in. Pick one number and report it weekly. Ship a smaller thing sooner, and let usage — not opinion — decide what gets built next.
That is the entire playbook. It isn't exciting. It's just what shipping looks like.
04Restarting a stalled project
If you have one of these zombies on the books, do not "relaunch" it — relaunches inherit the original sin. Instead:
- ▸Declare the old scope dead, publicly. Ambiguity about whether v1 is still alive kills v2.
- ▸Assign a single owner who wanted it all along. There is always one — find the person who kept bringing it up.
- ▸Cut it to a 30-day wedge using the narrowest slice that runs daily (see FM-02).
- ▸Report one number weekly from day one — the habit matters more than the early data.
05Running the diagnosis in one meeting
You can diagnose a live project against the three causes in a single thirty-minute session, and the questions are blunt on purpose. Ask the room: if this project needed a new API credential tomorrow, who grants it without asking anyone? Silence means no owner. Ask: show me where the output appears inside the tools the team already uses. A separate tab means no wiring. Ask: what number goes up if this works, and who reports it? A pause means no number.
The useful part is what the answers force. Each miss converts directly into an action with a name attached: appoint the owner, schedule the integration, pick the metric. Teams often resist the diagnosis because it feels reductive — surely the project is more complicated than three questions. It isn't. The complexity lives inside the build; the stall always lives in the scaffolding around it.
Run the same three questions in kickoff meetings for new projects and you get the inverse benefit: a project that can answer all three in week zero almost never joins the zombie portfolio.
06Anti-stall design, from day zero
The cheapest time to prevent a stall is before the project starts. Four commitments, extracted at kickoff, close off the standard failure modes:
- ▢A named owner who can approve access, spend, and process changes without convening a meeting.
- ▢Written acceptance criteria — what a user can do on day 30 that they can't do today.
- ▢A cutover plan: the date the new path becomes the default, agreed before the build starts.
- ▢One weekly metric and the person who reports it — the same slide, every week, forever.
OPERATOR NOTE — If your AI project has a steering committee but no owner, it has already stalled. It just hasn't told you yet.
Put this thinking to work.
A 30-minute strategy call with an operator — we'll map your first deployment path, not send a deck.