Developing and elaborating effective work breakdown structures
Today, project managers are more frequently finding high value in the creation of work breakdown structures (WBSs) as they begin the process of project management. Project success may be attributed specifically to use of a WBS (Halli, 1993).
As an essential element of the Planning Process Group outlined in A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (Project Management Institute, 2004), everyday practice is revealing with increasing regularity that creation of a WBS to define the scope of the project will help ensure delivery of the project's objectives and outcomes.
Moreover, the more clearly the scope of the project is articulated before the actual work begins, the more likely the success of the project—“…the intelligent structure of work breakdowns is a precursor to effective project management” (Homer & Gunn, 1995, p. 84). Specifically, the Planning Process Group begins with three essential steps—Scope Planning (184.108.40.206), Scope Definition (220.127.116.11), and Work Breakdown Structure Development (18.104.22.168) (PMI, 2004). The following discussion will examine the current trends and practice regarding work breakdown structures.
It is widely written that work breakdown structures are fundamental building blocks for project management practice. There are many writings on the subject, here are a but a few key examples:
- Harold Kerzner writes: “The WBS provides the framework on which costs, time, and schedule/performance can be compared against the budget for each level of the WBS” (Kerzner, 1997, p. 791).
- From the PMBOK® Guide:
The WBS is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team, to accomplish the project objectives and create the required deliverables… The WBS represents the work specified in the current approved project scope statement. Components comprising the WBS assist the stakeholders in viewing the deliverables of the project. (PMI, 2004, p. 112)
- Dr. Gregory T. Haugan: “The WBS is the key tool used to assist the project manager in defining the work to be performed to meet the objectives of a project” (Haughan, 2002, p. 15).
- Carl L. Pritchard: “… the WBS serves as the framework for project plan development. Much like the frame of a house, it supports all basic components as they are developed and built” (Pritchard, 1998a, p. 2).
The Importance of the WBS
Experienced project managers know there are many things that can go wrong in projects regardless of how successfully they plan and execute their work. Component or full-project failures, when they do occur, can often be traced to a poorly developed or nonexistent WBS. A poorly constructed WBS can result in adverse project outcomes, including ongoing, repeated project re-plans and extensions, unclear work assignments, scope creep, or unmanageable, frequently changing scope, budget overrun, missed deadlines, and unusable new products or delivered features.
The WBS is a foundational building block to initiating, planning, executing, and monitoring and controlling processes used to manage projects as they are described in the PMBOK® Guide. Typical examples of the contribution the WBS makes to other processes are described and elaborated in the Practice Standard for Work Breakdown Structures (PMI, 2006).
To explain, there are many project management tools and techniques that use the WBS or its components as input (PMBOK® Guide, Section 5.3). For example, the WBS uses the Project Charter as its starting point. The high-level elements in the WBS should match, word-for-word, the nouns used to describe the outcomes of the project in the Scope Statement. In addition, the Resource Breakdown Structure (RBS) describes the project's resource organization, and can be used with the WBS to define work package assignments. The WBS Dictionary defines, details, and clarifies the various elements of the WBS. The Network Diagram is a sequential arrangement of the work defined by the WBS, and the elements of the WBS are starting points for defining the activities included in the Project Schedule.
The WBS is used as a starting point for scope management and is integral to other PMI processes, and as a result, the standards that define these processes explicitly or implicitly rely on the WBS. Standards that take advantage of the WBS either use the WBS as an input (e.g., PMI's Practice Standard for Earned Value Management (EVM) and Practice Standard for Scheduling) or incorporate the WBS as the preferred tool to develop the scope definition (for example, the PMBOK® Guide and Organizational Project Management Maturity Model).
A WBS, as defined in the PMBOK® Guide, is
a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the project work. The WBS is decomposed into work packages. The deliverable orientation of the hierarchy includes both internal and external deliverables. (PMI, 2004)
With this definition, it is clear the WBS provides an unambiguous statement of the objectives and deliverables of the work to be performed. It represents an explicit description of the project's scope, deliverables and outcomes—the “what” of the project. The WBS is not a description of the processes followed to perform the project, nor does it address the schedule that defines how or when the deliverables will be produced. Rather, it is specifically limited to describing and detailing the project's outcomes or scope. The WBS is a foundational project management component, and as such is a critical input to other project management processes and deliverables such as activity definitions, project network diagrams, project and program schedules, performance reports, risk analysis and response, control tools, or project organization.
Defining the WBS
The upper levels of the WBS typically reflect the major deliverable work areas of the project, decomposed into logical groupings of work. The content of the upper levels can vary, depending on the type of project and industry involved. The lower WBS elements provide appropriate detail and focus for support of project management processes such as schedule development, cost estimating, resource allocation, and risk assessment. The lowest-level WBS components are called work packages and contain the definitions of work to be performed and tracked. These can be later used as input to the scheduling process to support the elaboration of tasks, activities, resources and milestones, which can be cost-estimated, monitored, and controlled.
A few of the key characteristics of high-quality work breakdown structures (PMI, 2006) are outlined below:
- A central attribute of the WBS is that it is “deliverable orientated” (Berg & Colenso, 2000). The PMBOK® Guide defines a deliverable as “any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase or project” (PMI, 2004). In this context, “oriented” means aligned or positioned with respect to deliverables, that is, focused on deliverables.
- An additional key attribute of the WBS is that it is a “hierarchical decomposition of the work” (PMI, 2004). Decomposition is
a planning technique that subdivides the project scope and project deliverables into smaller, more manageable components, until the project work associated with accomplishing the project scope and deliverables is defined in sufficient detail to support executing, monitoring, and controlling the work. (Ibid.)
This decomposition (or subdivision) clearly and comprehensively defines the scope of the project in terms of individual sub-deliverables that the project participants can easily understand. The specific number of levels defined and elaborated for a specific project should be appropriate for effectively managing the work in question.
- The 100% Rule (Haugan, 2002, p. 17) is one of the most important principles guiding the development, decomposition and evaluation of the WBS. This rule states that the WBS includes 100% of the work defined by the project scope and, by doing so, captures ALL deliverables—internal, external, and interim— in terms of work to be completed, including project management. The rule applies at all levels within the hierarchy: the sum of the work at the “child” level must equal 100% of the work represented by the “parent”—and the WBS should not include any work that falls outside the actual scope of the project; that is, it cannot include more than 100% of the work.
- The WBS can be represented in a variety of ways, including graphical, textual, or tabular views. The form of representation should be chosen based on the needs of the specific project. Exhibits 1 through 3 below illustrate the very same WBS elements represented in Outline View format (Exhibit 1), Tree or Organization Chart format (Exhibit 2), and in the Centralized Tree format (Exhibit 3):
Exhibit 1 – Outline View
Exhibit 2 – Tree Structure, or “Organizational Chart” Structure
Exhibit 3 – Centralized Tree Structure
It is clear the WBS is the starting point in the planning process for many other essential project management processes such as estimating, scheduling and monitoring/controlling. However, applying the WBS effectively to these processes remains a difficult task for many project managers.
Transitioning from the Deliverable-Oriented WBS to the Project Schedule
Frequent complaints about the relevance of deliverable-oriented work breakdown structures are attributed to the absence of clear guidance about the methodology used to apply this scope definition to other project processes, tools, and tasks.
In particular, the lack of helpful information about the processes used to apply deliverable-oriented work breakdown structures to project scheduling is seen as the primary obstacle project managers face when attempting to use deliverable-oriented work breakdown structures as a basis for scope management and schedule development. The difficulty they encounter making the logical association and transition from WBS to project schedule, drives their reluctance to adopt the practice. In fact, much of the available documentation (for example, Pritchard, 1998b) for applying work breakdown structures to project scheduling actually suggests developing “task-oriented” or “processoriented” work breakdown structures to ease the transition from WBS to project schedule.
Demystifying Linkages Between the Deliverable-Oriented WBS and Project Schedule
To correct and counter this confusing instruction, key guidance to assist project managers can be found in the PMBOK® Guide, Chapter 6 (PMI, 2004). This chapter, Time Management, contains much of the information required to explain and resolve the deliverable-oriented WBS-to-Project Schedule transition challenge. Though somewhat obscured by other important concepts presented in this chapter, the core elements that show the linkage between the deliverable-oriented WBS and the project schedule are present. From this chapter I have extracted here the elements that explain the transition. Activity Definition, section 6.1; Activity Sequencing, Section 6.2, and Project Schedule Development, section 6.5 are examined next in detail and contain, specifically, the fundamental concepts required to simplify the process.
- Activity Definition (section 6.1) describes the inputs, tools, techniques, and outputs necessary to create the listing of activities that will be performed to produce desired project outcomes. The Project Time Management Overview (Figure 6-1, page 140) and the detail found in this section clearly show the Scope Statement, WBS, and WBS Dictionary as inputs to the Activity Definition process. Tools for development of the Activity List, Milestone List, and remaining outputs of the process include Decomposition, Rolling Wave Planning and others. Illustrated simply, this can be described as:
- Activity Sequencing (section 6.2) explains how the project's activities, milestones, and approved changes are used as inputs to the activity sequencing process, while the tools for developing the outputs are described, including the Project Schedule Network Diagram, updated Activity and Milestone Lists, include various network diagramming techniques, such as Precedence Diagramming Method (PDM) and Arrow Diagramming Method (ADM). As above, a simplified view would be:
- Schedule Development (section 6.5) describes how these two processes are used to produce the end objectives of the process—the Project Schedule, Schedule Model, Schedule Baseline, and other related schedule components. Here, the chapter explains how the outputs of the two processes above are incorporated as inputs to the scheduling tools and scheduling methodologies to produce the project schedule. Simplified, this can be illustrated as:
Summarizing the information found in these sections:
- The core elements that enable the elaboration and development of the Project Schedule begin with the Scope Statement, WBS, and WBS Dictionary.
- These inputs are taken through a decomposition process to produce the project's Activity and Milestone Lists.
- These in turn, are input elements to Network Diagramming, which produces the Project Schedule Network Diagram and updated Activity/Milestone Lists.
- Finally, the Project Schedule Network Diagram and Updated Activity and Milestone Lists are then used as input to the project scheduling tools and methodology to generate the Project Schedule. Illustrated in simplified process-flow form as before, the entire process can be summarized as follows:
And again, this simplified view in block diagram form:
Exhibit 4 – WBS to Project Schedule Transition
Putting These Concepts to Work
To illustrate how this process would be put into practice, a simple example will be used. We will assume for this discussion that the WBS elements listed in the outline below are a few of the key scope components derived from an initial home-building contract. Representing level 1, 2, 3 and 4, the high-level scope elements include the components of the primary structure, the foundation, exterior walls, roof, plumbing, electrical, and interior walls. The component element list, without hierarchical structure, appear to the project manager (from the contractor) as:
- House Project
- Primary Structure
- Foundation Development
- Layout – Topography
- Cement Pour
- Exterior Wall Development
- Roof Development
- Electrical Infrastructure
- Plumbing Infrastructure
- Inside Wall Development: Rough Finish
The WBS in Hierarchical Outline Form
To organize this component list as it might be developed, the contractor might arrange this work in a hierarchical relationship. For this example, we will presume this work is truly the correct representation. Working with the contractor, the project manager, then, would arrange the high-level deliverables for the House Project in the following manner:
Exhibit 5 – House Project WBS Elements – An Illustration
In Exhibit 5, level 1 indicates that the work called “House Project” represents 100% of the work of the project. All other scope (WBS) elements associated with the project would be subordinate to the House Project element. At level 2, there are four major components that make up the House Project: Primary Structure, Electrical Infrastructure, Plumbing Infrastructure and Inside Wall Development. Level 3 shows the key components of the Primary Structure: Foundation Development, Exterior Wall Development, and Roof Development. And finally the Foundation Development is decomposed into three work elements in level 4: Layout – Topography, Excavation, and Cement Pour.
Granted, this is a highly simplified characterization of the work. It is used here, however, to help illustrate the WBS hierarchical concept, not necessarily the proper breakdown of all the work required to construct a home.
Identifying Dependencies between WBS Elements
Looking at this particular breakdown of the work, contractors, project managers, and homeowners alike would probably recognize that if this were the work to be completed, it would occur in a prescribed order, with some elements coming before—and being completed – before others begin. For example, it would be very helpful to build the foundation and walls before constructing the roof. Though it isn't mandatory to do it in this way – building the foundation first and then the walls – establishing this order would allow the roof to be constructed on top of the walls, where it will ultimately be completed and integrated to secure the structure. Certainly this is not the only approach to home construction, and the order can surely be modified to accelerate the building process, but for this illustration, we will presume a traditional home construction project, and the order would be: foundation, exterior walls, then roof.
Once the foundation, walls, and roof are completed (and assuming additional details such as windows, doors, and exterior finish are part of the work), the construction can move to the interior of the home. Here, it would make sense to complete the electrical and plumbing work before putting the interior wall material in place. As before, this order is not mandatory, but common practice would indicate the simplest, quickest, and easiest approach would be to first complete the work that would be hidden by the interior walls, then apply the interior wall material. Again, for this example, we will use that convention.
Creating a High-Level Network Diagram
With the above discussion in mind, a project manager could begin developing a very high-level network diagram representing the work described by the scope (WBS)—using nothing more sophisticated than pencil and paper—to illustrate the dependencies described above. Beginning with the “House Project” element at level 1, and including all of the remaining WBS elements described above, one representation of the work might look like this network:
Exhibit 6 – House Project High-Level Network Diagram
Exhibit 6 shows how the project manager would use the network diagram to indicate that Foundation Development (Layout, Excavation, and Cement Pour) must complete before the Exterior Wall Development can begin—and that Roof Development depends on the completion of the Exterior Walls. Once the roof is complete, both Plumbing and Electrical can begin, but the Interior Walls would not start until Plumbing and Electrical are complete (in reality, the word “complete” here could mean “roughed-in,” where wires and pipes are run to and from their destinations, but there are no fixtures attached to them). It is important to note, the work elements shown here are not tasks or activities, but rather significant scope components that logically lead and follow one another. Once these elements are placed into the project scheduling tool, they can be further decomposed from their work packages into appropriate tasks and milestones.
Creating the Project Schedule from the WBS Element List and Network Diagram
Exhibit 7 shows an excerpt from the project constructed using a common project scheduling tool. Clearly shown in the left columns are the line numbers for each of the WBS elements, the WBS hierarchical numbering scheme for each of the WBS elements, and the WBS element names from the project. In this example, the project manager referenced the network diagram (Exhibit 6) to create the dependencies described in the network. The hierarchical relationships have been established to reflect the interrelationships between the components as well as the dependencies described above.
Exhibit 7 – House Project High-Level Schedule
In this way, the project manager is able to use a stepwise process to create the linkage between the deliverable-oriented WBS and the project schedule. As discussed above, a clear path can be drawn from deliverable-oriented WBS to project schedule, if that path is taken through the network diagramming process. To recap the concept, in Exhibit 4 it is simply stated as:
Taking the Process One Step Further—Introducing the Scope Relationship Diagram
To further ease the transition from the deliverable-oriented WBS to project schedule, we can refine the central process to more clearly illustrate the relationships between scope elements—before they are placed into the project schedule.
In Exhibit 6, a network diagram was created to show dependency between various WBS elements. In this illustration, each element is shown in linear fashion, using a two-dimensional sequential format, with lines connecting the elements to show predecessor and successor dependencies. To produce the network diagram, the two dimensions at the core of the process are order and precedence (or dependency). While these two dimensions are critically important to developing a network diagram, in some cases they are not sufficient to enable the project manager to easily envision the project schedule from the network diagram.
Absent from this linear depiction of scope is the addition of a third dimension to compliment order and dependency. To clarify—the concept/dimension of inclusion can be inserted into the process to convert the linear, two-dimensional network into a diagram that would depict how individual WBS elements are related to one another, as parent and subordinate elements, reflecting graphically how they are developed and listed in an outline, chart, or WBS template.
“Inclusion” as a dimension is used to show which elements are “part of” larger work elements, as well as clearly articulating which WBS elements are not “part of” the work of others. Said another way, some work depicted by a WBS is intended to be seen as being “part of” a higher-order work element, while other elements in the WBS are clearly not “part of” specific higher-order elements.
Using the example from the House Project above, we will take another look at the hierarchical outline for the work:
Describing this outline using the concept of “inclusion,” it is easy to see that the WBS Elements 1.1, 1.2, 1.3 and 1.4—the Primary Structure, Electrical Infrastructure, Plumbing Infrastructure, and Inside Wall Development—are all “part of” the House Project. They are integral to the completion of the project and are “included in” the work. By the same token, it is clear from the outline that the elements 22.214.171.124, 126.96.36.199 and 188.8.131.52 are all “part of” and “included in” the work that makes up Foundation Development, WBS element 1.1.1.
Our network diagram in Exhibit 6 shows the precedence and dependency between these elements, but does not clearly show which elements are actually “part of” the scope of other elements. To explain, we will examine the Foundation Development elements closely.
In Exhibit 6, the Foundation Development elements at level 4—Layout – Topography, Excavation, and Cement Pour—were reflected as a series of scope elements executed in sequential fashion, under the “parent” element Foundation Development at level 3. Here is the excerpt:
Exhibit 8 – Foundation Development Graphic from House Project
In this excerpt, its difficult to clearly see the relationship between the parent and children WBS elements—other than the fact that the three elements at level four are children of the parent element “Foundation Development.” In truth, the relationship between the Foundation Development element at level 3 and its children at level 4 is more clearly shown in the textual, outline form:
Exhibit 9 – Foundation Development Outline from House Project
The outline form of the same elements shows that Layout – Topography, Excavation, and Cement Pour are actually “part of” and “included in” the work that is called Foundation Development. Showing this in graphic format using an alternative view may help somewhat, but does not fully clarify the relationship between the parent and child elements:
Exhibit 10 – Alternate Foundation Development Graphic from House Project
To solve and illustrate how these relationships actually occur, a Scope Relationship Diagram will be used instead to clearly show the relationships detailed in the outline version in Exhibit 9, as well as the order and precedence shown in Exhibit 8. The resulting Scope Relationship Diagram of the same elements would appear as follows:
Exhibit 11 – Scope Relationship Diagram from House Project Foundation Development Segment
In this Scope Relationship Diagram representation, the Foundation Development WBS element 1.1.1 is larger and visually includes the lower level elements 184.108.40.206, 220.127.116.11, and 18.104.22.168. Here, it is clear that the three elements at level 4 are executed in sequence “within” or as “part of” the scope of the parent element, Foundation Development.
Expanding this concept further to include all of the elements in the House Project, a Scope Relationship Diagram showing the work defined in the outline presented in Exhibit 9 would produce the following graphic:
Exhibit 12 – Scope Relationship Diagram for House Project
Once complete, the Scope Relationship Diagram for the House Project enables visualization of the work “included” within the scope of each parent WBS element and allows a more direct and straightforward transition from deliverable-oriented WBS to project schedule.
The process for developing and elaborating effective work breakdown structures begins with a thorough analysis of scope documents. Applying a carefully articulated WBS and WBS Dictionary to subsequent project processes further uses tools such as the Network Diagramming technique or Scope Relationship Diagram development, and results in the creation of a baselined Project Schedule, drawn from the decomposition of Work Packages, which reveals key project tasks, activities, and milestones.
An effective work breakdown structure:
- Is a deliverable-oriented grouping of project elements
- Is created by those doing the work
- Contains 100% of the work defined by the scope or contract and captures all deliverables (Internal, External, Interim) in terms of work to be completed, including project management
- Defines the context of the project, clarifies the work, and communicates project scope to all stakeholders
- Is expressed as a chart or outline, providing a graphical or textual breakdown
- Arranges all major and minor deliverables in a hierarchical structure, and is constructed so that each level of decomposition contains 100% of the work in the parent level
- Should contain at least 2 levels
- Uses nouns and adjectives, not verbs
- Evolves along with the progressive elaboration of project scope, up to the point of scope baseline, and thereafter in accordance with project change control, allowing for continual improvement
- Employs a coding scheme for each WBS element that clearly identifies the hierarchical nature of the WBS when viewed in any format
To develop work breakdown structures, the project manager should take the guidance provided here and apply WBS construction activities independently of the project schedule or scheduling tools. To do this, the project manager will reference a set of key documents to begin developing the WBS. These include:
- The project charter
- The project problem statement or scope definition
- Applicable contract or agreement documentation
- Existing project management practice
Armed with these documents as the basis for WBS development, the project manager will guide the project team through the development of a deliverable-oriented WBS, carefully relating all WBS elements to these foundational documents and associating work described by the WBS to specific scope boundaries defined by them. These activities are typically performed by engaging the entire project team in “brainstorming” or “idea-generation” sessions, using affinity diagramming techniques and iterative decomposition to define the WBS elements—all independent of the project scheduling tool.
Once complete, the WBS is placed under “Change Control” and will be managed in accordance with the Chang Management processes defined for the project, allowing for the expected and inevitable change that will impact the scope of the project. When these changes occur, they are reflected not only in the project schedule, but are documented as addendum or changes to the Scope Statement, Charter, contract, agreements, and, of course, the WBS.
In this way, the project manger will have constructed a work breakdown structure that directly links to sponsoring documents and provides a basis for project schedule and process management, yet is designed to grow and flex with the changes that impact the project in a controlled and controllable manner.
Chapman, James R. (2004, November). Work breakdown structure (WBS). Retrieved February 22, 2005 from http://www.hyperthot.com/pm_wbs.htm
Haugan, Gregory T. (2002). Effective work breakdown structures. Vienna, VA: Management Concepts.
Kerzner, H. (1997). Project management: A systems approach to planning, scheduling, and controlling (6th ed.). New York: John Wiley & Sons.
Macdonald Bradley, Inc. (2002, December). Independent verification and validation (IV&V) white paper. Retrieved February 20, 2005 from http://www.mcdonaldbradley.com/MBI_TECHNOLOGY.asp?a=independent%22
Pritchard, Carl. (1998a). How to build a work breakdown structure, the cornerstone of project management. Arlington, VA: ESI International.
Pritchard, Carl. (1998b). Rational unified process. Available at http://www.ts.mah.se/RUP/RationalUnifiedProcess/manuals/intro/im_diff.htm
Project Management Institute. (2006). Practice standard for work breakdown structures (2nd Ed.). Newtown Square, PA: Project Management Institute.
Project Management Institute. (2004). Project management body of knowledge (PMBOK® Guide) (2004 Ed.). Newtown Square, PA: Project Management Institute.
U.S. Department of Energy. (2001, August). Performance based contracting: Development of a work statement. Retrieved January 18, 2005 from http://www1.pr.doe.gov/acqguide/AGChapter37.htm
© 2007, Eric S. Norman, PMP, PgMP
Originally published for the 2007 PMI Global Congress Proceedings – Atlanta, GA, USA