Work Breakdown Structures
In project management, a Work Breakdown Structure (WBS) is an
exhaustive, hierarchical (from general to specific) tree structure
of deliverables and tasks that need to be performed to complete a
project. The Work Breakdown Structure is a very common and critical
project management tool. It is considered such a key part of project
management that many United States government statements of work
require a WBS.
The purpose of a WBS is to document the scope of a project. Its hierarchical arrangement allows for easy identification of the terminal elements (the actual items to be done in a project). Being an exhaustive document of the project scope, the WBS serves as the basis (indeed, the backbone) for much of project planning. All the work to be done in a project must trace its origin from one or more WBS entries.
How to build a WBS
A WBS is simply an organized presentation of the work required to complete the project. There are any number of ways to organize the presentation of the work. For example, one could organize it according to life-cycle phases, showing each phase as a top-level breakdown. Another way to organize it is by functional responsibilities. A key thing to remember is that the WBS documents the scope of the project, and not the execution plan of the project. Thus, in the house painting example below, 'Prepare Materials' could appear after 'Paint the Room' and it is still a valid and correct WBS.
For more details on the various approaches to building the WBS for a project (see e.g. How to Build a Work Breakdown Structure below). Whether the WBS should be activity-oriented or deliverable-oriented is a subject of much discussion. Even suggesting to pick one style and then sticking to it can be a point of argument.
An example of a work breakdown for painting a room (activity-oriented) is, to state the obvious:
* Prepare materials
o Buy paint
o Buy a ladder
o Buy brushes/rollers
o Buy wallpaper remover
* Prepare room
o Remove old wallpaper
o Remove detachable decorations
o Cover floor with old newspapers
o Cover electrical outlets/switches with tape
o Cover furniture with sheets
* Paint the room
* Clean up the room
o Dispose or store left over paint
o Clean brushes/rollers
o Dispose of old newspapers
o Remove covers
For comparative purposes, a deliverable-oriented WBS might look something like:
* Material Preparation
o Paint preparation
o Ladder preparation
o Brushes/rollers preparation
o Wallpaper Remover
* Room Preparation
o Old wallpaper removal
o Detachable decorations removal
o Floor protection
o Electrical outlets/switches protection
o Furniture protection
* Room Painting
* Room cleanup
o Leftover paint disposal
o Brushes/rollers cleaning
o Old newspapers disposal
o Covers removal
Level of detail
There is no set depth or breadth specifications for a WBS. The context determines if your WBS is too general, or too detailed. Project management is not about performing the work, but rather more concerned about monitoring the work, so a good maxim to follow in preparing the WBS is to go to just enough detail to allow a piece of work to assigned to a resource, and then the status monitored. Of course, there is nothing to stop that resource from developing their own WBS for the work assigned to them.
The size of the WBS should generally not exceed 100-200 terminal elements (if more terminal elements seem to be required, use subprojects). The WBS should be up to 3-4 levels deep. Each level should be 5-9 elements broad. These suggestions derive from the following facts:
1. short-term memory capacity is limited to 5-9 items.
2. having fixed time to plan a project, the more terminal elements there are, the less time there is to pay attention to any single one of them. Consequently, the estimates are less thought-through.
3. the more terminal elements there are the more there are potential dependencies among them (see fact 2 above for consequences).
It is common practice, in medium-sized to large projects, to use a hierarchical coding system, assigning a code to each WBS entry. A top level entry might have (for example) a code of 1,2,3, and so on, while entries under entry 1 may have codes from 1.1, 1.2, 1.3, etc.
Tools for developing a WBS
Project management software, can be very helpful in developing a WBS, although in early stages of WBS development, plain sticky notes are hard to beat for flexibility. It is much easier for a team to work together using sticky notes and a large empty wall than for the same team to cram themselves in front of a tiny computer monitor and one keyboard.
The purpose of a WBS is to document the scope of a project. Its hierarchical arrangement allows for easy identification of the terminal elements (the actual items to be done in a project). Being an exhaustive document of the project scope, the WBS serves as the basis (indeed, the backbone) for much of project planning. All the work to be done in a project must trace its origin from one or more WBS entries.
How to build a WBS
A WBS is simply an organized presentation of the work required to complete the project. There are any number of ways to organize the presentation of the work. For example, one could organize it according to life-cycle phases, showing each phase as a top-level breakdown. Another way to organize it is by functional responsibilities. A key thing to remember is that the WBS documents the scope of the project, and not the execution plan of the project. Thus, in the house painting example below, 'Prepare Materials' could appear after 'Paint the Room' and it is still a valid and correct WBS.
For more details on the various approaches to building the WBS for a project (see e.g. How to Build a Work Breakdown Structure below). Whether the WBS should be activity-oriented or deliverable-oriented is a subject of much discussion. Even suggesting to pick one style and then sticking to it can be a point of argument.
An example of a work breakdown for painting a room (activity-oriented) is, to state the obvious:
* Prepare materials
o Buy paint
o Buy a ladder
o Buy brushes/rollers
o Buy wallpaper remover
* Prepare room
o Remove old wallpaper
o Remove detachable decorations
o Cover floor with old newspapers
o Cover electrical outlets/switches with tape
o Cover furniture with sheets
* Paint the room
* Clean up the room
o Dispose or store left over paint
o Clean brushes/rollers
o Dispose of old newspapers
o Remove covers
For comparative purposes, a deliverable-oriented WBS might look something like:
* Material Preparation
o Paint preparation
o Ladder preparation
o Brushes/rollers preparation
o Wallpaper Remover
* Room Preparation
o Old wallpaper removal
o Detachable decorations removal
o Floor protection
o Electrical outlets/switches protection
o Furniture protection
* Room Painting
* Room cleanup
o Leftover paint disposal
o Brushes/rollers cleaning
o Old newspapers disposal
o Covers removal
Level of detail
There is no set depth or breadth specifications for a WBS. The context determines if your WBS is too general, or too detailed. Project management is not about performing the work, but rather more concerned about monitoring the work, so a good maxim to follow in preparing the WBS is to go to just enough detail to allow a piece of work to assigned to a resource, and then the status monitored. Of course, there is nothing to stop that resource from developing their own WBS for the work assigned to them.
The size of the WBS should generally not exceed 100-200 terminal elements (if more terminal elements seem to be required, use subprojects). The WBS should be up to 3-4 levels deep. Each level should be 5-9 elements broad. These suggestions derive from the following facts:
1. short-term memory capacity is limited to 5-9 items.
2. having fixed time to plan a project, the more terminal elements there are, the less time there is to pay attention to any single one of them. Consequently, the estimates are less thought-through.
3. the more terminal elements there are the more there are potential dependencies among them (see fact 2 above for consequences).
It is common practice, in medium-sized to large projects, to use a hierarchical coding system, assigning a code to each WBS entry. A top level entry might have (for example) a code of 1,2,3, and so on, while entries under entry 1 may have codes from 1.1, 1.2, 1.3, etc.
Tools for developing a WBS
Project management software, can be very helpful in developing a WBS, although in early stages of WBS development, plain sticky notes are hard to beat for flexibility. It is much easier for a team to work together using sticky notes and a large empty wall than for the same team to cram themselves in front of a tiny computer monitor and one keyboard.
Examples of Work Breakdown Structures