In almost every digital transformation engagement I get involved in, the same script plays out. An organisation has decided things need to change. A tool has been selected. A budget has been allocated. A project lead has been appointed. And somewhere in the project plan, there's a phase called "change management", scheduled for the final weeks before go-live. That's the moment I know how this is going to end.
That's the moment I know how this is going to end.
The tool is not the problem
Technology is the easy part of digital transformation. You can buy it, configure it, install it. You can hand it to a vendor, set a deadline, assign a budget. It's measurable, tangible, deliverable.
What you can't buy: that people will actually work differently. That they'll embrace a new system instead of working around it. That they'll enter data correctly. That the team leader on the floor will lead by example instead of rolling their eyes at every update.
The tool rarely fails. Adoption fails.
What actually goes wrong
I see the same patterns every time. Middle management that isn't on board: not out of bad faith, but because no one has properly explained what changes for them, and what's expected of them. The employee who has lived through three "new systems" that were quietly abandoned after six months, and who therefore rationally decides not to take this one too seriously either. The executive sponsor who approved the project and has been largely invisible since.
And then there's timing. Change management is not a phase you schedule before go-live. It starts the moment you decide something is going to change. Anyone who begins it later is already too late.
What actually works
There's no formula. But in the transformations that do succeed, a few things are almost always present.
The sponsor isn't just a name on the project charter: they show up, answer questions, and visibly use the new way of working themselves. People notice that. If the person who commissioned the change isn't living it, no one lower in the organisation is going to prioritise it either.
There's also honesty about what the change actually means. "What does this mean for me?" is the question everyone has and almost no one gets a straight answer to. Not the vendor pitch: the real answer: this changes, this gets easier, this disappears. People handle difficult truths better than vague reassurances that fall apart on day one.
Something I've seen make a real difference: making the numbers visible. Not buried in a status report that three people read. Actual adoption data, usage rates, where things are going wrong: shared with the teams involved. When people see that 80% of their colleagues have made the switch, the remaining 20% tend to follow. When they see a particular step generating errors across the board, the conversation shifts from blame to fixing it.
And then there's the thing no one wants to say out loud: not everyone will come along. In every transformation, there are people for whom the new way of working simply doesn't fit. Recognising that early, and being honest about it, is both more humane and more effective than spending months trying to bring them around.
Where the interim manager fits in
In these kinds of engagements, I'm often brought in too late: after the tool has been selected, the project plan is set, and resistance has already started to build. That can still be turned around, but it costs more time and energy than it needs to.
The best outcomes come when I'm involved early: in defining what actually needs to change, before technology takes centre stage. Because the real question is never "which system are we going to implement?" The real question is "how do we want to work two years from now, and what do we need to get there?"
A tool is part of that answer. Rarely the hardest part.