By Step 8, the consulting team is planning execution, and the energy in the room shifts because the work feels tangible. The risk is that this energy produces overconfidence: a rollout plan that assumes everything will go as designed. The principle that governs Step 8 corrects for this: each wave earns the right to launch the next one.
Phased Rollouts Succeed When Each Wave Earns the Next
A phased rollout divides execution into waves based on geography, business unit, product line, or some combination. In a standard rollout plan, these waves are sequenced on a calendar: Wave 1 in Q1, Wave 2 in Q2, Wave 3 in Q3. The dates are set during planning, and the implicit assumption is that each wave will proceed on schedule. If Wave 1 has problems, the typical response is to fix the problems while Wave 2 launches on its planned date. The organization scales execution and troubleshooting simultaneously.
The earn-the-next-wave approach works differently. Wave 1 has explicit success criteria that must be met before Wave 2 begins. These criteria are defined during Step 8, before execution starts, and they’re measurable. A client migrating to a unified data platform might require:
- Platform uptime above 98% at sixty days with user adoption above a defined threshold
- Data validation error rates below 2%
If Wave 1 doesn’t meet the criteria, Wave 2 does not start. The team addresses the gap, adjusts, and demonstrates that the approach works before scaling.
The plan should also maintain a gradient of specificity. Wave 1 gets detailed planning: specific sites, dates, resources, and success criteria. Wave 2 gets milestone-level planning: key gates, approximate timing, and resource requirements by role. Wave 3 gets directional planning: scope, sequencing logic, and the conditions that must be true before detailed planning begins. This gradient acknowledges that the team’s knowledge decreases with each successive wave; the plan should get smarter over time rather than predict the future with false confidence.
Explicit Gates Protect the Program’s Credibility
The resistance to this approach is predictable. Executive sponsors have committed to timelines, and board decks show deployment milestones by quarter with budgets allocated against a schedule. The suggestion that Wave 2 might not start on its planned date can feel like a threat to the program’s credibility.
This concern is understandable, but the greater risk is scaling a deployment that isn’t working. A client that deploys to fifty business units when the five-unit pilot has unresolved integration issues creates fifty instances of the same problem. The cost of fixing those issues at scale (i.e., operational disruption, analyst bandwidth, business unit frustration, and reporting impact) is higher than the cost of delaying Wave 2 by four weeks.
The earn-the-next-wave approach protects the program by making the gate explicit. The criteria are defined during planning when the team is thinking clearly. They’re agreed to by the executive sponsor and the steering committee before execution begins. When the gate is reached, the decision is grounded in data rather than optimism or political pressure.
A Learning Agenda Turns Wave 1 Into a Foundation for What Follows
Wave 1 will teach the team things they don’t know yet, and those lessons should change how subsequent waves are executed. A learning agenda makes this uncertainty explicit by listing the questions the team expects Wave 1 to answer:
- How long does installation actually take versus the planned estimate?
- Which configurations create complications the architecture didn’t anticipate?
- What does support volume look like during the first thirty days?
- How do end users respond to the new workflows?
These questions are formulated during planning because the team already knows they lack the answers. After Wave 1, the team reviews the agenda, documents what was learned, and uses those findings to adjust Wave 2. A rollout plan that does not change after Wave 1 has not learned anything.
Mapping Dependencies and Support Capacity Prevents Cascading Failures
Step 8 also maps the dependencies between waves and the support requirements for each one. Wave dependencies include shared resources, infrastructure prerequisites, and organizational capacity constraints that limit how many waves can run concurrently.
A common failure in rollout planning is underestimating the support burden of concurrent waves. If Wave 1 support issues are still consuming the help desk when Wave 2 launches, Wave 2’s support capacity is compromised from day one. We address this by treating support capacity as a rollout constraint, not an afterthought. During Step 8, the team maps expected support volume for each wave and validates that the support structure can handle the load. If it can’t handle Waves 2 and 3 running concurrently, the sequence adjusts.
The rigor of change management planning and planning for people not in the room shapes how each wave accounts for adoption, while the pre-mortem anticipates the risks that wave gates are built to catch. The collaborative energy of building together in the roadmap sessions is what gives the team confidence to hold the line when a gate says “not yet.”
