Restart Wave Plan¶
Workflow — instantiates Coordination and Synchronization Across Reentry Phases
A staged workflow that groups units into ordered reentry waves, sequenced by dependency and spaced with slack, so return happens in absorbable increments instead of all at once.
A Restart Wave Plan is the master schedule for a coordinated return: it takes a pile of units that all want to come back and turns them into an ordered sequence of waves, each wave a cohort released into a named phase, with the order fixed by who depends on whom and each wave spaced from the next by deliberate slack. Its defining move is that the whole sequence is laid out in advance, as a forward plan — it decides who goes in wave one, what has to be stable before wave two starts, and how much breathing room sits between them, before the first unit moves. It is not a probe that tests whether to proceed, and it is not a room full of people deciding in the moment; it is the written choreography that those other mechanisms then execute and adjust against.
Example¶
A national grocery distributor is restarting operations after a three-week regional flood shuttered a distribution hub, two hundred stores, and the carrier network that links them. Flipping everything back on at once would bury the reopened hub under three weeks of backlog on day one. The Restart Wave Plan instead lays out the return as ordered waves. Wave one is the distribution hub itself plus its refrigeration and inbound receiving — nothing downstream can restock until the hub can hold inventory, so the dependency inventory puts it first. Wave two is the carrier fleet and the twenty highest-volume stores nearest the hub. Wave three widens to the next fifty stores; wave four, the long tail. Between wave one and wave two the plan holds a five-day buffer so inbound inventory can rebuild a cushion before demand is switched back on, and each store cohort is capped so no single wave exceeds what the reopened hub can pick and ship in a day. The output is a dated wave chart with entry phases and slack windows — the thing every other team schedules against.
How it works¶
- Name the phases first. The plan works against a shared reentry phase map — closed → receiving-only → limited-fulfillment → normal — so "wave two is live" means the same thing to every unit.
- Order by dependency, not eagerness. The restart sequence follows the coupling inventory: a unit cannot be scheduled ahead of the upstream it draws on or the shared resource it would starve.
- Group into cohorts sized to absorb. Units are batched into waves small enough that the reactivated load lands in increments the system can take, rather than a single surge.
- Space the waves with slack. Explicit buffer windows sit between waves so a wobble in one does not immediately propagate into the next — the plan trades a little speed for absorption room.
Tuning parameters¶
- Wave size — how many units enter per wave. Larger waves restore faster but concentrate load and risk; smaller waves are gentler but stretch the return out.
- Inter-wave slack — how much buffer time sits between waves. Generous slack absorbs surprises but prolongs disruption; tight slack recovers speed at the cost of propagation room.
- Phase granularity — how many intermediate states the map defines. Fine granularity gives precise control and more decision points; coarse granularity is simpler but blunter.
- Sequencing priority — when dependency order and fairness order conflict, which wins. Strict dependency ordering is safest; weighting fairness or revenue can override the technically cleanest sequence.
- Re-planning cadence — whether the wave chart is fixed or re-cut as reality diverges. Frequent re-cuts stay realistic but cost stability in what everyone is scheduling against.
When it helps, and when it misleads¶
Its strength is that it converts an anxious scramble into an absorbable sequence: load arrives in increments, dependencies are honored by construction, and every team can see which wave it is in and what has to be true before the next one starts. The buffers between waves are what keep one unit's stumble from cascading into the whole return.
Its characteristic failure is a plan that ossifies. A wave chart drawn on week-one assumptions keeps being executed as though those assumptions still hold, and slack that looked generous gets quietly eaten to "make up time," so the absorption room the plan was built to provide evaporates exactly when it is needed. This is the planner's version of rolling-wave planning done badly — committing distant waves in false detail instead of re-cutting them as evidence lands.[1] A wave plan is also silent on whether any single wave is actually going well; it schedules the increments but does not test them, so momentum can carry the sequence forward past trouble it never checks for. The discipline is to keep the near waves detailed and the far waves provisional, to protect the inter-wave slack from being spent as a schedule reserve, and to let the units' own readiness evidence — not the calendar on the chart — decide when a wave actually starts.
How it implements the components¶
reentry_phase_map— the plan is drawn against a shared set of named phases and allowed transitions, so every wave enters a defined state rather than a vague "reopening."cohort_or_wave_plan— its core artifact: the grouping of units into ordered, sized waves with entry phases and timing windows.dependency_and_coupling_inventory— the sequence is derived from the map of which units, interfaces, and shared resources depend on one another; the plan uses that inventory to forbid an out-of-order restart.buffer_and_slack_reserve— the deliberate slack windows placed between waves to absorb rate mismatches and keep a stumble in one wave from spilling into the next.
It lays out the forward sequence but does not run the live probe that proves a cohort is safe to expand (interoperability_test_point, rollback_or_resuspension_trigger — that is the Canary Reentry Trial), nor does it render the live state of the return (status_observability_panel — that is the Shared Restart Dashboard).
Related¶
- Instantiates: Coordination and Synchronization Across Reentry Phases — the Restart Wave Plan is the staged forward schedule the whole coordinated return is executed against.
- Consumes: Shared Restart Dashboard — the plan sizes its waves against the capacity and bottleneck picture the dashboard renders.
- Sibling mechanisms: Canary Reentry Trial · Incident Command or Reentry Cell · Reentry Readiness Checklist · Shared Restart Dashboard · After-Action Reentry Review · Phase-Gate Review · Rollback or Pause Protocol
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Restart Wave Plan operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it a staged workflow that groups units into ordered reentry waves, sequenced by dependency and spaced with slack, so return happens in absorbable increments instead of all at once.
Independent corroboration: The frozen evidence defines Restart Wave Plan as 'A staged workflow that groups units into ordered reentry waves, sequenced by dependency and spaced with slack, so return happens in absorbable increments instead of all at once', so its operative form is Representation, Specification & Plan.
Nearest alternative: Protocol, Workflow & Routine — Restart Wave Plan includes features of a repeatable ordered procedure or handoff sequence that coordinates action, but its defining operation is a static representation, map, specification, schema, or prospective plan that externalizes information.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Disaster Management & Risk Reduction
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Phased reentry after disruption is characteristic of disaster recovery and continuity planning.
Related originating lineages:
- Logistics & Supply Chain Management — Flow planning contributes spacing and capacity slack between waves.
- Organizational & Management Science — Change and operations management materially shape dependency-aware sequencing.
Review resolution: Both blind reviewers agree that disaster_management is the primary historical origin. Explicit reconciliation of alternate origin disagreement, origin mode disagreement adopts reviewer_a's evidence: Phased reentry after disruption is characteristic of disaster recovery and continuity planning. The selected record uses alternates=logistics_supply_chain, organizational_management, origin_mode=cross_disciplinary_synthesis, and domain_reach=multi_domain; the other review proposed alternates=logistics_supply_chain, military_strategic_studies, organizational_management, public_administration_policy, origin_mode=convergent, and domain_reach=multi_domain. The selected combination better preserves the mechanism-specific formative lineages and calibrated scope; broader present-day use is not treated as proof of additional historical origin.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The wave plan is a sequence, not a gate: it says what order units return in and how much room sits between them, but the decision to actually release each wave belongs to the readiness gates and the coordinating body. A team that treats "wave three is scheduled for Tuesday" as permission to advance has confused the choreography with the go-ahead — the plan proposes the ordering; readiness evidence disposes.
References¶
[1] Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide). 6th ed. (2017). Defines rolling-wave planning as detailing near-term work while deferring and progressively refining distant work as evidence becomes available. registry ↩