Change management during a technology rollout: what actually works

A technology implementation that staff do not adopt is not an implementation. It is an expensive parallel system that runs alongside the old way of doing things until one of them is abandoned. The adoption problem is predictable, it is well understood, and it is still the most common failure point in technology projects. The reason is that change management is usually treated as a communication exercise rather than a design exercise.

The difference between communication and design ¶

Communicating a change means telling people it is happening, explaining why, and providing training. Designing a change means involving the people affected in shaping how the new system or process will work, identifying the specific points where resistance is likely to emerge, and building feedback mechanisms that allow problems to surface before they become entrenched.

These are not mutually exclusive, but they require different things from the project team. Communication can be planned and executed centrally. Design requires ongoing engagement with the people doing the work, which takes more time and produces more friction in the short term.

Identifying resistance early ¶

Resistance to a new system is almost never irrational. It usually reflects a genuine concern: the new system is slower for a specific task, it does not accommodate an exception that comes up regularly, or it changes a workflow in a way that creates additional work for a particular role. Those concerns are worth understanding before go-live, not after.

A structured pre-launch review with a representative group of end users, focused specifically on identifying friction points, will surface most of the significant issues. Some of them can be addressed through configuration. Others require a change to the implementation plan. A few will require a change to the process itself.

After go-live ¶

The period immediately after go-live is when adoption either takes hold or starts to erode. A feedback mechanism that is easy to use and visibly acted upon makes a significant difference. Staff who report a problem and see it addressed are more likely to continue engaging with the new system than staff who report a problem and hear nothing.

A structured review at thirty days and ninety days after go-live, comparing actual usage patterns against expected ones, will identify where adoption is lagging and why. That information is more useful than a satisfaction survey.

Change management is not a soft skill added to a technology project. It is part of the technical work, and it needs to be scoped and resourced accordingly.