Perfect Dashboards, Wrong Decisions: Where the Process Breaks
Article contents
Introduction
The meeting lasts forty-five minutes. The dashboard is projected on the wall, the charts are clean, the colours are right. Everyone looks at the numbers. Nobody questions what they measure. The contract gets renewed. Three months later it emerges that the real costs were double what the dashboard showed. The dashboard had not lied. It had shown exactly what it was asked to show. The problem had already happened — when someone decided which questions to ask.
The link between dashboards and wrong decisions rarely lies in the data itself. It lies in the moment before — when someone chose what to measure.
The Dashboard Shows What You Asked It to Show
Every dashboard begins with a moment when someone filled in a form, wrote a specification, or answered the question: “What do you want to see?” At that point, the KPIs are selected, the update frequency is set, the comparison baseline is fixed, and the data perimeter is defined. The dashboard read in the meeting is a faithful answer to those choices — not an objective photograph of reality.
The problem is that the original moment gets forgotten. The dashboard becomes “the data.” It gets read as if it were neutral, as if it showed everything worth knowing. And when the numbers are green, the decision seems obvious — even if those green numbers are answering the wrong questions. As explored in the analysis on decision context in procurement, whoever builds the information perimeter implicitly controls the space of available answers. A dashboard built on metrics the vendor proposed is not a control tool — it is a confirmation tool.
The dashboard does not lie. It shows exactly what it was asked to show. The problem is that nobody remembers who asked the questions — or why.
Perfect Dashboards, Wrong Decisions: Where the Process Breaks
The process breaks at three precise moments — rarely at the point when the report is actually read.
The first is KPI selection. Who chose them, using what criteria, in what context? In many organisations, contract KPIs are defined during the implementation phase, when the vendor is still present and helping configure the system. This is the moment the dashboard gets set up — and the moment the vendor has the strongest interest in proposing metrics that showcase its own platform. If procurement was not in that room, it missed the moment that mattered.
The second is the baseline. Every variation is measured against a starting point. If the baseline was set during a favourable period — a quarter with high utilisation, a period without incidents — the dashboard will always show positive performance, regardless of what happens afterwards. In a three-year cloud contract, a baseline fixed in the go-live quarter — when volumes are still low and operational issues have not yet surfaced — can render invisible a 20 to 30 per cent deterioration in real performance in subsequent quarters. The baseline is almost never renegotiated during the contract.
The third is the data perimeter. A cloud service performance dashboard includes response times, availability, throughput. It does not include the internal team time spent managing operational exceptions, the cost of workarounds needed to keep the service aligned with business processes, or the technical debt accumulated in configurations. These items are absent not because they do not exist — but because nobody asked for them.
A concrete case illustrates this well. In a contract review I was involved in, the dashboard showed indicators fully in line with the agreed SLAs. The vendor met every contractual metric. What the dashboard did not show was the time the internal team spent each week managing operational exceptions and manual activities required to keep the service aligned with business processes. Formally, the service was working. Operationally, it was consuming far more resources than the reports suggested. The dashboard was accurate. The measurement perimeter was incomplete.
The Decision Happens Before the Meeting
The meeting where the dashboard gets reviewed is not where decisions are made. It is where decisions already made — implicitly, upstream, when someone chose what to measure — get ratified. Whoever understands this changes their point of intervention. They do not wait for the meeting to ask questions about the numbers. They intervene earlier: when KPIs are being defined, when the baseline is being set, when the data perimeter is being agreed. At that point the variables are still open. In the meeting, they no longer are.
This follows the same logic explored in the analysis on procurement that fails on assumptions: the assumptions driving the decision are made before the formal process begins. Those who are not present when they are made always work inside a perimeter that others have already defined. The ICT Spend Analysis Dashboard is built on a different perimeter from the one vendors typically propose: it distributes spend across real cost categories — direct, operational, hidden — rather than by contract line item. The data is the same. The questions it generates are different. And those questions lead to a different meeting.
A perfect dashboard built on the wrong questions produces wrong decisions with remarkable precision.
Perfect Dashboards, Broken Processes
The problem is not the technology. It is not data quality, update frequency, or chart clarity. The problem is structural: the process that feeds the dashboard was designed by someone, at a specific moment, with specific incentives. If that process is never challenged, the dashboard will improve over time — and the wrong decisions will become increasingly precise.
Further reading
Why can a perfect dashboard lead to wrong decisions?
Because the dashboard shows exactly what it was asked to show. If the KPIs, the baseline and the data perimeter were chosen on the wrong criteria — or by someone with an interest in keeping them narrow — the dashboard will be technically flawless and informationally misleading.
Where does the decision-making process break down in an ICT contract review?
At three precise moments: when KPIs are selected (often during implementation, with the vendor present), when the comparison baseline is fixed, and when the data perimeter is defined. All three precede the meeting — and by the time the meeting starts, nothing is really being decided any more.
How can procurement build a more useful ICT dashboard?
By starting from the real cost perimeter, not the one the vendor proposes. Include internal operational costs, governance overhead and vendor dependency — not just contractual KPIs. And above all, be present when the questions are defined, not only when the numbers are read.
Share this article