Every organisation has a stalled rollout somewhere in its past. The software was chosen carefully, the business case was approved, the training was delivered — and eighteen months later half the company is still exporting to a spreadsheet. Nothing dramatic went wrong. The change simply never built enough momentum to displace the way people already worked.
That is the problem John Kotter set out to describe. After studying a large number of corporate change efforts and finding that most of them underdelivered, he argued that the failures were not caused by bad strategy. They were caused by skipped steps: leaders who declared victory early, who never built a coalition with real authority, who communicated a vision once and assumed it had landed. The eight steps are his attempt to name each of those omissions and put them in order.
The model was written for organisational transformation, not for launching a tool, so applying it literally to a software rollout produces a lot of ceremony and not much movement. This guide keeps the sequence and rewrites the content: what each step means when the change is a piece of software, what it looks like in practice, and the specific failure it exists to prevent. For the wider process around it, see our guide to change management for software adoption, and for the launch mechanics, the software rollout plan.
Key Takeaways
- Kotter's claim is about omission, not error. Change efforts fail because steps get skipped, not because the destination was wrong.
- The eight steps group into three acts — create the climate, engage the organisation, sustain the change — and most rollouts do act one, half of act two, and none of act three.
- Short-term wins are engineered, not awaited. Sequencing the easiest genuinely useful task first is the single highest-return decision in a rollout plan.
- Step 8 is where rollouts quietly die. A change that is never made the default decays back to the old way within a quarter.
- Kotter is organisation-level; ADKAR is person-level. Use Kotter as the programme structure and ADKAR as the diagnostic when one group will not move.
- The model predates product analytics. Its weakest assumption — that you cannot see what people do between milestones — no longer holds, and that is an advantage worth using.
What Kotter's 8-Step Model Actually Says
Kotter's 8-step change model, in one paragraph
A sequence for leading organisational change, published by John Kotter in 1995 and expanded in Leading Change. It holds that successful change follows eight steps in order — urgency, coalition, vision, volunteers, barrier removal, short-term wins, sustained acceleration, and institutionalisation — and that failure is normally traceable to a step that was skipped, rushed, or declared complete before it was. The steps are about momentum: each one creates the conditions the next one needs.
Two things about the model are worth stating up front, because they explain most of the confusion around it.
First, it is a model of an organisation, not of a person. It has nothing to say about why a specific accounts payable clerk is still using the old system. That is what ADKAR is for, and the two are routinely used together.
Second, the sequence is load-bearing. You can run steps in parallel, but you cannot get the value of a later step without the earlier one. A vision announced to people who feel no urgency is heard as noise. Short-term wins celebrated before barriers are removed read as spin, because the people being told about the win are still fighting the process that blocks it.
The Three Acts
Kotter later grouped the eight steps into three phases, and the grouping is more useful than the numbering when you are planning a rollout — because it shows you which act your project is actually in, and which act it has never reached.
Before anything can be built, enough people have to agree that the current situation is not fine and that there is a specific better one.
- Create urgency
- Build a guiding coalition
- Form a strategic vision
The change stops being a plan and starts being work people do. This is where most rollouts spend their entire budget.
- Enlist a volunteer army
- Remove barriers
- Generate short-term wins
The unglamorous half. It has no launch date, no kickoff meeting, and it is the reason a rollout is still working a year later.
- Sustain acceleration
- Institute change
A quick diagnostic. Look at your rollout plan and count how many named deliverables sit in act three. If the answer is zero — no deprecation date, no change to new-hire onboarding, no owner after go-live — the plan describes a launch, not a change.
The Eight Steps, Translated for Software
Here is each step with the version that actually applies when the thing changing is an application: what it means, what it looks like on a real rollout, and the failure it prevents.
1. Create a sense of urgency
Not a deadline, and not a threat. Urgency in Kotter's sense is a shared, concrete understanding of why the current state is unacceptable. In a software rollout the mistake is almost always borrowing the vendor's urgency instead of building your own: the deck says "digital transformation" when the honest version is "we lose four hours a week per person to re-keying data between two systems, and the error rate on that re-keying is what caused the incident in March."
Build the case from the users' own costs, not from leadership's. The people who have to change are the ones whose urgency matters, and they are unmoved by a strategy that saves money somewhere they cannot see.
Prevents: a rollout that reads as an IT project imposed on people who were doing fine.
2. Build a guiding coalition
A group with enough authority, credibility and operational knowledge to make decisions stick. The failure mode is a steering committee of job titles: senior enough to approve, too senior to know how the work is actually done, and unable to change a process without three more meetings.
The test is simple — has the coalition made a decision that cost something? Deprecating a report, changing an approval chain, telling a vocal department that the exception is not being built. A coalition that has only ever approved things has not been tested.
Prevents: a project that stalls the first time the change requires someone to lose an argument.
3. Form a strategic vision and initiatives
One sentence about how the work will be better, plus the specific moves that deliver it. If the vision needs a slide, it is not a vision. "Every customer request is visible to whoever picks it up next" is a vision. "Leverage a unified platform to drive operational excellence" is a sentence that survived a committee.
The vision has a second job people forget: it is the tiebreaker for every scope argument over the following year. If yours cannot settle an argument, it is decoration.
Prevents: twelve months of scope disputes with no principle to resolve them.
4. Enlist a volunteer army
Kotter's original wording was "communicate the vision"; he later reframed it around recruiting a critical mass of people who choose to help. That reframing matters for software, because the difference between a champion network that works and one that exists on a slide is whether champions get anything in return: early access, a direct channel to the project team, visible credit, and answers faster than the helpdesk provides.
Pick champions by influence, not by department symmetry. One respected sceptic who comes around is worth five enthusiastic volunteers nobody asks for advice.
Prevents: a communication plan that broadcasts and never hears anything back.
5. Enable action by removing barriers
The step with the highest return and the least glamour. Barriers in a software rollout are rarely attitudinal — they are permissions that were never granted, a report that only exists in the old system, a customer-facing process that still requires the old reference number, or a manager measured on a metric the new workflow makes worse.
Find them by watching, not by asking. People are poor at reporting the workaround they invented three weeks ago because it has already become normal. A short structured audit of where users actually stop is worth more than a survey.
Prevents: blaming resistance for what is actually an unremoved obstacle.
6. Generate short-term wins
The step most rollouts skip, usually by accident. Wins have to be engineered: chosen for visibility, sequenced early, and unambiguous. The classic mistake is migrating the biggest workflow first because it is the most important, which makes the first experience of the new tool the hardest thing it does.
Choose instead a task that is genuinely faster or newly possible, guide people through it on their first session, and publish the result. See the next section for how to pick one.
Prevents: the undecided middle drifting back to the old system while waiting for evidence.
7. Sustain acceleration
Kotter's original phrasing was "don't declare victory too soon", and the software version is specific: the pilot group gets floor-walkers, a dedicated channel and daily attention, and wave three gets a link to a wiki. Adoption in later waves then underperforms the pilot, and everyone concludes those departments are more resistant.
Later waves should onboard faster than the pilot, because you have learned where people get stuck. If they do not, support was withdrawn, not resistance discovered.
Prevents: a successful pilot followed by a mediocre rollout nobody can explain.
8. Institute change
Anchoring the new way in the things that outlive the project: defaults, onboarding for new joiners, the reports leadership actually looks at, and the deprecation of the old path. A change is instituted when a person who joins next year learns only the new way and never hears the old one mentioned.
This is the step with no launch event, which is exactly why it gets dropped. Give it a date, an owner, and a checklist — the same treatment the go-live got.
Prevents: quiet decay back to the old workflow over the two quarters after launch.
How to Engineer a Short-Term Win
Step 6 deserves its own section because it is the one step you can act on this week, and because "generate short-term wins" is useless as an instruction without a method. A usable win has four properties.
-
It is fast. Visible within the first session, or at the latest the first week. A benefit that arrives in month three is a business case, not a win.
-
It is unambiguous. The person experiencing it can tell it happened without being shown a chart. "That used to take a ticket and now it doesn't" qualifies.
-
It belongs to the user, not the company. Reduced licence spend is not a win for the person being asked to change how they work.
-
It is repeatable. A one-off demo impresses nobody twice. The win should be a task they do weekly.
Then make sure people actually reach it. This is the part where the rollout plan meets the product: the fastest route to a first win is to guide people to it directly rather than hoping they find it. A short in-app product tour that walks someone through exactly that one task on their first login converts the abstract promise into a thing that happened to them personally. An onboarding checklist keeps the next few wins visible without another email.
A short-term win is far more reliable when the first session is guided rather than discovered.
The measurement side matters too. If you cannot see how many people completed that first task, you cannot tell a win from an assumption. Adoption analytics turn step 6 into a number — completion rate on the first guided task, and time from first login to first successful use — which is also the evidence the guiding coalition needs at its next meeting.
Where Software Rollouts Break the Sequence
Four patterns account for most of the damage, and each maps to a specific step being skipped.
1. Urgency borrowed from the vendor
The business case is written in the language of the purchase — platform consolidation, single source of truth, licence rationalisation — and then presented to people whose actual question is whether Tuesday gets easier or harder. Rewrite the urgency from the desk of the person who has to change, using their numbers. If you cannot find a cost they recognise, that is important information about the project.
2. Training used as a substitute for barrier removal
When adoption stalls, the default response is another training session, because training is easy to schedule and produces an attendance number. But training addresses knowledge, and knowledge is rarely what is blocking a software rollout — an unremoved barrier or a missing personal benefit usually is. Diagnose before you schedule; our guide to training employees on new software covers what training can and cannot fix.
3. The hardest workflow migrated first
Perfectly rational from a project-planning view, and fatal to step 6. The first thing anybody experiences with the new system becomes the thing they tell colleagues about. Sequence one easy, genuinely useful task ahead of the big migration even if it delays the critical path by a week.
4. Victory declared at go-live
The project team is reassigned the week after launch, which removes steps 7 and 8 simultaneously. Usage then follows a familiar shape: a spike at launch, a trough four to six weeks later, and a plateau well below target. That curve is not a sign of a bad tool; it is the signature of a rollout that stopped at step 6. Watching it is straightforward with a retention curve.
The Steps That Live Inside the Product
Kotter wrote before it was possible to observe a change as it happened. Half of his steps now have a far cheaper implementation than the one the model assumes, because the software being rolled out can carry the change itself.
| Step | Classic implementation | In-product implementation |
|---|---|---|
| 1. Urgency | Town hall, email from the sponsor | A short in-app message at the point where the old workflow is slow, naming the cost in that moment |
| 3. Vision | Slide deck, intranet page | A one-line welcome screen on first login that says what changes for you |
| 5. Barriers | Feedback forms, escalation | Drop-off data showing precisely which step people abandon, plus a contextual tip where they stop |
| 6. Short-term wins | Celebrated in a newsletter, weeks later | A guided first task that produces the win in session one, with completion measured |
| 7. Acceleration | More floor-walkers per wave | The same guides serve wave three automatically, improved with what waves one and two revealed |
| 8. Institutionalisation | Update the training manual | New joiners get the guided path by default; the old workflow is removed rather than deprecated in a document |
None of this replaces the leadership work in steps 2 and 4 — a coalition cannot be delivered as a tooltip. But it does mean the communication-heavy steps stop depending on people remembering an email from six weeks ago, which is the assumption that quietly breaks the model in practice. Our guide to digital adoption covers the wider version of this argument.
Steps 5 to 8 stop being judgement calls once you can see where people actually stop.
Kotter, Lewin and ADKAR: Which One and When
These three models get presented as alternatives. They are better understood as different zoom levels on the same problem, and mature change programmes use all three.
| Model | Unit of analysis | Best used for | Weakness |
|---|---|---|---|
| Lewin | The change itself | Explaining why a change needs a beginning and an ending, not just a middle | Too abstract to plan from |
| Kotter | The organisation | Sequencing a programme and knowing which step you skipped | Assumes top-down authority and slow feedback |
| ADKAR | One individual | Diagnosing why a specific group has not moved | Says little about organisational momentum |
A practical division of labour: plan with Kotter, explain with Lewin, diagnose with ADKAR. And when the programme is structurally sound but the change still will not land, the problem is usually alignment rather than sequence — which is what the McKinsey 7S model is built to expose.
Kotter in a Rollout: Do vs. Don't
✅ Do
- Write the urgency case from the user's costs, in their own numbers
- Test the coalition by making it decide something expensive
- Keep the vision to one sentence that can settle a scope argument
- Give champions early access and a direct channel
- Sequence one easy, genuinely useful task before the big migration
- Give later waves more support than the pilot, not less
- Put a deprecation date on the old path
- Change new-hire onboarding as part of the project, not after it
❌ Don't
- Reuse the vendor's urgency as your own
- Confuse a steering committee with a guiding coalition
- Communicate the vision once and treat it as delivered
- Recruit champions for departmental symmetry
- Answer stalled adoption with more training by default
- Migrate the hardest workflow first
- Reassign the project team at go-live
- Leave the old system running indefinitely "just in case"
Giving Each Step an Observable Check
Change programmes drift into status colours because the steps sound unmeasurable. They are not — each one has a cheap observable test, and running through this list takes twenty minutes.
- Urgency: pick three affected people at random and ask why the change is happening. If you get three different answers, urgency has not been established.
- Coalition: name a decision it made that cost something.
- Vision: say it out loud in one sentence without reading.
- Volunteer army: are champions receiving questions directly, without being routed through the project inbox?
- Barriers: name one process, permission or report that has been switched off or changed.
- Short-term wins: name one task that is now measurably faster, and give the number.
- Acceleration: compare time-to-first-success in wave three against the pilot. It should be shorter.
- Institutionalisation: ask a recent joiner to describe the process. If they mention the old system, step 8 is unfinished.
Four of those eight are behavioural questions the product can answer directly, which is the practical argument for instrumenting a rollout at all. Our guide to onboarding metrics covers how to define time-to-first-success and completion in a way that survives scrutiny.
Run steps 5 to 8 inside the product
Kompassify lets you build guided tours, checklists, tooltips and in-app announcements without engineering time, and shows you exactly where people stop — so short-term wins get engineered, barriers get spotted, and later waves onboard faster than the pilot. Free up to 100 monthly active users, plans from $129/month, GDPR-compliant and EU-hosted.
Start for free →The One-Sentence Version
Kotter's eight steps say that change fails from omission rather than error — so the useful question about a stalled rollout is not "what went wrong" but "which step did we skip", and for software the answer is almost always number six, number eight, or both.
Frequently Asked Questions
What is Kotter's 8-step change model?
Kotter's 8-step change model is a sequence for leading organisational change, set out by John Kotter in 1995 after studying why most corporate change efforts failed. The steps are: create a sense of urgency, build a guiding coalition, form a strategic vision, enlist a volunteer army, enable action by removing barriers, generate short-term wins, sustain acceleration, and institute change. Its core claim is that change fails from skipped steps rather than from bad ideas — momentum has to be built deliberately, in order, because each step supplies the conditions the next one needs.
What are the 8 steps of Kotter's change model in order?
1. Create a sense of urgency — make the reason for change concrete and immediate. 2. Build a guiding coalition — assemble people with authority and credibility, not just job titles. 3. Form a strategic vision and initiatives — one sentence people can repeat, plus the moves that deliver it. 4. Enlist a volunteer army — recruit a critical mass who choose to help. 5. Enable action by removing barriers — clear the processes, permissions and systems that block the new behaviour. 6. Generate short-term wins — engineer visible early results. 7. Sustain acceleration — press on instead of declaring victory. 8. Institute change — anchor the new way in defaults, onboarding and how work is measured.
How do you apply Kotter's 8 steps to a software rollout?
Translate each step into something you can actually ship. Urgency becomes an honest statement of what the current system costs the people using it, not a vendor pitch. The guiding coalition becomes a named group with the authority to change process, not just to approve a purchase. The vision becomes one sentence about the work getting better. The volunteer army becomes departmental champions with a real support channel. Removing barriers means clearing the old workflow, the double entry and the missing permissions. Short-term wins mean sequencing the easiest genuinely useful task first. Sustaining acceleration means the second and third waves get the same support as the pilot. Instituting change means the new system becomes the default in onboarding, reporting and the deprecation of the old path.
Why do most software rollouts skip step 6?
Because short-term wins feel like they should happen on their own, and because the biggest workflow usually gets migrated first for planning reasons. That order guarantees the first thing anyone experiences with the new tool is the hardest thing it does. A short-term win has to be engineered: pick a task that is genuinely easier in the new system, make it the first one people are guided through, and make the result visible. Kotter's point is that the undecided middle is convinced by evidence rather than by argument, and a win is the cheapest evidence you can manufacture.
What is the difference between Kotter's model and ADKAR?
They work at different levels and are usually complementary. Kotter describes what leadership does across an organisation to build and sustain momentum. ADKAR describes what has to be true inside one individual — awareness, desire, knowledge, ability, reinforcement — for the change to stick for them. A common working pattern is to run the programme with Kotter and use ADKAR as the diagnostic when one team, region or role is not moving while everyone else is.
What is the difference between Kotter's model and Lewin's?
Lewin's three-stage model — unfreeze, change, refreeze — is a description of the shape of any change, and it is deliberately abstract. Kotter's eight steps are closer to a project plan: they say what to do, in what order, to get through Lewin's middle stage without stalling. In practice steps 1 to 4 are Lewin's unfreeze, steps 5 to 7 are the change itself, and step 8 is refreeze.
Is Kotter's 8-step model still relevant?
The sequence holds up, but two assumptions in the original have aged. It assumes change is announced from the top and cascades down, which fits a mandated internal rollout better than a product used voluntarily. And it assumes you cannot see what people are doing between milestones, which stopped being true for software: adoption, drop-off, time-to-first-success and the point where people revert are all measurable in real time. Kotter is best used today as the structure, with product analytics supplying the feedback that the original model had to get from meetings.
How do you measure whether a Kotter step actually landed?
Give each step an observable check rather than a status colour. Urgency: can three people picked at random state the reason for the change in their own words. Coalition: has it made a decision that cost something. Vision: does it fit in one sentence without a slide. Volunteer army: are champions receiving questions directly. Barriers: has any old process been switched off. Short-term wins: has a specific task got measurably faster. Acceleration: are later waves onboarding faster than the pilot. Institutionalisation: does a new joiner learn only the new way.