Increasingly, companies are drawing a line between managing the project and influencing adoption. But is that really the right move?
When he called me, his team just six weeks out from launching a new Field Ops system. He needed someone from my team to come in and “do change management” on a project where users hadn’t been consulted, stakeholders were in the dark, and the term “user readiness” had never once appeared on a status report.
As I listened, I kept thinking about the invisible walls we build:
- The project manager shouldn’t worry about requirements. That’s the BA’s job.
- The project manager shouldn’t bother learning a system’s technical details. That’s the developer’s job.
- The project manager shouldn’t worry about user adoption. That’s the change management lead’s job.
As a consultant, I’m always struck by the mindset differences between large companies and small ones. Big companies have the luxury of specialists, which should be a good thing. And it can be.
But when everyone stays in their lane, something important also gets lost. The PM’s mandate shrinks. They no longer feel responsible for the entire ecosystem of perceptions, politics, and people that decides if a project sinks or swims.
Which brings me to this week’s question:
Why do we treat project management and change management like two distinct skills? And can we really afford to keep doing that?
The Case for Separate Roles
To be fair, the logic for specialization is sound. Effective change management is a craft. It draws on organizational psychology, communication theory, and a deep understanding of human behavior. It’s about navigating the messy, unpredictable world of how people react when their work lives are upended. Asking a project manager—who is already juggling scope, budget, vendors, and timelines—to also be an expert in this is a big ask.
On large, enterprise-wide transformations, having dedicated specialists can be a winning combination. The PM focuses on the bigger picture, ensuring the car is built to plan (and that the plan still makes sense). The Change Manager focuses on adoption, making sure people know how to drive and actually want to take it for a spin. When this partnership works, it’s a thing of beauty. They operate as a single, cohesive unit, covering all the bases and anticipating risks from every angle.
The Dark Side of “Stay in Your Lane”
The problem begins when this practical division of labor hardens into a belief that the PM is not a change leader. The classic “stay in your lane” approach turns practical role boundaries into hardened battle lines.
When PMs are implicitly (or explicitly) told their job ends where adoption begins, we get what I call “project administrators.” They are skilled at tracking progress and managing spreadsheets, but they are fundamentally disconnected from the project’s ultimate value. Their goal shifts from delivering a successful outcome to simply delivering on time and on budget, even if the thing they deliver never gets used.
When we tell PMs to stick to managing the plan and let someone else worry about the people, we neuter their ability to lead. We make our projects vulnerable to the most common and devastating risks: low adoption, stakeholder resistance, and a complete failure to achieve the promised ROI. These aren’t soft issues; they are the core business risks.
The same thing happens when we draw rigid lines between the PM and the BA, which I’ve written about here.
It’s Time to Ask: Why Do We Ask So Little of PMs?
Over the past couple of decades, we’ve systematically carved up the project management role, handing off slices to other specialists.
We brought in Technical PMs to lead the developers, Business Analysts to own the requirements, and Change Managers to own the people. Each decision was made with good intentions, aiming to bring deeper expertise into the fold.
But in doing so, have we unintentionally hollowed out the project manager role itself? Have we defined it so narrowly that we’ve demoted project leaders to project coordinators?
It’s a strange contradiction. We expect PMs to influence without authority, yet we draw tight little boxes around what they are permitted to influence. We hold them accountable for project success but discourage them from engaging with the single biggest factor in that success: whether anyone will actually use what they build.
It feels like we’re asking them to win the game while telling them they can’t touch the ball. We need to expect more.
If You Have the Staff, Separate Roles Can Be a Winning Model. But Here’s the Case for Blurry Lines.
I’m not advocating for firing all your change managers. In a well-resourced organization, having a strong PM and a strong Change Manager on every key initiative is the gold standard. The key is that their roles shouldn’t be two parallel tracks that only meet at the finish line. They should be a tightly woven braid.
The most successful projects I’ve been on are the ones where you can’t quite tell where the PM’s job ends and the Change Manager’s begins. They share a stakeholder map. They co-facilitate some workshops. The Change Manager flags a communication risk that could throw off the timeline, and the PM adjusts the plan. The PM identifies a technical dependency that will impact training, and the Change Manager gets a head start on redesigning the materials.
The lines are blurry because they both know they serve the same master: a valuable change that actually sticks.
Here’s What PMs Should Be Able to Do:
Whether a PM is on their own or negotiating boundaries with a Change Lead, every PM must have a foundational literacy in the principles of change. This isn’t about becoming an expert; it’s about being aware and proactive.
Every PM should be able to:
- Map the human terrain: Who is impacted? Who holds the power? Who is likely to champion this, and who might quietly sabotage it?
- Treat adoption as a risk category: In every status update, they should be asking, “What are the biggest threats to people using this, and what are we doing about them?”
- Build readiness into the project plan: Training, communications, and user support aren’t afterthoughts you cram in at the end. They are critical dependencies that belong in the Gantt chart from day one.
- Tell the story: A PM shouldn’t just report what’s happening; they must be able to articulate why it’s happening and what it means for the people who have to adapt.
And Here’s What Change Managers Should Be Able to Do:
By the same token, Change Managers cannot be effective if they operate in a project management vacuum, focusing only on feelings and feedback. To be true strategic partners, they need a solid grasp of how projects actually get done.
A great Change Manager should be able to:
- Read a project schedule: They must understand the critical path and how their activities—like a town hall or a training pilot—fit into the larger sequence of events.
- Understand the “how”: They need to know enough about the technology or process being implemented to ask intelligent questions about how it will truly impact the day-to-day work of users.
- Translate sentiment into project risk: Instead of just reporting “stakeholders are anxious,” they should frame it in terms the project team understands: “If we don’t address this anxiety, we risk a 30% drop in adoption of the most important feature, which puts our entire business case in jeopardy.”
- Connect their work to the bottom line: They should be able to draw a clear line from their efforts to the project’s most important metrics, showing how change management directly contributes to success.
PMOs: Start Hiring T-Shaped Experts
So, where does this leave PMO leaders who are trying to build a high-performing team? It’s time to start deliberately hiring “T-shaped” professionals. These are people with deep expertise in one primary discipline (the vertical bar of the “T”) but also possess broad, functional knowledge across several related areas (the horizontal bar).
A T-shaped PM has deep skills in planning and execution, but also has a working knowledge of change management, business analysis, and product thinking.
A T-shaped Change Manager is an expert in human dynamics but can also read a project charter and contribute to a risk-register workshop.
These are the people who can see the entire system, not just their assigned part. They are the connectors, the integrators, and the leaders who thrive in the messy, overlapping spaces where real work gets done. For too long, we’ve prioritized specialization. It’s time to start valuing integration.
If You Only Do One Thing
This is going to sound dangerous, but hear me out.
Coach your team to start blurring lines in their work.
They still need clarity of accountabilities (role definitions) and tasks (who does what at any given time). But they also need unity in their mandate. A shared sense of risk. A common mindset that shows up no matter who is (or isn’t) in the meeting.
Here’s how to do it:
- Coach your PMs to find a moment this week to ask: “What is the biggest non-technical threat to my project’s success, and how can I help mitigate it?”
- Coach your Change Leads to find a moment this week to ask: “How can I help the PM understand how my work fits into the schedule, and opportunities to save time or mitigate risk?”
Start a new kind of conversation. You might be surprised by what you discover when you step across that invisible line.