In the previous 4 parts of this series we walked through all the theory behind creating a Benefits Dependency Network. In this final part of the series we’ll walk through an example of a BDN to make the practice behind the theory more clear.
Remember that there are five sections we need to link together in our Benefits Dependency Network. These are:
- Objectives: our wanted end state.
- Benefits: the organizational benefit of the end-state.
- Outcomes: the real-world changes that we be the outcome of any projects undertaken.
- Projects: that need to be delivered to produce outcomes.
- Enablers: things we need to do up front to get things moving.
In our example we will be considering an internet based business which sells physical products. For the purposes of our example the business objectives are to:
- Increase sales from repeat customers. Currently repeat sales are below industry averages.
- Build global presence to increase the number of customers to over 10 million. This represents a huge increase from the current 2 million customers, and a significant challenge as the US market is already saturated with competitors.
Once we have our objectives defined we begin to work backwards, defining what benefits to the organization these objectives might result in. We then work backwards again defining what outcomes (or results) projects will need to deliver to reach our objectives. We then consider what things we have to do up front before we can start our project work.
Examining the “Increase sales from repeat customers” objective, we determine that a business benefit is that it will lead to a reduced user acquisition cost relative to total sales per user. This is good as the means the business’ margins will increase.
To deliver this benefit there are some things we need to do, including constantly monitor existing user behavior and engage with them through the best channel (email, sms etc) based on their behavior. We also need to make the system easier to purchase goods through, and align marketing with accurate customer segmentation.
To produce these outcomes (or states) we need two projects, one to improve the CRM system and another to improve the system the customer sees. Before we can improve the CRM system we decide it would be a good idea to take this opportunity to redefine our customer segmentation.
This may sound complex, but when all of this information is drawn as part of a Benefits Dependency Network it should become much clearer. The BDN for our example is shown below.
So far in this article we’ve discussed how to construct a Benefits Dependency Network, but haven’t really discussed the benefits of using a BDN.
The real benefit of a BDN comes when we have items within it that have multiple connections to or from them. Because by understanding how enablers, projects, and outcomes contribute relatively to benefits and objectivess, it allows us to structure/schedule the program so that important benefits or quick wins are achieved first. It also allows us to make tradeoffs between projects and outcomes, and helps us to derisk the program.
The BDN example above is very simple but let’s examine the “Increased conversion rate” benefit. We can see that this benefit helps the business achieve 10 million users. If we understood that it provides just a 10% contribution to that objective then we might be willing to deliver this later to de-risk the “improve front end” project which is needed for the other 90% contribution to this objective.
We would also want to consider how scheduling “slicker user purchase” might impact our other benefits before making this decision. Ultimately the BDN allows you to consider lots of different combinations to schedule the program, with your aim as program manager being to find the combination which delivers the most benefit to the organization, most quickly and with minimal risk.
The BDN can also then be useful as a tool to discuss your logic with the program steering group, allowing everyone to understand the relative contributions of different aspects of the program to the overall objectives, and hence understand the logic behind the program plan.
In the five parts which make up this series of articles on Benefits Management, we have walked step-by-step through all the stages you should complete in order to construct a comprehensive BDN, and concluded with an example. As mentioned in the very first article, because the raison d’être of all programs is to bring about business benefit, no program should be started without a Benefits Dependency Network having first being constructed. A Benefits Dependency Network will help you schedule your program to deliver benefits in the best way for your organization.