Work Breakdown Structures, Part V

As mentioned before (here), when putting together a WBS from scratch, it’s useful to think about how each of the various work package deliverables are going to be procured. Will they be built in-house, purchased, or will you have to implement a contract with a vendor to produce an item? Thinking this through now will greatly help with the organization of the WBS, helping/causing you to logically group items together in a way that aligns with your procurement strategies. Most experienced project managers take this approach, and in fact it’s what we did when producing the WBS on my current project. We literally sat in a room toward the end of our initial WBS brainstorming session and took a first pass through our procurement strategy for each element. The final layout and organization of the WBS elements into logical groups was almost a trivial task to undertake following this exercise; we had a very good idea of how items should be associated with each other once we understood our plan for procuring those items. 

Another thing that’s very useful to do at this point is to think about personnel required to support your procurement strategies, and if possible, align the WBS and org charts with each other. Sometimes minor changes in one or the other can reduce (or at least clarify) what personnel resources are needed. For example, our project org chart very closely lines up with our WBS, and has a single dedicated “Cost Account Manager” (CAM) aligned to each major deliverable in the WBS. There were a number of "TBD" names written into the chart at that point in time (because we hadn't yet fully staffed the project), but thanks to this exercise we knew who and/or what type of person we would need to hire to support each major area of the WBS. Some projects actually write the name of their CAMs into the WBS tree, which then serves as the de facto org chart as well.

Another useful step to take when finalizing the first draft of your WBS is to create an interface chart of the WBS elements. Sometimes known as an “(N^2-N)/2” diagram, “N2”, or "N-squared for short, this chart helps define and track all the necessary interfaces between WBS elements. (The name of the chart derives from the number of possible interactions, or interfaces, between WBS elements. For example, a project with 4 WBS elements can have up to [(4x4)-4)/2] = 6 interfaces.) I’ll write more about N2 diagrams in a future post on managing the systems engineering of your project, but for now, just know that creating this chart now will help immensely when it comes time to begin planning procurements, as it helps focus efforts on defining key interfaces and procurements in a prioritized fashion. Here’s view of a big telescope project's N2 chart (click to enlarge):

An N2 diagram (pronounced "N-squared") for a big telescope design/construction project. The elements listed along the diagonal of the chart are the major WBS elements. The colored ovals above the diagonal represent interfaces between WBS elements. This graphically shows which elements are dependent upon others for key interface definitions; this helps focus and define procurement strategies and prioritizing on a project, as well as affecting the layout and structure of the initial WBS, too. Taking a first pass on an N2 diagram prior to putting your WBS under configuration control at the start of a project is a very beneficial step for the project manager to take, as it may help inform the logical grouping of WBS elements.

I promise I'll move to a topic other than WBS creation in the near future, but I've wanted to spend these last few posts on this subject, mainly because it is so incredibly vital to success on a project. You cannot solve a problem until you define it. When it comes to project management, you literally cannot succeed if you don't fully define what it is that the project is going to deliver-- down to the lowest level work package. Spend the time up front getting 100% of your project's scope captured in a logically arranged work breakdown structure, and you have taken the first step towards project success. Don't do this, and you're almost certainly destined to fail.

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

Work Breakdown Structures, Part IV

As promised in the last blog entry, here's my current project's WBS tree (you can click on the image to make it larger):

Is it perfect? Heck, no. There are any number of things I would change and re-organize if I were able to do it all over again, knowing what I know now. But it's not a huge issue. As I stated here, a WBS has to include 100% of your project's scope, but the organization and layout of the structure doesn't have to be perfect-- just good enough, which ours certainly is.

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

Work Breakdown Structures, Part III

Once you've completed a first detailed pass through your WBS and have reviewed it with your high-level engineering managers, the next step is to write a WBS Dictionary to accompany the breakdown. The process of creating this document can be laborious, but it's crucial; a WBS Dictionary serves as the one definitive document that explains and describes the full scope of your project. Without a WBS Dictionary, there can/will be ambiguity and uncertainty within your team over what is--and isn't--included in each scope area of the project. There can also be uncertainty over who is--and isn't--responsible for each element of scope.

The WBS Dictionary also serves as the jumping off point for performing your detailed cost and schedule estimates. Said simply, without a clear and detailed understanding of what is included in each WBS element, you cannot expect to be able to fully and accurately estimate the cost of that element, nor can you accurately estimate the time it will take you to complete the work associated with it. Risk identification, resource requirements, and so on all fall out naturally from a complete and accurate WBS Dictionary.

There are other reasons to create a WBS Dictionary, too. On our project, for example, each individual work package page (which are web accessible) also serves as the repository for other relevant information associated with the element. This includes such things as basis of estimate (BoE) calculations and spreadsheets, bottom up risk/contingency calculations, change request histories associated with the work package, plus links to other associated documents. In other words, ours is a WBS Dictionary on steroids, and it serves as the first place we tend to look for work package-related information. The Dictionary offers both high-level and very specific detailed information on WBS elements.

While you don’t have to go as far as we have, you still need a Dictionary. If you’ve never created one before, a good place to start is with a previous WBS Dictionary that your company has used. Alternatively, you can use a standard template, of which there are many just a Google search away.

For what it’s worth, some of the information our WGS Dictionary pages include are:

• WBS Name
• WBS Number
• Work Package (or Budget Account Code)
• Expected WP Start Date
• Expected WP Finish Date
• Current WP % Complete
• Responsible Cost Account Manager (CAM)
• Funding Source Earned Value Technique
• WP Description (both what’s included and what’s not)
• SOW for this element BoE for this element
• Change Request History
• Milestone Description, including weights
• Contingency Calculator
• All other relevant attachments

Each individual page of our WBS Dictionary also includes spaces for two required signatures. The first is the CAM, and the second is the Project Manager. These two entries are probably as important as any other on the page-- the two signatures represent that the information is agreed upon by both the low level cost account manager who is responsible for performing the detailed work associated with the element, and the high-level project manager who’s responsibility is to ensure the entire scope of the project is accounted for within the pages of the Dictionary.

I’ll have a few more things to say about WBSs in my next post, including the previously promised look at our project’s WBS. I’ll also include a same page from our WBS Dictionary as an example. Stay tuned...

© Copyright 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.

Work Breakdown Structures, Part I

Create a WBS to help organize your project into manageable pieces.

Many new project managers (and some experienced ones, too) struggle with the concept of a work breakdown structure, or WBS. They put the wrong types of things into their WBS. Or they put too many elements in it, or too few. Or they treat it as a schedule, or a plan, or a chronological listing of actions that have to be performed. Or perhaps they eschew the need for a WBS altogether. All of these are (correctable) mistakes.

A well-constructed WBS is vital to proper project management. Without a WBS, the project manager cannot fully and correctly cost a project, schedule it, staff it, or even evaluate the risks associated with it. A WBS is a fundamental building block upon which a project is assembled and managed.

In simple terms, a WBS is a logical subdivision of a large project into smaller, manageable "sub-projects" that each have to be performed for the cohesive whole of the project to be achieved. Each element of the WBS represents "work" that needs to be delivered, conducted, performed, managed, or produced by the project team. Further, each element can be further subdivided into smaller and smaller pieces. The lowest level items in a WBS are known as "work packages."

A WBS is generally oriented toward "deliverables" of the project, but also includes all other work that the project has to perform to deliver the end product, such as project management, quality assurance and control, science support, and systems engineering. It often also includes items and services that the project has to pay for and/or secure, such as administrative services and outside legal support.

One guiding principle you should keep in mind when creating a WBS is that it should include exactly 100% of all project work, including all internal, external, and interim items. This principle is called, not surprisingly, the "100% rule" by project managers, and it is perhaps the most important thing to keep in mind when putting your WBS together. Said simply, a WBS should include all the work required, but nothing more; a WBS should not include any work that falls outside of the scope of the project. The 100% rule also pertains to sub-branches within the WBS. That is, every "parent" element in a WBS branch must equal the sum of all is "child" subparts, no more and no less.

Another guiding principle when creating a WBS is that of mutual exclusivity. It is vitally important that there be no overlap or ambiguity in scope definition between the different elements of a WBS. Overlapping and/or ambiguous scope leads to confusion of responsibilities and/or duplicated work. It also makes accurate costing and scheduling very difficult.

Besides knowing what goes into a proper WBS, there are some things that definitely are not to be included. For example, a WBS is not an exhaustive list of tasks to be performed. Instead, it's a comprehensive classification and collection of project scope, not tasks. A WBS is also not a project plan, or a schedule, or a chronological listing of tasks. Instead, it lists what will be performed and delivered, not how or when. Finally, a WBS is not an organizational hierarchy per se-- but note that a good one often aligns closely with a project's org chart.

In the next installment, I'll discuss a little more about how to create a WBS from scratch. Stay tuned.

A simplified Work Breakdown Structure (WBS) for the construction of an office building. There are many missing elements in this example, such as procurement of land, permitting, outfitting and furnishing, etc.

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