How to Create a Work Breakdown Structure (WBS)
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. Fortunately, all of these are correctable mistakes.
A well-constructed WBS is essential to proper project management. Without a complete WBS, the project manager cannot accurately cost a project, schedule it, staff it, or evaluate the risks associated with it. A WBS is a fundamental building block upon which the entire project is constructed and managed.
What is a WBS?
In simple terms, a WBS is description of the deliverables of your project. It describes what you’re building in small pieces that add up to the entirety of the project. It is created via subdivision of a large project into smaller, manageable “sub-projects” that, together, make up the cohesive whole of the project. Each element of the WBS represents “work product” that needs to be delivered, conducted, performed, managed, and/or produced by the project team. The smallest, lowest-level components of a WBS are known as “work packages.”
A WBS is generally oriented toward “deliverables” of the project, but it also includes all the other work output that the project has to perform to deliver the end product. This includes such things as project management, quality assurance and control, safety, and systems engineering. The deliverable itself is typically known as the “product scope,” while all the supporting work is known as the “project scope.” Project scope often also includes items and services that the project has to pay for and/or secure, such as administrative services, building costs and utilities, and outside legal support. Click here more information on the difference between Product Scope and Project Scope.
A key thing to note is that all elements of a WBS, whether they represent product or project scope, should be stated in nouns, not verbs. For instance, the product deliverable elements of a WBS for a bicycle project would include such things as bicycle frame, handlebars, pedals, and gears. It would not use verb-terms like “design bike frame” or “manufacture handlebars.” Those things are activities and tasks that described and included in project schedules, not WBS’s.
The Different Forms of a WBS
Work Breakdown Structures are often presented in an org-chart-like layout, as shown in the image below. The highest level elements are decomposed into lower and lower levels of detail.
There are other forms a WBS can take. For example, a hierarchical numerical list is often used in conjunction with a chart-type. Below is an example for a simplified project numerical list WBS used to create new bicycle:
Other WBS forms can include mind-maps and general outlines. It really doesn’t matter which is used as long as the WBS contains the entirety of the project scope. Use a method or format that best suits the needs of your team and the industry you work within.
The 100% Rule
One guiding principle you should keep in mind when creating a WBS is that it ultimately must 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, to complete the project. A WBS should also 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.
While the layout of a WBS doesn’t need to be perfect, the content does. In other words, you absolutely must account for 100% of the work scope of a project. You must strive to not leave anything out. If you do miss something that is discovered later, you’ll very likely have to ask for additional money and/or time to create that missing scope. This will require a draw upon contingency reserves to pay for it, slip the schedule, and/or you’ll have to sacrifice other, lesser important work scope to pay for the newly discovered scope. Rarely are any of these good options. Ergo, strive to create a complete accounting for all the project’s scope.
Another guiding principle when creating a WBS is that of so-called “mutual exclusivity.” It is vitally important that there be no overlap or ambiguity in scope definition between the different elements or branches of a WBS. If a deliverable is in one element of the WBS, it cannot also occur anywhere else. Overlapping and/or ambiguous scope leads to confusion of responsibilities and/or duplicated work. It also makes accurate costing and scheduling very difficult.
Progressive Elaboration of the WBS
One way to find the entirety of project scope is via the application of Progressive Elaboration. Work on the higher-level WBS elements first. Review these to ensure you have all the big-picture scope accounted for, then drop down a level and subdivide and breakdown that level of scope. Rinse and repeat at each progressively lower level of the WBS until you get to the work package level. Visualize how a subsystem comes together; what are its constituent components, and what is and isn’t included. Start high and decompose into lower levels; do not try to create a WBS from the bottom-up.
As stated above, at the lowest level of a WBS are individual work packages (WP). When first planning a project you don’t have to identify every single one of these, but you will need to by the time you’re ready to baseline your project. Again, progressive elaboration is the key to tackling this 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 schedule activities for the project. You have to eventually break the work down to this level of granularity to create these things, but it makes no sense to go further than this. The sweet spot that lies between too little and too much detail is something that is different on every project—and something that every project manager has to determine for his or her own situation.
Knowing What’s NOT In The WBS Is As Important As Knowing What Is
In addition to ensuring 100% of the project is contained in the WBS, it is 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, no less.
Taking the time to define—and document—what is not included in your project then allows you to convey this to your stakeholders. This, in turn, means that they won’t be surprised at the end of the project when you deliver X and they were expecting Y. It also allows you to properly budget and schedule the work you and your team have to perform during the course of the project.
Brainstorm, R&D, and Other Methods of Scope Definition
Early on my current project, we held a series of WBS brainstorming sessions with the most experienced engineering and science members of our team present. We did this at a retreat location, away from our normal work offices, so that we could focus and work uninterrupted. We started by creating individual lists of delivered elements and subsystems for the new telescope.
During these sessions, we used dry erase white-boards, big sheets of “butcher paper,” and lots of yellow sticky notes and index cards to capture all this information in real-time. The immediate focus was 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 where those elements should reside in relation to each other in the WBS.
Another powerful tools to use at this stage is “R&D’ing”, or Rip-off and Duplicating from other, previous projects that are similar to yours. When it comes to capturing all the scope on a new project, look around and see if you can use a WBS from a similar project as a starting point, both for identifying scope as well as organizing it.
You can also copy templates that are used in your specific industry or field. The obvious benefit in doing this is it gives you an initial starting point in the content creation 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 the next, essentially “in-breeding” errors and omissions. You should definitely consider R&D’ing from other, similar projects, but remember to be judicious about it. Treat it as a starting point, then make it your own.
Organize the WBS AFTER Collecting Input
After you have collected all of your individual scope elements, you should begin organizing these into logical groupings and categories. Again, you can use butcher paper and note cards to shuffle and move things around on a big table and/or whiteboard. Similarly, you cam use so-called “mind-mapping” software to capture content. I’ve personally used products like coggle.it and MindNode for this purpose on small and large projects alike with very good success.
During this initial layout, management should give the engineering team almost complete carte blanche to sort and organize. That said, there should be some initial over-arching guidance; for example, when grouping items together, you might ask your team to think in terms of contracting strategies. How you’re going to subdivide the procurements on a project should align as closely with your WBS as possible; you should strive to avoid components in a single procurement package spanning multiple major branches in a WBS tree.
For example, on my current project, we were a small team at first, and the plan was to stay “lean” for a while and try to leverage involvement from industry and partner institutions. This meant larger than typical contracted sub-packages for combined design and fabrication for many of the subsystems. Even if we assumed we were going to self-perform a task in-house, we acted as if we were going to subcontract out that package when organizing the WBS; this kept us focused on ensuring discrete, standalone and self-contained “contract” packages for which we could readily write SOWs, specs, acceptance criteria, and interface control documents, as well as estimating cost and schedule.
While a well structured WBS is what you’re aiming for, the truth is that its organization doesn’t have to be 100% perfect; much more important is content than structure. Like many things in project management, laying out and 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 honest truth is that things will indeed likely 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 the WBS creation, get those things nailed down, and then fill in details in each successive iteration.
Work Scope: Yes; Tasks & Activities: No
Finally, it’s useful to reiterate what isn’t in a WBS; there are some things that definitely should not to be included. For example, a WBS should not be a list of tasks or activities to be performed. Instead, it’s a comprehensive classification and collection of work, not tasks.
A WBS is also not a project plan, or a schedule, or a chronological listing of tasks. Instead, a WBS simply lists scope; i.e., what will be performed and delivered, not how or when or in what order.