Chapter 1

INTRODUCTION TO THE WORK BREAKDOWN STRUCTURE

The work breakdown structure (WBS) plays a critical role in the project management process. To fully grasp the concept and application of the WBS—and why a work breakdown is so important—a basic understanding of project management terms and definitions is essential. A brief history of the evolution of the WBS will also help the government manager understand how the WBS fits into the overall project management process and appreciate the role of the WBS in public and private-sector projects.

PROJECT MANAGEMENT TERMS AND DEFINITIONS

Project management as a field of study has a set of acknowledged terms and definitions. The following are the key terms commonly used in the project management field. Selected terms are presented in Figure 1-1.

THE PROJECT PROBLEM AND SOLUTION

Starting a new project is like starting to write a report—you have an idea of what you want to do but are not sure how to start. Many writers, like many project planners and managers, find that outlining is the most effective first step in writing.

An outline is a method for organizing material as well as a plan for the report itself. But when you start outlining a report, especially an extensive report (e.g. based on doing research by collecting data on the subject), you realize there are many ways to do it. In general, you need to plan your research or data-gathering; decide what goes in each chapter, including appendices; and take into account the time it will take to draft chapters, get reviews, and carry out the other steps involved in reviewing proofs and publishing the document. In the government, a significant amount of time needs to be scheduled for internal reviews and rewrites. Of course, many projects are much more complex than writing a report.

So where do you start? A frequently used analogy for any large project is the old question, “How do you eat an elephant?” The answer is, “One bite at a time.” Let’s look a project where we “eat” an elephant. The first step in preparing an outline or planning a project is to start defining and categorizing the “bites” (activities). The bites are important because they are where the useful work is accomplished. For a project, brainstorming can help define the bites from the bottom up. Alternatively, a process of decomposition can be used, subdividing the project (in this case, the elephant) into major sections starting from the top and working down, as shown in Figure 1-2. In either approach, the objective is to develop a structure of the work that needs to be done for your project.

The parts of the elephant can clearly be broken down (or subdivided) further. For example, the head is made up of a face, ears, tusks, and trunk; the four legs can be individually identified; other body parts can also be identified, as can the tail and tuft. A WBS for a project is an outline of the work; it is not the work itself. The work itself is the sum of the many activities that make up the project.

A WBS can be started as an informal list of activities, or it can be highly structured, depending on the project and its constraints as well as the planner’s skills. It can end at whatever level of detail the planner wants it to end. The goal is to have a useful framework that helps define and organize the work.

In developing an outline for a report, for example, some things happen almost automatically, growing out of the discipline of the process. The first is that you limit the contents of the report; there is a beginning and an end, with the contents in between. Preparing an outline of the contents forces you to define the topics, sections, chapters, and parts of the report. The same thing happens when you develop a WBS of a project. You consider assumptions and constraints, often without focusing on them directly.

Once you complete the detailed outline of a report, you have also defined the scope of the project to prepare the report, especially when the outline is annotated (as it should be). The same thing happens in a project. An annotated WBS becomes an initial scope description. This is logical and elementary: If the outline (WBS) addresses all the work, then all the items described in the outline delineate all the work or the scope of the project.

Developing the WBS is an easy four-step process:

Step 1. Specify the project objectives, focusing on the products, services, or results that are to be provided to the customer.

Step 2. Identify specifically all the products, services, or results (deliverables or end items) to be provided to the customer to meet the project objectives and organize them in a hierarchical framework.

Step 3. Identify other work that needs to be performed in the project, making sure that 100 percent of the work is covered. Specifically, identify work that (a) cuts across deliverables or is common to the deliverables (cross-cutting elements), (b) represents intermediate outputs, or (c) complements the deliverables.

Step 4. Subdivide each of the work elements identified in the previous steps into successive logical subcategories until the complexity and dollar value of the elements become manageable units (work packages) for planning and control purposes.

A typical WBS for our simple project with report is shown in Figure 1-3.

