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).

To develop a WBS for your next project, just follow these three golden rules:

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.

Levels of a WBS highlighted for a sample project; an ellipsis (…) indicates more of the same

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)

Third, WBS Grammar Rules should be followed, but don’t worry, this grammar is easier than you think! Here’s how you do it:

  1. Use descriptive nouns to describe all your deliverables and sub-deliverables
  2. 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.

To learn more about WBS, read this MPUG article: “


Related Content

Webinars (watch for free now!):
Using WBS Schedule Pro by Critical Tools

The Work Breakdown Structure
3 Correct Ways to Do Great Scheduling with Microsoft Project