Vicki James, PMP, CBAP, PMI-PBA, CSM

There is an ongoing confusion in the world of project management regarding the Work Breakdown Structure (WBS); should it be deliverables based, activities based, or a mix? For instance, Microsoft Project refers to line items as tasks and assigns a WBS number to each task, yet according to the Project Management Body of Knowledge (PMBOK) it is “…a deliverable-oriented hierarchical decomposition of the work to be executed…to accomplish project objectives and create required deliverables…” (PMBOK 4th Edition, page 116). I have found many reasons why a deliverables based WBS is preferable to provide benefit to project planning.

You must first define what you need before you can define what you are going to do. All tasks that we perform are in support of a specific deliverable. I’m going to use the analogy of cleaning the kitchen to make my point. You can ask your (kid, significant other, housekeeper) to “do dishes”. However, you are likely to be disappointed in the end result if the dishes are clean yet the counter and floors are dirty. Going back to our PMBOK definition, a WBS for the intended result may look more like:

1. Clean Kitchen
1.1. Clean/stored dishes
1.2. Clear and clean counters
1.3. Clean Floor

* “Clean” and “clear” are used as adjectives in this context

From here we can go from the WBS to defining and planning the activities that will provide the expected outcomes (or deliverables).

A complete WBS will help ensure that all deliverables are defined and agreed to by the sponsor. Think of the software development project where the deliverable of a training program is not articulated as in, or out of, scope. If it is not listed as a specific deliverable in the WBS then it is not in scope as it was not purchased by the sponsor.

A WBS presented at the appropriate level is a much more concise way to agree on the work of the project team. Take a second to review the Clean Kitchen WBS above. How many tasks can you identify in order to ensure a quality deliverable? I can list about 10, however, none of these add value to scope definition itself, but they will help the team ensure quality delivery of the product. A task of “drying dishes” helps the team guarantee that stored dishes will be dry and free of water spots.

With the mention of “team” I want to make sure I discuss the development of the WBS. This is not something that the Project Manager and/or Sponsor can do in a vacuum. While the highest level of the structure may come from the sponsor’s scope definition, it takes full team participation to get all of the team’s deliverables defined. Some completed items may be presented directly to the sponsor, but many will delivered only within the team (test plan, design document, etc). When working with teams to develop WBS’s I ask team members to think about their personal deliverables to support the overall project. Next I ask them to think about what deliverable they need from others. This isn’t done as a brainstorm, but rather individual lists. The lists are then compiled and reviewed as a team. Some items will be found in duplicate and additional items will be identified as all team members review the context. Team members can ask for and provide clarification on the expectation and need for each deliverable and finally identify dependencies amongst the items. This information provides a complete basis for task identification, sequencing, estimating, and schedule development.

~~~~~~~~~~~~~~
Another excellent WBS Article, with special mention of WBS Chart Pro, an awesome tool – http://projectsolversblog.com/2011/07/05/benefits-of-the-work-breakdown-structure/