How to create a work breakdown structure (WBS)
Purpose of a WBS
A work breakdown structure is one of the most useful ‘tools’ you can have when managing projects.
It has an initial purpose in the planning phase: to enable the definition and capture of the complete scope of work of a project, so that estimating and planning are effective.
In the delivery phases, the WBS can then be used to help for example with assessing progress against work scope and enable an analysis of performance against budgets etc.
Origins and importance of a WBS
For us, it’s the most important project management asset we produce. If we had to give up any of our assets one by one, it would very likely be the last.
The concept originated from the discipline of Systems Engineering. There is much debate about what a WBS should contain, and what it should and should not be based upon.
Most common errors
The Wiki page on work breakdown structure contains some useful information but also contains fundamental errors, as can happen when management ‘concepts’ are presented as the aggregation of many people’s views on a single topic. Here are two examples: outcomes and phases. Outcomes are an excellent thing to consider within projects, but the WBS is the wrong place for these. If you have a Business case or equivalent that’s where outcomes belong. If outcomes are represented in a WBS it is likely to impact our ability to achieve what follows in this post. Phases are even more likely to do this. Phases are a natural part of life cycles, but again, they do not belong here. Phases are a key aspect of schedules – not the WBS. It must never be constrained by or attempt to represent schedule, order (i.e. sequence) or logic. The only logic that exists within a WBS is parent-child relationships as we decompose all elements of a project work scope. Attempts to do anything else damages the accuracy and usefulness of what we produce and therefore its effectiveness and integrity.
Here in the UK, we are great a taking a good idea and expressing it in a very British way and certain industries do that with their WBS. One common format you see in the UK is a list of functional tasks to be done, under level 2 headings like: Engineering, Procurement etc. This is the organisation of the company – not the WBS. Whenever you see this, it is a clear misinterpretation of the concept and most importantly often leads to much poorer planning. The other form that is wrong (but less common) is to see elements like Design, and Build Test at level 2. This is closer to correct but still leads to errors. More on why this is later in the post.
So what is the original concept? – ‘product oriented’
A true WBS is a hybrid structure that represents the deliverables (or products) and all the work required to define, design, develop, test and commission every one of the deliverables of a project. This is often referred to as a “product-oriented” (or product-based) WBS. Quite a mouthful, but 100% accurate. If our project reflects a customer contract, every major obligation in the contract must have a natural home somewhere in the structure.
So how do we create one?
Firstly we need all the key disciplines across the team to participate in the definition of the WBS. This should include suppliers. Project managers should never develop one on their own. Developing a WBS is in principle a 2 stage process. In Stage 1 we define the elements of the structure and agree on it – in stage 2 we populate those elements. Stage 1 should not take that long – stage 2 can take any amount of time, but should be done as soon as possible. With the correct people in the room, it should be possible to create the first draft of a WBS (stage 1) in less than one day regardless of how big the project is. That would then be adjusted as information is confirmed, and we must expect this to happen and allow for this. Another terribly British habit is once we have a WBS, we are often very reluctant to change it. This is fundamentally wrong. If it is incomplete or wrong, it must be updated and if that means codes need to change – they need to change!
So, the first draft may not take very much time, but the completion and confirmation of the WBS must evolve throughout the definition phase of the project.
In essence, we need to identify all the major deliverables (or products) of the project and decompose them in a logical parent-child manner until we reach what we feel are discrete packages of work, where the product meets development effort.
What does it look like?
It is a hierarchical decomposition of a project in a logical way. Imagine we have found a piece of land, and are going to construct our dream house. What would the WBS look like? We would have a budget in mind and would not want to exceed that. We would also likely have a schedule in mind, and although the WBS is not a schedule, it helps us ensure things have not been overlooked and therefore helps with scheduling and schedule performance.
(click to enlarge)
The above is a very simple example of what a product-based WBS would look like. Another totally valid approach (especially if the end product is more ‘system’ oriented) is to decompose the product until we reach items where work would naturally happen. For example, design, build and test. Knowing how to handle testing often causes issues too. The simple rule is that test can and often should exist at multiple levels, especially where incremental testing is performed.
Common misconceptions when first seeing one:
When people first see one, they sometimes think:
- there is some form of order (or sequence or flow) being conveyed – there is none at all;
- it somehow is an organisation chart – it is not, but it does help define responsibilities across the project.
The only logic that exists is parent-child relationship as we decompose the work of the project. Ultimately, everything that has to be done on a project should have a natural home within the WBS, i.e. an element to which it naturally belongs.
What should a WBS include?
We can add (almost) anything we like, but once fully populated, each discrete work package (¹) (individual elements of the WBS given to a person or organisation to do and be responsible for) should have:
- summary and detailed description;
- the inputs that are required (to do the work of the work package);
- the major tasks to be done;
- estimates of resources by task;
- any outputs that will be produced (e.g. specifications etc, including quantities where relevant);
- any deliverables that will be produced;
- standards etc that must be employed or complied with;
- assumptions and risks.
Developing a single integrated plan:
It makes huge sense for all of the estimating and planning processes to be driven from a single source or structure. A product-based WBS can give us that source. This means in practice, if we have schedules, the schedule should detail (and hence relate exactly to) the elements of the WBS.
Why product/deliverable based?
- that’s what we are producing;
- product based planning and estimating leads to far fewer gaps and issues in planning and estimating;
- leading to far more accurate estimates of both time and especially resources compared to a functional decomposition of the work (which typically leaves far more gaps or issues); (²)
- it can be the perfect structure around which to organise the work of cross-functional development teams;
- it then provides a hugely useful tool for helping to manage the work of the project in the delivery phase.
What are they used for?
A WBS is one of if not the most useful project management assets you can have on any project. It should be fundamental to:
- defining and capturing the unique scope of any project;
- organising responsibilities around discrete packages of work;
- improving estimating and planning of projects;
- providing the ideal structure for developing and managing project budgets; and finally
- a product-based WBS is the ideal structure upon which to base an earned value management process/system.
What about Template WBS’s – do they work?
No! Many think it would seem to be logical to develop standard WBSs for projects in their business. The temptation to do this is obvious, but it does not work. Projects are unique and the WBS for any project must reflect this. if you do this, one of two things will occur:
- either you will expend a reasonable amount of effort doing this and give up (as we have witnessed many times), or
- if you insist and adopt this approach it can damage the estimating and planning of projects considerably.
- In the defence industry Control Accounts are often used. Control Accounts contain work packages. We have deliberately chosen not to mention this, as it is a defence industry practice, and is only relevant when you have very large projects. For other projects, work packages alone are often more than sufficient.
- This is one example we have witnessed many times. We worked with a medium-sized project-based contracting business which categorised all external customer projects by types 1-3. Type 1 was the largest. They had a history of very poor estimates for category 1 projects – even worse. We worked with them, and they replaced their functionality-driven estimating process with one based exactly on the above. They transformed the accuracy of estimates for category 1 projects, immediately.