Every AI project has a moment — usually somewhere between the enthusiastic kick-off workshop and the first sprint — where the organisation has to make a real decision.

Not the budget approval. Not the vendor selection. Not the architecture review. Those are necessary, but none of them are the decision that determines whether the project actually succeeds.

The real decision is the Go/No-Go gate at the close of Phase 1.

Most AI projects don't fail because the technology didn't work. They fail because nobody asked the right questions before the project started.

"So — what should we use AI for?"

It sounds like a simple question. It isn't. And the reason most organisations struggle to answer it isn't lack of ambition or budget. It's that "AI" has become a single word standing in for an enormous family of fundamentally different technologies — each with different requirements, different risks, and different definitions of success.

When a technology program starts showing signs of trouble, the instinct is to act fast. But speed without structure often makes things worse—more meetings, more pressure, more resources thrown at a problem nobody has actually diagnosed yet.

Most project delays do not happen because a team failed to do their job. They often happen because that team delivered exactly what they were asked to—and then discovered, too late, that something else they depended on was not ready.

Losing commercial control of a technology program is common. It happens gradually, often with good intentions, and frequently goes unacknowledged until leverage is significantly weakened. Restoring it does not require confrontation or crisis — it requires a structured sequence that reestablishes clarity, accountability, and commercial authority one phase at a time.

The true cost of a failing project often appears in places that never show up on a balance sheet.

If your engineering team is busy but not shipping, it’s tempting to assume there’s a productivity issue at the individual level.

In reality, it’s usually structural.

When a technology project is failing, speed matters—but clarity matters more.

When a technology project starts to fail, urgency takes over. Deadlines are missed. Costs rise. Pressure mounts. Leadership wants answers—and teams want direction.

Technology projects don’t usually fail overnight.
They unravel slowly—missed milestones, unclear priorities, rising costs, frustrated teams, and a growing sense that something isn’t right, even if no one can quite name it.