John Kotter published “Leading Change: Why Transformation Efforts Fail” in Harvard Business Review in 1995, after a ten-year study of more than 100 companies attempting transformation, and developed it further in his 1996 book Leading Change. ^{[1, 2, 4]} The article identified eight errors that recurred in efforts that faltered, and correcting those errors became the eight steps known today.

Note that the fourth step has changed: in the 1995 article the fourth error was undercommunicating the vision, whereas the version Kotter Inc presents today makes it enlisting a volunteer army. ^{[2, 3]} Communication has not disappeared, but it has become part of inviting people to take part rather than a publicity campaign.

Steps 1–3: lay the foundations before the announcement

Create a sense of urgency. Kotter reported that more than half the companies he followed failed in this first phase, and that urgency is high enough when about 75% of management is honestly convinced that business as usual is unacceptable. ^[2] In the updated version, urgency is built around a “big opportunity” that speaks to heads and hearts, not around threat alone. ^[4]

Build a guiding coalition. The coalition needs people with position, information, reputation and relationships. It may start with three to five people in the first year, but in large companies it needs to grow to between 20 and 50 before much progress is possible. ^[2] Kotter Inc recommends diversity across levels, functions and tenure. ^[4]

Form the vision. Kotter’s practical test: if you cannot explain the vision in five minutes or less and get a reaction that shows understanding and interest, this phase is not finished. ^[2]

Steps 4–6: turn the vision into movement

Enlist a volunteer army. The idea is that people take part because they want to, not because they have to. Kotter Inc’s eBook states that about 15% of the organisation is enough to build material momentum towards change. ^[4] Leaders’ behaviour remains the strongest message: according to Kotter, nothing undermines change more than important individuals behaving in ways that contradict their words. ^[2]

Remove barriers. The obstacles Kotter cited include rigid organisational structures, pay or appraisal systems that conflict with the vision, and managers who refuse to change, stressing that communication alone is never enough. ^[2] The updated eBook adds silos, legacy rules and limited access to leaders. ^[4]

Generate short-term wins. Kotter argued that results should appear within roughly 12 to 24 months to sustain commitment, and that wins must be deliberately planned and created and be unambiguous, because without them too many people give up or join those resisting change. ^[2] In the updated version, a good win is relevant to the opportunity, meaningful to people beyond those who achieved it, and unambiguous and tangible enough for others to replicate or adapt. ^[4]

Steps 7–8: prevent backsliding

Sustain acceleration. Kotter’s seventh error is declaring victory too soon, because change remains fragile until it is embedded in the culture, which can take five to ten years. ^[2] Early wins should therefore be used to tackle bigger problems, not to celebrate the end of the effort. The eBook warns that regaining momentum once urgency has dropped is much harder. ^[4]

Institute change. Change lasts when it becomes “the way we do things around here”. That requires explicitly linking new behaviours to better performance and choosing successors who embody the new approach. ^[2] The eBook reminds readers that cultural change comes deep into a transformation, not at the start. ^[4]

What changed in the updated version?

Kotter later developed the model in his 2014 book Accelerate, and Kotter Inc summarises the differences between the two versions as follows: ^{[3, 4]}

In practical terms: in a large, multi-initiative transformation, do not wait for one step to finish before starting the next, and do not confine leadership to a steering committee. For a tightly scoped change, such as moving a department onto a new system, the original sequence is still a workable planning framework.

Where does implementation stall?

Typical sticking points map onto the steps themselves:
– Manufactured urgency: alarming figures nobody believes, or urgency felt only by senior management.
– A coalition of titles only: a committee of senior managers without people who hold front-line knowledge and relationships.
– A long, vague vision: a multi-page document no one can explain in five minutes. ^[2]
– Compulsory participation: assigning staff to take part instead of giving them a real choice and permission to act. ^[4]
– Leaving systems untouched: incentives and appraisals that still reward the old behaviour. ^[2]
– Easing off after the first win: declaring success before the change has taken root. ^{[2, 4]}

There are also limits anyone adopting the model should know. A 2012 academic review found support for most of the steps but no formal studies testing the model as a whole in sequence; it attributed the model’s popularity more to its direct, practical format than to scientific consensus on its results, and recommended using it as an implementation planning tool alongside others that address context. ^[5] Avoid quoting the claim that 70% of change initiatives fail, too: a 2011 study concluded there is no valid and reliable empirical evidence for that figure. ^[6]

Hypothetical example: moving a government body’s services online

A government body decides to move most of its services to a digital channel within two years. Leadership builds urgency around a clear opportunity: fewer visits to service centres and faster processing. It forms a coalition of the transformation director, heads of the most-used services, front-line staff and a technology specialist.

The coalition writes a two-sentence vision and invites staff to volunteer for service-testing teams. The teams discover that the performance appraisal counts only transactions completed at the counter, so it is amended to include digital transactions. The body launches two digital services in the first six months and shares their results with every department, then uses that win to extend the transformation to more complex services instead of declaring the project complete.

Readiness questions before each step

Use these questions in a guiding coalition meeting before moving into a new phase. Any “no” means the step needs more work, even if later steps have already started in parallel:

These questions are a practical rendering of the conditions Kotter described for each step, not an official Kotter Inc tool. ^{[2, 4]}

Conclusion

The Kotter 8 steps are a list of the leadership errors that derail transformation, arranged as steps. Use them to plan implementation and test your readiness at each step, run them concurrently in large transformations, and supplement them with tools suited to your organisation’s context.

It is easy to label someone who is slow to use a new system as uncooperative, but the label does not explain the cause. The employee may be unable to complete the task because of missing permissions, may see a conflict between two procedures, or may not understand why the way of working changed. Ask what happens in the specific task before judging the person’s attitude to change.

