Delivering benefits is no longer about getting a system signed off

(Who’s minding the shop?)
This blog is an attempt to stimulate discussion and understanding of the balance of responsibility for delivering business benefits from IT investment.
It is now fairly widely recognised that this is not as simple as choosing a system, getting it working and reaping the benefits, but as yet we can call on very few examples of good practice in making it work.
The business argument.
We have no time for discussions about how it all works, we just want a business case and if it gives us the ROI we need with acceptable risks, we want to do it. At least that’s the CFO’s line. In reality, many of these projects begin life as pet projects of the CEO, or other senior manager and it is clear from the outset that the question is not will it work, but make it work.
This is largely an understandable attitude, because businesses must be directed and managers must manage and sometimes the outcome can be a life or death one.
The IT supplier argument.
Be the supplier an in house department or an external supplier, the situation is not hugely different. The supplier tends to confine their responsibilities and activities to making the technology work. Better suppliers provide advice and guidance on rollout, but that is the limit of the activity and there is no responsibility beyond meeting technical requirements. This is wholly understandable, because the supplier has no control over whether the business case was correctly put together, whether the requirements were detailed enough or whether the culture is sufficiently flexible or disciplined to make the new system work and deliver benefits.
So who‘s minding the shop?
Well the answer very often is that nobody is minding the shop. Rarely is anybody in the business equipped to do this job and the suppliers are not getting involved.
The most usual scenario is that the system is delivered and there are issues and misfits that become immediately apparent, then there’s a return to the drawing board and changes are made and a re-launch and things are much better. Often you’ll find a new project with a new name the following year, billed as an upgrade and it finally knocks the thing into shape. Two years late and dramatically over budget the project is complete and nobody ever asks whether it delivered benefits because at this point the busines is bus with a whole new set of issues.
The other common scenario is that a consultant is hired to manage the project, he/she is expected to have a project management qualification PMI/Prince etc and have handled one of these type of projects before, maybe even in this industry.
Often the contract is already in place, the product defined and dates and budgets set.
Where does a Consultant go from here?
1. Recommend someone else who needs a bit of experience.
2. Take it on and hope for the best
3. Challenge the client at interview and get passed over as wrong attitude
4. Take it on and then challenge the client later via a robust consulting methodology
5. Challenge the client at interview via a robust consulting methodology
6. Offer to challenge the project’s soundness for a reasonable fee and provide a dispassionate report.

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

 Read part one  Read part two Read part three  Read part four

In our previous instalments we discussed the preparation of a business case and calculation of the data needed to prove it.

Today we will be discussing the art of delivering the business case in such a way that it competes on a level playing field with all other initiatives currently on the agenda.

There a re a few fundamental rules to bear in mind when presenting any proposition:

1.       Recognise and understand your audience so that you can directly target a known need or desire with your proposition.

2.       Use the appropriate language and context to present your proposition.

3.       Get your timing right.

4.       Demonstrate understanding of and sensitivity to the operating environment.

 The first paragraph should always be entitled ‘Executive Summary’, but it should be the last one written.

The next paragraph should be a backgrounder that demonstrates succinctly and understanding of the operating environment, I.E. political, environmental, social, technological.  Make sure you don’t fall into the trap of contradicting the CEO. Work form the five year plan or current year plan or what ever is the most relevant document and if there have been significant changes in the operating environment since it was written then discuss it with senior people so that you reflect it accurately and delicately.
You may find for example that the CEO published a plan for robust growth ina bullish market three years ago and the CFO is now investing inwardly in cost avoidance projects while they watch the news with interest for an indication of the way forward.

In this case you need to be able to reflect this in your businss case so that it sets the scene for your cost reduction proposal.
 When it comes to writing down your propositions, bear in mind that there will be two distinct audiences, those who want to scrutinise the details and those who want the bottom line only.
The latter type will very often be relying on the former to take care for the detail for them so it is very important that you address each in the appropriate manner, presentation and language.
In part two we drew a map that linked features to benefits. In this section we will expand this idea further and we will map those benefits to stakeholder driven propositions.

