How to understand - and reduce – the true cost of a system.
Which is greater, the upfront cost of a new insurance system or the cost to maintain it? The answer may surprise you.
With everything from new business, to underwriting, to claims management moving off paper and onto digital platforms, today every insurance company is (or should be) a tech business. This means everyone from the CIO through to product managers have a vested interest in exploring the potential of new software programs and systems to improve the efficiency and cost of day to day operations.
The potential productivity benefits are vital to the business, but the increasing demand for technology support is putting the IT function under pressure. IT budgets are not infinite, and decisions about IT expenditure very often come down to the raw numbers; how much, and how long, will this project take to deliver.
But what’s most critical - and more difficult to factor in - are the ongoing running and maintenance costs that will be required. Without considering the lifetime cost, it is possible to underestimate the cost of the new system by a factor of 10.
Gartner have estimated that on average a system will last 15 years and 92% of the total cost will be incurred after it goes live. Which means, if the initial development cost of your new system is $1,000,000, then the annual ‘maintenance’ cost will average $766,667 per year and total a staggering $11,500,000 after 15 years. And, these numbers are just averages. In your case, a lot more than 92% could be spent after the initial project.
It’s a sobering thought if you’re thinking of investing a few million on a new software project.
But, you might say – we’ll just watch our project more closely to make sure nothing gets out of hand. Unfortunately, Gartner also states there is no direct correlation between the initial project cost, and ongoing maintenance costs. This puts paid to the idea that prudent management of the initial project will be effective in reining in the system lifetime costs.
So what can you do to reduce the lifetime cost of an IT system?
When designing a software application there are several necessary steps which need to be carried out in order to ensure the final system works as planned, provides the functionality your users want, and integrates effectively with other existing systems.
It is also critical the architecture you choose for the initial project also has the flexibilty to designed for the entire system life cycle. You should assume everything that makes up the initial system will need to change over its lifetime.
Plan for future enhancements early
Be pragmatic about the need for future enhancements, and plan accordingly:
- Build in a well-established programming language that will continue to be supported. This will also make it easier to find skilled developers. The clear favourite today is Java.
- Ensure the system is modular not monolithic so that each component can be updated or replaced as needed without needing to rebuild the entire system
- Reduce the cost of future development by ensuring the system can be updated through configuration rather than more expensive coding.
- Ensure all interfaces are generic so they can be readily adjusted when external systems change.
- Build fully automated and comprehensive test scripts that can be handed over to the maintenance team after go-live.
- Use well-supported pre-existing components and libraries rather than developing your own.
Ensure there is a clear view of the required outcome
Today the complexity of IT projects is rapidly increasing, with an ever-widening group of stakeholders bringing new and sometimes conflicting demands to the table. This may lead to a situation with several hundred ‘must have’ features which are added just in case, without a clear rationale or user group to test.
In these circumstances it is much better to build the ‘minimum useful product’ using flexible technology in the first instance, and then add other features when you are sure they are needed.
Ensure that all decision makers are behind this approach by making sure they are fully immersed in the project so they make decisions based on a complete understanding of the requirements rather than focusing on their own needs based on their role in the business.
Prevent scope creep from creeping into the maintenance phase
Project managers can be effective at preventing scope creep during the design and implementation phases, but additional requests and features may be raised at a later stage.
Implementing them through the maintenance team rather than as a separate project does not allow for alternatives such as refactoring the solution or adding on other components to provide the new function. Not only may this lead to suboptimal solutions, but it can also can have a significant effect on the lifetime cost of ownership. To prevent this, don’t allow for enhancements in the maintenance stream, and include these as separate projects instead.
Maintenance costs also have a tendency to blow out if critical features are not completed as planned by the project team. Should deliverables be missed, consider creating a new project to deliver these, rather than handing them over to the maintenance team.
Be realistic about expected future costs.
Much like a car, the cost to operate, support and maintain software increase as it gets older, so be realistic about the expected future costs. Often the maintenance budget is consumed in finishing off the original project, resulting in a drop in that quickly creates more problems.
Make sure there is enough funding set aside for quality maintenance in advance, on top of any funding required to complete the original deliverables. As with a car under investing in routine maintenance can lead to much more significant outlays later. As an example, if you don’t validate all data on entry it can be expensive to retrospectively clean the data.
Ensure your maintenance team is delivering to best practice.
Ensure that you retain a knowledgeable and skilled maintenance team who have previous experience with the system to support future requests, rather than handing over maintenance to a new internal or external team. Over time this team will be a bigger investment than the initial project team, so make sure they are competent, experienced and well supported.
Ensure they carry out good development practices, such as building fully automated test scripts, writing code in consistent style, performing code reviews, doing performance and penetration tests, and running full regression tests before each new deployment. These practices are critical in maintenance to ensure a quality system.
With all this corrective action, is a zero maintenance cost possible?
Is it possible that with appropriate action you could prevent Gartner’s 92% cost after implementation figure? While no IT solution is identical, it is inevitable that over time significant maintenance costs will be incurred. This is why before investing in any new software whole-of-life cost modelling should be completed. This should include an estimate of an appropriate maintenance and enhancement budget which should be taken into account when choosing the technology platform.
It is likely that in the end the best option will turn out to be not the one that is the cheapest to implement, but the one which will provide the most functionality for the least cost over the full lifetime of the solution.