email article printer friendly

What's ROI Got to Do With It?
If you want to be taken seriously when proposing IT investments, calculate the ROI for your organization.
by Simon Galbraith

IT managers are flocking to .NET to take advantage of its new libraries and more efficient approach to developing software. The move to .NET improves productivity dramatically, but it also comes with challenges. Companies need new tools to take full advantage of the .NET architecture, but IT managers need to justify purchasing them.

In today's cash-strapped business climate, you need to arm yourself with return-on-investment (ROI) information that presents your case in terms financial managers can understand. Contrary to popular belief, ROI isn't about getting your investment back; it's about making an investment that delivers high returns over a short period of time.

The approach you use to determine the ROI for a software development tool is the same one you use for a physical asset. The difference is that your purchase's end results are less concrete. It's unlikely any direct income will result from the purchase, only greater operational efficiency. In this article, I'll explain the issues you need to consider when determining ROI so you can convince the people who control the purse strings your new tool is a worthwhile investment.

To understand ROI, you need to understand the total cost and total benefits of ownership. The value of the benefits needs to be greater than the cost of ownership. Calculating ROI is pretty tricky and you need to break it down into four determining factors: inputs, external costs, internal costs, and benefits. I'll demonstrate how you'd use these factors for a bug-tracking software package (see Table 1).

One important note: Although making an ROI calculation is normally valuable, once you reach a certain price point, the process becomes more costly than just making the purchase. If everything you ever bought were justified by a proper ROI calculation, you and your staff might be working full time on purchase justification documents. In my experience, an ROI calculation for any purchase of $2,000 or less is unnecessary and counter-productive.

When you do want to apply an ROI analysis, an initial set of inputs stays fairly constant. They include:

• The length of time the investment can be considered relevant. This should never be more than three years for a software development tool.
• The number of staff who will benefit.
• The number of working days a year for the staff who will use the software.
• The internal cost for that staff. (This is sometimes called the overhead rate and is normally set by the finance department.)

In this ROI analysis, you'll have both external and internal costs. External costs should cover all expenditures in real dollars for purchasing the software, licenses and support, hardware, training, consultancy, and any other expenses. Internal costs are generally measured in time, but you'll need to convert them into dollar amounts using the cost of staff input figure. These costs are an important part of your investment and are often much higher than external costs. You should note that, despite its name, "freeware" has a cost because license fees are usually only a small component of the total investment. Finally, you need to calculate benefits the same way you calculate external and internal costs.