change_management_playbook v1.0.0

name: change_management_playbook description: "Land an organizational change so people actually adopt it: map impact by stakeholder group, diagnose the ADKAR barrier per group, run a comms cadence people can plan around, handle resistance by cause, link training to real tasks, and measure adoption as behaviour. Ships a working CLI for impact ranking, ADKAR diagnosis, comms calendars, and adoption scorecards. Use when rolling out a new system, process, structure, or policy, when adoption has stalled, or when a change was announced but nothing changed."

Change Management Playbook

Purpose

Most failed changes were announced well and adopted badly. The announcement is the easy part. The work that decides the outcome is duller: who is hit hardest, what each group still needs, when people hear what, and whether anyone checks actual use after go-live.

This skill gives that work an operating system. It pairs the ACMP process order (impact, strategy, plans, execution, close) with Prosci ADKAR for individual progress and Kotter's eight steps as a sponsorship check. Full frame notes are in references/frameworks.md. A CLI in scripts/change.py does the scoring, calendar, and adoption math so the plan rests on numbers you can show, not on vibes.

Workflow

1. Define the change in one paragraph

• Write what changes, for whom, from when, and what stays the same. If you cannot write the stays-the-same part, you do not understand the change yet.
• Write the future state as behaviour, not as a project. "Pickers scan at the pack bench and exceptions go to the lead" beats "implement the new WMS".
• Name the sponsor who owns the outcome, not only the project. A change with no accountable sponsor gets a comms plan and nothing else, so say that plainly and stop.
• Write the success criteria and the date you will judge them. Agree the adoption target now, before launch, while everyone is still honest about what good looks like.

2. Map impact by group

Score every affected group on three kinds of depth, each 0 to 3: how much the process changes, how much the tools change, and how much the role itself changes. Run the scorer instead of ranking from memory:

python3 scripts/change.py impact --file groups.json

Input is a JSON list. Example file and verified output:

json
[{"name":"Warehouse pickers","headcount":40,"process_change":3,"tools_change":3,"role_change":1,"notes":"New scanner workflow, same job"},
 {"name":"Finance close team","headcount":8,"process_change":2,"tools_change":1,"role_change":0},
 {"name":"Customer support","headcount":25,"process_change":1,"tools_change":2,"role_change":1}]

Warehouse pickers: depth=7/9 tier=high headcount=40 exposure=280
Customer support: depth=4/9 tier=medium headcount=25 exposure=100
Finance close team: depth=3/9 tier=low headcount=8 exposure=24
total_groups=3 high=1 medium=1 low=1

• Depth 7 to 9 is high, 4 to 6 is medium, 0 to 3 is low. Exposure is headcount times depth, and it sets where your time goes first.
• Spend comms, training, and check-in time in exposure order. The common failure is equal effort for every group, which starves the high-impact group and floods the low-impact group with noise.
• Add two readiness facts per group before you plan anything else: how much change this group is already carrying, and whether their manager is for, neutral, or against. A high-impact group with a hostile manager is your first problem, ahead of any message.

3. Diagnose the ADKAR barrier per group

Rate each group 1 to 5 on awareness, desire, knowledge, ability, and reinforcement, from evidence: short surveys, manager conversations, training data, and observed use. Then run:

python3 scripts/change.py adkar --file adkar.json

Verified example. Warehouse pickers score awareness 4, desire 2, knowledge 3, ability 3, reinforcement 1. Finance scores 4 or better on all five.

Warehouse pickers: barrier=desire (awareness=4 desire=2 knowledge=3 ability=3 reinforcement=1)
Finance close team: no barrier at threshold 4.0

• The barrier is the first element below threshold, 4 by default. Fix the barrier, not the element you enjoy working on. A desire barrier needs personal impact work, trusted senders, and a real way to raise concerns. Sending more awareness material at a desire barrier makes people tune out faster.
• Re-score after each major intervention and after go-live. One score at kickoff is a snapshot, not a diagnosis you can run a quarter on.
• Keep group scores separate. An org-wide average hides the one group that will fail, and that group is usually the one doing the core work.

4. Build the comms cadence

People plan around a rhythm they can predict. They ignore a flood before launch and silence after it. Generate the calendar, then edit the messages, not the dates:

python3 scripts/change.py comms --start 2026-11-02 --go-live 2026-11-30

Verified output for that range: sponsor announcement on 2026-11-02, manager brief on 2026-11-09, affected-group updates on 2026-11-16 and 2026-11-23, go-live note on 2026-11-30, then adoption check-ins 30, 60, and 90 days after go-live, 8 events in total.

Rules for the messages themselves:

