Low Maturity, High Modernity: You Don't Have to "Grow Up" Before You Can Think Strategically About Change Management

Low Maturity, High Modernity: You Don't Have to "Grow Up" Before You Can Think Strategically About Change Management

This is Part 2 of a four-part series. If you haven't read Article 1 -- "OCM Isn't a Workstream: Why Change Management Belongs Above the Project Swimlane" -- that's the best place to start.

"I'd love to set up a Change Management Office. But we're just not mature enough yet."

I hear this often from my clients. It sounds reasonable. It feels responsible, even -- like you're being honest about your organization's limitations before taking on something ambitious.

But I've come to believe it's exactly backwards.

The idea that you need to earn strategic Change Management through years of maturity-building is one of the most useful lies the workstream model ever told. If the workstream model were a video game final boss, this would be its signature move. It keeps the function exactly where the workstream model wants it: small, subordinate, and waiting for permission.

Here's what I've observed at organizations across the maturity spectrum: maturity and modernity are not the same thing. And you can choose modernity today, regardless of where you are on the maturity curve.

What Maturity Models Actually Measure

Most change maturity frameworks describe a progression that looks roughly like this:

1. Ad hoc -- individual projects do some change activities when they remember

2. Isolated -- a few major programs use structured Change Management; most don't

3. Standardized -- there's a defined methodology and some governance

4. Organizational competency -- Change Management is widely used and expected

5. Continuous improvement -- change capability is embedded in how the org operates

This is genuinely useful. It gives you a way to diagnose where you are, identify gaps, and track progress over time. There's real value in these models.

But notice what they don't specify: where Change Management should sit in your org chart; whether it has its own mandate or just borrowed authority from projects; and whether it gets to challenge portfolio decisions or only serve them.

Maturity models describe how much Change Management you have. They don't tell you what kind. That's the gap that modernity fills.

What "Modern" Change Management Actually Looks Like

Modernity is a mental model, and it shows up in how an organization answers one foundational question: What is Change Management for?

In an outdated model, the answer is something like: "Change Management is for handling the people side of projects -- comms, training, resistance."

In a modern model, the answer shifts to: "Change Management is how we ensure our transformations actually change how we work."

Those two answers produce completely different structures, different placement decisions, and different relationships with the rest of the business.

A modern view means Change Management has its own enterprise mandate, not just project-by-project assignments. It sits above the swimlanes -- in a Change Management Office, Transformation Office, or similar -- with a portfolio-level view. It focuses on how people experience transformation, not just whether they attended training. And it spends as much time building leadership and manager capability as it does designing change plans.

This is a different identity entirely from "the people who write the emails."

Try This -- The Four Quadrants: Where Are You Today?

Put maturity on one axis and modernity on the other, and you get four places an organization can land.

Quadrant 1 -- Low maturity, old model. Change Management is sporadic and project-by-project. When it shows up at all, it's a change workstream focused on comms and training, with no enterprise view and no seat at the table.

Quadrant 2 -- Low maturity, modern model. You don't have a lot of process, headcount, or budget yet, but one or two people have an enterprise-leaning mandate. They sit near strategy, transformation, or HR. They look across initiatives, even informally. Their job isn't just to be "the change resource" for a single project.

Quadrant 3 -- High maturity, old model. Change Management is everywhere. Methods are defined, tools are deployed, and practitioners are trained. But it's still a support function inside project structures, with little real say in portfolio sequencing, capacity, or strategy. Lots of activity. Limited authority.

Quadrant 4 -- High maturity, modern model. You have both breadth and strategic placement. There's a Change Management Office or TCMO with a real mandate and protected budget. Change Management is treated as an enterprise capability, with the authority to match.

Most organizations trying to elevate Change Management are aiming for Quadrant 4. A surprising number get stuck in Quadrant 3 -- they've built up a lot of change activity without ever questioning whether the underlying model is still the right one.

The real opportunity, though, is the move from Quadrant 1 to Quadrant 2. You can make that move right now, without a multi-year maturity roadmap. And it's more valuable than it looks, because it immediately changes the nature of the function and what it can accomplish.

Why Small Organizations Can Still Be Modern

You do not need a 20-person Change Office to adopt a modern stance. You need a few deliberate choices and the willingness to say out loud that Change Management is for something bigger than project support.

Start by deciding what Change Management is for. Not what it does on a task list -- what it exists to accomplish. If your answer is "we handle the people side of projects," you're setting yourself up for Quadrant 1 or 3. If your answer is "we ensure transformations actually change behavior and build the organization's capacity to keep changing," you're already thinking in the right direction.

Give someone an enterprise-leaning mandate. Even if you only have one change leader, explicitly ask them to look across initiatives, surface change collisions and capacity risks, advise leadership on readiness, and create lightweight standards others can use. That person might still support individual projects, but their job is no longer only "be the project's change resource."

Place Change Management closer to strategy than to delivery. If your only change practitioner reports three layers deep into the PMO, they will be treated like a service desk. If they report into a Head of Transformation, HR, or Strategy with a clear cross-portfolio remit, the signals change quickly. Even getting a seat at portfolio review meetings is a meaningful, modern move.

Make people impact a shared responsibility. Instead of letting every project assume that "change owns comms and training," set a different expectation: each workstream owns the content and context for its own changes, and Change Management provides the standards, frameworks, and coaching to do it well. This single shift starts rewiring how the whole organization thinks about ownership and accountability.

Modernity Is a Design Choice, Not a Reward

Here's the mindset shift I'd invite you to consider.

Stop thinking of strategic Change Management as something you earn after reaching a high enough maturity level. Start thinking of it as a design choice you make -- or don't -- at any stage of the journey.

You can be small and modern. You can be large and outdated. The size of your change team, the number of certified practitioners, the sophistication of your methodology -- none of that determines whether you've chosen to position Change Management as a real capability or kept it tucked inside a project lane.

The question isn't "Are we mature enough?" The question is:

"Do we want Change Management to be a project workstream, or do we want it to be the capability that shapes how we transform?"

Your answer to that question should drive how you structure and fund the function next. Not the number on your last maturity assessment.

Next up: What a real Change Management Office looks like when it's designed as infrastructure, not a project support desk, and how to start building one from wherever you are.

If you're just joining the conversation, start at the beginning -- Article 1: "OCM Isn't a Workstream: Why Change Management Belongs Above the Project Swimlane" -- it lays the foundation for everything we're building across this series.

Which quadrant are you in -- and is it by design, or by default?