By Ritvars Mētra, Founder of ReadinessCompassA large ERP programme sets up its change plan as eight workstreams, named after Kotter’s eight steps. There is a urgency workstream, a coalition workstream, a vision workstream.
By month four, three of them have quietly stopped meeting, because they were never activities. Kotter’s steps describe conditions an organisation reaches, not tasks a team performs, and the difference matters more on a system implementation than almost anywhere else.
What the model is, and what it is not
The eight steps — urgency, coalition, vision, communication, empowerment, short-term wins, consolidation, anchoring — come from John Kotter’s observation of transformations that failed, set out in Leading Change in 1996. It is a distillation of pattern, and it has been enormously influential.
It is worth being clear-eyed about its evidential status, because practitioners rarely are. Steven Appelbaum and colleagues reviewed fifteen years of literature against each of the eight steps in the Journal of Management Development. They found support for most of the steps individually, but no formal studies covering the entire spectrum and structure of the model — and noted that Kotter’s original work did not reference outside sources. Their conclusion is the sentence to remember: the model appears to derive its popularity more from its direct and usable format than from any scientific consensus on results.
That is not a reason to discard it. It is a reason to treat it as a checklist of conditions worth engineering rather than a method that guarantees anything.
Step by step, against a real implementation
| Step | On an ERP programme |
|---|---|
| 1. Urgency | Survives, inverted. The date supplies urgency for free. The risk is the opposite one: manufactured urgency about the deadline crowds out any discussion of whether the business is ready |
| 2. Guiding coalition | Survives, and is the highest-value step. Usually exists on paper as a steering committee that reviews status rather than making decisions |
| 3. Vision | Mostly does not survive. Nobody is inspired by a finance system. A statement of what specifically gets better for each function does more work than a vision |
| 4. Communicate the vision | Survives as volume, fails as effect. ERP programmes over-communicate the why and under-communicate the what-changes-for-you |
| 5. Empower action | Structurally blocked. A packaged system is configured centrally; local teams cannot remove their own obstacles, which is what the step asks for |
| 6. Short-term wins | Genuinely hard. A big-bang go-live has no wins before the deadline, only preparation. This is the step most worth engineering deliberately |
| 7. Consolidate gains | Survives, and is skipped. This is the shakedown period, and it is where the programme is usually being disbanded |
| 8. Anchor in the culture | Survives in principle, unowned in practice. Anchoring means measurement and management systems, not culture work — and by then nobody owns it |
The assumption that breaks
Kotter’s model assumes the change leader controls the pace. Urgency is created, then a coalition forms, then a vision is developed, and the sequence proceeds as readiness allows.
An ERP programme has none of that freedom. The date is set by a contract, a licence expiry or a financial year. The sequence runs to the plan whether or not the conditions have been reached, and there is no step in the model for “the organisation is not ready and the date will not move”.
This is why framework-shaped change plans decay on system programmes. The framework describes a journey; the programme is a deadline. Where the two conflict, the deadline wins, and the unreached conditions simply become the risks nobody wrote down — which is exactly what separating business readiness from technical readiness is designed to surface.
Engineering the short-term win
Of the eight, step six is the one worth real effort, because it is both the hardest to get on a big-bang programme and the most protective when things go wrong.
A short-term win is not a milestone. “Design signed off” is a programme event and means nothing to a warehouse supervisor. A win is something that makes a specific person’s work measurably better before go-live. Three that are usually available:
- Fix something small in the current system that the target group has complained about for years, and say the programme did it. It buys credibility that no communication can.
- Deliver one report people currently build by hand, early, from migrated data.
- Remove a step in an existing process that the new design was going to remove anyway. Take it out now.
Each is cheap and each does more for adoption than a quarter of engagement activity, because it changes the answer to the only question people are actually asking: does this programme make my job better or worse?
What to keep
Kotter is best used as a diagnostic set of questions asked at intervals, not as a plan structure:
- Is there a coalition that can actually decide, or a committee that reviews?
- Can any affected person say what specifically changes for them?
- What has this programme given anyone yet?
- Who owns consolidation after go-live, by name, and are they funded past the closure date?
- Which measurement or incentive would have to change for the new way to be the easy way?
Those five questions carry most of the model’s value and none of its ceremony. They also have the advantage of being answerable with evidence rather than assertion, which is the standard any framework should be held to — including this one.
More on frameworks and evidence in the Change Readiness Hub, or read why no single model explains organisational change.