The Project Succeeded. Did the Change?
- jahzeel47
- 3 days ago
- 3 min read
Why PM and CM Need to Stop Running on Parallel Tracks
There’s a moment most project managers and change practitioners know well. The system goes live. The budget closes clean. The project is declared a success. And then, six months later, someone asks: Is anyone actually using it?
The silence that follows that question is expensive.
This is the gap I’ve spent my career studying and closing; the space between delivery and adoption, between a project that finished and a change that stuck. It exists not because project managers aren’t doing their jobs, or because change managers aren’t doing theirs. It exists because, in most organizations, they’re doing their jobs on entirely separate tracks.
If you’ve ever arrived at a stakeholder meeting where scope was already frozen and the go-live date was already set; and been handed a change management plan to build around decisions that were never yours to shape, you know exactly what this gap feels like from the other side.
Three Outcomes. Most Organizations Only Measure One.
When I work with project teams, I ask them to distinguish between three things that often get collapsed into one:
Delivery is what project management traditionally measures: go-live, on time, on budget. The system is live. Requirements are met. Budget is closed. By every traditional project metric, this is success.
Adoption is what change management measures: are people actually using it? Were behaviors changed? Was resistance addressed? A change practitioner can check every box on their plan and still hand off to an organization that quietly reverts to old habits within a quarter.
Sustained Value is what the organization actually needs: did it stick, and did it matter? Did outcomes realize at 90 or 180 days? Did the ROI materialize? Did the culture shift the way the business case assumed it would?
Most organizations measure the first. Some measure the second. Very few deliberately measure the third because by the time sustained value can be assessed, the project is closed, the team has disbanded, and no one has been named as the owner of what comes next.
What Parallel Tracks Actually Cost
When PM and CM run independently, delivery is optimized at the expense of everything that comes after it. Both disciplines are doing valuable work but without deliberate integration, they are optimizing for different finish lines, and the organization ends up crossing neither.
The failure patterns are predictable:
• CM is brought in after scope is already set, making the response plan reactive rather than designed.
• Risk registers stay separate; PM tracks technical risk, CM tracks people risk and neither team sees the full picture.
• Training gets disconnected from the schedule; too early (people forget) or too late (go-live pressure). Either way, it doesn’t land.
• Success gets measured at go-live, not at 90 or 180 days. Nobody owns the outcome after the project closes.
• Reinforcement is left to chance. The CM practitioner moves on. No one has a plan to sustain the behavior change.
Each of these failure points is individually addressable. Together, they describe an organizational design problem.
Integration Isn’t About More Meetings
The solution isn’t to make PM and CM sit in the same room more often. It’s to give them shared artifacts — shared anchors that force integration as a structural reality rather than a goodwill gesture.
The five principles I work from:
Involve change at charter stage. Not as a recipient of the charter, as a co-author. Stakeholder register, change risk, and adoption metrics start here, before scope hardens.
Define adoption metrics before go-live. What does 80% adoption look like? Who measures it? When? These questions need answers at planning, not retrospectively.
Integrate the risk register. One register, jointly maintained. People risk and technical risk in the same view, with shared escalation paths.
Share status reporting. One dashboard: delivery progress and adoption readiness. One source of truth for leadership, instead of two separate updates that sometimes contradict each other.
Plan reinforcement, not just launch. Reinforcement planning starts during Execute, not after Close. Name the owner. Budget for it. Calendar it. Before the team disbands.
The Goal Is Not to Make PM and CM Work Together
That’s worth saying plainly, because it reframes why integration matters.
The goal is not improved collaboration. The goal is not organizational harmony. The goal is not even better project outcomes in the traditional sense.
The goal is to make the change succeed; to close the gap between the system that went live and the value the organization was promised when the business case was approved.
When project management and change management operate as integrated disciplines rather than parallel tracks, that gap closes. Not always easily. Not without deliberate design. But reliably.
That’s the work worth doing.






Comments