A state health department was modernizing how its data moved. Everyone involved knew the effort would live or die on its people. The staff closest to the data had seen initiatives come and go. A change plan written in a conference room was going to join the pile. So we didn't write one there.
Data modernization plans usually get written about the systems and around the staff. We inverted that. Before any plan existed, I led stakeholder interviews with the data stewards themselves: the people whose daily work the modernization would change most, and whose quiet non-adoption could sink it quietly.
Those conversations weren't requirements-gathering. They were about what the stewards valued, what earlier change efforts had felt like from the inside, and what would make this one different. The stewards most skeptical of the effort turned out to know the most about where it could go wrong.
The standard failure mode is a template: a communications calendar, a training schedule, a readiness survey, all copied from the last engagement. It fails because it treats resistance as an obstacle to manage rather than information to use.
The department didn't need to be persuaded harder. It needed a plan its own people could recognize themselves in: one built from the values the stewards had actually named, and honest about what the change would ask of them.
The department got a change management plan grounded in its staff's own values and words, designed from the start to be executed by the department itself. Building their capacity to carry it was the point of the engagement.
It's the same method as every build on this site: go to the people who live with the problem first, treat what they tell you as the design input, and leave them owning the result. I treat change management like a product problem: the thing you're actually shipping is adoption.