How does a good WBS look like?

There are many decisions you can make when creating a WBS, but there is very little practical guidance on how to do it out there. To understand how a good breakdown of a project should look like, the different types of parent-child relationships must be understood. This blog post will try to go through various options I have come up with during my years of working with breakdown structures.

There are several options to create children to a parent, depending on the type of WBS and the type of project. Here are some examples of parent-child relationships:

• Parent consists-of children
• Children belong to the category described by the parent
• Children are part of the same state as described by parent
• Children are products needed to complete parent
• Children are services needed to complete parent
• Children are objectives needed to complete parent

Below are details and examples for each of these.

Parent consists-of children

This may be physical or conceptual. A car, for example, consists physically of wheels and engine (and many other parts), whereas a software conceptually consists of features or components. A WBS that only consists of these types of children is called a PBS (a Product Breakdown Structure). It is common for a WBS to have a PBS as a child, while also adding services, such as project management, required to deliver the PBS as other children. When a WBS is broken down this way, it is important that no children of a parent is omitted, as that would make the parent incomplete. Therefore the 100% rule must be followed (more on that will be written in a separate blog post).

Example WBS using only this relationship, focusing on pages:

• Web site
  • Front page
  • About page
  • Community pages
    • Sign up page
    • Login page
    • Community page
  • Blog

Another WBS for a web site focusing on features:

• Web site
  • Epic: Search for products
  • Epic: Browse for products
  • Epic: Buy product
    • User story: put product in shopping basket
    • User story: check out shopping basket
    • User story: pay for product
  • Epic: Track purchase

A simple product based WBS for a building could look like this:

• Building
  • Ground floor level
  • First floor
  • Frame
  • External
    • Walls
    • Windows
    • Roof
  • Internal
  • Installations
    • Ventilation
    • Heating/sanitation
    • Electricity
    • Fire protection

Children belong to the category described by the parent

Categories may be time based, such as a stage, relationship based, location based or priorities. The parent in this case is usually used to group child elements based on certain characteristics of the proejct, that makes it easier to manage. It can be useful to have a list of stages (or phases), for example, showing the deliverables planned for each stage. This type of parent node is often used right below the top node of the project, and then all nodes on the same level should be of the same category. Another type of categorization could be grouping by priority, for example using the MoSCoW technique, where each ”Must-have” are grouped together.

Example reusing the above WBS but using categories as stages:

• Web site
  • Stage 1
    • Front page
    • About page
  • Stage 2
    • Community pages
      • Sign up page
      • Login page
      • Community page
    • Blog 

Children are part of the same state as described by parent

This is a variation of the category described above, where the category is a state. This may be interim versions of the product, such as drafts, preliminary or final versions. This is especially useful for products that can be iterated, for example documents, drawings, contracts, reports or software.

Example WBS using states for procuring a web could look like this:

• Web site
  • Requirements
    • Collected requirements
    • Agreed scope
    • Procurement SOW
  • Design
    • Draft design
    • Final design
  • Prototype
    • First prototype
    • Second prototype
    • Final prototype
  • Contract
    • Draft contract
    • Final contract
    • Signed contract
  • Deliverables
    • Alpha version
    • Beta version
    • Final version 

Children are products needed to complete parent

To use screws, you may need a screwdriver, even though the screwdriver itself is not part of your final deliverable. In the same way, products required to for example manage, develop or test could be listed. Contracts or agreements are examples of these types of products, but may also include management documents in the project, such as a project management plan, requirements documentation or the company’s quality standards.

Example WBS using categories for stages on the first level could look like this:

• Web site
  • Development
    • Hardware
      • Integration test environment
      • Performance test environment
      • Production environment
    • Software
      • Runtime environment
      • IDE, Integrated development environment
      • Control and Version Software
  • Build environment and software
  • Deploy environment and software
  • Bug and issue tracking environment and software

Children are services or processes needed to complete parent

This type is often related to the previous type, as products needed may need additional services, or may sometimes even be replaced by services. One of the most common type of service that is required in a project is “project management”, describing a type of overhead that needs to be allocated for in terms of budget and resources, while ensuring that all other parts of the project will be delivered. Other types of services could be systems engineering, test and evaluation, handover or training.

Example WBS with three services and a PBS:

• Web site
  • Project management
  • Quality assurance
  • UX
  • Pages
    • Front page
    • About page
    • Community pages
      • Sign up page
      • Login page
      • Community page
    • Blog

Children are objectives needed to complete parent

In addition to the products or services needed to complete a parent, often it is desired to describe the objectives of the products in its final environment. This often means a change of behaviours of users, customers and other stakeholders. This includes information campaigns, education, manuals, marketing, sales, post-sales processes, roles and responsibilities and other types of governance to maximize the benefits of the project. Some may argue that this type should only be part of a program rather than a project, (as it focuses on benefits). However, even projects need to deliver all the things that is required for the final results to be useable.

Example WBS that adds governance and changed behaviours to the PBS:

• Time reporting tool
  • Features
    • Epic: Report time
    • Epic: Track purchase
    • Epic: Administrate users
  • Governance
    • Processes
      • End user support
      • Bug and feature reporting
    • Roles and responsibilities
      • Administrators
      • Users
      • Support
  • Changed behaviours
    • Educated users
    • Educated support staff

Conclusions

All the types outlined above can be combined in various forms to produce more complex, more detailed and more useful WBSs. You can also have multiple WBSs, that are being used for different purposes in the project, for example budgeting, control or communication with stakeholders.

With modern tools (like breakdownstructure.com), you can also use tags to get additional perspectives on the breakdown structure. Through practice and experience, you will improve the way you break down your projects, and thus manage them!