An Under-Utilised but Effective Tool You Can Use To Improve Your Project's Success
It takes a bit of practice but this tool can improve the success of your project.
Work Breakdown Structure is a core principle within the PMI’s PMBOK. They even created a Practice Standard for it. Love or loathe it, work breakdown structures play an important role in project management. You might think that you don’t use it at all. But when we plan, we use some sort of hierarchical breakdown of the work. It may not be as formal as the PMBOK makes it out to be but we do decompose the work to help with planning.
What I want to do today is to summarise the WBS and show some techniques you can use to help you create one for your project.
What is a WBS and do we need one?
The WBS is a structured and hierarchical breakdown of the project’s scope and the work that needs to be done to meet its objectives.
The objective of the WBS is to break down the work into smaller, knowable sizes and reduce the uncertainties in completing the work. The WBS then drives the project plan and provides input into the other knowledge areas and processes of the project. It also helps with the monitoring and controlling of the project.
It improves the planning of the project by having smaller manageable tasks. This can be used to work out dependencies and sequences of the activities. By having smaller tasks that can be easier to estimate, the project team can estimate the effort and resources required.
It helps to identify the deliverables and output of the project and organises the project scope into different types of work or outputs that need to be done. It helps in the breakdown of the work from the highest conceptual level to the smallest tangible work packages.
The WBS is hierarchical because it allows the grouping of smaller pieces of work that collectively deliver a higher level deliverable. For example, the Architecture Design Document may be at level 1.1 and it can be decomposed into 1.1.1 for the Infrastructure Design, 1.1.2 for the Integration design and 1.1.3 for the Software Design. And within the Level 3 hierarchy, it can be broken down even further. Under the Infrastructure design document, there may be 1.1.1.1 - Servers, and 1.1.1.2 - network design.
Approaches to creating a WBS
Creating a WBS is simple but never easy.
You start by identifying the project scope.
You decompose the scope of work into deliverables and activities.
You review and refine until you have captured all the items for the project scope.
A WBS can be broken down into phases. Or it can be broken down by deliverables. A WBS broken down by product is known as a Product breakdown structure and is a concept used within the Prince2 methodology.
A waterfall project would do this upfront and baseline it before proceeding past the Discovery phase. Any updates to WBS are potentially a change request.
WBS for waterfall projects are usually broken down into phases and each decomposition is the deliverables or output for each phase.
An agile project would iterate through each release and each sprint to get the WBS until you get it correct. In Agile projects, epics, features and user stories represent the decomposition of work. Instead of doing it upfront, the release planning, backlog grooming and sprint planning sessions decompose the work as the project progresses.
Creating a WBS by phases can be simplistic and does have limited value. The most effective use of a WBS is to break down the deliverables and the work. By having a hierarchical breakdown of the project deliverables, then you can start working through a sequence of activities that falls within the various phases.
Elements and Concepts
To use a WBS for your project, it is useful to know the terms and concepts that come with it. I’ve included the terms that directly impact the WBS (some definitions have been removed). This section comes from the PMI Lexicon of Project Management Terms, PMBOK Guide, and Agile Practice Guide.
Activity - a distinct, scheduled portion of work performed during the project.
Deliverable - Any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase or project.
Planning Package - a control account may include one or more planning packages. A planning package is a work breakdown structure component below the control account and above the work package with known work content but without detailed schedule activities.
Scope - the sum of the products, services and results to be provided as a project.
Scope baseline - the approved version of a scope statement, WBS and it’s associated WBS dictionary that can be changed using formal change control procedures and is used as a basis for comparison to actual results.
Work breakdown structure component - an entry in the work breakdown structure that can be at any level
Work breakdown structure element - any single WBS component and its associated WBS attributes contained within an individual WBS.
WBS Dictionary - a document that provides deliverable, activity, scheduling and estimating information for each element in the WBS.
Work package - the work defined at the lowest level of the WBS for which cost and duration are estimated and managed.
Principles of WBS
The principles of using the WBS are:
The work at the lowest level of the hierarchy rolls up to the higher levels. The sum of the work at the child level totals the work at the parent level. This ensures that all scope and deliverables are captured.
WBS do not contain costs, or resource assignments, do not have time or sequence, don't show relationships and don’t imply importance
There are no limits to the levels of decomposition.
WBS items do not overlap and avoid duplication.
How to Decompose
The approach is usually an iterative process. You start with a high-level WBS and as you progress through the Discovery phase, you start breaking it down into more detail.
Input required for a WBS are usually:
Initiation documentation
Requirements/ Features/ Epics
Design
Technical and/ or functional specification
The PMI Practice Standard on WBS has a set of questions that you can use to help develop the WBS. I’ve replicated it below and have created a separate document as a checklist for you to use.
Is the product of the project part of another project?
Is the project charter defined and issued?
Which project life cycle is used? (Waterfall, Agile or Hybrid)
Is the project scope statement defined and issued?
Have the project manager and the team formulated a vision of the final product(s), service(s), or result(s)?
Have personnel who will do the work been assigned to develop the WBS?
What are the project’s component parts?
How do the pieces work together?
What are the needs and expectations?
Have the project’s intended business objectives been defined? What is required to achieve the business value?
Has the entire project been thought through? Have the high-level deliverables been sufficiently decomposed?
Have both interim and final deliverables been identified? What is to be provided? What is required?
has the relationship of each component to the product been defined? How will this component contribute to the finished deliverables?
Has the process for the production of the deliverables been defined? What methods and practices will be employed? What special processes will be needed? What are the quality requirements? What kinds of inspections need to be done?
Have the activities needed to support the deliverables been identified, including those that directly or indirectly facilitate their creation?
Has technical input from knowledgeable subject matter experts (SMEs) been obtained, and is that technical input communicated to and validated by other key SMEs assigned to the project?
Does the project require any external sources to contribute to the project and have they been identified?
Has all work associated with quality and risk management been identified?
Have the risks associated with project assumptions been identified?
Has all the work associated with project management been defined?
Top Down Approach
This is the most common approach to building a WBS. As the project manager, you need to ensure that no work packages are missed and it is at a sufficient level for oversight and control.
Identify the project’s deliverables and outcomes.
Identify the major or intermediate deliverables (e.g. Design document)
Decompose major deliverables to smaller discrete elements of work.
Each decomposed element needs to roll up to the parent and make up 100 per cent of the work for the parent.
Each decomposed element is an actual deliverable or set of deliverables.
Review and refine until completed.
Bottom-Up Approach
Another approach is to generate the WBS from the work packages or user stories and work backwards to the high-level deliverables. This may be a good approach if the project is not complex and small. As the project manager, you need to make sure that all the deliverables and output are identified, grouped logically and don’t lose focus on the big picture.
Identify all the deliverables.
Group the deliverables in a logical manner.
Roll up the deliverables to the next higher level. Make sure the parent totals the child's deliverables.
Review and make sure all the work is covered.
Repeat to make sure all child elements are rolled up to a single parent that represents the project.
Review and refine until completed.
Mindmaps
Mindmap is an excellent tool for helping to decompose the project into the child elements. If you don’t know how to use mindmaps, check out the link here. Your organisation should have tools available to help create mind maps. If it doesn’t, I use an open-source tool called draw.io.
You can use mindmaps during brainstorming workshops with project team members and SMEs to break down the work.
Story Maps
In Agile projects, there may not be a formal work breakdown structure and some purists may be resistant to the idea. A similar technique is used in the Agile product development space called story mapping.
This is a great way to break down the work for the teams and provides a visual for the team on what is being delivered now and what is coming in the future.
Improve your delivery
Work breakdown structures are an underutilised tool within project management. Even though teams may use it informally and inadvertently create one as they work through the project, taking a more formal approach to creating a work breakdown structure will help projects and stakeholders visualise and articulate what they are delivering.
There is no need to make it as formal as the PMI promotes in their methodology. For agile projects, story mapping is a good approach to breaking down the product for the teams.
Resources
Resources used for this newsletter
PMI Practice Standard for Work Breakdown Structure. It’s pricey to buy on it’s own. If you’re a member of the PMI, you can get a copy for your own use.
Mindmap - an excellent technique that can be used for all parts of your life.
Story Mapping - for more information on Story Mapping. here is a link to Jeff Patton’s website. Jeff wrote a book on Story Mapping.
WBS Cheatsheet - you can use this to help create a WBS in your next project
Quote
“It is not the strongest of the species that survive, not the most intelligent, but the one most responsive to change.” – Charles Darwin
A few questions for you to think about and journal base on the quote above.
In what aspects of your profession/ craft/ career are you adaptive to change?
In what aspects are you resistant to change? Why?
What is one thing you can do to be more adaptive?
Drop me a message with your thoughts on this
Practice
Start building a work breakdown structure or story map for your project that you want to get started. If your project is in progress, choose a personal project in which you can practice this technique.