How Do I Keep Every Team Working from the Same Plan?
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.
Why doesn't coordination happen on its own?
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.
Why are teams working from different plans?
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?"
Why does "launch" mean something different to each team?
"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 does a single source of truth actually require?
Effective coordination isn't about more meetings.
You need:
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
Why do coordination problems surface too late?
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.
Who owns alignment on a project?
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.
References & Related Reading:
1) Heath and Staudenmayer, "Coordination Neglect" (Research in Organizational Behavior, 2000): https://www.semanticscholar.org/paper/Coordination-Neglect%3A-How-Lay-Theories-of-in-Heath-Staudenmayer/4dfc056865608ce0be809c42a1d2bb6988e9e3ee
2) Szulanski, "Exploring Internal Stickiness" (Strategic Management Journal, 1996): https://sms.onlinelibrary.wiley.com/doi/10.1002/smj.4250171105
If you're running a rollout and want a plan for each stage, The DANCE System gives you 29 tools across five phases, from defining the change to keeping it in place after launch.
Related Blog Posts:
Why do organizations repeat the same rollout mistakes?
Why does good strategy still rollout badly?
How do I get three teams to cooperate when none report to me?
