The Waves Are Sequenced. The Transitions Aren’t.
The program has a wave structure. The pilot goes first, then Wave 1, then Wave 2. The sequence is documented. The timing is on the schedule. The team knows which audiences are in which wave. What the team hasn’t documented is what has to be true before one wave ends and the next begins. There is no explicit gating logic. There is no dependency map. There is no decision protocol for when a wave doesn’t meet expectations. The transitions between waves are managed by calendar, not by evidence. This is the gap that wave dependency mapping closes. The sequence tells the team who deploys when. The dependencies tell the team what must be verified before the team expands.
Why Transitions Are Where Rollouts Break
The work within a wave is usually well-managed. The team has a plan for deploying to this audience, supporting them during the transition, and tracking progress. The breakdowns happen between waves, in the transitions where the team decides whether to proceed. Two forces conspire to make transitions dangerous: Momentum pressure. The program has been running. The organization is watching. Pausing between waves feels like stalling. The team faces pressure to maintain pace even when the evidence doesn’t support expansion. Data and escalation gaps. The success criteria from the previous wave may not be fully measured yet. The data exists in various systems but hasn’t been consolidated into a decision framework. And if the previous wave didn’t meet criteria, who makes the call? Without a pre-designed escalation path, the team improvises under pressure: which typically means proceeding without addressing the root cause.
What a Wave Dependency Map Contains
A dependency map captures five elements for each transition: The dependency. What must be true before the next wave can begin. This can be an evidence condition (“Wave 1 success criteria met”), a resource condition (“Training materials updated based on Wave 1 feedback”), or a readiness condition (“Wave 2 audience has completed pre-deployment preparation”). The source wave. Which wave produces this condition. Not every dependency comes from the immediately preceding wave. Some dependencies come from the pilot that need to persist through all subsequent waves. The target wave. Which wave requires this condition. Some dependencies gate a single wave. Others gate all remaining waves. The verification method. How the team confirms the dependency is met. Data review, sign-off, checkpoint meeting, system check. The verification should be specific enough that it can happen quickly and produce a clear yes/no answer. The escalation path. What happens if the dependency isn’t met. This is the most critical field and the one most often missing. The escalation path should specify who makes the decision, what options are available (delay, proceed with modifications, scale back, pause), and what criteria guide the choice.
The Speed Trap: When Compression Eliminates Learning
The most common wave dependency failure is compressing the time between waves so tightly that there’s no space for evaluation. The program timeline shows full deployment by a fixed date. Working backward from that date, the team calculates wave durations and discovers that there’s no room for analysis between waves. Wave 2 has to start within days of Wave 1 ending. The team tells itself that it will analyze Wave 1 data while Wave 2 is running. This is a phased rollout in name only. If Wave 2 starts before Wave 1 data is analyzed, the team has no basis for adjusting the plan. Problems discovered in Wave 1 replicate in Wave 2 because the learning loop never closed. The team is managing two waves of problems simultaneously with support resources planned for one. The dependency map prevents this by making the analysis window explicit. The transition from Wave 1 to Wave 2 includes a dependency: “Wave 1 success criteria reviewed and learning agenda items addressed.” If the timeline can’t accommodate that dependency, the team has a conversation about timeline feasibility before deployment starts, not during it.
The Escalation Decision Tree
The most valuable part of a wave dependency map is what happens when dependencies aren’t met. This should be designed in advance, not improvised under pressure. A useful escalation path has three branches: Proceed as planned. The dependency is met. Move to the next wave. This is the default path and should require the least decision-making overhead. The wave gate requirements define the specific conditions that must be satisfied. Proceed with modifications. The dependency is partially met. The team can address the gap with specific adjustments to the next wave: additional support, modified training, adjusted timeline for a subset of audiences. This path requires someone to specify the modifications and confirm they address the root cause, not just the symptom. Pause or delay. The dependency is not met and cannot be resolved with modifications. The next wave does not start until the gap is closed. This is the hardest decision because it directly affects the timeline, the budget, and the organizational narrative. But it’s a better outcome than discovering at scale that the team should have paused earlier. The decision owner for each escalation should be named in advance. If the decision owner is the same person who’s accountable for the timeline, the incentive structure favors proceeding. Consider separating the go/no-go authority from the timeline accountability to create genuine decision quality.
Types of Dependencies Most Programs Miss
Beyond the obvious evidence dependencies (success criteria met), rollout plans should capture: Resource dependencies. Are support resources actually available for the next wave? Not planned. Available. Confirmed. If the same trainers who supported Wave 1 are supposed to support Wave 2, are they free, or are they still addressing Wave 1 issues? Readiness dependencies. Has the next wave’s audience completed pre-deployment preparation? The change plan specifies communication and training sequences. If those haven’t been delivered, the audience isn’t ready regardless of whether the previous wave succeeded. Learning dependencies. Have the questions from the learning agenda been answered? If the pilot was supposed to test whether users could complete the new workflow independently, was that hypothesis validated? If not, what changes before the next wave? Infrastructure dependencies. Are the technical prerequisites for the next wave in place? System configurations, data migrations, access provisioning, integration testing. These are often managed on a separate track and assumed to be on schedule. The question is whether the team maps every dependency and designs the escalation path before deployment starts: or whether it discovers at the wave transition that nobody defined what would trigger a pause.
Keep Reading
New to the Rollout Plan? Start with the foundations:
Ready to benchmark your work against best-in-class? See what excellence looks like: