Why do I need a change plan?

Someone has handed you a change — a new system, a new process, a reorganisation — and said "can you manage the change side of this?" You nodded. Then you searched "how to manage a change", found a wall of acronyms, and ended up here. This is for you.

The plan shipping is not the same as people adopting

Most projects have a delivery plan: build the thing, test it, go live. That plan can succeed completely — the system works, on time, on budget — and the change can still fail, because the people who were meant to use it don't. They carry on with the old spreadsheet, work around the new process, or quietly wait for it to be abandoned like the last one was.

A change plan is the other half. The delivery plan gets the thing built; the change plan gets people ready to use it, willing to use it, and still using it a quarter later. They are different jobs, and the second one rarely happens by accident.

What actually goes wrong when you skip it

• People hear about the change too late, from the wrong person, and decide it's being done to them rather than with them.
• A few vocal sceptics set the tone, and nobody notices until go-live that half the team is quietly against it.
• Training happens once, weeks before launch, and is forgotten by the time it matters.
• Go-live arrives, adoption is low, and there's no agreed way to tell whether it's working — so the project is declared "done" and the problems surface months later as the old way creeps back.

None of these are technical failures. They're people failures, and they're predictable — which means they're preventable with a plan.

What a change plan actually contains

Stripped of the jargon, a change plan answers a handful of plain questions:

• Who is affected, and how much does this change their day?
• How ready is each group — do they know it's coming, do they want it, can they actually do it?
• Who are the people whose opinion moves everyone else's, and where do they stand?
• What will we tell people, when, and who should say it?
• What training or support do they need, and did it land?
• How will we know, after go-live, that it stuck — and what do we do if it didn't?

That's it. If you can answer those, you have a change plan. You don't need a certificate to ask good questions about your own organisation.

You don't have to learn a methodology first

There are well-known frameworks — ADKAR, Kotter, Lewin — and they're genuinely useful once you're deeper in. But you don't need to study one to start. ChangeOS builds the plan around those plain questions, drafts the first version from a few sentences describing your change, and explains the method behind each screen as you go. You review and approve everything; nothing is sent or decided on its own.

The honest version: the plan shipping is the easy half. Getting people to adopt it is the half that fails — and it's the half a change plan is for.

A sensible first step

Before you plan anything, find out where people actually are. The free readiness check takes two minutes, needs no sign-up, and tells you how ready one team is across the five things that predict adoption. It's a good way to see, in concrete terms, what a change plan is about to help you with.