When Your Change Team Doesn't Know What's Launching Next Week
The implementation team is building the new process. The training team is developing materials. The communication team is drafting announcements.
They're all working from different timelines, different scope definitions, and different assumptions about what "done" means.
Nobody discovers this until five days before launch.
The Coordination Assumption
Most change initiatives assume coordination is happening.
Someone is tracking dependencies. Someone is managing handoffs. Someone is making sure training content matches what's actually being implemented.
That assumption holds until you ask: "Who specifically is doing that?"
The answer is usually "I thought you were" or "isn't that project management's job?" or silence.
Coordination doesn't happen automatically. It requires explicit role assignment, regular checkpoints, and authority to surface conflicts.
Without that structure, teams work in parallel until they collide.
The Version Control Problem
Implementation teams iterate. They make decisions, reverse decisions, adjust scope, change timelines.
Most of those changes never get communicated to downstream teams.
Training develops materials based on the requirements from six weeks ago. Communications writes announcements based on the timeline from last month. Nobody realizes the versions don't match until someone asks "wait, are we still doing the automated approval piece?"
The problem isn't that changes happen. The problem is that there's no system for propagating them.
The Definition Gap
"Launch" means different things to different teams.
To implementation: core functionality is working in production To training: materials are published and available To communications: announcement has been sent To support: help desk is staffed and ready To users: they can actually do their work in the new way
These definitions overlap but they're not identical.
When teams aren't explicit about which definition they're using, "we're ready to launch" becomes meaningless.
What Systematic Coordination Requires
Effective coordination isn't about more meetings.
It's about:
Clear decision rights (who can change what, and who needs to know)
Version control for scope, timeline, and requirements
Explicit handoff points where teams confirm alignment
A single source of truth that all teams work from
This requires infrastructure, not just good intentions.
The Discovery Timeline
Most coordination problems get discovered too late to fix properly.
They get discovered when:
Training asks "what do we do if the system does X" and implementation says "it doesn't do X anymore"
Communications publishes a date that implementation knows is impossible
Users start asking questions nobody prepared answers for
By that point, you're managing crisis, not executing a plan.
The teams that handle change well discover misalignment early because they've built explicit checkpoints designed to surface it.
The Ownership Question
If coordination isn't someone's explicit job, it becomes everyone's assumed responsibility and no one's actual priority.
Before your next launch, answer: "Who owns making sure all teams are working from the same version of the truth?"
If that role doesn't exist, create it.
If it exists but lacks authority to pause work until alignment is restored, fix that.
Coordination isn't overhead. It's the thing that prevents launches from becoming disasters.
The DANCE System includes coordination structures that surface misalignment early and maintain version control across change teams. Learn more about systematic change communication
