One Work Breakdown Structure Example That Will Make it Clear

What’s the main problem with a Work Breakdown Structure example? They are all theory in a vacuum. Therefore, below you’ll find a real-life example. I just changed the names and titles under NDA.

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.

Now let me show you a WBS example with annotations. It will help you understand the main principles. After that, you’ll get a real-life example from a small software development project.

Work Breakdown Structure Example With Annotations

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.

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

You see those “Back End”, “Front End”, “Mobile Applications” elements. They look like deliverables, right?

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

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

(You can learn about the best practices of a WBS in the guide below.)

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 team starts testing the product. So, it’s an interim deliverable.

Logically, it may seem convenient to put Alpha, Beta, and RC as a major delivery, 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 deliveries.

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.

On the other hand, 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 to put 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.

If you follow my approach from the guide below, it’ll be much more transparent. Once you produce an interim deliverable (like an Alpha), you can report the work packages included in this delivery.

If a product scope changes, you’ll easily add it to the WBS and will add another interim delivery in the Integration branch.

Your project scope will stay valid. The product development life cycle will incorporate an additional interim state.

What else should you notice here?

All WBS elements have only one parent and don’t have a relation to the others.

There are no verbs in titles. All of them are results.

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

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

On real projects, it is a standard case.

Nowadays, defining all requirements upfront is the luxury 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.

Real-life WBS Example

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

That’s why I created an in-depth guide on WBS quality:

Get the Guide

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.

Check Your Current Knowledge of the WBS

Take this short quiz to identify the knowledge gaps that you have right now.

Work Breakdown Structure Software

Here is important advice.

WBS should not take too much effort to create and maintain it. Keep it simple.

If your software does not allow you to create a hierarchy diagram easily, don’t do it in MS Word, please. Forget about the hierarchy diagram. Go for an outline. You can do it in any text editing tool.

If you are in the position to choose a project management software for your project – use the form below to find the most suitable solution.

I recommend to also read:

• Scope Baseline, Project Scope Statement and More (+Examples)
• Check Project Management Basics library for valuable downloads.