October 27, 2023

Work Breakdown Structure Examples (Software, Construction)

In this article, you’ll find several examples of Work Breakdown Structures from different projects. Also, you’ll find an in-depth guide on how to create a WBS in the real world. I’ll share all my practical tips and tricks as well.

Work breakdown structure is a cornerstone tool in project management. But let’s be honest – it’s quite a complex tool. It requires some knowledge, experience, and creativity.

However, if you want to be a great project manager, you must know how to create and use work breakdown structures. I’ve got you covered! This article will explain everything you need to know.

Work Breakdown Structure Definition

According to the Project Management Institute:

WBS (Work Breakdown Structure) is “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. It organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the project work… .” – PMBOK® Guide.

Table of Contents

Work Breakdown Structure Example For a Software Project

A Work Breakdown Structure diagram that shows decomposition of seven deliverables of an IT project
Click to open a full-size version of this image.

Annotation to Work Breakdown Structure Example for Software Development Project

Let me point out several critical concepts in this work breakdown structure. Then, I’ll show you the WBS Dictionary below as well. 

Point #1: Product Vision at the Top

At the top of the structure, there’s always the final product, service, or result. It should represent the vision of the full scope of your project.

If you create all project deliverables below and put them into a cohesive whole – they should result in the final product or service.

Point #2: Major Deliverables or Project Phases

On the second level of decomposition, the work breakdown structure should contain your major deliverables. These are the elements with 1–7 WBS codes.

You may also put the project phases on this level—for example, Initiation, Requirements, Design, Development, Testing, etc. 

Again, they come from your project’s life cycle. 

However, I don’t recommend phases for a software development project. The only exception is when you have a fixed-price contract. 

Let me elaborate…

Phase-based Work Breakdown Structures

Alpha, Beta, and Release Candidate are the stages of software development. They describe the state of the product.

For example, Alpha is the state where developers have finished the implementation and tested their work. But it’s before the quality assurance team starts testing the product. So, it’s an interim deliverable in project management terms.

Logically, it may seem convenient to put Alpha, Beta, and RC as major project deliverables on the second level of the work breakdown structure. You’ll then decompose them and work towards delivering Alpha, for example.

However, it’ll mean that work on any requirement (a feature) will be partially present in all major deliverables.

For example, development work in Alpha, testing and fixing defects in Beta, and final testing in RC. Decomposing and tracking these related work packages will be difficult.

Here’s another catch!

What about change requests? 

For example, you delivered an Alpha to your customer.

Later, he requested a change and added a new feature. So what now? Do you need to provide Alpha again?

In general, project managers should not put life cycle phases as their major deliverables in the work breakdown structure. It’ll create a mess during the execution of a project. However, I’ll show you a phase-based WBS example.

Work Breakdown Structure Template: Critical Note!

Keep in mind that you won’t find a viable work breakdown structure template for a software development project. That’s because I don’t recommend putting project phases at the top of the WBS.

A diagram that shows agile project life cycle and main phases

On the other hand project deliverables in a software project are way too unique. Their names and descriptions are not standard.

So, don’t put any faith in the work breakdown structures you see on the internet. You can’t reuse them for your projects.

Point #3: Integration Deliverable. What’s that?

Do you see those “Back End,” “Infrastructure,” and “Mobil App” work breakdown structure elements? They look like project deliverables, right?

But what about that “Integration” thing out there (rightmost part)?

A quality WBS can contain specific elements describing the nature of a project or details of its life cycle. It’s one of them.

So, you need to create a “Beta Version of Web App.” When your product has all the must-have features, you need to fix all critical defects. Then you need to provide this build as a deliverable to clients. 

Likewise, project management itself is also a specific type of work breakdown structure element. That is why you should include project management documents as deliverables as well.

This way, you’ll not lose this work in the process. 

Point #4: Tangible Results and Naming

First of all, do notice that there are no verbs in titles. Only nouns and adjectives. 

Secondly, all elements of this WBS describe a tangible result – not a process.

Though, intentionally, some titles are better than others. Check on your own if you feel the difference.

A diagram that shows how information flows from project charter to scope statement and work breakdown structure It continues to tasks and task atributes

Point #5: Level of Decomposition

Also, you can see that deliverables have different levels of decomposition: some have work packages, and some don’t.

On real projects, it is a standard case.

Nowadays, defining all requirements upfront is a luxury that customers cannot afford. 

You’ll progressively elaborate on all deliverables in your work breakdown structure when the time comes.

