Procurement Decision Context: Who Builds It Controls It
Article contents
Introduction
In ICT procurement, the decision context is the variable nobody manages deliberately — yet the report arrives every month, the charts are clean, the numbers updated, and when a real decision needs to be made the report never quite gets you there. The data is not the problem. The context is. And almost always, that context was built by someone else — with different questions, serving different interests.
The Problem Is Not the Dashboard
Every report answers the questions of whoever commissioned it. If the vendor requested it, it answers the vendor’s questions: usage, volumes, platform growth, comparison against a benchmark the vendor chose. If the CFO commissioned it, it answers the CFO’s questions: total spend, year-on-year variance, deviation from the approved budget. Procurement reads both — and always works inside an information perimeter that someone else designed.
This is not negligence. It is how data production works inside organisations. Whoever commissions the report decides which questions can be asked. Whoever does not commission it reads answers to questions they never chose. In this structure, data is never neutral. It is always the result of a decision about what to measure, at what frequency, against which baseline. A vendor presenting a performance dashboard has already decided what enters the calculation and what does not. The benchmark it uses is the one that favours its own position. Exceptions are excluded by design.
Accurate data built on the wrong perimeter produces the wrong conclusions. The problem is not the quality of the number — it is the quality of the question that generated it.
What “Context” Actually Means in Practice
Context is not supplementary information to be found in a second report. It is the history that turns a number into a signal. Is a 73% utilisation rate high or low? It depends on what was expected, when the service was activated, how many users were planned in the original model and how many actually came on board. Without that history, 73% is a number. With it, 73% is either a signal of underutilisation or confirmation of normal adoption.
As explored in the analysis on KPIs that mislead in procurement, data can be calculated correctly and still lead to the wrong decision — because it measures the right thing in the wrong context. The issue is not the KPI itself. It is that the KPI answers a question someone else formulated, against a baseline someone else chose. The same logic applies to the assumptions behind every analysis. ICT procurement does not fail on costs — it fails on assumptions: when the analytical perimeter is already set by others, the implicit assumptions holding it up are never questioned, because they are never visible.
As the Harvard Business Review noted, competitive advantage in data does not come from the volume of information available — it comes from the quality of the questions an organisation is able to ask.
Procurement Decision Context: Who Builds It Controls the Outcome
This is the part that rarely gets named explicitly. Whoever defines the questions a report answers implicitly controls the space of available responses. Not necessarily through manipulation — often through structural incentives that nobody consciously decided. The vendor produces data that demonstrates the value of its platform. That is its job. IT produces reports that show the stability of the systems it manages. That is its incentive. The CFO produces analysis that demonstrates budget control. That is its performance metric. Everyone builds context within their own perimeter of responsibility.
Procurement working solely on this data is not analysing reality — it is reading reality filtered through the incentives of others. And when it makes a decision based on that reading, the decision is already shaped by whoever built the context. As shown in the ICT TCO procurement analysis, the perimeter that determines what you measure matters more than the precision with which you measure it. A TCO built on the line items the vendor chose to include is not an analytical tool — it is a confirmation of the proposal the vendor already made.
The data is never missing. What is missing are the right questions — the ones nobody else had an interest in asking before you.
How to Build Your Own Context
This is not about collecting more data. It is about deciding which questions to ask before opening the report. The operational difference is precise: instead of starting from the data and looking for an interpretation, you start from the hypothesis you want to test and build the data you need to do so. If a cloud contract is up for renewal, the question is not “how is the service performing?” — that is the vendor’s question. The question is: “Has the real operational cost of this service, including internal governance and integration costs, stayed within the original expectations?” These are two different analyses. They produce two different contexts. They lead to two different negotiations.
The ICT Spend Analysis Dashboard is built on exactly this logic: not aggregating spend the way the vendor reports it, but distributing it across real cost categories — direct, operational, hidden — on the perimeter that makes sense for the person making the decision, not the person justifying the contract. The data is the same. The context around it is different. And that difference is everything.
Whoever builds the context decides what is visible. Whoever reads someone else’s context makes decisions inside a space that others have already defined.
Data Is Never Missing. The Right Questions Almost Always Are
The information problem in ICT procurement is not technical. Tools are not missing, dashboards are not missing, data feeds are not missing. What is missing is the moment when someone stops to decide which questions the data should answer — before the report is produced, not after. Anyone managing technology contracts without building their own context is always reading reality through the filter of whoever had an interest in producing that data. And making decisions that look informed, but are already shaped by whoever built the questions.
Why is data never enough to make decisions in ICT procurement?
Because every data point is the result of questions someone chose to ask —
and whoever commissioned the report chose those questions based on their own
incentives. The vendor produces data that demonstrates the value of its service.
IT produces reports on the stability of the systems it manages. Procurement
reads answers to questions that others formulated.
What does “context” mean in ICT data analysis?
Context is the history that turns a number into a signal. Is a 73%
utilisation rate high or low? It depends on the original expectations, the
chosen baseline, and the point at which it is measured. Without that history,
the data point is accurate but uninterpretable. With it, it becomes the basis
for a decision.
How can procurement build its own information context?
By starting with questions before opening the data. Not “how is the service
performing?” — that is the vendor’s question — but “has the real operational
cost of this service stayed within the original expectations?” These are
different analyses, they produce different contexts, and they lead to different
negotiations. The data is the same: what changes is who decided what to measure.
Share this article