Rolling wave planning: an example on a Gantt chart

How does the chart work?

A rolling wave Gantt chart has two levels of detail. Near-term tasks have owners, durations and dependencies; later phases each have one estimated bar. A planning milestone marks the date when the next wave gets its detailed tasks. If you have not split a plan into phases before, start with phases and their gates.

The long bars have a name in formal project management. PMI's PMBOK Guide describes rolling wave planning as a way of breaking down work over time, and earned value guidance, including the US Government Accountability Office's schedule assessment guide, calls the placeholder for not-yet-detailed work a planning package. The practical point is to distinguish known tasks from estimates. A fully detailed 12-month plan can make uncertain work look settled.

Each placeholder still needs an estimated duration, a dependency on preceding work and a clear name. These bars determine the end date, so vague or unrealistic estimates make that date unreliable.

Month 1: detail the selection

In month 1, only the first wave is planned in detail: eight weeks to choose the CRM. The ops lead lists requirements and shortlists three vendors, sales managers sit through demos while IT reviews security and data handling, five reps trial the front-runner for two weeks, and finance negotiates the contract. The wave ends with a milestone, "CRM chosen", at the end of week 8.

The other three phases are a single bar each. The pilot with one sales team is 12 weeks, the rollout to every team is 16, and the service team and close-out phase is the last 16. Each of those bars is named for when its detail will be planned, and three planning milestones sit on the chart: week 7 for the pilot, week 18 for the rollout and week 34 for service and close-out.

Sample data: the CRM rollout as planned in month 1, in working days with weekends hidden.

Why stop the detail at week 8? Because nobody can list the pilot's tasks before they know which CRM they are piloting. The setup work for one product is not the setup work for another, and the data import depends on what the new system accepts. Anything written down for those weeks in January would be rewritten in March.

The planning milestone for the pilot sits in week 7, before the contract is signed. By then the choice is effectively made, and planning the pilot while finance finishes the paperwork means the first pilot task can start the Monday after the decision instead of two weeks later.

Month 4: revise the outline

By month 4 the CRM has been chosen, its phase is collapsed to a single row, and the pilot is now six tasks: set up the pipeline stages and fields, import the north team's accounts, train the team, work live deals in the new system for six weeks, collect feedback and fix the setup, and a pilot review at the end of week 20.

Sample data: the same plan in month 4, with the finished phase collapsed.

The rollout estimate also changes. Importing the north team's accounts took the full week planned for it, and the south and west teams hold roughly three times as many. That is new information about the rollout, not the pilot, and it lands on the rollout's placeholder bar straight away: 16 weeks becomes 18, and the planning milestone for the last phase moves from week 34 to week 36.

That leaves less time for the last phase. The close date in week 52 has not moved, so service and close-out shrinks from 16 weeks to 14. That is a decision, not an accident of the chart. Someone has to say whether 14 weeks is enough, or whether the honest move is to tell the sponsor the end date is now at risk. A rolling wave plan that only updates the next wave would have hidden this until month 8.

Review later estimates as soon as current work gives you better information. Placeholder bars are provisional estimates, not dates to leave untouched until their wave begins.

Month 8: detail the rollout

In month 8 the first two phases are collapsed and the rollout has been in detail since its planning milestone in week 18. It runs three weeks of account imports for the south and west teams, a week of training for each team, three weeks to build a weekly pipeline report, a milestone in week 30 when the old pipeline spreadsheet is retired, and a weekly adoption check that runs to week 38.

Sample data: the same plan in month 8.

The three-week import confirms the estimate made in month 4, which is the method working as intended: the outline was corrected early, so the detailed plan arrived without a surprise. One placeholder remains, and its planning milestone in week 36 is a few weeks away. By then the team will know how adoption is going, which decides how much of the service team's setup can reuse the sales configuration.

Across the three charts, each wave's detail comes from people who have just completed the preceding wave, rather than a task list guessed in January.

