Chapter 4

Defining WBS Quality

4.1 Overview

What is a quality WBS? The PMBOK® Guide—Third Edition (Chapter 8) considers quality to involve the “the degree to which a set of inherent characteristics fulfills requirements.” 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. (See Chapter 3 of this WBS Practice Standard for the uses, purpose, and importance of the WBS.) To state that a particular WBS is of high quality, one must agree that the WBS 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. This chapter will describe these principles and identify the characteristics of a high-quality WBS that flows from each principle. It will illustrate the negative effects of a poorly constructed WBS and it will provide tools for project managers to use in evaluating any specific WBS that is being developed. The remaining sections of this chapter are as follows:

4.2 WBS Quality Principle 1

4.3 WBS Quality Principle 2

4.4 Annotated Example of a High-Quality WBS

4.5 Problem Diagnostic Checklist

4.6 Summary

4.2 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 use of a WBS. These describe core characteristics of every WBS and use-related characteristics that describe a particular WBS based on its individual setting and use.

4.2.1 WBS Quality Sub-Principle 1—Core Characteristics

There is 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.

With respect to core characteristics, a WBS either has them 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. A WBS with the following core quality characteristics can be said to have core quality:

• Is a deliverable-oriented grouping of project elements
• Defines the scope of the project
• Clarifies the work and communicates project scope to all stakeholders
• Contains 100% of the work defined by the scope
• Captures internal, external, and interim deliverables in terms of work to be completed, including project management
• Is constructed so that each level of decomposition contains 100% of the work in the parent level
• Contains work packages that clearly support the identification of the tasks that must be performed in order to deliver the work package
• Provides a graphical, textual, or tabular breakdown of the project scope
• Contains elements that are defined using nouns and adjectives—not verbs
• Arranges all major and minor deliverables in a hierarchical structure
• Employs a coding scheme for each element that clearly identifies its hierarchical nature when viewed in any format such as a chart or outline
• Has at least two levels with at least one level of decomposition
• Is created by those who will be performing the work
• Is constructed with technical input from knowledgeable subject matter experts (SMEs) and other project stakeholders, such as financial and business managers
• Iteratively evolves along with the progressive elaboration of project scope, up to the point the scope has been baselined
• Is updated in accordance with project change control, thereby allowing for continual improvement, after the project scope has been baselined.

4.2.2 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.

With respect to use-related characteristics, the quality of a WBS depends on how well the specific content and type of WBS elements meet all the needs for which the WBS has been developed. This statement implies that the more project needs are met by the WBS, the higher its quality. A high-quality WBS is constructed so that it can be used to meet all project requirements, even if a given project does not take advantage of all of the characteristics present.

Use-related characteristics support the application of WBS practice in situational contexts. These can include, and are not limited to the following:

• 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.
  • The depth of the WBS correlates with the size and complexity of the project and the level of detail needed to plan and manage it.
  • All deliverables are limited in size and definition for effective control. However, they should neither be so small that the cost of control is excessive, nor should they be so large that the item is unmanageable or the associated risks cannot be identified.
• Provides sufficient detail for communicating all work. A WBS facilitates conceptualization and definition of the product, service, or result (deliverable) details. But the degree of WBS detail necessary for conceptualization of project detail can vary. For example, existing modules can be satisfactorily described by a product number, while to-be-designed components might need to be described in greater detail. To ensure clarity of communication regarding the intent of any WBS element, an entry detailing specific information about the WBS element should be placed in the WBS Dictionary. This will minimize misunderstanding of the WBS and, in turn, the project scope.
• Is appropriate for tracking, as required by the specific project or organization. Some projects or organizations can require highly detailed performance reporting at the work package level, while others might require only summary level reporting at a WBS rollup level.
  • The WBS has logical summary points that assist in tracking the evaluation of performance accomplishments, resource allocations, costs, and schedule performance.
  • Suitable management control points are identified in the WBS that can be used to facilitate communication and to control scope, quality, and technical soundness.
  • In summary, the WBS provides a feasible mechanism to assess performance and progress.
• Is appropriate for control activities. A WBS balances the control needs of management with an effective level of project detail. It provides a good balance between complexity, risk, and the project manager's need for control.
  • Shorter, less complex projects may require only a few performance assessments at higher WBS levels, whereas larger, more complex projects may require many intermediate reviews at the work package level.
  • Elements are detailed enough to meet performance measurements and accountability objectives, thereby facilitating effective planning, monitoring, and control.
• Can contain specific kinds of WBS elements, as needed for each project. Some projects might need to include a majority of the following types of WBS elements, while other projects need only one or two:
  • Some project WBSs can include elements for integration, procurement, supply chain management, information/communication, administration, documentation, training, and software development.
  • WBS elements representing subcontracted or externally committed deliverables should directly correspond to matching elements in the subcontractor's WBS.
  • A WBS might include level-of-effort WBS elements.
  • Deliverables from the development life cycle stages, such as planning, analysis, design, assembly, testing, and implementation, can be reflected in the WBS, where appropriate.
  • WBS elements can reflect the deliverables within the product development life cycle, where appropriate, such as in the IT industry.
• Enables assignment of accountability at the appropriate level. Some projects or organizations can require assignment of accountability at a very detailed, work package level, while others might be satisfied with accountability assigned at a summary rollup level.
  • Each WBS element can be assigned to an accountable individual, subcontractor, or organizational unit.
  • The WBS can serve as the mechanism for documenting the accountability and responsibility for the various deliverables by having a direct relationship among the WBS elements related to the Organizational Breakdown Structure (OBS) identified through the Responsibility Assignment Matrix (RAM).
  • WBS elements clearly identify accountability to the level of detail required for managing and controlling the project.
