Putting total cost of ownership (TCO) into action
TLDR; in this third and final blog in the series on TCO, we explore how TCO can be used to drive action throughout the lifecycle of a digital asset. There are three key areas: using TCO up front to determine whether a business case exists for a technology investment; using TCO during the design phase to help explore solution options and surface underlying assumptions; and using the actual TCO of existing digital assets to identify where application modernisation and rationalisation is needed. Finally we recommend that you work in partnership with finance colleagues to calculate TCO.
Use TCO at inception to "fail fast"
The earlier you can calculate TCO in the lifecycle, the earlier you can use it to make informed decisions, enabling you to avoid common traps such as the sunk cost fallacy.
When estimating TCO for a new digital asset there is likely to be uncertainty, so provide a range of values that you would anticipate. If historic data is available, use costs incurred from similar digital assets to back this up. This will really help to focus minds on the validity of the investment that is being considered, enabling you to frame questions such as:
Should we invest in this asset in the first place? Will it generate sufficient business value over its lifetime to justify the TCO? In other words, does it have a positive return on investment (RoI)?
Is the TCO complete? Does it include all of the costs associated with delivering the asset over its lifetime?
Are there other higher priority / higher value areas we should be diverting this investment to?
Expect to get a shocked response and challenge from stakeholders when you calculate TCO. I used to have a stakeholder who would respond "What? That's way too expensive! I could build that myself in a weekend!" whenever I provided them with a TCO for a new technology product they were considering. When you receive this type of response, stay calm, explain everything that you have considered and how that has contributed to the TCO.
This typically comes down to functional requirements vs non-functional requirements. Provide a check list of all the things to consider, and ask that stakeholder how they have factored in all of those "known knowns". What you will find is that the "known knowns" are the stakeholders "unknown knowns" - and that's the point - this is your area of expertise. Turning back to the to the owning a pet analogy, they're just thinking of the purchase price or adopting a rescue cat for free. Not the food, pet care, vet and cremation costs.
Hopefully, after getting this broader perspective, the stakeholder will agree that the TCO you have generated is more representative of the true costs.
If at this point, they still see the TCO as being too high, this is no bad thing. You have "failed fast", wasting little time and effort to determine that the anticipated benefits do not justify the costs.
If the TCO is acceptable, you have set expectations early with stakeholders about the budget that will be needed to develop, sustain and retire the digital asset over its lifetime. This is no bad thing!
For this reason, we recommend that you calculate even an "rough estimate" of TCO as early as possible in the lifecycle as possible.
Use TCO to surface assumptions and explore potential solutions
Another useful aspect of preparing a TCO is to highlight the underlying assumptions that have made to formulate it. We recommend setting out the underlying assumptions along with the TCO, this enables the assumptions to be constructively challenged and for alternative strategies to be identified, or for the assumptions you have made to be validated. For example:
Architecture - are there alternative architectures that could fulfil the requirements. Is the solution over-engineered? Are there existing platforms in use within the organisation that could be leveraged to deliver the solution?
Buy Versus Build - is there an off the shelf alternative?
Resourcing - the decision about in house, independent contractors, local technology provider or off shore provider. By viewing this through the lens of TCO, access to cheaper resources overseas may not be as attractive when you consider other factors such as the overhead in communicating requirements, the extra layers of management and the impact of knowledge loss due to the higher churn of resources.
Vendor choice - looking beyond the core license or platform costs to aspects such as developer experience, level of responsiveness to support tickets or the ability to partner with the vendor when it comes to influencing the direction of their product.
Operating model - allowing you to make a choice between a "proactive" maintenance approach and a "break fix". For low risk scenarios, a "break fix" approach may be justified provided you are willing to absorb the business disruption of outages, which should be included in the TCO calculation.
Software Bill of Materials (SBOM) - can be used to support TCO, highlighting the value of developing a full understanding of the constituent parts of a solution. By leveraging your SBOM you can weigh up different options such as use of open source versus licensed platforms. The SBOM may also highlight indirect costs by highlighting the risk associated with the dependencies - for example the high profile Log4J vulnerability.
Use TCO to drive rationalisation and modernisation
You should also revisit TCO for existing digital assets on a periodic basis to evaluate actual TCO versus forecast TCO. This will generate some interesting insights, allowing you to answer questions such as:
Which digital assets in your organisation are not generating a sufficient return on investment to justify true TCO? Should we retire them to free up cash and resources? See the separate blog A simple toolkit for IT budgeting and planning for a more comprehensive approach to rooting out waste in your technology budget.
Which digital assets are incurring a lower TCO than anticipated? Are we accruing technical debt and / or risk as a result?
What strategies, could we adopt that would enable us to reduce TCO overall?
Work in partnership with finance colleagues to calculate TCO
Finally, we recommend working in partnership with the finance team within your organisation to calculate TCO. TCO is one half of the calculation of the "net present value" of any investment, the other half being the total lifetime value. The finance team can help to navigate some of the pitfalls and layer in important considerations such as depreciation (for capital investments), the "cost of cash" and inflation into the calculations. They can also help to leverage historic financial data as a means of validating the calculation. By getting finance colleagues involved your TCO will have credibility with stakeholders.
Further reading
We hope that this article helps you to make better decisions in your organisation when it comes to making new investments in technology and / or protecting existing investments. Other articles and blogs that provide further perspectives on this topic include:
Gartner's defintion of Total Cost of Ownership (TCO) also includes the costs of any downtime of the asset including opportunity cost and loss in productivity. This could potentially allow you to a compare and contract different TCO strategies: for example a "break fix" strategy where outages are anticipated and the costs incurred are accounted for versus a more practice TCO which seeks to minimise outages and disruption.
Arif Harbott, writing for Computer Weekly: "The true cost of running technology" makes the case for proactive investment (what he calls addressing "value demand") in order to deliver maximise the value that TCO generates over the lifetime of the asset.
Alessandra Gyben, writing for Technology Advice: "Total Cost of Ownership in Technology: Implementation" points out the hidden costs of adopting freeware and the disruptive impact that it could have on your organisation when it outgrows it.
Dave Vale, writing for Computer Weekly: "Of cats and clouds: a lifetime TCO question", uses cats rather than power stations to make important points about the importance of considering TCO when it considering a migration from on premise data centers (capex) to public cloud infrastructure (opex). We have a cat, and I was shocked to see his TCO calculation for an average moggy!
Mike Lauer: "Total Cost of Ownership is a Mindset Problem – Not a Math Problem", is concerned with "custom applications". Here Mike highlights the different phases of the application lifecycle in a similar manner to our blog above. Reinforcing the need to adopt an experimental "Investor Mindset" during the early stages, a "Homeowner Mindset" in the sustain phase and an "Ugly Baby Mindset" in the later stages. In the later stages he talks about rewriting but does not mention the other option which is retiring.
