When you start a project, does your team ever feel overwhelmed and not know where to begin? Or have you started working on a project only to realize that you didn't factor in critical work (or major deliverables)?
Suppose a contractor is redoing a bathroom that involves taking an old shower stall down to the studs and retiling the shower. It seems simple enough, but there's more to the project than ripping out the tile and installing new tiles.
If the waterproofing is forgotten until the contractor starts tiling, the supplies will be delayed. If they forget entirely about it (and don't do it), you'll have water or mold issues at some point.
If this feels all too familiar, have you considered incorporating a work breakdown structure (WBS) into your project planning?
A work breakdown structure (WBS) is a project management tool used to create a hierarchical decomposition of a complex project into the lowest level, actionable individual tasks.
As Desmond Tutu said, "There is only one way to eat an elephant: a bite at a time."
In this article, we'll look at:
- Benefits of a work breakdown structure
- How do you write a work breakdown structure?
- An example of a work breakdown structure
Benefits of a work breakdown structure
Let’s take a look at some of the benefits of using a WBS.
 |
Defines the work required
You and the project team must define and understand all the work involved before beginning a project. Missing pieces can cause delays, cost increases, quality issues, etc.
A work breakdown structure starts with the project objective and goals, then broken down into a list of tasks in a hierarchical structure. You end up with a visual representation of all the work that needs to be done for the project, like a periodic table or an organizational chart.
Helps with project scheduling (and timelines)
Accurate timelines are an imperative piece of project management. Without them, everything from resource management and scheduling to tracking progress would be a guessing game. But without knowing the detailed tasks to complete a project, it's nearly impossible to come up with good timelines. Catch-22.
With a WBS, you'll know exactly what tasks are involved in a project, and their dependencies (more on this later) to gin up a workable schedule and timeline upfront.
In our shower example, that'd mean being able to schedule resources, give the customer a realistic done date, and track progress against the timeline.
Helps with estimation
Would you want your bathroom renovated without knowing the estimated cost beforehand? Didn't think so.
With a detailed task list (and their dependencies) from the WBS in hand, it becomes much easier to do time, resource, and cost estimation.
With a detailed WBS, the project manager for the shower remodel project will be able to estimate the total cost of the project and an expected completion date.
Transparency
Since the WBS is a big-picture breakdown of all the tasks involved in a project in an easily digestible, visual format, it can be used to convey those details to the project team and customer. This way, everyone is on the same page no matter where in the project you are or what exact details you need to convey or discuss.
The shower customer (and project team) can see exactly what work has been or will need to be done at any point in the project. If the demo part of the shower is done, but took a bit longer than expected, the team and customer can agree on how to speed up the work based on the tasks in the WBS left to do.
How do you write a work breakdown structure in 6 steps?
Let’s take a look at the steps to take to write your own WBS.
 |
Define your project requirements
First, you need to determine what you want to accomplish in your project. Your project objective and supporting goals. It's best to work with your team, customers, and stakeholders to understand what the end goal of the project is.
Consider creating a project charter and scope statement to ensure your project team and stakeholders understand and agree on what the project should be about.
Once you nail the project objectives and goals, you’ll want to dive head-first into the project requirements, or features and functionalities needed to complete a project. In an Agile project management framework, the preferred way to capture these is as “user stories,” which are the requirements from the customer’s perspective (in layman’s terms).
A catering company hosting a large wedding (the project objective) wouldn't offer twenty different main courses. They'd offer a set number of main courses, and work with their customer to choose how many of each would be served (a project requirement). This would be documented in the contract (the project scope statement).
Establish the deliverables
You and the project team (next) need to determine what the deliverables of the project will be.
Project deliverables are project speak for outcomes, products, or services that are produced as part of the project. These can be internal deliverables the team uses to accomplish the project, or deliverables shared with the customer.
For the catering company, the wedding itself is a deliverable (outcome), as are the meals (product).
Break down the work into smaller tasks
Once you've defined the project objectives, goals and deliverables, you can break them down into a list of specific, actionable tasks needed to make those happen.
If the catering company is supplying the wedding cake, tasks might include:
- Provide the couple with design options.
- Bake test samples of their offerings.
- Do a taste-testing event.
- Get the couple to make decisions, and sign off on their final choices.
It's also helpful to define project milestones, which are waymarkers of sorts that help you track progress against the project objectives and goals. Signing off on that wedding cake might be a milestone in the project plan.
Determine task dependencies
You can't have your cake and eat it too. Well, not until you bake it.
While some tasks may be worked concurrently, others will have to wait for other, previous tasks. I.e. they're dependent on those previous tasks.
Since the WBS is a visual, high-level overview of the entire project, it's easier to recognize (and document) those dependencies. This will make scheduling (and creating a timeline) significantly easier when the time comes.
Assign a time to each task
Although detailed effort or time estimation is usually reserved for other project management phases, it can't hurt to get started in the WBS to get a feel for the overall project timeline.
At this point, it'd suffice to do high-level time ranges or simply categorize task efforts to make detailed effort estimation easier down the road. (We'll cover one such method later in our end-to-end example).
Review the WBS with your team
With all the information from the previous steps, it's time to review the WBS with the project team to check for understanding, answer questions, and get feedback.
Doing so has the added benefits of getting buy-in from the team on the work to be done, enabling transparency, and fostering a culture of collaboration (all important, "soft" actions that'll help you get projects across the goal line.)
Had the project manager for the shower remodel done this, someone on the team might have caught that the waterproofing task was missed.
An end-to-end example of a work breakdown structure
Let’s go through developing a WBS for a grocery store website. The grocery store would like our team to create a website (project objective) to allow customers to place orders for delivery or curbside pickup (project goal).
 |
Project requirements
Based on the project objective and goal, here are some of the requirements (features and functionality) the team has landed on for the curbside and delivery order functionality:
- Customers need a login or can check out as a guest.
- Order confirmations need to be sent via email.
- Customers should be able to cancel their orders via the website.
- Only a finite number of delivery slots should be allowed per hour.
Deliverables
The project manager will document what the team must do to deliver the project. This includes meeting with stakeholders, creating a scope statement (deliverable), and reviewing the scope statement with stakeholders for approval.
The BA will develop requirements (deliverable) and website mockups (deliverable) and present them to stakeholders for approval.
The programmer must write the code (deliverable) and unit tests (deliverable) to ensure the website works before passing it along to QA.
The QA analyst can give input on their steps, such as writing test cases (deliverable).
Finally, the team would implement the website (deliverable), monitor for issues, and check in with the customer to see how things are going.
Task dependencies
There are some key dependencies in this project
For example, the business analyst can't review requirements with the customer before writing and vetting them with the team. The programmer can't unit test before coding. QA can't test before they write their test cases.
These dependencies will be noted in the project schedule.
Estimate
Here is where having specific details about what is required will come in handy.
As mentioned before, the team would only need high-level effort (time) estimates at this point. A great way to go about that is with t-shirt sizing the tasks.
T-shirt sizing is a technique where tasks are assigned sizes like S, M, L, etc., to represent their relative complexity or effort required.
For the sample requirements, here's what the team came up with:
- Customers need a login or can check out as a guest: M
- Order confirmations need to be sent via email: S
- Customers should be able to cancel their orders via the website: M
- Only a finite number of delivery slots should be allowed per hour: L
...where small (S) is one full day, medium (M) is two to three days, and large (L) is a solid week for the coding and testing work.
Review
Everyone on the project team should review the WBS to ensure everything was accounted for. Is anything missing needed to fulfill the project's objective and goal? For example, will programming and QA have all the documentation they need to understand what they need to program and test?
3 tips for a better work breakdown structure (and using it)
Tasks should be specific and actionable
For example, "Build a website to allow customers to order from a hardware store online" isn't specific or actionable. "Order confirmations need to be sent via email" and "Customers should be able to cancel their orders via the website" are
Collaborate
Your team (that does the work) are the experts on what should be done. No need to guess.
For example, the business analyst, developer, and QA tester know what's needed for the grocery website project. Ask them for help with the WBS and estimates.
Besides getting accurate and specific information, you're also building a culture of collaboration and transparency.
Use project management software
Project management software can allow your team to access the project tasks in your WBS and collaborate on tasks. Having project management documents, like the WB, and information stored in a central location means the team can access the same information and any updates.
Use Motion to keep your WBS tasks moving
Consider using Motion to keep tasks moving.
All you have to do is input the task into Motion's Task Manager and specify the task duration, priority, and deadline.
Motion's Intelligent Calendar will schedule the tasks for the team members, considering priorities, abilities, and preferences.
If a task is in danger of missing a deadline, users will receive an alert so they can jump on it and figure out a workaround.
If you aren't using Motion yet, access a free trial today.
