Rolling Wave Planning

Schedule technique · See it on the map

Guide only — A printable worksheet is written for it; there is no figure for a launcher to compute.

Planning near-term work in detail and far-off work only roughly, refining it as it gets closer.

When to use it

Use it whenever the far end of the schedule genuinely cannot be broken down yet — the requirements aren't settled, a vendor hasn't been chosen, or an earlier phase's output will determine what the later phase even contains. It is the honest alternative to guessing detail you don't have.

When to avoid it

Don't reach for it as an excuse to skip planning work you actually know how to detail today — that just relabels procrastination as a technique. And don't use it past the point the far-out work has become knowable: a wave that's two weeks away and still a single placeholder line is a planning gap, not rolling wave.

Steps

1. Split the schedule horizon into a near wave (detailed, task-level) and one or more far waves (summary-level placeholders with a rough duration and owner).
2. Decompose and estimate the near wave to the level of detail the team will actually execute against.
3. Set a trigger for each far wave — a date, a milestone, or a decision point — at which it becomes the new near wave and gets decomposed in turn.
4. When a wave's trigger fires, re-plan it in detail using whatever estimating technique fits the information now available, and update the plan.

What it produces

• A schedule with mixed granularity: detailed near-term tasks, summary-level future placeholders, and stated triggers for when each placeholder gets detailed.

Common pitfalls

• The far-wave placeholder gets treated as a real commitment by anyone who doesn't know it's provisional — a stakeholder reads a one-line summary task as a firm date.
• The trigger never fires because nobody owns watching for it, so a wave stays undetailed well past the point it should have been broken down.
• Re-planning a wave quietly changes scope as well as detail, and the change never goes through change control because it's framed as "just detailing what was already there".

Worked example

A clinic intake system project details the first six-week sprint task by task, and represents "Phase 2: reporting module" as one summary bar pending the vendor's data export API being finalized. When the vendor confirms the API spec in week five, the team decomposes Phase 2 into real tasks before the current wave ends.

Source

• PMBOK-6 §6.2.2.3

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.