h t t p s : / / w e b . a r c h i v e . o r g / w e b / 2 0 2 5 0 7 1 0 1 1 3 9 5 7 / h t t p s : / / w w w . p m i . o r g / l e a r n i n g / l i b r a r y / m a n a g e - i n n o v a t i o n - p r o g r a m s - r o l l i n g - w a v e - 3 5 1 5

Ingest: Manage Innovation Programs With a Rolling Wave

Type: kb/sources/types/ingest-report.md

Classification

This is a practitioner report: it prescribes a six-step planning method, explains the method through first-person experience and named practitioner examples, and provides no controlled comparison. The retained observation is the Internet Archive's 2025-07-10 Wayback capture of PMI's official article page; PMI's canonical current record is cited separately from that archived observation. Internet Archive is the capture host, not the publisher: Gregory D. Githens is the named author, and PMI published the article in PM Network 15(5) in May 2001. Githens writes from his evaluation of new-product-development organizations and reports observations from several practitioners, but the article does not disclose a study design or comparative outcome data.

Summary

Githens's source method is rolling-wave program management for uncertain development: establish a top-down program architecture, WBS, and planning horizons; elaborate the near horizon bottom-up into work packages and a Gantt plan; secure a baseline through approvals and change control; then execute and replan at phase transitions. The shared mechanism that transfers to Commonplace is narrower: defer future detail until a planned relearning point supplies information that the earlier planner did not have. The consequence for agent-operated knowledge work is to preserve purpose, mark unresolved future structure honestly, and schedule the next information-informed planning decision—not to import PMI-specific gates, WBS/Gantt elaboration, baselines, change-control procedure, or approval bureaucracy. The method's own stopping boundary is uncertain, design-heavy development; Githens warns that it can slow comparatively linear deployment, and the report does not establish superiority over alternative adaptive methods.

Quotes

  • Source extract (verbatim): In this step, the team details out individual work packages for the first horizon, “bottom up.” (This includes estimating task durations, resources, and cost.)
  • Source location: “Process of Rolling Wave,” Step 3: Perform the First Planning Iteration, Starting Bottom-Up
  • Source extract (verbatim): Include any identifiable work in the later time buckets, using what I call a “black box” placeholder to indicate that you expect to define certain work later.
  • Source location: “Process of Rolling Wave,” Step 3, later-horizons bullet
  • Source extract (verbatim): ■ Establish a work package and fixed date for replanning for the next time horizon. The deliverable of the replanning work package is an updated rolling wave plan.
  • Source location: “Process of Rolling Wave,” Step 3, replanning bullet
  • Source extract (verbatim): Step 5: Execute the Planned Work in the First Time Bucket. Inside the time buckets, work is straightforward: plan your work, and work your plan. For rolling wave it is particularly important to have a learning orientation. Capture learning for feed-forwarding to anticipate and avoid future problems, or to quickly react to the risks that the team decides to accept.
  • Source location: “Process of Rolling Wave,” Step 5: Execute the Planned Work in the First Time Bucket
  • Source extract (verbatim): ■ Assess the team's learning, the needed work, and replan the next horizon of the program (go back to Step 3).
  • Source location: “Process of Rolling Wave,” Step 6: Iterate Through the Planning Horizons and Close the Project

Connections Found

The source's settled role is a bounded practitioner anchor for An author should fix what the executor can't determine, not what it will. The supporting connection is the shared information-timing mechanism—later detail is deliberately deferred until scheduled execution and relearning supply its premises—not Githens's surrounding system of phase gates, WBS/Gantt elaboration, baselines, change control, and approvals. Commonplace can use the former to decide when an agent should commit detail without adopting the latter as a workflow prescription. The article's explicit development-versus-deployment limit is also a worked comparison for Abstract an experience into a lesson only when you can state where the lesson stops. Its broad uncertainty category should be narrowed through Changing requirements conflate genuine change with disambiguation failure, while its repeated plan-do cadence contrasts with the explicit prediction-and-study mechanism in Foundation and History of the PDSA Cycle.

Extractable Value

  1. Match planning precision to information availability -- The source gives a concrete instance of the existing executor-boundary claim: preserve purpose and near-horizon commitments while deferring choices whose premises execution will reveal. This information-timing rule transfers without the source's project-control machinery. [quick-win]
  2. Schedule a relearning decision -- Naming when new evidence will be assessed turns deferred detail into an explicit future decision rather than indefinite vagueness; an agent workflow can use that commitment without creating a formal phase gate or approval cycle. [quick-win]
  3. Represent unresolved later work without pretending it is known -- Githens's black-box WBS entries instantiate a more general pattern: keep a visible placeholder for future work while withholding invented detail. The placeholder principle is experimentable in multi-stage knowledge work; the WBS notation is context-bound. [experiment]
  4. State the method's stopping boundary in terms of work structure -- The development/deployment distinction ties rolling wave's value to design uncertainty and warns that the same overhead can harm relatively linear execution, making the report a reusable example of bounded transfer. [quick-win]
  5. Keep iterative planning distinct from experimental learning -- Comparing the report with PDSA prevents a shared plan-do rhythm from erasing the difference between progressive elaboration and testing explicit predictions against observations. [just-a-reference]

Limitations (our opinion)

The report is a persuasive account assembled from the author's experience and selected practitioner testimony, not a test of rolling wave against plausible alternatives. It does not expose failed adoptions, sample selection, team conditions, or outcome measures, so it cannot establish that rolling wave caused faster or more creative results. A simpler explanation is that explicit relearning dates and disciplined attention to uncertainty produce much of the benefit. The article does not show that phase-transition gates, WBS/Gantt elaboration, baselines, change-control regimes, or multi-party approvals are necessary for that mechanism; importing those PMI-specific prescriptions wholesale could add bureaucracy without improving an agent-operated KB workflow. The development/deployment split is useful but coarse: mixed programs may contain both inventive and repeatable work. The report also groups changed demand, new technology, weak requirements, and invalid assumptions under one uncertainty heading; as Changing requirements conflate genuine change with disambiguation failure explains, those causes can require different responses. Its 2001 organizational examples further limit transfer of the surrounding management prescriptions, even where planned deferral until relearning remains plausible.

Add a bounded rolling-wave example to An author should fix what the executor can't determine, not what it will, citing this ingest for planned deferral until relearning supplies missing premises and explicitly excluding Githens's WBS, Gantt, gate, baseline, change-control, and approval machinery from the transferred claim.

Relevant Notes: