Most water institutions have already bought a dashboard that nobody opens. It was demonstrated once, it was screenshotted for a report, and within a few months the people it was built for went back to the spreadsheet they trusted. This is common enough that a buyer commissioning a new system is usually not asking whether it can be built. They are asking why the last one failed.
The reasons are consistent across organisations, and almost none of them are about the interface. They are decided before any code is written.
It answers a question nobody was asking
The most common failure is that the system displays what the data could show rather than what someone needed to decide. This happens when a project starts from an available dataset instead of from a decision, which is the ordinary way these things begin: a monitoring programme exists, it produces numbers, somebody proposes visualising them.
The test is simple and uncomfortable. Name the decision, name the person who makes it, and name the day of the week they make it. If any of the three is vague, the dashboard will be built to be looked at rather than used, and being looked at is not a habit that survives a busy month.
The number underneath was never calibrated
A dashboard is a claim about the world, and people stop opening it the moment they catch it being wrong. Where a figure comes out of a model, the question is what that model was fitted against and how well it reproduced it. A groundwater level surface, a flood extent or a network pressure that has never been checked against a measurement is an opinion rendered in a nice typeface.
This is why calibration belongs in the same conversation as the interface rather than in a separate technical annex nobody reads. We build groundwater models and the systems that surface them together for that reason. When the number is challenged in a meeting, and it will be, somebody has to be able to say what it was tested against.
The data pipeline died and nobody noticed
Silent failure is the quiet killer of these systems. A logger goes offline, an API key expires, a file format changes upstream, and the dashboard keeps rendering the last values it received. Nothing breaks visibly. The chart still draws. It is simply no longer telling anyone about the present.
By the time somebody notices, trust is gone, and it does not come back on the strength of an apology. A system that is going to be relied on has to say when it is stale, and somebody has to receive that message. Freshness is a feature, not an operational detail.
It shows everything instead of one thing
Comprehensiveness is the instinct of the person building it and the enemy of the person using it. Every additional panel is defensible in isolation and the sum is a screen that requires a decision about where to look before it offers any help at all.
The systems that get opened daily tend to answer one question on landing and put the rest a click away. That is an editorial choice about what matters most, and it is uncomfortable to make, because it means telling a stakeholder that their metric is on the second screen.
It was built for the funder, not the operator
A dashboard commissioned as a project deliverable and a dashboard commissioned as an operating tool look similar in a specification and behave nothing alike in use. The first is optimised for a demonstration: broad coverage, visual impact, a story that reads well in a final report. The second is optimised for a Tuesday morning.
Both are legitimate. The failure is building the first while describing the second, which is what happens when the reporting requirement and the operational need are never separated during scoping. If the honest purpose is to evidence a programme, say so, and design something good at that instead.
The refresh cadence does not match the decision cadence
Real time is the most over-specified requirement in this field. It is expensive, it constrains the architecture, and for a great many water decisions it is irrelevant. An allocation reviewed monthly does not need a live feed. A reservoir operating rule revisited each season does not need one either.
Where it genuinely matters, it matters completely. A burst on a distribution network or a flood warning threshold is worth building the whole system around. The point is to decide which case you are in rather than defaulting to the expensive one because it demonstrates better.
Nobody owned it after handover
Systems decay without an owner, and the owner has to exist inside the institution rather than at the consultancy. That means somebody named, with time allocated, who knows what the system does and is expected to notice when it stops doing it.
This is rarely budgeted, because handover is treated as the end of the project rather than the start of the asset. A system with documentation, source code and no owner is a system that will be quietly retired within two years, and the next procurement will begin with somebody explaining that the last dashboard did not work.
Which of these is the buyer's to fix
Four of the seven are decided by the buyer before a supplier is even selected: whether the decision is named, whether the purpose is honestly reporting or operations, whether the refresh cadence is chosen rather than assumed, and whether anyone will own the thing afterwards. A supplier can raise all four and a good one will, but none of them can be fixed from the outside if the answer is no.
The other three, calibration, silent pipeline failure and the discipline to show one thing, are squarely the builder's responsibility and are fair grounds to judge a bid on.
Naming that split at the start is the single most useful thing a buyer can do, because it converts a vague fear about wasted money into a short list of decisions that belong to identifiable people. That conversation is where we start when we build a decision support system, and it is also most of what our consulting and modelling work is actually for.