Professional change management literature highlights the importance of context, involvement, communication and leadership in successful transformation. That does not mean every objection is right or that every employee can stop the project; the point is that management decisions improve when they distinguish a fixable problem from deliberate non-compliance with clear instructions. “Resistance” must not become a way to silence an important professional observation. ^[1]

Which questions reveal the real cause?

Ask the employee to carry out a common task in front of a member of the project team, in a suitable test environment. Ask where they got stuck, what information they were missing, and how they used to do the task. Watch for repeated steps, switching between systems and approval requests. An open interview reveals important concerns, while watching the task helps verify the operational part of them.

Then separate the causes: Is what is required unclear? Is a skill missing? Is there not enough time or equipment? Do management incentives still reward the old way of working? Does the employee fear that mistakes made while learning will be used against them? This is an editorial diagnostic list, not a psychological test or a fixed label for people. Keep the notes as work problems that can be solved, without collecting personal details the project does not need.

When is training the answer, and when is it not?

If the employee knows the goal but not the steps, they may need short training tied to their task, with a chance to practise and review. If they know the steps but the system rejects their permissions, adding a lecture will not change the result. Training development standards stress verifying that a gap can be closed by training, rather than treating training as the automatic response to every performance weakness. ^[2]

Design support by role. An approver needs to understand approval decisions and exceptions, while the person processing a transaction needs correct data entry and document checks. Do not put everyone through a long walkthrough of every screen when most of them are irrelevant to their work. After training, provide a short reference and on-the-job support, and update it whenever the interface or procedures change, so people do not learn from conflicting versions.

How do you handle fear of losing expertise or status?

An employee may have deep expertise in the old procedures and feel that the new system reduces their importance or exposes past mistakes. Do not answer that with a general statement about the need to move with the times. Recognise the value of their operational knowledge, and involve them in testing and documenting exceptional cases. Useful involvement gives them a defined role, while the project team keeps responsibility for design and decisions.

At the same time, do not promise staff job outcomes that management has not approved. If the transformation will change how roles are allocated, explain what has been decided, what is still under study and who answers questions. Uncertainty feeds guesswork and rumours. Honest communication helps build realistic expectations; over-reassuring people and then backtracking weakens trust in the project’s next messages. ^{[1, 3]}

What is the line manager’s role after launch?

In practice, the manager decides which way of working is rewarded. If they ask for the system to be used but keep accepting only the old reports, or routinely handle exceptions outside it, the team will see the change as cosmetic. The manager should use the new outputs in follow-up, set aside time for learning, and remove conflicts between daily production targets and temporary transition requirements.

That does not mean open-ended leniency. Set a reasonable transition date based on operational readiness, and explain the exception route and when it ends. When a mistake recurs, first check that the procedure is clear and that the skill and capacity to do it are there. If these conditions are met and non-compliance continues, it is handled under the approved performance policy. Separating diagnosis from accountability makes the decision fairer and easier to explain to both the employee and management.

How would this work in a hypothetical Gulf organisation?

A hypothetical service organisation moves from email requests to an approvals platform. Delayed transactions appear, and someone proposes retraining the staff. A review of a sample of transactions shows that some requests wait for an approver who is not assigned during leave, and that staff re-enter data that already exists in another system. This is a teaching case and does not represent the results of a real project or an assessment of any particular platform.

The team fixes approval delegation, reviews the required fields, then trains users on the corrected route. Follow-up is then measured by completed transactions, data quality and reasons for delay, not just the number of logins. If usage improves, success is not automatically credited to training; changes to permissions, procedure and support also contributed. Documenting these factors protects management from a simplistic conclusion that gets repeated on the next project.

How do you take the Gulf work environment into account?

Organisations with multilingual teams need to explain terms and instructions in a language users understand, while keeping the required official version. Shift work, branches, and the permissions of employees and contractors also need to be considered. Do not assume that one announcement reaches people who work away from the office or at different times; check that the message arrives and is understood for each group.

In government or regulated organisations, review the system’s effect on authorities, records, document retention and privacy. A mandatory step is not cut just to speed up use, and real data is not moved into a test environment without controls. It is good practice to make user experience part of acceptance testing, so that representatives of the key roles complete their real tasks before the system is rolled out to everyone.

How do you know the change has taken hold?

Define evidence tied to the work: transactions completed in the approved way, less unnecessary re-entry, a clear exception route, and staff able to resolve routine cases themselves. These are suggested indicators from which the team picks what suits it. Do not treat the disappearance of complaints alone as a sign of success; it may mean users have stopped reporting or gone back to channels outside the system.

How do you run an obstacle log without blaming individuals?

Describe the obstacle in terms of the task: a request could not be approved while the approver was absent, a field was unclear, or two instructions conflicted. Then record its impact, route and the person responsible for resolving it. Avoid phrases like “the employee doesn’t understand”; they do not help the process owner know what to change. Link each report to an example with unnecessary data removed, so the problem is clear without exposing customer information.

Classify the response as a technical change, a procedural clarification, training or a management decision. An obstacle may need more than one response, but having a coordinator prevents it getting lost between teams. Tell the person who reported it what was decided, and test the fix with them where appropriate. Getting a reply encourages people to report work problems instead of turning to unofficial channels.

In reviews, compare open and closed obstacles and the reasons they recur. More reports at the start may reflect better reporting, not a worse system. Do not set a target simply to close them quickly, or the team may close a problem on paper only to see it return. What matters is that users can complete the correct task and know where to get help. When a fix works, update the guide and the training so the correction does not remain knowledge held by a few people, then review similar cases that may face the same problem in other branches or roles.