Writing the Work Breakdown Structure

February 17, 2012

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.

By the way, this and the next few essays will be under the larger topic called “The Devil is in the Details,” one of my eight tips for project management success.

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

{ 0 comments }

Involve Your Customers

February 10, 2012

First and foremost, this means listening to your customers. Early on in the project, your team must spend time with customers and end users. Make sure the project team understands the requirements from the users’ point of view.

As you move from planning into project development, try to create prototypes of the end product. If the product is a web page, it’s simple to build a dummy page that looks like a user interface but which has no functionality. If you’re building a house, build a model first. If you’re writing a play, test some scenes with friends. The idea is to build a mockup of the product before the “point of no return” decisions have been made. Change is cheap during the prototype stage, but change is expensive once we’ve locked down functionality.

Why build a prototype? Because people are busy and because language is an imperfect communication tool. I can spend hours writing documents and talking about user interfaces but the odds are high that my audience is busy thinking about other things. However, when you sit them down in front of a prototype and say “this is what the product is going to look like,” then suddenly they can focus. Even if they tell you that they hate it, you’ve made progress because now you have information.

Another benefit of involving your customers is that they become invested in the success of the project. It’s easier to manage their expectations because they are close to the project. Finally, if your customers are truly involved, then you can be confident that you’re working on the right project. Don’t forget, if you build the wrong product quickly and effectively, it’s still wrong.

{ 0 comments }

Inspirational Thoughts on Leadership

February 3, 2012

My friend, Jack Perron, sent me this excerpt from a sweet book called The Willows and Beyond by William Horwood. The book is a sequel to Kenneth Grahame’s The Wind in the Willows. For best comic effect, take a moment to read these inspirational words on leadership out loud. In this scene, Toad (who has [...]

Read the full article →

Project Risk and Task Estimation

January 27, 2012

It’s common knowledge that I love Liquid Planner. In my opinion, it allows me to to do magic and foresee the future. ::geek mode on:: Liquid Planner allows you to use probabalistic modeling for any or every task in your schedule. This means that instead of saying that a task will take 5 days, you [...]

Read the full article →

Having a Vision

January 20, 2012

Your team has a good project, one you believe in and which will help your organization to achieve its goals. The next step is to write a good vision statement. You may think that everyone understands where the project is going, but folks are probably more confused than you think. Here’s Scott Berkun on the [...]

Read the full article →

On Being a Change Agent

January 12, 2012

When I introduce project management to my students, I always tell them that my goal in the course is not just to teach them how to do project management. My goal is to change their lives. In part, this is because learning project management is about becoming empowered. No longer will you feel that you [...]

Read the full article →