Defining the benefits of an IT project is a different issue fromdefining costs; the latter may not be easy to calculate, but it canusually be done. Benefits, however, are usually in the mind of thepeople who want the project done, and generally are not easy to getdefined and get a dollar value assigned to them.
In fact, the definition of benefits for IT projects does not existas recognizable discipline. If you go searching for it, what you willalways get is the answer that business sponsor/owner has to tell ITwhat the benefit is. If they can’t reasonably describe and quantify abenefit, then the project will not happen.
In the early days of IT Projects, the stated benefit was usually theautomation of manual effort; this was not always as simple to proposeas it sounds, because automation usually was translated into reducedhead count for the business. If the staff in the area affected by aproject perceived this as eventually leading to lay-offs, this couldkill a project because you almost always need those people as thebusiness experts for the business scope of the project. I wrote manyproject proposals that had reduced manual effort as the prime benefit,but further described these savings as allowing the enterprise to takeon more business without adding more people, or freeing up people to donew more valuable work for the enterprise; reduction in headcount wasnever mentioned.
However, automation of manual work as a benefit could usually bequantified in dollars in potential saved salary costs. The problemtoday, however, is that all the obvious automation projects haveprobably already been carried out at your company. This leaves smalleror less obvious cost-cutting projects, or projects that are expected toincrease revenue/income.
The question becomes: how much will this project contribute toincreased sales of products and/or services. This is difficult topredict, and most business people are leery of attempting to do so.Just like IT Project teams are held to a project estimate or beconsidered late/costly, business people who estimate revenue increasescan be held to task if it is perceived that the expected increase didnot materialize. An interesting corollary development is the increasein the number of companies that are evaluating projects some time afterthey complete (six months or so) to see if the promised benefits havebeen realized. This can make business people even more wary of puttingtheir names to what is and should be treated as an estimate.
In the end, however, some dollar value of benefits needs to beproposed and agreed to, if a cost-benefit analysis is to be performed.All I can say here is that, like all estimates, stating yourassumptions and having them agreed to as the basis of your estimate iscrucial. If reality proves that one or more assumptions turn out tofalse, then everyone involved in the project shares responsibility.
David Wright
