Change management is usually scheduled as a training week near the end of a project, by which point the decisions that determine adoption have all been made. Whose job changes, and what they lose, is a scope question.
This guide covers who to ask before the scope is set, why training on the changed process beats training on the screens, and what has to be in place by week six.
Key takeaways
- Decide at approval, not at go-live: Whose job changes and what they lose are scope questions, and a training week cannot answer them.
- Train on the job, not the screens: Staff who learn the buttons and not the changed process keep running the old way behind the new system.
- Close the old route on a date: Where both stay open, a predictable share of people never moves and the business pays for two processes.
- Plan week six: Adoption is lost after the attention ends, when the first awkward case arrives and the team has dispersed.
Start with the business outcome
Success is people doing the job the new way rather than running the old process behind a new screen. Write down which roles change and how, because change management planned as a training week is answering a question nobody asked.
List the roles affected and, for each, what they stop doing and what they lose. Somebody loses discretion, somebody loses a relationship, somebody loses the thing they were the expert in. Those three people decide whether the rollout works.
Four areas to define before choosing features
1. Leadership
Name who is publicly accountable for the change succeeding and check whether they use the system themselves. A sponsor who never opens it is visible to staff within a fortnight, and it tells them exactly how much the change matters.
2. Users
Identify the group with the most to lose, what they lose, and whether anyone has asked them about it. Resistance is usually a rational response to an unacknowledged cost, and it is cheaper to answer than to overcome.
3. Transition
Fix the date the old way stops, decide who approves exceptions to it, and estimate how many exceptions you expect. Where both routes stay open, a predictable share of staff keeps using the one they know and the business runs two processes.
4. Reinforcement
Plan what happens in week six, when the project team has moved on and the first awkward cases arrive. Adoption is lost after the attention ends, and the person who would have known the answer is usually on another project by then.
Decide what to measure
Measure adoption together with cycle time, rework, exception volume, customer outcome, and management response. A rising login count does not prove transformation if the old channels and reconciliation work remain necessary.
Manage the most likely risks
| Decision area | Risk to make visible | Practical safeguard |
|---|---|---|
| Leadership | The sponsor never uses it | Check whether the person accountable has opened the system, because staff will notice within a fortnight. |
| Users | Nobody asked the people who lose out | Find out what the affected group gives up and answer it rather than overcome it. |
| Transition | The old route stays open | Fix the closing date, decide who approves exceptions, and estimate how many you expect. |
| Reinforcement | Support disappears in week six | Name who answers questions after the project team has moved on, before launch. |
Build a roadmap around evidence
1. Find out who the change costs
List the affected roles and what each one gives up, and invite one of them to the steering meeting.
2. Rewrite one person's working day
Describe the new version of their job and walk them through it while you watch.
3. Train on the job, not the screens
Teach the changed process, and use the places people hesitated as the material.
4. Plan week six
Decide now who answers questions and how a problem reported then becomes a fix.
For the operating model this change is usually trying to put in place, see How to Build a Digital Operating Model for Your Business.
Plan adoption and operating ownership
Most of what is called change management happens too late to change anything. The decisions that matter are made when the scope is set: whose job changes, what they lose, and who will still be answering questions two months after launch. Make those decisions at approval rather than at go-live, and the training week becomes a reminder rather than a rescue.
Create a service blueprint for both sides of the screen
For software change management, draw the user journey across the top and the staff workflow underneath it. Connect each customer action to the visible response, backstage action, source system, and evidence of completion. Use Leadership, Users, Transition, and Reinforcement as checkpoints rather than isolated modules.
Use the blueprint to decide what belongs in the mobile or web experience, what belongs in the back office, and what belongs in shared backend services. This makes the goal to prepare leaders, users, data, support, and operating rules for a successful transition visible as one service rather than several disconnected deliverables.
A 30-day validation plan: Software change management
Days 1 to 5: find out who the change costs. List the roles affected and, for each, what they stop doing and what they lose by stopping. Somebody loses discretion, somebody loses a relationship, somebody loses the thing they were the expert in. Those three people decide whether the rollout works, and none of them is usually in the project meetings. Invite one of them to the next steering meeting, because a change designed without the people it costs is a plan with a predictable failure point.
Days 6 to 15: train on the changed job, not the screens. Write the new version of one person's working day and walk them through it. If the training explains which buttons to press but not what their job is now, staff will learn the interface and keep doing the old process behind it, which is the most common way a technically successful launch fails. Let them do the walkthrough themselves while you watch, since the places they hesitate are the places the training material has to be written about.
Days 16 to 30: plan for week six. Decide now who answers questions once the project team has moved on, and how a problem reported then turns into a fix. Adoption is usually lost in the weeks after the attention ends, when the first awkward case arrives and the person who would have known the answer is on another project. Name that person before the launch, as the role is easy to assign in advance and nearly impossible to fill once the team has dispersed.
A practical worksheet: Software change management
Change management is usually scheduled as a training week near the end. Complete these rows at the point the project is approved instead, and keep the sheet where the steering group can see it.
| Decision area | What to record |
|---|---|
| Leadership | Who is publicly accountable for the change succeeding, and whether they use the system themselves |
| Users | The group with the most to lose from the change, what they lose, and whether anyone has asked them about it |
| Transition | The date the old way stops, who approves exceptions to that date, and how many exceptions you expect |
| Reinforcement | What happens in week six, when the project team has moved on and the first awkward cases arrive |
| Measurement | Use of the new process by team, read alongside the volume still going through the old route |
Training people on features rather than on the changed process is the most common cause of a rollout that technically succeeded. Staff know how to click the buttons and still do not know what their job is now, and that shows up as support load.
Related guides
- For what this looks like in practice, see Digital Transformation Roadmap: A 7-Step Business Guide.
- A second perspective worth having is Paperless Workflow: How to Digitize Paper-Based Processes.
When the priorities in Software Change Management: Communication, Training, and Adoption need sequencing against a real budget, Discuss Your Digital Roadmap.
Ali Boran Gazel