In at least two (probably more) the guide (version 6) talks about how the Project Manager and team should understand and analyze the duration of the rolling wave in effect for planning purposes (6.1)
I understand the concept of rolling wave planning, but how is the DURATION of the wave analyzed? Is there a mathematical technique that one can use to establish what the rolling wave SHOULD be for a project? That's pretty strongly hinted at by the PMBOK guide in chapter 6. Saving Changes...
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Good Question David.
I do not think that there is a mathematical technique to do so otherwise they would have mentioned it. This could mean different things for different project life cycles:
Waterfall: You could probably take the overall project duration and estimate as to when you need to have fully detailed deliverables in order for the project to remain on track.
Agile: Progressive elaboration is done before each iteration so and when you plan the release, you estimate the no of iteration you need so this is what they probably mean in this context.
This is my personal opinion of course from what I understood from the guide. Saving Changes...
First off, I agree with you. That's exactly what I believe as well. BUT!
This same topic shows up later in chapter 6 as well. (6.2.1.1) It says that the "Project Management plan should define the duration of waves for rolling wave planning."
But, how did the project team arrive at the duration? That part is never explained. It doesn't read as if it's a rule of thumb in the PMBOK, it sounds like it's calculated ("defined"). I'm very curious about this technique - if there is one - used to calculate the period of time that project detail is understood into the future (the period of the rolling wave).
This could be like EVA! E(rolling wave)A :) We'll call it the Kaibni method.
...
1 reply by Rami Kaibni
Mar 27, 2019 12:33 PM
Rami Kaibni
...
I see what you mean and I agree. This should be refined and restated in a better way in the next version because it could be misleading.
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Mar 27, 2019 12:26 PM
Replying to David Maynard
...
Hi Rami:
First off, I agree with you. That's exactly what I believe as well. BUT!
This same topic shows up later in chapter 6 as well. (6.2.1.1) It says that the "Project Management plan should define the duration of waves for rolling wave planning."
But, how did the project team arrive at the duration? That part is never explained. It doesn't read as if it's a rule of thumb in the PMBOK, it sounds like it's calculated ("defined"). I'm very curious about this technique - if there is one - used to calculate the period of time that project detail is understood into the future (the period of the rolling wave).
This could be like EVA! E(rolling wave)A :) We'll call it the Kaibni method.
I see what you mean and I agree. This should be refined and restated in a better way in the next version because it could be misleading. Saving Changes...
Wade HarshmanScrum Master| GDITIndianapolis, In, United States
David, thanks for digging a little deeping in the PMBOK and bringing this up. The cynic in me will say that perhaps PMI only included "rolling wave" (a WWI term) in the PMBOK as an acknowledgement of what some project managers were doing, but they either never fully understood it or never really thought that it was worth a great deal of ink.
In 6.1.2.2, the PMBOK says an analysis "can also include" duration of waves. I like the more open-ended verbiage here, rather than 6.2.1.1 that you cited. That would be a good change, I think, for the reasons you mentioned.
Note, also, that the PMBOK does little to distinguish between "rolling wave" planning and other forms of iterative planning. The PMBOK uses both terms as though they are distinct, yet combines them frequently as though they are synonymous. (Page 177 actually says that iterative scheduling with a backlog is a form of rolling wave planning.)
The term "Rolling Wave" was in earlier versions of the PMBOK, so PMI acknowledged early on that projects can start without all future details being known. The closer you get to actual project events, the more details you need. This is basically what Scrum coaches teach today. This is a little frustrating to me because it shows that PMI has known about problems with fully predictive plans for a long time, but we didn't develop this topic and now we're struggling to catch up.
(I see you're in Fort Wayne, but I assume you're still watching the game on Thursday?) Saving Changes...
I've never seen a formula to apply rolling wave planning. It's always been done based on expert judgement. Certain major milestones are a natural fit, such as a PDR and CDR, which are often major decision gates, and typically result in re-planning based on a thorough scrub of the entire project.
The time-frame between those major milestones can be quite large on some projects so there is often a need to insert some intermediate checkpoints for evaluation and plan adjustment. How often is dependent on many factors, such as time span to cover, project domain, and the complexity of the integrated change process. A planning wave may take significant time and effort as it may involve supplier commitments and everything else in the value chain, so the span between waves should never be shorter than the time it takes to fully commit a new plan at the last wave, or you never even have a firm schedule before the next wave of changes. Saving Changes...
Good question. For us, we have arbitrarily decided that the duration is 6 months. This is based on the traditional PM approach for large scale defence acquisition projects that span 10 plus years. Saving Changes...
It's like asking the question, how fast should you drive at night. The answer usually depends on how far ahead you can see with your headlights. Well, that also depends on what weather conditions are - with fog, you'd drive a lot slower than with clear weather.
The same is true for projects following a rolling wave approach. The duration should be based on how far ahead the team is able to see with confidence. Anything beyond that is premature planning and risks rework.
The way I understand the rolling wave and the duration. In a large project, you would do planning to a certain level. The Time between rolling wave should be determined.
For example every three months you would do a new rolling wave planning to adjust with project reality and a new level of detail available to planning.
In a large fast track construction project, you don't have all the needed information at the start. So at a regular predetermined moment, a new rolling wave planning will be done. Saving Changes...
Robert MarshallCOO| Prive TechnologiesHitchin, United Kingdom
Great question and one I think most PM's battle with. However I think the guide simply states that you should create a structured approach and plan as to how YOU will manage planning if you need to implement some kind of iterative approach. Depending on how unique or repeated the project outputs are, you would need different approaches. In software development the approach is in fact built into the software development life cycle, and as units of measure for software creation is more art than science, quantitative modelling is very difficult. Thus using expert skill and previous experience on similar projects is the only techniques that can really be used to estimate.
Would be very interested to see if anyone else have a more illuminating answer to your very good question. Saving Changes...
RAJESH K LProject Manager, PMP| Bharat Electronics, Bengaluru, IndiaBengaluru, Karnataka, India
Very good question. using WBS framework, Duration of project is derived based on estimates decided for lowest level of WBS item.
Re-estimation is normally done when scope/schedule changes (due to various factors) or clarity / correction on existing requirements.
In my understanding, rolling wave duration is subject to scope change or other reasons attributing to re-estimation. Saving Changes...
Community Champion
