Introduction
The intent of this paper is to acquaint the reader with the contents of the Practice Standard for Work Breakdown Structures-Second Edition, explore a few of its key concepts in detail, and to motivate the reader to consult the Practice Standard regularly as a reference.
The Project Management Institute (PMI®) recognized the unique importance of the Work Breakdown Structure (WBS) when it published, in 2001, a Practice Standard devoted exclusively to the WBS. This document was the first “practice standard”. It focused on providing “…guidelines on the mechanics (e.g., nuts and bolts, basics, fundamentals, step-by-step usage guide, how it operates, how to do it)” for the WBS (PMI, 2001, p. 29). A Practice Standard “…is intended to be more prescriptive than the PMBOK® Guide” (PMI, 2001, p. 30). Increasing sophistication in the use of the WBS has stimulated production of an updated and revised edition – Practice Standard for Work Breakdown Structures–Second Edition.
The Practice Standard for Work Breakdown Structures–Second Edition addresses many of the recommendations received since the first publication, including the need for more detail, a broader overall perspective, more and varied examples, checklists, and reference material, while ensuring that this material accurately reflects the application of standard practice in the industry. Throughout the standard, the reader will find more guidance about the characteristics that make up a high-quality WBS, as well as a discussion about the use of the WBS in real-life practical experience. The Practice Standard for Work Breakdown Structures—Second Edition is consistent with A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Third Edition.
The primary objectives of the Practice Standard for Work Breakdown Structures—Second Edition are 1) to provide a common ground for understanding the concepts and benefits of the WBS, and 2) to present a standard application of the WBS as a project management tool. The intent is to encourage consistency in applying this tool and, as a result, to improve project planning and control.
The WBS Concept
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, p. 212)
The WBS provides a clear statement of the objectives and deliverables of the work to be performed. It 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 the deliverables will be produced, but rather is specifically limited to describing and detailing the project's outcomes or scope. The WBS is a foundational element, 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 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 work to be performed and tracked. These can be later used as input to the scheduling process to support tasks and milestones which can be cost estimated, monitored, and controlled.
A central attribute of the WBS is that it is “deliverable orientated” (Berg and 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, p. 108) In this context, “oriented” means aligned or positioned with respect to deliverables, i.e., focused on deliverables.
A second key attribute of the WBS is that it is a “…hierarchical decomposition of the work…” (PMI, 2004p. 127) 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” (PMI, 2004, p. 373). 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 should be appropriate for effectively managing the project 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 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 same WBS represented in Outline View format, Organization Chart format and in the Tree or Centralized Tree Structure:
Exhibit 1 – Outline View.
Exhibit 2 – Tree Structure, or “Organizational Chart” Structure.
Exhibit 3 – Centralized Tree Structure.
The Importance of the WBS
Experienced project managers know that there are many things that can go wrong in projects regardless of how successful project managers are in the planning and execution of their work. Project failures, however, can often be traced to a poorly developed or nonexistent WBS. A poorly constructed WBS can result in adverse project outcomes such as ongoing project extensions, unclear work assignments, goals, objectives, or deliverables, scope creep or unmanageable, frequently changing scope, budget overrun, missed deadlines, unusable new products or features, or failure to deliver some elements of project scope. The Practice Standard for Work Breakdown Structures–Second Edition provides a checklist as a guide for identifying and repairing WBS defects (section 4.5).
The WBS plays an integral role in other project management initiating, planning, executing, and monitoring and controlling processes as described in the PMBOK® Guide—Third Edition. Typical examples of the contribution of the WBS to other processes are described in the Practice Standard for Work Breakdown Structures–Second Edition.
There are many project management tools that use the WBS or its components as input (PMI, 2004, Chapter 5, Section 5.3). For example, the WBS utilizes 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 in conjunction 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.
Scope management is integral to other PMI standards and therefore these 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 the upcoming Practice Standard for Scheduling) or incorporate the WBS as the preferred tool to develop the scope definition (e.g., the PMBOK® Guide—Third Edition, OPM3®).
Defining WBS Quality
The PMBOK® Guide considers quality to involve the “the degree to which a set of inherent characteristics fulfills requirements” (PMI, 2004, p. 195). This includes the ideas of conformance to requirements and fitness for use, that is, the ability to satisfy the purpose for which the item—in this case a WBS—was intended. A “high quality” WBS is one that has been created so that it satisfies the purpose for which it was created.
There are two basic principles that govern the quality of a WBS.
WBS Quality Principle 1
A “quality WBS” is a WBS constructed in such a way that it satisfies all of the requirements for its use in a project.
There are two sub-principles that pertain to satisfying requirements for a WBS. These describe core characteristics and use-related characteristics.
WBS Quality Sub-Principle 1 – Core Characteristics:
There are a set of “Core Characteristics” that must be present in every WBS, as these characteristics enable the WBS to satisfy project needs that are present in every project. A WBS either exhibits the Core Characteristics or it does not, and, as such, these characteristics represent the minimum set of specific attributes a WBS must contain. When evaluating or developing a WBS, the absence or presence of these core characteristics will dictate whether or not it is a “Quality WBS.” Selected examples from the full list of Core Characteristics contained in the Practice Standard for Work Breakdown Structures–Second Edition are:
- Is a deliverable-oriented grouping of project elements.
- Defines the scope of the project.
- Contains 100% of the work defined by the scope.
- Provides a graphical, textual or tabular breakdown of the project scope.
- Arranges all major and minor deliverables in a hierarchical structure.
WBS Quality Sub-Principle 2 – Use-related Characteristics:
There is an additional set of “Use-related Characteristics” that may vary from one WBS to another. These characteristics enable the WBS to be used for purposes that are unique to a specific project, industry or environment, or are applied in a particular way to individual projects.
The quality of a WBS depends on how well the specific content of the WBS and the type of WBS elements included meet all the needs for which the WBS has been developed. The more project needs that are met by the WBS, the higher its quality. Selected examples of Use-related Characteristics include:
- Achieves a sufficient level of decomposition: A WBS is broken down to a level of detail sufficient for managing the work. The appropriate level of detail to enable effective management can differ from organization to organization or project to project.
- Provides sufficient detail for communicating all work: The degree of WBS detail necessary for conceptualization of project detail can vary.
- Is appropriate for tracking, as required by the specific project or organization.
- Is appropriate for control activities: A WBS provides a good balance between complexity, risk, and the project manager's need for control.
- Can contain specific kinds of WBS elements, as needed for each project.
- Enables assignment of accountability at the appropriate level: Some projects can require assignment of accountability at a detailed level, while others might be satisfied with accountability at a summary rollup level.
- Has a succinct, clear, and logically organized structure to meet project management and oversight requirements: The logic of the hierarchical decomposition of a project can vary in response to a variety of project and organizational factors.
WBS Quality Principle 2
WBS quality characteristics apply at all levels of scope definition.
There is no conceptual difference between a project WBS, a program WBS, and a portfolio WBS. A high-quality WBS developed at any of these levels possesses precisely the same characteristics and attributes as a high-quality WBS developed at the individual project level. These differ only in the breadth of the content and scope. The WBS quality principles that apply to a project WBS also apply to a program or portfolio WBS.
The Practice Standard for Work Breakdown Structures–Second Edition provides a checklist for assessing WBS quality (PMI, 2006, Sec. 4.5)
Considerations While Creating a WBS
The WBS is created in the ‘Create WBS’ planning process. (PMI, 2004, sec. 5.3) There are many ways to create a WBS. It can be developed entirely as a new document, can reuse components from existing WBSs, can be based on a template, or can follow pre-defined WBS standards. When reusing existing components, WBS elements can be drawn from similar projects or from standard project templates that the organization has determined support accepted good practices.
A number of project management tools can be used to assist with the development of a WBS. These tools include outlines and organization charts, fishbone and brainstorming techniques. There are many WBS templates available, and corporate standards can be referenced or copied for quick-starting WBS development. The Practice Standard for Work Breakdown Structures–Second Edition contains many examples that may be used as starting point. There are many benefits to using tools to develop a WBS. For example, tools often promote consistency and repeatability in the development of a WBS, especially enterprise productivity tools. WBS tools can also promote and enforce the principles of the WBS standard and can significantly reduce the development effort, simplify the WBS process, and even promote reusable WBS products.
The WBS evolves through an iterative consideration of the project's purpose and objectives (both business and technical), functional and performance design criteria, project scope, technical performance requirements, and other technical attributes. A high-level WBS can often be developed early in the conceptual stage of the project. Once the project is defined and specifications are prepared, a more detailed WBS can then be developed. It should be customized to the specific needs and requirements of the project. All non-required work and deliverables should be listed and removed so the WBS represents only the project's scope. The end result is a WBS that represents the complete list of deliverables for the project. A number of authors have provided useful guidance on preparing a WBS (Haugan, 2002; Pritchard, 1998; Uyttewaal, 2003).
Some of the more popular methods employed to create a WBS include a top-down approach, a bottom-up approach, the use of organization-specific WBS guidelines or standards, and the use of WBS templates. Each of these has advantages and disadvantages, which are described in the Practice Standard for Work Breakdown Structures–Second Edition. The choice of appropriate method should be based on the specific project objectives, requirements, assumptions, and constraints.
The Practice Standard for Work Breakdown Structures–Second Edition offers guidance (sec 5.3) for developing a WBS. This includes attention to the basic tenets of WBS construction, for example, explicit inclusion of all deliverables, including interim and intangible deliverables, the 100% rule, use of an appropriate decomposition logic, appropriate level of detail, and use of an iterative WBS process. The guidance also includes consideration of specific questions within the Project Management Knowledge Areas.
Effective application of use-related characteristics relies on experience and judgment by the project management team. Important areas of WBS development that require judgment include level of detail, types of WBS elements to include, and logic of decomposition.
The level of detail in a WBS is a function of the size of the project, and reflects a balance between complexity, risk, and the project manager's need for control. The level of detail can also vary during the evolution of a project. Short-duration projects lend themselves to decomposition to a high degree of detail at the outset, while projects of longer duration and higher complexity can preclude decomposition of all deliverables until more is known about the project. This is especially true when employing rolling wave planning.
Not every WBS needs to include all types of work. Rather, the kinds of work included in a WBS should be dictated by the scope and nature of the project for which the WBS is being developed. Some projects require certain types of WBS elements, e.g., assembly or integration, while others do not. All projects require a project management WBS element at level 2 in order to ensure that the work of planning, tracking, and reporting is adequately captured and managed. (Practice Standard for Work Breakdown Structures–Second Edition provides an example of a project management WBS.) A particular organization, however, might require use of a standardized WBS template that does not include certain kinds of project management WBS elements—for example, administration, documentation, or reporting elements—because the need for these is adequately addressed by other business processes established by that organization.
The way that the project manager decomposes the project (i.e., the logic used for decomposing the work) can vary depending on the needs and requirements of the performing organization and how the WBS will be used. Where new product development proceeds in sequential stage-like phases with later work contingent on the outcome of earlier work, it would make sense to organize the WBS in terms of the product development life cycle, rather than in terms of physical components of the product.
The ability of a WBS to meet the needs of a project is also directly related to the level of project management competency available within the project management team. An experienced project management team will be able to identify a greater range of stated and implied project needs that the WBS can address. A more experienced project management team will ensure the WBS is employed in a greater variety of project roles, and will use the WBS in more efficient and sophisticated ways than will a novice or inexperienced project management team.
Evolution of the Practice Standard
The publication of revised editions of the PMBOK® Guide and The Practice Standard for Work Breakdown Structures recognizes the growth and increased sophistication of project management thought and practice in general, and of the WBS in particular. In some cases this evolution reflects revised thinking and reformulation of earlier concepts, and in other cases it represents progressive elaboration and formalization of concepts that were previously only implicit. These represent current and emerging practice and are now explicit in this practice standard.
An example of revised thinking is the concept of the WBS as “Deliverable-oriented” which has changed from a “Task-oriented ‘family tree’ of activities’ (PMI,1987), to “deliverable-oriented decomposition of the work to be executed” (PMI, 2004). The evolution from a task-orientation to a deliverable orientation reflects the realization that decomposition of project deliverables, expressed as nouns, is necessary for complete scope definition and control, and that the lowest level of the WBS may be connected to activities and work packages defined in terms of actions, expressed as verbs (Berg and Colenso, 2000, p 69; PMI, 2001, p. 3; Colenso, 2003.)
An example of increasing formalization of implied concepts is the explicit statement in the WBS Practice Standard - Second Edition of the “WBS Quality Principle #1” which states that a WBS is characterized by a set of “Core Characteristics’ required for all projects, and a set “Use-related Characteristics” that may vary from one WBS to another because they “…enable the WBS to be used for purposes that are unique to a specific project, industry or environment, or are applied in a particular way to individual projects.” (PMI, 2006, sec 4.2). These concepts had been implicit in descriptions of the WBS from the earliest days (e.g., Office of the Secretary of Defense. DoD and NASA Guide PERT COST Systems Design, June 1962, pp.27, 33) but only became explicit in the latest edition of the The Practice Standard for Work Breakdown Structures.
Usage Trends
In a survey conducted by the Practice Standard for Work Breakdown Structures–Second Edition team, 87% of respondents said that they use the WBS as a planning tool for project management activities at least half of the time and over 60% used it more often. Their main objectives were to use the WBS to support activity definition, resource planning, scope planning and definition, cost estimating, and risk planning. 91% of the respondents stated they were either satisfied or very satisfied with the ability of the WBS to meet these objectives. These results illustrate the broad acceptance and use of the WBS in project management practice today.
The concept of the WBS has evolved to meet the evolving requirements of the project management profession. This is an evolution which has elaborated the core concept of the WBS: a tool to enable the definition, development, communication and execution of project scope. The practice standard will also continue to evolve in parallel with generally accepted good project management practice.
