The change management plan arrives in week eight, written by someone who wasn’t in the architecture sessions, didn’t attend the roadmapping workshops, and hasn’t spoken to the stakeholders most affected by the program. It contains a communication calendar, a training schedule, and a resistance analysis; all of it looks professional, and almost none of it will accomplish anything.
Four Artifacts Expose the Disconnect
The plan references milestones accurately but does not reflect the discussions, tradeoffs, and political dynamics that produced them.
The communication plan is a calendar of emails: launch announcement, progress updates, go-live notification. The emails will be sent, skimmed, and forgotten because information alone does not produce behavior change.
The training plan is designed around system features rather than job changes. A patient services coordinator who needs to learn a new patient enrollment workflow gets a training module on the hub software interface. The software is the mechanism; the job change is the thing that needs to be managed.
The resistance analysis lists “people don’t like change” as the top risk. A real resistance analysis names specific groups and specific concerns: the field medical team resists because the new call planning process adds documentation requirements they view as administrative overhead; the commercial leads resist because the launch sequencing was set without input from their regional medical science liaisons. These are different problems with different solutions.
Adoption Is a Design Problem
Change management gets scoped as a communications function. The implicit model is that the program team designs the change and the change management team tells people about it. Under this model, the change management lead doesn’t need to be in the planning sessions.
This model fails because adoption is a design problem. When how the engagement feels shapes what happens after it ends, the transition experience matters as much as the deliverables. The question is how to design the change so that the people affected by it can make the transition. That question can’t be answered after planning is done; it has to be answered during planning, when we’re making decisions about scope, sequencing, and rollout that directly determine how the change will land.
Change Management Starts During Stakeholder Mapping
In a well-designed engagement, change management starts during stakeholder mapping, when one-on-one interviews surface who will be affected, how they see the program, and what concerns they carry. It continues during architecture, when we define what changes and for whom. The change management lead needs to be in the room for these decisions because the design of the change is inseparable from the design of the transition.
It continues during the pre-mortem, when the consulting team identifies adoption risks (e.g., “field teams won’t adopt the new call planning process because training is scheduled during a congress cycle when they’re traveling”). A finding like that shapes both the rollout plan and the change management approach.
By the time we reach roadmapping, the change management plan should be a synthesis of everything learned across stakeholder interviews, architecture, and the pre-mortem, designed by someone who was present for those conversations. The real work is planning for the people not in the room: the hundreds or thousands of employees who will experience the change without having participated in designing it.
The Change Management Lead Belongs in the Room from the Start
The fix is structural: the change management lead is in the room from stakeholder mapping forward. They participate in interviews, sit in on architecture sessions, and attend the pre-mortem and roadmapping workshops.
The plan they produce looks different from the afterthought version:
- Targeted interventions for specific groups based on what surfaced in interviews, paired with job-change workshops that address the actual transition people need to make
- A resistance map that names who pushes back, why, and what the program will do about it
Change management designed from the start produces adoption; change management bolted on at the end produces a calendar of emails that nobody reads. When rollout begins, every wave earns the next, and teams that skip this work discover it the hard way when a rollout that skips wave lessons forces them to re-learn what the first deployment already taught.
