When is a business case not a business case (part two)

Read part one   part two Read part three  Read part four

In this section I will be talking about benefits, why they are so important to the business case and how they can be tracked right through the project, thus making the business case a key document in successful project delivery, rather than just a tool to get the budget released.

The model above illustrates our basic theory of benefits delivery.
On the left side of the diagram, we represent high level requirements.
This is intended to illustrate the level of requirements that is generally outlined in the business case.

This requirement is then tied indirectly to the composite benefits illustrated on the far left of the diagram. These benefits are the ones providing the key arguments for action.
That part of the model is very simple and intuitive. We have high level requirements and we expect to deliver the identified benefits.  The # denotes that this metric is to be measured.

A key element of this approach is to remember at all times is that the requirement exists in the business case only to deliver the identified benefits and any change to the requirement or surrounding circumstance that impacts it’s ability to deliver these benefits is a red flag issue and must trigger a business case review.

The devil may be in the detail

 Between the high-level requirement and the composite benefit, naturally, lies a lot of very important detail.  While this detail is not represented in the business case, but in other documents such as requirements specifications and benefits realisation plans, the exploration and bottoming out of this detail, will be critically important to the final conclusions of the business case process.

We look at this benefits mapping activity in terms of feature level requirements I.E. identifiable succinct features of the product or deliverable and with this we associate two things:

1. The measurable benefit that is expected as a result of this feature, along with a suggestion of how it might be measured.
2. The risks management attached to realising this benefit.  We describe it as risk, because we want to confine the change management activities to those that are necessary in order to deliver the benefits.

By taking this approach, we are proactively testing the likelihood of our successfully delivering the benefit and we are planning the change activities required to ensure that they are delivered.

Benefits realisation example

E.G. In the CO2 example, we may have assumed a fuel saving of 1000 gallons per month resulting in a measurable reduction in CO2 emissions.
In order to actually realise these benefits, we might have to take steps to ensure that all the lean cars are not last to be taken from the car-pool, while the big luxury ones are first choice. The approaches can vary considerably, but they have to be planned and in many cases included in the costs of the project. The likelihood of this succeeding is a key part of the final assessment.

Without this risk assessment and change management activity, the likelihood is great that the potential impact of replacing luxury cars with lean ones will deliver little or no benefit to the environment or to the organisation, No ROI and a project failure.

Now if we look again at our diagram, it may become obvious that we will have quite a few of these feature level requirements and that each will have it’s own mini business case including the level of ROI and the level of risk attached to delivering benefits.

As the project takes shape and more is learned about each of these requirements, this mini business case needs to be constantly reviewed and updated so that poorer candidates can drop off the radar and stronger ones get promoted to a higher priority.

Approaching the business case in his way and continuously managing it as the development continues from outline business case to full business cases will keep the business in control and minimise the likelihood of pursuing projects that perform below expectations.

 Read part one   part two Read part three  Read part four