People Do not Resist Change. They Defend What They Already Have.

People rarely resist change outright. What they resist is losing something they’ve already formed a bond with — a process they understand, a spreadsheet they built, a way of working they no longer have to think about. They look at the future through a lens ground entirely from the past, and then they call the result “caution.”

I see this constantly in ERP programs. Not as a personality trait in individual staff, but as a structural pattern that a Project Sponsor either names and interrupts, or quietly allows to run the program into the ground.

Here’s what it looks like, why it stalls programs longer than any technical issue does, and what a Sponsor actually does about it.

The Pattern

Once attachment to “what we have” sets in, a few things happen predictably.

People start finding more problems than solutions. Every new process surfaces five objections and no proposed way through. Not because the objections are wrong — because the mind keeps replicating what it already knows, and anything that doesn’t match gets flagged as a defect rather than evaluated on its own terms.

The new system looks ambiguous. The old one — even the one you’re replacing because it’s failing — gets remembered as stable and certain. Nobody asks whether that certainty was ever real. It’s just familiar, and familiar reads as safe.

And here’s the part that actually stalls a program: people keep telling you they’re open to change. They mean it. Then, in the next breath, they evaluate every proposed solution against what they used to have — not against what the organisation actually needs going forward. The new gets compared to the old, loses on familiarity every time, and the program doesn’t move.

What This Looks Like in the Room

You’ve seen these, even if you haven’t named them:

• A steering committee that spends three meetings “gathering feedback” on a new approval workflow, and each round of feedback is really a different version of “can we keep it closer to how we used to do it.”
• A finance team that goes live on the new system, then quietly keeps the old spreadsheet running “just to double-check the numbers” — six months past go-live.
• A status report that says “team is engaged and supportive of the change” in the same month that adoption metrics show half the transactions still routed through workarounds.
• A sponsor who asks “what are the risks with the new solution,” but never asks what the risk is of staying on the current one.

None of this shows up as resistance in a RAID log. It shows up as delay, re-litigation, and a program that looks fine on paper while nothing actually changes underneath. That’s drift, and it’s the Sponsor’s problem to solve — not the project team’s.

What the Sponsor Actually Does

1. Name the pattern before you try to fix it.

Most Sponsors skip straight to persuasion — more workshops, more comms, another town hall explaining the benefits. That doesn’t work, because the resistance was never about lacking information. It’s a comparison being run against the wrong baseline. Your job is to say it out loud, in the room: “We keep testing this against what we used to have. That’s not the test that matters.” Until the pattern is named, every discussion about the new solution is secretly a referendum on the old one.

2. Disrupt it with constraints, not more persuasion.

Once you’ve named it, you remove the option to keep defaulting back. That means real constraints — a hard cut-off date after which the legacy system is switched off, not left running “in parallel for safety.” It means quantifying what the old way actually costs: hours spent on the shadow spreadsheet, the errors it introduces, the rework nobody bills to the project. Show the benefit of the new solution in terms that are hard to argue with, not in terms that require faith. People don’t abandon the familiar because you asked nicely. They abandon it when the constraint makes holding on more expensive than letting go.

3. Put the accountability where it belongs — with you.

This is the step Sponsors avoid, because it means owning a decision instead of facilitating a discussion. Set the mandate. Define the conditions the team and vendor are expected to comply with, and stop treating every objection as a fresh negotiation. Then set clear responsibility for finding solutions constructively, ahead of the next roadblock — not for raising more questions and letting uncertainty sit unresolved in the working group. A project team that’s allowed to keep surfacing problems without owning the corresponding solution isn’t being thorough. It’s being permitted to stall.

The Real Cost

None of this is about pushing change through by force. It’s about recognising that “we’re still evaluating” and “we’re gathering more feedback” are, past a certain point, not diligence — they’re the old system‘s grip on the room, and every week you let it hold on is a week the new investment isn’t producing value.

The technology was never the hard part. Holding the line while people work through their attachment to what they already had — that’s the job. And it’s yours, not the vendor’s, not the project manager’s.