Here is a simple example from my own experience.

Strategy and KPI mapping

 Strategy and KPI mapping

 In the diagram above we can clearly see that the CEO has published a key goal for the current period which is to improve net profit margins by 1 %.
 The CFO has a related KPI called indirect costs/sales volume and he is hell bent on improving this KPI by 1 point in order to meet the CEOs  goal.
The Operations Director is working on a goal to reduce the paperwork element  involved in picking, packing and shipping products, while maintaining or improving delivery success rates

In your business case the value propositions would address each of these stakeholders in his/her own terms and use context to draw an accurate picture of the scale of benefits.
E.G.
The proposed system will positively increase net profit margins by a factor between .2 and .4% in it’s first year of operation and reach breakeven in the first quarter of year 2.

In achieving this, it will increase the costs/sales volume KPI by a factor of around .3 through virtually eliminating the paperwork involved in the picking, packing and shipping aspect of operations.
Additional benefits will be reduced propensity for error in this area that we have not attempted to quantify.
For detailed breakdown, see the financial analysis section.
You will note that this sentence describes the system in terms of benefits that can be readily understood and appreciated by each individual stakeholder.
By quoting KPIs the scale of the benefit is immediately put into context so that you capture the attention of your target readers.

Presenting the figures.
You don’t need to be a financial analyst to figure out that bringing in benefits early has a dramatic affect on the financial results of your project.  If you cast your mind back to part three when we talked about Net Present Value (NPV), you will realise that bringing in, or saving  a million next year rather than the following year, supposing a discount rate of 10% will deliver an extra 100,000 in benefits.  Not only that but it reduces the total investment required, thus improving ROI and freeing up capital for other important projects.

This simple exercise will help you optimise your business case by bringing forward benefits where it can be done.  You may remember that in part one we talked about listing the features and benefits that make up your projects and creating metrics for each feature.
Here is a simple tool we use to prioritise these features.

Tool helps with prioritising features

 If you need to analyse more complex and more data rich cases, then a Pareto chart can be an excellent way to single out the low hanging fruit.
For non financially aware people you may be able to put the benefits in context by taking the ROI and calculating how much extra revenue it would take in order for the business to deliver that same return through extra revenue generation.
In order to make this case rock solid you need to also present at least one potential alternative tactical solution and a do nothing scenario.
In your final analysis, you will compare the do nothing scenario, the tactical solution and the proposed solution and demonstrate clearly the basis for your proposal. 

Project plan
An indicative project plan should be included in order to demonstrate the likely timelines including benefits realisation activities, implications for personnel, budget and  team structure.

The executive summary.
In this section we always place two things:
1.       Our proposal, stated in direct no nonsense language aimed at all relevant stakeholders jsut as we discussed earlier.

2.       Our paragraph of analysis that briefly describes the alternatives and the rationale behind our proposal.

The executive summary should contain nothing but the bare facts and concise value propositions, no rambling intros or winding up paragraphs. It is a business document and it is about cold hard cash so keep it clean and factual and get straight to the point.

Sign off sheet
Don’t forget a sign-off sheet so that they are very clear of the immediacy and urgency and the fact they will be expected to make decisions as opposed to having a discussion.
Presentation

n order to present the business case, our strong recommendation is that you produce three artefacts.

1.       The full business case

2.       A one page summary including the executive summary  and financial conclusions

3.       A presentation of four or five slides demonstrating pictorially, the background, the benefits, the financial analysis, the project outline.

The first  communication should be the short summary sent by email to the stakeholder list along with an invite to discuss it in a formal setting.
The second communication should be a presentation of the business case with opportunities for questions and answers and the full business case handed out about half way through the presentation once the key points have been presented.

  Read part one  Read part two Read part three  Read part four

 

Reblog this post [with Zemanta]

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.

Benefits map diagram expains the bridger method of mapping requirements to benefits

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 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.

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