However, the deliverables are there. Defined, analyzed, and estimated at a high level.

And we’ll take them into our planning in such a state with all related assumptions and risks.

And one more thing here…

Point #6: Deliverable that Requires Decomposition

Deliverable 6, “Mobile App,” is not decomposed into work packages at all. And it’s totally fine.

We may not have any details on it yet. We may not have the expertise to decompose it. Or any other reason. 

But again, it’s a part of this project. So, we keep it as a placeholder. 

Point #7: Child elements constitute 100% of a Parent

It’s not evident from the picture. But you need to include it in your design:

The sum of child elements should result in 100% of a parent. It works for all aspects: required work, costs, duration, etc. When you deliver all child elements, you should automatically get the parent without any extra work.

This concept works on all levels of the work breakdown structure. So, when you finish all major project deliverables – you should get the final product. In our case, deliverable 7, “Integration,” will be the last one.

Point #8: Include 100% of Required Work

It’s something that comes from experience:

Creating a Project Management Plan is one piece of work. Getting it approved is an additional effort.

It applies to lots of other deliverables on a project as well. 

Work Breakdown Structure Video Guide

If you want to learn the most critical aspects of how to create and use a Work Breakdown Structure – do watch this video:

Don’t forget to subscribe to my Channel!

Work Breakdown Structure Example for a Construction Project

Full disclosure: I’m an IT project manager. I know nothing about construction projects. 

However, I understand project management. 

With a few hours of research, I learned about common project phases and life cycles.

It allowed me to create a fictional Work Breakdown Structure for a Construction Project.

Work breakdown structure for a construction project that has seven major phases at the top level of decomposition
Click the image to see a full-size version of this image.

Point #1: Phases on the Top Level of Decomposition

Construction project managers often put project phases at the top level of the work breakdown structure. So, you’ll often see phase based WBS.

Whether to make a WBS with a deliverable focus, structure focus, or system focus comes from your knowledge of the industry’s best practices. 

Unfortunately, there’s not an algorithm to make the right decision.

Point #2: Work Different in Nature

Notice that major project deliverables require different types of work and expertise:

  • Deliverable #1 is mostly engineering.
  • Deliverable #2 is for construction.
  • Deliverables #3-5 are legal and procurement. 
  • Deliverables #6-7 will require a whole mix of expertise.

Point #3: Getting Formal Acceptance is an Effort

It’s another example where you should ensure identifying 100% of the required work to finish a deliverable.

Getting formal sign-off may require several iterations of acceptance testing. You should be ready for it.

Point #4: Several Things Didn’t Fit in

It’s not a complete work breakdown structure. Some deliverables just didn’t fit in. 

For sure, there’s a project management deliverable there and some others. 

If you are from the construction industry, you need to do some research. Learn more about phases, life cycles, and major deliverables. 

Keep in mind that one company usually does similar projects. So, you don’t need to learn all of that for all niches of the industry.

Real-life WBS and Scope Statement Example

Below is a real work breakdown structure example of my early days as a project manager (like 10 years ago).

I’m not proud of it. But I want to show you that it still works. And it’s better than nothing!

Keep in mind that putting the life cycle elements as major project deliverables works only for smaller projects.

Ideally, you want to put them in the “Project Management” or an “Integration” deliverable.

The whole scope baseline that consists of WBS Project Scope Statement and WBS Dictionary
WBS in this case is not really a necessity Nevertheless it is done automatically

Example of the WBS Dictionary

Below is the WBS Dictionary example. Notice that it’s not a final version.

I didn’t fill out all the Notes (or Descriptions) of each WBS Element. Moreover, some of them are really just my notes.

Later, in the process of scope identification, I would write proper descriptions of the work and outcomes of each task.

Example of the work breakdown structure dictionary This WBS dictionary has WBS index title description Jira Epic Requirements and Status columns

WBS Dictionary requires a lot of effort. Therefore, it’s better to apply the Rolling Wave technique with it.

As you can see from this Work Breakdown Structure Example, it required not that much of an effort.

Project Scope Statement was created together with WBS and WBS dictionary in one application.

Also, please note that you don’t have to put “everything” a textbook prescribes. Just ensure that the Scope Baseline serves its purpose.

What is Work Breakdown Structure In Project Management?

Why is the work breakdown structure so important?

It defines all the work for a project. It provides a baseline for future changes. So it helps to control scope creep. It is an input for many processes like cost estimation, schedule developmentrisk identification

It’s a foundation for communication with stakeholders. It is a framework for monitoring and controlling processes.

And the list goes on.

Diagram show the flow information and tool a project manager need to create in order to product a work breakdown structure

Table of Contents:

It takes some experience to understand the importance of a clearly defined scope. When you know what to do, planning and executing the project is just a routine.

So, today, I want to fast-forward you through your professional experience. I want to teach you to make your project more predictable, easier to manage, and more focused on valuable work.

Take a look at different project management methodologies.

You can see that there are just a few approaches to describing and identifying project scope.

Work Breakdown Structure is one of them. It is flexible, scalable and robust.

What’s the Value of WBS for a Project Team?

Out of the top of my head, here’s a short list of benefits that a work breakdown structure can provide:

  1. Defines project scope.
  2. Defines a structure for project integration.
  3. Provides a foundation for estimation of resources, duration, and costs.
  4. Provides proof of needed resources, time, and money.
  5. Helps to prevent scope creep.
  6. Helps to integrate changes.
  7. Focuses the project team members on what needs to be done.
  8. Helps to identify risks.
  9. Provides context for any discussion.
  10. Helps with managing stakeholders’ expectations.
  11. Helps to prevent changes.
  12. Facilitates cooperation.
  13. Gets team buy-in
  14. Provides ownership of a piece of the project.
  15. Shows the impact of each team member.
  16. Shows the global roles of a team member in the project.
  17. Provides an opportunity for initial team building.
  18. Helps with Project Closure.

It looks like a WBS is the most valuable tool in project management. Well, it is:

Project Management Institute names the absence of a Work Breakdown Structure the most common reason for project failure.

Additionally, I have another vision of WBS’s benefit.

Work Breakdown Structure gives you a structured way to deliver value.

What does that mean?

Assume that your project finishes in a day or a week abruptly. How much value have you created?

For example, you have ten features to deliver. You can start working on all of them at once. However, a feature 90% done is worth nothing. You can’t put it on the market.

Quite often, we manage projects as if all work is equally valuable. We think it should be done anyway no matter what. So we do not bother and do it all at once.

But what if your project ends today? Will it deliver value at all?

Work Breakdown Structure organizes the work to provide value and work towards producing tangible results.

Having a structured approach makes it easier to control the project. You’ll always work towards delivery. So, all efforts and resources will be assigned to a clearly defined piece of work.

What are the 3 Types of WBS Design (WBS Representations)?

These are the main work breakdown structure formats you’ll see in the real world.

#1 Work Breakdown Structure Chart

Work breakdown structure in hierarchical chart representation

You can use it on a daily basis to communicate project status to your team. When you set goals, it’ll be easier to show your expectations. So I think this representation is a must-have.

I suggest you always have a hierarchy diagram for a work breakdown structure. It gives you a visualization of your project breakdown.

#2 Hierarchical Structure

Work breakdown structure in hierarchical list view inside Merlin Project project management software

Likewise, you will always see a hierarchical list in all project management software. So, never purchase solely work breakdown structure software. WBS should be an integral part of the application.

Here’s the list of project management software you can try:

  1. Mac OS: Merlin Project
  2. Windows: MS Project
  3. Web: Wrike

#3 Tabular WBS Design

Tabular representation of a work breakdown structure

Here’s one video from my online course, How to Boost Your Project With Expertly Built WBS 2.0. Here, I explain the definition and show key representations.

What are the Key Concepts of Work Breakdown Structure?

1. Product Scope vs. Project Scope

At the top of the work breakdown structure, there’s always the final product, service, or result.

It should represent the vision of the full scope of your project.

And here, you need to understand the difference between project scope and product scope:

Product scope is the feature and functions that characterize a product, service, or result.

Product scope defines how a product should work, what it should look like, what traits it will have. It’s all about the product and its functionality.

Project scope is the work performed to deliver a product, service, or result with specified features and functions.

The project scope defines the work required to produce a product, service or result that is described by the product scope.

It means that the project scope includes the product scope, plus the efforts required to analyze and research product requirements, assure quality, manage the team, hand off the product, etc.

So, do not forget. You need a vision of the project scope at the top of a work breakdown structure.

2. Deliverable-Oriented Structure

A deliverable is a tangible part of the work completed to meet project objectives. It can be a part of the product or service that stakeholders can try or see. It can be a project document or a part of the Project Management Plan. In any case, it is something important we need to finish our project.

