Home > Articles

  • Print
  • + Share This
From the author of

Creating the Work Breakdown Structure

Once the scope statement has been written, it's time to break down. Well, not you, the scope. A Work Breakdown Structure (WBS) is a deliverables-oriented decomposition of the project. It is not the activities needed to create the project deliverables; it's the stuff that the activities create.

Gasp!

That's right. A WBS is not the work, but the deliverables. Some folks in the IT world (I won't mention them by name, but their initials are Microsoft) have skewed this a bit. If you've ever used Microsoft Project, a great tool, you may have been led to believe that the activity list, the default view in Microsoft Project, is the WBS. It isn't so.

A WBS is not the activities but the actual deliverables that the customer expects from the project work. Suppose that we were going to install a network from scratch in five different locations around the country: northern California, Tacoma, Philadelphia, Atlanta, and L.A. We'd have some major categories of things for our project:

  • WAN

  • LAN

  • Operating systems

  • Education

These major categories of things can be broken down again to more things that we'll be delivering in the project:

  • WAN

  • Routers

  • Switches

  • ISP contracts

  • WAN diagram

  • IP addressing schemes

  • LAN

  • Switches

  • Patch panels

  • Wall jacks

  • LAN addressing schemes

  • Operating Systems

  • Servers

  • Workstations

  • Education

  • End user education

  • IT professional education

See how the deliverables are decomposed into more things? We're decomposing the project scope into things that the customer will get as a result of the project. Stuff, not activities. The end result of the WBS is a clear picture of what the customer will and won't get as part of the project.

So how far should you break down the project deliverables? You could (not that you'd want to) decompose your WAN deliverables down to the nuts and bolts in the rack that'll house the hardware.

You want to follow the "8/80 Rule" when you break down your project scope. The 8/80 Rule, which really isn't a rule but a guideline, requests that the smallest deliverable in the WBS, called the work package, equate to no more than 80 hours of work and no fewer than 8 hours of work to create that deliverable. You don't want to get so granular or so vague with your WBS that it's uncontrollable and useless.

But why even bother creating a WBS? There are a bunch of reasons why an accurate and complete WBS needs to exist, but there are five prominent reasons why every project needs a WBS (discussed in the following sections).

Cost Estimating

Because a WBS requires you and your project team to account for everything you'll be creating, you can create very accurate cost estimates of what the project will cost to complete. This estimate, which comes a bit after your rough order of magnitude estimate (ROM), is called the definitive estimate, and it is the most accurate. You may know ROM estimates referred to as hallway estimates or ballpark estimates.

Cost Budgeting

Cost budgeting is the actual money committed on a project deliverable. Once the cost estimate has been created, we have to track the actual time and materials expenses that went into creating the WBS deliverable. The difference between what was estimated and what is actual is the cost variance. Cost budgeting allows the project manager and management to track the cost baseline of the project.

Resource Planning

How do you know how much help you'll need to complete the project? Most project managers rely on expert judgment, experience, and gut feelings, but the WBS reveals the deliverables and the required talent to create the deliverables. For example, in our WAN/LAN project, one of our deliverables might be Cisco routers. This deliverable might require us to hire or contract a CCIE to configure our network.

Risk Management Planning

Risk is an uncertain event that can have positive or negative effects on our project. The WBS allows us to consider the circumstances and conditions of each deliverable for risks within our project. Once we've identified the risks, we can then shovel them through qualitative and quantitative analysis to capture which risks we need to mitigate and which ones we can live with.

Activity Definition

Sigh of relief, right? Once we have the WBS created we can then define the needed activities to actually create the deliverables that the customer is waiting for. We need to identify all the deliverables that the project will create so that we can identify all the activities to create the project.

  • + Share This
  • 🔖 Save To Your Account

Related Resources

There are currently no related titles. Please check back later.