The rollout plan had three waves, eight weeks apart, sequenced by complexity. In practice, the team treated Wave 1 as the first batch of deployment rather than as a learning exercise: they launched, hit issues, then moved on to Wave 2 on schedule without resolving them. The same issues appeared in Wave 2, and by Wave 3 the cumulative weight of unresolved problems nearly stalled the program. The principle that every wave earns the next only works if the team actually pauses to learn.
Wave 1 Reveals What Planning Cannot Fully Anticipate
Wave 1 revealed two categories of issues the planning sessions hadn’t fully anticipated:
- Training gaps. The training materials covered the new system’s functionality but not how the system changed daily workflow. Frontline teams understood the software; they didn’t understand how their morning count process, exception handling, and end-of-day reconciliation were supposed to change.
- Process workarounds and system edge cases. Within two weeks, site managers had created informal workarounds for situations the new process didn’t cover: some legitimate adaptations, others shortcuts that undermined data integrity. Standard transactions worked well, but exceptions (i.e., returns without receipts, cross-location transfers, manual overrides for unloaded promotions) produced errors or required steps the training hadn’t covered.
Schedule Pressure Compounds Unresolved Issues Across Waves
The program team documented the Wave 1 issues, logged them in the issue tracker, assigned owners, and launched Wave 2 on the original schedule. The pressure came from two directions: the executive sponsor had committed to a completion date tied to a board-level milestone, and delaying Wave 2 would have required communicating a slip. The program also had a deployment team staffed and scheduled for Wave 2, and pausing would have left a cross-functional team idle. Both pressures are common, and both create the same outcome: the rollout proceeds with unresolved issues that compound. When change management is treated as an afterthought, the training and communication gaps from Wave 1 never get addressed before Wave 2.
Wave 2 experienced the same training gaps, workarounds, and edge cases as Wave 1, plus new issues specific to the mid-tier locations. The support team, sized for steady-state, was handling incident volume from two waves of unresolved issues, and workarounds from Wave 1 had spread informally through peer networks. By Wave 3, the program was carrying the accumulated weight of two waves of unresolved problems. The deployment and support teams were both stretched past capacity, and the site managers in Wave 3, who had heard from their peers, arrived with low confidence. Designing for failure before execution starts is what prevents this cascade; a pre-mortem would have named the risk of compounding wave issues before the first deployment.
Learning Gates Give Each Wave a Structured Checkpoint
The structural fix is straightforward. Wave 1 is designated as the learning wave with explicit success criteria beyond “systems are deployed and running”:
- Training effectiveness measured by observed behavior, not completion rates
- Workaround and edge case cataloguing with a review of which adaptations to incorporate and defined responses for exception scenarios
Between Wave 1 and Wave 2, there’s a gate. If the success criteria aren’t met, Wave 2 does not start. The gate is a structural hold that requires a documented decision to proceed: the program leadership reviews Wave 1 findings, approves adjustments to training and process, and then authorizes Wave 2.
The learning agenda artifact, built during rollout planning in Step 8, embeds this structure into the plan. It lists the specific questions Wave 1 is designed to answer and assumes that Wave 1 will teach the team things that change how subsequent waves are executed.
This approach requires the executive sponsor to accept that the rollout timeline includes built-in flexibility. Committing to a fixed end date before Wave 1 has produced any learning is a commitment to ignore whatever Wave 1 teaches. The sponsor needs to communicate a different kind of commitment: the program will deploy in waves where each wave informs the next, and the timeline will be updated based on what the organization learns. Programs that failed with good plans almost always share this pattern: the plan was sound, but the execution ignored what the early waves were teaching.
