The purpose of this article is to provide you with everything you need to know about Work Breakdown Structures (WBS) so you can improve the way you plan, manage, and control your projects and programs.
PMBOK defines a WBS as “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. The WBS defines the total scope of the project.”
An easier way to think of Work Breakdown Structures is as being similar to a family tree, that is, they are a tree structure showing the subdivision of components necessary to deliver a project or program. Work Breakdown Structures are very useful for establishing an agreement between stakeholders and project team members as to the scope of the project.
In a general sense, we can think of WBS as follows:
How to Get Started?
If we think about starting a project, we begin with a project charter and preliminary scope statement. This defines the high-level goals and deliverables of the project. We then create the project scope document which further defines these deliverables into a list of all deliverables and the requirements of each. The next step is to use this comprehensive list of deliverables to build the WBS.
The WBS will detail the full scope of the work necessary to finish the project. The WBS can then be used to estimate the cost of the project, schedule resources, and plan quality gates. Essentially the WBS will enable you to better manage your project.
Some WBS Examples
The best way to understand work breakdown structures is by means of some examples. We’ll look at two examples, one which looks at the components that make up a Car, and another which looks the components that make up a Project. Firstly, let us look at the components which make up a car.
At the very top of the WBS is the project or program name, in this case, Car. The lowest level of any WBS is always called the work package level. Thus, in the example above, 4.0 Chassis is a work package to deliver the Chassis in its entirety for the car.
Now let’s consider the WBS for the Project:
Here we can see that the project is made up of four phases: Requirements, Design, Build and Deliver.
One way to think about these two examples is that the Car example is showing the “what” (the components of the car), and the Project example is showing the “how” (the components needed to deliver a generic project).
Getting to a Point Where we can start to plan
We do this using the process of decomposition. Decomposition is a 5-step process:
- Identify all the major project deliverables. One way to do this is to involve the project team as a group to identify all the major deliverables from the project scope statement.
- Organize the WBS (we’ll cover next)
- Define the WBS components. Here we decompose the major deliverables defined in step 1 into lower level components.
- Assign identification codes. This can be done simply by attaching a number to each of the WBS components. All the examples I’ve used have identification codes attached.
- Verify the WBS. Here we validate the WBS for correctness. Ask yourself and the team questions such as “are all the components clear?” Are all components complete? Is each component absolutely necessary? Does the decomposition sufficiently describe the work which needs to be done?
It’s a lot of work to do this, but really beneficial if you’re at the early stages of managing your project or program. By deconstructing the tasks you may identify areas you would not have otherwise noticed until later in the project execution. This makes you more likely to get things right up front and stops the teams getting frustrated because you will not be asking them to change things several times during the project.
Organising the WBS
PMBOK states that you can organize the WBS in several ways:
- Major deliverables and subprojects: here the major deliverables of the project or program are used as the first level of decomposition. This is the approach we used for the Car example above.
- Subprojects executed outside the project team: you can think of this as being like streams within a program. For example, if on one stream is to roll out the product globally, then the rollout project manager can define the WBS for this component. Often a subproject will be contracted out.
- Project phases: using this technique, each phase of the project would be listed in the first level of decomposition, with the deliverables of each phase listed in the next level. This is the approach we used for the Project example previously.
- Combination approach: this is a combination of the organizational methods, for example, you might have subprojects listed on the first level, with the major deliverables of each listed on the 2nd level.
When to Stop
Don’t go crazy when creating your Work Breakdown Structures. What you’re trying to do is define the work of the project or program so you can easily plan, manage and control that work. You should only decompose the plan to a level that allows you to achieve this aim.
WBS and Agile
Having read this far, you may well be thinking that work breakdown structures are very old fashioned and don’t apply to Agile. However, WBS equally applies to Agile. An agile WBS is organized around end-user functionality. Here, features are decomposed into Epics, Epics into User Stories, and User Stories are decomposed into Functionality which can be implemented within a single iteration. Because an individual user story is atomic, stories can be added or removed from the WBS provided the sum of the work can still be implemented within one sprint.
At this point, I think I should add a personal note on this. This is the theory of Agile work breakdown structures, but I don’t in practice think it is necessary to do this, as most Agile methods effectively make this a duplication of effort.
Unique WBS Identifiers
It’s good practice to assign a unique identifier to each level of the WBS. For example, we might use the following based on the Car example we looked at earlier:
Work Packages
As mentioned previously, the lowest level in a WBS is a work package. Work packages are components which can easily be given to a person, a team, or a subcontractor, who then has accountability and responsibility for delivering the work package. Click here for more information on Accountability and Responsibility.
In programs or large projects, a work package may be at a level requiring further decomposition into its own work breakdown structure. The breakdown of the work package might then be done by the project team for that work package or even an external vendor.
WBS Dictionary
This is where all the work component descriptions are documented. Each component within the dictionary should include the following:
- The identifier
- Statement of work, describing the work which makes up the component
- Milestones
- Person/Organization responsible for completing the component
Scope Baseline
Now that you have created the Work Breakdown Structure you are ready to baseline the scope of the project or program you are managing. The scope baseline for your project or program is defined as the approved project scope statement, the work breakdown structure, and the WBS dictionary.
Design Principles when Constructing Work Breakdown Structures
When constructing work breakdown structures there are a couple of guiding principles you need to know to keep you on track:
- The 100% Rule: The WBS should define the total scope of the project. If it doesn’t do this then the plans you create from the WBS will by inference have gaps and missing components.
- Mutual Exclusivity: there should be no overlap between any two elements in a WBS. If there are, then you run the risk of duplicating work in the project execution
- Include Deliverables, Not Actions: I’m not going to go into details (you’ve done well to read this far already) but this is one of the best ways to stick to the 100% rule
- Use Common Sense: as mentioned previously, don’t go into too much detail. What you’re looking for is enough detail so you can plan, manage and control the project.
Conclusion
I hope that this article has given you everything you need to know about work breakdown structures (WBS), that you can see the value in them, and that it’s clear to you how to apply this information to your next project or program. Remember that the greatest benefit of a work breakdown structure is to establish a common understanding of all work required to deliver the project or program. Feel free to contact me if you have any questions.
