Work Breakdown Structure Examples (Software, Construction)

A great project manager should master the most crucial tool in project management – Work Breakdown Structure.

But let’s be honest – it’s quite a complex tool. It requires some knowledge, experience, and creativity.

That’s why you need to review the Work Breakdown Structure example below and read the notes. It will help you become a better project manager.

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.

Jump to:

• Work Breakdown Structure Example For Software Project
• Work Breakdown Structure Example for a Construction Project
• Real-life WBS Example + WBS Dictionary Example
• In-depth Guide on Work Breakdown Structure

Work Breakdown Structure Example For Software Project

Annotation to Work Breakdown Structure Example for Software Development Project

Let me point out several critical concepts in this WBS. Then, I’ll show you the WBS Dictionary. 

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 deliverables below and put them into a cohesive whole – they should result in the final product or service.

Point #2: Major Deliverables or Phases

On the second level of decomposition, you want to have your major deliverables. These are the elements with 1–7 WBS codes.

You may also put the phases of a project 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…

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

For example, Alpha is the state where developers 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.

Logically, it may seem convenient to put Alpha, Beta, and RC as major deliverables on the second level. 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, 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, I don’t suggest putting life cycle stages as your major deliverables. It’ll create a mess during the execution of a project. Though, I’ll show you an example with the life cycle stages below.

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

You see those “Back End,” “Infrastructure,” “Mobil App” elements. They look like 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. 

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.

Point #5: Level of Decomposition

Also, you can see that deliverables have a different level of decomposition.

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 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 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 decomposition. So, when you finish all major 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:

Work Breakdown Structure Example for a Construction Project

Full disclosure: I’m a software development project manager. I know nothing about construction projects. 

However, I understand project management. 

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

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

Point 1: Phases on the Top Level of Decomposition

In this example, I put phases at the top level. 

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

It’s a real WBS example for my early days as a project manager.

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 deliverables works only for smaller projects.

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

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.

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

WBS Code	JIRA	Title	Notes
	PT-530	WBS Example	This release is aimed for minimal support of iOS 9. No SAO issues are included into the scope.
1	PT-521	Feature Complete
1.1	PT-526	64-bit Support	To pass the App Store review we have to support 64-bit support.
1.2	PT-531	iOS 9 Issues	iOS 9 issues will be analyzed. If it is a bug in the code or required change – it will be fixed. If a bug is considered an Apple issues it will be either reported or a workaround agreed with <clientname> will be implemented.
1.2.2	PT-532	BUG: iOS 9. Incorrect appearing animation of some popovers/action sheets
1.2.1	PT-533	BUG: iOS 9. Bad appearance of popovers in Edit/Create Story Wizard.
1.3	PT-517	3х Resources	To fully support iPhone 6 and iPhone 6 Plus we need to include 3x resources into the project. In general, this task is optional. But should be double-checked if it is not a mandatory requirement from Apple.
1.4	PT-504	Updatde 3rd Party Licence	Update Licence as it was done in <projectname3> lately.
1.6	PT-502	Library Component adjustments	Maintenance of reuse components.
1.7	PT-518	Update PRProgressHUD to the latest version
1.8	PT-529	Integrate smaller defaultPicLibrary.ptbk
1.9	PT-498	Compressed help pdfs
1.1	PT-487	Latest Dropbox SDK
1.11		Minimum supported iOS version 8.2
1.121		BUG: Application crashes after tap on the Search field	Bug
1.122		BUG: iOS 8 Empty pages shown for PDF help files	Bug
1.12		Testing
1.12.1		Testing on latest iOS 9 Beta	Testing on the latest available version of iOS 9 will be performed to verify fixes and ensure no new issues are introduced.
1.12.2		Full Test	Full test cycle is required to verify 64-bit support.
2		Release Candidate
2.1		New Bugs	Only bugs introduced during work on the current version will be fixed.
2.2		Acceptance Testing
3		Project Management
3.1		Task Analysis	Initial analysis of requirements and their clarification, reading out of specifications, investigation of issues. As a result a list of questions and assumptions should be formed, initial risks identified.
3.2		Scope Statement	Narrative description of the project: description of a deliverable, general approach to the work, assumptions, constraints, exclusions. Done by the manager.
3.3		WBS	Creation of graphical and textual Work Breakdown Structure.
3.4		Estimate	Decomposition and estimates of tasks stated in WBS.
3.5		Schedule	Creation of project schedule. As a result, a milestone chart should be created.

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.

