Building a Change Management Office That Isn't Just a Project Support Desk

Building a Change Management Office That Isn't Just a Project Support Desk

This is Part 3 of a four-part series. If you're landing here for the first time, Article 1 -- "OCM Isn't a Workstream" -- is where the argument begins.

Here's a pattern I've seen more times than I'd like.

An organization announces they've set up a Change Management Office. Leadership feels good about it. The change team feels validated. And then you look closer and realize:

Everyone is funded entirely through project chargebacks. Their days are consumed by slide decks, email drafts, and training logistics. Nobody invites them to portfolio conversations. And when a project manager wants to cut change scope, there's no real mechanism to push back.

That's not a Change Management Office. That's a centralized slide factory with a better title.

If you want Change Management to operate outside the project swimlane -- to function as a strategic capability rather than a glorified service desk -- the design of your CMO or Transformation and Change Management Office matters enormously. Here's what that design actually needs to include.

First: What Is a Real CMO/TCMO For?

Before you draw an org chart or write a job description, answer a more fundamental question: what problem does this office exist to solve?

A real Change Management Office exists to answer this:

"How does this organization change -- consistently, sustainably, and repeatedly -- across everything it does?"

Not "how does Project X manage its people impacts?" That's a project question. The CMO question is an enterprise question. And to answer it, the office needs a mandate in four areas.

Enterprise change strategy. Defining how the organization approaches transformation: what principles apply, what standards major initiatives must meet, and what level of change investment different types of initiatives require. This isn't a methodology binder on a shelf; it's a living set of standards the CMO owns and updates.

Portfolio-level change intelligence. Maintaining a view of all major initiatives and their combined impact on people. Tracking change load, saturation points, and readiness signals across key groups. Providing early warning when the portfolio is about to overload critical populations. This is the kind of signal that gets missed entirely when Change Management is embedded project by project.

Capability building. Equipping executives, managers, and project teams with change leadership skills that outlast any single program. Building communities of practice. Creating the tools and playbooks that make good change easier to do consistently across the organization.

Strategic advisory to major initiatives. Joining significant programs early -- not at communications planning time -- to shape scope, sequencing, and adoption strategy. Having the standing to challenge decisions when readiness and ambition are badly misaligned.

These are enterprise functions. A project workstream cannot own them. Only an office with an enterprise mandate can.

Where the CMO/TCMO Sits -- and Why That Matters

Organizational placement is not a bureaucratic detail. It's a signal about power, and everyone in the organization reads it.

If your CMO reports deep inside the PMO, it will be treated like a PMO service function. Projects will "request change resources" the same way they request test environments. The CMO won't have standing to challenge portfolio decisions; it can only respond to them.

If your CMO or TCMO reports into a senior enterprise role -- a Chief Transformation Officer, COO, Head of Strategy, or CHRO -- it has a fighting chance at being seen as a peer to the functions it needs to influence: PMO, HR, Risk, and Strategy.

That peer relationship matters a great deal. Because Change Management's job is not to help individual projects look good on their status reports. Its job is to help the organization change in a coherent, sustainable way. Those are different mandates, and they sometimes create real tension that only works if both parties have equivalent standing.

A few design principles worth holding onto as you think this through.

Peer to PMO, not subordinate. PMO optimizes for delivery -- on time, on budget. The CMO/TCMO optimizes for adoption and human outcomes. These perspectives should challenge and inform each other from a position of relative equality, not from a hierarchy where delivery always wins.

One foot near strategy, one near people. The best placement has Change Management connected to both strategic ambition (what are we trying to become?) and human reality (what can our people actually absorb?). That dual connection is where its real value lives.

Funding It Like Infrastructure

Here's one of the clearest signals about whether an organization truly believes in strategic Change Management: how it funds the capability.

If every change role is funded entirely through project chargebacks, change will always be seen as a project expense -- and project expenses get cut. It really is as straightforward as that.

The alternative is a two-bucket funding model that separates the core from the flexible.

Central infrastructure budget. This covers the core CMO/TCMO team, the tools and platforms needed to maintain a portfolio view, and the capability-building programs that benefit the whole organization. This budget exists regardless of how many projects are live this quarter. Its existence signals that change capability is part of the organization's permanent architecture, much like IT or Finance.

Project-linked recharge budget. This covers embedded change leads assigned to major programs and surge support for high-intensity moments like cutovers or mergers. Projects fund these roles, but the people still belong to the CMO/TCMO for methods, coaching, and performance management. They go where the work is, but they come home to the same professional community and the same standards.

This hybrid model does three things at once: it protects the core capability from project-by-project budget negotiations, it gives you the flexibility to direct capacity where the work is, and it preserves the CMO's strategic identity even when its people are embedded in delivery programs.

How the CMO/TCMO Actually Relates to Projects

A common concern I hear when I talk about elevating Change Management: "If change is above the swimlanes, does that mean we're not in the trenches anymore? Are we just writing strategy papers?"

No. The relationship changes, but the connection absolutely stays.

The clearest way I've found to frame it is this:

• The CMO/TCMO owns the "how we change" system.

• Projects and workstreams own the "what we change" and "who's affected."

In practice, the CMO/TCMO sets minimum standards for change assessment and sponsorship, provides shared tools, reviews major initiatives at key decision points, and surfaces cross-initiative risks. Projects use those tools, own their own change content and communications, and bring the CMO in when their change footprint is large, risky, or colliding with another initiative.

The shift is from doing all the people work for projects, to designing the system that makes people work done well everywhere. That's not backing away from the work. It's doing more important work.

A Minimalist Blueprint for Starting From Scratch

You don't need a full org redesign to begin. Here's a practical entry point that works even at small scale.

Name the capability and give it a sentence. Decide what you'll call it -- Change Management Office, Transformation and Change Office, Enterprise Change Capability -- and write a one-sentence purpose statement. Something like "We design and steward how this organization changes." That sentence does more work than you'd expect, because it immediately clarifies what you're there for and, just as importantly, what you're not.

Place it deliberately, even at small scale. Even if you're starting with one or two people, align them to a senior leader with enterprise accountability. Give them a cross-portfolio remit, not just project assignments.

Protect a core budget. Even modest central funding -- for tools, capability programs, and the people who hold the enterprise view -- changes how the capability is perceived. It signals permanence rather than contingency.

Establish three non-negotiables for major initiatives. A basic change impact assessment. A named executive sponsor with a defined role. A readiness check before critical milestones. These three moves alone begin shifting Change Management out of project support territory and into something with real standing.

A Self-Diagnostic for Those Who Already Have a CMO

If you already have something called a Change Management Office, ask yourself honestly:

• How much of our time goes to enterprise-level work versus project production?

• Do we have any budget that isn't tied to specific project codes?

• Can we say "not yet" when change load is too high -- and does anyone listen when we do?

If the answers are "mostly production," "not really," and "not really," then you have the title of a CMO without the mandate of one.

The good news is that's a design problem, and design problems can be fixed.

Next: Why "comms and training" don't belong to the change team, and what happens when you shift that ownership back to where it belongs.

This is Part 3 of a four-part series on repositioning Change Management as a strategic enterprise capability. Read the full series: Article 1 -- "OCM Isn't a Workstream" | Article 2 -- "Low Maturity, High Modernity" | Article 4 -- "Stop Outsourcing Comms and Training to Change."

What's one thing your CMO/TCMO owns that it probably shouldn't -- and one thing it should own that it doesn't yet?