Defining the benefits of an IT project is a different issue from defining costs;

...continuing from the previous post...

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. However, benefits 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 it could lead 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 (taking orders on-line saves on paper costs...whoopee!), or, projects that are expected to increase revenue/income.

The question becomes: how much will such a 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.

Next time: Cost - Benefit Analysis

See more about Cascade on Amazon http://amzn.to/gbgYNJ ; On Sale(!) at lulu.com http://bit.ly/92k1gf