If I had to identify a single method/tool/process that is a must for project managers, it would be the Work Breakdown Structure (WBS).  Yet, I am always amazed that in some of the advanced workshops that I conduct on project management very few practitioners understand what a WBS is and how to develop a good WBS that will help in project planning.

Fortunately, this week I am teaching a basics workshop on project management so my expectations of the participants knowing about the WBS is fairly low.  This is the one topic that I try not to rush through, even if it means that I go over its alloted time within the workshop outline.  The place that I usually begin is with the standard definition of WBS out of the PMBOK Guide, which states:

“A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables.  It organizes and defines the total scope of the project.”

Within the project management community there are two views of WBS development.  One group focuses on identifying the tasks that are needed to be accomplished on the project.  What this means is that they like to identify all the “verbs” associated with project.  In this case, the argument is that by identifying the activities, one is able to generate the schedule out of the WBS.  In some scheduling tools, there is even the option to produce a pictorial view of the schedule as a WBS.

On the other hand, there is another group that is focused on identifying all the work products that need to be delivered by the project team.  What this means is identifying all the “nouns” associated with the project.  I am a supporter of this later view.  By working on defining all the work products, we are able to generate a list of the deliverables of the project. Task identification, estimating, and scheduling are indeed follow up activities are are in my opinion not part of WBS development.

Here are some good tips that have served me well in developing the WBS:

• Focus on the what not the how.  “What is it that we are trying to do, not how?”
• The WBS is a team activity, it should involve key stakeholders, not the project manager alone.
• Allow the team the opportunity to brainstorm using post-it notes so that they can work both in a top-down and bottom-up fashion.  This will allow for multiple working styles.  Those who like to start with the big picture and those who like the details can both be happy doing brainstorming in a way that makes them comfortable.
• “Bad ideas” should be encouraged during brainstorming to allow for deliverable groupings later.  The benefit in capturing a deliverable that perhaps is outside the scope is it can be parked on a separate sheet and later documented as such.
• Ensure that the team documents assumptions and later use these assumptions as a potential input to risk identification.
• Don’t be constrained by attempting to sequence deliverables, that comes later.
• Ensure that the team documents internal and external deliverables.  Within IBM we used the term work product for internal deliverables to distinguish it from deliverables that go into a statement of work.
• Capture both project deliverables as well as product/service deliverables.  Many teams often forget that a project charter and a project plan are actually deliverables that should go into the WBS.
• Use the opportunity of developing the WBS as a team building activity to bring the team together and accelerate the stages of team development.
• Remember the 80 hour rule for the work packages.  At the bottom level of the WBS, there are work packages.  These work packages are deliverables composed of tasks that should add up toe 80 hours worth of effort.

The benefits and uses of the WBS are many. By identifying the total scope of the project through a deliverable composition, the WBS supports the project team to achieve the following:

• Understand what is “in” and what is “outside” the scope of the project.  If it is not listed, then it is out.  This process can allow the project team to document that a given deliverable may be outside the scope.
• Envision potential areas of risk, based on the assumptions that are documented.
• Build a foundation for developing a solid project baseline and each work package can be used to identify key tasks within the 80 hour rule.
• Communicate with stakeholders regarding potential requirements that could be met based on a mapping between requirements and deliverables.
• Establish clear accountability for work packages and assigning champions/owners.

There are many other tips and benefits for the WBS, such as the coding system that can be used or leveraging the the WBS during the execution phase and controlling process.  While each of these are important considerations, my focus for this post has been on using the WBS as a solid anchor for the team during the planning process.

I will close by emphasizing that a good WBS can indeed be the differentiating factor between a successful project and a failing one.  Those who are not familiar with it or don’t know how to create it need to spend the time reading through the PMBOK Guide and other books that have relevant information.