QUICK SUMMARY

Our Team Lead, Delivery Management Victoria Etheridge argues most digital transformation projects fail not because of the technology itself but as a result of treating change management as an afterthought.

Digital transformation sounds incredibly glamorous, especially once it’s been wrapped in enough language around innovation, agility, and modernization. In practice, it often looks more like a new tool, a half-explained workflow, and a group of leaders wondering why nobody is using it properly three weeks later. 

In my experience, digital transformation rarely fails because the tool was the wrong one. More often, it fails because the organization treated behavioural change as something to sort out later, “once the real work was done”.  

Cart meet Horse 

When companies talk about digital transformation, they tend to start with technology.

The new platform. A piece of custom software. A Microsoft 365 tool that is meant to improve collaboration. What gets less attention is the part that determines whether any of it works: people now have to do their jobs differently. And this is usually where the trouble starts. 

The start of a change doesn’t begin at launch; it begins much earlier, when the organization is still deciding what is changing, why it matters, who it affects, and what people will need to adopt it successfully. If this work is treated as secondary to the build itself, launch is usually where the confusion becomes visible, not where it begins. A lot of organizations still treat change management as the moment the new thing gets announced and are left wondering why adoption is poor despite their apt communication. 

That early work matters more than many people realize. Before anything goes live, people need to understand what, why, and how that new tool materially affects their day-to-day work. Their say in shaping that change will likely increase their investment in using the new tool. After all, they had a hand in choosing it. The people being asked to change also need the right kind of support.

Documentation may explain what a new tool does with detailed step-by-step instructions, but that’s not the same thing as helping someone understand how they’re now expected to work and equipping them with the knowledge and training to do so. 

Do you have a tool problem or a governance problem?

There’s also work to be done at the organizational level; governance decisions need to be made up front.

Take a fairly ordinary example: a company introduces a new M365-based workflow to improve collaboration and make documentation easier to find. On paper, this is perfectly reasonable. The problem is that nobody is asking, let alone answering, the obvious follow-up questions: 

  • Where is working documentation supposed to live?
  • What counts as final?
  • What belongs in TeamsSharePoint, and Loop?
  • Who is responsible for maintaining the structure, and who decides when the process itself needs to change?

It doesn’t take long for a new tool or process to get blamed for what was really a governance problem all along. 

Custom software implementations are not immune. If anything, it may be more obvious and exacerbate the problem, simply because the investment is larger and the expectations are higher.

A company can build a strong system and still get disappointing results if forethought isn’t given to the downstream effects of a change. Often, none of this is especially dramatic, which is partly why it gets missed. It’s just operationally annoying enough to quietly derail your adoption. 

The beginning of the end

This is how organizations underestimate what digital transformation actually asks of them. 

More importantly, implementation and adoption shouldn’t be treated as the same thing. The work is not finished when the tool is built, or the workflow is launched. In many cases, launch is when the slower and more demanding part begins. Reinforcement of the new processes around the new tools tend to take longer than leaders expect, and people don’t change at the same pace. Managers at all levels need to work with their teams to answer questions, correct drift, and reinforce expectations over time. 

Frameworks like the Prosci ADKAR® Model are useful because they focus on the people side of change, which is where most transformations succeed or fail.

Even without applying a formal model, the principle is simple: if people do not understand the change, don’t buy into it, or are left to figure it out on their own, the transformation will stall no matter how sound the technology may be. A perfect technical solution is nothing without the people who use it. Of course, the right technology still matters. It’s just not the whole job.

If organizations want transformation to stick, they need to spend more time making the change understandable, usable, and sustainable in day-to-day work.