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 three)

Read part one   part two Read part three  Read part four

In this part I will be talking about  the importance of the financial analysis and the practicalities of putting the figures together.
After all the bottom line in any busines case is going to be financial although individual stakeholder priorities and concerns will play important parts as will the organisation’s history with similar projects and even good old office politics will often play a part.

At this point I would caution that despite the importance of the figures, it would be foolish to present a business case without taking into account the stated aims of the business in it’s short and long term plans and the key performance indicators and critical success factors of the key stakeholders.

If you are able to tie your benefits very clearly and distinctly to the corporate goals and to the personal KPIs of your individual stakeholders, then you stand a much greater chance of getting their attention and you may even be able to enlist their help in fleshing out your arguments.
You will also have an aopportunity to spot delicate or contentious areas that are best played down or avoided.

The approach to financials

Financial decision based on Cost v benefit v risk

When approaching financial analysis for a business case, three subjects immediately emerge as important topics:

  1. Cost benefit analysis
  2. Quanitfying and presenting intangible benefits.
  3. Risk/reward analysis

The reasoning behind our approach is simple.
Ultimatey, your business case is about costs versus benefits so a good estimate of costs is critical alongside of a realistic estimate of benefits.

The majority of projects bring benefit that are not easy to measure in reduced costs or increased profits, but are nevertheless important and valuable.

Given that some benefits are easier to hook and land than others, it makes perfectly good sense to have an indicator of how likely you are to succeed in delivering the benefits and to stay within cost estimates.
This way you are able to cherry pick the projects that suit your organisation’s current appetite for risk and you have an option to delve further into risk management if the potential reward is particularly attractive.

 Positioning the business case
It  is important to position your business case and calculations correctly from the outset and to put in the appropriate level of analysis and checks in collating the figures.
This activity will begin as an outline business case offering your best estimates based on hard data where available and tacit input form key stakeholders to fill the gaps and make adjustments where appropriate. This type of estimation is often described as stake in the ground estimation. It’s purpose is to decide whether a initiative is worthy of pursuing further.

Later after you have received appoval to proceed, you will continue to refine all the estimates until you arrive at a baseline part of the way through the project.

Doing the mathematics

Rule number one;  Unless you are trained in financial analysis, put somebody else in charge of this part of the work and act as the collector of data. If you can’t delegeate it then you are still going to need close cooperation from the finance department to get access to key numbers and you will need them to scrutinise your figures before you show them to anybody else. 

The financial benefits can generally be described as either of Cost avoidance, or Increased revenue. These events have very similar effects on Return On Investment (ROI).
A key measure for most organisations will be ROI and a simple viewpoint can be that the project represents an investment of capital in the hope of achieveing better returns than it could achieve elsewhere.
One of the options for investment of retained capital would be the equities market though the key indicater here is the organisation’s Cost of Capital.  This figure is unique to every organisation so you need to find it out.


First you need to do some good old stake in the ground estimating of costs. Use as many reliable and respected opinions as possible to get ballpark figures at the start and refine this with as much verifiable data as you can get hold of. You can also try some online tools like Gartner TCO analyst, WIPRO TCA tool, or a number of services available online.

Look through old project budgets if you can and learn from experience to make sure that you don’t leave important costs out. Nothing can erode your credibility quite llike having a glaring ommission pointed out to you in front of the board.

 If you are estimating costs for a new  CRM system for example,  you can begin with internet research and you will find detailed case studies and benchmark costs there, which give a very useful starting guide once you factor in comparisons of scale and other knowns.

Next you can look at the organisation’s history of deliveirng similar projcts. This is a critical sanity check, because not all organisations have the same capabilities and you need to estimate realistically. Look at similarly sized projects and similarly complex projects and look for overall time, scope creep, cost escalations and the obvious areas of weakness.

Factoring this information into your initial estimates will give you a very sound footing for moving forward to attempting an actual breakdown of costs:
Typical project deliverables are a useful way of making sure you cover ebverything; Project planning, management, requirements analysis, licensing, etc until you have a comprehensive list.
You wil then need to seperate the ongoing costs form the capital costs. E.G. Support, annual licenses etc.

In the case of an IT investment I would generally expect to have three columns in my spreadsheet to cover three years going forward.
Now total up all of your costs for each year and make sure to account for indirect costs with a best estimate.
The last step in calculating costs is to apply a confidence level to each calculation based on the maximum you expect it to slip. E.G. you predict that testing will cost £100,000 and you expect that the most it could slip by is  8%. Your confidence level  8% the max figure is 108,000

