Most companies that run projects have a dashboard graveyard. The module inside the ERP that nobody configured past the first month. The screen a consultant set up, which looked impressive in the demo and was never opened again. The Monday-morning PDF that still goes out to twelve people, none of whom have read it this year.
The failure is rarely technical. The charts render, the data loads, the colours are perfectly acceptable. These dashboards die because they were built to impress in a review meeting rather than to answer the question a manager actually carries into the office each morning — and attention goes only where the answers are.
So before any talk of charts and filters, it is worth naming that question. In project-driven companies it is nearly always the same one: where do all my projects stand right now, and which of them needs me today. A dashboard either answers that in seconds, or it joins the graveyard.
Why dashboards go unopened
A review-meeting dashboard is designed backwards. It starts from what would look comprehensive on a big screen — a dozen charts, a map, a wall of filters — and works back to whatever data can be found to fill it. It is optimised for the quarterly presentation, where it will be looked at for ten minutes, not for the daily decision.
The daily test is harsher than the quarterly one. A manager opens the screen with one question in mind, and either the answer is there immediately or it is not. If it takes three filters to find, they will not look twice. If the data turns out to be a week old, they will not trust it once.
There is usually a burden problem underneath. Many dashboards are fed by a weekly reporting ritual — someone at each site compiling numbers into a format that someone at head office re-compiles into slides. The screen is only as fresh as that ritual, which means it is always days behind the one question it exists to answer.
Either way, managers return to the method that has never failed them: pick up the phone and call the site. That is the real competition. A project dashboard is not competing with other software — it is competing with a phone call to the site engineer, which always produces a current answer, whatever else it costs.
The phone-call test
So that is the test we build to. Can a manager see where every project stands — progress, issues, updates — without calling the site? Not most projects but every project; not last week's position but today's. If yes, the dashboard earns a place in the morning routine. If not, no amount of visual polish will save it.
The test disciplines what goes on the first screen. Progress against plan, issues waiting on a decision, and the latest updates from each site — that covers the morning question. Anything beyond it has its place, but it belongs a click deeper, where it cannot slow down the first look.
Notice what the test leaves out. Nothing about how many charts, nothing about which technology, nothing about matching what another company's software shows. Those debates have consumed many dashboard projects, and not one of them decides whether the screen actually gets opened on a normal Tuesday.
The best dashboard is the phone call you no longer have to make.
The dashboard is only half the product
Here is what the review-meeting approach always misses: a dashboard is only as good as what the field feeds it. If site teams must fill long forms at a desktop after a long day, the data will arrive late, thin or invented. The head-office screen will then faithfully display fiction, and managers will sense it within a week.
That is why we build project tracking as a pair — a mobile app for site teams and a dashboard for management. The engineer records progress, raises issues and posts updates from the site itself, on a phone, in the flow of the working day. The dashboard at head office reflects it in real time.
The order of design matters. We shape the site team's two minutes first and the manager's screen second, because the second is entirely downstream of the first. Make the update effortless where the work happens, and the dashboard stops being a reporting chore stapled onto the week and becomes a live picture of the ground.
What the site team gets back
There is a payoff on the field side too, and it is what makes the system stick. When management can see status on a screen, they stop calling for it. The engineer who was interrupted several times a day for the same update now answers once, in the app, and gets on with running the site.
Status calls also have a way of multiplying. Everyone calls whoever answers fastest, so the same question ricochets around the project and the answers drift apart in the retelling. When updates flow through one channel, the question lands in one place, with a record — and every office reads the same version of the truth.
Issues gain the most. A problem raised on a call exists only in the memory of whoever took the call, and it escalates only if that person remembers. A problem raised in the app sits on the dashboard until someone deals with it. Attention stops depending on who happened to pick up the phone.
Start from the morning question
If you are considering a dashboard for your projects, resist starting from a features list. Start from the questions your managers ask every morning and count the phone calls your sites answer every day. The dashboard that replaces those calls will be opened daily. The one designed to decorate review meetings will not survive its first quarter.
That is how we approach it at Stedvio. We map how information actually moves through your organisation — who calls whom, who needs to know what, where the updates stall — and build the pair of tools that carries it automatically from field to head office. The busywork of reporting runs itself; your people keep their attention on the decisions.
Know where every project stands without a phone call. It is a modest-sounding promise, which is exactly why it holds. Dashboards fail by promising insight and delivering charts; this one promises only the answer to the morning's first question. A dashboard that reliably answers that question is the one that gets opened.