Determining the total cost of ownership (TCO) of a software purchase is a complex process, rife with follow-on and hidden factors that must be taken into account. Here’s how to achieve a more accurate TCO estimate.
When organizations buy a shiny new piece of software, attention is typically focused on the benefits: streamlined business processes, improved productivity, automation, better security, faster time-to-market, digital transformation.
The other side of the cost/benefit equation — what the software will cost the organization, and not just sticker price — may not be as captivating when it comes to achieving approval for a software purchase, but it’s just as vital in determining the expected return on any enterprise software investment. After all, if you can’t accurately forecast or calculate the total cost of a software implementation over the full lifecycle of the product, you have no foundation on which to make sound IT decisions, purchasing or otherwise.
What is TCO and why is it important?
Total cost of ownership (TCO) is an estimate of an organization’s overall expected spend to purchase, configure, install, use, monitor, maintain, optimize, and retire a product or service.
A full-blown TCO analysis can be complicated and time consuming. But if you’re a department head pitching a major software expenditure to a CIO, if you’re a CIO with a limited budget trying to choose between competing projects, or you’re a CIO trying to sell a software-driven strategic initiative to the CEO or the board of directors, a strong TCO analysis is a must.
Beyond simply providing an accurate and predictable analysis of costs over time, digging into TCO can provide other benefits. It can help uncover hidden costs that could come back to bite you down the road. For example, if you plan to run the application for five-plus years, but the servers you plan to run it on are approaching end of life and will need to replaced in two to three years, you’re going to need to account for that.
A TCO review can also help make sure a software implementation performs as expected and delivers the benefits you were looking for. A TCO analysis forces you to think about things such as data migration, employee training, and process re-engineering.
The good news is there are guides and templates to help you get started. For example, Apptio offers an application TCO cheat sheet, and GetApp has an Excel spreadsheet TCO calculator for both on-premises and SaaS applications.
But there’s no cookie-cutter way to determine TCO because so much depends on your unique environment. And it’s always a good idea to reach out to as many people as possible to try to anticipate how this new software will impact various parts of the organization.
Any TCO calculation will have three major buckets: initial cost and installation; ongoing operation and maintenance; and retiring the software after its useful life is over. Here are some of key factors that should be included in each of these categories.
Initial purchase, configuration, and installation
Negotiating software license terms is a skill in itself that might require assistance from the company’s legal team or CFO. Most software vendors provide discounts off list price because they make money on long-term service and support contracts, which can run up to 20% of initial purchase price.
It’s important for organizations to seek RFPs from multiple vendors and to play hardball when it comes to negotiating license terms, service, and support levels, as well as financing options.
Most software vendors are transitioning from the traditional one-time perpetual license to a subscription-based model, which means that costs will be recurring, probably on an annual basis.
When performing a TCO analysis, it’s important to try to accurately estimate how many licenses you need today, as well as how many licenses you might need down the road. If that number is expected to increase significantly, then your costs will rise year-over-year. And there could be ancillary costs, such as the need for additional server hardware or data storage capacity.
As for installation costs, they can run the gamut given that deploying a new software platform is never a plug-and-play proposition. Here are some costs that will need to be included in your analysis:
- Hardware: Do I need to buy new hardware, or do I have capacity to run the software on existing servers and storage? If I have a hybrid model with on-premises servers, colocation facilities, and cloud-based infrastructure-as-a-service, what would it cost under each option?
- Energy: If I need new hardware, what are the additional energy costs in terms of electricity, cooling, etc.?
- Testing: Before I even deploy the hardware, what are the costs of quality assurance and testing? Applications don’t exist in isolation, so what are the requirements for ensuring the solution can integrate with the rest of the software stack?
- Configuration and cutover: How much configuration is required to set up the software to run smoothly in my environment, and will there be any downtime associated with the cutover from the old system to the new?
- Security: Make sure the security team is in the loop and has adequate time to vet the new software for potential security vulnerabilities. In addition, what are the costs associated with incorporating the new software into the organization’s security infrastructure in areas such as access control, authentication, and zero trust.
- Training: What type of training is required to get end users up to speed on the new software?
- Networking: Will this new software require additional bandwidth or new pathways for data to flow?
- Re-engineering: What type of process re-engineering will be required to make sure workflows are optimized to get the maximum benefit from the new software.
- Data migration: If you’re replacing a legacy point product with a more modern version, it’s important to calculate the cost of data migration. If you’re replacing multiple point products with a platform or suite, the data migration process becomes even more complex and costly.
- Backup: Application data doesn’t simply live in one place. Organizations keep multiple copies of application data for backup and disaster recovery reasons, so companies need to add the cost of replacing backups.
Monitoring, maintenance, and optimization cost factors
Once the app is up and running, there are additional costs that need to be included in a TCO analysis:
- Customization: Every organization has its own unique workflows and software dependencies, so the app will likely need to be tweaked to smooth out any potential bumps in the road to productivity.
- Integration: No matter how much testing occurs prior to installation, integration issues will always crop up and will need to be rectified.
- Patching/upgrades: Nobody likes the constant drumbeat of patches and software updates, but IT needs to devote resources to making sure the application is patched in a timely manner and running the latest version.
- Application performance managment: While a service and support contract will provide vendor assistance in the event the software gets buggy or crashes, it’s typically up to the IT staff to monitor application performance.
- Ongoing training: Training is a never-ending process, particularly as employees come and go, and the vendor adds new capabilities and features over time.
- License monitoring: There’s nothing worse than conducting an audit and discovering that you’re paying for licenses that are not being used. Conducting periodic audits can identify licenses belonging to employees no longer working at the company, or instances in which you overestimated license requirements for a particular team or business unit. In these cases, it’s possible to reduce licenses costs or to transfer the licenses to end users who can benefit from the tools.
Retirement costs center around data migration
It’s obvious that hardware, once it has reached end-of-life, needs to be disposed of properly. With software, there are costs as well, primarily associated with data export.
First, data needs to be migrated from the old software to the new, which can be complex given all the dependencies and database calls that might be required for even a single business process. Then there’s backups and disaster recovery.
The new software might require that data to be formatted in a different way. And you still might need to keep archived copies of certain data stores from the old system for regulatory or compliance reasons.
Another wrinkle in the TCO calculation is estimating how long you plan to use the software. Are you an organization that doesn’t change tech stacks if it doesn’t have to and therefore will probably run the software for as long as it still does the job? In that case, it might make sense to do a five-year TCO analysis as well as a 10-year version.
On the other hand, what if your company has an aggressive sustainability strategy that calls for eliminating all of its data centers within three years, and moving as many apps as possible to SaaS alternatives. You might need this software right now because it fills a critical business need. But you know it will have a shorter life span and your TCO calculation would need to reflect this.
The bigger picture: Cost vs. benefit
Keep in mind that determining TCO is only part of the cost/benefit equation. C-level executives conducting an ROI analysis need to balance estimated costs with anticipated benefits. New software should support high-value projects and align with the strategic goals of the company.
Of course, both the anticipated benefits of new software as well as the expected TCO are estimates that are subject to change. But conducting a detailed TCO analysis provides a solid framework to build on. And it’s certainly preferable to flying blind and then getting hit with surprise costs down the road.
More on TCO and ROI:
