What is Work Breakdown Structure (WBS) in Project Management?

Originally published March 13, 2018. Updated December 5, 2022

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.

Understand the Work Breakdown Structure (WBS)

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.

What is a WBS or Work Breakdown Structure?

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 managable 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.

Additional Definitions:

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:

• Work: According to PMBOK, work refers to “work products or deliverables that are the result of effort and not the effort itself”. That is, “work” defines the end result of any activity. The work remains constant even though the amount of effort needed to get there might inflate/deflate.
• Deliverable: PMBOK says that a deliverable is “any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project”. Deliverables will vary from project to project and client to client.
• Work package: According to PERT (which developed the WBS), a work package is “the work required to complete a specific job or process, such as a report, a design, a documentation requirement or portion thereof, a piece of hardware, or a service.” PMBOk has a simpler definition: “a work package is a deliverable at the lowest level of the WBS.”

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 a metal frame, etc. - would be part of the work package.

What are the Characteristics of the Work Breakdown Structure?

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:

• Hierarchy: The WBS is hierarchical in nature. Each “child” level exists in a strict hierarchical relationship with the parent level. The sum of all the child elements should give you the parent element.
• 100% rule: Every level of decomposition must make up 100% of the parent level. It should also have at least two child elements.
• Mutually exclusive: All elements at a particular level in a WBS must be mutually exclusive. There must be no overlap in either their deliverables or their work. This is meant to reduce miscommunication and duplicate work.
• Outcome-focused: The WBS must focus on the result of work, i.e. deliverables, rather than the activities necessary to get there. Every element should be described via nouns, not verbs. This is a big source of confusion for beginners to WBS.

Work Breakdown Structure (WBS) Examples

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. This 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 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 really have to follow all the hard rules we discussed above.

On that note, let’s look at some work breakdown structure examples.

A construction project WBS example

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 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.

A casual WBS example:

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 really matter as long as each level makes sense to you.

Computer program WBS example:

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 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.

Work Breakdown Structure vs Project Schedule vs Project Plan

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.

• Work breakdown structure describes the deliverables needed to complete the project, i.e. the “what” of the project. It doesn’t include timelines or resources. The goal of the WBS is to give the project team a hyper-focused idea of what they need to achieve.
• Project schedule describes the project’s deliverables as well as their deadlines and resource requirements. Think of it as the “what”, “when”, and “who” of the project.
• Project plan is an expansive document covering virtually every aspect of the project and its management. It includes details on how the project will be executed, managed, and controlled. It usually has several constituent plans governing communications, risk management, change management, etc.

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.

What are the benefits of a WBS?

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:

• Project schedule: The WBS is the foundation of the project schedule and budget. Once you know all the deliverables required to complete the project, as well as their hierarchical relationships, it will be much easier to assign resources and set deadlines.
• Accountability: Since all elements in a WBS are mutually exclusive, it helps create accountability. A team assigned to a single work package is wholly accountable for its completion. This reduces overlaps in responsibility.
• Commitment: The WBS gives teams a very high-level overview of their responsibilities. Since each team is responsible for a specific component at a time, it helps make them more committed to completing their assigned tasks.
• Reduces ambiguities: The process of developing the WBS involves the project manager, project team, and all relevant stakeholders. This encourages dialog and helps everyone involved flesh out their responsibilities. Thus, everyone has less ambiguity and a better idea of what they're supposed to do.

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.

Work Breakdown Structure in Project Management

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:

• A carpenter
• Raw materials such as wood, polish, nails, glue, etc.
• Tools such as hammers, saws, drills, etc.

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.

HOW TO CREATE A WORK BREAKDOWN STRUCTURE

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.

1. Understand the Project’s Scope

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:

• Project scope statement to understand the project’s scope in detail.
• Project scope management plan to understand how to deal with changes to the project’s scope (which will affect your deliverables).

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:

• Work breakdown structure
• WBS dictionary
• Scope baseline

2. Determine Major Deliverables

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:

• Each deliverable must be essential to the success of the project. For example, you can’t build a house without a foundation, exterior, or interior.
• Each deliverable should be the responsibility of an independent team. In the above example, the team responsible for laying the foundation won’t be the same as the team building the interiors.

3. Determine Work Packages

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, and then identify all the work necessary to complete it. This work package must be:

• Independent: The work package must be mutually exclusive and have no dependence on other ongoing elements.
• Definable: The work package should have a definite beginning and end and should be understood by all project participants.
• Estimable: You should be able to estimate the work package's duration and resource requirements.
• Manageable: The package must represent a "meaningful unit of work", i.e. it must accomplish something concrete and can be assigned to an individual or team. It should also be measurable.
• Integratable: The package must integrate with other elements to create the parent level.
• Adaptable: Ideally, the package must be able to accommodate changes in scope as per the project's requirements.

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:

• 8/80 rule: A common rule of thumb is that each work package must be no longer than 80 hours and no less than 8 hours in total length. If it is longer, decompose it further. If it is shorter, think of going up by one level.
• Reporting period: Another common rule is to limit each work package to a single reporting period. If it takes longer than one reporting period (monthly, weekly, etc.), to accomplish, decompose it further.
• Use nouns: You should be able to describe each work package with a noun or an adjective. To break it down further, you’ll need to use verbs. For example, “bike seat” is a noun describing a work package. If you break it down further, you’ll need to use verbs like “cut foam”, “stitch leather”, etc.

4. Create a WBS Dictionary

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:

• Work package ID (see the ID convention below)
• Work package name
• Work package description
• Assigned to (individual or team name)
• Department
• Date of assignment
• Due date
• Estimated cost

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)

5. Use the Right WBS Format

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 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.

Work Breakdown Structure Template

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.

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:

BONUS TEMPLATE: Click here for our editable Work Breakdown Structure (WBS) template with both tree and tab views. Start creating your WBS in minutes.

In the next and final section, I’ll share some best practices for getting the most out of your work breakdown structure.

Key Work Breakdown Structure Best Practices

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:

1. Use Nouns, Not Verbs

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.

2. Follow the 100% Rule Closely

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.

3. Keep All Elements Mutually Exclusive

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.

4. Mind the Level of Detail

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).

5. Use a Project Management Software

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.

TYPES OF WORK BREAKDOWN STRUCTURES: DELIVERABLE-BASED VS PHASE-BASED

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. 

BEST (& MOST IMPORTANT) FEATURES IN WBS SOFTWARE

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: 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.  

HOW TO CREATE A WBS IN PROJECT MANAGEMENT SOFTWARE

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

• Depending on the project and the software, the top-level project task is the main deliverable and/or project.

Step 2: Enter and Indent Task Groupings for the Project:

• Determine task groupings (sometimes called Summary Tasks) that collect individual but related deliverables into a group. 
• Use Descriptive Names (“Develop Reporting System” Not “Task 1”)
• In certain software (such as Microsoft Project) Indenting distinguishes the level of nested tasks - making it clear to viewers and the software which tasks are included in a parent task.

Step 3: Enter Individual Tasks

• Indent these below Summary Tasks. These are the most granular tasks and, again, should be given a descriptive name. For each, you’ll include the task name, expected time allocated, as well as start and delivery dates for the task. Additional details can be added in, such as task assignee or relevant notes; however, these will not be required to generate the core WBS.
• At this stage, your Project Management Software may auto-populate time allocations as well as delivery dates, etc upward into the parent Task Groupings and Top-Level Project tasks; if not, you can update those manually based on the figures you’ve assigned individual tasks.

Step 4: Enter Milestone Tasks

• A milestone task effectively tells readers (and the software) important events - often completions and delivery of a task group.

Step 5: Generate or Display the WBS

• Depending on the software, generating the WBS may mean selecting a different project “view”, applying a different format, or could require adding an additional column to the report that auto-populates WBS numbering.

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. 

HOW WORKAMAJIG CAN HELP WITH WBS IN PROJECT MANAGEMENT

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 project, 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.