ICT Procurement assumptions: Where Real Costs Hide
Article contents
Introduction
I work for a cloud provider. I regularly see companies approve ICT expenditure with business cases that look solid on paper. The root cause of most failures in this space isn’t the budget — it’s unverified ICT procurement assumptions that nobody wrote down.. The numbers add up, the budget is respected, and the vendor — often us — has addressed every point in the tender specification. A few months later, actual consumption diverges from the forecast, and no one can pinpoint exactly where the evaluation went wrong.
The calculation wasn’t the problem. The assumptions underpinning it were.
ICT Procurement Assumptions Nobody Writes Down
Every financial evaluation in the ICT space rests on a set of underlying assumptions: how many users will actually use the platform, how often, for how long, and with what intensity. These assumptions are rarely written down explicitly anywhere. They live in the heads of the people who built the business case, on slides shown to the board, and in some Excel spreadsheet that nobody will ever update.
The problem isn’t that assumptions exist — making them is unavoidable. The problem is that when they remain implicit, they cannot be challenged, revised, or compared against reality. When something doesn’t add up, there is no reference point to return to. The only thing that remains is the signed contract.
This is a pattern I see repeat itself: a business case is built on adoption rates that nobody has ever committed to in writing. When actual usage diverges — and it almost always does — the contract is technically correct, the prices were competitive, but the entire economic model was built on a shared expectation rather than a verifiable assumption.
When the Assumptions Aren’t Even Yours
There is a second, more uncomfortable layer to this. When assumptions do get made explicit — and it does happen, particularly in more structured procurement processes — they are often not built internally. They are the estimates provided by the vendor: usage projections, industry benchmarks, adoption scenarios. Data presented with authority, often difficult to verify independently, and almost always designed to support the purchase.
The vendor arrives at the table with the numbers. You arrive with impressions. Vendor projections start from a specific commercial interest and from aggregated market data that may not reflect your organisation’s context at all. The result is a financial evaluation that looks robust but rests on foundations that don’t belong to the people who will have to live with them.
A usage projection provided by a vendor is not a neutral forecast. It is an estimate built by someone with a commercial interest in the sale, based on aggregated market data that may not reflect your specific context. Accepting it as an input without internal validation is one of the most underestimated risks in ICT procurement evaluations.
By the Time You Know, It’s Too Late
The most critical issue isn’t that the assumptions were wrong. It’s that the system provides no real mechanism to verify them before they become contractual constraints. ICT contracts are evaluated at the point of signature. Revision clauses exist, but they are rarely negotiated and even less frequently activated. Operational monitoring — when it exists at all — measures consumption and technical performance, not deviation from the original assumptions.
By the time real data emerges clearly — after nine, twelve, or eighteen months — the contract is already running. The vendor has been paid, the team has moved on to other priorities, and renewal is approaching. The only remaining lever is negotiating the next cycle, often from a position of weakness because dependency has quietly been established in the meantime.
ICT procurement is structured to evaluate at the point of purchase. It is not structured to learn during execution. That gap — between the decision and its verification — is where most of the waste accumulates that no one can trace back to a precise cause.
Those who manage this well treat ICT procurement assumptions as first-class artefacts: written down from the outset, shared with a named owner, and tied to a specific review date. — written down, shared, with a named owner — and define when and how those assumptions will be compared against real data.
A minimal example: “Expected adoption 70% within 6 months — owner: IT Manager — review: Q2.” Three fields, one owner, one date. That’s all it takes to make an assumption verifiable.
The contract is not the endpoint of the evaluation. It is the moment you lose the ability to correct it. That is why assumptions must be written down beforehand — not to be right, but to be wrong in a way that can be learned from.
Further Reading
- Digital procurement, cloud and ICT data: the real picture
- When a KPI lies: what procurement numbers don’t tell you
- Gartner — IT Spending Forecast (press release)
Why do ICT projects almost always exceed the planned budget?
In most cases the calculation isn’t wrong — the initial assumption is. Adoption rate, usage volumes, actual duration: these are rarely written down explicitly and almost never verified during contract execution.
How do you avoid basing an ICT evaluation on vendor projections?
The starting point is building an internal set of explicit assumptions — with a named owner and a verification date — before comparing them against vendor estimates. Not to challenge the vendor, but to have an independent reference point for negotiation.
When is the right time to verify the assumptions in an ICT contract?
Not at renewal — by that point the contract is already running and leverage is limited. The useful window is between six and twelve months from go-live, when real usage data is available but the vendor has not yet consolidated its renewal position.
Share this article