How do you know which IT Projects to do? Benefits…
Defining the benefits of an IT project is a different issue from defining costs; the latter may not be easy to calculate, but it can usually be done. Benefits, however, are usually in the mind of the people who want the project done, and generally are not easy to get defined and get a dollar value assigned to them.
In fact, the definition of benefits for IT projects does not exist as recognizable discipline. If you go searching for it, what you will always get is the answer that business sponsor/owner has to tell IT what the benefit is. If they can’t reasonably describe and quantify a benefit, then the project will not happen.
In the early days of IT Projects, the stated benefit was usually the automation of manual effort; this was not always as simple to propose as it sounds, because automation usually was translated into reduced head count for the business. If the staff in the area affected by a project perceived this as eventually leading to lay-offs, this could kill a project because you almost always need those people as the business experts for the business scope of the project. I wrote many project proposals that had reduced manual effort as the prime benefit, but further described these savings as allowing the enterprise to take on more business without adding more people, or freeing up people to do new more valuable work for the enterprise; reduction in headcount was never mentioned.
However, automation of manual work as a benefit could usually be quantified in dollars in potential saved salary costs. The problem today, however, is that all the obvious automation projects have probably already been carried out at your company. This leaves smaller or less obvious cost-cutting projects, or projects that are expected to increase revenue/income.
The question becomes: how much will this project contribute to increased sales of products and/or services. This is difficult to predict, and most business people are leery of attempting to do so. Just like IT Project teams are held to a project estimate or be considered late/costly, business people who estimate revenue increases can be held to task if it is perceived that the expected increase did not materialize. An interesting corollary development is the increase in the number of companies that are evaluating projects some time after they complete (six months or so) to see if the promised benefits have been realized. This can make business people even more wary of putting their names to what is and should be treated as an estimate.
In the end, however, some dollar value of benefits needs to be proposed and agreed to, if a cost-benefit analysis is to be performed. All I can say here is that, like all estimates, stating your assumptions and having them agreed to as the basis of your estimate is crucial. If reality proves that one or more assumptions turn out to false, then everyone involved in the project shares responsibility.
- dwright's blog
- Login or register to post comments
- 795 reads
There are recognized frameworks for doing this
D. Wright,
There are two problems, both of which lead to dissatisfaction with IT project outcomes and with the cost of IT (It's too expensive!).
The first, as you've mentioned it is, is around measuring benefits. There is an excellent framework for doing this called Val IT that comes out of ISACA (Information Systems Audit and Control Association). They're the authors of the CISA and CISSP standards for auditor and security certifications. COBIT, upon which Val IT is built, also offers processes and suggested KPIs for measuring their performance. These are, unfortunately, high-level frameworks and while they tell you what to do they don't tell you how to do it.
This is where other methodologies come in. The one that is most quantitative in nature is called Applied Information Economics and is endorsed by both Forrester and Gartner as being a good if somewhat (unfortunately) onerous methodology. Regardless of this the author of this method published a book entitled 'How to Measure Anything' which gives you insight into measuring the 'unmeasurables'. According to him all benefits can be measured - and if you read the book I think you'd have to agree he's right. It requires that you be a bit of a creative thinker though. Another way to identify the benefits is through brainstorming.
The second problem as I see it is managers' unwillingness, or perhaps lack of motivation would be kinder, to measure the outcome. In other words, once the project has been delivered are we really seeing the benefits we predicted? What can be seen as a negative, i.e. we didn't get the benefits, is really a positive if learning and the ability to make mistakes is tolerated in your company's culture. The more you predict/measure benefits the better you get at it. Intel's IT business value program has been tracking IT benefits since around 2004 if I remember correctly. They've racked up $100's of millions in savings and can demonstrate it.
This second 'opportunity', to flip it on its tail, includes changes to how you manage IT. What's the point of doing business cases if the political structure means those with power get their projects approved. I'd like to think this is less true today but continue to see it in different forms in organizations I work with. In one heavily regulated company, quality and finance got their projects approved by fear - 'If we don't do this we're going to suffer the ten plagues of Egypt'. OK, I'm exaggerating...but only just. Even risk can and should be quantified so the benefit of risk avoidance can be weighed against value add when comparing the two different kinds of projects - as usually companies can't do every project on the table.
This political challenge can be met with a framework like Val IT. It turns all of these things I've mentioned above into processes - including how senior management decides to fund projects.
I hope this helps. And if you need help getting these practices and processes in or even justified, give me a shout - I do this for a living :) - including making, or helping others build, presentations to senior management to convince them why they should go this route.
Asad Quraishi
Principal Consultant
Knowledgework