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 takes some experience to understand the importance of 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 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 need 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 organises 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.
Test Yourself!
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 organises 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.
Representations of Work Breakdown Structure
Here is one video from my free online course How to Boost Your Project With Expertly Built WBS. Here, I explain the definition and show key representations.
If you want to get access to the rest of the videos, get free access now.
I suggest you have a hierarchy diagram always. It gives you the visualisation 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 an 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 hierarchy diagram. Go for an outline. You can do it in any text editing tool.
Here is the list of software applications that I can recommend for WBS purpose.
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 characterise 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 efforts required to analyse 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.
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 is decomposition again?
It is what you do to break down the project into smaller pieces: deliverables -> work packages -> activities.
At the top of 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 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
No matter what tools and techniques you will choose, you must involve your team. People who will do the work should participate in creation. Meetings, brainstorming, and interviews are your instruments of choice.
Involving stakeholders is also a good idea. They can provide valuable input. Remember, you need to identify 100% of work.
Also, keep in mind, the internal stakeholders. They may impose additional deliveries on your project. For example, a particular report, regular meetings, or formal policy compliance.
Everything takes time. Every effort should move you closer to the project deliverables. All deliverables should support the project objectives.
Here is the problem. The absence of a WBS on a project often leads to project failure. The presence of a poorly created WBS also leads to project failure. That is why you will see a lot of arguing on the Internet about benefits of Work Breakdown Structure. But I will teach you how to create a quality WBS.
I should admit. I have a negative experience of failing a project due to the low quality of WBS. It is like Scrum. It is easy in theory, but it is hard to master. Moreover, it’s hard to see the benefits because WBS, in general, is aimed at avoiding problems. It is not enough just to have a Work Breakdown Structure. You need a quality one.
Core Characteristics of a Quality WBS
There are a set of traits that a quality WBS should have. It is dictated by the concept and purpose of the tool.
There is an extensive list below. However, it is worth the efforts. You can apply these principles in any project management methodology. It doesn’t matter whether you decompose your project into Deliverable and Work Packages or into User Stories.
1. Quality WBS is a deliverable-oriented grouping of project scope. It means that we should work towards creating tangible results throughout the whole project lifecycle. Not only in the end. We deliver project scope incrementally or by separate pieces. Nevertheless, we need to verify these parts of project scope continually with a customer.
2. Quality WBS defines the scope of the project, and it contains 100% of the work defined by the scope. Remember that every single task takes time. Failure to include all work into WBS may lead to going over budget or behind schedule.
3. Any Work Breakdown Structure should contain elements that are defined using nouns and adjectives—not verbs. This one is huge. I would say if you try keeping to only this rule, your WBS will be twice better. You see nouns and adjectives describe the result. Something we want to achieve. Verbs describe a process.
You can measure the desired outcome. You can say when the result is achieved. But it is hard to do the same for a process. For example, WBS work packages: “Product Design Creation” or “Product Design”. Both are aimed at Product Design. However, only the second one will succeed.
4. Quality WBS is a tool for communication first of all. It should clarify the work and project scope to all stakeholders (including project team). Therefore, it should not be “smart”. It should be simple and clear.
5. Quality WBS includes internal, external, and interim deliverables. Do you want to deliver the project successfully? Then, do not hide your internal needs. Producing internal and interim deliverable also takes time and money. Show it as a part of project scope.
6. Quality WBS includes project management deliverables. WBS, Project Management Plan, Risk Register, whatever. It all takes time. Even if you are not asked to produce these project management artefacts, you need them for your own use. Like I said in the previous point, WBS should include all internal deliverables.
7. In a quality, WBS child levels contain 100% of a parent level. I often see this problem. Especially in software development. A major deliverable is decomposed nicely into separate work packages. They describe all pieces that are needed. But no WBS element represents the integration of this interim deliverable. Putting it all into one working (interim) product. It is supposed to be a part of the product development process. But it is not. You do need to setup a system to produce a deliverable at least once.
8. To identify 100% of project scope, you need you engage in the creation of WBS those who will be performing work. You should also solicit feedback and input from subject matter experts, technical, financial and business managers, and other stakeholders.
9. In a quality WBS, there are no work packages that you do not know how to deliver. Otherwise, you input uncertainty into project scope. It is not the way you should manage unclear and ambiguous parts of a project. It is better to plan for design, research, and investigation as a separate deliverable. If your project requires R&D activities, you should plan them accordingly. Do not hide them within work packages of delivery.
10. Work Breakdown Structure is not a one-time endeavour. You will progressively elaborate it. Which means you will know more about deliverables when you start working on them. You will add more levels of decomposition and clarify work packages. However, be careful. Progressive elaboration and Rolling Wave Planning technique do not imply that you can omit unclear parts of scope. All deliverables should be added to WBS. Even if you do not know all the details.
Please notice that this point doesn’t contradict with the previous one. If you start decomposing a deliverable, ensure that you will be able to decompose work packages into tasks (activities). Otherwise, it means you need more time and effort to define requirements.
11. A quality WBS can be updated following project change control. What does this mean? Whenever you need to add something due to a change request, your WBS should not break apart.
There are also a set of “technical” traits of quality WBS:
12. It has at least two levels with at least one level of decomposition.
13. It arranges all major and minor deliverables in a hierarchical structure.
14. It provides a graphical, textual, or tabular breakdown of the project scope.
15. It has a coding system that clearly shows a position for each element in the hierarchy. It applies to all representations.
Use-related Characteristics of a Quality WBS
16. A quality WBS achieves a sufficient level of decomposition. Though it will differ from organisation to organisation and the nature of a project. In general, the level of decomposition should be enough for you to manage the project. Depending on the project complexity you need to limit the size of delivery. It should also not be too small. Micromanagement is the last thing you want to achieve. I have a rule of thumb here. I stop decomposition at the level where I’m comfortable to delegate the work to my team leaders.
17. A quality WBS should contain enough details for communicating all work. It means it should provide no more, no less information than needed. Some common deliverable may not require complete decomposition. For example, a piece of standard hardware. Stating the model will be sufficient. On the other hand, unique deliverables should be described in all possible details to communicate required efforts.
18. A WBS is not a strictly standardised tool. Therefore, a good one can contain specific kinds of elements that describe nature of a project, or details of its life cycle.
19. A quality WBS should also be appropriate for monitoring and controlling activities. It goes for both internal and external tracking. In varies widely depending on the organisation. But in general, your WBS should contain elements appropriate to provide information on a regular basis. You should be able to use WBS for scope, cost and schedule performance reports.
WBS quality characteristics apply at all levels of scope definition. As Practice Standard for Work Breakdown Structures Second Edition states:
“There is no conceptual difference between a project WBS, a program WBS, and a portfolio WBS. A high-quality WBS developed at any of these broader levels possess precisely the same characteristics and attributes as a high-quality WBS developed at the individual project level. These differ only in the breadth of the content and scope.”
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 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 white board. 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 finalise 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.
Why?
Work Breakdown Structure as part of Scope Baseline is input to all critical processes of project management. Therefore, it means it should be applicable in 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 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 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.
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 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 the 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 analysing your WBS, you will be able to define 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 a 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 organisation, 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 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 to 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 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 into 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 can not afford. You will progressively elaborate all deliverables when the time comes.
However, the deliverables are there. Defined, analysed and estimated at a high level. And we will take them into our planning in such state with all related assumptions and risks.
Conclusion
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.
Therefore, I strongly suggest you learn it in more details through my free online course.
The post Ultimate Guide on How to Create a Robust Work Breakdown Structure appeared first on PM Basics.