Why change management fails before the project starts
The most common cause of failed change programmes is not resistance during rollout. It is the decisions made in the weeks before anyone knew the project existed.
When a change programme fails, the post-mortem usually lands on resistance. The team did not engage. Key stakeholders checked out. People went back to the old way of doing things as soon as attention moved elsewhere.
That is often true. But the resistance is rarely the cause. It is the symptom of decisions made weeks or months before the project was formally announced.
The scoping problem
Most projects are scoped by the people who want the change to happen. That is a reasonable starting point. But it becomes a problem when the scope is fixed before anyone has asked the people who will be affected by the change what they think.
By the time those people hear about the project, it has a budget, a timeline, and a name. The people running it have already invested in the approach. Feedback at that stage is rarely welcome, and the people giving it can sense that.
This is not a communication problem. It is a sequencing problem. The consultation happened too late to change anything meaningful.
The “project owner” gap
Change programmes need someone who owns the outcome, not just the delivery. There is a difference.
A project owner who owns delivery is focused on scope, timeline, and budget. A project owner who owns the outcome is focused on whether the change actually happened and whether it stuck.
Many organisations have the first type and assume they have the second. The distinction does not matter much during delivery. It matters enormously six months later, when the new system is running but nobody is using the new process, or when the team has quietly reverted to the approach they preferred.
What to do instead
The change work starts before the project plan. Here is what that looks like in practice:
Map who is affected before you scope the solution. This sounds obvious but it is skipped constantly. The people affected by a change are not the same as the people who asked for it. Get the two lists in front of each other early.
Bring key sceptics in early, not late. The instinct is to bring in supportive stakeholders first and manage the difficult conversations later. This gets the sequencing backwards. A sceptic who is consulted early becomes a translator. A sceptic who is informed late becomes an obstacle.
Separate the “what” from the “how.” People resist the “how” more often than the “what.” If you can give people meaningful input into how the change happens, without reopening the question of whether it happens, you will get better engagement and a more practical implementation.
None of this eliminates resistance. But it changes the nature of it. Resistance that comes from not being consulted is much harder to work through than resistance that comes from having concerns about a specific implementation detail.
The first type tends to show up at launch. The second type tends to show up in the design phase, when you still have time to do something about it.
If this pattern sounds familiar, I am happy to talk through what it looks like in your organisation. Get in touch.