In the early phases of a project, it may be feasible to develop only a two- or three-level WBS because the details of the work may not yet be defined. This is typical when the work is to be contracted out or outsourced. As the work on the project progresses into the project definition phase, the planning becomes more detailed and the WBS also becomes more detailed. The subdivisions of the WBS can be developed to successively lower levels at that time. Or the government may want to specify only the first two or three levels and then let the contractor specify the lower levels in a contract WBS (CWBS).

The final subcategories or work packages created in step 4 are the detail elements. These are the bites we are going to use to “eat the elephant one bite at a time”—that is, to perform the project work. The product of this decomposition or breakdown process is the completed WBS.

The following example demonstrates how to begin developing a WBS using the four-step process in a project to build a garage: ²

Step 1. Specify the project objectives: Build a one-car garage with landscaping on the existing lot; the garage should have internal and external lighting and plumbing.

Step 2. Identify specifically the products, services, or results (deliverables or end items) and agree on a hierarchical framework: The final products are the garage and the landscaped grounds.

Step 3. Identify other work areas to make sure that 100 percent of the work is identified: A project management function is needed to perform tasks like planning construction, obtaining permits, and awarding subcontracts.

Level 1 is the total project and Level 2 is the first subdivision of the work into the final products (a garage and landscaped grounds) plus “cross-cutting” work elements (work elements whose products apply to several work elements) needed for the project, such as the project management function. The total scope, 100 percent of the project work, is represented by the sum of the work in the three Level 2 elements.

Step 4. Subdivide the elements until a level is achieved that is suitable for planning and control. The subdivision of each Level 2 element shown in Figure 1-4 is shown in Level 3 of Figure 1-5.

A further breakdown of some of the Level 3 elements could be performed. The complete WBS to the work-package level (which is adequate for planning and control) is shown in Figure 1-6. The work package level is defined as the lowest level of each branch of the WBS; therefore, a work package may be at the overall Level 3 or 4, depending on the decomposition of the specific branch. The next level below the work packages is where the activities or tasks are performed.

In Figure 1-6, the WBS is presented in outline format rather than the space-consuming graphic format usually used. Either format is acceptable; the outline format is used when entering WBS data into project management software packages or to save space in documents.

The individual tasks or activities are located at the first level below the work packages and are not normally considered part of the WBS. In fact, one of the primary purposes of the WBS is to provide a framework that helps you define the activities of the project. When the WBS is complete, it covers the total scope of the project.

Figure 1-7 is the same WBS in an alternate depiction of the “organization chart format.” It was prepared using WBS Chart Pro, a software package designed to help develop a WBS and then seamlessly transfer it to MSProject® software to develop the schedule.

For this display, the WBS numbers were added automatically by the software.

This mention of scope brings up a very important project management principle: Work not included in the WBS is outside the scope of the project. For example, in Figure 1-6, no heating, ventilation, and air conditioning (HVAC) system is shown; therefore, HVAC is not part of the project.

After the WBS is established, it must be maintained and updated to reflect changes in the project. The configuration and content of the WBS—and the level of detail of the work packages—vary from project to project depending on several considerations, including the following:

•  Size and complexity of the project

•  Culture of the enterprise

•  Structure of the organizations involved

•  Phase of the project (conceptual, planning, implementation, operations)

•  Natural physical structure of the deliverable items

•  Project manager’s judgment of work allocations to subcontractors

•  Degree of uncertainty and risk involved

•  Time available for planning.

The WBS is an excellent tool to use for communicating the scope of a project or proposed scope in an understandable form to the project team and other stakeholders. At the end of the planning phase, the plans and schedules are frozen or “baselined” and become the basis for executing the work of the project. At the same time, the WBS is baselined and becomes one of the key mechanisms for change management. Proposed work that is not in the WBS needs to be added to the project and to the WBS through formal change control processes.

Figures 1-8 and 1-9 show examples of WBSs that focus on the output products or deliverables of the project.

