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 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, together, make up the cohesive whole of the project. Each element of the WBS represents “work” that needs to be delivered, conducted, performed, managed, and/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 it 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. The former is typically known as the “product scope,” while the latter 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 and outside legal support. (Click here more information on the difference between Product Scope and Project Scope.)
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 or branches 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 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, 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.