On complex, multi-year projects with hundreds or thousands of tasks to define, sequence, and estimate, you and your team can spend significant time and effort putting together the IPS-- and some of this time and effort can be a waste of, well, time and effort. Said simply, detail planning of the work that is scheduled to happen in the near term matters a lot more than the detail of the work that will happen in the distant out years of the project. In fact, the details of those out-year tasks don't have to be perfect. Far from it.
Yes, it would be great if you knew for certain all the specific step-by-step things your team has to do during the third week of June four years from now, but the truth is you almost certainly don't know what's going to happen during that week. The truth is you probably don't know for certain what is going to happen four months from now, let alone four years. Heck, you're often doing well as a project manager if you know what's going to happen four weeks from now with certitude. You can guess the out year work--and a certain amount of guessing is indeed necessary--but far to many new project managers get hung up on trying to get those out years perfect. And in most cases, it's a waste of time to do so. In fact, it's costly to do so. Let me explain.
First, notice the word "guess" in the previous paragraph. Your boss and/or sponsor probably doesn't want to hear and/or acknowledge this, but a schedule is nothing more than an educated guess of how long and in what order the tasks of your project will need-to occur. You, as a project manager, get paid to make and hold your project to these guesses, but they're still guesses nonetheless. And the fact is that you can guess a whole lot better for the work coming up in the near-term than you can for the work that will happen months or years from now. Enter rolling wave planning.
Rolling wave planning is a type of progressive elaboration technique in which you concentrate you and your team's effort on adding detail and fidelity to the near-term "wave" of upcoming tasks and deliverables, and spend less time estimating details and durations for the out-year tasks. As time inexorably marches forward, your job is to push this rolling wave of guesses forward and add detail and refinement to the plan as the project's "event horizon" changes. At the beginning of the project, near term work is decomposed into individual subtasks and steps, and they are defined at the greatest level of detail possible. Schedule activities that will take place several reporting periods in the future are more broadly defined. For example, phases one and two of a project might be fully broken down in full detail, but phases 3-6 might be outlined only to the level of subprojects, and phases 7-10 are even more broadly estimated. While schedule activities for phase 1 are underway, the detailed planning for phase 3 would commence. As phase 2 is put in motion, planning for phase 4 would start, and so forth.
In this way, rolling wave planning permits work activities to move forward on current and near term deliverables while refined planning is still ongoing for future work packages. This type of project management approach is particularly useful when the availability of information needed to plan future work packages in detail is based and predicated on the successful completion of previous project phases. Here's a generic example of a rolling wave schedule to demonstrate (click image to enlarge):
Note that the near term work in this generic schedule has been estimated and sequenced down to a relatively high level of detail and fidelity. The mid-term tasks that follow the near-term are left as bigger blocks of medium-sized tasks, with less resolution. And the far out-year work is simplyl represented by big, rough blocks of effort.
Note, too, however, that reportable level-1 milestones have a regular cadence to them that is irrespective of the level of detail in the schedule above; this type of milestone is usually important to your senior management and/or your sponsor, so you often have to include all of them from the very beginning of the project. Most of these are tied to specific work tasks, but sometimes the out year milestones need to be artificially placed using educated guesses and/or expert judgement. As the rolling wave of time moves forward, you can refine and add logical predecessors to more accurately reflect milestone movement.
In almost all projects, the out-year task details are going to change and adjust as the project matures and progresses. Stuff happens, as they say. New information becomes available, tasks you thought would go easily don't, and vice versa. Delays happen. Technical problems crop up. External factors affect your internal work. Personnel leave and/or get promoted and/or move on. Change occurs. Spending a lot of time making the out-year work planning guesses perfect in your schedule is, frankly, a waste of that time. Not only are you spending valuable effort estimating things in great detail that are almost certainly incorrect and will change, you also have to continuously debug and refine and defend and explain all the resulting changes to those tasks as they move and shift in your IPS.
Instead of doing this, spend that same time and effort making the near-term and mid-term items as perfect as you can, and just estimate the out-year work via past experience on other projects, engineering rules of thumb, and expert advice. If possible, build in buffer on those out-year estimates to soften the blow of future changes. But then stop fretting that out-year work, and refocus the bulk of your attention on managing the near-term efforts. As time marches forward and the mid-term work starts to be creep into the near-term, you and your team will add detail and refine those new event horizon tasks. The wave of time marches forward, and so should your planning efforts.
For example, on my current project, for the first few years we left our enclosure (dome) site assembly and test work very roughly planned in our schedule. We didn't know for certain how this work would be sequenced, so we didn't waste time worrying about it. We knew from past projects that it took roughly a year to assemble and test an observatory dome, so we simply inserted a year-long estimate into the schedule and then focused our efforts on planning and managing the tasks that led up to that work. Then, when we were about six months from performing the site assembly and test work, we took the time to reexamine and break down the large generic tasks into more refined and accurate smaller tasks that we could track and manage as we moved into that phase. Here's the before and after shot from our schedule to demonstrate how this worked (click to enlarge):
This is a classic demonstration of how rolling-wave planning should function on large, complex projects. That's the good news. The bad news is we frankly didn't so well in a few other areas of our project. In fact, a couple of our subsystem engineers added far too much detail to their respective out-year tasks when laying out the original IPS, and we/they are still paying for that mistake; these engineers/workpackage-managers have to spend significant time every month changing and managing and explaining those bad guesses as things have changed. This all could have been avoided if we'd enforced the concept of rolling wave planning across the entire team on our project from the beginning.
Learn from this and try it on your next project. You'll probably be much happier if you learn to surf the wave!
2014 Mark H.Warner. All rights reserved.
