The Benefit Breakdown Structure (BBS) Notation
Estimated reading time: 4 minutes.
Why use the BBS Notation?
Benefit Breakdown Structure diagrams are useful to plan and execute projects. A BBS diagram follows the Start with the end in mind idea: We should start by analysing the intended benefits and then simply plan backwards:
- What is the strategic intent or investment objective? Why are we looking at planning a project? This should be a linkage to the overall company strategy. I am particularly fond of the idea of calling a project an investment.
- What are the associated benefits? By looking at the project proposal and matching the investment objective, what benefits can we aim at?
- Which (business) processes will need to change for realising each benefit? Please note that a benefit is not created during the project. Instead a changed process will create the benefits each time it is executed. So, which process is creating the benefit? It doesn't have to be a formal process, it doesn't even need to be executed twice. But both are often enough the case.
- What one-off changes are enabling the changed processes? This is ultimately the task of the project.
Often enough we plan a project the other way around: one starts with an idea of a new technology/system/product idea and then tries to find the benefits for that. I believe that here is one of the root causes of many failed projects. Someone fell in love with an idea, not with a benefit.
An example of a BBS diagram that explains some of the key concepts.
The diagram above is created with this Notation. It shows how the structure of a (rather small) project could look like. The clusters are used to explain how the diagram translates into a project environment.
A better understanding of the underlying ideas of benefit realisation through a BBS can be found on the author's website](https://kneupner.de/thoughts/benefit-realisation).
The Notation contains a Node Type for each of the questions raised earlier.
The Benefit Breakdown Structure Notation
There are a few notes to make:
- You will never define the whole structure from the objective to the enablers. It is absolutely fine to include as well planning in the other direction. You even need to identify dis-benefits which normally always happen.
- I was considering providing many similar nodes, like "IT Enablers", "HR Enablers", "Financial Benefit", etc. but didn't do so. Simply create a Node Type duplicate and adapt it to your needs.
- If you follow the planning as suggested will you realise that the shape of the diagram should be a triangle, as there will be more and more entries the further you are away from the investment objectives. If this is not the case for your diagram then you might overlook something.
- This approach is easily aligned with Agile approaches. You can create a rough Business Case for each benefit and then compare each in-project business case. Focus on the best benefit and change the process. Once you are done you can re-evaluate the BBS and select the next benefit. Looking from this angle, a benefit becomes a feature.
- Keep the BBS updated throughout the project. It will guide you. E.g. when you learn that a benefit is smaller than expected and you consider the benefit as no longer worth enabling then the BBS will allow you easily to de-scope those enablers that were in the plan only for this benefit.
|Is Starting Node Type?
|Investment Objectives are the goal of the initiative. They should be linked into the organisation's strategy.
|A benefit is an advantage on behalf of a stakeholder. What are the benefits associated with the investment objective? What benefits can we achieve that support the investment objective?
|Business Changes are changed processes that create the expected benefit by execution. Please note that a benefit is not created during the project. Instead, a changed process will create the benefits each time it is executed. Which process(es) is (are) creating the benefit? It doesn't have to be a formal process, it doesn't even need to be executed twice.
|Enabler are what a project is delivering. Enablers are one-off changes that enable the business processes to be executed in a better way. They are therefore prerequisites to the Business Changes
BBS uses Necessary Condition Logic.