A bit of discipline required

I continue to be surprised at how few companies systematically measure the impact of IT projects on the business in monetary terms. When doing some recent research into master data management projects I frequently found that even quite large projects had no business case and few firms had looked back to see whether promised benefits actually transpired.

In my particular research 37 per cent of companies that participated made "no attempt" to build a business case for their projects, while a study by Aberdeen Group some years ago found that just five per cent of companies regularly did post-implementation reviews of their IT projects. That's just one in 20!

Why does this state of affairs occur? No one would drill for oil or build a new factory without having a pretty firm idea of what it might cost and what it was expected to deliver, yet many IT projects seem to get by without this basic financial discipline. I learned my trade at Exxon, where even small IT projects had to be justified with a cost/benefit analysis, and it still surprises me that this approach is by no means universal.

Even if your company does not insist on producing net present value and internal rate-of-return analysis of all significant IT projects, there is a good reason why you should. Some projects get kicked off because they have a high-level business sponsor who has sufficient influence or budget, or both. However, as we are all aware, senior managers move around, and if your project is the pet of a sponsor it is vulnerable if he or she moves on for some reason. At some point there will be a review of projects conducted by a steely-eyed financial controller, and there will be a process to winnow out the least promising projects in order to save money or resources. When this project beauty parade is carried out you can be sure that one of the first questions to be asked will be the strength of the business case for the project, as choosing projects with the highest internal rate of return is an entirely rational way of prioritising.

It should not be that difficult to produce a business case for a project. There is a steady state business situation, and your budget gives you a vague idea of what the project is going to cost. Your project is going to improve things in some way so it should be possible to quantify that, either in terms of manpower saved, some specific cost saving or in terms of some top-line growth. It must be possible to quantify these things, and even if you do not know what these savings are, then a business person, probably the project sponsor, must be able to have a stab at putting hard numbers against these benefits. There may be some nice 'soft' benefits, but these are unlikely to cut it with the financial controller.

Go through the project benefits one by one, quantify the ones that you can, leave the soft benefits for the PowerPoint presentation, and add up the hard numbers. Remember to only start counting the benefits the month the project actually starts delivering them, and map out these in a spreadsheet month by month or year by year. Set these benefits against the estimated costs of the project, subtract one from the other to work out the cashflow, employ the magic of the Excel Net Present Value (NPV) and Internal Rate of Return (IRR) functions and, hey presto, you will have a business case for the project. As a minimum, show the NPV (which should be positive), the IRR (which should be more than your company's cost of capital hurdle rate -- your friendly finance person will explain) and the payback period of the project, which should be as short as possible.

If no-one can come up with any quantifiable case for a project, then unless it is rendered compulsory by a regulatory change, it should almost certainly not be done. None of this is rocket science, so why does it not happen as a matter of course in all companies? I remember one of my managers at Shell saying that many corporate bosses didn't seek data to support their decisions because they felt that using their "judgment" and "instincts" were mainly what they were being paid for. This syndrome was summarised elegantly by historian James Harvey Robinson, who said: "Most of our so-called reasoning consists in finding arguments for going on believing as we already do."

I believe that there are very, very few managers who are so gifted that their instincts are always right, and that IT projects should be subjected to the same rigour as any other capital project. If you are feeling really virtuous, try going back afterwards and seeing what actually happened; that is, whether the benefits really came about as planned. When IT departments can do this as a matter of course, they will go a long way to gaining the respect of the business that so many find elusive.