A Work Breakdown Structure (WBS) is the best way to understand the detailed work of the project when you have to build a schedule from scratch. It's used to break the project down into the major phases, deliverables, and work components that will be built by the project. These work components can then be broken down 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:
#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 of 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.
By using these five techniques, you will save you time and rework on your next WBS.Get weekly PM tips in your inbox TechRepublic's IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!