WBS Concepts

A WBS diagrams effort in small discrete pieces, or elements, to show how each element relates to the others and to the program as a whole. It can be thought of as an illustration of what work will be accomplished to satisfy a program’s requirements. Elements such as hardware, software, and data are further broken down into specific lower-level elements. The lowest level of the WBS is defined as the work package level. By breaking work down into smaller elements, management can more easily plan and schedule the program’s activities and assign responsibility for the work.

A WBS breaks down product-oriented elements into a hierarchical parent-child structure that shows how elements relate to one another as well as to the overall end product. A well-defined WBS clearly delineates the logical relationship of all program elements and helps promote accountability by identifying work products that are independent of one another. Failing to include all work for all deliverables can lead to schedule delays and subsequent cost increases. It can also result in confusion among team members.

A WBS is an essential part of developing a program’s cost estimate and enhancing an agency’s ability to collect data necessary to support future cost estimates. A WBS also facilitates establishing the schedule, cost, and earned value management (EVM) baseline. Its hierarchical nature allows the WBS to logically sum the lower-level elements that support the measuring of cost, schedule, and technical analysis in an EVM system. It also allows a program manager to more precisely identify which components are causing cost or schedule overruns and to more effectively mitigate the root cause of the overruns. Moreover, when appropriately integrated with systems engineering, cost estimating, EVM, and risk management, a WBS provides the basis to allow program managers to have a better view into a program’s status, facilitating continual improvement.

The number of levels in a WBS depends on a program’s complexity and risk. Work breakdown structures need to be expanded to a level of detail that is sufficient for planning and successfully managing the full scope of work. However, each WBS should, at the very least, include three levels. The first level represents the program as a whole and therefore contains only one element—the program’s name. The second level contains the major program segments and the third level contains the subsystems for each segment. These relationships are illustrated in figure 7, which depicts a simple construction WBS.

Figure 7: A Product-Oriented Work Breakdown Structure
Tip: Click the figure to view a larger version in a new browser tab.

In figure 7, all level 2 elements also have level 3 subcomponents. For some level 2 elements, level 3 is the lowest level of breakdown; for other level 2 elements, lower levels are required. The hierarchical parent-child relationship shows logical connections and relationships and leads to a better understanding of the technical effort involved. It also helps improve the ability to trace relationships within the cost estimate and EVM system.

In the example in figure 7, construction is a child of the house system but the parent of foundations and underground, house construction, and site work. In a WBS, the sum of a parent’s children must equal the parent. Thus, in figure 7, the sum of framing, exterior finishes, interior rough-in, and interior finishes must be equal to the level 3 parent house construction. In this way, the WBS ensures that each element is defined and related to only one work effort.

Case study 8 highlights problems that can occur when this best practice is not followed.

Case Study 8: Program Level Work Breakdown Structure, from Plutonium Disposition Program, GAO-14-231

The Department of Energy’s (DOE) National Nuclear Security Administration (NNSA), a separately organized agency within DOE, manages the Plutonium Disposition program to dispose of surplus weapons-grade plutonium by burning it as mixed oxide (MOX) fuel—a mixture of plutonium and uranium oxides—in specially modified commercial nuclear reactors. In 2012, DOE forecasted cost increases of close to $3 billion over the previous estimates for the program’s two construction projects, the MOX facility and the Waste Solidification Building (WSB) for disposing of waste from the MOX facility. GAO was asked to review these cost increases and the life cycle cost estimate

GAO’s assessment of NNSA’s process for developing its draft life cycle cost estimate found, in part, that the estimate was only partially comprehensive. GAO found that work breakdown structures were developed for the MOX and WSB projects and other components of the program, but that NNSA had not formalized a program-level work breakdown structure. A typical work breakdown structure provides a clear picture of what needs to be accomplished, how the work will be done, and a basis for identifying resources and tasks for developing a cost estimate. Without a program-level work breakdown structure, NNSA could not ensure that its life cycle cost estimate captured all relevant costs, which could lead to cost overruns.

GAO recommended that to identify lessons learned from and provide assurance of preventing recurrence of cost increases for the MOX facility and WSB, and to develop reliable cost estimates for the Plutonium Disposition program, the Secretary of Energy should direct the DOE and NNSA Offices of Acquisition and Project Management and the NNSA office responsible for managing the Plutonium Disposition program, as appropriate, to revise and update the program’s life cycle cost estimate following the 12 key steps described in the GAO Cost Estimating and Assessment Guide for developing high-quality cost estimates, such as conducting an independent cost estimate to provide an objective and unbiased assessment of whether the estimate can be achieved. In 2017, NNSA directed its Office of Cost Estimating and Program Evaluation to develop a new life cycle estimate for the plutonium disposition program based on NNSA’s preferred approach of dilute and dispose. That estimate was completed in March 2018. The estimate was directed to be done in accordance with GAO cost estimating and assessment best practices.

GAO, Plutonium Disposition Program: DOE Needs to Analyze the Root Causes of Cost Increases and Develop Better Cost Estimates, GAO-14-231 (Washington, D.C.: February 13, 2014).

A WBS may sometimes be organized by function rather than by product. A functional WBS categorizes effort by activities or processes, such as manufacturing, engineering, or quality control. But because a product-oriented WBS reflects cost, schedule, and technical performance on specific portions of a program, it represents a cost estimating best practice. For example, an overrun on a specific item in figure 7 (for example, framing) might cause program management to change a specification, shift funds, or modify the design. If the WBS was functionally based—for example, organized by carpenters instead of framing—then management would not have the right information to get to the root cause of the problem. Hence, elements at the second or third level of the WBS should be structured according to products or deliverables. Examples of elements that are not products are:

  • design engineering, requirements analysis, logistics, risk, quality assurance, and test engineering (all functional engineering efforts), aluminum stock (a material resource), and direct costs (an accounting classification);14

  • types of funds used in program acquisition phases (for example, research, development, test, and evaluation);

  • rework, retesting, and refurbishing, which should be treated as activities of the WBS element;

  • nonrecurring and recurring classifications, for which reporting requirements should be structured to ensure that they are segregated;

  • cost saving efforts—such as total quality management initiatives and acquisition reform initiatives—included in the elements they affect them, not captured separately;

  • the organizational structure of the program office or contractor;

  • the program schedule—instead the WBS will drive the necessary schedule activities;

  • meetings, travel, and computer support, which should be included in the WBS elements they are associated with;

  • generic terms (terms for WBS elements should be as specific as possible); and

  • tooling—that is, special equipment needed to produce, handle, or assemble an item—which should be included with the equipment being produced.

While functional activities are necessary for supporting a product’s development, the WBS should not be organized around them. Moreover, a WBS dictionary should state where the functional elements fall within the products and how the statement of work elements come together to make specific products.15 A WBS dictionary is a document that describes in brief narrative format what work is to be performed for each WBS element.

  1. When following the product-oriented best practice, there should not be WBS elements for various functional activities like design engineering, logistics, risk, or quality, because these efforts should be embedded in each activity.↩︎

  2. In addition to product-oriented and functional breakdown structures, costs may be categorized in a cost element structure (CES) that groups costs by system or appropriation.↩︎