A change management plan connects an approved change with what people must do differently, the support they need and the evidence that the new arrangement is usable. It should name the affected work, decision owners, readiness conditions and the person who will sustain the change after the launch team steps back. Announcing a decision is one part of that plan, not the whole implementation.
This guide is for operating and people leaders planning a bounded workplace change. It offers an illustrative decision record, not a certified methodology, employment policy or replacement for technical, safety, quality or other required controls. Begin with the authorized scope; a planning conversation does not itself approve a change.
What belongs in a change management plan?
A useful working plan answers seven questions: What outcome is authorized? Whose work changes? What must be ready? Who can decide and support the work? How will concerns receive an answer? What evidence will distinguish adoption from attendance? Who owns the arrangement after implementation? Keep each answer specific enough that an affected person can use it.
Prosci’s explanation of change-management plans treats communication as one element alongside sponsor, manager and training activity. It describes tailoring plans, adapting them during implementation and sustaining change. Prosci presents its own framework; the work record below is our editorial application, not a reproduction of that framework, a certification or an affiliation claim.
Define the approved change and its boundary
Write a plain-language statement of the work that will change and the problem it is intended to address. Identify the authorized sponsor and process owner. Include exclusions: which teams, systems, policies and decisions remain outside the change? Separate a desired outcome from an assumption about how to achieve it.
Fictional example: a service organization has approved a new handoff arrangement for changed customer requests. The aim is to make an accepted change visible to the person responsible for the next customer update. The plan covers one team’s handoff, not a new CRM, revised customer promises or authority to bypass an approval. No Lean Leaders Plus client is depicted.
Map the work change for each affected role
For each role, describe the current action, the proposed action, the trigger and the information needed. Ask the people doing and receiving the work to walk through an ordinary case. A process diagram may show where a handoff belongs without showing whether someone can actually perform it.
In the fictional example, the request owner records an accepted change in the approved system. The receiving coordinator checks that record before preparing the next update. The manager resolves an unclear responsibility. An authorized sponsor decides what happens when two commitments cannot both be met. Those are different actions with different decision boundaries.
Identify temporary work as well: who keeps the existing service operating while people learn the new arrangement? If the plan assumes spare capacity, check that assumption. The priority and capacity guide helps examine what must pause or move rather than treating implementation as invisible extra work.
Check readiness before announcing that the change is ready
Readiness means the required conditions are available, not that everyone attended a launch meeting. Can affected people access the approved information? Do they know the trigger, required action and exception route? Is there appropriate time to practise? Are receiving owners available? Have the responsible specialists completed required checks?
Use a readiness record with the condition, evidence, owner and unresolved dependency. In the fictional example, a coordinator demonstrates how to find an accepted request change using a permitted sample. If access is missing, record that condition rather than marking training complete and assuming the workflow will function.
Name the authorized go, pause or escalation decision before rollout. If a required condition is absent, take it to that owner. Do not improvise a workaround that weakens a required control. A leadership plan cannot approve an unsafe technical fallback or change an employment arrangement.
Give sponsors and managers different responsibilities
The sponsor explains the purpose, decides within their authority and resolves cross-team constraints. Managers translate the approved change into work expectations, make practice feasible and surface unresolved conditions. The implementation owner coordinates dependencies and records decisions. The ongoing owner maintains the arrangement after handover.
Where responsibility is disputed, use a decision-rights matrix to clarify who decides, contributes and receives the answer. Naming a task owner does not automatically give that person authority to change priorities, policy or resources. Record those boundaries explicitly.
Explain the change and create a response route
Explain what changes, what remains the same, why the decision was made and when people should act. Tell each affected group where questions go and when an answer can be expected. The change-leadership communication plan provides a deeper audience, message and read-back approach. This broader plan additionally covers readiness, practice, adoption and continuing ownership.
Ask people to explain the next action in their own words and demonstrate it where appropriate. A delivered announcement, open rate or attendance count shows exposure to a message, not understanding or adoption. Keep the existing routes for confidential, safety and formal concerns available.
Investigate concerns before calling them resistance
A question about the change may identify unclear purpose, incompatible priorities, an unavailable resource or a genuine risk. Ask for the specific work condition and what evidence would resolve it. Do not infer a person’s motivation from hesitation or label every unresolved concern a training need.
In the fictional example, the coordinator says the new record cannot be checked before the agreed update time. The manager investigates access and timing rather than asking for a more positive attitude. If the concern needs a sponsor decision, name the dependency and report back. Listen without promising that every requested change will be approved.
Build practice around a real work decision
Agree a permitted practice case and the support available. Have the affected role perform the action, explain what information is sufficient and identify where an exception goes. Use an appropriate environment and qualified owners for any technical or regulated test; this guide does not authorize live customer or personnel experiments.
For the fictional handoff, practice includes an ordinary accepted change and a case with missing information. The coordinator can show both the expected action and the escalation boundary. A manager reviews what was unclear, updates the approved guidance through its proper owner and checks that the next practice reflects the decision.
Review adoption and the operating outcome separately
Adoption asks whether the new arrangement was used as intended. The operating outcome asks whether the original problem changed. Define each observation before rollout, including the population, period and relevant exceptions. Otherwise, a busy launch can become evidence for a result it did not measure.
In the fictional example, adoption evidence records whether accepted changes were available to the update coordinator at the agreed checkpoint. Outcome evidence records whether required customer updates could be confirmed at that checkpoint. Keep the same definitions when comparing periods and note changes in request mix, staffing or demand.
If adoption is incomplete, investigate usability, support and competing commitments. If adoption occurred but the problem remains, examine the next constraint. A before-and-after change alone does not prove causation or financial return. Where observations are too few or inconsistent, state that limitation rather than manufacturing a success score.
Transfer ownership before the project team leaves
Name the ongoing owner, the maintained guidance, the review routine and the exception route. Ask that owner to demonstrate how a new colleague will learn the arrangement and how a proposed adjustment will be considered. Resolve outstanding dependencies or leave them explicitly assigned with a next decision point.
The handover is not complete merely because the project team sent a document. The receiving owner needs usable information, authority and support. Record what remains unresolved and who can settle it. Avoid quietly transferring an impossible commitment to a manager who did not approve it.
Use the plan throughout the year
Annual planning can establish resources; quarterly reviews can revisit dependencies; ordinary work supplies adoption evidence between meetings. Choose timing around the actual operational need. This calendar application does not establish that change-management searches peak in fall, winter or spring.
For a first review, bring the approved scope, affected roles and one unresolved readiness question. If the recurring problem is leadership coordination or managers practising an agreed response, discuss the actual fit with Shannon. Technical implementation, formal HR matters and required specialist approvals remain with their qualified owners. This article does not announce a new fixed change-management service.
About this resource: Prepared with AI-assisted drafting and editorial review. The organization, handoff example and work record are fictional and illustrative, not client results or a validated assessment. Prosci informs the brief comparison of planning scope; the implementation questions are our editorial application. Cover: AI-generated illustration of fictional colleagues.