In-depth Guide on Work Breakdown Structure

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 development, risk identification.

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

And the list goes on.

Table of Contents:

• Value of WBS
• Work Breakdown Structure Definition
• Representations of WBS (WBS Design)
• Key Concepts of WBS
• How to Create a High-Quality WBS
• How to Create Work Breakdown Structure
• How to Make WBS Usable
• Work Breakdown Structure Software

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.

Value of WBS

Out of the top of my head, here’s a short list of benefits that a WBS 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 team 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 impact of each team member.
16. Shows 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 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 and 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.

Work Breakdown Structure Definition

Here’s the detailed definition of a 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. It organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the project work… .” – PMBOK® Guide.

I think it’s better to show it once rather than trying to explain it in different words. Watch the video below to get a better insight into what a WBS is.

3 Types of WBS Design (WBS representations)

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

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

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.

Key Concepts of WBS

1. Product Scope vs. Project Scope

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.

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, how should it 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 project scope includes the product scope, plus the efforts required to analyze and research product requirements, assure quality, manage the project team, hand-off the product, etc.

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

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?

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

“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’ss 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 a High-Quality WBS

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.

That’s why I created an in-depth guide on WBS quality. It’s a part of the Resource Guide on Scope Management.

How to Create Work Breakdown Structure

1. Identify major deliverables

Read through Project Charter and Project Scope Statement, review emails and meeting notes, 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 decomposition.

I mean, 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 software application during this meeting.

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

3. Triage and structure the deliverables

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 should have one responsible person. So, we create the RACI Matrix at this point.

5. Team leaders decompose Deliverables into Work Packages

At this moment, team leaders work with others 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.

Why?

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

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, dedicated application or an integral part of project management solution.

In any case, I do not suggest you invent the wheel. Use a suitable product that supports WBS creation.

I think the most important part of it should be an integrated WBS Dictionary.

You should be able to attach documents and images. You need to have enough flexibility to add several text descriptions, tags, and links.

It should be convenient to include all the information about each work package.

Also, it should be easy to make changes to a WBS.

2. Maintain the Integrity of Naming

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

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

They might not be very instructive or clear. Nevertheless, you need to use the names in your Project Scope Statement.

You can use it as a description of the final result. But you need also decompose it into manageable pieces of work.

The goal here is to maintain the relation between Children 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.

Smaller ones may end up lower in the hierarchy.

It is tempting to rephrase some of them to have consistency. However, keep in mind that WBS is also a tool for communication.

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 customer provided from Project Charter. Then, use the same names in Project Scope Statement and Work Breakdown Structure.

6 Practical Applications of a 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 “percents 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 followed 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 or is going to work. 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 packages.

Always put stakeholders into the context of a particular WBS 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 regards 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 WBS should include 100% of 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 of 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 a 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 more you can leverage the WBS. Though they depend on the organization, you work in.

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

Conclusion

Work Breakdown Structure is a powerful and valuable tool in project management.

It’s easy in theory but difficult in practice.

Moreover, there are a lot of aspects that you can learn only the hard way.

Get My Scope Management Plan Template

Most project managers don’t have formal education. That’s why you have to google all the bits and pieces of project management.

I know how frustrating it is to search answer for each step of a project.

That’s why I recommend you get this Scope Management Plan template. It will provide you with access to all my Scope management materials:

Recommend Further Reading:

• Practical Project Management Book
• How to Control Project Scope and Avoid Scope Creep