A Work Breakdown Structure: What It Is and Why You Might Need It

• Unito home /
• Blog /
• A Work Breakdown Structure: What It Is and Why You Might Need It

Published in Project management on 24/06/2020, last updated 02/06/2023.

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 to create a work breakdown structure

Making sure all the work a project needs is represented in a single document might seem daunting. But you can easily build a work breakdown structure for any project by following five steps. Here they are:

Define the scope, goal, and objectives

Before you start figuring out who needs to do what, you need to ask yourself what the project is for. That means figuring out your project’s scope, goal, and objectives. While these might sound interchangeable, they’re not:

• Scope: How much are you trying to get done with this project? Defining this early keeps your project from falling victim to scope creep.
• Goal: What is your project trying to accomplish?
• Objectives: What are the specific checkpoints your project needs to cross on the way to its final goal?

Identify phases

This process comes right after defining a project’s objectives. Think of each phase as all the work that happens between each objective. You then want to hammer out a rough estimate of how long each phase should take to complete.

List deliverables

A deliverable is a specific product, service, or document that is completed through a project. If, for example, your project is reworking a website’s home page, the new home page itself is a deliverable. But so are new copy blocks and graphical elements.

Define work packages

Now that you know what your deliverables are, it’s time to figure out what needs to get done to, well, deliver them. That means breaking down each task that needs doing. For a web page, that means creating tasks for the work a web developer will have to do, the designer, and the writers. Then, you need to group them into these packages.

Choose task owners

After fully breaking down all the tasks your project involves, you need to assign them to people. While your inclination might be to put them on a manager’s plate, your project will actually be well-served by giving individual reports accountability.

Elements of a work breakdown structure

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.

Say “when”

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:

1. 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.
2. 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.
3. 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.

Examples of a work breakdown structure

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

Marketing campaign

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.