- Defining the Project Scope
- Documentation Means Everything
- Creating the Work Breakdown Structure
- Decently and In Order
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.