Have you ever prepared coffee? Or, if you were asked to make coffee, what would you do?
Some of your steps might include:
As you can see, there are several steps involved in making coffee. Now try thinking of making coffee as your project. In the example above, you deconstructed the coffee making process into individual tasks. Each activity or step is broken into small pieces so you know exactly how much time it takes to complete a given activity.
This process enables you to easily create your schedule and multitask, reducing activity time. By doing so, you can optimize the time it takes to make a coffee.
Similar to the prior example, think of a project you are working on. The project can be divided into a finite set of tasks that have to be performed in sequence or parallel to one another to achieve the project goal. This deconstruction is called a work breakdown structure (WBS).
A work breakdown structure (WBS) is a project deliverable that organizes large projects into smaller, more manageable steps. Breaking down the project into components enables teams to integrate scope, costs, and deliverables into a single tool.
The Project Management Body of Knowledge (PMBOK 5) defines the work breakdown structure as “a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.”
The coffee making example above shows the benefits, but let’s talk about what you might expect in terms of project management. To better understand the benefits, you should know why you need WBS and what work breakdown structure can do.
Not having a work breakdown structure for your project makes it difficult or impossible to:
Building a WBS will help you solve these problems and knowledge gaps. Below are the biggest benefits of using work breakdown structures for project management:
A WBS helps the project manager and the team understand the overall scope of the work and also evaluate the scope against the customer requirement(s) to see how much of the requirements are covered. The WBS presents the big picture and allows you to work toward the totality of the project, rather than focusing on one solution.
A WBS helps with the cost estimation of each activity and allows you to determine an accurate cost for the entire project. Using a work breakdown structure, the product manager can optimize cost further by scheduling and developing a resource allocation strategy.
A WBS also works as an input for scheduling. The product manager uses the WBS to schedule the project. The WBS lets a project manager walk through activities at every level and decide the sequence of activities to be performed.
WBS lets you know which activities are redundant and also understand which activities can be done in parallel. From this, the project manager can optimize the schedule and define the project timeline.
A WBS helps determine what resources are needed and how long they’re needed for. The WBS allows the product manager to scale the project as they see fit.
The most important benefit of a WBS is status tracking. It creates a transparent view of the entire project giving every stakeholder an opportunity to learn the scope of the project and the resources needed for completion.
Once drawn, it becomes an efficient tool for the project manager to update status and report to all stakeholders in one coherent view.
Now let’s create a WBS as an example to understand it further.
Say you’re a project manager building a cafe. The customer gives you the requirements and asks you to come up with a timeline. To give your customer the timeline (and schedule), you will have to first create the WBS. It would look like this:
To develop a cafe, you have deconstructed the entire project into several tasks and grouped them in a meaningful manner. This grouping is called levels. We will discuss levels below.
In the above example, there are three different levels. You can have any many levels as you want, but, in general, projects tend to fall into three levels:
This is the root level and you can just call it the name of the project you are working on. This level states the final deliverable of the project.
Some project managers even specify the goal and deconstruct it into tasks, which is absolutely fine to do. However, at this level, the focus should be on the final deliverable. In the above example, Dalh’s Cafe is the final deliverable. The common name for level one is project.
This is the first level deconstruction from level one. The final deliverable has to be chunked into major milestones or deliverables that combined deliver level 1. In the example above, kitchen installation is one of major milestones to build Dalh’s Cafe.
This is the second deconstruction from level 1. The level 2 components/deliverables are further deconstructed into smaller activities that combined together deliver a level 2 component. This might be a small task that cannot be further divided, or a smaller activity that can be further divided into multiple tasks.
Level 3 elements are known as planning packages if there are further levels needed, or as work packages if the elements are the smallest tasks.
Further levels can exist depending on the project (e.g., above, the task “chumney setup” is the smallest and doesn’t need to be broken down further, whereas the task, “cooking counter” can be further divided into multiple tasks.
A few rules guide the WBS process to keep it running smoothly and as a project manager, one must adhere to it until the end of the project. To aid this, whenever you are creating, editing, deleting, or updating any elements in work breakdown structure the following rules apply:
This is the most important rule in WBS. It states:
This may seem easy, but as the project progresses and changes, difficulties can arise. As a project manager, one should work towards maintaining this 100% while updating the progress, status, and changes. This rule helps stakeholders to keep scope, cost, and the schedule intact to the project’s budget.
This rule states that the last child level activity (work package) defined in a WBS must be the smallest, such that the work package doesn’t take more than eight hours of effort to complete it and also doesn’t exceed 80 hours. Basically, this rule ensures, effort of every work package ranges between 8–80 hours.
This rule states that any work package in a WBS can be assigned to a specific individual or team. If you have created your work breakdown structure well adhering to above 8/80 rule, the work package would mostly get allocated to an individual.
This rule is important to eliminate duplication of efforts and redundancy of work/effort. It also avoids overlaps in each work package.
This rule states that any activity at a certain level should be a deliverable and not an action. The rule guides product managers to develop a work breakdown structure based on the outcomes to meet the project goal, rather than mentioning tasks/activities that are action oriented.
The example we discussed above, shows outcomes at each package level. It is easy to understand what is expected at each level, what has to be completed to achieve it, and what the estimates of that package are to evaluate further.
A WBS is made by deconstructing the project into deliverables or phases. In the visual view of the WBS, there is limited space to capture every detail and there is a need for additional components.
A WBS is complete when it has the following components:
This is the core of a WBS where the visual view of the entire project is detailed. It explains every deliverable needed to accomplish the project and also divides deliverables into sub-deliverables.
You have seen a WBS and due to space limitation, not all details can fit into the WBS elements. This is solved by creating a work breakdown structure dictionary.
The WBS dictionary is a detailed document of each element in a WBS explaining the context, detailed descriptions, deliverables, acceptance criteria, efforts, and costs. The key reference between the WBS and the WBS dictionary is the numbering (1.1, 1.1.1, etc.) followed in the WBS.
Below is an example of a WBS dictionary documenting an element in detail:
This WBD dictionary document is a sample, but doesn’t limit to the details captured. A project manager can elaborate this document as much as they need for their stakeholders.
The WBS fields, or glossary, is the document that explains every term used in the work breakdown structure that needs further understanding. Below is an example:
You only need to add further details if they’re necessary. To build the WBS glossary, you just need the term and its definition.
A WBS is complete when the hierarchy, dictionary, and glossary are built, approved, and published for all stakeholders.
There are various ways to create a WBS. Below are four examples:
Let’s look at a template for each type of work breakdown structure to see what it looks like in practice.
Every element at each level in this type of WBS is a deliverable or an end sub-product. This is the most popular and widely used work breakdown structure type by project managers. For almost all projects, a WBS can be broken into deliverables. At every level and element, the project manager specifies whether a deliverable is the end product or a sub-product that combines together to create a major deliverable. An example of a work breakdown structure of this type looks like:
A deliverable based WBS is a powerful tool that a project manager can use to divide the project into goals and subgoals. This helps all stakeholders track the project in an efficient manner because the work breakdown structure depicts not only how work is done or pending, but also showcases the autonomous usage, potential, and testing of each deliverable.
In a phase-based WBS, a project manager creates major deliverables as different phases and defines the tasks/activities needed to complete the phase. This is best suited in projects like software development or manufacturing, where a set of processes/operations have to be carried out for the completion of a project.
The phase based approach looks like this:
In a responsibility-based WBS, a project manager divides the major deliverables as different teams/individuals and then creates activities/tasks that are to be carried out under each team/individual. This is best suited in projects that are services based and involve multiple teams carrying out tasks independently.
As an example, a cleaning services company could create a project for cleaning a customer office and define their tasks using a work breakdown structure:
Fewer product managers are aware of the time-based approach. In a time-based WBS, the project manager divides projects into time periods — e.g., Quarter 1, Quarter 2, etc. — and defines activities to be carried out in that time period. It usually looks like a roadmap to achieve project success.
You’re most likely to see this type used in an area where the next set of requirements are unknown and the scope is open. Here, a project manager would create the visibility of the next few months and then keep it open to update at a later time, like so:
Before digitization, project managers used to create WBSs on whiteboards to display for the entire team. The project manager would create a WBS with multiple sets of papers and maintain them throughout the project lifecycle.
Modern digitization has overcome this challenge. The first work breakdown structure projects in the digitization era were created in Excel sheets. Later, several tools emerged, with Microsoft Project Gantt Chart gaining the most popularity.
In today’s world ,there are many popular project management tools available in market, such as:
In these, the traditional (tree hierarchy) WBS format is replaced by each tool’s own way of implementation and visualization. You don’t have to use these tools, but they can aid project management and tracking.
We have discussed the many benefits and uses of WBS in project management. A project can have various tasks and dependencies that can block deliverables and increase cost. A work breakdown structure provides the overall picture to the team(s), helps them efficiently plan their individual activities and manage time, as well as unblocks dependencies to meet project deadlines without increasing the cost.
Teams can evaluate the time allocated to a task and actual completion time of the project, which can help you work toward covering the schedule and meeting the targeted due dates. WBS builds transparency in the work process, which helps a project manager re-strategize their work schedule or scope for their teams to meet targets. It also helps a Project Manager evaluate any additional needs to complete the work on time.
A work breakdown structure is a powerful tool for project managers, executing teams, and other stakeholders to make a project successful. After gathering the requirements and understanding the scope of a project, a project manager should create the entire WBS and then proceed with scheduling, cost estimates, etc., using the WBS as an input.
A project manager should constantly update the WBS throughout the project life cycle and use it as the reporting view for the entire project for all stakeholders. Project teams should use the work breakdown structure as a daily board to understand the current state of a project, impediments, and dependencies to overcome and deliver on deadlines.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Learn how to prepare and launch internal products effectively with real PM examples, readiness pillars, and a practical launch checklist.
Learn how to balance confidence and collaboration as a product leader while building trust, authenticity, and high-performing teams.
Data shows you what users do, not why. Learn how blending qualitative and quantitative insights fuels real product innovation.
Feeling overwhelmed by endless PM tasks? Learn simple, proven strategies to stay organized, focused, and in control of your workload.
Learn more →
