A Change Management Plan Is Only as Good as the Decision It Serves

A change management plan inherits the decision it serves. If that decision rested on an assumption nobody tested, the plan will manage the adoption of a change that should have been reconsidered before the first stakeholder briefing was scheduled. Test the decision, then plan the change.

A change management plan is only as reliable as the decision it implements. Most plans detail communication schedules, training calendars, and resistance strategies without ever stating the assumption the change depends on. If nobody has tested whether the underlying commitment is sound, the plan organises effort around a decision that may already be wrong.

Last year a project manager at an Australian energy utility sent me her change management plan for a systems migration affecting six regional offices. The document ran to thirty-one pages. It covered a stakeholder register, a twelve-week training calendar sorted by function, and a resistance management section that classified employees by their likely adoption speed. What the plan did not contain was a single sentence explaining why the migration had been approved in the first place.

I asked her whether the executive team had tested any of the assumptions behind the decision before giving their approval, or whether the business case had simply been accepted on its own terms. She told me the CIO had presented a business case in February and the board had signed off in March. That was authority, not analysis. Nobody had asked what conditions needed to hold for the migration to deliver its promised savings, or what early signal would indicate the case was breaking down.

That definition is accurate as far as it goes. Nevertheless, it conceals the load-bearing assumption behind every change management plan: that the decision it supports was made properly, and that someone examined the assumptions holding the case together before the spend was approved.

In nearly 50 years of working with organisations in heavy industry and government, I have found that assumption unsupported more often than confirmed. The plan becomes what Roger Estall and I call secondary-element work in Deciding: machinery around the decision, not the decision itself.

A change management plan is a structured document that coordinates the activities needed to implement an approved organisational change, from stakeholder communication through post-launch monitoring.

Why Most Change Management Plans Fail Before They Start

The most cited statistic in the field is that 70 per cent of change initiatives fail. Beer and Nohria popularised the claim in Harvard Business Review in 2000 without a footnote or any empirical support. No valid empirical evidence sits behind the number. Mark Hughes reviewed the five published sources most commonly cited for that figure in his 2011 paper for the Journal of Change Management and confirmed as much. The number endures because it is useful to change consultants and framework vendors, not because anyone has measured it.

What more recent surveys suggest is less dramatic but more useful. BCG's Henderson Institute found in 2022 that 75 per cent of ambitious change programmes fail to capture long-term value, and their first listed pathology is telling: goals treated as predetermined, "often oblique to the true problem."

The plan inherits whatever the decision assumed. When an organisation skips the work of testing its premises, the plan becomes an elaborate schedule for delivering an outcome nobody verified was achievable, and the underlying organisational change rests on ground that was never examined.

What a Perfect Plan Could Not Save

Click to expand

In the Netherlands, a teaching hospital decided to switch surgical sutures after a routine procurement tender. The standard change management framework was followed. Surgeons were consulted and communication was handled according to the playbook. Graamans and colleagues documented what followed in 2020: surgeon resistance escalated until the hospital cancelled the switch entirely.

By any template standard, the plan followed correct procedure. The procurement decision, however, had never tested whether the new suture was compatible with how surgeons actually work in time-pressured procedures. The plan managed the rollout competently; the decision it served had not earned commitment.

This is the pattern I encounter repeatedly in change management work. Organisations invest weeks building a detailed plan, complete with Gantt charts and stakeholder heat maps, while the decision at the centre was approved on authority rather than on analysis. The plan channels activity upward and provides a visible demonstration that change is being managed. What it rarely does is test whether the change deserves the resources committed to it.

Name the assumptions sitting under your next change before they surface as resistance. Start the Walk →

What Resistance Is Actually Telling You

Most plans include a section on resistance. The usual treatment is diagnostic: classify people by type and assign engagement tactics. The assumption embedded in this structure is that resistance is irrational and located in the people being asked to change.

