As described previously, the first step in the Benefits Management Process is to identify the benefits we want to achieve. Benefits don’t exist in isolation, and so we start this process by determining the objectives.
You can think of objectives as the desired end state. It’s likely the organisation’s objectives will have already been set by the executive board, but if not you will need to create them from first principles. It is important to define objectives, as without them you have no reason for wanting to achieve any benefits.
As an example, an objective might be to “Deliver best in class customer experience”. Objectives can be recorded in a table as shown below.
It is a good idea not to have too many objectives. Typically 5 objectives will be enough. The objectives are useful to share at communication events, so that everyone, not just senior management, understands what the program is trying to achieve. The reason I recommend not having too many objectives is that having fewer makes it easier to prioritise during program execution. Additionally, too many objectives results in conflicts between the different objectives and makes it very difficult to get things done.
Now that we’ve determined our objectives (end state), we’re ready to define our benefits. We define the objectives or end-states first as these provide the platform from which we can define our benefits. In effect, benefits are the positive things that will be enjoyed by the organisation as a result of having reached our desired objectives (end states).
We’ve already discussed in the first part of this series “exactly what a benefit is“. One thing to point out is that a lot of people often confuse benefits and project/program milestones. For example, “the new factory is open” is simply a milestone, but not a benefit. So what if the new factory is open, it’s the benefits the organisation will achieve because the new factory is open that we’re really interested in. It is best to create benefits which are objective rather than subjective, so its easier to measure if the benefit has been realised. From the previous example, a benefit related to creating the “best in class customer experience” might be that we “increase customer retention by 5%”. Again, we should record benefits in a table.
Now that we’ve created our list of benefits, it’s often a good idea to perform some analysis on them (benefit profiling), which can help us when we come to create the program plan and associated benefit reasisation plan. Just as we might classify risks according to impact and probability, we can do exactly the same with benefits:
In this case the probability refers to how easy the benefit is to achieve, a high probability meaning the benefit is thought to be easy to achieve and a low probability indicating the benefit is difficult to achieve. Impact indicates the size of the benefit to the organisation. A large impact brings a big benefit to the organisation, while a small impact brings a smaller benefit to the organisation.
Those benefits positioned in the top-right of the diagram are ones which are easily achievable but critical to the service. These are our flagship benefits. Benefits with a high impact but a low probability are high risk but important to the program, and we will need to devote a lot of attention and effort to ensuring these benefits are delivered.
When performing this exercise of profiling benefits for real, it is at this point good practice to re-evaluate all benefits with a low impact, particularly if they have a low probability to see if they are worth doing at all. It is often far better to remove these benefits from the program at this stage so as the key benefits can be concentrated on without any noise coming from far less important items. This is especially true from low probability benefits as they are difficult to achieve and their failure could cause the entire project to fail.
