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