Figure 1-8 is a WBS for an aircraft project in which a passenger aircraft was converted into a freighter (by a government contractor). The output products are a certified-airworthy converted aircraft, technical manuals, and a list of spare part requirements.

This WBS contains a cross-cutting work element labeled “system engineering” that encompasses the work necessary to define the conversion. It is considered cross-cutting because the work performed applies to or affects all or most of the other WBS elements at the same WBS level; thus, it “cuts across” other WBS elements. The WBS element system engineering is present in most WBSs involving engineering development. “Project management” is a common cross-cutting WBS element in all WBSs.

Figure 1-9 presents a WBS for a generic government software development project where the goals and objectives are specified. The primary deliverable is the software itself; the secondary deliverables are the training materials and the user documents. The software system also has a cross-cutting work element labeled “system analysis,” which represents work such as project definition, workflow analyses, and structured analyses.

The WBS can be used, in whole or in part, to make work assignments, issue budgets, authorize work, provide the basis for other data organization schemes, and explain the scope and nature of a project. Projecting the WBS on a screen at a meeting greatly facilitates the explanation of many aspects of the project and helps people who are newly assigned to the project understand the major work elements.

Responsibilities are normally assigned at the lowest WBS level, such as “coding” and “test” in Figure 1-9. The WBS serves as a common focal point for presenting the totality of a project. Note that the WBS is not an organization chart, even though its hierarchical structure is similar to that of an organization chart.

THE WBS IN THE PROJECT MANAGEMENT PROCESS

Managing projects is a continuous process. Figure 1-10 shows the ten steps in the basic project management process. That process focuses on achieving the project objectives within the project management triad of time-cost-quality constraints and goals.

Each of the steps in the basic project management process has a specific output that is defined and documented. The steps are frequently iterative; circumstances that arise during specific steps may require revision of earlier steps and then repetition of all or part of the steps that follow the revised step. This constant iteration/replanning characterizes the day-to-day activities of the project manager and the project team.

Figure 1-10 shows the categorization of the basic project management process into five types of actions: initiation, planning, executing, controlling, and closing. The process of project management emphasizes the importance of planning before extensive project work begins and the importance of bringing the project to closure after all the work is done.

The WBS is the key tool in the planning phase, where the scope of work is defined, and at the completion of the planning phase, when the plan—including the WBS—is baselined. The WBS is involved in virtually every aspect of managing the project. Therefore, it is critical to prepare the WBS early and correctly.

FIGURE 1-10
Basic Project Management Process

BACKGROUND OF THE WBS CONCEPT

The WBS is not a new concept in project management. In 1961, a sample WBS was included in an article published within General Electric Corporation that explained the importance of a WBS in developing effective management control systems. ³

The program evaluation and review technique (PERT) and WBS concepts spread widely and swiftly once their efficacy was recognized in their use on the Polaris Submarine Program and other similar large multidiscipline and multicontractor systems. These management tools and their application, as developed between 1958 and 1965, are the basis for most of the project management body of knowledge in use today.

Current DoD Requirements

The Department of Defense (DoD) has been a major user of the WBS since its conceptualization. DoD has developed a standard for the use of the WBS to ensure commonality in certain types of projects and to use as a template.

DoD has a required standard for a WBS usage that is addressed in MIL-STD-881C, The Standard Practice Work Breakdown Structures for Defense Materiel Items. ⁴ This is the most recent version of the standard, which dates back to 1968 and is “based on the cooperative efforts of the military services with assistance from industrial associations.” Updates to the standard specifically address advances in technology and modifications of the acquisition process and incorporate new materiel items, developmental concepts, and approaches. The Department of Energy (DOE) also has a Work Breakdown Structure Handbook that “… provides suggested guidance and best practices on the development of product-oriented Work Breakdown Structures (WBS) that should be used by all projects within DOE to organize and subdivide total project work scope.” ⁵

