What does a failed AI rollout actually look like?
It rarely looks like failure. Nobody announces that the project is over. The licences stay on the invoice, a handful of enthusiasts keep using the tool for emails and summaries, and everyone else quietly goes back to the way they worked before. Six months later a partner asks what the firm got for the money and nobody can point to a single job that now takes less time.
That quiet fade is the most common outcome, and it is worth recognising early because it costs more than it seems. The firm pays for the software, pays for the time spent on training, and loses some appetite for trying again. The next proposal to do something with AI meets a reasonable question: we tried that, what is different this time?
What are the usual causes?
The same handful of causes turn up again and again. Most rollouts suffer from more than one.
- Nobody owns the outcome. IT owns the licences, a partner sponsored the purchase, and the people doing the work were told it was available. No named person is responsible for a specific job getting faster, so nobody is.
- The rollout starts with the tool, not the job. The question asked was "how do we use this?" rather than "which piece of work costs us most, and what would fix it?" A general answer to a general question produces general, occasional use.
- Too many uses at once. Staff are shown twenty things the tool can do. Each gets tried once. None becomes routine, because routine comes from doing the same thing the same way every week.
- It is tested on demonstrations, not live work. A tidy example works in the training room. The real engagement has a messy file, three versions of a template and a client with a particular way of doing things. The first time it meets real work, it struggles, and trust drains away.
- There is no baseline. Nobody measured how long the job took before, so nobody can show it takes less time now. Without that evidence the project has no defenders when budgets are reviewed.
- Review is left undefined. Fee earners are unsure whether AI output can go to a client, who checks it, and against what. Faced with that uncertainty, careful people do the sensible thing and avoid it on anything that matters.
- Support stops at launch. The first fortnight after go-live is when small problems appear. If nobody is there to fix them, people route around them, and the old way comes back.
Why does more training not fix it?
Training is the most common response to a stalled rollout, and it usually disappoints. Training teaches people what a tool can do. It does not change the steps, templates, handoffs and checks that make up the job. A fee earner who has been on the course still opens last month's document, still gathers the same inputs from the same places, and still spends the same evening formatting. The tool is one more window on the screen. The differences between building knowledge and changing the work itself are set out in training or implementation, and the underlying point is explored in a tool is not a process.
How can you tell whether your own rollout is failing?
Ask four questions. They take ten minutes and they are more reliable than any usage dashboard.
- Can you name one specific job, such as a monthly client report or a bid response, that is now done differently because of the rollout?
- Can you name the person responsible for that job running the new way?
- Do you know how long the job took before and how long it takes now?
- Would a new joiner learn the new way as the normal way, without being told it is optional?
If the answer to any of these is no, the rollout has not changed how the firm works yet. That is not a reason to give up. It is a sign of where to focus.
What does a rollout that works do differently?
It narrows. Instead of giving everyone a capability and hoping, it picks one process that repeats, follows a recognisable structure and costs senior people real time. It maps how that job runs today, with the people who do it. It rebuilds the job around the firm's own documents and templates, in tools the team already uses. It tests on live work, so problems surface while there is still time to fix them. It sets out who reviews what before anything reaches a client. And it measures the time the job takes before and after, so the result is a number rather than an impression.
That is slower to announce and faster to deliver. One process running properly does more for a firm's confidence than a dozen experiments. It also gives the next project an answer to the question "what is different this time?" What to automate first covers where to begin.
How do you rescue a rollout that has gone quiet?
Stop trying to revive it firm-wide. Find the few people who kept using the tool and ask what they use it for; their habits often point at a job worth rebuilding properly. Choose one process, give it an owner with the time to see it through, and record how long it takes today. Then rebuild that single job end to end rather than adding more prompts on top of the old way. Check whether staff have drifted to personal AI accounts in the meantime, because that is a common side effect of a stalled rollout and it carries its own risks, covered in shadow AI.
If you are not sure which job to pick, the audit estimates where your fee earners' unbillable hours go and names the process to start with.