What this is
Change management is the work of making sure a system, process or organisational change actually gets used the way it was designed to be used. A correctly built solution that nobody adopts hasn't actually changed anything — it's just added a new tool that people work around.
Adoption is a separate problem from correctness. A system can be built exactly right and still fail, if the people using it weren't brought along with it.
What's covered
- Stakeholder alignment — identifying who is affected by the change and what concerns or resistance exist before rollout, not after
- Adoption planning — a defined path from current state to the new way of working, sequenced to avoid disruption
- Training delivery — structured to the people actually doing the work, not a generic walkthrough
- Post-go-live tracking — checking, after implementation, whether the change is actually being used as intended
The process
- Stakeholder mapping — who is affected, and how, is identified before rollout planning begins.
- Adoption plan — a sequenced path to the new way of working is agreed, accounting for operational disruption.
- Training — delivered to the people actually doing the work, at the point they need it.
- Go-live support — hands-on presence during the transition itself.
- Post-go-live check-in — usage and outcome data reviewed against what was expected, at a defined point after launch.
Timeline depends on the scale of the change and the number of people affected, and is confirmed project by project.
What you need to provide, and where it comes from
- The change itself — the system, process or organisational change already planned, typically documented in a project brief or scope document
- A stakeholder map — everyone affected by the change, usually built from an org chart or team structure
- Prior change history, where relevant — what's been tried before and how it landed, which shapes how this one is planned
Why this matters
Most failed technology and process projects aren't failures of the solution — they're failures of adoption. The solution gets built, the training gets scheduled once, and six months later people have quietly reverted to the old way. Change management is the work that prevents that reversion.
Common questions
Why does a change need separate management?
Because a system being correct on paper doesn't mean people will use it as designed. Adoption failure is a distinct problem from whether the solution was built correctly.
What does post-go-live tracking involve?
Checking, after implementation, whether the change is actually being used as intended — a defined check-in reviewing real usage against expectation.
Is this only for large organisations?
No. Adoption failure happens at any scale. The approach scales to the size of the change, not the size of the company.