All resources
Leading Through Change 11 min read

Before You Blame Change Management, Zoom Out

When a change starts to struggle, change management is often the first place organizations look. Before we conclude change management failed, we need to zoom out — what looks like a change management problem at the initiative level may actually be an organizational problem when you step back far enough to see the whole environment.

When a change starts to struggle, change management often becomes one of the first places organizations look. Why are people resisting? Why is adoption low? Why are managers frustrated? Why are employees still using the old process? Why are people confused after all the communication and training? Why does implementation seem to be stalling?

Sometimes the answer really is the change management strategy. Communication may have come too late. Managers may not have been equipped well enough. Impacts may have been poorly understood. Training may have missed what people actually needed. Sponsorship may not have been activated effectively.

However, before we decide that change management failed, I think we need to zoom out. Change does not succeed or fail inside the boundaries of a change plan. It happens inside an organization, and that organization already has its own capacity constraints, priorities, leadership behaviors, operational pressures, technology problems, resource limitations, history with previous changes, and dozens of other things competing for people's attention.

This is important because what looks like a change management problem at the initiative level may actually be an organizational problem when you step back far enough to see the whole environment.

We manage initiatives separately, but people experience them collectively

Most organizations structure change one initiative at a time. Each project has its own business case, sponsor, timeline, project plan, communication strategy, training plan, stakeholders, and measures of success. From inside that project, the expectations can look perfectly reasonable.

The employee experiencing the change does not have that same view. They are not experiencing Project A in isolation from the system implementation happening next month, the cost-reduction effort, the restructuring, the new performance process, the AI rollout, the leadership transition, and the operational targets they were already responsible for meeting.

Their manager may be trying to translate all of those things while continuing to run the team, manage performance, coach employees, solve problems, hit deadlines, and absorb the same organizational change themselves.

From the project level, each initiative may be manageable. At the organizational level, the cumulative effect may be very, very different.

This is one of the reasons I think organizations need to think more seriously about portfolio change management. It is not enough to ask, "How are we managing this change?" We also need to ask, "What environment is this change entering?"

Adoption is shaped long before the change plan is executed

We tend to associate adoption with the activities that happen closer to implementation: communication, training, manager conversations, reinforcement, feedback, and resistance management. Those things absolutely matter, but many of the conditions that ultimately determine how difficult adoption will be were created much earlier.

Adoption is already being shaped when leaders decide what needs to change and why. It is shaped when timelines are established, when priorities are set, when resources are allocated, and when an organization decides whether to sequence initiatives or stack them on top of one another. It is shaped by whether the people closest to the work were involved in designing the future state and whether managers were brought in early enough to understand what their teams would actually be expected to do differently.

It is shaped by whether the technology works, whether the process makes sense in practice, whether leaders stay engaged once implementation becomes difficult, and whether people have enough capacity to learn and adopt something new while continuing to deliver everything already expected of them. It is also shaped by what happened during the last five changes the organization asked people to adopt.

By the time leaders see resistance, low adoption, frustration, disengagement, workarounds, or managers saying their teams cannot absorb another thing, they may be looking at the downstream effects of decisions that were made months earlier. That does not remove accountability from change management. It simply means change management cannot be the only place we look when an organizational change struggles.

Change management can identify a risk without having the authority to fix it

Good change management often does exactly what it is supposed to do: it makes risk visible. A change practitioner may identify that managers do not have enough context to lead the change, that the organization is already overloaded, that multiple initiatives are affecting the same employee population, that leadership alignment is weaker than it appears, or that the implementation timeline creates significant adoption risk.

Change assessments may surface that employees were involved too late, that the future-state process creates operational problems, or that the technology is not stable enough for the behavior change being requested. Those are valuable findings, but assessment is not authority.

Change management may be able to identify that the timeline is unrealistic without having the authority to change the project schedule. It may identify saturation without being able to stop another initiative from launching. It may recommend stronger sponsorship without being able to force a leader to stay engaged. It may show that teams need additional capacity without controlling staffing or resource decisions. It may identify that the future state is creating friction without owning the technology, process, or solution design.

That is where organizations can create an accountability problem. Change management surfaces the risk, the organization chooses to continue without meaningfully addressing it, and then when adoption struggles later, the question becomes, "Why didn't change management get people on board?" Or we could ask the question of whether the organization created conditions in which getting people on board was reasonable in the first place.

This is where a portfolio view changes the conversation

Looking at change initiative by initiative gives us useful information, but it does not give us the whole picture. A portfolio view helps leaders understand the broader environment in which all of those individual changes are occurring.

Instead of only asking whether one project has a communication plan or a sponsor, we can start asking where change is concentrated across the organization. Which teams are absorbing the greatest cumulative impact? Which initiatives are competing for the same leaders, managers, employees, resources, and attention? Where are priorities conflicting? Which changes are truly business-critical, which can move, and which may need to be sequenced differently?

It also allows us to look more honestly at organizational capacity. Are we repeatedly asking the same managers to translate, reinforce, coach, troubleshoot, and sustain several major changes at once? Are employees being asked to learn new systems, processes, responsibilities, and ways of working simultaneously? Are different projects independently making reasonable requests that become unreasonable when they all land on the same population?

This is why portfolio change management is about more than building a heat map of projects. The real value is in helping leaders make better decisions about the environment in which change is expected to happen.