Therefore, a WBS is oriented at decomposing project work into tangible pieces of the project scope.

3. Decomposition

Decomposition is a planning technique that helps to divide and group the project scope and deliverables into smaller, manageable components that support your executing, monitoring and controlling needs.

So, what’s this decomposition again?

But essentially, it’s what you do to break down the project into smaller pieces: deliverables -> work packages -> activities.

At the top of a work breakdown structure, there’s always your product, service, or result.

On the second level, there will be major project deliverables of the project. Quite often, they are described in the Project Charter. So, there are always at least two levels in a WBS.

If your project is large and complex, it’ll be divided into project phases first. Each phase can have a separate WBS.

However, a Work Breakdown Structure is scalable to any extent. Therefore, you can have a portfolio and program as well as a project or a sub-project WBS. They all follow the same set of rules.

On the third level, you may have either interim deliverables or work packages.

4. Work Package

Again, according to the Project Management Institute:

“A deliverable or project work component at the lowest level of each branch of the work breakdown structure. The work package includes the schedule activities and schedule milestones required to complete the work package deliverable or project work component.” – Practice Standard for Work Breakdown Structures 2nd Ed.

Therefore, the main aspects of a work package:

  • It’s the result of further decomposition of a Deliverable.
  • It’s still a tangible and verifiable piece of work.
  • The lowest level of decomposition of work in the WBS.

How to Create Work Breakdown Structure

The quality of a WBS can make or break your project.

Yes, poor quality Work Breakdown Structure is often a cause of a failed project.

Here’s how to create a high-quality WBS.

1. Identify major project deliverables

Read through Project Charter and Project Scope Statement, review emails and meeting notes, check project management plans from past projects, etc.

Your goal is to collect all deliverables mentioned by stakeholders during project initiation.

2. Brainstorm

Gather appropriate team members for a brainstorming session. Invite available subject matter experts.

You can also consider contacting project managers who did similar projects.

Your goal here is to define the first two levels of the work breakdown structure.

I mean project phases and additional major deliverables. Do not forget to name the interim and internal ones.

I try to encourage idea generation and broad thinking.

Therefore, we usually put everything on a whiteboard. I don’t bother logging deliverables into the software application during this meeting.

To capture everything from the whiteboard, I simply take a photo.

3. Triage and structure the deliverables

How to identify project deliverables?

The answer is simple: work with the team and stakeholders.

Sometimes, it’s a separate meeting. Sometimes, it’s the extension of the brainstorming one but with team leaders only.

Together, we try to finalize the second level of decomposition. We give proper and final names to WBS elements.

Then, we define what really are the major deliverables and group the rest as sub-deliverables.

Now we log everything into our software.

4. Assign responsibility for deliverables

Each deliverable in the work breakdown structure should have one responsible person. Usually, it will be one of your project team members. So, creating the RACI Matrix based on deliverables is a good practice.

Example of a RACI matrix based on deliverables and roles on a project

5. Team leaders decompose Deliverables into Work Packages

At this moment, team leaders work with project team members to decompose the project further.

I try to stay away.

Usually, I only facilitate meetings with experts and try to keep the team focused on getting things done.

They are prone to debate a lot here.

Note that you need to educate your team. Don’t expect them to know the ins and outs of WBS as well as you do

6. Verify the WBS

Depending on the policies and processes, you may need to validate WBS with some stakeholders.

If not, I still recommend you to review the final draft with the team and peer PMs.

7. Present WBS to customers. Get feedback. Make corrections. Get sign-off

Yes, you do need to get some kind of sign-off from the customer.

Otherwise, customers will have an opportunity to say that YOU forgot something.

And it’ll happen at the end of the project as usual.

Therefore, throughout the whole process, you need to build their buy-in. They should share responsibility for scope identification with you.

How to Make a Usable WBS

Creating a WBS and putting it on a shelf is a waste of time.

It can and should be used on a daily basis.


Work Breakdown Structure as part of the Scope Baseline is input to all critical processes of project management.

Therefore, it means it should be applicable to different aspects of a project. How can you achieve it?

First of all, you need to follow the quality rules described in the guide above.

Second, you need to ensure the following two aspects:

1. Integrate the Project via Work Breakdown Structure

What does WBS integration mean?

Simply put, you need to be able to connect WBS elements with other entities of your project management framework.

For example, each activity should relate to one Work Package. Each hour spent should be tracked against an element in the work breakdown structure.

Planning WBS integration is not easy:

