A few days ago I posted a blog entry about Microsoft infrastructure optimisation and I’ve since received confirmation of having been awarded ValueExpert certification as a result of the training I received on the Alinean toolset from Alinean’s CEO and recognised ROI expert Tom Pisello.
One of the things that I’ve always found challenging for IT infrastructure projects has been the ability to demonstrate a positive return on investment (ROI) – most notably when I was employed specifically to design and manage the implementation of a European infrastructure refresh for a major fashion design, marketing and retail organisation and then spent several months waiting for the go-ahead to actually do something as the CIO (based in the States) was unconvinced of the need to spend that sort of money in Europe. I have, on occasion, used a house-building analogy whereby a solid IT infrastructure can be compared to the plumbing, or the electrical system – no-one would consider building a house without these elements (at least not in the developed world) and similarly it is necessary to spend money on IT infrastructure from time to time. Sadly that analogy isn’t as convincing as I’d like, and for a long while the buzzword has been “total cost of ownership” (TCO). Unfortunately this has been misused (or oversold) by many vendors and those who control the finances are wary of TCO arguments. With even ROI sometimes regarded as a faulty measurement instrument, it’s interesting to look at some of the alternatives (although it should be noted that I’m not an economist).
Looking first at ROI:
ROI = (benefits – investments)/investments x 100%
Basically, ROI is looking to see that the project will return a greater financial benefit than is invested in order to carry it out. On the face of it, ROI clearly describes the return that can be expected from a project relative to the cost of investment. That’s all well and good but for IT projects the benefits may vary from year to year, may be intangible, or (more likely) will be realised by individual business units using the IT, rather than by the IT department itself – they may not even be attributed to the IT project. Furthermore, because all the benefits and costs are cumulative over the period of analysis, ROI fails to take into account the value of money (what would happen if the same amount was invested elsewhere) or reflect the size of the required investment.
To try and address the issue of the value of money, net present value (NPV) can be used – a figure used to determine what money spent today would be worth in future, given a defined interest rate. The NPV formula is a complex one as it takes into account the cost of money now, next year, the year after and so on for the entire period of analysis:
NPV = I0 + (I1/(1+r)) + (I2/(1+r)2) + … + (In/(1+r)n)
(where I is the net benefit for each year (cash flow) and r is the cost of capital – known as the discount rate).
The theory is that future benefits are worth less than they would be today (as the value of money will have fallen). Furthermore, the discount rate may be adjusted to reflect risk (risk-adjusted discount rate). NPV will give a true representation of savings over the period of analysis and will recognise (and penalise) projects with large up-front investments but it doesn’t highlight how long it will take to achieve a positive cash flow and is only concerned with the eventual savings, rather than the ratio of investment to savings.
That’s where risk-adjusted ROI comes in:
Risk-adjusted ROI = NPV (benefits – investments) / NPV (investments).
By adjusting the ROI to reflect the value of money, a much more realistic (if less impressive) figure is provided for the real return that a project can be expected to realise; however, just like ROI, it fails to highlight the size of the required investment. Risk-adjusted ROI does demonstrate that some thought has been put into the financial viability of a project and as a consequence it can aid with establishing credibility.
Internal rate of return (IRR) is the discount rate used in NPV calculations in order to drive the NPV formula to zero. If that sounds like financial gobbledegook to you (as it does me), then think of it as the value that an investment would need to generate in order to be equivalent to an alternative investment (e.g. keeping the money in the bank). Effectively, IRR is about opportunity cost and whilst it is not widely used, a CFO may use it as a means of comparing project returns although it neither indicates the level of up-front investment required nor the financial value of any return . Most critically (for me), it’s a fairly crude measure that fails to take into account strategic vision or any dependencies between projects (e.g. if the green light is given to a project that relies on the existence of some infrastructure with a less impressive IRR).
Finally, the payback period. This one’s simple – it’s a measure of the amount of time that is taken for the cumulative benefits in a project to outweigh the cumulative investments (i.e. to become cash flow positive) – and because it’s so simple, it’s often one of the first measures to be considered. Sadly it is flawed as it fails to recognise the situation where a project initially appears to be cash flow positive but then falls into the red due to later investments (such as an equipment refresh). It also focuses on fast payback rather than strategic investments.
As can be seen, none of these measures are perfect but each organisation will have it’s preferred method of measuring the success (or failure) of an IT project in financial terms. Indeed, each measure may be useful at a different level in an organisation – an IT manager focused on annual budgets may not be concerned with the cost of money but will want a fast payback and an impressive ROI whereas the CIO may be more concerned with the risk-adjusted ROI and the CFO may only consider IRR. It’s worth doing some homework on the hurdle rates that exist within an organisation and, whilst I may not be an expert in financial management, sometimes it doesn’t hurt to understand the language that the bean counters use.