Ford, Ford, and D'Amelio challenged this directly in their 2008 Academy of Management Review paper. Resistance, they argued, is not "an irrational and dysfunctional reaction located 'over there' in change recipients." Change agents contribute to resistance through their own actions, including broken agreements and failures of legitimacy. In our framework, resistance functions as a resource: an early signal that something in the original case does not hold.

The Dutch hospital suture case makes this concrete. The surgeons who resisted were not being irrational; they were identifying a compatibility problem that the procurement decision had failed to test. A plan that treats resistance as a communications problem will try to message its way past the objection. A plan that treats resistance as information will go back to the decision and ask what assumption the resisters are exposing.

The second approach requires knowing what the assumptions were, which means surfacing them before mobilisation rather than managing them afterward.

This is where the Universal Decision-Making Method enters. It places the step of recognising assumptions before implementation, not during it. In my experience, when assumptions have been named and tested in advance, the resistance profile changes, because people resist differently when they can see that the case was examined honestly, even if they disagree with the conclusion. The transition management literature often treats resistance as emotional friction to be smoothed away; the better question is whether the friction points at a factual gap in the original decision.

What to Test Before You Write a Change Management Plan

The pocket card in Appendix E of Deciding does not begin with communications or stakeholder buy-in. It begins with purpose: what is this organisation for, and what opportunity does this change address? From there it asks what outcome the decision should produce and how long the effects are expected to last. Only after those questions are answered does the methodology move to implementation and monitoring.

In practical terms, this means sitting down with the sponsor before a single slide is drafted and working through the primary change in language that anyone in the organisation can follow. What exactly is being altered, and what outcome does the organisation expect over what period? What has to remain true for that outcome to materialise? What evidence, available within the first weeks or months, would show the case holding or failing?

If nobody can answer those questions in plain language, the organisation does not have a tested decision; it has a mandate, and mandates do not survive contact with reality any better than untested hypotheses.

The plan still has a purpose. It is the sequence that matters: examine the decision first, then build the plan around what you find. Making assumptions visible, as Roger and I have argued, is the single step that separates a plan worth executing from paperwork that will be abandoned when conditions change. Assumptions, we wrote, "are far more likely to be properly understood and properly taken into account if they are articulated and thus made visible."

What Belongs in a Change Management Plan Once the Decision Holds

Once the decision has been tested and the primary assumptions named, the plan gains a foundation that most templates lack. The first section should be a tested decision statement: one paragraph naming the change and its expected outcome, along with the assumption carrying the most weight. Every other section in the plan should trace back to that statement.

Stakeholder analysis then serves a different purpose. Instead of mapping people by influence and likely resistance, it maps them by which assumption they are closest to and best positioned to monitor. Communication and training anchored to the rationale behind the decision are harder to design than generic messaging calendars, but they produce something people can evaluate rather than merely acknowledge.

Monitoring changes too. Instead of tracking adoption percentages and training completion, the plan should track whether the assumptions behind the decision still hold.

In Deciding, Roger and I identify four ways a change can fail after launch: the original decision was defective, the implementation drifted from what was approved, the supporting activities degraded, or the wider context shifted. Each calls for a different response, and a plan that cannot distinguish between them will misdiagnose every setback.

Monitoring has value only when someone competent reviews the results and understands what the data is saying about the original assumptions; that person must also hold the authority to require action if those assumptions are failing. A standing trigger completes the architecture: if, say, integration costs exceed the original estimate by 20 per cent within the first quarter, the sponsor must reopen the decision rather than request more training. That trigger needs to work in a rollout that keeps live operations running, with a service floor and hold point that let the sponsor pause the next wave before the operating impact spreads.

The difference between a plan built on a tested decision and one built on an approved mandate is the difference between a document that can steer and a document that can only report. I have written separately about the broader frame for what change management can and cannot do. The argument here is narrower: test the decision first, then write the plan.

---

Grant Purdy is the co-author, with Roger Estall, of Deciding (2020), and the architect of the Universal Decision-Making Method.