Originally published March 13, 2018. Updated June 25, 2024
The Work Breakdown Structure (WBS) is essential for getting a project off the ground. This beginner-friendly guide will help you understand WBS project management and help you create a WBS of your own
The work breakdown structure can be confusing, especially for new project managers. Despite its name, it doesn’t actually involve breaking down work; it involves breaking down deliverables.
This, among other reasons, is why you need a thorough understanding of the work breakdown structure before creating your own.
WBS meaning:
“A work breakdown structure defines everything a project needs to accomplish, organized into multiple levels, and displayed graphically.”
You might have also heard WBS referred to as “hierarchical breakdown” or “decomposition”.
Essentially, the WBS defines the “what” of the project. Everything you need to accomplish in the project is displayed in a single, easy-to-understand chart. The purpose of this chart is to break down complex activities into smaller, more management constituents.
For example, here’s a WBS example for an aircraft system:
Developing an aircraft system is obviously a very complex endeavor. You need an aircraft (which itself is an extremely complex undertaking), a system to train staff and pilots, a way to manage infrastructure, etc.
As shown above, a WBS breaks down all these complex activities into smaller, more manageable constituent parts.
Thus, you might have one group responsible for building an aircraft. Within this group, you might have one team focused on building the airframe, another on creating a propulsion system, and so on.
It’s common to have three levels of decomposition in the WBS. You might have a fourth and even a fifth level in case of extremely complex projects. For most projects, however, three levels will suffice.
Here’s another example of a bicycle construction broken down into three levels:
The numbers next to each item indicate the number of hours or resources required to complete the work. The sum of all these must be 100 at each level.
This is the oft-quoted “100% rule” - that the sum of the work at each “child” level must be 100% of the work at the “parent” level.
You’ll notice that the WBS doesn’t describe any actions. Instead, every item is a noun describing an end product - a bicycle seat, fork, handlebar, etc.
This is one of the fundamental features of a WBS: it describes deliverables, not the activities necessary to get there. Every item in the WBS must correspond to an end product (real or virtual). If there are any verbs in your WBS, you’re doing something wrong.
For example, if you’re creating a work breakdown structure for manufacturing a car, you’ll include items such as “car body” (a deliverable), not “welding steel” (an activity).
Before we discuss the benefits and impact of a WBS further, there are a few additional definitions you should know.
Throughout this article and others related to WBS, you’ll encounter terms such as “work,” “deliverable,” “work package,” etc.
In the context of project management, these terms often have very specific definitions:
For example, a “bike seat” might be one of your deliverables if you're building a bicycle. All the work required to create the seat - cutting leather, shaping foam, creating a metal frame, etc. - would be part of the work package.
Not every breakdown of project deliverables can be classified as a WBS. For it to be called a work breakdown structure, it must have certain characteristics:
The best way to understand how work breakdown structures work is by looking at a work breakdown structure example. Seeing how complex projects are actually broken down can help you do the same in your projects.
While work breakdown structures are technically supposed to focus on deliverables, not activities (i.e. nouns, not verbs), plenty of project managers skip this rule in actual projects. This is why you’ll see examples of WBS where top-level “deliverables” actually describe activities.
This isn’t ideal, but keep in mind that people use a work breakdown structure for all sorts of things, even outside of project management - writing a book, planning a vacation, etc. If you’re using it casually, you don’t have to follow all the hard rules discussed above.
On that note, let’s look at some WBS examples.
This first example comes courtesy of StakeholderMap.com and shows a WBS for a construction project.
This is a three-tier WBS with each level denoted with numerical notation (such as “1.1.2”). For each subsequent level, you’d add another decimal to the notation (such as “1.1.2.1”).
Also note how the WBS is organized into broad deliverables and sub-deliverables, all of which are nouns, not activities. Further, if you add all the deliverables together, you’d get the first level in the WBS, i.e., the 100% rule.
This is the key defining trait of a good WBS.
The convenient format of the WBS means that you can use it for any number of purposes, including managing casual projects.
In such cases, you don’t really have to follow the formal guidelines of a work breakdown structure. Rather, your goal should be to create natural categories and sub-categories. The only restriction? They should all add up to 100% of the work to be done.
Here’s an example from AmericanWaterCollege.org:
00
Note that the WBS lists activities (“cut lawn”) instead of deliverables. This wouldn’t pass muster in a formal work breakdown structure, but if you’re using something internally, it doesn’t matter as long as each level makes sense.
In the third of our work breakdown structure examples from VisualParadigm.com, we see one of the biggest mistakes people make when creating the WBS: mistaking activities for deliverables.
As you can see below, the third level in the WBS identifies activities such as “developing business case” or “performing primary planning.”
This is superfluous within the context of a WBS. If you remove the verb from each of these WBS levels, you will get a deliverable (i.e., a noun), not an activity. You don’t need to “develop a business case” - just a “business case” is enough.
Keep this in mind when you create your work breakdown structures. Remove verbs from each WBS level. You are, after all, describing things that need to be delivered, not the tasks necessary to deliver them.
Another common source of confusion for beginners is the difference between the work breakdown structure, project schedule, and project plan.
While these three often describe the same thing—what is to be achieved in the project—they vary greatly in scope and details.
In terms of the level of detail, you can think of the project plan as the broadest, followed by the project schedule, and finally, the work breakdown structure.
This might make you ask: Why bother with the work breakdown structure at all? Can’t you get all the same details in the project schedule?
As you’ll see below, the WBS has several advantages over the project schedule.
The WBS is a laser-focused breakdown of all the key deliverables needed to make the project successful. Creating one offers several advantages, such as:
Creating a WBS is the first step in developing a comprehensive project schedule. It can be massively helpful in helping everyone understand the project’s scope and deliverables at different levels.
Where does the WBS fit within the project management framework?
To avoid confusion and make your WBS effective, it’s important to ensure that it aligns seamlessly with your project milestones plan, amongst other documents.
The WBS structure springs from the project charter. Ideally, the high-level deliverables in the WBS should match, word for word, the goals, and deliverables listed in the project scope statement.
Consequently, the WBS is one of the first documents you create in the project management lifecycle. You’ll create it before you create the Gantt chart or the project plan.
This means that the WBS is often the first deliverable in a project.
While the stated benefit of a WBS is in helping you keep track of deliverables and managing project scope, it has another key use in project management: creating the project schedule.
As this PMI conference paper points out, understanding the deliverables included in a WBS and mapping their relationships is crucial for charting a project schedule. In this process, you first create a WBS dictionary (i.e., a list of deliverables), turn these deliverables into a map of relationships (i.e., a network diagram), and use it to create the schedule.
You can also use the map of deliverables (and the relationships between them) in a WBS to determine the resources to be used in creating them. This is called a Resource Breakdown Structure (RBS).
A resource breakdown structure consists of the material and human resources required to complete a deliverable. For example, if you’re creating a chair as part of a larger house remodeling project, you’ll need:
You can represent these resources as follows:
Once you understand how resources will be used to create each deliverable, you can also improve your project scheduling—one of the many ways a work breakdown structure is useful in project management.
I’ll share a process for creating a WBS in the next section.
The output of the WBS development process might seem simple: a short document with a list of deliverables. To create it, however, you need a thorough understanding of the project’s scope, your team’s capabilities, and your stakeholders’ requirements.
Here’s a process for creating a WBS from scratch.
In our earlier project management guide, we identified the WBS as one of the key documents created at the end of the ‘Planning’ phase.
However, before you can create it, you need a thorough understanding of the project’s scope and objectives.
Chiefly, you need two things:
You’ll want to refer to your project charter to develop the scope statement and scope management plan.
The output of the entire WBS development process is as follows:
Once you understand the project scope, start the WBS development process by determining the key deliverables.
For example, if your goal is to “build a house”, you might have the following three broad deliverables at Level 2:
There are two heuristics you can follow for determining major deliverables at the 2nd level:
As you learned above, a work package is a deliverable at the lowest level of a WBS.
In a typical 3-level WBS, determining work packages would be the next step after identifying major deliverables.
This is one of the most important parts of the WBS development process, and it will require extensive input from your project team and stakeholders.
You aim to pick a major deliverable and identify all the work necessary to complete it. This work package must be:
If the work can’t meet the above requirements, you can decompose the WBS into another level.
There are a few heuristics you can follow for determining work packages:
The WBS dictionary outlines the definition and scope of each element in the WBS. It is a supporting document meant to help incoming project teams better understand each work package.
You don't necessarily need a WBS dictionary, especially if the project is simple or has a limited scope. However, the dictionary can greatly improve clarity for complex projects with a lot of churn.
Further, the WBS dictionary takes you one step closer to creating the project schedule. You can often transplant details from this dictionary straight to your project scheduling tool.
Here are a few details you can include for each item in the WBS dictionary:
The level of detail you want to include is entirely up to you.
Here’s a more simplified WBS dictionary example with element ID, name, and description:
A WBS dictionary helps project team members understand each element (Image source)
Once you have all the work packages and the WBS dictionary, it’s time to create the WBS.
There are several WBS formats you can follow. The simplest way to do this is to create text-based hierarchical groupings. By convention, you use numbers and decimal points to indicate the level of the element.
For example, the number 1.1.1.3 means that you’re referencing the 3rd element of the 4th level of the WBS.
Thus, you might have a text-based WBS as follows:
Alternatively, you might use a more visual tabular structure as follows:
Another option is to create a flowchart:
Once you’ve made the work breakdown structure, share it with your team. Use it to get a high-level overview of the project’s progress.
While creating a work breakdown structure is technically easy (it’s just a flowchart or an Excel sheet), it can be time-consuming.
This is why we created this work breakdown structure template to help you get started.
This template contains both a tree view and a tabular view. Use either as you see fit.
Click the link below to download your WBS template:
In the next and final section, I’ll share some best practices for getting the most out of your work breakdown structure.
The work breakdown structure is the foundation of your project schedule, which, in turn, is the foundation of the entire project.
Following a few best practices in the WBS creation phase can greatly improve the accuracy of your project schedule. A clear breakdown of key deliverables will help you estimate and assign resources better.
Here are some key best practices you should follow when creating a work breakdown structure:
As I said earlier, the purpose of a WBS is to track deliverables, not activities. The "what" of the work matters, not the "how" of getting there.
One way to achieve this goal is to use nouns when adding elements to the WBS. Every element in the WBS should be either a noun or an adjective.
Think of "House foundation" instead of "Removing earth to create the foundation", or "Communication plan document" instead of "Gathering requirements for communication plan".
This "nouns, not verbs" exercise aims to force you to keep your elements broad in scope. Activities usually describe the final level in any work package. Your WBS should focus on one level above that.
A work breakdown structure is meant to be exhaustive. There should be no deliverable outside of the WBS.
This is why you must follow the 100% rule. Every level should be everything you need to deliver. Anything beyond that should be scrapped.
This helps you spot gaps and redundancies. It also ensures that every project component is complete and nothing is left behind.
The other cardinal rule of work breakdown structures - besides the 100% rule - is "mutual exclusivity". Every element should be independent. You shouldn't need any input from any other element to complete it. If you do, it's better to combine the two elements and push the work package to a level.
For example, if you're building a bicycle, you can create a "handlebar" independently of the "bicycle frame". Thus, it would be a separate work package.
In contrast, to create the "wheel spokes," you first need the exact dimensions of the wheel rim. In such a case, combining "wheel spokes" and "wheel rim" into a single work package would be better.
A common mistake when creating work breakdown structures is to keep the level of detail either too broad (i.e. too few levels) or too narrow (i.e. too many levels). Like Goldilocks, there is a level of detail that's "just right".
Ideally, your decomposition should stop before you can use verbs to describe the element. For instance, if you're building a bicycle, "wheel rim" should be the final level since it describes a deliverable. If you decompose further, you'll have activities related to the deliverable such as "buy steel", "shape steel", "make holes for wheel spokes", etc.
If this happens, you know you've got too many levels.
Aim for 3-5 levels. Any further than that, and you'll likely have a project that's too complex (and might be better as a program).
One of the best tips I ever received about WBS was to “use a template.”
You might use a simple Word template, or you might use something offered by your flow chart tool. But if you want the WBS to integrate with the rest of your project documents, the best source of templates is your project management software.
Most PM tools, such as Workamajig, will have built-in capabilities to create a work breakdown structure from scratch. You can simply specify your level of detail and add element data to create a WBS quickly.
The best part about using a PM tool is that your WBS data is available to you when you’re creating your project schedule.
Compare the best creative project management software here.
Though it’s you and your company who will be working on the project, including stakeholders in creating a WBS, it can give you valuable insight as to the best way of breaking down deliverables. It’s also a great way to ascertain that you are on the same page as stakeholders in regard to what exactly the deliverables will be.
Another important document in project planning is the project schedule. When creating your WBS, ensure that the deliverables and milestones listed within it mirror those in your project schedule to avoid confusion.
While the principles are the same, WBS users should be aware that different industries and different projects will require different applications of Work Breakdown Structures - i.e. different types of WBS.
The most common type remains Deliverable-Based WBS - where level 2 is representative of the different deliverables a project manager should expect to produce. In the case of a creative agency, this might mean a deliverable-based WBS would identify copy, photographs, and video in level 2.
Alternatively, for bigger projects with a lot of moving pieces - or where those pieces will, themselves, be spread across multiple phases - a project manager is likely to use a Phase-Based WBS. In this type, the stages of production are represented in level 2 (as opposed to individual deliverables). For example, a creative agency working on marketing materials might identify the following items in level 2: Planning, Design, Production, and Delivery.
There are additional sub-types of WBS (such as noun-oriented, verb-oriented, and time-phased); however, the vast majority fall into deliverable or phase-based types.
There are countless project management software on the market but not all of them provide the necessary tools to support Work Breakdown Structures - which require a series of unique feature sets in order to maximize effectiveness. That said, tools vary as do the needs of project managers, so anyone in search of the perfect WBS tool should focus on which features they need - and which ones are not relevant to their business.
- Drag and drop functionality: This might seem obvious but WBS projects can be very complex with many moving pieces. So, ensuring you can build your Work Breakdown Structure with intuitive and easy-to-use software will save you a lot of time.
- Progress management: Whether you’re setting, altering, or measuring the progress of tasks within your WBS, look for software that provides clear measurement functionality - so that you always have a clear snapshot of the projects as a whole along with any individual parts that need a deeper look.
- Ability to link tasks: Since some WBS tasks will be dependent on others, a quality Work Breakdown Structure tool should allow you to link your tasks to illustrate dependencies as well as provide quick access to connected action items.
- Robust Reporting: A project view is helpful for project managers; however, there will be numerous cases where a WBS lead will need to present the status of a project or task to others who might not know how to navigate the tool (or understand WBS at all). For that reason, it’s important your WBS software also includes detailed reports that can be presented or summarized in a variety of ways - to make sure your intended audience can understand how things are going or what tasks still need to be completed.
Third-Party Compatibility: Another obvious point but important to consider. How well does your WBS tool play with other applications that are used within your organization? The more integrations and compatibilities a tool offers, the less chance you’ll find yourself with data or reports that need to be manually recreated - simply because they weren’t easily exportable.
History Revision: How to handle changes and revisions in a Work Breakdown Structure? Considering how often projects change, especially complex ones, a revision tool can be a major time-saver - in the event that you (or someone else) alters your WBS and tasks go missing or no longer include all of the relevant information. Being able to look back - or even revert previous versions of your Work Breakdown Structure is a handy tool to have.
Unique Templates: As mentioned, there are multiple types of WBS - each with its own benefits and shortcomings. A tool that provides access to WBS templates ensures you set up the right Work Breakdown Structure for your project and, coupled with other useful features (such as drag-and-drop functionality), ensures even WBS beginners are working from a solid foundation.
Every project management software is different, and, as such, there is no one-size-fits-all answer to how a user would create a WBS in their software of choice. Many software offerings make creating a WBS incredibly simple, with step-by-step instructions and automated WBS generation. That said, there are some basic fundamentals that can assist new WBS managers in their approach to creating a Work Breakdown Structure in software that requires a more manual approach.
Step 1: Create a Top-Level Project Task for the WBS in Your PM Software
Step 2: Enter and Indent Task Groupings for the Project:
Step 3: Enter Individual Tasks
Step 4: Enter Milestone Tasks
Step 5: Generate or Display the WBS
Again, this is one of the more manual processes - providing a granular look at organizing a WBS in generalized Project Management software. For specific instructions on the software you use, refer to that tool’s FAQ or online support.
As indicated, creating a WBS can be a relatively straightforward process; however, as a project increases in complexity and size - or requires significant changes mid-delivery - it’s important to have a robust tool that can be as flexible and intuitive as you. As a tool designed for creative and agency project management, Workamajig’s Work Breakdown Structure features help users plan their projects, visualize interconnected tasks, and quickly adapt to changes, delays, and roadblocks.
Thanks to easy-to-read dashboards and project views, it’s simple to view time tracking, access files, search conversations, and update schedules - providing a clear picture of where you may need to make alterations to your WBS or where certain deliverables are in conflict or off-schedule.
With an intuitive interface and powerful features, you'll be able to streamline your workflow and get your projects done on time and on budget. Schedule a free demo to learn more about how Workamajig can help with your Project Management plans.
Related reads:
