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.

In the previous chapter we saw the difference between a business use case and an application use case. In this chapter we discuss a process for deriving impacted AUCs from a BUC.
5.1    Overview

The BUC includes business process steps making up its workflow. Each of these steps has the option to be automated. The business analyst (BA), systems analyst (often the same person), systems architect and business process owners (BPO) determine between them which steps are to be automated. The systems analyst and architect roles are mainly to determine the time and cost to automate the business process. The BA and BPO will determine the return on investment (ROI) in order to determine if there value in automating a business process.

A typical IT project will involve IT people resources, of course; analysts, designers, programmers, testers, trainers, etc… The titles may be different at your company, but the people will be performing these roles. The question, of course, is how much of the valuable time of these people will be needed, and how much that does that time cost? This is when the estimating begins.

Estimating the cost of IT projects is a whole discipline in of itself. I highly recommend the writings of Vitalie Temnenco on this topic, such as “Software Estimation, Enterprise-Wide - Part I: Reasons and Means (June 2007), at

 http://www.ibm.com/developerworks/ration… ,