Why change management fails in technology programmes

Change is treated as communication, not capability

The default approach to change management is to tell people what is changing and how to use the new system. Training manuals. Instructor-led courses. Lunch and learn sessions. User guides. All focused on transferring knowledge about what the system does, not developing capability to work differently.

Effective change requires capability development. People need to understand not just how to click through the new system, but why their role is changing, how their performance will be measured differently, what their decision-making authority looks like in the new operating model, and what the business expects them to do differently on day one. This is fundamentally different from system training. It is capability building, and it requires a completely different approach.

In a Dayforce deployment, training people to enter pay data into the system is system training. Developing the capability of HR and payroll teams to audit pay data quality and identify root causes of variance is capability development. The difference matters, because the latter determines whether the programme delivers the intended outcome.

Change starts too late to influence programme design

Most change management efforts start three months before go-live. By this point, the future state operating model has already been designed. The system has already been configured to reflect how business stakeholders thought they wanted to work. Change management has no seat at the table when those decisions were made, so its job is to sell what has been decided, not to help the business design what it needs to become.

Change management should start at programme initiation, working with the business to design the future state operating model before the system is built. This means the change team is actively involved in scenario planning, helps define new roles and responsibilities, identifies capability gaps, and recommends an implementation sequence that allows the business to develop capability in parallel with system delivery. This is not possible if change management is still being hired when testing is underway.

In an ERP programme, this means the change lead is in the process design workshops from day one, ensuring that new processes are designed around capability that exists or can be developed, not processes that require a level of expertise the business does not have. The change team helps the business make trade-offs between what the system can do and what the business can realistically operate.

Change is disconnected from delivery

In many organisations, the change workstream operates in parallel to the delivery programme but rarely intersects with it. The programme team is focused on building and testing. The change team is focused on planning communication. The two groups have different leaders, different success metrics, and little direct interaction until the final weeks before go-live.

When change is this disconnected, it becomes easy for change assumptions to be violated without anyone noticing. The programme decides to compress the go-live timeline. Change has already designed a training schedule that no longer fits. The programme changes a process design in testing. Change has already produced training materials based on the original design. The change message becomes internally inconsistent, and users rightly become confused about what is actually going to happen.

Change must be embedded into programme governance. The change lead should be part of the programme steering committee and the core programme team. Change should have input into scope decisions, timeline decisions, and configuration decisions. When the business asks for something to be built differently, change is the function that says whether the business has the capability to operate what is being asked for. This only happens if change is part of programme delivery from day one.

Leadership is not visibly committed to the change

Leaders often view change management as something the HR team or the project manager will handle. The business sponsor approves the budget and then largely disappears until the weeks before go-live. The programme director is focused on delivery. The steering committee receives change status reports but does not actively lead or champion the change itself.

Users watch this pattern and draw the obvious conclusion. If the leaders do not think this change is important enough to spend time on, then it is not actually important. When the programme goes live and people default to old ways of working, the failure is then attributed to user resistance rather than leadership commitment.

Visible leadership commitment means the executive sponsor is actively involved in the change narrative, regularly talking about why the change is necessary and what the business needs to do differently. It means senior leaders are held accountable for the adoption of their teams. It means when the programme identifies a behaviour that is misaligned with the new operating model, the leader who oversees that team is personally called on to address it. This level of visible commitment sends a clear signal about the importance of the change and dramatically increases the likelihood that users will take it seriously.

The business is not involved in designing the future state

Many programmes operate with a clear separation between "we build" and "you use it". The technology team and the system integrator design the future state. The business is consulted about current state pain points, but has limited input into what the solution looks like. The business is then asked to change their working behaviour to match the pre-designed solution.

When the business is not involved in designing how they will work, adoption becomes much harder. Users feel that the new system was designed by people who do not understand their work. They see gaps and inefficiencies that could have been addressed if they had been asked. They default to workarounds not because they are resistant to change, but because the officially endorsed way of working was never designed with their input.

Design workshops should be co-led by the technology team and the business together. The business brings knowledge of their work and constraints. The technology team brings knowledge of what the system can do. The outcome is a design that is both technologically sound and operationally feasible. Users are then adopting a way of working they helped design, which dramatically increases the likelihood of success.

Nobody measures adoption or capability change

Most programmes measure change management activity. How many people attended training. How many people clicked through the online learning module. How many emails were sent. None of these measures adoption or capability change. They measure exposure to change messaging.

Adoption is measured through system usage data. Are people logging into the system and using it? Are they doing what they were trained to do, or using workarounds? Are they following the new process as designed, or defaulting to the old process? These questions require active measurement from the business, not just from the technology team. A user could be logging into the system daily but spending most of their time in a legacy spreadsheet that they built as a workaround.

Capability change is measured through outcome data. A business process that previously took eight hours should now take four. A compliance issue that required manual investigation should now be identified automatically. A decision that previously took a week should now take a day. If these outcomes are not being realised, then the change programme has not delivered, regardless of what the training attendance numbers look like.

Measurement should start at programme initiation, with a clear baseline of current state performance. Capability and adoption should be tracked through the programme and beyond go-live. The first full operating cycle post-go-live is when the business is actually working normally, and that is when adoption and capability change can be properly assessed.