You know your end goal, you’ve got your deadline, and the budget’s been set. Now comes the Herculean task of planning out your project and assigning deliverables. That’s where the work breakdown structure comes in.
With a deliverable-focused approach to project management, this methodology might be just what you need. Here’s how it works.
What is a work breakdown structure?
The work breakdown structure method (or WBS for short) was first developed by the United States Department of Defense (the DoD). It was originally created for the Polaris missile program, then adopted for other projects by the DoD, NASA, and the aerospace industry at large. The WBS was created for huge projects with tons of moving parts—both literally and figuratively. So what is this methodology?
The work breakdown structure is a hierarchical breakdown of all deliverables required for a project to be considered complete. It’s usually broken down into two or three tiers, from the project itself down to the smaller deliverables. Here’s what a work breakdown structure would look like for a bicycle:
The first tier of this plan is the main deliverable: the bicycle itself. From there, the project is broken into seven main components, from the physical construction of pieces like the crank set to the management of the project itself. Then each of those sections is broken down into the key deliverables needed for completion. For example, the frame set is broken down into the frame, the handlebars, the fork, and the seat. This way, you can track how close the frame set is to being finished and compare it to the bike’s other components.
The flow chart is just part of the way the work breakdown structure is represented. Notice that each part of the chart has a number associated with it. For instance, the wheels are coded as 1.3, while the front wheel is 1.3.1. This is done to streamline communication. Not all communication channels can support the visual representation of the WBS, hence the need for a simple numerical code that represents each part of the structure.
That’s the gist of the work breakdown structure. It breaks down work that seems huge and complex—like building an airplane—into manageable chunks. Now how do you go about doing this?
How does it work?
When you’re not familiar with the WBS, it can be hard to draw the line at just how far the “breakdown” part of the work breakdown structure needs to go. Here are some rules to keep in mind when creating your own WBS:
The 100% rule
A project’s work breakdown structure has to cover all the work required to complete it. This rule is pretty simple in theory, but it can be difficult to stick to. Your WBS doesn’t have to show every single task required to complete a project but all the deliverables need to be there. Refer to the bicycle example above. Not every nut and bolt on the bicycle is accounted for in this structure, but all its essential parts are. For your WBS to be complete, there can’t be any essential work not featured on your graph.
Deliverables, not tasks
A project like building a missile has a lot of moving parts. If you tried breaking it down into each task that needs to get done along the way, your WBS won’t be any use. While no one reading this is hopefully not building missiles, your projects can end up just as complicated and convoluted.
When you use the work breakdown structure, you need to break your project down into the specific items you need to call the project complete. If your project is building a website, for example, you won’t be breaking it down into things like “review the homepage” and “create copy.” Rather, you might break it down into the different pages the website needs in order to be called complete.
While there will still be coding, design, and writing tasks behind each page, the WBS can still follow the 100% rule if it’s broken down by page rather than task. That’s because it’s much easier to break down your work into deliverables than into tasks; otherwise you’re likely to include too many or too few tasks.
This is the big caveat to the 100% rule. While your WBS needs to represent all the deliverables that make up your project, it’s easy to get carried away and keep breaking things down until you have a giant, unwieldy flowchart that no one can read. You need to find a stopping point. Here are three things to keep in mind while creating your WBS:
- The 80-hour rule: Any activity or deliverable at the lowest level of your structure shouldn’t take more than 80 hours of work to complete. If your deliverable needs more hours than that, it’s worth breaking down further. If the reverse is true across your structure’s lowest level, then you’ve probably reached a good stopping point.
- Keep it within a single reporting period: What is your project’s reporting period? A month? Three? A couple weeks? Deliverables at the bottom of your structure shouldn’t take longer to complete than a single reporting period. If your project demands quick turnaround times, you’ll probably have more levels in your hierarchy.
- Common sense: When the rules fail, ask yourself “do I really need this level of detail?” Training and knowledge are good metrics to follow when creating a WBS, but so is your gut. If breaking work down further doesn’t make sense, don’t do it.
The work breakdown structure in practice
Like many project management methodologies, the work breakdown structure had its start in manufacturing and it’s now being used in a number of other fields. Here are a couple examples of common projects, and how they might be represented by a WBS:
Building a website
Software feature development
Break it down
The work breakdown structure can be used for a number of projects across industries. Its manufacturing roots show that it’s a robust methodology, and its staying power demonstrates its flexibility. Adding the WBS to your project management toolbox might just make that mammoth project a lot more manageable.