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 with analysing the intended benefits and then simply plan backwards:
What is the strategic intend or investment objective? Why are we looking at planing a project? This should be a linkage to the overall company strategy. I am particular 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 is 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 try to find the benefits for that. I believe that here is one of the root causes for many failed projects. Someone fell in love with an idea, not with a benefit.
A better understanding of the underlying ideas of benefit realisation through a BBS can be found at the author’s web site:
The Domain contains a Node Type for each of the questions raised earlier.
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 in order to identifier dis-benefits which normally always happen.
I was considering to provide many similar nodes, like “IT Enablers”, “HR Enablers”, “Financial Benefit”, etc. but didn’t do so. Simply create a Node Type duplicate and adopt 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 actually 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.
Investment Objectives are the goal of the initiative. They should be linked into the organisation’s strategy.
Yes / –
A benefit is an advantage on behalf of a stakeholder. What are the benefits associated with the investment objective? What benefits can we achive that support the investment objective?
No / 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.
No / Benefit
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