What Is a Work Breakdown Structure in Project Management?

A work breakdown structure (WBS) is a fixture in classic project management methodology and systems engineering that breaks a project down into a hierarchy of deliverables and tasks. It’s a simple, yet methodical, way of organizing and understanding your project scope in smaller, manageable components.

Essentially, using a work breakdown structure enables you to take a top-down look at your project and break it into the tasks and subtasks that will get you to completion. It’s a helpful tool that defines a detailed cost or time estimate and provides guidance for schedule development and control.

Why use a work breakdown structure?

There’s no doubt about it: Estimating projects can be confusing and somewhat difficult. But creating a project estimate doesn’t have to cause you heartburn. Asking questions, analyzing needs, and breaking your scope down into chunks can help.

Creating a work breakdown structure for any plan or set of tasks helps you get granular about the work that needs to be done on any given project. If you estimate your projects based on units—whether it’s weeks, days, or hours—using a work breakdown structure will help you understand very quickly if your estimate will exceed the intended budget or deadline.

How to create a work breakdown structure to estimate projects

When you’re comfortable with the overall process of creating a work breakdown structure, you’ll be able to adapt the practice to any project—from moving your house to building a complex database with 75 offshore teams. That’s right, the work breakdown structure will be your friend.

But before you go off and start creating a WBS (and on-point estimates), let’s walk through a process that will help ensure a solid, workable estimate.

Step 1: List your project's high-level deliverables

If you’ve got a project scope, getting started on your work breakdown structure should be easy.

Don’t have a scope? Turn right around and talk to your clients or boss about the scope. Starting any project without a scope is dangerous because it sets the stage for what will be delivered and when.

First, sit down with your team, and list out what you’ll need to deliver to meet your project’s end goal. For instance, if you’re building a new website, your deliverables might include:

• Sitemap
• Wireframes
• Page designs
• Front-end code
• Back-end code

Be sure to include all tasks and that you’re not leaving anything out. For instance, if you’re working on a website redesign project, have you accounted for content? If you miss a deliverable now, you’ll regret it later.

That’s why listing things out as a team is so helpful. A team conversation not only ensures all your bases are covered. It also helps you set expectations for who will be responsible for deliverables and tasks, all while engaging the team on the overall process of the project. See, you’re winning already! 🏆

Step 2: Break each deliverable down into tasks

Once you’ve identified the high-level deliverables for your project, it’s time to take a deeper look into what actually needs to be done within each individual deliverable.

This isn’t just a simple exercise where you say, Who will do this, and how long will it take? It goes much deeper than that—and that’s a good thing because that’s how you’ll be able to create a better estimate.

As you dig into each high-level deliverable, ask your team (or yourself):

• What needs to be done to create this deliverable?
• What other related project tasks will contribute to successfully completing this deliverable?
• What are the task requirements?
• Are we cutting any corners here? (Make sure you list everything and anything—don’t cheat yourself!)

As you conduct this exercise, keep in mind that you truly want to list every possible task that could go into a high-level deliverable. Remember, the point here is to account for all time so you can create a reasonable estimate. You won’t be able to do that if you’re not thinking it through properly.

Using the website redesign as an example, here’s how you might break up the “Sitemap” deliverable:

• Review current site
• Test the current structure with 5 site users
• Review test findings
• Organize the sitemap in a spreadsheet
• Review the first low-fidelity version with the team
• Revise the structure using the team’s input
• Create a visual version of the sitemap
• Annotate sections
• Write description of the new sitemap
• Present the sitemap to clients
• Review client feedback
• Implement feedback
• Deliver v2
• Conduct meeting with clients
• Finalize sitemap

This list of tasks is an estimate for all of the work that will need to be done in order to get to a finalized sitemap.

This might not be the way you’d do it, and that’s just fine. When you sit down with your team to discuss these tasks, just be sure you’re operating with a common understanding of how things are done—or that you’re at least talking through the process you want to enact.

No matter what, listing out every single detail will help you spell out the effort it will take to complete the deliverable.

Step 3: Get granular with subtasks

That’s right: You want to make your work breakdown structure as detailed as possible. The only way to do that is to examine every task you’ve identified and list out subtasks. It’s all about elaborating effort and determining the work that will need to be done to successfully complete the deliverable.

It’s a process that takes time and thought, but if you make an investment to do this, you’ll find less room for missed expectations and budget overages in the long term. So, take the next step and detail out what will go into each task.

Using the website redesign as an example, here’s how you might break down the “Test the current structure with 5 site users” deliverable even further:

• Recruit users
• Schedule sessions
• Write test script
• Conduct 5 sessions
• Compensate users for time
• Write up findings and recommendations

This one task is proof that any single line item in a scope can be an expensive one! Not only did this example include 6 subtasks—it also included a line item that requires payment to a party outside of the project.

You’re going to want to know about any expenses before scoping your project, and your clients will too. Be sure to account for them early on so nothing comes as a surprise when you’re knee-deep in your project.

Step 4: Format your WBS and estimate the work

Traditionally, you’ll find work breakdown structures presented in flowcharts that resemble website sitemaps. That format works well because it shows a hierarchy of tasks and is easily numbered and referred back to.

But, some people like to list them out on whiteboards or put them in spreadsheets. The format isn’t what matters here—it’s the completeness and accuracy of the tasks included. You can create your work breakdown structure in any format that makes you comfortable. (We’ve included some examples below to get you started.)

When you’ve listed all of your tasks and subtasks in a format that makes sense, you’ll want to review it again and make sure you’ve included all of the possible tasks and subtasks.

Once that’s confirmed, go through the list and discuss each task in terms of level of effort. This could be in minutes, hours, days, weeks—it really depends on how granular you need to get and how your organization estimates projects. Assigning an increment of time to each task will help you add up a total estimate of time (and possible cost) and sets you up to create a project plan when you’re ready for that step in your project.

When you’re done, you’ll know if you’re in scope, out of scope, or actually operating on another planet. It’s true: You might run this exercise and find you’ve articulated too much time or effort to do everything within the scope of the project. The good thing is, you’ve set the baseline for what’s needed, and as a group, you can scale back on tasks to fit the scope or the timeline (and help yourself avoid the awkward deliverable due date dance).