What is a change management plan, and what does it actually contain?
A change management plan is the operational bridge between a decision and a new routine. It is not a communication schedule, and it is not a project plan with the word “change” added. It answers four questions in writing: what will people do differently, who is affected and how much, what is being removed or added to make that possible, and how we will know it happened.
The distinction that matters: project management delivers the solution, change management delivers the usage. A CRM implementation can be perfectly on time and still fail, because “go live” describes software availability, not adoption. The plan’s job is the second thing.
Five blocks make a complete document.
Change definition. One paragraph naming the change, the go-live date, the specific behaviours that must change, and what stops happening. “The sales team will log every opportunity in the CRM before the proposal is sent, and the shared spreadsheet will be retired on 30 June” is a change definition. “Implement CRM phase 2” is not.
Stakeholder map. Groups affected, headcount, impact level, influence, current stance, and what each group loses. Loss is the part teams skip, and it is the part that generates resistance.
Resistance plan. For each significant source of resistance: the objection in the stakeholder’s own words, the evidence behind it, the intervention, and the owner.
Rollout schedule. Dated phases with activities, owners, and the metric that closes each phase.
Adoption metrics. Three to five numbers with baselines and targets, reviewed weekly during rollout and monthly afterwards.
How do ADKAR and Kotter fit together?
They answer different questions, which is why using one alone tends to produce a plan with a blind spot.
Kotter’s eight steps describe the organisational sequence: create urgency, build a guiding coalition, form a strategic vision, enlist a volunteer army, enable action by removing barriers, generate short-term wins, sustain acceleration, institute change. It is a programme design tool. It tells you what to do in what order, and it is excellent at preventing the classic mistake of announcing a change before anyone believes it is necessary.
Prosci’s ADKAR describes the individual journey: awareness of the need, desire to participate, knowledge of how, ability to perform in the real work environment, reinforcement to sustain. It is a diagnostic tool. When adoption stalls, ADKAR tells you which element is missing, and the intervention is completely different for each.
| Dimension | Kotter | ADKAR |
|---|---|---|
| Unit of analysis | The organisation | The individual |
| Best used for | Designing the programme | Diagnosing a stall |
| Time horizon | Whole change lifecycle | Per person, per behaviour |
| Typical output | Coalition, vision, wins, embedding | Readiness score, barrier list |
| Failure it prevents | Announcing change too early | Training people who have no desire to use it |
| Metric it implies | Milestone completion | Adoption by cohort |
The practical combination: plan with Kotter, then score each affected cohort with ADKAR before go-live. A cohort that scores high on awareness and knowledge but low on ability is not a communication problem; it is a tooling or time problem, and more emails will make it worse.
A worked readiness score for one cohort of 30 account managers, each element rated 1 to 5: awareness 4, desire 3, knowledge 3, ability 2, reinforcement 1. Total 13 out of 25, or 52% readiness. The lowest element is reinforcement, and the second lowest is ability. The correct response is to fix the ability barrier — in this case, the CRM required 14 clicks to log an opportunity — and to publish a reinforcement mechanism before launch. Launching at 52% readiness with a training programme already delivered is how organisations end up with 30% adoption and a conclusion that “the team resisted”.
Join Doitify Today
Move projects forward without the chaos: all your tasks, progress, and team reports in one unified workspace. Built for companies, startups, and remote teams — with a quick setup and a free trial.
What columns should the plan template contain?
A template earns its place by forcing the uncomfortable columns. These are the ones worth keeping.
| Column | What goes in it | Example |
|---|---|---|
| Change ID | Stable reference | CHG-014 |
| Behaviour change | What people do differently | Log opportunity before proposal |
| Affected group | Cohort and headcount | Account managers, 30 |
| Impact level | High / medium / low | High |
| What they lose | Status, autonomy, comfort, expertise | Personal spreadsheet control |
| Sponsor | Named executive, not a committee | VP Sales |
| Resistance source | Objection plus evidence | “14 clicks, I’ll do it weekly” |
| Intervention | Specific action with owner | Reduce to 4 clicks, demo in standup |
| Readiness (ADKAR) | Score out of 25 | 13 |
| Go-live date | Date the behaviour is required | 2026-06-30 |
| Adoption metric | Number with baseline and target | Opportunity logging rate, 41% → 90% |
| Status | RAG plus next review date | Amber, 12 June |
The rule that makes this template useful rather than decorative: every row with a resistance source must have a named owner and a dated intervention. A resistance column without an owner is a complaint log.
What does a filled rollout plan look like?
Below is a complete rollout for a 180-person company replacing a spreadsheet-based sales process with a CRM, over 16 weeks. This is the table most templates leave empty, and it is the one that determines whether the change lands.
| Phase | Weeks | Key activities | Owner | Success metric | Status |
|---|---|---|---|---|---|
| 1. Frame | 1–2 | Sponsor brief, business case in one page, baseline metrics captured | VP Sales | Baseline logging rate 41% recorded | Done |
| 2. Coalition | 2–4 | 9 champions recruited across 4 regions, fortnightly working group | Sales Ops | 9/9 champions active | Done |
| 3. Design input | 3–5 | 12 user interviews on deal workflow; click-path reduced 14 → 4 | Sales Ops | 4-click path signed off | Done |
| 4. Communicate | 5–7 | Three town halls, manager talking points, FAQ v1, intranet page | Comms | 85% attend or watch | Done |
| 5. Train | 7–9 | Six sessions of 30, role play on real deals, sandbox access | Enablement | 90% passed practical task | Amber |
| 6. Pilot | 9–11 | 24 users, two regions, daily triage, rapid fixes | Sales Ops | Pilot logging rate 88% | Done |
| 7. Go live | 12 | Spreadsheet set read-only, CRM becomes system of record | VP Sales | 100% new deals in CRM | Done |
| 8. Reinforce | 12–16 | Weekly adoption review, leaderboard, manager 1:1 checks | Managers | 80% weekly active by week 16 | Amber |
| 9. Embed | 16+ | Remove legacy reports, update job descriptions and onboarding | HR + Sales Ops | Legacy access revoked | Planned |
Read the status column, not the activity column. Phases 5 and 8 are amber at the same time, which is a signal: training passed only 90% of the practical task, and weekly active use has not reached target. Those two facts are connected. The people who failed the practical task are the same people not logging deals, and the fix belongs in ability and reinforcement, not in another communication wave.
Note also phase 3. Reducing the click path from 14 to 4 before launch is a change-management intervention disguised as a product decision, and it is usually worth more than three town halls.
How do you build a resistance plan that is not a complaint log?
Resistance is information. Each objection points at a real cost the person will bear, and the plan’s job is to reduce that cost or compensate for it.
Segment by stance, not by seniority. Rogers’ adoption curve is a usable approximation: about 2.5% innovators, 13.5% early adopters, 34% early majority, 34% late majority, 16% laggards. In a 180-person company that is roughly 5 innovators, 24 early adopters, 61 early majority, 61 late majority, and 29 laggards. The early majority is the group that decides the outcome, and it moves on peer evidence rather than on executive messaging. Budget peer demos for that 34%, not another all-hands.
Name the loss. The most common unspoken losses are competence (I was the expert in the old system), autonomy (this tool monitors me), status (my role changes), and time (I have no slack to learn). Each has a different remedy: competence needs public recognition of expertise in the new system, autonomy needs clarity on what is and is not measured, status needs a role redesign, and time needs protected hours in the calendar.
Price the objection. If 20 people say the process takes too long, measure it. A 12-minute task done 6 times a day is 72 minutes, which is a legitimate objection and not resistance to change. Fixing it is cheaper than persuading people to absorb it.
| Segment | Headcount | Stated objection | Underlying loss | Intervention | Owner |
|---|---|---|---|---|---|
| Senior AEs | 18 | “I’ll update it weekly” | Autonomy over own pipeline | Mobile quick-log, 4-click path, no activity scoring in Q1 | Sales Ops |
| New hires | 22 | “I never learned the old one either” | Confidence | Onboarding module from day one, buddy system | Enablement |
| Regional leads | 6 | “My region is different” | Status and local control | Region-specific dashboard, monthly lead forum | VP Sales |
| Sales support | 14 | “This adds work to my day” | Time | Process step removed, not added; measured before/after | Sales Ops |
| Long-tenured reps | 9 | “The spreadsheet works” | Expertise and identity | Champion role, public credit for coaching others | Managers |
Which adoption metrics actually predict success?
Adoption metrics should be behavioural, countable, and available weekly. Satisfaction scores are lagging and easy to game; usage is neither.
| Metric | Formula | Target | Cadence |
|---|---|---|---|
| Activation rate | Users completing the core action once ÷ trained users | 95% by week 2 | Weekly |
| Weekly active use | Users performing the core action ÷ in-scope users | 80% by week 8 | Weekly |
| Process compliance | Records created in system ÷ total records created | 90% by week 6 | Weekly |
| Time-to-competence | Days from training to first unaided correct use | Under 10 days | Per cohort |
| Rework rate | Records returned for correction ÷ records created | Under 5% | Weekly |
| Support volume | Tickets per 100 users per week | Falling after week 4 | Weekly |
| Cycle time | Median end-to-end process time, before vs after | −15% by week 12 | Monthly |
Two of these are diagnostic rather than descriptive. A high activation rate with low weekly active use means the first experience worked and the second did not — usually a workflow or performance problem. A falling support volume with flat compliance means people have stopped trying rather than stopped needing help, which is worse.
What does failed adoption cost?
The cost is rarely the licence. It is the workaround labour and the delayed benefit.
Take the 180-person rollout above. Suppose adoption stalls at 60% for a quarter and the remaining 40% — 72 people — keep a parallel spreadsheet for 1.5 hours a week. That is 108 hours a week, or 1,404 hours over 13 weeks. At a $55 blended rate, the workaround costs $77,220 in a single quarter, and the CRM benefit case assumed none of it.
Add the delayed benefit. If the business case promised $40,000 a month in forecast accuracy and pipeline hygiene gains, a three-month delay defers $120,000 of value. Combined, a stalled rollout costs roughly $197,000 against a change programme that might have cost $35,000 to run properly — a 5.6× return on the change budget before counting the second-order effects on credibility.
Industry failure rates are worth quoting carefully. McKinsey’s 2015 article “Changing change management” states that 70% of change programmes fail to achieve their goals, largely due to employee resistance and lack of management support. The figure is widely repeated and methodologically contested, but the direction is consistent with every practitioner’s experience: the default outcome is partial adoption, and the plan exists to beat the default.
What are the trade-offs in planning a change?
Every choice in a rollout trades speed against depth, and the plan should state which way it is leaning.
Big bang versus phased. Big bang is faster and cheaper to coordinate, and it concentrates risk into one week. Phased rollout reduces risk per cohort and creates internal reference cases, but it takes two to three times as long and the early cohorts feel like guinea pigs unless they are resourced properly. Phased wins whenever the change is behaviourally hard; big bang wins when the change is technically simple and the deadline is external.
Communication volume versus credibility. More messages do not produce more adoption, and past a point they produce less. Three well-prepared touchpoints with manager talking points outperform nine announcements, because the manager conversation is what people actually trust.
Training depth versus calendar. A half-day workshop produces knowledge; it does not produce ability. Ability comes from practice on real work in the first two weeks, which means protected time and a floor-walker, not a longer course.
Pilot size versus representativeness. A pilot of volunteers will succeed and teach you little. A pilot that includes two known sceptics will be uncomfortable and far more informative, because their objections are the ones the late majority will raise in week ten.
Sponsor visibility versus sponsor overreach. An absent sponsor is the most common structural failure. A sponsor who personally chases individual compliance creates a change that collapses when attention moves. The useful pattern is a sponsor who removes barriers and appears at milestones, not one who monitors daily usage.
What are the most common mistakes?
Six recur often enough to be predictable.
Treating go-live as the finish line. Go-live is the start of the adoption curve. The eight weeks after launch decide the outcome, and they are usually the least resourced.
Training the willing. Sessions fill with the already-convinced, attendance is reported as success, and the sceptical cohort — the one that determines whether the change sticks — never attends.
No baseline. If you do not know the current logging rate, cycle time, or error rate, you cannot prove the change worked and you cannot detect a stall early.
Communication without removal. People are asked to adopt a new process while the old one remains available. Dual running is comfortable for managers and fatal for adoption; the legacy path must be closed on a named date.
Managers left out. Managers are the delivery mechanism for change, and they are usually informed rather than equipped. A one-page talking-points sheet and a 30-minute briefing per manager is the highest-return item in the plan.
Measuring satisfaction. “86% of users are satisfied” tells you nothing about whether the process is being followed. Measure behaviour, and use satisfaction only to explain a behavioural number.
How does Doitify support a change rollout?
Doitify is our product, so read this as disclosure rather than as an independent review. A change programme is itself a project with phases, owners, dependencies, and a governance rhythm, and that is the layer the platform covers: a project per phase, tasks with owners and due dates, checklists for training and pilot readiness, documents for the plan and the FAQ, and work and performance reports for the weekly adoption review.
The useful part is not that the plan lives somewhere tidy. It is that the rollout table and the adoption metrics sit next to the work they describe, so a phase that slips is visible on the same timeline as the go-live date it threatens. The honest limit: Doitify will not diagnose resistance for you, and it will not replace a sponsor who does not show up. Those remain human problems, and the plan template is where they get named.
FAQ
Conclusion
A change management plan is a short document that does an unpopular job: it states what people must do differently, what they lose, who removes the obstacle, and what number proves it worked. Kotter gives the programme its sequence; ADKAR gives the diagnosis when adoption stalls; the rollout table and the adoption metrics keep both from becoming theory.
The practical test of any plan is whether it survives a busy Tuesday. If the new process takes longer than the old one, if the legacy path is still open, and if no manager mentions it in a one-to-one, the plan is decoration. Fix ability first, close the old route on a named date, equip managers, and measure behaviour weekly for eight weeks. That sequence accounts for most of the difference between a change that lands and one that is quietly abandoned.
If this post on change management was helpful, you might also enjoy Agile Sprint Project Template: Sections, Example, and How to Use It and What Is Definition of Done in Scrum? A Complete Guide with Examples.
Join Doitify Today
Move projects forward without the chaos: all your tasks, progress, and team reports in one unified workspace. Built for companies, startups, and remote teams — with a quick setup and a free trial.