Every change management model promises the same thing: a clean, linear path from where you are now to where you want to be. Eight steps. Five stages. A tidy unfreeze-change-refreeze diagram that fits neatly onto a single slide.
The problem isn't that these models are wrong. Lewin's original three-stage idea is nearly 80 years old and people still teach it, because the underlying psychology of change holds up. Kotter and Prosci built entire consulting practices on models that genuinely describe how people move through a transition. The problem is what happens after the diagram gets presented at the town hall.
Someone picks a change management model, walks the leadership team through it, and then, in practice, nothing changes about how the work gets tracked. No one owns week three of the rollout. No one is checking whether adoption is actually happening, or just being reported as happening in a status update nobody reads closely. The model described the shape of the change. It never said who checks on it, how often, or what 'working' looks like in numbers.
This guide runs through the change management models you're most likely to come across, compares them side by side, and then covers the part most of them leave out: how to turn a model into something you actually operate, not something you present once and file away.
The change management models worth knowing
Most of what gets referenced under 'change management models' comes down to a handful of frameworks, each with a slightly different emphasis. None of them is wrong. They're just answering different questions.
Lewin's change model (unfreeze, change, refreeze)
The oldest of the bunch, dating to the 1940s. Three stages: unfreeze the current mindset and habits, make the change, then refreeze the new way of working so it doesn't slide back. Simple, and still useful as a mental model for why change reverts when the 'refreeze' stage gets skipped.
Kotter's 8-step process
John Kotter's model breaks the same journey into eight steps: create urgency, build a guiding coalition, form a strategic vision, enlist volunteers, remove barriers, generate short-term wins, sustain acceleration, and institute change. It's the most detailed of the classic models and the one most often taught in MBA programmes.
ADKAR
Prosci's ADKAR model works at the individual level rather than the organisational one: Awareness, Desire, Knowledge, Ability, Reinforcement. The idea is that an organisation only changes when enough individuals move through all five stages. It's popular with HR and internal comms teams because it maps neatly onto training and communication plans.
McKinsey 7-S framework
A broader alignment model rather than a change sequence: strategy, structure, systems, shared values, skills, style, and staff. We've covered the McKinsey 7-S framework in more detail elsewhere. Useful for diagnosing why a change effort is stalling (usually because one of the seven elements is out of step with the rest), less useful as a step-by-step rollout plan.
Bridges' transition model
William Bridges draws a distinction that the other models mostly skip: change is the external event, transition is the internal psychological process people go through in response to it. His three phases (ending, the neutral zone, new beginning) focus on the emotional side of change, which is often where rollouts actually break down.
What these models have in common (and what they leave out)
Look past the terminology and every one of these models describes the same thing: a sequence of stages people or organisations move through on the way to a new way of working. That's genuinely useful. It tells you what to expect and roughly when to expect it.
What none of them tell you is how to run the change day to day. There's no owner assigned to 'build a guiding coalition'. No cadence attached to 'reinforcement'. No number that tells you whether the organisation has actually reached 'refreeze' or whether everyone just stopped talking about the change because the project officially closed.
The problem isn't the model. It's that a model is a map, not an operating system. You still need to decide who owns each stage, how often you check on progress, and what you're actually measuring to know the change has landed rather than just been announced.
Turning a change model into something you can track
Pick whichever model fits your situation (Kotter for a large structured rollout, ADKAR if the change is mostly about individual behaviour, Bridges' if you're worried about morale) and use it as the map. Then build the operating layer on top of it, the same way the rest of the business runs its OKR framework.
1. Use one model, not a blend of five
Mixing Kotter's steps with ADKAR's stages with a bit of Lewin usually produces a plan nobody can actually follow. Pick the one whose emphasis matches your change, and stick with its language throughout.
2. Translate stages into a small number of outcomes
A model with eight steps doesn't need eight key results. Pick the two or three outcomes that actually indicate the change is working, then cascade them down to the teams affected, rather than tracking the model's stages literally.
3. Assign an owner to each outcome, not just a sponsor for the whole rollout
Most change initiatives have an executive sponsor and nobody else. That works for the kick-off meeting and falls apart by week four. Every outcome needs someone whose job is to notice when it's slipping, not just someone who signed off on the business case.
4. Set a fixed check-in cadence
Weekly early on, when adoption is still fragile and worth watching closely. Monthly once the change has settled. The cadence matters more than the format: a simple weekly ritual that surfaces what's stuck beats a quarterly steering committee that reviews a status report nobody's updated in six weeks.
5. Treat resistance as a leading indicator, not an HR footnote
Every model acknowledges resistance exists. Few of them tell you to actually measure it along the way. Falling attendance at training sessions, a spike in support tickets, managers quietly reverting to the old process: these are leading indicators, not just anecdotes, and they show up well before adoption numbers do.
This is where StratOps comes in. Change management models describe the transition. StratOps is the operating layer that turns any of them, whichever you pick, into OKRs with named owners and a fixed check-in rhythm, so the change plan lives in the same cadence as the rest of the business instead of in a separate project tracker nobody opens after week two.
A worked example: Kotter's 8-step meets an operating cadence
Say you're rolling out a new CRM across a 40-person sales team, and you've picked Kotter's model because it's a large, structured change with a clear go-live date.
Instead of tracking the eight steps as a checklist, translate the two stages that matter most (generating short-term wins and sustaining acceleration) into a quarterly objective: 'Sales team is fully operating in the new CRM.' Underneath it, two or three key results: percentage of reps logging deals in the new system daily, percentage of pipeline data migrated and verified, and a simple adoption survey score run every two weeks.
Assign an owner to each key result. Set a weekly check-in for the first month (when resistance is highest and easiest to miss), dropping to fortnightly once adoption clears 80 per cent. Log qualitative notes on friction alongside the numbers, not as an afterthought at the post-mortem.
None of this replaces Kotter's model. It just gives the model somewhere to live between the town hall and the retrospective.
Common mistakes teams make with change management models
- Treating the model as a one-time presentation rather than an ongoing reference point for the rollout.
- Picking a model that's too rigid for how fast the organisation actually moves (an eight-step process for a change that needs to land in three weeks).
- Measuring training completion instead of adoption. Everyone attending the session tells you nothing about whether they've changed how they work.
- No clear owner beyond the executive sponsor, so nobody notices the change stalling until the numbers are already bad.
- Abandoning the check-in cadence the moment the official go-live date passes, right when reinforcement (the step every model agrees matters most) is supposed to start.
Where to go from here
Change management models are worth knowing. They're not worth stopping at. The model tells you the shape of the journey; the operating cadence is what tells you whether you're actually on it.
If you're rolling out a change and want the plan to survive past the town hall, Tability is built for exactly this: turning whichever model you pick into outcomes with named owners, key results and a real check-in cadence. Sign up free or book 30 minutes with us and we'll help you set up the cadence for your next change.
.png)
.jpg)
