Most doomed AI projects are recognisable in the first meeting. Not because anyone is incompetent — usually the opposite — but because the project is shaped wrong from the start, and the shape is visible if you know what to look for.
This is the *pre-commitment* view. Why your AI pilot never reached production is the post-mortem: the engineering gates that separate a demo from a deployed system. This piece is earlier and cheaper — five tells, each with a question you can ask out loud before anyone writes code.
The stakes justify the paranoia. 95% of enterprise generative-AI pilots deliver no measurable P&L impact (MIT Project NANDA, 2025), and Gartner expects more than 40% of agentic-AI projects to be canceled by the end of 2027 (Gartner, 2025). Those are mostly projects that never should have been funded in the shape they were funded.
Tell 1 — It starts with the technology
The project began as *we should be using AI* and worked backwards to a use case. You can hear it in how it's described: capability first, problem second, and the problem sounds slightly retrofitted because it is.
Ask: *what were we going to do about this before AI existed as an option?* If the honest answer is "nothing, it wasn't a priority," you're looking at a technology in search of a justification. That's not automatically fatal — but it means there's no baseline urgency to carry the project through the hard middle, and every AI project has a hard middle.
Tell 2 — Nobody can name whose day gets better
Healthy projects have a person attached. *Priya in support stops spending her mornings triaging.* Doomed ones have an abstraction: efficiency, the customer experience, the organisation.
Ask: *whose specific job changes on the day this ships, and have we talked to them?* If nobody's day changes, nobody will adopt it. And if the person whose day changes hasn't been consulted, expect to discover in month four that the workflow has exceptions the plan didn't account for — because it always does, and they're the only one who knows them.
Tell 3 — Success is defined as launch
Listen to how done is described. *Deployed by Q3.* *Live in the support flow.* Those are milestones, not outcomes — and a project whose definition of success is its own existence cannot fail, which means it also cannot succeed.
Ask: *what number will be different in ninety days, and who reports it?* A project that can't answer will produce something that launches, gets a congratulatory email, and quietly stops being used. That's the modal outcome, and it's worse than a visible failure because nobody learns anything.
Tell 4 — The sponsor can't say what stops
If the AI does the work, something a human does now must stop, shrink, or change. A sponsor who hasn't thought about that hasn't thought about the project — they've thought about the demo.
Ask: *what do we stop doing when this works?* Hesitation here predicts the parallel-run that never ends: the agent handles cases, humans check every one forever, and the saving never materialises because the old process was never actually retired. The answer can legitimately be "nothing stops, we absorb more volume with the same team" — that's a fine answer. Having no answer is not.
Tell 5 — It's a demo hunting for a budget
Someone built something impressive, showed it around, and now the organisation is looking for a problem worthy of it. The tell is that the project's champion is whoever built the prototype rather than whoever owns the workflow.
Ask: *if this prototype didn't exist, would this be in our top five priorities?* If not, the prototype is doing the arguing, and prototypes are extremely persuasive about their own necessity.
The five, as questions
| Tell | Ask | Bad answer sounds like |
|---|---|---|
| Technology first | What were we doing about this before AI? | Nothing, it wasn't a priority |
| No named beneficiary | Whose job changes, and have we asked them? | It helps the whole org |
| Launch as success | What number changes in 90 days? | We'll define KPIs post-launch |
| Nothing stops | What do we stop doing when this works? | Hesitation, then "good question" |
| Demo-driven | Would this be top five without the prototype? | But have you seen the demo? |
What to do when you spot one
Killing it is rarely the right move, and rarely politically available. Reshaping it usually is:
- Re-anchor on a costed workflow. Find the work already consuming 15+ hours a week and point the project at it. Most doomed projects are aimed at the wrong target rather than being fundamentally bad ideas — the five signs are the qualification test.
- Attach a name and a number. One person, one metric, before more money is spent. This is the cheapest intervention available and the most predictive.
- Redefine done as running unattended, not as deployed. It changes what gets built, starting immediately.
- Shrink it until it's fundable on evidence. A two-week fixed-price diagnostic that ends in a deployed pilot tells you more than another quarter of planning, and it's cheap enough to be wrong about.
If you'd rather diagnose the organisation than the project, the AI Readiness Assessment scores the five operational dimensions underneath all of this. And the reason our engagements start with a paid Audit phase is precisely this: the most expensive AI project is the well-executed one aimed at the wrong problem.
