Work Breakdown Structure (WBS)

A work breakdown structure (WBS) is a key project deliverable that organizes the team’s work into manageable sections. The Project Management Body of Knowledge (PMBOK) defines the work breakdown structure as a “deliverable oriented hierarchical decomposition of the work to be executed by the project team.” The work breakdown structure visually defines the scope into manageable chunks that a project team can understand, as each level of the work breakdown structure provides further definition and detail.

Work Breakdown Structure Guidelines:

The following guidelines should be considered when creating a work breakdown structure:

  • The top level represents the final deliverable or project
  • Sub-deliverables contain work packages that are assigned to a organization’s department or unit
  • All elements of the work breakdown structure don’t need to be defined to the same level
  • The work package defines the work, duration, and costs for the tasks required to produce the sub-deliverable
  • Work packages should not exceed 10 days of duration
  • Work packages should be independent of other work packages in the work breakdown structure
  • Work packages are unique and should not be duplicated across the work breakdown structure

How to use 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 these documents (and on-point estimates), let’s walk through a process that will help ensure a solid, workable estimate.

Step 1: List 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: Think about 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

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 and estimate

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.


Work breakdown structure examples:

One thought on “Work Breakdown Structure (WBS)

Leave a Reply

Your email address will not be published. Required fields are marked *