Thousands of creative leaders manage their agencies with Workamajig.
All-in-one marketing project management software for creative agencies & in-house teams
Marketing resource & traffic management tool schedules, tracks & assigns tasks all in one place
Track time & tasks for more transparency, more billable hours & keep projects right on schedule
Get real time insight on cash flow, budgeting & forecast revenue with custom reports
Fully integrated accounting and financial reporting tools make billing & invoicing a breeze
Capture new business opportunities & potential revenue with easy to use CRM for marketing
Get weekly tips on marketing project management & running an efficient agency.
Get answers to the most common questions about Workamajig.
Get customer support for existing Workamajig Users.
Have questions about Workamajig? Get in touch!
See the platform in action, ask as many questions as you'd like, and discuss your specific needs with our friendly and knowledgable sales team. Demos typically run for about an hour.
The Work Breakdown Structure (WBS) is essential for getting a project off the ground. This beginner-friendly guide will help you understand the work breakdown structure and create one on your own.
We'll also share a downloadable template you can use right away to create your own WBS in tree or tabular format.
For quick navigation, use the table of contents below to jump to the right section:
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 others, is one of several reasons why you need a thorough understanding of the work breakdown structure before you can create your own.
As with most things in project management, let’s start by looking at what PMBOK has to say about the work breakdown structure.
“A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables”
That’s a mouthful!
Let’s try another definition, this time from the Association of Project Management:
“A Work Breakdown Structure (WBS) is a hierarchical structure of things that the project will make or outcomes that it will deliver”
This one is far better.
Let’s simplify things further:
“A work breakdown structure defines all the things a project needs to accomplish, organized into multiple levels, and displayed graphically.”
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 management 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, then 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 dive further into the benefits and impact of a WBS, there are a few additional definitions you should know.
Throughout this article and others related to WBS, you’ll come across terms such as “work”, “deliverable”, “work package”, etc.
In the context of project management, these terms often have very specific definitions:
For example, if you’re building a bicycle, a “bike seat” might be one of your deliverables. All the work required to create the seat - cutting leather, shaping foam, creating 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 different WBS examples. 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. Which is why you’ll see WBS examples where top-level “deliverables” actually describe activities.
This isn’t ideal, but keep in mind that people use 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 really have to follow all the hard rules we discussed above.
On that note, let’s look at some work breakdown structure 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 “18.104.22.168”).
Also note how the WBS is organized into broad deliverables and sub-deliverables, all of which are nouns, not activities. Further, if you were to add up 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:
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 really matter as long as each level makes sense to you.
In this third WBS example 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 “develop business case” or “perform primary planning”.
This is superfluous within the context of a WBS. If you remove the verb from each of these WBS levels, you’d get a deliverable (i.e. a noun), not an activity. That is, you don’t need “develop business case” - just “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 things 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 of massive help in getting everyone to understand the project’s scope and deliverables at different levels.
This brings us to an important question: where does the WBS fit within the project management framework?
The work breakdown 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.
Which is to say, 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. Within this process, you first create a WBS dictionary (i.e. 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 figure out the resources to be used in their creation. This is called a Resource Breakdown Structure (RBS).
A resource breakdown structure consists of both 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 finds use 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.
Before you can create it, however, 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 have an understanding of the project scope, start the WBS development process by figuring out 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:
A work package, as you learned above, 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 one that will require extensive input from your project team and stakeholders.
Your goal is to pick a major deliverable, then identify all the work necessary to complete it. This work package must be:
In case 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 is a document that outlines the definition and scope of each element contained in the WBS. It is a supporting document meant to help incoming project teams understand each work package better.
You don't necessarily need a WBS dictionary, especially if the project is simple or limited in scope. For complex projects with a lot of churn, however, the dictionary can greatly improve clarity.
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 an example of a more simplified WBS dictionary 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 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 22.214.171.124 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, after all), it can be time consuming.
Which 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. That is, 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".
The goal of this "nouns, not verbs" exercise is 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 it is crucial that you 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 together and push the work package up 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 to have the exact dimensions of the wheel rim. In such a case, it would be better to combine "wheel spokes" and "wheel rim" into a single work package.
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 between 3-5 levels. Any further than that and you're looking at a project that's likely 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.
If you follow these guidelines, you’ll have a highly effective work breakdown structure that will help you in every phase of project planning.
Have you ever created a work breakdown structure for your project? What tools and tactics did you use?
Share them with us in the comments below.
Get all our templates, tips, and fresh content so you can run effective, profitable, low-stress projects in your agency or team.