Software Development Tool Purchasing

As an IT manager in today’s cash-constrained business climate you will be faced with many challenges. One of the trickiest is how to justify the purchase of a new software development tool. You and your staff might believe the benefits are obvious, but others can easily view such a purchase as little short of indulgence. What you will be required to do is illustrate that there will be a measurable return on your proposed investment. You will need to demonstrate a positive ROI.

So, what is ROI? Well, the answer to this is not simple because different circumstances require different calculations. Sometimes a very broad sweep will be necessary, setting both tangible and intangible benefits against overall outlay and extrapolating this over the full lifetime of the new tool. More often, though, a much narrower definition will apply, one that views ROI as a percentage representing the annual return on the capital invested.

“Our customers look for a demonstrable return over a meaningful period.” says Simon Galbraith, founder and Marketing Director of Red Gate Software who sell a range of tools to support and assist the development process. “Typically that’s no more than three years, which means our products have to show an average ROI of at least 33% per annum.”

Although essential, projecting ROI can be a laborious task. The starting point should be the calculation of absolutely all the costs that will be incurred in making the investment. This might appear straightforward as both the purchase price of a tool and its ongoing costs (maintenance, upgrades, etc.) are clearly defined. That, of course, is not the end of the story. Software does not install and implement itself; staff do not simply wake up one morning fully skilled in how to use their new tool. Thus, it is necessary to include in the calculation an allowance for time spent setting up the product and learning how to use it. This may be a matter purely of staff time, though it could involve external expenditure on consultants and trainers. Installation may also require the acquisition of new hardware.

This is perhaps a good moment to explore the principle of internal costs. These are the nominal rates used to value staff time. Some people call this “funny money” because it is not real expenditure, meaning that it does not involve actual payments going out of the company. Some even dismiss such costs as irrelevant. This is a big mistake. These costs are not merely the result of some management accountant’s idle imaginings; they represent how much it costs the company to employ each member of staff, taking into account not just salary but also various other overheads. So, if staff time is being used on a project such as the introduction of a new tool, the cost of that time must be included in the overall investment computation.

Sometimes another factor comes into play. By allocating staff time to a project, that time is being denied to any other project or task. There is, therefore, a knock-on effect, which ought to be recognised when assessing the full cost of investment. Another project might be delayed, for instance, an action that may or may not have a financial impact upon the company. To mitigate any delay, temporary staff might be needed. In the case of a software house, the amount of time available to work on customer projects may be reduced, thus degrading the company’s revenue-earning capacity. Here, there is a true opportunity cost, which may mean valuing staff time even higher than the standard internal rates.

So much for the cost side of the calculation – what about the returns? Well, the first rule to remember is that a payback on investment can come in two forms: increased revenue and/or reduced costs.

“Essentially, there are three types of development tool.” explains Simon Galbraith. “Tools that improve productivity, like IDEs and bug trackers; tools that validate work already done, such as the traditional load testing products, and tools that enable you to do the right thing. This last category might include proof-of-concept testing tools, for instance.”

Given these classifications, it may seem unlikely that a software development tool will provide increased revenue opportunities, but it does happen. One real life example is of a software house that invested in a report writing tool, its aim being to reduce the time developers required to produce customer reports. As a spin-off, though, it also offered the company a new income stream, which it gladly exploited by establishing a fast response database reporting service.

Of course, accelerating throughput, as in the example above, is chiefly a matter of improving productivity, of achieving more without increasing staff numbers. However, as Galbraith warns, throughput should not be the only metric: “Improved productivity is not solely about doing more with existing resources. Sometimes it is about doing the same things better.”

There are many illustrations of this, including some that derive from tools that more obviously fit into Galbraith’s second category, tools that are designed mainly to validate work already done. For instance, a company that invested in a regression testing tool found that benefits accrued not just from speeding up the testing process, but also from making that process more watertight. The tool enabled iterative processes to be repeated quickly and identically on all occasions. Testing staff were freed from undertaking these boring, repetitive chores and were deployed instead on tasks that more vigorously tested functionality, security and robustness. The end result was higher quality software, which in turn meant reducing the cost of re-work and raising customer satisfaction.

As Galbraith agrees, such instances show that, whilst his classifications are neat and readily understandable, they are not mutually exclusive. “Just because a tool is aimed principally at improving productivity by accelerating throughput, it doesn’t mean that it won’t deliver additional benefits in the shape of, say, reduced re-work.” His message, therefore, is that anyone assessing ROI for a development tool must think broadly and, as well as including savings on both internal and external expenditure, must look laterally for spin-off savings and ahead for future and on-going cost reductions.

The end product of the ROI calculation exercise ought to be a brief, but comprehensive document, possibly in spreadsheet form with supporting notes. These notes are important, as they should explain the basis of your reasoning, clarify the assumptions you have made, itemise your information sources and highlight any known omissions, limitations or constraints. What must never be forgotten is that the aim is to determine a percentage ROI per annum. Consequently, all costs and benefits must be measured in the same units, namely pounds or dollars. This will mean converting such benefits as productivity gains into a monetary sum.

One final matter to consider when preparing this document is risk – the risk of buying the proposed product and the risk of not buying it. Such an assessment is not actually a part of the ROI calculation, but it is useful to include it as it can have a material impact on the ultimate purchase decision.

Many risks can be seen in purely financial terms. The risk of buying a product might be measured, for example, as the product’s price and the cost of its installation and implementation. This could be seen as the worse case scenario, where the product fails before it delivers any of the expected benefits. That may not be the end of the story, however. Its failure could adversely impact other activities, so it is important to identify any dependent projects or initiatives. Means of mitigating or obviating such risks should also be explored.

And what of the risk of not buying the product? This could, indeed, be the biggest risk of all. Staff may remain demotivated, customers may decamp through continued late delivery and poor quality. It is even possible that the company’s growth will be stifled, that it will be unable to adapt to new market needs and that it will become uncompetitive.

“At Red Gate,” says Simon Galbraith, “we recognise the challenge IT managers face when having to justify investment in development tools. As a responsible vendor, we welcome the scrutiny necessitated by the ROI calculation process. After all, it is very much in our interest that Red Gate’s products are bought for sound financial reasons and are measured favourably against well-constructed commercial objectives.”

Indeed, the ROI challenge can often prove not just useful, but enlightening. It is certainly something that should be embraced by IT managers and one that should hold no fear for them.