I’ve watched too many manufacturing AI projects slowly die. The pattern is remarkably consistent. Problems emerge early but get ignored or rationalised. By the time leadership pays attention, too much time and money is gone.

Here are five warning signs I’ve learned to recognise—and what to do if you see them.

Warning sign 1: The timeline keeps slipping, but the explanations keep changing

Some schedule slip is normal for technology projects. But troubled projects slip in a particular way: each delay has a different explanation, and the explanations don’t actually resolve.

Month 1: “We’re waiting on sensor data access.” Month 3: “The data format wasn’t what we expected, so we need to rebuild the ingestion pipeline.” Month 5: “The model isn’t performing well on night shift data, so we’re collecting more training data.” Month 7: “Actually, the fundamental approach might need to change because…”

See the pattern? Each delay is attributed to a new problem. The previous problems are presumably solved, but somehow the timeline never recovers.

What this usually means: The team doesn’t actually understand the root causes of difficulty. They’re treating symptoms rather than underlying issues. Or they’re discovering that the problem is harder than anticipated but not confronting that reality.

What to do: Stop accepting new excuses. Get a clear-eyed assessment of what’s actually needed to complete the project. Is it three more months? Six? A complete reset? If the team can’t give you a credible answer, that’s information too.

Warning sign 2: Nobody can explain what the AI is doing

Ask the project team: “How does the AI make its predictions?” If you get vague hand-waving about neural networks and machine learning rather than a clear explanation, there’s a problem.

Explainability matters for two reasons. First, you can’t troubleshoot what you don’t understand. When the AI gives wrong outputs, how do you diagnose and fix the issue? Second, operators won’t trust a black box. If maintenance techs don’t understand why the AI is recommending a repair, they’ll ignore it.

What this usually means: Either the team doesn’t truly understand their own work (worrying), or they’ve built something too complex for practical deployment (also worrying).

What to do: Insist on explainability. Ask for examples: “Show me a specific prediction and walk me through why the AI made it.” If they can’t do this, the project isn’t ready for production—and maybe never will be.

Warning sign 3: The pilot worked, but production deployment keeps stalling

The demo was great. The pilot showed promising results. Everyone was excited. That was six months ago. Now there’s always a reason production deployment isn’t quite ready.

“We need to integrate with the MES first.” “IT security has concerns we’re working through.” “We want to expand the training data before full rollout.” “The vendor’s new version will be better, let’s wait.”

What this usually means: Often, the pilot success was overstated or couldn’t survive contact with real production conditions. Sometimes there are legitimate integration challenges. Sometimes the organisation simply isn’t ready for change, regardless of the technology.

What to do: Set a firm deployment date. Work backwards to identify what genuinely must be resolved before that date (vs. what would be nice to have). Force trade-off decisions. If deployment keeps being pushed, escalate to understand the real blockers.

Warning sign 4: The AI champion has left (or checked out)

Every successful project has a champion—someone who believes in it, fights for resources, solves problems, and keeps momentum. When that person leaves, moves to another role, or simply loses interest, projects die.

Watch for:

• The original project sponsor getting promoted and not naming a successor
• The technical lead moving to another project
• Key stakeholders stopping attending steering meetings
• Enthusiasm replaced by “let’s see how things go”

What this usually means: The project has lost organisational energy. Without a champion, obstacles don’t get removed, resources get redirected, and the project slowly starves.

What to do: If you’re the executive responsible, you need to either become the champion yourself or find a new one. If that’s not possible, it’s better to kill the project cleanly than let it linger.

Warning sign 5: The goalposts keep moving

The original goal was predictive maintenance to reduce unplanned downtime. Now somehow it’s evolved into a broader “digital transformation initiative” involving new dashboards, workforce analytics, and integration with systems that weren’t in the original scope.

Or the reverse: the ambitious original scope has been quietly trimmed down to something much less valuable. “Well, we can’t actually predict failures, but we can create nice visualisations of the data…”

What this usually means: Scope creep usually indicates unclear objectives or resistance to accountability. Scope shrinkage usually indicates the original goals were unrealistic and no one wants to say so.

What to do: Return to the original business case. What specific problem were you solving? What was the expected ROI? Is the current project still addressing that? If objectives have legitimately evolved, create a new business case. If the project has drifted, decide whether to refocus or cut losses.

What to do when you see these signs

Recognising problems is step one. Responding effectively is step two.

Get an independent assessment

Project teams have incentives to stay optimistic. Bring in someone without those incentives—internal audit, a different business unit leader, or external consultants—to assess the situation honestly.

Have the hard conversation

Struggling projects often continue because nobody wants to admit failure. Leadership creates pressure for success; teams fear looking bad; vendors want to keep billing.

Someone needs to say: “This isn’t working. Let’s talk about why and what to do.” That’s a leadership responsibility.

Consider your options

You generally have three choices:

1. Reset: Acknowledge problems, address root causes, restart with appropriate adjustments. This works when the underlying opportunity is real and the issues are fixable.

2. Pivot: The original goal isn’t achievable, but there’s a different, smaller goal that is. This works when partial value is better than no value.

3. Kill: Some projects should end. Better to cut losses and redirect resources than to keep pouring money into failure.

The worst option is continuing to drift, hoping things will improve without real changes.

Learn for next time

Failed AI projects have lessons. Was the problem selection wrong? Was the data foundation inadequate? Were expectations unrealistic? Did you have the right skills and partners?

Document these lessons. Otherwise, the next project will repeat the same mistakes.

A final thought

Not every AI project should succeed. Some ideas seem promising but turn out to be impractical. That’s how innovation works.

The failure mode to avoid is the slow death—months or years of accumulated cost without value, because nobody was willing to confront problems honestly.

Watch for the warning signs. Respond decisively. And don’t be afraid to call it when a project isn’t working.