AI Change Management: Why Your Rollout Stalled

AI change management fails not because the tools break, but because organizations skip the work redesign that makes tool access mean anything. A framework built for how AI actually changes work.

Your AI pilot worked. The model performed. The vendor demo was clean, the accuracy numbers held up in testing, and the business case got approved. Six months after rollout, usage has flatlined and the productivity gains never showed up in the numbers.

This is not a technology story.

The tool worked. The deployment didn't.

Dell'Acqua et al. (2023) ran a field study with consultants using AI tools and found something that should make every rollout leader uncomfortable: workers performed better on tasks that fell inside the tool's competence zone and worse on tasks that fell outside it. The model was the same across both groups. The variation came from how workers applied it to different task types. That is a role-design and judgment problem, not a model quality problem.

Brynjolfsson, Li, and Raymond (2023) found productivity gains in field conditions where workers had structured support, not just access. Access alone did not move the needle. The conditions around use did.

Acemoglu and Johnson (2024) pull this back to a longer pattern: across multiple waves of new machinery, the tools that generated value were the ones paired with deliberate work redesign. The tools with the best technical specifications, deployed into unchanged work structures, did not outperform them.

What generic change models miss about AI adoption

Prosci's ADKAR model is fine for a one-time system migration. Awareness, desire, knowledge, ability, reinforcement. It covers the sequence. The problem is that AI does not change work at the process level the way an ERP replacement does. It changes work at the task level, inside roles, sometimes inside individual decisions. A rollout plan built for a single-event transformation treats AI adoption as a destination. It is not. It is an ongoing adjustment to how specific people do specific work.

[Inference] Most enterprise rollouts I have seen treat ADKAR as a checklist rather than a design constraint, which means reinforcement, the phase that actually determines whether new behavior sticks, gets cut when the project timeline compresses.

Westerman, Bonnet, and McAfee documented this failure pattern across digital transformation broadly in their 2014 research: firms that bought technology without changing how people worked did not win against firms that paired adequate technology with strong leadership and deliberate process change. The AI version of this pattern is running now, at scale, in most large organizations.

The McKinsey objection is real, and it does not change the argument

McKinsey and Gartner both point to data quality, model fit, and governance as genuine failure drivers. They are right. A model built on bad data will produce wrong outputs regardless of how well the rollout is managed. No amount of manager coaching rescues a tool that hallucinates at a rate that makes its outputs untrustworthy.

The thesis here is not that technical quality is irrelevant. It is that even when the technology works as intended, programs stall without role-specific rollout, manager engagement, and work redesign. McKinsey and Gartner are describing a different failure mode: programs where the technology never worked in the first place. Those are real. They are also outside the scope of what most stalled rollouts are actually experiencing.

What a framework built for AI adoption actually requires

Role-based deployment decisions come first. Dell'Acqua et al. (2023) make this unavoidable: blanket deployment across a function, without identifying which tasks inside each role fall inside the tool's competence zone, sets workers up to misapply the tool on the tasks where it will hurt them.

Manager behavior is the second lever, and it is the one most rollout plans skip entirely. MIT Sloan Management Review's AI and workforce research from 2024 to 2026 repeatedly identifies manager support and workflow fit as the key blockers in adoption, separate from training. Managers who do not use the tool themselves, or who do not reinforce its use in daily work, create an implicit signal that the rollout is optional.

Work redesign is not a phase that follows rollout. It is a condition for rollout. If the job description, the performance metrics, and the daily workflow do not reflect the new tool, employees will default to the old method. Not out of resistance. Out of rationality.