Menu Close

Breakdownstructure Blog

Collaborate on WBS or PBS online

Multidimensional WBS structures

We are part of the ISO standardization of WBS, and have just returned from an ISO meeting in Paris, where the upcoming WBS standard ISO 21 511 is scheduled to launch during the second part of 2018. An recent, but important change, to the standard, is the support for non-hierarchical aspects of the WBS. Some type of work in a project may be ”overhead”, applying to other parts of the structure itself. Project management is a typical example of this, and is therefore often placed as a top node of a WBS, being a ”service” to the rest of the project. Using this principle, it is possible to break out a lot of the recurring work from other parts of the tree, reducing this second dimension to a part of the tree itself.

Another possibility of getting another dimension on the WBS is to integrate the WBS with another structure, such as an OBS (organizational breakdown structure). This mapping then describes which resources that are responsible for each part of the tree. It is also possible to integrate with other data or structures, such as risks, location, specialization or issues. These mappings provide valuable additional information and views on the project that better describes areas of concern, progress or just being able to focus on a specific aspect of the project.

In, it is possible to use tags to get a second dimension through the use of tags. You could set up tags for group responsibility (team1, team2), risks (high-risk, low-risk), urgency (urgent, next-action), issues (defect, bug, change-request), location (building1, south-area) and many more. Tags can then be used to filter on the appropriate card, and are retained when exporting to other tools.

We are also working on refining different perspectives on the project, and soon we will launch a feature, where an individual can view all cards that he is responsible for in all projects. There are many things that can be done in this area, and we will ensure that we implement as powerful features as possible while still ensuring that the tool is easy to use, which have always been our first priority.

Why Does Your Small Business Need an Online Team Collaboration Tool?

Teamwork acts like a tether for the growth of a business, irrespective of whether it is a startup, a mid-scale business or a multi-million dollar enterprise. Hence, the claim that teamwork can make or break a business stands true.

We would specifically like to talk about the small business or startup scenario today. We all know how small businesses in the US are multiplying like rabbits. This has given rise to cutthroat competition. With that being said, the need of getting more done to beat the competitors has become quintessential for every startup. If you are working with a small business or are running one, you know how difficult it is to make this machine function properly. You’ll have to look into every small part, starting with the recruitment to training and onboarding. The list is a huge one!

Amidst all the team building, collaboration and management often take a backseat. It is ironical that the part, which demands undivided attention is often neglected. The bottom line here is that if your team does not collaborate well, your business is likely to a hit a downward spiral sooner or later.

How do you overcome the team management issues? Should you hire a top-level manager and leave it on his shoulders? If such questions have been haunting you, this is where all your suffering ends.

The answer to your questions is Online Team Collaboration Tool.


Now, you may be thinking about how effective can a tool be. So, without much ado, let us list down the 4 benefits that such tools come with.

  1. Easy and Efficient Project Tracking: These days most of the collaboration tools come with distinctive project tracking features. They make it easy for the team to see how the project evolved over the course of time. Team members can instantly see the changes that are made to the files. Also, assigning tasks become easier as the need of constant emailing is often completely eliminated.
  2. Seamless Communication: Online team collaboration tools encourage smooth communication between the members. If you want your freelance employees to communicate regularly with the ones at the office, team collaboration software is what you need. Also, any team member is away from the office, these tools can help participate in the project even when they are some physically present in one place with the rest of the team. Overall, it removes scope for communication gap and encourages team members to be productive while working remotely.
  3. Saves Money and Time: Small businesses make money by making the most of their time. Online team collaboration and other project organization tools encourage the teams to manage their time effectively. This reduces loss of time trying to understand the project. Right utilization of time in this case is directly proportional to the financial gains that a company receives.
  4. Reports Can be Compiled Quickly: Creating project reports is often seen as tedious task. But with the online collaboration tools, this predicament can be won over. They help in creating detailed reports that contain all activities related to the project from the very beginning.

The crux comes out to be that collaboration tools make teamwork more productive, efficient and rewarding. With a motivated and managed team holding the pillars of its foundation, a small business can deliver better services to its clients. Thus, investing in a software that keeps you team on track and your clients happy is something you must do as a small business owner.

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


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, 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!

What is a WBS?

The definition

A WBS is abbreviation for Work Breakdown Structure, and is a hierarchical division of the project into smaller pieces of “work”. The problem with “work” is that it is ambiguous, in that it could both represent an activity or the result of activity (see

Most definitions state that a WBS is “product-oriented” (e.g. NASA, MIL-STD-881C, DEF(AUST)5664), although there are also other definitions out there, such as “deliverable-oriented” (e.g. PMI Practice Standard for WBS, Wikipedia). This means that “work” in the WBS should be thought of more as the result of activities, rather than the activities themselves.


Generic view of a WBS in an outline view format (created by

Why the focus on products/deliverables?

The focus on products or deliverables ensures that the WBS focuses on WHAT to do rather than HOW to do it. This gives room for those responsible for the deliverable to choose the best way of delivery, for example buying an off-the shelf solution instead of developing it in-house.

A deliverable-oriented WBS also makes it easier to define quality requirements for each specific sub-deliverable. Deliverables also provides more meaningful control of the progress of a project, as completing activities does not necessarily result in the completion of the final deliverables, and in the end it is only the completion of deliverables that is desired.

Some drawbacks of products/deliverables

Not all projects results in a physical product, such as organisational change projects. It is hard to argue that an improved effectiveness of an organisation is a product or deliverable. Therefore it can be useful to think about a WBS as a breakdown of the results of all activities.

Another drawback of the deliverable focus is that it can be hard to estimate the total costs of a project solely on the WBS, without describing all activities required to produce those deliverables. Having the activities in a separate document increases the complexity of managing the project.