Gregory T. Haugan (Author)
Publication date: 07/01/2013
The Government Manager’s Guide to the Work Breakdown Structure
GREGORY T. HAUGAN, PHD, PMP
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.
Activity: A defined unit of work performed during the course of a project that is described using a verb. An activity normally has a work description, expected duration, expected cost, and expected resource requirements. Activity and task are terms that are often used interchangeably.
Control account (CA): A specific WBS work element and functional organizational responsibility where the work in a work package is assigned and actual direct labor, material, and other direct cost data can be collected; formerly known as a cost account in earned value management systems.
Cross-cutting element: A WBS element that relates to work performed in other branches of the WBS. For example, the work performed in project management relates to other work in the project yet has its own unique identity.
Deliverable: Any tangible, verifiable product, service, or result that must be produced to complete a project or part of a project. The term is often used narrowly to refer to hardware or equipment, a report, software, data, or other items that are subject to approval by the project sponsor or customer.
End items: A general term that represents the hardware, services, equipment, facilities, and data that are deliverable to the customer or that constitute a commitment on the part of the project manager to the customer.
Organizational breakdown structure (OBS): A graphic representation of the work of a project in terms of organizational units.
Portfolio: A collection of related projects or programs and other work that groups projects or programs to support effective management of the total work effort in a way that meets strategic business or organizational objectives.
Program: A long-term undertaking consisting of a group of related projects that are managed in a harmonized way. Programs often include an element of ongoing work or work related to the program deliverables.
Project: A temporary endeavor undertaken to create a unique product, service, or result.
Project element: A component of the work to be performed in a project derived from the logical decomposition of the total work (top down) or synthesis of a logical grouping of required activities or work elements (bottom up).
Responsibility assignment matrix (RAM): A graphic structure that correlates the work outlined in a WBS element to the organizational division that is responsible for the effort. A RAM is created by intersecting the WBS with the OBS. The control account is established at the intersection.
Risk breakdown structure (RBS): A hierarchical arrangement of the risks that have been identified in a project or a hierarchical framework presenting possible sources of risk, either generic or project specific.
Subproject: A logical major component of a project. A subproject is usually a WBS element that can be managed as a semi-independent component of the project and is the responsibility of one person or organization.
Task: A generic term for a defined unit of effort on a project; often used interchangeably with activity, but could be a further breakdown of an activity. A task, like an activity, has an action component and is defined using a verb.
Work breakdown structure (WBS): A product-oriented, service-oriented, or result-oriented family tree or grouping of project elements that organizes and defines the total work scope of the project. Each descending parent/child level represents an increasingly detailed definition of the project work.
WBS element: An entry in the WBS that can be at any level and is described by a noun or a noun and an adjective.
WBS level: The relative rank of a WBS element in a WBS hierarchy. Customarily the top rank, the total project, is Level 1 and the top element in a program is Level 0.
Work element: Same as WBS element.
Work package: The lowest-level element in each branch of the WBS. A work package provides a logical basis for defining activities or assigning responsibility to a specific person or organization. Also, the work required to complete a specific job or process such as a report, a design, a documentation requirement or portion thereof, a piece of hardware, or a service. 1
100 percent rule: The requirement in a WBS that the sum of the work effort of a series of child elements add up to 100 percent of the work effort of the parent element.
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.
The WBS is the outline of the work, not the work itself.
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: 2
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.
The total scope, 100 percent of the project, is represented by the sum of the work in the three Level 2 elements.
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 next level below the work packages is where the activities or tasks are performed. The activities are the action elements (“order asphalt for driveway,” “install windows”); do not confuse activities and WBS elements
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.
Because the WBS defines the scope of the project, work not included in the WBS is outside the scope 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
• 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.
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 is not an organization chart, even though its hierarchical structure is similar to that of an organization chart.
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.
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. 3
The WBS is not a new concept; it has been in use for more than 50 years. It brings an important discipline to be used in structuring projects and contracts.
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. 4 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.” 5
DoD’s WBS standard provides mandatory procedures for all programs subject to DoD Instruction 5000.02 and is mandatory for all major DoD acquisitions (Acquisition Category I, II, and III programs). Section 2 provides instructions on how to develop a government program WBS
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.
The Standard Practice Work Breakdown Structures for Defense Materiel Items, MIL-STD-881C, and DOE’s Work Breakdown Structure Handbook should be in every government manager’s library.
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). 6 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, 7 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. 8
PMI’s Practice Standard for Work Breakdown Structures, Second Edition, includes a useful WBS discussion and samples.
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.
There is no fundamental difference in approach or content between a WBS for a government project and a WBS for a private sector project. The principles and application are the same.
The fundamentals of developing a WBS can be applied to any project, whether the deliverable is a product, service, or result.
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).
Explore how to assess a wide range of factors to determine which contract type will provide the government the best value...
Transform your workplace into a well of learning and employee potential fulfilled with the help of this book!
Use past performance to win contracts at the lowest risk and cost
Learn project management processes, tools, and techniques that are scalable and adaptable to small projects.