WBS – Facilitated Change

One of my office neighbors asked me about how I handle “problem” team members. His examples were:

the team member who doesn’t provide good estimates
the team member who doesn’t stop talking in meetings

In each case, and I argue, in most cases, there are no problem team members. I firmly believe that most people want to do their job well. However, people are often misunderstood, or they don’t understand what they’ve been asked to do.

As project managers, we must ensure that we don’t jump to conclusions. Just because we have a clear picture of what needs to be done, that doesn’t mean that anyone else shares that understanding. We must use the tools of project management, especially the Work Breakdown Structure, the Schedule, and the Risks List, to build that shared understanding.

Here’s my take on the answer to my friend’s specific questions. First, the person who has trouble estimating has a lot of company. Few people estimate well when they start out. That’s why I’m such an advocate for time tracking. Until a person builds up a history of how it long it takes to do certain tasks, it’s very hard to develop accurate estimates. I use Liquid Planner every day, and I take advantage of its timing feature to keep track of how well my effort estimates match my actuals. Second, when dealing with someone (like myself) who talks a lot in meetings, it’s important that the meeting facilitator explicitly asks the quieter members of the team to speak. There are kind and gentle ways of telling the extrovert that you’re grateful for her comments, but that you’d like to hear from others as well.

The WBS is a mythic document in Project Management. Every text reminds us that the WBS is the foundation of the project plan. But what the heck is it? Perhaps appropriately, I’ve found a lot of mythology on this topic. So let’s talk about what it is and how to build it.

I should begin by saying that experts differ. I belong to the school of “Effective Work Breakdown Structures” as outlined by Gregory Haugen in his book of the same name. Thus, we are believers in the deliverable-oriented work breakdown structure.

Simply put, the WBS is an outline of all the major deliverables that will be produced as part of your project. The key is that we are talking about the nouns, the (mostly) tangible objects that will be created through project work. Those items about which we can say, “once we have all of these things, the project is complete.”

Most people have trouble with this concept at first. We have often been trained to think in terms of the activities, that is, the verbs, rather than the deliverables or nouns.

There are several ways to create the WBS. If you’re finding that you are focused on those verbs, then do a sticky note exercise. Write one activity each on a bunch of stickies. Then find a nice blank wall and arrange those verbs so that you can see which deliverable should result from each set of activities. This is a bottom-up approach.

Another approach is to begin at the top. Think about the largest categories of deliverables. Usually these consist of things like:

Research
Design
Construction
Documentation
Test
Project Management

Then decompose those major deliverables into one or two smaller categories. Thus, under Design, we may have both Database Design and Website Design. The goal is to keep the WBS fairly high level. I don’t like to see WBS documents which are longer than one or two pages (which is related to another topic: keep your projects small and manageable).

However, you do need to make sure that 100% of the project-related work is represented on the WBS. For example, say you forgot to list Documentation as a deliverable but you know that there will be documentation work that must be done. In that situation, the WBS would not be an accurate reflection of the work and all the future prject management documents would underestimate the resource needs of that part of the project.

One final thought: meetings are not deliverables, but that’s a topic for a future essay.