The DoD standard (and the DOE handbook for project managers) presents instructions for effectively preparing, understanding, and presenting a WBS. It is intended to provide the framework for DoD program managers to define their programs’ WBSs and also provides direction to DoD contractors in their application and extension of a contract WBS. Section 1 provides general instructions and defines and describes the WBS. Section 2 provides instructions on how to develop a government program WBS. Section 3 provides contractor instructions for developing and implementing a contract WBS, and Section 4 addresses implementation of the CWBS. Section 5 provides a series of notes on various WBS issues. Other government agencies have similar documents, most of which are based on the DoD model.

Private-Sector Standards for the WBS

The lead in monitoring and documenting project management practices transitioned from the public to the private sector with the reductions in the space program, the end of the Cold War, and the rapid growth of the Project Management Institute (PMI).

PMI, a professional association of more than 600,000 members, through its conferences, chapter meetings, monthly magazine, and quarterly journal, provides a forum for discussion of the growth and development of project management practices. In August 1987, PMI published the landmark document, The Project Management Body of Knowledge. That document was revised and republished in 1996 as A Guide to the Project Management Body of Knowledge (the PMBOK® Guide). ⁶ It has been updated frequently, and the fifth edition was published in early 2013. The PMBOK® Guide reflects the experience gained in project management since the seminal work of DoD, NASA, other government organizations, and the aerospace industry in the 1960s. In addition to the standard PMBOK® Guide, a DoD version was published in 2003, ⁷ and a government version was published in 2006. A construction version is based on the 2000 PMBOK® Guide. (These are all available at www.pmi.org.)

In addition to the discussion of the WBS in the PMBOK® Guide, PMI has published the Practice Standard for Work Breakdown Structures, Second Edition, which is intended to be more universal in application than the comparable DoD Handbook. ⁸

THE WBS IN THE GOVERNMENT SECTOR VERSUS THE WBS IN THE PRIVATE SECTOR

In most respects, there is no difference in the use of the WBS on government and nongovernment projects. The principles are the same, whether the projects are performed in-house or are outsourced. The use of contractor or subcontractor labor to complement or supplement existing labor requires the same skills and tools that are required when performing the work in-house; the project manager must still manage day-to-day work performance to achieve project objectives within the time, resource, and quality constraints.

The use of the WBS is essential when major government projects must be approved by the Office of Management and Budget (OMB) or when the projects are to be contracted out and the government project manager must develop the work statement, specifications, schedule, and budget, as well as participate in the formal acquisition process. In addition, with the OMB requirement for use of the earned value management systems (EVMS), it is essential that an effective WBS be developed as a basic framework for an EVMS.

The government or large enterprise project manager frequently has two roles: (1) to plan and manage the work of the basic organization, and (2) to specify and manage the work of contractors or other organizations. Both roles require an effective WBS.

The fundamentals of developing a WBS can be applied to any project, whether the deliverable is a product, service, or result.

NOTES

 1. DoD and NASA Guide, PERT COST Systems Design (Washington, DC: Department of Defense and National Aeronautics and Space Administration, 1962).

 2. This garage WBS is a modified version of the building WBS presented in Appendix A, p. 33, of the Department of Energy, Office of Management, Work Breakdown Structure Handbook (Washington, DC: U.S. Department of Energy, 2012).

 3. Warren F. Munson, “A Controlled Experiment in PERTing Costs,” Polaris Projection (GE Ordnance Department, November 1961).

 4. Department of Defense, Standard Practice Work Breakdown Structures for Defense Materiel Items, MIL-STD-881C (Washington DC: Assistant Secretary of Defense, 2011).

 5. Department of Energy, Office of Management, Work Breakdown Structure Handbook (Washington, DC: U.S. Department of Energy, 2012), 1.

 6. Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 3rd ed. (Newtown Square, PA: Project Management Institute, 2004).

 7. Defense Acquisition University, U.S. Department of Defense Extension to: A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 1st ed., v. 1.0 (Fort Belvoir, VA: Defense Acquisition University Press, 2003).

 8. Project Management Institute, Practice Standard for Work Breakdown Structures, 2nd ed. (Newtown Square, PA: Project Management Institute, 2006).