Change Management Is the Actual Bottleneck

A program ships. The system works, the integration holds, the accuracy is good. Six months later the promised benefit has not appeared, and an investigation finds that roughly the same number of people are doing roughly the same work, now with an additional system alongside it.

This is not a rare outcome. In my experience it is the single most common way an enterprise system delivers less than it promised, and it has almost nothing to do with the quality of what was built.

Delivered, available, used, trusted, and sustained are five separate states. Programs are funded and measured on the first and report as though it implies the fifth.

Why this hits AI programs harder

Every enterprise system has an adoption problem. Agents have a sharper one, for three reasons that are specific rather than general.

The output requires a judgment the user did not previously have to make. A report is either run or not run. An agent's proposal has to be assessed: is this right, do I trust it, what happens to me if I approve it and it is wrong. That is a new cognitive task added to somebody's day, and if it takes longer than doing the work, a rational person stops using it. Quietly, without filing anything.

Trust is asymmetric and slow to rebuild. A person who is burned once by a wrong output will check every subsequent one by hand, which converts the tool into pure overhead while it continues to report healthy usage numbers. One bad week in month one can cost a year, and nothing in the telemetry shows it, because the clicks still happen.

And the accountability did not move. This is the part programs consistently underplay. When an agent proposes and a human commits, the human is answerable for the commit. They have taken on review work and kept all of the risk. If nobody has explicitly addressed what happens when they approve something the agent got wrong, they will assume the worst, and they will be careful in the way that removes the benefit.

Where the value actually leaks

Between delivered and available you lose access, permissions, and licensing. Unglamorous, easily fixed, and it routinely costs a program its first month, because nobody owned it and everybody assumed somebody had.

Between available and used you lose to workflow placement. If the agent lives in a system the user does not have open, in a tab they must remember, it will not be used, regardless of quality. Work happens where work already happens.

Between used and trusted you lose to the review burden described above, and to the absence of an obvious way to report a bad output. A user with no channel to say "this one was wrong" concludes that nobody wants to know, which is often correct and always fatal.

Between trusted and sustained you lose to the old process never being retired. Where both paths remain available, under any pressure at all, people revert to the one they know, and the parallel path silently becomes the real one again.

What actually works

Retire the old path deliberately, on a date, with a named owner. Not as a hard cutover on day one, which is reckless, but as an explicit decision with a schedule. Programs that leave the old process running indefinitely have not de-risked the change, they have guaranteed the reversion.

Put it where the work already is. Inside the system they already have open, in the queue they already work through, in the document they already produce. Every context switch you add is a tax collected on every single use, forever.

Answer the accountability question in writing, before rollout, at a level of seniority that makes it real. Something on the order of: you are accountable for reviewing to a stated standard, and if you did that and the output was still wrong, that is the program's failure and not yours. Vague reassurance in a town hall does not do this. People need to know what happens on a bad day, and they will assume the harshest answer until told otherwise.

Make reporting a bad output take one action. And then close the loop visibly, because the second most demoralizing thing is a feedback mechanism that goes nowhere. The reports are also your best eval cases, so this pays twice.

Find the people who are already trying to make it work and give them the time. Every rollout has them. They are usually not the ones nominated, they are already doing this on top of their real job, and formalizing that with actual protected hours is the highest return spend in the program.

Measure trusted and sustained, not delivered. Ask what share of proposals are accepted without being redone by hand, and whether the manual path has actually stopped. Those two numbers tell you the truth. Usage counts will happily rise while both of them fall.

The uncomfortable position

The honest reason change management gets underfunded is that it is nobody's specialty and everybody's afterthought. It is not engineering, so the technical program does not own it. It is not strategy, so the sponsor treats it as execution. It gets handed to a communications workstream, which produces a deck, a training session, and a launch email, none of which change anybody's incentives.

And incentives are what is actually in play. If a person's manager measures them on throughput, and the agent makes them slower for six weeks while they learn to trust it, they will not use it, and they are behaving correctly. No amount of enablement fixes an incentive that points the other way. Someone with organizational authority has to change what is measured, temporarily, and absorb the dip.

That is why this cannot be delegated downward. It is the part of an AI program that is not about AI at all, it is the part most likely to determine the outcome, and it requires exactly the authority that the people closest to the work do not have.