Change Management in Digital Transformation Programs

The most common mistake in transformation programmes is treating change management as a workstream you switch on at the end, a kickoff email, a deck, two training sessions, a job aid PDF, and a post-go-live survey. That is not change management. That is the announcement of a change, which is a different thing. The change itself happens in the weeks and months after launch, when people decide, one workflow at a time, whether the new way is worth the effort it costs them.

This article looks at what actually drives adoption inside transformation programmes: how people decide whether to change a habit, why resistance is more useful than it seems, why middle managers usually decide the outcome, and what has to shift in the operational fabric of the organisation for a new way of working to stick.

People adopt what changes their day in a way that works for them. They do not adopt a vision, a roadmap, or a strategic priority, those are slides. They adopt a workflow that takes less time, a tool that removes a frustration they have been complaining about for two years, or a change that makes their boss leave them alone about something specific. If the new way costs them more time on Monday morning than the old way, no amount of communication will change the outcome.

This is why "what is in it for me" is not a cynical question to wave away, it is the question. A useful early test for any change is to write down, per affected role, what their first day after launch will look like. If the honest answer is "more clicks, two new logins, and a meeting nobody asked for", the programme has an adoption problem before it has a launch date. The work to fix that has to happen during design, not during training.

Resistance to a change usually gets framed as a problem to overcome, something to push through with executive air cover and a more upbeat communications plan. That framing wastes most of the information the resistance contains.

Three kinds of resistance show up, and each one means something different. The first is technical resistance: the new system genuinely does not work for the case the person is raising. This is the most valuable kind, because the person is doing free quality assurance. Listen, fix, ship.

The second is process resistance: the new way works in theory, but it removes a workaround the team had quietly built around a real constraint nobody documented. The right response is not training, it is to surface the constraint and decide whether to address it or accept that the workaround stays.

The third is identity resistance: the change reduces the perceived status, autonomy or expertise of someone who used to be central to the old way. This is the hardest, because no amount of "what is in it for me" works when the honest answer is "less". It needs a direct conversation about new responsibilities, not a glossier comms campaign.

Conflating the three, and treating every objection as identity resistance to be managed around, is one of the fastest ways to lose the credibility of the programme.

The line manager, the person who runs the team meeting on Monday morning, decides what gets brought up, and signs off on the team's priorities for the week, is the single most predictive variable in whether a change sticks. If they visibly use the new tool, ask about it in the team meeting, and protect the time it takes to learn it, the team follows. If they treat it as overhead the executive team has imposed and quietly let people work around it, the team follows that too.

This means middle managers cannot be the last group to be onboarded; they have to be the first. Their training is not "how to use the tool", it is "how to lead the team through the change", which is a completely different skill, and one most middle managers have never been taught. Programmes that treat middle managers as a comms target rather than the primary lever consistently underperform programmes that invest in them as the actual change agents they are.

This is also where leadership ownership shows up in practice, and why the framing in who should lead a digital transformation program matters as much for adoption as it does for governance.

Training has a half-life of weeks. Communications campaigns have one of days. The thing that makes a change permanent is when the operational fabric of the organisation moves with it: the meetings, the KPIs, the reporting cadence, the systems people are evaluated on, the templates a new joiner is handed on day one.

Until those move, the new way is optional, and humans optimise for what they are measured on. Once they move, the old way becomes harder than the new way, which is the only durable version of adoption. A practical test, six months after launch: if a new joiner who has never seen the old way could not reasonably guess that an old way ever existed, the change has landed.

Two specific habits separate programmes that get there from those that do not. The first is measuring real adoption, not declared adoption, actual usage data, not survey responses about how training went. The second is closing the loop on what that data shows: when adoption stalls in a specific team, going to that team in person to find out why, rather than scheduling another all-hands.

Change management in a transformation programme is not the deck at the end. It is the design choice at the beginning, to build the change so that the people who have to live with it actually want to. Programmes that treat it that way spend less on comms, less on training and less on rescue work twelve months in. Programmes that treat it as a launch task spend more on all three and still end up with a system that everyone has been instructed to use and almost no one does.

The wider context, sequencing, governance, leadership roles, how adoption interacts with the rest of a programme, is collected in the digital transformation insights cluster. And when the question is no longer "how do we communicate the change" but "how do we design and run it so that it actually lands", that is exactly what my project management and digital strategy practice is built around.