Product versus work breakdown structure

Patrick Weaver
August 13, 2015

I was recently involved in a virtual discussion on the UK’s Association for Project Management (APM) website around the use and differences between a product breakdown structure (PBS) and a work breakdown structure (WBS). The resulting briefing document produced by the APM is summarised here with some additional commentary.

The concept of a WBS goes back to the development of PERT in the USA, in the 1950s (if not earlier) and is integral to the concept of earned value management. The WBS is a hierarchal decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.

The concept of a PBS is integral to the PRINCE2 methodology. The origins of PRINCE can be traced back to the UK in the 1970s. The PBS is a hierarchical structure of things that the project will make or outcomes that it will deliver. It decomposes a Main Project Product into its constituent parts in the form of a hierarchical structure.

While PBS and WBS look very similar, they serve different needs and both can have important roles to play in the project planning and control process and should not be confused.

What is a PBS?

The product breakdown structure (PBS) is a hierarchical structure of things that the project will make or outcomes that it will deliver.

product breakdown structurePBS generated by P2ware Planner

The PBS diagram differentiates between the different types of product (ie thing):

  • The final product is the blue box at the top of screen
  • Assemblies are shown as green rhombus
  • Internal products (those built by the project) brown rectangles
  • External products (those either supplied by another project or bought in) are ovals

Products are described using nouns or as an outcome described in the past tense, for example ‘Test Plan’ or ‘Training Delivered’. The PBS is supported by a Product Log (list of products) and associated Product Descriptions that describe individual products in more detail. This enables quality expectations and responsibility for approval to be clearly identified at an early stage in the project lifecycle.

Once completed, the PBS gives confidence that the project team clearly understands what has to be created and that the relationship between a product and its constituent parts has been defined.

From the PBS a Product Flow Diagram can be produced to represent the order in which sub-products build into the main project product. This helps define the logic of the delivery plan.

To validate the PBS, ask the following questions:

  • Does the PBS contain work? If so this work needs either moving to the WBS or converting into a product.
  • Are all high-level products broken down to an adequate level of detail?
  • Have all external products been identified and sourcing confirmed? If they are outputs from other projects these represent risks that should go in the risk log and/or be defined as project interfaces/dependencies.
  • Are all products couched as nouns or outcomes in the past tense?

What is a WBS?

The work breakdown structure (WBS) provides a hierarchical structure of project activity; it focuses on the work required to accomplish the project. The WBS Dictionary is produced in conjunction with the WBS to store relevant detailed information in support of the planning process. In general the WBS makes it clear what work needs to be done and makes it easier for that work to be assigned to project teams.

Work Breakdown StructureA typical WBS

Similar to the PBS, external work is included in the WBS with an internal manager taking responsibility for the oversight of the external contractor or supplier.

The completed WBS forms the basis of the Project Plan, it decomposes the main project into stages or major components, then into control-packages then into work-packages. The levels of detail are dependent upon the complexity of the project.

Elements in a WBS are described by a verb and a noun, for example, ‘Install Servers’ or ‘Deliver Training’. The work-packages are then used as the basis for developing the project schedule, cost control and other management controls.

Once completed the WBS gives confidence that all of the work required to deliver the outcomes is understood. To validate the WBS ask the following questions:

  • Does the WBS contain things? If so these things need to be moved to the PBS and each thing replaced in the WBS by a work-package.
  • Is there a work-package or combination of work-packages for all project products?
  • Is work couched as nouns with associated verbs?
  • Are all work-packages broken down into sufficient detail to be clear to the deliverer what is required?
  • Are work-packages aligned to contracts where required?

Using the PBS and WBS to plan a project

The PBS should be developed first so that the project outcome is clearly understood and can be agreed with the sponsor. The PBS clarifies what is to be built or acquired. The Product Log is a useful place to record suppliers of external products and a Product Flow Diagram enables you to identify the order in which components of the product are required. This enables the logic of the overall plan to be understood at a high level before detailed planning begins.

A WBS can then be built to organise the construction of products as a set of work-packages. Organising the work into work-packages simplifies resource and team planning and provides the basis upon which a realistic project plan can be constructed. All elements of the PBS should be aligned to a phase boundary (Level 2 or 3 in the WBS) so that the project controls system can accurately measure progress in delivery.

While there is no direct relationship between the structures of the WBS and the PBS, having a thing- and work-related view of the overall project is very useful for validating the completeness of the plan. The key questions to ask are:

  • Do you have products without work-packages? If so you will not be able to deliver the outcome or you have products in the PBS that in the cold light of day are not required.
  • Do you have work-packages without products? If so you are either doing unnecessary work or have missed something from the PBS.

Using the PBS and WBS to control a project

The PBS provides a useful management tracking tool preventing phase (or stage) boundaries from being passed without tangible progress being made. In PRINCE2, the PBS (or more specifically the Product Log) also forms the basis of the quality assurance process. Ultimately it is the quality of each individual product that will drive the success of the project.

The WBS forms the basis of the detailed delivery plan and is used to task teams and individuals and hold them to account for their progress: this is the core concept in earned value management.

Used in conjunction, the PBS and WBS offer powerful tools in ensuring the correctness and completeness of project plans, and then to ensure the project delivers everything required, and can really help the project manager establish clear communication and expectations with the wider stakeholder community and the project team. If you decide to use both, make sure the separate purposes and functions are respected.

However, it is quite common to see a hybrid WBS/PBS in a single chart (typically called a WBS). In this situation, the separation between project phases, products and work-packages tends to be based on the various ‘levels’ in the WBS. This is the approach adopted in MIL-STD-881C which forms the basis of all program WBSs developed for every acquisition made by the USA military.

Ultimately every work-package should produce a product, even if some products are largely internal to the project, and every product requires work to be performed in its creation. The real difference between a WBS and a PBS is how the elements that combine to make up the completed project deliverable are described.

Author avatar
Patrick Weaver
Patrick Weaver is the managing director of Mosaic Project Services and the business manager of Stakeholder Management Pty Ltd. He has been a member of both PMI and AIPM since 1986 and is a member of the Asia Pacific Forum of the Chartered Institute of Building. In addition to his work on ISO 21500, he has contributed to a range of standards developments with PMI, CIOB and AIPM.
Read more