Use of product breakdown structures and work breakdown structures

Introduction

Product Breakdown Structures and Work Breakdown Structures look very similar and both have important roles to play in the project planning and control process.

It is quite common for misunderstandings and the loose use of language to blur the edges in these two diagram types causing them to lose effectiveness. The purpose of this web briefing is to clarify the purpose of each of these planning tools and to offer some standard guidance for their use.

To illustrate the use of each diagram type a simple “Third Party Software Installation Project” has been drawn up. The intent of this simple project structure is to illustrate use of the diagram techniques not to offer a complete model for the implementation of third party software.

What is a Product Breakdown Structure?

A Product Breakdown Structure (PBS) is a hierarchical structure of things that the project will make or outcomes that it will deliver. It can be thought of as the project “shopping list.” 

It decomposes a "Main Project Product" into its constituent parts in the form of a hierarchical structure. 

The diagram below illustrates a typical PBS for a simple project.

Notice that “internal” products (those built by the project) are differentiated from “external” products (those either supplied by another project or bought in). Note also that products are couched either as nouns or as an outcome described in the past tense - E.g. "Test Plan" or "Training Delivered".

Once completed the PBS gives confidence that what is required is clearly understood and that the relationship between a product and its constituent parts has been defined. 

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 life cycle. 

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. The diagram below illustrates the idea. 

Notice that the ordering of delivery differs in this case from the PBS structure. Again, internal and external products are differentiated in the diagram.

What is a Work Breakdown Structure?

In contrast to the PBS the Work Breakdown Structure (WBS) provides a hierarchical structure of project activity. If you like it represents the project “to do list.” Its focus is on “work” not “things.” 

Similar to the Product Log, a WBS Dictionary can be produced in conjunction with the WBS to store relevant detailed information in support of the planning process. 

The WBS forms the basis of the Project Plan, decomposing the main project into stages, then workpackages then into sub-activities per work-package. The levels of detail are dependent upon the complexity of the project.

Once completed the WBS gives confidence that the tasks required to deliver all outcomes are understood and that the ordering is correct. 

The diagram below proposes a WBS to deliver the “Third Party Software Project” illustrated above.

Notice that items are couched in terms of a verb and a noun. E.g. "Install Servers" or "Deliver Training". 

Note also that organising the work into work-packages gives the opportunity to organise external supplier contracts into distinct a work-package rather than having contract work scattered about the plan. In general the WBS should make it clear what needs to be actually done and make it easier for that work to be assigned to project teams.

There is no direct relationship between the structures of the WBS and the PBS. 

Tests for correctness

PBS

• Critically review the PBS and ask the following questions:
• Does the PBS contain "work"? If so it has gotten muddled and this work needs either moving to the WBS or converting into "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 risks log and/or be defined as project interfaces/dependencies.
• Are all products couched as nouns or outcomes in the past tense?

WBS

• Critically review the WBS and ask the following questions:
• Does the WBS contain "things"? If so these things need to be moved to the PBS and the "things" replaced in the WBS by "make thing" work-packages.
• 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?

Use in the planning process

Both techniques bring different benefits to the planning process and should ideally be used in conjunction to ensure the project is thoroughly planned out.

Together they support a "Design Backwards" approach to the planning process that enables the project manager to clearly:

• Define the outcome
• What is it?
• How will you know that you have achieved it?
• Define what is needed to fulfil the outcome
• Define how what is needed can be produced
• Understand when this can be achieved
• Understand who will be needed to achieve it

You should produce the PBS 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 indeed imported from elsewhere. External products represent sub-products sourced externally to the project, not built - for example pre-fabricated components or Commercial Off-the Shelf Software. It is therefore a useful source of risks and external dependencies for the project manager.

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 products are required. This enables the logic of the 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 and associated tasks. Organising the work into work-packages simplifies resource and team planning and provides the basis upon which a realistic plan can be constructed. 

Having “thing” and “work” related views of the plan is very useful in completeness validation.

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

It is entirely possible (indeed probable) that the PBS and WBS will look quite different. Products can be represented on the project plan as milestones and linked to the outputs of their associated work-packages. Whatever technique is used there needs to be traceability between the two.

If products will only be partially finished at a stage boundary then intermediate products should be created to ensure that quality checks can be carried out. For example, a test plan may be delivered in draft form for an end-stage review with a view to completion in the next stage. 

To be truly effective the WBS and resulting plan need to fit neatly with the organisation structure that will be doing the delivery. Work-packages in particular need to be readily assignable to coherent teams or groups within the organisation.

Use in running the Project

PBS

All elements of the PBS should be aligned to a stage boundary so that the Project Board can measure progress in delivery. The PBS therefore provides a useful management-tracking tool preventing stage boundaries from being passed without tangible progress being made.

In PRINCE2 the PBS (or more specifically the Project 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.

WBS 

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. It can also form a useful bridge between the delivering organisation and the outcomes required of the project.

Other "Breakdown" structures you might like to consider

See http://toostep.com/insight/article---break-down-structures---wbs-obs-rbs-pbs-cbs-an-ove

• Organisation Breakdown Structure - describes the structure of the delivering organisation that can then be matched to work-packages in the WBS. This is useful particularly when work will be performed by business staff seconded to the project or by specialist teams working on more than one project.
• Cost Breakdown Structure - matched back to the WBS this can provide a useful connection between your Project Finances and the requirements of the Finance Department addressing all those perennial issues around cost centres and expense authorisation/invoice payment/Levels of Authority for spend etc.
• Resource Breakdown Structure - a hierarchy of all resources planned for use on the project. Organised by "Project Team" as sub-units this structure identifies who is available to work on the project and forms the basis for decision making around matching teams to work-package in the WBS.
• Risk Breakdown Structure - Hierarchy of risks broken down by category. Enables the project manager to recognise where the preponderance of risks lie and also understand and express any relationships between risks.

Conclusion

Used in conjunction the PBS and WBS techniques offer powerful tools in ensuring the correctness and completeness of project plans however simple or complex. 

It is important that both are used for their proper purpose with no blurring of the edges of “thing” and “activity.” If this is achieved and the relationship between the resulting outputs is critically reviewed early in the planning process the risk of work completing without the required outputs being completed can be significantly reduced.

Use of the PBS in reporting and the WBS in assigning work can really help the project manager establish clear communications and expectations with the stakeholder community and project deliverers.

Attributions

Editor: Colin Parker

Contributors: Ian Hughes (Oldloggie), Pauline Pritchard (popugo), Mike Beniston (MikeB), Neil Curtis, Neil Gee (neilgee67), Jason Lee, Grant Smith, Simon Springate, Patrick Weaver, Matt Whyndham

Web briefings

Web briefings are the developed from the APM Community, an online community of project professionals. They result from discussions and questions asked within the community, the content is developed from users’ responses and edited by us. 

Web briefings are constantly evolving within the online community and are intended as a guide to issues within the profession.