A work breakdown structure or WBS is a common term in project management. The concept is used each time a new project is designed — and is created before entering any data into a Microsoft Project file. Yet even though the WBS is an important construct to project managers, creating and using a WBS in the project design phase does not occur with the regularity that you might expect.
Some of this lack of use of the WBS stems from the complicated 243-page specification published by the United States Department of Defense (MIL-STD-881C), which was initially developed back in the 1960s to help NASA and the U.S. military better manage mega-projects, like building rocket systems or getting to the moon. Nobody wants to adopt a practice that takes 243 pages to describe. However, it doesn’t have to be that difficult.
A WBS is really just a visual breakdown of a project into smaller components — think hierarchy – which makes planning for (and creating) the required deliverables easier to accomplish for any project team.
The benefits of designing a project that incorporates a WBS are multifold:
- The WBS helps define key deliverables and sub-components of deliverables before work is scheduled and started, resulting in a smoother rollout during the project. The scope of your project is captured in the WBS, helping to prevent mission- or scope-creep later.
- The WBS provides a much-needed collaborative tool that can be reviewed early on with project teams, management and other stakeholders before a plan is locked in.
- The WBS gives everyone a clear, visual representation of a project, without having to wade through the minutia and tedium of other types of project metrics or documentation.
- Through use of a numbering schema, the WBS identifies parts of a plan numerically (often called WBS codes), which can be used in many ways during the execution of your project. For example, a repetitive deliverable that is identified by number can be easily resourced, costed or scheduled programmatically from within Microsoft Project (or many other scheduling tools).
Rules to Develop a WBS structure
Exhaustive & Mutually Exclusive Rule
First, the 100% Exhaustive & Mutually Exclusive Rule provides that within every level of your WBS, everything you need to deliver is represented within that level. For Level 1 of your hierarchy, for instance, you should find everything that you need to deliver for your project in totality. Within level 2 of that hierarchy, everything you need to deliver for that subcomponent of your project is included (and nothing else). There should be no overlap in scope between the various levels of your WBS. Just the act of creating the WBS exposes deliverables or events that may detrimentally overlap in your plan — and therein lies the beauty of employing a WBS. This figure shows a sample WBS structure I’ve set up in a “mind map” format.
Make a Logical Structure Rule
Second, the Make a Logical Structure Rule provides that you make a visible representation of your WBS in a hierarchy that makes sense, and is easy to read. In olden times, this was often done in PERT charts. In today’s world of simplification, a much more recognized and modern visualization tool is the ubiquitous mind map, as shown in the figure above.
Note: the numbering schema that goes along with this hierarchy can be automatically generated in Microsoft Project (see the figure below for an example), and WBS codes are better formatted this way instead of being within the task names themselves.
Microsoft Project can automatically assign WBS codes, using a new column and the WBS field (a preferred method over typing numbers into task names)
WBS Grammar Rules
Third, WBS Grammar Rules should be followed, but don’t worry, this grammar is easier than you think! Here’s how you do it:
- Use descriptive nouns to describe all your deliverables and sub-deliverables
- At the lowest levels, use action verbs to describe what’s needed to make each sub-deliverable “happen.” This figure shows WBS grammar rules in action.
WBS grammar rules applied at different levels of the hierarchy
By following these three golden rules, your WBS will become an invaluable tool throughout your project planning experience: from the initial design collaboration – to the actual scheduling in Microsoft Project — you will surely come to depend on having a WBS prepared for every project that you manage.
For more information on how to mind-map out your WBS, see this article on MPUG.org.
Related Content
Webinars (watch for free now!):
Using WBS Schedule Pro by Critical Tools
Proactive Scheduling Essentials with Microsoft Project
Articles:
7 Incorrect Ways to Use Microsoft Project: Too Much Detail in the Schedule
You Produced a Great Schedule…Now What?
The Work Breakdown Structure
Chris Rose
Jigs,
I was with you up until the end. A WBS contains deliverables, and only deliverables. No tasks. Research, Write, Produce. Those are tasks and belong in the schedule, not the WBS. What do you produce from the Research. What do you Write. What do you Produce. Those are what go here. I’m with you besides that. Thanks for the article.
Jim Spiller
WBS as it pertains to MS Project is simply a way to organize tasks in a project in a hierarchical fashion. What the author has given us is a WBS “Chart” which demonstrates this type of outlining in a graphical image. In its simplest form a WBS (or outline) is created in MS Project by indenting items in a Gantt Chart. This produces the structure of Summary Tasks (those with subordinates) and Tasks (at the lowest level). This is the approach to building a WBS that Microsoft has used since Project was released. MS Project doesn’t offer the “Chart” part of the WBS but nowhere is this clearer or easier to accomplish than in WBS Schedule Pro (www.criticaltools.com) which produces WBS Charts from the outlining created in MS Project.
The bottom line is that what you get out of MS Project is Outlining with WBS coding and pictures of this can come from other tools.
Jigs Gaton
@ Chris, @Jim: good comments, thx. You both illustrate how a WBS has been modified from a pure form to fit what we have today – also an example of how software can modify methodology, for better or worse 🙂 Btw Jim, I used WBS Schedule Pro to create the figures above; it’s a very good add-in.
Jigs Gaton
@ Carlos: Yes, I like WBS Schedule Pro as well, and I use that interchangeably with MindManager or Xmind… to visually create the WBS for import into MS Project or http://www.projectplan365.com. I think the important point is that if your main PM app is not visual in nature (spreadsheet-based apps), then I recommend creating the WBS outside of that. Just as one would first mind-map out a school paper before starting to type in MS Word or whatever.