Pages

Friday, August 26, 2011

Beginners Guide to Project ManagementPart 07, The Work Breakdown Structure

This is the 7th part of the "Beginners Guide to Project Management" and it will push the planning phase one step further with the Work Breakdown Structure or WBS. This technique is focused on what is to be delivered with the project, so it seems like the perfect place to start. Basically, a WBS is just a hierarchical tree that defines the entire scope of the project.

What is a WBS for?
The main purpose of a WBS is to give a picture of what the project is all about by showing all the deliverables. It’s not a plan, a schedule or an organization chart. It contains only deliverables - not activities and tasks.
With a WBS you can also:

Cross check if you’re not forgetting something on your schedule

Make sure that everything on your schedule is contributing to some deliverable

Help you with the rest of the planning, including risk identification and even communication planning

Also, as a WBS is a bit static (much more static than a schedule anyway) it is very useful for in-scope / out-of-scope discussions - if it’s not in the WBS it’s out of scope for sure. Of course a WBS can change along a project but that should only happen after some kind of approval process, even if an informal one. And everyone at least in the project team should know about the scope change.

How to build a WBS
Although a WBS is usually a hierarchical tree, like an organization chart, you can use whatever representation is suitable. One tool I use a lot for WBSs is a Mind Map - with the great advantage of giving just enough detail as needed. Paper can be fine too. Or you can use a Project Management tool such as Microsoft Project - as long as you don’t confuse a WBS, a schedule and a Gantt chart.
To build a WBS you start with your project name. To give an example, suppose you are to hold a fund raising event based on a wine tasting event. You could start thinking about it on a time perspective, what to get done first. So you’d probably start thinking about what you needed to get things started, then what you needed to plan, the preparations for the event, what was needed to do to setup everything, what was needed to do in the day of the event and to wrap things after it was all finished. Oh, of course, and what Project Management deliverables were needed. Here’s a possible WBS in the form of a Mind Map for this project:

Other perspectives
You don't have to use a time perspective to build a WBS. You can also use a department or functional (organizational) perspective, a geographical perspective, a cost center perspective and so on. Use whatever suits your particular project best.

Rules for building a WBS
Although this WBS looks very loose in the sense that it’s just a diagram / drawing, you must take care and follow some basic rules so you won’t be sorry sometime after. These rules make all the sense, but check them for yourself and check what would happen if you failed to follow any of them:

Complete

Whatever you have in one level of the WBS, it must be exactly the same as the sum of the level below. If the level below is just a detail of the level above, they represent exactly the same thing, right?

8/80 rule

The last work package in any branch should take more than 8 hours and less than 80 hours to complete. This is just a rule of thumb, but it’s OK for most projects. If you’re building a WBS for a 25 year project, this probably would make the WBS so huge that it would lose its graphical impact, so be flexible with this one and do take it as a rule of thumb. One way around this, and thus the use of Mind Maps and collapsible branches, is to detail your WBS using this rule even in big projects but to show collapsible models as fit so the WBS regains its graphical benefits.

Deliverables

The last work package in each branch should be a deliverable, not an activity or task; and they should be represented by a noun, the name of the deliverable. But specially if you’re building a time phased WBS, there could be “almost activities” in the WBS in the sense of phases like planning, developing and testing. No problem whatsoever, as long as you can tell them apart.

Decomposition

If a work package is decomposed, it has to be decomposed in more than one work package. There’s not much sense in having a work package decomposed in just another work package, right? That would be repetition, not decomposition.

100% of the scope

If something is in the scope of the project, it must be in the WBS and if something is in the WBS it must be in the scope of the project; that is, the WBS must always be a perfect match with the project scope. This is the most important rule and it will allow you to use the WBS in many ways, including helping you schedule the activities in your project.

Consistency

The used criteria for telling apart any 2 work package must be the same. May seem just a detail but it does sound reasonable, no?

Conclusion
Although pretty basic, the WBS technique to represent the project scope is very useful as it forces everyone involved to share the same view of the project. It can help you along with the other planning activities and it has saved me many in-scope / out-of-scope discussions. I must add that changing the scope of a project so much that you have to change the WBS is not a bad thing, but you must know that it is changing.
I use WBSs even in very small, 2 week projects. If not for any other reason, it sets the ideas straight in my mind - and a small project must have a small WBS...