Tangible benefits

Once you have finished calculating the costs, you can begin to calculate the tangible benefits.
In most cases this is a fairly simple set of calculations such as 20% reduction in returned goods.
cost of a single return = n total saving per annum = n * 20% *average returns level.

Always remember to do simple cause and effect analysis to determine what extra benefits might accrue that could be included and to be aware of any adverse effects that might result. The approach should be the same as with costs, the more collaboration you do, the more beleivable your results wil be and the more buy-in you will get.

Intangible benefits

Bit by bit organisations are coming to accept that intangible benefits are important and should be measured and accounted for. The difficulty is that measurement is as yet not a science and the responsibility of signing off large budgets without masurable benefits is too great for many senior executives.

The reality however, is that intellectual capital, the real classification of these intangibles is a major part of the calpital of every organisation and becomes especially noticeable when valuing a business for sale or valuing an equity. The business with an innovative loyal staff, an attractive location and great reputation is infinitely more valauable as an assett than an identical organisation without these attributes.

Physical and intellectual capital in an organisation

Above is a view that illustrates in a very simple way the part played in an organisation’s value by intellectual capital. The type that might be dismissed as intangible unless you make the attempt to represent it correctly.

One area where some progress has been made is the company Brand.
E.G. A favourite areas of disagreement used to be the expenditue on building and maintaining a brand.  CFOs were reluctant to sanction spendng on what they often saw as “pink and fluffy stuff ” that delivered nothing at the bottom line.
Recently Coca Cola had their brand revalued to $67.5 billion dollars and you can bet your last dollar that it appears on the balance sheet.
Today it is easier to get  formula for calcualting the value of the brand than it is to get a sensible definition of what a brand is, so don’t be put off by apparently intangible benefits. Tackle them and tame them.

There are three approaches that we tend to use most:

  1. Take the same aproach as brand valuation, I.E. how much more would the business be worth with a better reputation in the recruitment market and first call on the brightest talent.
    This type of calculation can be easier to do than seems apparent at first. If you can get hold of competitive analysis reports it will be easier still because the strengths and weaknesses of immediate competitors wioll be listed there and you can aim right at the bulls eye.
    Once you have made an estimate add a sensible confidence level to it and run wih it.
    Once again, remember to be collaborative and to bear in mind the language and culture of the orgnisation.
  2. Identify a KPI that will be significantly afffected by the benefit and discuss it with the owner of that KPI.  Perhaps the HR director is tasked to reduce staff churn and has a KPI measuring this.  Ask her to help you work out the value to the business of imporving that KPI by 1 point.
    Armed with this estimate, predict how mny points you expect to improve it by and then calculate the financial benefit. Again apply a sensible confidence metric.
  3.  Track benefits via impact analysis, represent this on simple fishbone charts and then quantify the bottom line beenefits that can be identified.  E.G.  Improved reputation as an employer -> reduction in churn -> reduced costs of recruitment (£) + More skillful staff -> win bigger projects from competitors ->(£)

Now that you have done the figures it is a simple matter of presenting them in a table so that they can be easily evaluated.

In my example you will notice that I have included my confidence levels on a seperate row so that the reader can take whichever view point he/she wishes.

The only  calculation we use in a standard business case is the NPV. This represents the Net Present Value of a sum of money, I.E the value of that money in todays currency after factoring in Cost Of Capital.
E.G. It is infintely better to have a poundt in your hand today than to receive it in three years, because it will purchase less in three years.  In the NPV calculation we use the same thinking except that rather than inflation we use a Discount Rate that is based on cost of capital, because to better represents the investment options for that capital.

It is key to get the cashflows right i.e. to work out a benefits schedule, because you need to know when cash is coming in and going out if you are to calculate NPV.
Once you have this in place you can use the NPV function in Excel to calculate the NPV for you.

The Payback period is a straightforwar and obvious calculation and the Internal Rate of Return (IRR) is just an interest rate representing the return on the investment of capital.


Year 1

Year 2

Year 3

Delivery costs




Delivery incl. risk (n%)




Ongoing costs




Ongoing incl.  risk (n%








Benefits less risk (n%)




Net Cash flow








Options risk




Net options




Discount rate








Payback (months)








 Risk analysis

As you will have noticed we built the risk analysis into the individual calculations as opposed to applying it to the whole calculation at once.
If this is a sensitive area, then it is a simple matter to calcualte these elements as an overall cost risk and overall benefits risk and look at best and worst case scenarios.

 At this point we have a fit for purpose finacial proposal and now we need to set about optimising the presentation.




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