OCM Isn't a Workstream: Why Change Management Belongs Above the Project Swimlane

OCM Isn't a Workstream: Why Change Management Belongs Above the Project Swimlane

"I need you to own the change management workstream."

The sponsor said it like it was a good thing. Like I should feel seen.

What he was actually telling me: You'll be writing emails and scheduling training. Don't expect a seat at the table.

I've heard that sentence, or a version of it, more times than I can count. And every time, it signals the same thing: this organization has decided that change management is a task list, not a capability. A lane on a Gantt chart, not a function that shapes whether transformation actually works.

Here's what I want to say, plainly:

OCM isn't a workstream. And treating it like one is quietly killing your transformations.

The "Workstream Trap" and How It Happens

Most organizations plan change the same way they plan everything else. They put it in a project structure, break it into workstreams, and assign an owner.

So the swimlane diagram looks something like this:

• Technology

• Process

• Data

• Training

• Communications

• Change Management

It feels tidy. Organized. It even signals that you "take change seriously."

But it's a trap, and here's why.

When Change Management lives in a lane, it gets bounded by that lane's rules. Scope is defined by the project. Budget is controlled by the PM. The success criteria become "did we send the emails?" and "did people attend the training?" rather than "did behavior actually change?"

And when budgets get tight? The "soft" lane gets cut first. You rarely see the Technology workstream de-scoped. You almost never see Compliance scaled back. But the Change Management workstream? Not brought in until Sprint 3 and gone by Sprint 4.

Here's the deeper problem: when Change Management lives inside a lane, power flows the wrong direction. The people making decisions about your scope, timing, and resourcing are optimizing for on-time, on-budget delivery. They are not optimizing for human readiness, long-term adoption, or whether people will still be using this system in 18 months.

That was always a compromise. In 2026, it's a structural failure.

The World Has Changed. The Workstream Hasn't.

When transformation was occasional -- a major system overhaul once every five years -- you could get away with a bounded, project-level approach to change. You finished the project, wrapped up the workstream, and moved on.

That's not the world most organizations are living in anymore.

Today, change is continuous and overlapping. There's no clean "before and after." Instead, there's a digital transformation running alongside an operating model redesign, an AI rollout, and three regulatory shifts -- all at once, all landing on the same people.

AI alone is changing this equation significantly. You're not rolling out a new tool; you're changing what decisions look like, what skills matter, and what "good work" even means. That requires ongoing sense-making, iteration, and guardrails, not just a go-live communications plan.

And the humans absorbing all of this? They're already stretched. Hybrid work, burnout, cognitive overload -- these aren't edge cases anymore. They're the backdrop to every change initiative. Treating them like an afterthought to project delivery is not just ineffective. It's disrespectful.

A workstream, by design, cannot hold any of this. It's too small, too temporary, and too subordinate to the delivery machine it lives inside.

So If It's Not a Workstream, What Is It?

Think about how your organization treats Project Management for a moment.

You don't put "Project Management" in a lane next to Technology and Process. It's a discipline that shapes how everything gets done. It sits above and around initiatives as a shared capability, with its own standards, its own authority, and its own line of sight across the portfolio.

Change Management should work the same way.

As an enterprise capability, Change Management doesn't live inside projects. It shapes them from the outside. It looks across the portfolio to see where people are overloaded, where readiness is shaky, and where the timing is about to create a collision. It defines standards for how change gets assessed and designed. And it builds the skills of leaders and managers not just for one initiative, but for the long haul.

At the same time, it still needs to show up inside initiatives -- co-designing change strategies, coaching workstream teams, and making sure the human side is considered before it's too late to act on it.

The difference, ultimately, comes down to placement and identity.

• Old identity: "The team that does comms and training for projects."

• New identity: "The capability that designs and stewards how this organization changes."

One of those identities belongs in a swimlane. The other belongs alongside Portfolio, Risk, and Strategy.

Try This: Redraw Your Swimlane

Pull up a transformation you're familiar with and look at its swimlane diagram.

Now do three things:

1. Remove the "Change Management" lane entirely.

2. Draw a band above all the lanes, labeled "Transformation and Change Management Office" (or whatever you'd call it in your context).

3. In each remaining lane -- Process, Systems, Data, Talent -- write down what that workstream owns in terms of people impact. Because here's the thing: they already own it. Every workstream has a people responsibility that cannot be outsourced. The process team is responsible for how people learn new ways of working. The systems team is responsible for how users actually navigate the tool. The data team is responsible for what analysts need to understand and trust. Naming it in everyone's swimlane just makes it visible -- and non-negotiable.

4. Now ask yourself some harder questions. What happens when the Process lead can no longer hand "the people stuff" to someone else? What happens when the Systems team has to explain their own UI changes to the people who will use them, rather than passing that off to a change practitioner who's three degrees removed from the actual work? This is not a small shift. When workstreams own their people impact -- genuinely own it, not just list it as a task for someone else -- it changes the conversation for PMs, for executives, and for the project structure itself. Suddenly, Change Management stops being a support function and becomes the standard-setter that every workstream reports against.

The Cost of Staying in the Lane

I understand why organizations stay with the workstream model. It's familiar. It fits the planning templates. It feels manageable.

But the costs are real, and they compound over time.

You get change theater: a lot of visible activity (emails, workshops, dashboards) with very little actual behavior change underneath. Your change practitioners burn out, asked to be both strategic advisors and tactical production support for everything people-related. And you miss the window to build a real enterprise capability, one that outlasts any single program and actually increases your organization's ability to absorb and sustain change.

The organizations that will navigate continuous transformation aren't necessarily the ones with the most polished project plans. They're the ones that have built change capability like infrastructure -- designed deliberately, funded appropriately, and given the authority to influence how the whole portfolio moves.

That starts with one shift in how you see Change Management.

Stop treating it as a workstream. Start treating it as the way your organization changes.

Up next: Why "maturity" and "modernity" in Change Management are not the same thing, and why even low-maturity organizations can choose a more strategic stance today.

Where does Change Management live in your organization -- inside a lane, or above the swimlanes?