Sometimes the appropriate intervention really is better communication, stronger training, more manager support, or a different engagement strategy — AND sometimes the answer sits further upstream. Maybe two initiatives need to be sequenced differently. Maybe a timeline needs to move. Maybe leaders need to clarify which priority actually takes precedence. Maybe scope needs to change. Maybe resources need to be added. Maybe a technology problem has to be solved before employees are expected to change their behavior around it. Sometimes something truly does need to stop.

Those are not communication problems. They are organizational decisions.

Low adoption is a signal, not a diagnosis

Organizations can be quick to treat visible symptoms as explanations. Low adoption tells us something is happening, but it does not always tell us why. The same is true for resistance, disengagement, workarounds, frustration, or a manager telling you their team cannot handle another change.

Those outcomes should prompt investigation rather than immediate labeling. Maybe people genuinely do not understand the change. Maybe training was insufficient. Maybe managers need better tools or more context. Maybe the communication strategy needs to change.

But there are other possibilities too. People may understand the change perfectly well but not have enough capacity to execute it. The new process may conflict with another initiative. Managers may have been told that five different things are all the highest priority and are now left to decide what gets dropped. The future state may make sense in a project plan but create problems in day-to-day operations. Employees may have been through so many "critical transformations" that were later abandoned that they are waiting to see whether this one will actually last. The organization may simply be trying to consume change faster than it is creating the capacity to absorb it.

If we immediately describe those outcomes as employee resistance or poor change management, we may spend a great deal of effort trying to solve the wrong problem.

Before you ask what change management missed, look at the system

When an initiative struggles, the change strategy should absolutely be reviewed, and that review should be part of a larger conversation about the conditions surrounding the change.

Was the change connected to a clear business need? Was the future state actually workable? Were the people closest to the work involved early enough to identify practical impacts? Did the project have the technical and operational readiness required to support what employees were being asked to do differently? Were leaders aligned beyond the kickoff? Were managers given enough context to lead, rather than simply being handed talking points shortly before launch?

We should also be asking whether people realistically had capacity for the change and what else was happening to the same population at the same time. Were competing initiatives considered when timelines were established? Were risks identified by change management actually used as inputs into decisions? Was anyone looking across the full portfolio of organizational change, or was every project team looking only at its own initiative?

That last question is huge because every initiative can make sense independently while collectively creating an environment where successful adoption becomes increasingly difficult.

Change management cannot compensate for every organizational decision

Change management is powerful. It can create clarity, identify impacts, strengthen sponsorship, equip managers, build feedback loops, prepare employees, anticipate risk, and make adoption easier.

But it cannot 'communication plan' its way out of every organizational problem. It cannot train people into having more capacity. It cannot stakeholder-map its way around conflicting priorities. It cannot create strong sponsorship on behalf of leaders who are unwilling to remain involved. It cannot make unstable technology stable or turn an unworkable process into a good one through messaging. It cannot make five simultaneous priorities feel like one. It cannot sustainably create adoption for a future state that the organization itself has not made workable.

That is why I think we need to expand the conversation when organizational change stalls. We cannot simply ask "What did change management miss?" without also posing the question, "What happened across the system that made this change harder to adopt?"

Look at the initiative, but also look at leadership. Look at project decisions. Look at the operational environment. Look at manager capacity. Look at the other changes happening simultaneously. Look at what risks were surfaced and what decisions were made in response. Look at the portfolio.

Change management should absolutely be accountable for the quality of change management, but let's keep in mind that successful organizational change is bigger than the change management function. Adoption is an organizational outcome. If we want to understand why change succeeds, stalls, or fails, we have to be willing to zoom out far enough to see the whole system.


What a portfolio view actually looks like

Below are sample screens from the kind of portfolio change management view I use with organizations. This is what "zooming out" looks like in practice — one place to see every initiative, where change is concentrated, when it lands, and which teams are absorbing the most.

Executive Overview — active programs, average change load, overloaded units, and a change collision warning showing role groups being hit by multiple programs at once
Executive Overview — active programs, average change load, overloaded units, and a change collision warning showing role groups being hit by multiple programs at once

Where the leadership conversation starts. Not "how is Project X going?" but "what is our whole organization actually carrying right now?"

Program Schedule — a Gantt-style timeline of every program with change load coded by colour, projected go-live dates, and a today marker so pile-ups are visible before they hit
Program Schedule — a Gantt-style timeline of every program with change load coded by colour, projected go-live dates, and a today marker so pile-ups are visible before they hit

Every program plotted on one timeline so you can see the pile-ups before they hit. When five "Heavy" go-lives land in the same quarter, that is not a change management problem waiting to happen — it's a sequencing decision waiting to be made.

Organization view — role groups ranked by cumulative change saturation, with several groups already at 100% saturation from multiple simultaneous programs
Organization view — role groups ranked by cumulative change saturation, with several groups already at 100% saturation from multiple simultaneous programs

When six role groups are already at 100% saturation, the question is no longer "how do we get them on board?" It's "what do we stop, move, or resequence?"


Want to talk about building your organizational portfolio of change to drive your adoption strategy? Let's chat — hello@managemeantexcellence.com.

Save it for laterSave to Pinterest
Management, honestly — the newsletter

Get the newsletter.
Practical management, in your inbox.

New posts, manager resources, and the occasional honest note — no fluff, unsubscribe anytime.

No spam, ever. Unsubscribe in one click.