Understanding the Total Cost of Ownership (known as “TCO”) of digital products should be seen as a strategic imperative essential for sound business decision-making for CTOs.
One of the most difficult challenges in framing the CTO role is that the responsibilities defining the role don’t have easy definitions either. We know the CTO role came from R&D facilities during the 80s to ensure that such investments were synchronised with the strategy.
The CTO mission began with the idea of ensuring that R&D activities were fuelling business strategy. It’s safe to say that it wasn’t a role initially meant for small organisations. Of course, strategy is not an easy concept; the more details we add, the murkier it gets.
Nevertheless, one too-often-neglected concept which should be core to CTO strategy is the total cost of ownership (TCO). This article is an attempt to put this business-critical idea on the table finally and is split into two blogs to ensure the area is sufficiently covered. The follow-up blog is coming soon.
What is the Total Cost of Ownership?
The Total Cost of Ownership estimates the expenses associated with purchasing, deploying, using, and eventually retiring a product or piece of equipment. Therefore, TCO includes the total price across the product’s entire life cycle, from innovation to scaling to whatever happens after that. In that way, it captures a more accurate basis for determining the value of an investment than the purchase price alone.
If CTO strategy means anything, it means thinking about cost-benefit and return-on-investment analysis. In this sense, TCO spans the cost-benefit analysis but takes it further to ensure there are no hidden costs and that fully loaded costs are visible for decision-makers as the product is born and then matures.
Why is TCO important for CTOs?
In a digital business, the software is the business or at least a very large part of it. Therefore, the services and products CTOs are working on are part of a company’s valuation, whether the company is public or not, covering all aspects of the business, including the company’s management, capital structure, and future earnings. What CTOs do with technology, with their teams, under their leadership, increases or decreases the company’s value.
As a practising CTO, I have been involved in many technical due diligence efforts. Every time we looked closely, it was a shock for the sellers to see how everything adds up in TCO for the first time. There is usually a moment in every company’s life where the next round requires in-depth technical due diligence. We can better prepare for that.
It’s easy to see what happens when we neglect TCO:
- A company’s value and sales price may change thanks to issues uncovered in due diligence
- A buyer might demand a warranty for high risk of loss in reputation (security activities were neglected)
- The buyer may even cancel an acquisition process (information systems out of control)
- CTO replacement after the deal (inadequate positioning)
Of course, TCO is useful in many business situations and is foundational in industrial and manufacturing industries. However, in this article, when we refer to TCO, we think about digital products.
Types of costs estimates included in TCO
Basically, we need to add all costs to the TCO, even if some costs are indirect. Here are some examples of digital product development (not acquisition):
- Development (which includes team management, product ownership, quality assurance, DevSecOps)
- Technical Debt (a simple concept raising many questions for CTOs. Unproperly managed, it may easily lead to unbearable complexity and important loses in competitivity).
- Technology stack mismatch (inadequate solution choice)
- Licensing & tooling
- Running infrastructure
- Support & maintenance
- Incidents management
- Security breaches (in loss of reputation and recovery costs)
- Business continuity and disaster recovery
- Regulatory compliance
- Audits
- Training (+ continually onboarded new users)
- Governance
- Decommissioning
TCO equation
Estimating TCO is not rocket science, but it isn’t too easy either. Below is a model I’ve created to engage in TCO estimations with my teams. Like everything else, it comes from multiple iterations.
Evolving product costs
Evolving product costs are sometimes referred to as acquisition costs or also initial costs. If you develop a digital product yourself or purchase it, these costs are cumulated here. So, the term means more than “acquisition.”
While the organisation actively creates and optimises the value being created, costs are generated.
For example, developer licenses for IDEs would go here. Their salary pack as well. And when it comes to salaries, as TCO is estimated usually over three years, salary evolution is also important. It doesn’t matter if the product is live or still in its infancy before launching the MVP.
Estimated technical debt is also cumulated here. Improving the product via DevSecOps, compliance with new regulations or engineering practices (to improve quality or reduce the cycle time, enhance architecture capabilities, or any other efficiency-related activity) also accumulate here as it implies evolving the product.
You might ask: Why technology stack mismatch isn’t in technical debt? Well, it could be unless it is big enough to be listed separately.
Evolving product costs vs maintenance costs
Many companies distinguish between the costs associated with evolving the product and maintenance costs. Why do they do this? In the case of procurement, acquisition also comes with some maintenance services that we want to see on different lines. In the case of development, organisations are structured to shift work from “active development” into “maintenance.”
Wearing my “lean development” hat, I can only discourage this approach. A product moving on from the active development stage into maintenance is a degrading product and a never-ending story. Handing over the work to a mutualised maintenance team might be a very ineffective way to keep the system up and running. The space of this article is too small to elaborate more on the topic.
Maintenance costs
When products switch to this stage, the team that did the work originally typically isn’t available anymore. The value delivered for the users will stop being optimised. If the system switches to this state, even if small investments are being made, like a new set of features, it shouldn’t be a reason to go back to earlier application lifecycle stages. Therefore, costs continue to cumulate to maintenance.
At this stage, products rarely progress in Maturity Models. The maintenance team in charge will either keep the status or allow the system to degrade. Whatever the efforts are to consolidate the product on these Maturity Models, costs cumulate here. The concept of the Maturity Model is the default way Pentalog engages with its customer to give visibility on how they stand on various IT axis.
Operational costs
Licenses for libraries integrated into the product also cumulate here. Backups or platform subscriptions are also part of operational costs.
Another interesting example is the usage of third-party services requiring their own subscriptions. For example, we’ve seen in a B2B scenario for an early-stage company where the product kept enough users around and where there was no room to develop reporting. A temporary solution was provided with secured access to slave storage for self-service BI. These tools usually require payment per user, so dedicated licensing was cumulated in operational costs.
Training the users or monitoring the system are also part of operational costs.
Support costs
Customer or user support, independent from their support level, along with the infrastructure and tooling required to sustain support processes, also cumulate in support costs.
Many successful products don’t have sophisticated support schemes. Therefore, this rubric may be left empty, and the required ad-hoc support could be cumulated in other columns. What matters more is to not lose these costs.
Decommissioning is usually a forgotten aspect of initial estimates. But done right, it can be hard and expensive. And depending on the organisation, decommissioning might refer not just to one but to a series of stages in a very long and costly process. Cleaning and anonymising data, shutting down servers, and adapting the operational process should also be included here.
Migrating users to a new system is usually part of evolving costs of the new initiative, even if it would be healthier to estimate roughly the budget from the start.
The next blog in this series will cover how to prepare for Total Cost of Ownership, how CTOs will approach TCO in different ways and the key benefits of thinking TCO.
***
If you or your CTO / technology lead would benefit from any of the services offered by the CTO Craft community, use the Contact Us button at the top and we’ll be in touch!
Subscribe to Tech Manager Weekly for a free weekly dose of tech culture, hiring, development, process and more.