When should you plan ahead?

Plan the next wave a few weeks before it starts, using a milestone already on the chart. The detail horizon in most small and medium projects is six to eight weeks: far enough ahead to line up people and suppliers, near enough that the tasks are real. Put the planning milestone two to four weeks before the wave begins, so that suppliers with lead times can still be booked.

A few signals say you are planning too late or too early:

• Too late: the first week of a new wave is spent working out what the wave is, or a supplier needed in week 2 of it has a four-week lead time.
• Too early: the detailed tasks get rewritten before they start, because something in the current wave changed them.
• About right: the people who will do the next wave can describe their first two weeks of tasks, and nobody expects the list to change much.

The wave length does not have to be equal across a project. A short, uncertain phase may need re-planning every month. A long, well-understood one can be detailed in one sitting. When you do the detailed planning, the same rules apply as for any other estimate, and the page on estimating task durations covers where the numbers should come from.

What can you promise clients?

Promise the current wave's dates firmly, the end date as a target with the assumptions it rests on, and the date by which the next wave will be planned. The next planning date tells the client when to expect a more detailed schedule.

In the CRM example, a month 1 update to the sponsor might read: the CRM will be chosen by the end of February; the pilot starts the following Monday and will be planned in detail by mid-February; the target for full rollout is mid-September, assuming the pilot shows no major data issues; the project closes by the end of the year. This update states dates and assumptions without inventing the rollout's weekly tasks.

Avoid filling later phases with speculative tasks. Clients can read changes to those tasks as delays, even when you are refining an estimate. Showing placeholders as placeholders, labelled with the week their detail arrives, avoids that conversation entirely. If the client gets the chart itself, choosing client-facing detail has more on what to leave out.

How does progressive elaboration differ?

Progressive elaboration is the broader idea: a plan becomes more detailed and more accurate as the project produces information. Rolling wave planning is one specific, scheduled way of doing it. Progressive elaboration says the plan will improve. Rolling wave says when, and which part.

In practice the difference is the planning milestones. A team that "elaborates progressively" without them tends to add detail whenever someone asks for it, which is usually too late. A rolling wave plan puts the moments of elaboration on the chart, so they get done.

Rolling wave planning vs agile

Rolling wave planning and agile both defer uncertain detail, but they organise planning differently. A rolling wave plan keeps one end-to-end schedule with a target end date and adds detail to a fixed sequence of phases. Agile methods usually fix the length of each iteration and let the scope of later iterations change based on what was learned.

That makes rolling wave planning a natural fit for projects with a committed outcome and a real sequence, such as a system rollout, an office move or a research project, where you know the phases but not their contents. It sits comfortably next to agile delivery, too: a team can run two-week sprints inside the current wave while the chart above them shows the phases and the dates the business cares about. The page on planning releases alongside sprints shows that combination at release level.

Rolling wave planning questions

How long should each wave be?

Long enough to line up people and suppliers, short enough that the tasks are real: six to eight weeks suits most small and medium projects. Waves do not need to be equal. Uncertain phases can be re-planned monthly, and stable ones detailed in one go.

Is rolling wave planning only for long projects?

Mostly, yes. On a project of eight weeks or less, everything is already inside the detail horizon, so you can plan it all at the start. The method starts to pay off once the later phases depend on decisions or results that do not exist yet.

Do the placeholder bars need dependencies?

Yes. Link each placeholder to the phase before it, so that a slip in the current wave moves the later bars and the end date. A placeholder floating free on the chart gives a false sense that later work is unaffected.

How should you start?

List your phases and give each one an honest single bar. Break only the first six to eight weeks into tasks, put a planning milestone a few weeks before each later phase, and link everything so the end date moves when the near term does. Then revise the outline every time the current wave teaches you something, not only when the next wave comes up. If your plan is turning into a wall of tiny tasks, the common scheduling mistakes include over-detail and how to fold it back.