Project goals are often quite large and the process of achieving them complex. It is the very raison d'être of a project however it doesn’t make it a straightforward process to define how the goal can be achieved. Many Project Managers will struggle to take a large deliverable and turn it into a timeline of activities that need to be completed and the best way to work in order to complete them. The Work Breakdown Structure or WBS provides a way to do just that. In a traditional project a WBS helps to create a detailed project schedule and is usually done up front during initiation (the Gantt chart is an outcome of the WBS and detailed project schedule). In an Agile project a WBS can also be useful however will be iteratively developed over time instead of up front with the first WBS focused only on an iteration or release.
What is a Work Breakdown Structure?
The Work Breakdown Structure or WBS does as the name suggests, it takes the project (100% of the work) and breaks it down into smaller, more manageable parts. The WBS can be used for all types of projects however is most commonly associated with Waterfall Projects and done at the beginning of the project. It is useful in these Projects given the need to try and plan the entire delivery up front as well as estimate cost, resources etc.
4 essential hierarchy layers of WBS
- The Project Goal – 100% of the work
- The Objectives that need to be met in order to deliver the Project goal – each objective will be a % of the whole Project (in an Agile WBS this may be a Release)
- The outputs required to deliver the objective – each being a % of the Objective (in an Agile WBS this may be an iteration or increment)
- The Activities that will deliver the output – each being a % of the Output (in an Agile WBS this may be a feature).
This detail effectively creates work packages, which can be managed by a person or a team to deliver back to the Project. Each Work Package will have a % of the overall work and can therefore have an assumed % of the budget required. The WBS can also be used for bottom up budget estimations where each work package is assigned resources over time, which in turn will generate cost. The sum of all Work Package costs is the expected overall Project Spend.
Many Agile Project Managers may feel a WBS is not needed for an iterative Project that will not define all work up front. The WBS is absolutely an optional approach and there is nothing saying that it is mandatory. However, irrespective of methodology, if you are looking at a larger piece of work and not sure where to start, the WBS definitely has its uses even if it helps to inform a single release or iteration.
What are some work breakdown structure examples?
If you are ever trying to puzzle out what a WBS is and how it can work for you, perhaps try some everyday project examples such as planning for a holiday or building a house. All work is made up of smaller components and the more you can practice seeing them, rather than just the biggest piece, the better you will become.
Waterfall WBS example
Below is an example of a Waterfall WBS that uses the layers in the hierarchy to break the Project (100% of the work) into smaller work packages.
Agile WBS example
Below is an example of an Agile WBS that focuses on breaking down the project into releases, iterations and the features or story points that will be done in each.
Excel is an easy tool to use to develop an initial WBS and can be done by a Project Manager but it is best if done collaboratively with those that will own work packages and ideally, when the WBS is quite detailed, done with specialist PPM tools. As always take the most useful approach and tailor it to your needs.