Table of Contents

• What is a Product Breakdown Structure?
• PBS vs WBS
• Why Use a PBS?
• How to Create a PBS
  • Step-by-Step Process
  • Decomposition Guidelines
• PBS Notation
  • Conventions
  • Example: Website Redesign Project
• Levels of Decomposition
  • When to Stop Decomposing
• Product Categories
  • Specialist Products
  • Management Products
  • Quality Products
• Using the PBS for Planning
• Linking PBS to Product Descriptions
• Maintaining the PBS
• Common Mistakes
• PBS Workshop Approach
• Related Resources

What is a Product Breakdown Structure?

A Product Breakdown Structure (PBS) is a hierarchical decomposition of the project’s final product into its constituent sub-products and components. It answers the fundamental planning question: “What do we need to produce?”

The PBS is a cornerstone of product-based planning, a technique used in PRINCE2 and widely applicable to any project methodology. By identifying all products first, you ensure nothing is missed and every piece of work is tied to a tangible deliverable.

PBS vs WBS

The Product Breakdown Structure is often confused with the Work Breakdown Structure (WBS). While related, they serve different purposes:

The PBS feeds into the Product Flow Diagram which shows dependencies, and then into Product Descriptions which define quality criteria. Only after these steps should you plan activities and build the Schedule.

Why Use a PBS?

• Completeness – Systematically identifies all deliverables so nothing is overlooked
• Shared understanding – Gives the team and stakeholders a visual picture of what the project will produce
• Scope definition – Clearly shows what is in scope and what is not
• Estimation basis – Each product can be estimated for effort, cost, and duration
• Quality planning – Each product can have quality criteria defined via a Product Description
• Progress tracking – Products are either complete or not, making progress easier to measure than activities

How to Create a PBS

Step-by-Step Process

1. Identify the final product – Start with the overall project output at the top of the hierarchy
2. Decompose into major components – Break the final product into its main sub-products
3. Continue decomposing – Break each sub-product into further components until you reach products that can be assigned, estimated, and quality-checked
4. Identify external products – Mark any products that come from outside the project (inputs, existing systems, third-party deliverables)
5. Validate completeness – Review with the team and stakeholders to ensure nothing is missing
6. Number each product – Assign unique identifiers for traceability

Decomposition Guidelines

PBS Notation

A PBS uses a simple hierarchical tree structure. Products are typically shown as boxes or rectangles, with the final product at the top and sub-products branching below.

Conventions

Example: Website Redesign Project

Levels of Decomposition

The number of levels depends on the size and complexity of the project. More levels provide greater detail but increase the overhead of managing the PBS.

When to Stop Decomposing

Stop breaking down products when:

• The product can be assigned to a single person or small team
• You can write a meaningful Product Description for it
• You can estimate the effort to produce it with reasonable confidence
• You can define clear quality criteria and review it upon completion
• Further decomposition would add complexity without adding value

Product Categories

When building a PBS, it helps to think about three categories of products:

Specialist Products

These are the deliverables specific to the project’s purpose – the things the project exists to create. Examples include software applications, buildings, reports, or business processes.

Management Products

These are the documents and artefacts needed to manage the project itself. They include plans, reports, logs, and registers. Examples:

• Project Initiation Document
• Stage plans
• Highlight reports
• Risk register
• Lessons log

Quality Products

These are products created specifically to verify the quality of other products. Examples:

• Test plans and test results
• Review records
• Inspection reports
• Audit findings

Using the PBS for Planning

The PBS is not just a diagram – it is the foundation for the entire planning process:

Linking PBS to Product Descriptions

Every product identified at the lowest level of the PBS should have a corresponding Product Description. The PBS provides the “what” and the product description provides the “how good.”

You do not need a product description for every product in the PBS. Focus on:

• Products that will be reviewed or inspected
• Products that are complex or high-risk
• Products that will be delivered to stakeholders or customers
• Products where quality expectations need to be explicitly agreed

Maintaining the PBS

The PBS is a living document that evolves as the project progresses:

• Review at stage boundaries – Update the PBS when planning each new stage
• Add newly identified products – As understanding grows, new products may emerge
• Remove products no longer needed – If scope changes, update the PBS accordingly
• Track completion status – Mark products as complete when they pass quality review
• Version control – Maintain a version history to track changes over time

Common Mistakes

PBS Workshop Approach

A practical way to build a PBS is through a team workshop:

1. Prepare – Brief the team on the project scope and objectives
2. Brainstorm products – Use sticky notes to capture all deliverables the team can think of
3. Group and organise – Cluster similar products together and identify parent-child relationships
4. Build the hierarchy – Arrange products into a tree structure on a wall or whiteboard
5. Identify gaps – Walk through the structure and look for missing products
6. Mark external products – Identify which products come from outside the project
7. Number and document – Assign identifiers and capture the structure digitally
8. Review – Validate the PBS with stakeholders who were not in the workshop

Related Resources

• Product Descriptions – Defining quality criteria for each product
• Product Flow Diagram – Mapping dependencies between products
• Schedule – Building a schedule from the PBS
• Milestone Management – Linking products to milestones