If you are confused about what is involved in creating a Work Breakdown Structure (WBS), you are not alone. Come along as we define the WBS and look at some of the nuances in WBS terminology.
One of five keys to project success is to have agreement among stakeholders on the goals or end product of the project. This is where having a good understanding of a WBS becomes important. The WBS is an implicit contract between the customer and project manager describing the end product or service the project will produce. A sound understanding of the WBS is therefore imperative for project success.
This article describes what is and is not included in a WBS to help foster mutual agreement among stakeholders on project objectives or the end product of the project.
The concept of the work breakdown structure was first developed by the U.S. Navy in 1957 as part of the Program Evaluation and Review Technique (PERT) methodology developed for their Polaris missile program. It is interesting to note that while the term ‘work breakdown structure’ was not used specifically at this time, PERT did organize tasks into product-oriented categories.
What exactly is a WBS? The Project Management Institute’s (PMI) “A Guide to the Project Management Body of Knowledge (PMBOK Guide)” defines a WBS as a “hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables”. Note the use of the terms scope, work, and deliverable. PMBOK defines scope as “the sum of the products, services, and results to be provided as a project”. Work, of course, is effort. However, in the context of a WBS the PMI’s “Practice Standard for Work Breakdown Structures” says “work refers to work products or deliverables that are the result of effort and not the effort itself”.
A deliverable, according to PMBOK is “any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project”. So a deliverable is the end product or service provided to the customer. The Practice Standard takes all these definitions and terms into consideration when it states that “In a sense, the WBS can be thought of as a ‘deliverable’ breakdown structure”.
It is important to think of the WBS in this ‘deliverable’ breakdown structure sense, so you know what you are presenting when you describe your project’s WBS to all the stakeholders. The Practice Standard says that the WBS is used in projects “to define the project’s scope in terms of deliverables and to further decompose these deliverables into components”. Despite its name the WBS is not a description of the work or effort required to produce the deliverables; it is a breakdown of just the deliverables by themselves. This discrepancy causes confusion.
Some authors of books on Microsoft Project say the WBS is “an indented list of deliverables and tasks”. PMI says deliverables, yes, but tasks, no. This distinction is important because when you present the WBS you may think of yourself as presenting a scale model of say; a building to be constructed. You are not displaying a diorama of the building in the process of construction with three-dimensional figures of construction workers and equipment. The WBS tells you what the end product or service looks like – nothing more – nothing less. So do not confuse your WBS presentation by the addition of associated tasks or activities. They come later in the scheduling process.
Let me here quote the Practice Standard to clarify. “The WBS represents a clear description of the project’s deliverables and scope – the ‘what’ of the project. It is not a description of a process or schedule that defines how or when deliverables will be produced, but rather is specifically limited to describing and detailing the project’s outcome or scope.”
Now enters the concept of the “work package” that seems to contradict the quotes stated above. The PMBOK Guide defines work package as “the work defined at the lowest level of the work breakdown structure for which cost and duration can be estimated and managed”. Taking into consideration the above quotes, the work package on the WBS is the deliverable at such a level of decomposition that the associated tasks, including duration estimates and resource assignments, may be defined for that decomposed deliverable.
The Practice Standard says work packages should “clearly support the identification of the tasks that must be performed in order to deliver the work package”. Thus, the WBS does not describe work, however, it “supports the definition of all work required to achieve an end objective or deliverable(s)”. Again, the WBS “defines the hierarchy of deliverables”. That’s it!
The Practice Standard further states that the WBS should “contain elements that are defined using nouns and adjectives – not verbs”. Deliverables are described by nouns and adjectives, while the work required to produce those deliverables is described by verbs. The WBS elements do not describe work, so you use nouns and adjectives to define the WBS elements and not verbs.
The Practice Standard realizes that team members may become confused, in particular, when it comes to defining work packages. So if your team members are identifying “all of the deliverables (or work packages) involved in the project”, and they propose activities, the Practice Standard tells you how to address this issue. “If participants propose activities [for work packages], then the associated deliverables, but not the activities, should be included (i.e. translate suggested activities into associated deliverables)”.
People who use Microsoft Project may become easily confused and include tasks along with deliverables in the WBS. This is most likely because the WBS elements and associated tasks are listed in the same column in Microsoft Project. Also, Microsoft Project assigns both deliverables and the associated tasks WBS identification codes. Microsoft Project schedulers should note that only “Summary Tasks” are WBS elements, and, therefore, deliverables. If you are creating a schedule in Microsoft Project and want to display the WBS solely by itself then use the standard “Summary Tasks” filter in Microsoft Project.
Primavera P6 Professional is less confusing to the novice as it has a separate tab or view for simply displaying the WBS. Also, Primavera P6 only assigns WBS identification codes to WBS elements. So even when the WBS and associated activities are displayed in the same view in Primavera P6 it is easy to decipher the WBS elements from the associated activities.
Let’s take a quick look at an example WBS. Here we have in Figure 1 a WBS of a
“Repair and Improvement Underground Pipe System”.
Figure 1
Note that all the WBS elements are described by nouns. Some of them are interchangeable noun and verb depending on the meaning of the word. The goal, however, of using nouns and adjectives to describe the WBS elements is apparent. The lowest levels of the WBS hierarchy are decomposed deliverables; broken down to the point where you can begin to describe the activities (verbs) required to produce these deliverables. Remember! These activities are not apart the WBS. But they are closely associated with the WBS. The lowest elements of the WBS, again, support the definition or development of schedule work.
Summary
The WBS is an implicit contract, so it is important to clearly describe the WBS and nothing more or nothing less. The WBS is a hierarchical decomposition of the required scope to create the deliverables. Perhaps, the WBS should be thought of in terms as a ‘deliverable’ breakdown structure.
Think of the WBS as a model of the finished product and not a diorama of construction in process. Again, work packages are a confusing topic. They simply are the WBS element deliverable at such a level of decomposition that you may begin to consider the tasks required to produce those decomposed deliverables. These tasks, however, are separate from the WBS.
Microsoft Project schedulers may display the WBS by itself by utilizing the “Summary Tasks” filter. Primavera P6 has a separate tab or view displaying just the WBS for reporting purposes. Again, proper WBS development supports agreement on project end goals, which is one of five major factors leading to project success.
Quoted books
A Guide to the Project Management Body of Knowledge (PMBOK Guide), PMI, Fifth Ed.
Practice Standard for Work Breakdown Structures, PMI, Second Ed.
Forecast Scheduling with Microsoft Project 2010, Eric Uyttewall, PMP
The Fast Forward MBA in Project Management, Fourth Ed., Eric Verzuh