Five tips for building a work breakdown structure

Tom Mochal offers some practical advice to save you time and rework on your next work breakdown structure.

A work breakdown structure (WBS) is the best way to understand the detailed work of a project when you have to build a schedule from scratch. It lets you break the project down into the major phases, deliverables, and work components that will be built by the project. You can then break down these work components into the activities that are required to build them. The WBS is not the same as the final schedule (which requires sequencing, resources, estimated effort, estimated duration, etc.). Here are five tips to keep in mind when building your WBS.

Note: These tips are based on an entry in our IT Leadership blog.

1: Create a WBS dictionary for large projects

Normally, you wouldn't need a WBS dictionary. But if your WBS has hundreds (or thousands) of detailed activities, there may just be too much to keep track of by hand. In this case, it might make sense to place all the important information in a WBS dictionary. The dictionary helps keep track of all of the summary and detailed activities, including a short description, the WBS numeric identifier (1.1, 1.1.1, 1.1.2, etc.), and the estimated effort. If you enter your WBS dictionary into a specialized tool, the tool can also help to keep track of changes to the WBS as well.

2: Use the summary activities as milestones

Your WBS should contain both detailed and summary activities. (A summary activity is one that is broken down further; a detailed activity is one that is not broken down further.) Although a schedule usually includes only detailed activities, it makes sense to include the summary activities as milestones (i.e., markers signifying that a deliverable or set of deliverables is complete). A summary activity can be used as a milestone since it would indicate that all of the underlying detailed work has been completed.

3: Break activities into two or more detailed activities

I've seen teams that break one activity in the WBS into only one activity at the next level. In my opinion, this doesn't make sense because then the detailed activity represents the same work as the prior summary activity. This doesn't buy you anything.

4: Make the final detailed activities action oriented

The detailed activities on your WBS (the ones that are not broken down further) are ultimately moved to your schedule. For that reason, it's easier if the detailed activities in your WBS are action oriented -- just as activities in your schedule would be. For example, instead of describing a detailed WBS activity as "meeting," you should state it as "schedule a weekly meeting." Instead of having a WBS detailed activity for "Testing Plan," you should state it instead as "Create Testing Plan." In this way, the detailed activities can be moved to the schedule with a minimum of wording changes.

5: Don't place requirements on the WBS

If you place a deliverable on your WBS, you can break this deliverable down into the activities that are required to create it. You don't break a deliverable down into the requirements that describe it. Requirements do not belong on a WBS. Only deliverables and activities belong on the WBS.