Why is 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 costs estimation, schedule development, risk identification.
It is a foundation for communication with stakeholders. It is a framework for monitoring and controlling processes.
And the list goes on.
It is a long guide. It goes in every detail of a Work Breakdown Structure. You can get it in PDF version along with other useful books. Click here to get access to the whole library.
Table of Contents:
1. Value of WBS
2. Work Breakdown Structure Definition
3. Representations of WBS (WBS Design)
4. Work Breakdown Structure Software
5. Key Concepts of WBS
6. How to Create a High-Quality WBS
7. How to Create Work Breakdown Structure
8. How to Make WBS Usable
9. Work Breakdown Structure Example
Check Your Current Knowledge of the WBS
Take this short quiz to identify knowledge gaps that you have right now.
It takes some experience to understand the importance of ca learly 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 is a short list of benefits that a WBS can provide:
- Defines project scope.
- Defines a structure for project integration.
- Provides a foundation for estimation of resources, duration and costs.
- Provides proof of needed resources, time and money.
- Helps to prevent scope creep.
- Helps to integrate changes.
- Focuses the team on what needs to be done.
- Helps to identify risks.
- Provides context for any discussion.
- Helps with managing stakeholders expectations
- Helps to prevent changes
- Facilitates cooperation
- Gets team buy-in
- Provides ownership of a piece of the project
- Shows impact of each team member
- Shows global roles of a team member in the project.
- Provides an opportunity for initial team building.
- 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 you 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 will always work towards delivery. So, all efforts and resources will be assigned to a clearly defined piece of work.
Work Breakdown Structure Definition
Here is 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 is better to show it once rather than trying to explain in different words. Watch the video below to get a better insight on what a WBS is.
3 Types of WBS Design (WBS representations)
Here is 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 will be easier to show your expectations. So I think this representation is a must have.
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.
Key Concepts of WBS
1. Product Scope vs. Project Scope
At the top of the structure, there is 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 is 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 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 project scope.
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 is decomposition again?
It is what you do to break down the project into smaller pieces: deliverables -> work packages -> activities.
At the top of a work breakdown structure, there is 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. There are always at least two levels in a WBS.
If your project is large and complex, it will 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 programme 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, a work package is:
- It is the result of further decomposition of a Deliverable.
- It is 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
Quality of a WBS can make or break your project.
Yes, poor quality Work Breakdown Structure is often a cause of failed projects.
That is why I created an in-depth guide on WBS quality:
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 interim and internal ones.
I try to encourage idea generation and broad thinking. Therefore, we usually put everything on a whiteboard. I do not 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 is a separate meeting. Sometimes it is 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.
5. Team leaders decompose Deliverables into Work Packages. At these 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. Do not 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, he will have an opportunity to say that you forgot something. And it will happen at the end of the project as usual.
How to Make WBS Usable
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 above. Second, you need to ensure the following two aspects.
1. WBS Integration Into a Project
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 can use the WBS. What information will be required? 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. Integrity of Naming
Regardless of how powerful your software is, you will have to maintain naming consistency on your own.
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 the 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.
Now, 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 is beneficial to use stakeholders’ language here. You can always get into technical details at lower levels of decomposition.
So, try to preserve names of deliverables customer provided from Project Charter. Then, use the same names in Project Scope Statement and Work Breakdown Structure.
How to Use WBS
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 piece of the project work together.
Using WBS as a framework for integration management is a separate topic. I touch it a bit in my WBS online course.
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 will make your life easier.
There are two good practices for work packages.
Firstly, a work package should not be larger than 80 hours of work. Otherwise, it becomes less manageable and predictable.
Secondly, it is good when a work package fits into one reporting period. This way it will be easier to communicate progress. You will mostly avoid “percents done”.
Following these rules will make decomposition to activities much easier and will make estimates more accurate.
Framework for Communication
If you followed the instructions above, you have a ready-to-use framework for communication.
You will operate with names and terms that stakeholders are already familiar with. Your Project Scope Statement can describe the order in which you will 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 will ring the bell. For most stakeholders, it will be sufficient.
The same goes for the cases when you need to integrate a change or include risk response plan activities. You will be able to point to a specific deliverable or work packages.
Always put stakeholder into the context of a particular WBS element. It will help them to understand what part of a project you are talking about. You can set a focus for the team the same way.
Human Resource Planning
By analyzing your WBS, you will 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 will then create a RACI matrix. It is a matrix that will help you to determine roles and responsibilities in regards to different deliverables. It is an easy way to communicate your expectations to responsible people.
Risk Response Planning
Part of the risks will be avoided or mitigated by performing some particular work. This 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.
Scope Control and Scope Verification
It goes without saying that you will 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 will give their feedback. If everything suits then you can mark a delivery as finished. Otherwise, there will be defects or change requests. It the latter case you will need to update the WBS with new requirements.
I understand that you will 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.
Work Breakdown Structure Example
At the top of the structure, there is 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. It is elements with 1–7 WBS codes.
You see that “Back End”, “Front End”, “Mobile Applications” elements. They look like deliverables, right?
But what about that “Integration” thing there?
You might remember point #18 of the quality principles. A quality WBS can contain specific kinds of elements that describe the nature of a project, or details of its life cycle. It is one of them.
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 implementation and tested their work. But it is before the quality team starts testing the product. So, it is an interim deliverable.
Logically, I may seem convenient to put Alpha, Beta, and RC as a major delivery, on the second level. You will then decompose them and work towards delivering Alpha, for example.
However, it will 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?
I do not suggest to put life cycle stages as your major deliverables. It will create a mess during the execution of a project.
If you follow my approach, it will 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 will easily add it to the WBS and will add another interim delivery in Integration branch. Your project scope will stay valid. The product development life cycle will incorporate additional interim state.
What else should you notice here?
All WBS elements have only one parent and don’t have 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 luxury customers cannot afford. You will progressively elaborate all deliverables when the time comes.
However, the deliverables are there. Defined, analyzed and estimated at a high level. And we will take them into our planning in such state with all related assumptions and risks.
Work Breakdown Structure is a powerful and valuable tool in project management. It is easy in theory but difficult in practice. Moreover, there are a lot of aspects that you can learn only the hard way.
I recommend to also read:
- Scope Baseline, Project Scope Statement and More (+Examples)
- Check Project Management Basics library for valuable downloads.