TCO Is Useless If You Don’t Know What You’re Really Buying
Article contents
Introduction
In ICT TCO procurement, the model is rarely wrong — it is built on the wrong perimeter. A financial services company signs a three-year contract with an enterprise cloud provider: licensing, support, infrastructure, the numbers are solid and the board approves. Eighteen months later, actual costs exceed the original model by 60%. There were no calculation errors, no hidden clauses discovered too late. The TCO was correct — it was simply measuring the wrong thing.
The Problem Is Not the Spreadsheet
In ICT procurement, TCO models are built on what you already know. Licence costs come from the vendor’s own quotes. Infrastructure sizing is estimated by the IT team. Support levels are defined in the contract. All of this is real — but the perimeter was shaped by the vendor.
What never makes it into the model is not difficult to calculate — it is difficult to see before it has already happened. The internal staff managing the contract day to day never appears in the TCO. Governance overhead — steering meetings, escalations, procurement time spent on routine contract management — never appears in the TCO. Migration costs at the end of the contract period, when lock-in clauses have fully matured, never appear in the TCO because at signing they look like a remote possibility.
Internal operational costs — dedicated staff, governance, monitoring, compliance — rarely feature in the initial proposal. Not because they are marginal, but because at the point of signing they are distributed across the organisation with no explicit owner. Nobody brings them into the model because nobody owns them.
In mid-complexity cloud contracts, this cost block can account for between 30% and 50% of the declared vendor price.
This is an estimate based on direct experience, not a third-party data point. The actual range varies depending on the maturity of the internal ICT team and the complexity of the integration. The precise percentage matters less than this: in most TCO models, this line item is zero.
This is where the TCO begins to diverge from reality — not on the licence fee, but on everything required to make it actually work.
Who Defines the Boundary
This is the part that rarely gets said clearly enough: the TCO boundary is almost always defined by whoever has an incentive to keep it narrow. The vendor presents a cost model optimised to make their solution look competitive. The line items that would enable an honest comparison — exit costs, integration complexity, mature technical dependency — do not appear in the proposal and are rarely added by the buyer.
As explored in the article on vendor lock-in, the dependency is not technical — it is economic. It consolidates in the months after signing, not at the point of selection. Procurement, for its part, tends to build the TCO around what is verifiable and defensible at the approval stage. Certain costs (licences, subscription fees) are easy to document. Uncertain or implicit costs (governance, downtime risk, accumulated technical debt) require assumptions that someone must own — and that someone might challenge.
The result is a TCO that is not wrong. It is simply incomplete by design.
The TCO boundary is almost always built by whoever has an incentive to keep it narrow. If you start from the vendor’s proposal and add line items from there, you are already working inside their model — not your own.
ICT TCO Procurement: What Changes When You Widen the Boundary
I built the ICT TCO Calculator — an open-source Python tool — specifically to make this mechanism visible on real data. It distributes spend across three levels: direct costs, internal operational costs, and hidden costs. The key output is the Invisible Cost Ratio: the share of indirect costs relative to the declared vendor price, expressed as a percentage.
In the preloaded synthetic scenario — a three-year enterprise cloud contract at €120,000 per year — the real TCO exceeds the declared cost by 106%. Hidden costs alone (exit fees, lock-in, migration, integration) account for €94,000 over the contract period. These are not invented figures: they are order-of-magnitude estimates consistent with mid-complexity cloud contracts.
The pattern is not isolated. The Flexera 2026 State of the Cloud Report finds that 29% of cloud spend is wasted every year — and the figure has started to rise again. Not because organisations lack the tools to measure it, but because they have not defined what to measure.
The point is not the final number. It is the question that number forces you to ask: have you already brought these line items to the negotiating table, or are you still only discussing the subscription fee?
Negotiating With the Right Boundary
Those who understand the problem change when they build the TCO — not just what goes into it. The model is built before the vendor conversation, not after. Instead of starting from the proposal and adding costs, you start from the real service lifecycle and map every cost category: direct, operational, hidden. The vendor is then invited to bring their numbers to a boundary you have already defined.
The model is built before the vendor conversation, not after. Instead of starting from the proposal and adding line items, you start from the real service lifecycle and map every cost category: direct, operational, hidden. The vendor is then invited to bring their numbers to a boundary you have already defined. This is also why procurement almost always arrives too late — when the cost perimeter has already been set by someone else.
As with aggressive negotiations that optimise price while increasing rigidity, the risk here is bringing the wrong number to the table — a TCO that excludes the costs that will surface in the twelve months after signing.
The second difference is temporal. The cloud spend predictability problem is not just about monthly variability: certain costs concentrate in years two and three of the contract, when lock-in has matured and alternatives are more expensive to pursue. A TCO that does not model this curve is not an analytical tool — it is an approval document.
TCO Is a Governance Tool, Not a Justification
The difference between a TCO that works and one that does not is not in the precision of the calculation. It is in who defined the questions before the model was built.
If the vendor defined the questions, the boundary serves the vendor.
If you defined them, the boundary serves the decision.
What is TCO in ICT procurement?
Total Cost of Ownership in ICT covers all costs tied to a contract or technology across its full lifecycle — not just the declared subscription fee, but also internal operational costs, governance, integration, training and exit costs. The most common failure is not a miscalculation: it is building the model on a perimeter that is too narrow.
What are the most common hidden costs in a cloud contract?
The most frequent are: early termination and data migration costs, internal governance overhead (ICT team and procurement time spent on contract management), integration complexity with existing systems, and the implicit cost of vendor lock-in, which matures in the months after signing. These costs rarely appear in the proposal — they almost always appear in the invoice.
How do you build a sound TCO before entering negotiations?
Start from the real service lifecycle, not the vendor’s proposal. Map three levels of cost — direct, operational and hidden — before opening any conversation with the supplier. This inverts the logic: the vendor brings their numbers to a boundary you have already defined internally, not the other way around.
Share this article