• 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.
  • The WBS decomposition level balances the project definition with data collecting and reporting requirements.
  • WBS elements are compatible with relevant organizational and accounting structures.

4.3 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 broader levels possess 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.

4.4 Annotated Example of a High-Quality WBS

This WBS example is based on a hypothetical organization that builds bicycles to an individual customer's specifications. The annotations refer to specific characteristics of a high-quality WBS. Figure 4-1 illustrates a simplified WBS as it pertains to a sample project. The project is the design and building of a bicycle and is an example of a WBS to encompass the work for this sample project.

4.4.1 Level 1

This level comprises the full scope of work necessary to produce the bicycle. It includes all direct and indirect work. Level 1 is the overall product, always a single WBS element. In this example, the top level is represented by both a name and a WBS identifier to differentiate it from other WBSs in a program or portfolio of which it is a member. This may not always be the case. If the project stands alone, the top level or Level 1 identifier may not be required. When the top level identifier is not included, numbering for the remaining WBS levels will also change accordingly.

4.4.2 Level 2

This is the first level of decomposition. This level is the high-level breakdown of the major areas in the scope of work. It holds the basic components of the product, along with integration and project management. The frame set is basically the parts you sit on, steer with, and to which you attach wheels and other parts. The crank set includes the pedals, bearings, crank arms, and sprocket. The braking system includes the brake pads and related mechanisms for the wheels, cables, and levers. The shifting system includes the front and rear shift mechanism, cables, and levers. This level is numbered as #.#—for example, frame set is 1.1.

4.4.3 Level 3

This level decomposes each major area from Level 2 into its constituent parts. It is important to note that the 100% Rule is always adhered to in the development of a WBS. This level would tend to start targeting specific, tangible deliverables of the project effort. Here, integration is decomposed into interim deliverables based on the project life cycle chosen for this project. This level is numbered as #.#.#—for example, rear wheel is 1.3.2.

4.4.4 Level 4

In the same manner, each exclusive area in Level 3 would be decomposed further, if applicable. Again, the complexity of the work will drive the depth and number of levels of the WBS decomposition. Note that testing is further decomposed into three elements: component test is pre-assembly testing; product test is quality control and pre-customer test; and customer test is customer delivery, final adjustments, and customer acceptance. This level is numbered as #.#.#.#—for example, Product Test is 1.6.4.2.

4.5 Problem Diagnostic Checklist

The following are representative examples of major project problems resulting from key WBS defects.

• There are frequently missed deadlines and an extended schedule
  • Have all major and minor deliverables been included? Failure to include all deliverables within the initial WBS can increase project schedules when missed deliverables are identified.
  • Have deliverables been defined specifically enough to allow for appropriate work packages to be developed?
  • Does the WBS facilitate the use of earned value management techniques?
• Project is over budget
  • Does the WBS provide logical summary points for assessing accomplishments, as well as for measuring costs and schedule performance?
  • Does the WBS facilitate the use of Earned Value Management techniques?
• Individuals are unable to use the new product or feature
  • Are deliverables decomposed into smaller, more specific deliverables? For example, a deliverable of training might not be decomposed thoroughly enough to cover all of the people who need training to use the new product, process, or service.
  • Are the WBS elements deliverable-focused?
  • Were appropriate assembly or integration deliverables and testing activities present?
  • Were training and implementation deliverables defined?
• The project scope has changed and is unmanageable
  • Has a WBS been created for the project?
  • Does the WBS decompose the overall project scope into deliverables?
  • Does the WBS provide a level of flexibility for change?
  • Has the WBS been updated when necessary changes are approved by the change control process?
  • Has the WBS been placed under change control?
• The project has become an ongoing project with no end in sight
  • Has a maintenance plan been developed for post implementation if needed?
  • Does the project have a specific end point?
  • Does the WBS include a closeout phase or plan?
  • Is the endeavor actually a project or is it an ongoing operation?
• Project team members are confused about their individual responsibilities
  • Do the WBS elements define overlapping responsibilities for the creation of a deliverable?
  • Is the information within the WBS at the appropriate level of detail, and in formats and structures meaningful to those performing the work? If so, were clear communication processes and decision authorities agreed upon beforehand?
  • Do the WBS elements reflect work with specific, tangible deliverables?
  • Have all key stakeholders, including subject matter experts, contributed to the creation and validation of the WBS?
• Some planned work does not get done
  • Has all required work been included in the WBS?
  • Are the WBS elements deliverable-focused?
  • Has the WBS organized around deliverables rather than process steps?
  • Was decomposition completed before dependencies and durations were defined?

4.6 Summary

There are several characteristics that need to be present to produce a quality WBS deliverable. For a WBS to be considered as high quality, it should conform to its original requirements and be fit for use by the project. More simply stated, it should satisfy the purpose for which it was originally intended.

In summary, a high-quality WBS:

• Is constructed in a consistent fashion, varying only in its level of focus based upon its intended use
• Satisfies the needs of the project
• Contains all of the key elements necessary to represent the full scope of work
• Is usable by project managers with a broad base of experience to manage the varying degrees of scope, budget, schedule, and risk
• Avoids the common pitfalls associated with WBS construction.