A system switch rarely fails in the technology. It fails in how it is received: the system goes live, a training session is held, and three months later half the business is still living in spreadsheets and inboxes. The configuration was right, but nobody changed how they work.
That is why we treat change management as part of the delivery, not as an add-on. Here is the checklist we work by ourselves, divided into before, during and after.
Before: anchor the problem, not the solution
- Say why, in the business's own words. "We're switching systems" motivates nobody. "Nobody should have to chase status in three channels" does. The goal should be recognizable in everyday work.
- Map the real way of working. Not the process map that should apply, but how work actually flows today, including the shortcuts. The shortcuts are information: they show where the old system fell short.
- Appoint ambassadors in every team. One or two people per team who help shape the setup before it is finished. They become the voice of the change within the team, instead of the change coming from above.
- Decide what to stop doing. Every new step needs an old one to be removed. If the old way lives on in parallel, it always wins, because it is more comfortable.
During: short steps, real data, fast answers
- Roll out in sprints, not in one big launch. One flow at a time, with a check-in every week. Small steps make it safe to give feedback, and feedback has time to shape the next step.
- Train on the team's own data. A generic demo is forgotten in a day. A walkthrough of the team's own projects, customers and tickets in the new system sticks, because it is about their everyday work.
- Answer quickly in the first weeks. Every unanswered question early on becomes a reason to go back to the old way. We always staff a responsive support channel in the first weeks after each partial rollout.
- Make progress visible. When the first team drops its weekly report because the view has replaced it, tell people. Concrete wins among colleagues convince more than any training.
After: measure, manage, don't let go
- Measure usage, not satisfaction. Are tickets logged in the system? Are statuses updated? Usage can be seen; surveys can be answered politely.
- Have a way in for improvement ideas. A system that never changes after go-live signals that it is ready to be abandoned. A simple suggestion box with visible handling keeps it alive.
- Document and hand over. The setup, the decisions behind it and the routines should be written down, so the knowledge lives in the structure and not with a single person, whether that person is yours or ours.
- Follow up after a while. A couple of months after go-live, do a review: what is used, what chafes, what should be adjusted. That is when the last shortcuts get cleaned out.
The uncomfortable truth
The checklist above is not complicated. The hard part is that it requires time from the business during a period when everyone would rather the "IT project" ran itself. Our experience is unambiguous: the hours teams put in during the rollout come back many times over afterward, and the projects that skip them pay instead with a half-used system.
So when we plan a rollout with you, the change part will be in the plan with the same clarity as the configuration. It is not a soft bonus. It is what determines whether the investment pays off.