Common mistakes when calculating Total Cost of Ownership (TCO)

The benefits of Total Cost of Ownership (TCO) analysis are clear and well documented, yet surprisingly few companies do it well or accurately. While working for Covisint, who offer Software and Platform as a Service solutions, it was common to have companies state that they could provide the same services being offered at a fraction of the cost, yet when you drilled in at any level it often became apparent that all they were looking at was initial cost of software and hardware and the most obvious project costs.

While working on a multi-million dollar in-house project I inherited, almost the first exercise I was given was to look at the technical budget to validate it, only to discover large areas of the TCO to be entirely missing. This included relatively simple things like hardware replacement over time and disaster recovery, to more subtle things like understanding the compound impact of inflation on salaries and maintenance over 5 years.

Almost every enterprise will end with their own TCO calculator based on their business model, and a variety of factors such as buy versus build, or in-house versus SaaS. Having said that, there are certain common errors that are made when calculating TCO – here are some of them

Inflation

This may seem ridiculously obvious, but it is amazing how many people fail to take inflation into consideration. If you have a spreadsheet that you use for TCO, have each column multiple the value from the previous column by the rate of inflation for the last few years, you will be shocked by the impact on TCO over 5 years.

As an example if you are paying $1,000 for support for software per year and the vendor contract allows them to increase by 3% per year, that $1,000 becomes $1,125 in year 5. Over the course of the 5 years the costs changes from $5,000 to $5,309. At 5% (which is not uncommon) the cost becomes $5,525 over 5 years, a 10% cost. That may seem counter-intuitive, but % increases year over year have a compound effect.

Some line items do not follow this pattern, for example storage historically has tended to get cheaper over times (although businesses end up using more over time).

People

On premise projects require a project; a project requires people. Even if you totally outsource the project, you still have internal resources that manage the project, redline the contract, conduct architecture reviews, and provide networking support. Calculate a blended rate for each type of position and calculate the number of hours. And yes, take into account annual salary increases.

Disaster recovery and business continuity

Business owners often leave disaster recovery off the list of requirements. In some cases they deliberately do it to lower the perceived cost, in other cases they had no idea it was an extra cost. Work with the business to define their disaster recovery and business continuity needs. Define both a recovery time object and a recovery point objective and help the business to understand the implications of each. Then define and cost your architecture and hardware appropriately

Storage

Storage is cheap, right? Well not as much as you may think. Common storage errors:

1. Calculate what you need at the start of the project. Buying disk that sits spinning empty is simply a waste of time.

2. Accurately project what you will need and what the growth will be. Make sure you have the business discussion on retention of data. Your storage requirements will be vastly different if you can purge data after 3 months versus keeping it 5 or 10 years.

3. Calculate actual storage required. This is sometimes called usable storage. If you have an Oracle database with 50 tables and the records use 3 TB, you don’t need 3 TB. Databases require temporary space, there is disk used up when you transform data, and every field that you index uses space. Get a DBA to calculate what your real requirements are.

4. Your storage costs need to take into account redundancy, a process that can double or triple your usable space requirement. A good IT department will take your usable space requirement and calculate your cost with redundancy built into it, based on your business requirements. Have the discussion - don’t simply assume this is being done.

Hardware replacement

Servers get old and have to be replaced. Your IT staff will be able to tell you the numbers you need to use for this. Depending on the systems being used, server and workstations should be replaced every 3 to 5 years. In fact any hardware will have the same issue. If you build a TCO over 5 years (and I would not recommend less) this has a significant impact.

Training and support

People have to be trained, and for a large system replacement involving re-training, this can be as large a cost as the system itself. Work out you model, and include training costs for every year since users leave and new user come on board. The larger the user base, more complex the training, the higher the cost.

Define level 1, 2 and 3 support. Most likely level 1 will be run by your organization, so understand the impact in support personnel and training requirements for your support staff. If your vendor provides level 2 and 3 support, understand the costs involved. And if you developed it yourself, chances are you are providing all 3 levels, develop your TCO accordingly.

Hidden vendor costs

Vendors can intentionally or unintentionally hide costs, or simply not explicitly state them. An example would be a contract that specifies they will integrate with the first system, but doesn’t give explicit costs for future integrations. Never assume that if the cost for something is not explicitly stated it is free, it is almost certainly the opposite. Common areas to look for include additional integration costs, if you use an MPI growth in the number of records, modules you may assume are included but are not, and consulting fees.

Scaling and growth

Systems grow and your TCO should reflect that. As users are added you require more servers, greater bandwidth, more training, and increased support. Even if the user base does not grow, storage will grow year after year unless you are able to purge old data. Systems are seldom static, build a realistic deployment model that shows realistic growth over 5 years. Then set higher and lower growth numbers and model it at least 3 ways.

Usage patterns

This may be one of the least intuitive factors, but particularly in a hospital setting (the industry I work in) there are peak hours. During peak hours concurrency increases, and if not correctly designed systems may not perform as expected, resulting in slower response times or even time-outs. In most hospitals running 12 hour shifts your peak usage time is from 6 to 9 am. That period includes rounding, shift change and admission of patients for outpatient procedures.

Compliance

Finally do not forget compliance. Are their Sarbanes-Oxley implications for the systems you are implementing? In healthcare, while most systems are HIPAA compliant, you still have to make decisions such as whether to encrypt data at rest for PHI to get the HITECH safe-harbor, and how to do that. If you are dealing with mental health data understand your responsibilities under CFR 42. There are a slew of state and federal regulations, make sure you understand them and plan accordingly.

Total Cost of Ownership should be a routine part of planning for any major project. The reality is that most major IT projects run over budget, and lack of an accurate TCO is often a major factor in budget overruns. From a business perspective, business owners need to know the TCO to make an accurate return on investment analysis. No matter how well we do the TCO analysis there will always be unexpected project overruns (consider adding a contingency number to the budget), however a good TCO analysis will reduce the number and severity of these.