Sunday, September 7, 2014

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.

No comments:

Post a Comment