TL;DR
- Definition: the structured approach to moving people from how things work now to how they will work after a change, so the change actually holds.
- It is about people, not project plans. Project management delivers the change; change management gets it adopted.
- The most common failure is announcing rather than involving, and the second is declaring victory at go-live.
- The main models: Kotter's 8 steps, ADKAR, Lewin's unfreeze-change-refreeze. They mostly agree; pick one as a checklist.
- The single highest-return act is explaining why, honestly, including what is genuinely uncertain.
What change management actually is
Any significant change has two halves. There is the mechanical half: build the system, sign the contract, publish the new org chart. And there is the human half: people understanding why, knowing what it means for them, and changing what they do on Monday.
Change management is the second half. It exists because the first half completing does not cause the second half to happen, which surprises people repeatedly.
What it is not:
- Not project management. Project management tracks the delivery. Change management tracks adoption. A project can finish perfectly and produce no change at all.
- Not communications. Communication is a component, and a change program that is only communication is a broadcast, which is the most common weak version.
- Not persuasion. If the change is bad for someone, telling them harder will not help. Being straight about it works better.
- Not a phase at the end. Starting change management after the decision is made and built is the single most common structural error.
Why it matters (and the signs it is missing)
The cost of skipping it is not usually visible as a failure. It shows up as an expensive system nobody uses, a reorg where people quietly keep the old reporting lines informally, or a process that everyone works around.
Signs it is missing:
- People find out from the wrong place. A rumour, a calendar invite, or a customer.
- Nobody can say why. People can describe what is changing but not the reason, which means they cannot make good judgment calls within it.
- Enthusiastic launch, quiet reversion. Usage spikes and then decays to the old way within two months.
- Shadow processes appear. The old spreadsheet is still being maintained by someone.
- Middle managers are surprised. The layer that has to explain it to their teams found out at the same time as their teams.
- Success is declared at go-live. Which is the halfway point, not the end.
The main change management models
They overlap heavily. The value is in having a checklist, not in the specific one you choose.
| Model | Structure | Best used for |
|---|---|---|
| Kotter's 8 steps | Urgency, coalition, vision, communicate, remove obstacles, short-term wins, consolidate, anchor | Large organizational change with a leadership sponsor |
| ADKAR | Awareness, Desire, Knowledge, Ability, Reinforcement | Diagnosing where an individual or group is stuck |
| Lewin | Unfreeze, change, refreeze | Simple framing; good for explaining why the post-change period matters |
| Bridges' transition model | Ending, neutral zone, new beginning | Change involving loss, such as restructures and layoffs |
If you only take one thing: ADKAR is the most practically useful for diagnosis. When adoption stalls, walk through it. Do people know it is happening? Do they want it? Do they know how? Can they actually do it in practice? Is anything reinforcing it? Adoption problems almost always sit at one specific letter, and the fix is different for each. Teams routinely run more communication, an Awareness fix, when the actual blocker is Ability.
How to do change management well
1. Start before the decision is finished. Involve the people affected while it can still be shaped. Involvement is the difference between a change happening to someone and a change they had a hand in, and it is worth more than any amount of later messaging.
2. Explain why, honestly. Including the parts that are uncomfortable. People forgive difficult changes explained honestly far more readily than pleasant-sounding evasions. If the reason is cost, say cost.
3. Say what you do not know. "We have not decided how this affects team structure, and I will tell you by the 15th" is vastly better than silence. Silence gets filled with the worst available guess.
4. Bring middle managers in first. They have to answer the questions, and they cannot do that if they learned about it in the all-hands. Give them the information and the likely questions a few days early.
5. Name what people lose. Every change costs someone something: familiarity, status, a tool they liked, a relationship with a manager. Acknowledging it explicitly defuses more resistance than arguing about the benefits.
6. Make the new way easier than the old way. If the old process is still available and simpler, people will use it. Adoption is often a friction problem dressed up as a culture problem.
7. Find the sceptics and talk to them. Not to convert them. The respected sceptic usually has a concrete objection worth hearing, and addressing it improves the change. Ignoring them means the objection circulates without you in the room.
8. Plan the period after go-live. This is where change programs are abandoned and where adoption is actually won or lost. Support, reinforcement, and someone checking whether people reverted.
9. Measure adoption, not delivery. Are people using it, and doing so the intended way? Delivery metrics tell you the project finished, which you already knew.
Resistance, and what it usually means
Resistance is treated as an obstacle to overcome. It is more useful as information.
| What it sounds like | What it usually means | What helps |
|---|---|---|
| "This will not work here" | They see a specific practical problem | Ask what specifically, and listen |
| "We tried this before" | Previous change was handled badly | Acknowledge that, and say what is different |
| Silence and compliance | They have decided to wait it out | Ask directly and privately |
| "I do not have time" | Genuinely true, or a proxy for low priority | Remove something else, or explain the priority |
| Working around the new process | The new way is harder | Fix the friction; this is your best signal |
The pattern: most resistance is either a legitimate practical objection or a trust deficit from a previous change. Neither is fixed by more enthusiasm.
Change management at different scales
A team-level change, a new tool or process. Mostly needs explaining why, involving people in how, and checking in after two weeks. Formal models are overkill.
A department-level change, a restructure or new operating model. Needs the middle-manager layer briefed first, explicit naming of what people lose, and a plan for the months after go-live.
An organizational change, a merger, strategy shift, or major system migration. Needs a named owner, a sponsor with authority, and a structured model as a checklist. This is where dedicated change management roles exist and earn their place.
A minimal plan for a normal change
Most changes are not organizational transformations. They are a team adopting a new tool, a process being replaced, or a reporting line moving. Formal models are too heavy for these, and skipping the thinking entirely is how they go wrong. This is roughly the minimum that works.
Before the decision is final. Talk to three or four people who will be most affected. Not to announce, to ask: what would make this hard, and what would you need. This step takes an afternoon and prevents most of the problems that show up later as resistance.
When you announce. Say what is changing, why, what it means for each group specifically, what you have not decided, and when you will next update. Send it to the managers a couple of days ahead so they are not answering questions cold.
In the first two weeks. Make the new way easier than the old way, and if you can, turn off the old way. Parallel running is where adoption goes to die, because the old path is familiar and available and people default to it under pressure.
At four to six weeks. Check whether people actually reverted. Not by asking in a group, which produces polite answers, but by looking at usage or asking individuals privately. This is the step almost everyone skips, and it is where you find out whether any of it held.
One honest conversation. Find the person most sceptical and ask what they would change. If they are respected by the team, their objection is circulating whether or not you hear it.
That is perhaps two days of effort spread over six weeks, and it is the difference between a change that holds and one that quietly reverts.
How to get better at leading change faster## How to get better at leading change faster
The models are easy to read and hard to run, because the difficult parts are conversational rather than structural: telling people something they will not like, sitting with a room's frustration without defending, and hearing an objection you cannot immediately answer.
Those are practised skills, and reading about ADKAR does not build them. What helps is working through your actual change with someone who has led one, and rehearsing the conversations you are dreading before you have them for real.
A change management workshop does that with your team and your actual change rather than a case study. Sessions are live, built around a brief you write, and matched with an expert within 48 hours. Under 5 percent of applicants are accepted onto MentorCruise, so the person in the room has led change through real organizations.
FAQs
What is change management in simple terms? The work of helping people adopt a change, rather than the work of making the change happen. Building the new system is one job; getting people to use it properly is a different one, and change management is the second.
What is the difference between change management and project management? Project management is about delivery: scope, schedule, resources, risk. Change management is about adoption: awareness, willingness, capability, reinforcement. Large changes need both, and the most common failure is funding the first and assuming the second.
What is the ADKAR model? Awareness, Desire, Knowledge, Ability, Reinforcement. Its main strength is diagnostic: when adoption stalls, you can identify which letter people are stuck on and pick an appropriate response, rather than defaulting to more communication regardless of the cause.
Why do change initiatives fail? Most commonly because the change was announced rather than shaped with the people affected, because the reason was never explained honestly, because middle managers were briefed too late to answer questions, or because everyone stopped paying attention at go-live, which is precisely when adoption is decided.
How do you deal with resistance to change? Treat it as information first. Ask what specifically concerns them and listen properly, because a large proportion of resistance is a legitimate practical objection or residual distrust from a previous badly-handled change. Neither responds to more enthusiasm.
Do we need a dedicated change manager? For team or department-level changes, usually not; the manager leading it can do this with some structure. For organization-wide changes affecting hundreds of people across functions, a named owner with the time and authority to do it properly is worth the cost, because otherwise it becomes nobody's job.
