Project and Programme Management #08: Product Breakdown Structure

So far in looking at the Business Case I have covered the why and who – let’s move on to look at the what and when.

People will probably be familiar with the Gantt chart – the view of a project’s timeline that shows the different tasks as horizontal bars stacked in parallel down the page, and overlapping to show when they are due to take place and how long they will last.

This can be a relatively simple chart with just a few bars that could be created in an application like Excel, or a complex project with hundreds of tasks, created in a specialist application like Microsoft Project.

So how do you build a Gantt chart?

The theory is quite simple, but in practice it can be difficult to tease out all the detail:

1. Identify the tasks
2. Identify the task dependencies
3. Estimate the task durations
4. Allocate task resources
5. Carry out task levelling

I will deal with each of these steps in more detail in this and subsequent posts, but first a few observations and pointers.

When you are drafting the first version of the Business Case you won’t know what all the tasks are and you won’t have accurate information on task durations, etc. A project plan is a dynamic document that should be regularly reviewed and updated throughout the project. At each revision point you add in the information to the best of your knowledge: these are estimates, not 100% concrete forecasts.

I have seen many project plans that have steps 1 and 3 and nothing else. For a small project this may be OK, but it is very dangerous because if you don’t identify task dependencies then you can’t assess what happens if something slips: what is its impact on the rest of the project? So avoid the temptation to cut corners when planning.

The project manager will almost never have enough knowledge of the project to be able to identify all the tasks, dependencies, durations and resources on his/her own – planning is a team effort.
Identify the tasks

The classic tools for task identification are the product breakdown structure (PBS) and the work breakdown structure (WBS). For belt and braces you should do a PBS followed by a WBS, but in practice one or the other is fine. Both PBS and WBS use the organisation tree chart to map them out.

Creating a PBS

PRINCE2 (2005) describes a PBS as “a hierarchical structure that breaks down a final product into its constituent sub-products. It helps the planner to think of what other products are needed to build the final product, and to clarify all necessary work for the creation of that final product.”¹ This defines the “what” of the project: the product and its components.

The figure here shows a simple PBS (click to enlarge). At the top is the final product, and underneath all the sub-products that go into creating the top level product. If a product doesn’t need to be broken down into sub-products, it’s called a simple product. The ones that can be broken down are called intermediate products. Thus “Tea simple” and “Milk simple” only have one component, whilst the others each have three components. The following diagram for a “project” to make a cup of tea illustrates the idea.

In practice you can go to more than three levels, but you should avoid more than five levels as otherwise the structure gets too complicated.

Note that the PBS does not show sequence, though for something as simple as this example parts of the sequence can be implied, e.g. you get the kettle, fill it with water and bring the water to the boil. Similarly you get the cup, wash it and then put the boiled water into it. But the diagram doesn’t show whether you get the cup after boiling the water or before.

In all but the simplest of projects, no one person will be able to identify all of the products. The best way to identify the products is to hold a workshop with relevant people from across the project – not only will this help tease out the products, but it will help build a common understanding of what the project is to deliver, and joint ownership of that.

It’s best to try and identify some of the main top level product groups before the workshop, but not essential.

The workshop should comprise a series of steps:

• People think about products and write each product on a sticky note;
• All the sticky notes are put on a wall;
• Review the sticky notes and remove duplicates;
• Review the remaining sticky notes and put them in related groups;
• Repeat the steps as necessary until everyone feels that all the products have been identified, (usually three or four iterations is enough).
• Build the PBS – the groups identified in step 4 are the equivalent of the intermediate products, so should be give appropriate names.

At the first run-through people will be a little uncertain, so allocate a reasonably short period of time for the first step – once a few sticky notes are up on the wall and they can see how things get grouped, they’ll cotton on and become more productive.

A more complex (but still quite simple) project example is shown below for moving and renovating a garden shed  (click to enlarge). In practice there will be too many products to show on a single PBS diagram, so the master diagram would show the main groups, and a series of supplementary diagrams would show the breakdown for each group. For example item 3 in the above example could occupy a separate diagram with further breakdown of 3.1 (3.1.1 Floor dimensions, 3.1.2 Longest wall dimensions, 3.1.3 Shortest wall dimensions), etc.

Note that the products have been numbered as well as labelled in the shed diagram. This is not obligatory, but it is useful because it helps identify products that belong on a group and also their level in the hierarchy.

Once the PBS has been completed, a final check should be made with the project stakeholders, that everything has been captured. For example the item “3.4 New Fixtures & Fittings” might have a further breakdown that identifies two windows and a door and the sponsor may say that a third window is required. Although such requirements should have been written into the project’s mandate, business case and initiation document, in practice these documents are too high level so the PBS is a good tool for teasing out more details in the user specification.

The business case doesn’t need to include this, but it can be used as the basis for the section that describes what is to be delivered.

Product descriptions

Product descriptions can be useful as part of planning for the following reasons:

• They establish the criteria for user acceptance;
• They act as a checklist for project deliverables;
• They clarify what each product is required to deliver.

In small and medium projects, product descriptions possibly are not required – or could perhaps be used for top level products in the PBS. In Major projects it is worth considering whether at least some, if not all, of the products should have product descriptions.

Once the PBS has been completed, product descriptions can be written. These should be checked with relevant stakeholders and ideally signed off by the sponsor or project board. The PRINCE2 templates include a product description template.

Next post: Task dependencies.

Note 1:
The newest version on PRINCE2, released in 2009, no longer includes specific techniques as part of the methodology, though it still states that an appropriate set of techniques is a requirement for project management. The quote is taken from the earlier 2005 version: OGC (2005) Managing Successful Projects with PRINCE2, TSO, London, p293