You need to understand how you will use the WBS. What information will you enter? Moreover, you want to have an easy way to query any related information.

A proper software plays a major role here.

It can be a spreadsheet, a dedicated application, or an integral part of a project management solution.

2. Maintain the Integrity of Naming

Regardless of how powerful your project management software is, you’ll have to maintain naming consistency on your own.

For example, some deliverables may be described in a Project Charter.

The goal here is to maintain the relationship between child and parent pieces of scope.

Stakeholders should clearly see how you divided the big whole into smaller deliverables. From time to time, they use terms and words they understand. That is OK to adopt them.

Also, all major deliverables described in the Project Scope Statement should move into the second level of WBS.

It’s beneficial to use stakeholders’ language here. You can always get into technical details at lower levels of decomposition.

So, try to preserve the names of deliverables customers provided in the Project Charter. Then, use the same names in Project Scope Statement and Work Breakdown Structure.

How do Project Managers Use WBS?

1. Use it as a Framework for Integration

WBS provides elements that can be used throughout all project processes as a medium.

These elements will help you to interrelate all pieces of the project work together.

Using WBS as a framework for integration management is a separate topic.

2. Use Work Packages for Activity Definition

The idea here is simple:

You need to take all the work packages on the lowest level and decompose them into activities.

And you do want to preserve the connection of each activity to its “parent”.

Given the rule that all activities should, in sum, produce the work package, it’ll make your life easier.

There are two good practices for a work package:

Firstly, a work package should not be larger than 80 hours of work. Otherwise, it becomes less manageable and predictable.

Secondly, it’s good when a work package fits into one reporting period.

This way, it’ll be easier to communicate progress. You’ll avoid “percent done”. You’ll operate with fully finished work packages only.

Following these rules will make decomposition to activities much easier and will make estimates accurate.

3. Use WBS as a Framework for Communication

If you follow the instructions above, you have a ready-to-use framework for communication.

You’ll operate with names and terms that stakeholders are already familiar with.

Your Project Scope Statement can describe the order in which you’ll work on deliverables.

It will simplify your reporting even further.

You will be able to name the deliverables or work packages the team worked on or is going to work on. And it’ll ring the bell. For most stakeholders, it’ll be sufficient.

The same goes for the cases when you need to integrate a change or include risk response plan activities. You’ll be able to point to a specific deliverable or work package.

Always put stakeholders into the context of a particular work breakdown structure element.

It’ll help them to understand what part of a project you are talking about. You can set a focus for the team the same way.

4. Check WBS for Human Resource Planning

By analyzing your WBS, you’ll be able to define the resources required to deliver each work package.

It will be very handy when you need to use shared resources or plan to acquire rare specialists.

You’ll then create a RACI matrix.

It is a matrix that will help you to determine roles and responsibilities in regard to different deliverables.

It’s an easy way to communicate your expectations to responsible people.

5. Risk Response Planning Should be Tied to WBS Elements

Part of the risks will be avoided or mitigated by performing some particular work – Risk Response Plan. These pieces of work should go into the WBS.

You remember that the work breakdown structure should include 100% of the work. Risk management is a part of the project; don’t let it slip through.

Connect activities related to risk response plans to work packages.

This way, you will have better overall control of the risks and efficiency of your response plans.

6. WBS is the Main Tool for Scope Control and Scope Verification

It goes without saying that you’ll use a WBS to control the scope.

Once you see new activities appear on your project, and you can’t relate them to any work package – it is a Scope Creep

Should you spend more time on an activity you defined – it is an inaccurate estimation.

When you provide deliverables to stakeholders, they’ll give their feedback.

If they accept the deliverable, then you can mark the delivery as finished.

Otherwise, there will be defects or change requests. In the latter case, you’ll need to update the WBS with new requirements.

I understand that you’ll need some practice before it works for you.

There are many ways you can leverage the WBS. Though they depend on the organization you work in.

Nevertheless, I strongly suggest you try using the Work Breakdown Structure on your project to the full extent.


Unfortunately, this article was just one piece of a complex project scope management framework: Many other processes happen before and after this one.

If one part doesn’t work, the whole system breaks.

My Scope Management Plan Template connects all processes and tools into one cohesive system. It also provides access to other articles and videos on scope management. 

Don’t put your projects and reputation at risk. Ensure you know how scope management works in the real world.

All successful project managers know it’s better to learn from someone else’s experience (aka lessons learned). Tap into my 12 years of practical IT experience and get the Scope Management Plan Template.