• Segment by group. Each message answers three questions for that group only: what changes for us, what do we do differently and from when, and where do we ask questions.
• Use the sender each group trusts. Sponsor for why, direct manager for what it means for the team, peer or champion for how it works in practice. One all-staff email from the top covers none of these well.
• Make every message two-way, with a named route for questions and a date by which answers come back. Publish the hard questions and the answers. Silence after a hard question reads as a hidden answer.
• Repeat the core message across channels and weeks. People miss messages for ordinary reasons. Hearing it once means most of the group never heard it.
• Never announce a date you are not sure you can hold. One moved go-live costs more trust than a later date announced once.

5. Handle resistance by cause

• Log every concern with the group, the exact worry in their words, and a cause bucket: fact, impact, trust, or capacity. The buckets and what to do with each are in references/frameworks.md.
• Answer fact concerns by fixing the plan where the concern is right, and say what changed because people raised it. That sentence, when true, is the strongest adoption tool you have.
• Answer impact concerns by naming the loss honestly and stating what support exists: training time, a transition period, a fallback, or compensation where the organisation offers it. Do not reframe a real loss as an opportunity.
• Plan for the dip. Performance usually drops while people learn the new way. Tell managers the dip is expected, set a window for it, and judge the change after the window, not during the worst week.
• Pick champions from volunteers inside each high-impact group. Conscripted champions convince nobody, and the group can tell the difference in one meeting.

6. Link training to real tasks

• Build training per role from the impact map, not one generic session for everyone. Each module covers the tasks that role does in the first week of the new way.
• Give practice, not only presentation. People need to do the new task once in a safe setting, with their own data or cases, before go-live depends on it.
• State the training deal plainly: how long it takes, when it runs, whether work cover exists, and what happens if someone misses it. Unanswered logistics questions are a quiet source of resistance.
• Put job aids where the work happens: a one-page checklist at the bench, a short video linked from the tool, a named person for the first two weeks. A PDF on an intranet nobody opens is not a job aid.

7. Measure adoption as behaviour

Define adoption before go-live as a behaviour you can count: active users of the new tool, orders processed the new way, old forms no longer submitted. Then score it:

python3 scripts/change.py adoption --file metrics.json --target 80

Verified example, with 100 target users, 62 active, and 90 trained:

adoption_rate=62.0% active=62 target=100
training_completion=90.0% trained=90
training_to_use_gap=-28.0 points (negative means people trained but not yet using it)
verdict=at_risk against agreed target 80.0%
warning: old way still available with no end date. Name a retire date or adoption will stall.

• Read the gap, not only the rate. High training and low use means the barrier is ability, desire, or a blocker in the work, and more training will not close it. Go to the group and find the blocker.
• Track leading signals weekly (training completion, active use, help requests by type, short sentiment checks) and lagging results monthly (the benefit the change was for, error rates, cycle time). Review at the 30, 60, and 90 day check-ins from step 4.
• Report adoption by group, in exposure order, to the sponsor. One blended percentage lets a failing core group hide behind easy groups.
• Set a retire date for the old way and publish it early. Two ways of working side by side with no end date means the old way wins, because it is the one people already know.
• Close properly: judge the outcome against the criteria from step 1, hand ownership to the operational leader, fold the new way into onboarding and goals, and write the lessons learned while the people who lived it are still around.

Output Contract

Deliver, for each change:

• A one-paragraph change definition: what changes, for whom, from when, what stays the same, the sponsor, and the success criteria with a judgement date.
• An impact map: every affected group with process, tools, and role scores, depth tier, headcount, exposure rank, current change load, and manager stance.
• An ADKAR table by group with the barrier point named for each group and the intervention planned for that barrier.
• A comms calendar with dates, audience, sender, and the three questions each message answers, running from announcement to the 90-day check-in.
• A resistance log: concern in the group's own words, cause bucket, response, owner, and status.
• A training plan by role: tasks covered, format, practice element, dates, and the job aid for the first two weeks.
• An adoption scorecard: target, behaviour definition, rate by group, training-to-use gap, verdict against the agreed target, the old-way retire date, and the next fix for any group off track.

Do not deliver a comms plan on its own and call it a change plan. Without the impact map, the barrier diagnosis, and the adoption measure, it is only an announcement schedule.

Operating Rules

• No invented numbers. Every rate, date, and threshold in the plan is either measured, agreed with the sponsor, or labelled as an example to agree. Never present a planning default as a proven standard.
• Impact before messages, always. If time is short, cut message polish, not the impact map or the barrier check.
• One group, one barrier, one fix at a time. Parallel interventions on every element at once spend the budget and teach you nothing about what worked.
• The sponsor stays visible for the whole change, not only at launch. If the sponsor goes quiet, raise it as a risk in writing, with the adoption data attached.
• Middle managers carry the change or block it. Brief them before their teams, give them talking points and honest answers for the hard questions, and check what they are actually saying.
• Treat a missed date, a cut training session, or a silent sponsor as plan changes, not footnotes. Re-run the impact and ADKAR checks after any of them.
• Keep personal data out of the tracking. Score groups, not named individuals, and never use adoption data as a covert performance ranking of people.