Business practice
AI change management.
A rollout that arrives as an announcement gets treated as one. You get a change plan built for the people doing the work, so the new way survives the first busy week.
The first busy week decides whether a change survives. Almost nothing else does.
A rollout announced at an all hands is a message, not a plan. People nod, the deck circulates, and then a deadline lands and everyone reaches for the way of working they already trust. By the time anyone notices, the new process has quietly become optional.
What holds is a change plan built around the people who have to do the work differently. That means knowing where the resistance actually sits before you design the training, teaching the real task rather than the feature list, and coming back after go-live, when the drift starts and nobody is watching.
The approach
Three words we work by.
Ask.
Resistance gets asked about rather than assumed. Short conversations with the people whose work changes, plus an anonymous read where seniority would keep someone quiet. Most of what surfaces is practical: a step that breaks, a client who will notice, a busy period nobody upstream accounted for.
Train.
Training is built around the task somebody actually has to finish, not around the features of the tool. People practise on their own live work, with their own examples, so what they leave with is a way to get Thursday done rather than a set of screenshots they will never open again.
Check.
A checkpoint is scheduled after go-live, at the point where attention has moved on and the old way starts creeping back. It is a short, specific look at whether the new way is being used, where it is being worked around, and what needs fixing before the workaround becomes the standard.
The work
Four workstreams, in sequence.
Resistance read
Conversations with the people whose day changes, plus an anonymous route for anything they would not say out loud. You get the real objections, sorted into the ones that are a training problem, the ones that are a process problem, and the ones that are telling you the plan is wrong.
Change plan
A plan written for the people doing the work: what changes, when, who is affected, what they stop doing, and who they ask when it breaks. It names the busy periods it has to survive and sequences around them rather than through them.
Training on the real task
Sessions built on your own live work, run in small groups, with the procedure written down afterwards in your team's words. Anyone who joins next month can follow the same path without needing the person who ran the session.
Post go-live checkpoint
A scheduled return after the attention has moved on. Usage looked at honestly, workarounds surfaced without blame, and a short list of fixes made while changing them is still cheap.
Related reading.
All insights
Governance
Shadow AI is already in your firm. Here is the map.
The median hundred person company shows between fourteen and twenty two distinct generative AI services in its browser telemetry. One or two of them are approved. The gap is not a technology problem and it is not solved by blocking domains, because the work that drove people to those tools does not go away when
Operations
The two-person dependency test
Pick any critical workflow and ask one question. If these two specific people were both unreachable for a week, what happens. If the honest answer is that things quietly stop, you have found the real risk register of your firm, and it does not appear in
Questions
Asked before, answered plainly.
Usually, and often faster than the first attempt. A stalled rollout has told you exactly where the friction is, which is information the first attempt did not have. We start by asking the people who went back to the old way why, and that conversation is normally where the plan comes from.
A short conversation each for the people whose work changes, and one training session in a small group. The plan and the write up are our work, not homework we hand back to your team. The heaviest ask is the checkpoint after go-live, and that is an hour.
It is written for them because that is where we are asked most often, and because AI rollouts fail in a particular way: people quietly stop using the tool and nothing on a dashboard says so. The same plan works for a new process or system. The questions do not change much.
Then the plan changes. Some of what surfaces is not resistance at all, it is people telling you the new way breaks something you did not know about. Finding that in week one is the point. It is far cheaper than finding it in the first busy week with clients watching.
The checkpoint looks at use, not opinion. Is the new way showing up in the work, where are people routing around it, and has anything quietly reverted. You get that read in writing, with the fixes worth making, while they are still small.