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 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:
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.
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, lets 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 it’s entirity 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: Requiements, 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).
We do this using the process of decomposition. Decomposition is a 5-step process:
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.
PMBOK states that you can organize the WBS in several ways:
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.
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 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.
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:
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.
This is where all the work component descriptions are documented. Each component within the dictionary should include the following:
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.
When constructing work breakdown structures there are a couple of guiding principles you need to know to keep you on track:
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.
Program Management Primer
The Change Equation
What is the Long Tail?
Program Management: Understanding Effort and Influence
Customer Journey Programmes in Financial Services
Lean Startup and Program Management
Project Management Culture determines Project Success
Simple Scope Management