Time Management - Rolling Wave Planning

In my last post (here) I described the basic process of putting an Integrated Project Schedule, or IPS, together from scratch. Today I want to discuss a common trap that many Project Managers fall into when creating their IPS: adding too much detail to the out year work. 

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.

Work Breakdown Structures, Part II

When creating a WBS from scratch, there are two major actions that have to be performed right from the start: 1) determining what scope to put in, what to leave out, and how far to subdivide things; and 2) sort, layout and organize the tree structure with this scope. While nowhere near comprehensive, here are some lessons learned and rules of thumb to keep in mind when doing these things.

• 100% of Project Scope. While the layout of a WBS doesn't need to be perfect, the content does. In other words, you absolutely have to account for 100% of the work scope of a project. You must strive to not leave anything out. If you do miss something, you'll have to either ask for additional money and/or time to perform that missing scope later when it's discovered, you will have to draw upon contingency reserves to pay for it, and/or you'll have to sacrifice other lesser important work scope to pay for the newly discovered scope. None of these options are good. One trick to doing this is the application of Progressive Elaboration. Hit the higher-level WBS elements first, then subdivide and breakdown the scope as you proceed. Visualize how a subsystem comes together; what are it's constituent components, and what is and isn't included. Start big and decompose.
• Brainstorm Scope. Early on our project, we held a series of WBS brainstorming sessions with the most experienced engineering and science members of our team. We did this away from our normal work location so that we could focus and work uninterrupted. We started by creating individual lists of delivered elements and subsystems of the new telescope. We used dry erase white boards, big sheets of "butcher paper," and lots of yellow sticky notes and index cards to capture this information in realtime. The key is to focus on listing and capturing everything, not sorting and categorizing them; i.e., identifying all elements of work scope at this point was significantly more important than deciding with absolute certainty where those elements should reside in relation to each other in the WBS.
• Don't Include Non-Project Scope. In addition to ensuring 100% of the project is contained in the WBS, it's just as important to exclude items that are not true work scope. A well constructed WBS should include exactly 100% of the project work scope, no more, and no less. On our project a number of items were ultimately rejected because they more correctly belonged in operations.
• Don't Reinvent the Wheel. One of your most powerful tools as a project manager is your ability to "R&D", or Rip-off and Duplicate from previous projects that are similar to yours. Look around and see if you can use a WBS from a previous project as a starting point, both for identifying scope as well as organizing it. Also look for templates that are used in your specific industry or field. The obvious benefit in doing this is it gives you a leg up in the process. Potential downsides, however, include: a) all projects by definition are unique, so the WBS for one project won't map fully to another; and b) organizational and content problems get carried over from project to project, essentially "in-breeding" errors and omissions. Definitely consider R&D'ing from other projects, but be judicious about it.
• Organize your WBS to Align With Your Team Strengths and Contracting Strategies. Once we had a fairly comprehensive collection of individual scope elements, we started organizing these into logical groupings and categories. Again, we used butcher paper and note cards to shuffle and move things around. (Another trick is to use so-called "mind-mapping" software to capture content. I've personally used products like coggle.it for this purpose on small and large projects alike with good success.) During this initial layout, management gave the engineers nearly carte blanche to sort and organize, but they did insist on one thing that served us well: when grouping items together, management asked that the team think in terms of contracting strategies and personnel to manage said contracts. We were a small team at the time, and the plan was stay lean for a while and try to leverage involvement from industry and partner institutions. This meant larger than typical contracted sub-packages for design and fabrication for many of the subsystems. Also, even if we knew we were going to self-perform a task in-house, we acted as if we were going to subcontract that package when organizing the WBS; this kept us focused on discrete, standalone "contract" packages for which we could readily write SOWs, specs, acceptance criteria, and interface control documents, as well as estimating cost and schedule.
• Recognize Perfect is the Enemy of Good Enough. While a perfectly structured WBS is what you're aiming for, the truth is that its organization doesn't have to be 100% ideal; much more important is content than structure. Like many things in project management, structuring a WBS is a balancing act: it's important to spend enough time up front to get to something that won't have to be changed later, but the truth is that things will change. Try to build in simplicity and flexibility in the WBS organization to accommodate these future changes. It's also useful to utilize methods like Progressive Elaboration; i.e., worry about the big picture items during the first pass through, get those nailed down, and then fill in details in each successive iteration. 
• Work Packages. At the lowest level of a WBS tree are the individual work packages (WP). When first planning a project you don't have to identify ever single one of these, but you will have to by the time you're ready to baseline your project. Again, Progressive Elaboration is the key to tackling the job of identifying WPs. The purpose of breaking down the WBS into WPs is that you will use these to produce realistic cost estimates and schedules for the project. You have to break the work down to this level of granularity to perform these steps, but it makes no sense to go further than this. Finding this sweet spot between too little and too much detail can be challenging.
• Size of Work Packages. Every project is different, but there are some rules of thumb that project managers tend to fall back on when determining how far to subdivide the work:
• 80-Hour Rule. For "standard" work products in typical projects, the lowest level of detail (i.e., work package) in a WBS should be something that takes no more than 80 hours to perform. Unfortunately, on big, complex multi-year science projects, this means there could potentially be thousands of work packages. This can often be overkill, and therefore this rule is really only applicable to simpler standard projects.
• Reporting Period Rule. Another rule of thumb to consider is that no single work package deliverable should take longer to perform than a single reporting period. For example, if you have to report to your customer on a monthly basis, the work packages should be subdivided such that the tasks associated with each WP can be performed in less than one month. Again, on bigger projects this may not apply very well.
• The Common-Sense Rule. Remember the goal of a WP is to allow accurate estimating, planning, executing, and controlling. If a WP doesn't fit within the 80-Hour or Reporting Period rules, then that is fine. Too much detail is often just as bad as too little.
• Don't Go Too Far, Too Fast. Be careful about over-subdividing, especially too soon. Once a WBS number is created, it's used in many places by many people; i.e., it becomes difficult to change later (due to all the impacted docs). For example, we made this mistake whebn subdividing our site and support facilities work into very low-level WBS items that we assumed would match a specific contract strategy we expected to employ. Unfortunately, our strategies and corresponding subdivison of the work changed later, but our WBS was so ingrained into the project at that point we had to live with the old numbering system. This caused significant confusion and bookkeeping issues in later years of the project that could have been avoided if we simply refrained from too much detail.
• Don't Worry About Numbering Systems Until You're Done. It's easy to get hung up on numbering systems and wondering whether a work element should be at the third or fourth level of the WBS. This is a waste of time early in the process and just serves as a distraction. In fact, the final numbering and sorting shouldn't take place until very near the end of the WBS process.
• Alternatives to Numbering Systems. I know of one major project that doesn't actually use traditional numeric numbering systems; the project uses 3- and 4-letter words, separated by decimal points as a substitute to traditional number. In other words, instead of element getting a number like 4.6.3.12  that element would get TEL.STRUC.BASE.FOUND, which would stand for "Telescope.Structure.Base-structure.Foundation. This makes it very easy for a newcomer to the project to understand the various pieces. I'm not entirely sure if this is the best route to go, as project members quickly learn numbering systems just by natural usage, but this is something that is worth considering if you find the traditional numbering systems to be confusing to your team.
• Wait to Apply Change Control.  While it's important to put a WBS under change control, as it will be used for the basis of any number of key project documents, doing so is a double edged sword. You have to get to a point where the WBS is fairly stable and unchanging, primarily so that people can begin working with it (e.g., cost estimating, scheduling, writing documents, etc.). On the other hand, it's useful to simply live with the WBS for a while and let it settle out with time before formalizing it. You will often find that scope items need to be moved from one area to another once you get into their specific details, including determining their contracting approaches, and this becomes harder and harder the more the WBS is formalized. It's a balancing act that is unique to each project.

In the next installment of the Work Breakdown Structure series, I'll discuss the need for a WBS Dictionary, and also include some additional tricks to keep in mind when finalizing your WBS layout and structure. I'll also include a graphic of our current project's WBS, and talk a bit about why it's not perfect (and why that's OK). Stay tuned...

© Copyright 2014 Mark H.Warner. All rights reserved.