Technology Is Only Half The Battle
Two failures, same week
Two conversations, a few days apart, about two businesses that had both spent real money trying to get ahead on AI. Neither person used the word failure. Both would get there eventually, if you pushed.
The first was an operations director at a distribution business, walking me through the usage dashboard for the AI assistant they had rolled out to forty people eight months earlier. Six logins in the past month, out of forty seats. He wasn't defensive about it, just tired. "We bought the proper version," he said. "We even sent round a training video." Nobody had changed a single thing about how anyone actually built a shipment schedule or answered a customer query. The tool had landed on top of the old process like a coat of paint over damp: it looked like progress for a fortnight, and then the damp came through anyway.
The second was a partner at a professional services firm that had run a genuinely good two-day workshop on using AI in client work. People left that room energised. One of them told me it was the first internal training day in years that hadn't felt like a write-off. Six weeks later, the same person was back to building the same report in the same spreadsheet, the same way, because that was still the only system anyone had given them to build it in.
Different businesses. Different budgets. Different departments running point. Same ending: nothing durable changed. The more of these I sit through, the more convinced I am that they are not two different problems. They are one problem, wearing two different outfits.
The shelfware problem
The first failure is the one that gets talked about most, because it leaves a paper trail. Somebody signs a contract, licences get provisioned, a rollout email goes round, and for a while the project looks, on paper, like it happened. It has a budget line, a start date, and an owner in IT or operations who can report, honestly, that deployment is complete.
What it doesn't have is any change to the work itself. The report still gets built the same way. The customer query still gets handled through the same three-step process it always has. The tool sits next to the job rather than inside it: available to anyone who wants to go looking for it, required by no one, embedded in nothing. Most people, reasonably, don't go looking. They have a job to do and a way of doing it that already works well enough to get through the day.
Usage craters within a couple of quarters, and what follows is worse than nothing happening. The team watched real money get spent on something that was never going to change how they worked, and they were right about that before anyone else was willing to admit it. That correct, quiet scepticism doesn't go away. It gets banked, and it gets spent against whatever comes next with the word AI attached to it.
The workshop hangover
The second failure is the mirror image, and it's the one that catches people out because the room genuinely felt like it worked. Good facilitation produces real enthusiasm. People leave wanting to work differently, and they mean it.
Then it's Monday. The CRM has the same fields it had on Friday. The report template hasn't moved. The approval chain still needs three people to sign off by email before anything ships. The manager who has to approve time spent experimenting is still measured on the old throughput numbers, so that's what he protects. Nothing about the actual infrastructure of anyone's day has changed to hold up the new intention, and intention on its own is no match for infrastructure. Infrastructure is what's waiting at eight o'clock on a Tuesday morning, when the to-do list is already too long to try something new.
Within a few weeks, the old defaults have quietly reasserted themselves: not because anyone stopped caring, but because nothing in the system gave the new habit anywhere to live. What's left is a slightly worse position than the one they started from. A team that tried to change, watched it not take, and is now a little more cynical about the next workshop than it was about this one.
One failure, not two
On the surface these look like opposite problems. One is a technology story: money spent, nothing adopted. The other is a people story: enthusiasm generated, nothing sustained. Treated as separate diagnoses, they get separate fixes, better change management for the second, better tool selection for the first, and both fixes miss what's actually wrong.
The common root is simpler than either fix admits, and we see it often enough now to be confident of it. In both cases, exactly one half of the system moved, and the other half stayed exactly where it was. A tool dropped into an unchanged workflow is just new furniture in an old room: it doesn't matter how good the furniture is if nobody's rearranged the room around it. A room full of new intentions with no rebuilt workflow to carry them is enthusiasm with nowhere to go: it doesn't matter how genuine the intention is if the system it has to operate inside hasn't changed shape. Neither half is sufficient alone. The tool gives a new habit somewhere to live. The new habit is the only reason the tool gets opened twice.
This is also why doing them in sequence, tool first or culture first, tends to fail worse than doing neither. A team that has never been offered an AI tool is simply uninitiated. A team that watched licences get bought and quietly die, or sat through a workshop that visibly changed nothing, has learned something specific: that this is what "the AI thing" looks like here, and it doesn't work. Whoever proposes the next attempt now has to spend the first few months undoing that lesson before they can teach a new one. That's a real cost, and it's the cost that "let's get the tool in and worry about adoption later" never counts.
Why it keeps splitting in two
If the fix is obvious once you see it, why doesn't it happen more often? The answer isn't that leaders don't understand the argument. It's that the existing structure of most businesses is very good at funding and reporting on each half separately, and much worse at funding and reporting on both together.
IT or operations holds the technology budget and reports on technology metrics: seats provisioned, uptime, licences activated. HR or L&D holds the people budget and reports on people metrics: sessions delivered, satisfaction scores, attendance. Both are legible. Both fit cleanly into a board pack, on a schedule the business already knows how to run. A genuine redesign of how a team actually works, with the tool built into the new process from the start, doesn't sit inside either budget line, doesn't have one clean metric, and doesn't have an obvious owner in the org chart, because it needs authority over the exact boundary where those two functions don't currently have to talk to each other.
So it splits. Not because anyone decided to split it, but because the two halves are what the existing structure already knows how to fund, schedule and report against. Nobody chooses this failure mode on purpose. The org chart chooses it by default, unless somebody with real authority over both halves deliberately overrides it.
What one piece of work actually looks like
Doing it properly means architecting the system and rebuilding the habits at the same time, as one project with one owner, not two workstreams that happen to share a launch date.
In practice: instead of "roll out the AI assistant to the finance team" running alongside, but separately from, "run a training day on using AI in reporting," it becomes one piece of work. Someone sits with the finance team and maps the actual report-building process end to end. They decide which steps the tool takes over, rebuild the template and the approval chain around that decision, and only then put the tool in front of anyone, already wired into the new process, with the training built into the rollout itself rather than sitting before or after it. Nobody's first experience of the tool is "here's a new app to try." It's "here's how the report gets built now," and the tool is simply part of why that's true.
That's harder to plan, because you can't start procurement on day one; you have to understand the workflow first. It's harder to sell, because it needs one person, or one small team, with authority over both the technology choice and the process redesign, who can't hide behind "the training was excellent, adoption is someone else's problem" or "the licences are live, whether people use them properly is a culture question." And it's exactly why the split version is so tempting: both halves can start immediately, on separate tracks, each looking like progress.
Done properly, this was never a project about doing the same work with fewer people. It's a project about the same people producing something like five or ten times what they currently do, because the tool and the workflow were redesigned together around what they're actually capable of, rather than bolted onto what they already had.
The question that exposes the gap
Before greenlighting any AI initiative, there's one question worth asking out loud, in the room, before any money moves: is there a single, accountable owner for both halves of this, the technology and the change in how people actually work? Or has it already split into two workstreams, each with its own budget, its own timeline, and its own version of progress to report?
If the honest answer names two people, two teams, or two board slides, both failure modes are already loaded, whatever the project plan calls itself. A second question: what happens in week one after the tool goes live? Does the old workflow still exist unchanged while people are asked to "start using" the new tool alongside it, or has the workflow already been rebuilt to require the new way of working? If the answer is that the workflow will catch up later, that's the tell. Later is where most of these initiatives go to quietly stall.
None of this needs a bigger budget or a cleverer model. It needs a refusal to sign off on either half in isolation, and an honest look, before anything is spent, at whether one owner genuinely exists for the whole piece of work, or whether two initiatives are about to be funded and called one.