Work breakdown structures help define project scope

By Geoff Choo

One of the hardest parts of planning any project is also one of the easiest ways to screw it up: clearly defining the scope of a project or, in other words, understanding what’s included in a project and what’s not.

Proper scope definition is critical for a project’s success. A work breakdown structure (WBS) can help you define the scope of your project by taking the scope statement and subdividing the major project deliverables into smaller, manageable packages of activities. In this article, I’ll explore the use of a WBS and how it can help guide your projects.

Building the WBS
A WBS is built around a hierarchy of deliverables or tangible outcomes. Each deliverable or outcome will have a set of related activities, and one individual will be responsible for each activity.

A WBS shouldn’t just be a to-do list of every possible thing that needs to be done in the project; rather, it is a collection of assignments that members of your project team will be responsible for delivering.

Here’s a quick look at the WBS process and its use within a project:

The WBS process

As a project leader, you should create the WBS in iterative cycles and constantly reevaluate the hierarchy of deliverables, activities, and subactivities. You should also validate that you have broken down every deliverable into all the high-level activities required to complete it.

Then, decompose every activity into more granular activities in iterative cycles. Next, validate that you’ve included every subactivity required to complete that higher-level activity.

At the end of every cycle, ask yourself and your team members these three questions:

• If I had all these deliverables, would I achieve the planned objectives for the project?
• If I do all these activities, will I complete that deliverable?
• If I do all these subactivities, will I complete that activity?

If the answer is no, retrace your steps and fill in the missing elements.

Tips and techniques for WBS
Here are some suggestions on how to approach a WBS:

Name smartly
Name all deliverables as noun deliverables or adjective/noun deliverables, such as “Creative Brief” or “Functional Specification.”Name activities as active verb/adjective/noun deliverables. Examples include “Create Creative Brief” or “Update Functional Specification.”

By adding the active verb, you communicate better to the assigned team member not only what the outcome is (the deliverable) but also what kind of work the assigned person is going to perform (create or update). (Note: Don’t use weak verbs like “do,” “execute,” or “perform.” They do not clearly communicate what outcome or result is expected.)

How granular should you get with a WBS?
You won’t find any hard-and-fast rules on how granular a WBS should get. It all depends on the complexity of the project, the level of risk, how skilled your team is, and how much detail is required to maintain the necessary level of control.

If you’re working with a skilled team, for example, you could probably get away with a shallower WBS. If you need more control on a complex project, the WBS should be decomposed as deeply as you can realistically go. Generally, the deeper the WBS gets, the smaller (and shorter) the activities become. Don’t go too deep, though. There is a logical limit to how deep a WBS should get and how small (or large) an activity should be.

A general guideline that I like to follow is that each lowest-level activity in the WBS should be assigned to a single individual, and that individual should be able to complete the activity in one to 10 working days.

Anything smaller than one day and you’ll end up with a 100-level-deep WBS with a huge list of five-minute tasks. Any bigger than 10 days and you might not have enough detail to effectively control the status of that activity.

Don’t spend all your time generating long to-do lists
The smart project manager doesn’t try to micromanage the team with mile-long lists of things to do. Instead, give themclear and measurableobjectives and results and then let each team member define the tasks to reach those goals.

This means that while you may define the deliverables and high-level activities, your team will fill in the blanks with the lower-level activities. Work with them to write down the lowest-level activities that you will use to track their progress.

Geoff Choo is a project manager for Invisible Site, an Italian interactive media agency, and a freelance business and technology writer. He also helps produce NetStatistica Report, a free monthly newsletter that provides Internet economy demographics, statistics and facts.

This article was originally published on gantthead on Jan. 14, 2002.