This change management plan template connects a proposed working change to its impact, support, evidence of use, and follow-up. The equipment-request example distinguishes transition activities from ordinary work and uses three simulated records to plan different responses.
Describe what will change for each group
The original fictional proposal moves equipment requests from unstructured email into a shared register. A request would need an item ID, needed date, and request owner before review. The actual business purpose, approval, effective date, and access arrangements are to confirm. The example does not announce that a new requirement has taken effect.
| Group | Existing work | Proposed work | Support or decision needed |
|---|---|---|---|
| Requesters | Send a request by email with varying details. | Enter the item ID, needed date, and request owner in the register. | Confirm access; provide a worked request; explain what to do when the item ID cannot be found. |
| Reviewers | Read the incoming email and ask for missing information. | Check register completeness, then follow the agreed review route. | Agree incomplete-request handling and cover during the handoff. |
The impact is the changed behavior in each row. Providing a link or explaining a feature may help, but the plan still needs to address whether people can perform the new work under ordinary conditions.
Prosci's explanation of change-management plans connects defining impact, planning action, tracking use, adapting support, and transferring ownership. Its method-owner guidance helps distinguish a coordinated change plan from the communication and training activities that support it. This independent example uses those general planning questions, not a copied proprietary framework or a claim of measured organizational benefit.
Keep introduction activities distinct from use
The supplied planning snapshot contains three different states:
| Item | Supplied state | What it establishes |
|---|---|---|
| Announcement | A draft exists. | Wording is available for review; no sending, reading, or agreement is established. |
| Practice exercise | Planned. | An activity is proposed; no attendance or demonstrated use is established. |
| Ordinary request use | Not observed in actual work. | The example contains no actual adoption evidence. |
Choose Activity-only status in the example to inspect those states. A completed announcement would still be evidence about communication. A practice exercise would be evidence about that exercise. Neither automatically establishes that the register is being used for real requests.
Before introduction, confirm why the change is needed, who has authorized it, when it applies, and whether affected people can access the register. Agree where exceptions should go. Keep the previous process available or withdrawn according to the actual decision; do not let a preparation page invent that decision.
Plan the review using specific request evidence
The following records are explicitly simulated teaching cases. They are not findings about actual staff or a sample from which to calculate an organizational adoption rate.
| Case | Simulated record | Proposed review response |
|---|---|---|
| U1 | New-register request with item ID, needed date, and request owner present. | The three fields are present. Review the request through the agreed process; do not infer approval or successful fulfillment. |
| U2 | Request arrives only by email; no corresponding register entry is supplied. | Ask about access, awareness of the intended route, and any agreed exception. Do not label the requester Resistant. |
| U3 | New-register request has an item ID and owner, but the needed date is blank. | Review field guidance and the rule for requests whose date is not yet known. Do not make up a date to complete the record. |
Choose U2 and U3 in the example to compare the responses. U2 concerns the route used and why. U3 shows use of the new route with an incomplete field. Giving both people the same reminder may leave two different problems unresolved.
Keep the use evidence connected to the changed task. A page visit alone would not establish that the requester submitted the required information. A complete request establishes more than a visit, but it still does not show that every affected person can use the process or that the request achieved its purpose.
Adapt the support and name the follow-up owner
For U2, establish whether the route was known and accessible before deciding what support is appropriate. If an approved exception explains the email, represent that exception in the process rather than treating the email as failure.
For U3, have the process owner decide what a requester should do when the needed date is genuinely undecided. A clearer instruction, a permitted incomplete state, or another process arrangement may be needed. The plan should record the actual decision and review subsequent work to see whether the issue remains.
A sanitized review copy in your NOS workspace can put those two cases beside the different support questions. A team lead can clarify a static instruction such as “Use the new form” to state which fields and exception route it refers to. That wording change does not launch the register or supply the missing access and approval decisions.
Assign actual follow-up owners, review points, and record locations through the team's process. After introduction, retain responsibility for resolving the issues that real use reveals. Transfer ongoing support to the process owner only when the arrangement and its responsibilities have been agreed.
Copy a prompt for the impact and use-review plan
Create one complete HTML change-management review page.
Actual purpose and approved old-to-new working change: [PASTE]
Affected groups and task-level impacts: [PASTE]
Approval, effective timing, access and exception arrangements: [PASTE]
Support activities, owners and review points: [PASTE]
Actual ordinary-use evidence and permitted feedback: [PASTE]
Adaptation decisions and ongoing process ownership: [PASTE]
Connect the changed work to each group's barriers/support and to
evidence of use after introduction. Keep communication, practice,
and ordinary use distinct. Do not invent approval, access, adoption,
dates, employee attitudes or actual organizational findings.
Include this original fictional equipment-request proposal:
Old: unstructured email. Proposed: shared register requiring item ID,
needed date and request owner before review. Actual purpose, approval,
effective date and access remain TO CONFIRM.
Requester impact: enter the three fields; needs access, a worked
request and a route for missing item ID.
Reviewer impact: check completeness and use agreed review route;
needs incomplete-request handling and handoff cover agreed.
Announcement draft exists; practice exercise planned; ordinary
actual request use not observed. No rollout or activity completion.
Simulated cases only, not real staff evidence:
U1 new-register request: item ID/date/owner all present. Completeness
of fields does not establish approval or fulfillment.
U2 email-only request: no register entry supplied. Ask about access,
awareness and agreed exception; do not infer resistance or motive.
U3 new-register request: item ID/owner present, needed date blank.
Review guidance and agreed unknown-date handling; never invent a date.
No population percentage or grade can be inferred from these cases.
Provide Requesters/Reviewers impact selection, Activity-only status,
Evidence-of-use review and U1/U2/U3 selection. Show exact cases and
different proposed follow-ups. Keep actual evidence fields blank
and readiness unresolved until actual decisions/evidence exist.
Add an impact/transition/use-evidence/adaptation/ownership scaffold
and temporary review notes. Preserve typing across views and confirm
reset. No launch, notification, register integration, employee rating,
automatic agreement or completion badge. At least 16px text, native
labeled controls, visible focus, stacked records at 360px without
overflow. Inline CSS/JavaScript, no external assets, network or
storage. Return full HTML and the decisions still needed from owners.
Read the generated U2 and U3 views side by side. The former should ask why a different route was used; the latter should inspect the missing field and its handling rule. Neither should invent a reluctant employee or turn a planned exercise into actual use.
Ask what the next ordinary request will reveal
Before the review, decide which actual record will show whether a requester can use the intended route and supply the information needed. Record who will inspect it and how an exception will be discussed. Keep the review focused on the work, not on assigning a label to the person.
After support changes, inspect subsequent permitted records. If the same field remains incomplete, return to its purpose and handling rule with the process owner instead of counting another reminder as progress.