One of the things that makes the WBS so likeable is that it's very simple, readily comprehensible and consequently, rarely needs much by way of explanation. The product breakdown structure is an excellent tool of communication to illustrate a project's scope. The work breakdown structure is a slightly more focussed tool, but nevertheless is a great way of engaging with resource brokers.
Here's a few of the things I keep in mind when constructing a work breakdown structure.
1. Proportionality - I decompose elements of the WBS to a level that 'makes sense'. This is often informed by early assessments of the volume of work and who's going to do it.
- Estimating is more accurate when work is broken down into small chunks. 6 separate work breakdown structure elements of 3 or so days each tends to be more reliable than one of 18 days.
- There's some logic in breaking tasks down to a level of work that can be completed by one person only - this has some benefits when manipulating and scheduling the project plan in software
- Resource brokering - ideally, I'd like each element of the WBS to be undertaken by resources brokered through a single individual. Or to put it another way, I want to go and see one team leader about a job, not two or more. The resource brokers are likely to be happier about this too as it reduces constraints in resource planning.
2. Manageability and maintainability - I usually create the WBS in MS Word - there's a couple of hierarchical structures in the SmartArt feature that lend themselves quite well to the creation and maintenance of the WBS. I find the 'Organisational Chart' works well. Microsoft tend to pick and choose which features they include in any given version of a piece of software - I use MS Office Professional Plus 2010 - other versions may differ. If they get really big then you could use some like MindJet's MindManager, but there are some practical points to be born in mind. The WBS above was created in Google Docs.
- You do want to be able to produce this on a single page (whatever it's size) - a multi-page WBS is probably more like multiple WBSs
- If it's getting unavoidably big, you lose some of the benefits such as the WBS being a readily comprehensible tool of communication
- The bigger the WBS the more likely errors will creep in
- I find a three tier WBS works quite well for most of my work and if things are getting beyond that then I tend to segment the work into more manageable stages.
- If you've got, by necessity, a very large WBS under constant edit and amendment by multiple parties, you're going to need a different tool - they do exist.
3. A requisite level of detail - while there is a little bit or wriggle room, if work needs to be done and resource needs to be brokered it must be on the WBS
- There is an obvious conflict here in terms of keeping the WBS simple enough to work with. This is readily managed by taking the WBS elements within the WBS and elaborating them further in other products (more on this in another post) but so long as we have a WBS element with a unique identifier - we can (and do) expand this elsewhere.
- Certain things don't go in the WBS. These mostly relate to work that generally comes under the heading 'Level of Effort' or LOE or the effort relating to project management processes themselves.
- In my illustration, I've included quality activities (the snagging and building control sign-off) this is a good way of seeding quality through-out the activities and illustrating this to all parties early on.
- I've also included certain activities like estimating and make or buy decisions
4. And generally - the following can be helpful to keep in mind
- Generally speaking, left to right and top to bottom reflect the chronological sequence of events. This isn't critical, but can just assist the overall readability
- I haven't identified a reason why the elements need unique titles - happy to hear otherwise, but you must have a unique identifier
- Avoid trying to incorporate too much detail at this juncture (dependencies, resourcing and scheduling) this isn't the tool for the job
- Peer review is vital - you're unlikely to be a subject matter expert across the whole WBS - get the appropriate individuals to formally review and approve specific parts of the WBS - you must be on a firm, consensus led footing when this activity is finished.
The next few posts will take the WBS above and supplement it with additional detail to make it a self-contained resource. We'll start to look at the WBS dictionary and product descriptions too.