These days, the creation of a new essential IT system is almost never the creation of something completely new. Most of the time, a new IT system is a replacement of a previous one.
In the first article in this series, we discussed establishing the objective of the new system.
This second article focuses on the cost of your old system and what that can reveal about the cost of your new system.
Yes, this does sound a little crazy. How can the cost of a system that is perhaps 15 years old really be relevant for the cost of a brand new, top notch IT system?
The magic lies in the combination of a couple of calculations. While these individual calculations might not be very insightful on their own, collectively they provide a useful benchmark for estimating the expenses of a new system.
Four useful calculations:
A) Doing the math on man-hours
A first calculation is unrelated to the cost of the system back in the days – but rather relates to the hours spent on the system since then.
Historical data on the maintenance and operational costs, including support staff, can inform the expected ongoing costs of the new system.
Would the estimate resulting from such a calculation be reliable in any way? As said, it’s the combination of calculations that will lead to a serious prognosis. So be careful! With an initial calculation like this, the margin of error could be as high as 100 per cent.
B) Sizing up the system
Consider this analogy: In building construction, it’s standard practice to estimate costs per square meter. These costs vary depending on the building’s purpose, whether it’s a house or a school, and also on the level of luxury involved.
In the IT realm, lines of code play a similar role to square meters in real estate. Both the quantity – the number of lines – and the quality – akin to the ‘luxury’ aspect in construction – provide valuable insights.
However, be mindful that the cost for the same type and amount of code will never mirror what it was when you first developed a system.
Expect to roughly double your estimate. Coding is just part of the expense. Ancillary costs, including project management, testing, and overhead, combined with wage inflation, typically equate to the coding costs.
Ask your IT department about this type of benchmarking, or give us a call!
C) Sifting through old bills
Based on the initial system, a third question can be asked: what did the creation of this system cost the company originally?
Why is that relevant? A general rule of thumb for calculating the cost of software renewal is to divide the original cost by four.
Many functionalities that might have required custom development in the past can now be integrated using standardized software components. Furthermore, infrastructure investments today are generally less than in the past. With just a click, such infrastructure can be accessed online through services like Microsoft Azure or Amazon Web Services.
D)Building-in a safety margin
To get everybody on board, I described how it is usually a good idea to add at least one serious functionality when replacing an essential IT system.
Bear this in mind during your preliminary financial estimations. Depending on the extent of the new goal, consider adding a margin of 10 to 20 per cent to your total cost estimate. And that’s that.
One more point: In this article, I’ve described four potential calculations based on your old system. While there are many such calculations available, each with its own benchmarks, the ones mentioned here are particularly significant.
Our advice is to discuss three or four of these calculations with your IT executive. This approach should provide a solid initial cost estimate!
In article three of this executive workflow series for IT replacement, we will go beyond the calculations based on replacing the existing system. In the next article I will start exploring how to calculate software renewal costs based on actual choices about the new system.