AI in practice

The programmes that stall are short of a question

Ask why an AI programme stalled and the answer comes back technical. Underneath it there is usually a question nobody had formed properly, with nobody waiting for the answer.

In short
  • Gartner names unclear business value among the reasons agentic AI projects get cancelled, alongside cost and risk controls.
  • A well-formed question has an owner, a decision attached and a date. Most AI requests have none of the three.
  • Supply-led AI produces impressive output that nobody was waiting for.
  • Fix the question and the technology question usually gets smaller.

Ask why an AI programme stalled and you will usually be told something technical. The data was not ready. The integration was harder than expected. The model was not good enough for the use case.

Some of that is true. Most of it is downstream of something earlier, which is that nobody had a properly formed question.

What a well-formed question looks like

It has three things, and the absence of any one of them is enough to sink the work.

An owner. A named person who wanted to know, and who will do something differently depending on the answer. "The business" is not an owner, and neither is a committee.

A decision attached. The answer has to change what somebody does. If the same thing happens whatever the answer, you have a report, and reports are cheap to produce and easy to ignore.

A date. By when is the answer useful. This is the one that gets left out, and it is the one that tells you what quality of answer is actually needed. An answer next quarter to a question that mattered last week is not a slightly late success. It is a complete failure that looks like a success in a status report.

Most requests that arrive at an AI team have none of those. They have a topic.

What the research says, and what it does not

Gartner's prediction that more than four in ten agentic AI projects will be cancelled before the end of 2027 is widely quoted. The part worth reading is the list of causes: escalating costs, unclear business value, inadequate risk controls. Two of the three are commercial and one is governance. None of them is capability.

That matches what we see. The technology is rarely the blocker. The blocker is that the thing being built was never attached to a decision anybody was waiting to take.

Supply and demand get confused

Here is the pattern, and we have been guilty of it ourselves.

A capable team acquires a capable tool. The tool can produce analysis, summaries, recommendations, drafts. So it does. Output appears, it is genuinely good, and it is circulated.

Nobody asked for it.

It gets read, sometimes. It rarely changes anything, because the person who might have acted on it was not waiting for it and has their own list. The team producing it concludes that the business is slow to adopt. The business concludes that the team is producing things nobody needs. Both are describing the same failure from opposite ends.

The tell is simple. Count how much of what you produce can be traced back to a question somebody actually asked. If the answer is uncomfortable, that is the finding.

The two changes that worked

Start from the question, in the requester's words. Not the topic. The question, written down, with the name of whoever needs it and the date they need it by. If it cannot be written in one sentence, it is not ready to be answered.

Say no to unattached work. This is the hard one, because unattached work is usually interesting and always easier than finding out what somebody actually needs. Producing it feels productive. It is the thing that keeps a team busy while the value sits somewhere else.

We are moving the first conversation of our client engagements to this model. The objective is written down in the client's words, the aim is to surface the gaps the conversation missed while the client is still in the room, and the client signs the confirmed objectives before anything is built. It is slower on day one. It is designed to catch early the change requests that used to arrive in month three. How that first conversation works is on AI-assisted engagement and delivery.

The uncomfortable implication

If you take this seriously, the first phase of an AI programme is not a technology phase. It is a period of finding out what questions the organisation is actually trying to answer and which of them are currently going unanswered or answered too late.

That work is not exciting and does not demonstrate well. It is also the only part of the programme that decides whether anything gets used.

We did that exercise properly, with numbers, and what came back was worse than we expected.

Before we get to that, the next piece turns the same discipline outward, at a change already in consultation that will reach every VAT-registered business in South Africa.

Keep reading

More from Insights

AI in practice

Activity is not progress

Last of three. A process can be dramatically faster while the business barely moves. The smaller number was far less impressive and much more useful.

18 September 2026 · 4 min read