PROJECT MANAGEMENT ESSENTIALS

Top Tips for Developing a Breakdown Structure

The following is a list of simple but effective tips that you should use each time you
create a breakdown structure.

1. Be clear on your project objectives: these are your starting point.

2. Identify the type of breakdown structure you need to do, e.g. WBS, PBS, OBS, CBS.
3. Sub-divide the work, from the most general level at the top, down to the most specific
at the bottom, until manageable units are achieved; i.e. organise the outputs or work
into a pyramid arrangement.
4. Define the objectives and inter-relationships at each level within the structure.
5. Allocate each discrete element of the structure a unique reference code (1.1, 1.2
and so on).
6. Estimate effort, time and cost at the lowest level of the WBS or PBS.

Project

1 2 3

1.1 1.2 1.3

3.1 3.2

7. This process should be democratic, with all project participants being represented
so that nothing is left out, ensuring all parties commit themselves to, and take
responsibility for, their part in the project.
8. When developing your breakdown structure, check the following:
 Does the structure represent how the work is going to be done?
 Is it compatible with other existing processes (e.g. time recording, purchasing,
finance, etc.)?
 Is there consistency in size of the lowest level activities (or tasks)?
 Can I reconcile the structure back to the requirements (or contract) to ensure
that all elements are included?
 Can I be sure that there are no tasks that cross a phase or stage boundary?
 Have I got too much detail or developed too many levels?
9. When developing a WBS, and all tasks identified, it is useful to check that all tasks
have the following attributes:
 results in a product
 is a definable scope of work
  has a measurable start (restraint)
 has a measurable finish
 any assumptions are clearly stated

Some Common Sense Guidelines

It is impossible to define a single set of workable rules on how to develop a Breakdown

Structure. However, a number of common sense guidelines do exist. Remember...

 each project is different

 each project manager has a preferred approach
 customers may have a preferred approach
 tasks must not cross life cycle stage boundaries

Tasks should be of a size that they could be completed within two reporting periods but:

 Project management or other support tasks should not be unnecessarily limited.

They should cover a phase or stage of the project and should, ideally, have a
duration of no longer than twelve months.
 If an activity is to cover outside purchases that have a long lead-time, it is counter-
productive to split this work into separate tasks.
 If an activity is to cover intense activity over a short time period, it may be useful
to sub-divide the activity into smaller elements (tasks) than two months.
 Do not develop the WBS in to too much detail in the early stages of a project. A WBS
that has been developed too early will require frequent changing. Once a WBS has
been set up it becomes difficult to change.
 Minimise the number of levels. Too many levels will cause confusion and
misunderstandings.
 Look at other successful projects. Copy their ideas and layout. Examine unsuccessful
projects and learn from their failures. Use templates where possible.
 Leave gaps in any numbering system. Anticipate changes and variation orders. By
leaving gaps, any new tasks can be built into the structure at a logical point.
 If projects are short-term and can be completed in one or two reporting cycles it is
pointless to develop a detailed WBS. In many of these cases, a single activity with
associated tasks may suffice.
 Each task must have strictly defined entry and exit criteria, with the scope of each
work package being unambiguously defined.
 Templates can be useful but do not slavishly copy them. If templates or structures
from other projects are being used as the basis for developing the WBS, take care to
ensure that elements are not omitted or that elements have not been included from
the template that do not apply to the current project.
 If possible, involve the customer when developing the WBS. Also involve the
project team. They are the people who have to accept responsibility for doing the
work.