Project Management

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.

7 comments
bergenfx
bergenfx

a good reason for excluding a reference to requirements (cited in item 5). I am sure you know that one of the primary reasons for project failure is inadequate requirements fulfillment. Whether or not it fits the formalized planning and development process standards of the day, traceability of requirements from analysis through testing is essential. If you have a another way of maintaining that traceability, fine. But I wanted any plan I saw to achieve that traceability. I personally find mapping requirements into WBS and then further downstream as well, to be an easy, common sense way to ensure what is being built is both necessary and sufficient with respect to requirements.

wspuck
wspuck

These tips are valuable advice, but I think a big one was omitted: linking the WBS to products. There are two ways of thinking about this. One way is to observe that every WBS element represents effort (work). All work should result in a useful product, else why do it? While I fully agree that a WBS element should be described by a verb (an active verb), it's really valuable that that verb be linked to the product of the effort. An example might be "create project plan." The other way is to observe that a project is also a unit of work (a bigger unit), and the purpose of a project is to create a product (let's call this product a system just to distinguish it from products in general). Further, a system by definition (see Wikipedia or another dictionary) is made up of subsystems, the subsystems of sub-subsystems, and so forth. Each of these components must be made,and this means work on each. Therefore the core of a WBS should be the work necessary to design, make, and integrate the components of the system. In short, then, a WBS should be product-oriented. The hierarchical structure of a system is frequently described in a tree structure like a WBS. this system tree structure is generally called a Product Breakdown Structure. A good way to get to a WBS, then, is to develop the PBS for the project's system and then map the products to the work necessary to produce them; that is, to map the PBS to the WBS. The link between too many WBSs and the system the project was created to implement is often missing. This missing link is often the cause of project failure.

ndsatya
ndsatya

I swear by PMI/PMP principles here - creating WBS. In fact, PMP and MS Project 2007 are quite the same - the later being a theoretical. Here is one: http://art-of-project-management.blogspot.com/2008/08/pmbok-pmp-and-ms-project-2007-synergy.html I'll put more shortly. 1. Create a WBS dictionary for large projects In fact, WBS dictionary should be there for all of the projects. It helps you to give an intial time frame, an initial cost estimate, the account to which it belongs to, along with other side benefits for detailed explanation for each work package for individuals team members. And is not WBS an a team building tool - which you correctly mentioned in the linked piece? 2. Use the summary activities as milestones It is not the fact. Fundamental in project management - milestone is of zero duration! And when you talk of summary activities, it will have the estimation of other activities bottomed up. So you will have a time duration! 3. WBS should not have much activities to be shown up. It should have only work packages. Now which can be taken as work package is described here: Why? 1. WBS is used in planning stage - you do not know all the activities which can be assigned to 1 person. 2. A WBS looks like an inverted tree when displayed diagramatically. Can you imagine, how long it can grow? It need not be till the activitiy level which can only be assigned to 1 person. http://art-of-project-management.blogspot.com/2008/05/work-break-down-structure-wbs.html 4. Make the final detailed activities action oriented I fully agree here. The activity should start with a verb, rather than a noun! However, in the WBS you need not have it. 5. Agreed. To have a WBS created using the PMI priciple and using MS Project 2003/2007, I'll post one article later!

santeewelding
santeewelding

Why your response would reflect the nature and character of the original. The original was bloodless.

Dave Baker, PMP
Dave Baker, PMP

A WBS and MS Project are NOT the same. While MS Project can be a very powerful tool to organize the results of the WBS process, it is no substitute for the analytical process that is the WBS.

ndsatya
ndsatya

Thanks Dave. Typed too fast after being excited to open and felt a sense of dejection! You are right, they are complimentary. Satya Dash, PMP

Editor's Picks