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.