Skip to content

Operations dashboards

Operations Dashboard Consultant: Building the Screen Leadership Actually Uses

Most operations dashboards are built once, admired for a fortnight, then quietly ignored. The failure is rarely technical. It is that nobody decided what the screen was for, who owns each number, or which meeting it feeds. This page sets out how I design an operations dashboard leadership actually opens, and what earns a place on it.

By Ashish Kumar Agnihotri·Last reviewed

The pattern repeats across industries and tools. A leadership team asks for visibility. Someone competent builds a dashboard with thirty tiles, four filters and a date picker. For two weeks people open it. Then a number looks wrong, nobody can say who owns the definition, the argument moves to email, and the meeting goes back to slides. Within a quarter the dashboard is dead and the company is running on somebody's spreadsheet again. I have watched this happen in businesses with good data teams and expensive licences. The tooling was never the constraint. What was missing was a decision the dashboard existed to serve, and an owner for every number on it.

A dashboard is not a report and it is not an archive. It is a decision instrument: a small set of numbers that tells a leadership team, in under two minutes, whether the operating machine is behaving and where to point attention this week. That purpose imposes discipline. One screen, no scrolling. Five to nine metrics, which is the same size I use for an operations governance scorecard, because it is roughly what a group of tired executives can hold in their heads at nine on a Monday. Every metric compared against something — a target, last week, the same week last year — because a bare number carries no judgement. And every metric with a named human who answers for it.

I have spent nineteen years in operations, most recently as Senior Director, Business Excellence at Publicis Groupe, where quality and delivery ran across 500+ clients, teams of 2,000+ and more than USD 750 million in annual media spend. The reporting habit is older than that. Early in my career I built HR scorecards and business intelligence across 23 business units at Raymond, and ran reporting and audits covering 4,500+ retail stores across 19 telecom circles for Vodafone. Those were pre-modern stacks. They taught me the part that has not changed: a dashboard is only as good as the definitions and the cadence behind it. I work independently now, with companies between fifty and five hundred people.

In depth

What you need to know about operations dashboard consultant.

Why most operations dashboards are abandoned

Four causes account for nearly all of it. The dashboard was scoped as a data project rather than a decision project, so it answers questions nobody was actually asking. It contains everything the source systems could produce, on the theory that more is safer, which guarantees no one can tell signal from furniture. Its numbers do not reconcile with finance or with the operational teams' own trackers, so the first dispute destroys its authority permanently. And it is attached to no meeting: nothing in the company's week requires anyone to look at it. Any one of these is fatal. Most abandoned dashboards have all four. Notice that none of them is fixed by better visualisation, a different tool, or another round of stakeholder interviews about what people would like to see.

Start with the decision, not the data

Before anything is built I ask a blunt question: what decision does this screen change? Not what would be interesting to know — what will be done differently on Monday because of what it shows. If the honest answer is nothing, the metric does not belong. A useful discipline is to write, for each candidate number, the sentence that follows a bad reading. Utilisation is under seventy per cent, therefore we pause hiring in that pod. Rework is above threshold on two accounts, therefore those two go on the exception list this week. First-pass yield has slipped for three consecutive weeks, therefore we reopen the standard. Metrics that cannot complete that sentence are commentary. Commentary is not worthless, but it belongs in a monthly review pack, not on the operating screen.

What belongs on one screen

I build around four layers, with one to three metrics each. Flow: is work moving, and where is it queuing — throughput against commitment, ageing of the oldest open item, or a bottleneck load figure. Quality: what fraction of work is right first time, plus escaped defects that reached the client. Load: capacity against demand, so leadership can see strain before it becomes attrition or missed deadlines. Cash consequence: the operational number that finance feels, usually cycle time from delivery to approved invoice, or value stuck in dispute. Four layers, five to nine metrics, one screen. Everything else — the breakdowns by team, client, geography, week — sits one click beneath as drill-down, available when someone asks why, invisible until then.

Design rules that keep a dashboard honest

Six rules do most of the work. Every metric carries a comparison, never a bare figure. Every metric has a threshold, agreed in advance, so the screen tells you when something is wrong instead of leaving each viewer to decide. Every metric has one named owner, printed on the screen, because a number nobody owns is a number nobody fixes. Every metric shows its as-of timestamp, since a stale dashboard that looks live is worse than no dashboard. Colour means one thing only — within threshold or outside it — and is never decorative. And the definition of every metric is one hover away, in the same words the data dictionary uses. Dashboards lose credibility through small ambiguities, not large errors.

The dashboard exists to serve a meeting

A dashboard with no meeting attached will die, however well built. The reverse also holds: a weekly operating review with a shared screen changes behaviour within a month. So I design the two together. The screen leads the meeting; the meeting is short and follows a fixed shape. Read the exceptions, not the whole board. For each exception the owner states the cause and the corrective action with a date. Actions from the previous week are closed or explicitly rolled with a reason. Nothing else is discussed at the operating review — strategy, cases and deep dives go elsewhere. Two things follow. Owners begin checking their own numbers before the meeting rather than after, and the dashboard becomes the artefact everyone trusts because it is the artefact everyone is judged against.

Definitions, sources and the reconciliation problem

The technical build is the smaller half of the job. Before a single tile is drawn, each metric needs a written definition covering the numerator, the denominator, the inclusions and exclusions, the source system of record and the refresh frequency. Then it needs reconciling against whatever the business already believes. Somebody in finance has a revenue number, somebody in delivery has a volume number, and if the new dashboard disagrees with either, the dashboard loses. Reconcile first, publish second. Where the numbers genuinely differ, say so on the screen and explain why, in one line. I would rather ship a dashboard with six defensible metrics than twenty that provoke a monthly argument about whose export is correct.

Tooling, and why it matters less than you think

I stay deliberately tool-agnostic. Companies between fifty and five hundred people generally already own something adequate, and the failure modes I have described are not solved by migrating to a better platform. Two practical positions, though. First, build the first version in whatever your team can maintain without a specialist, even if that means a spreadsheet fed by a scheduled export — a dashboard nobody but a contractor can change will freeze the moment definitions evolve, and definitions always evolve. Second, do not automate a metric until its definition has survived a quarter of use. Automation makes a definition expensive to change, so automating early locks in the version you understood least well. Get the decisions and definitions right on a manual build, then industrialise the ones that have earned it.

How I work as an operations dashboard consultant

Engagements start with a fixed-fee diagnostic. I sit in the existing management meetings, read whatever reporting exists, trace three or four numbers back to their sources, and interview the people who produce them. The output is a specification: the decisions the dashboard must serve, the metrics that survive the tests, their definitions and owners, the sources and reconciliation gaps, and the meeting the screen will run. From there a monthly retainer scaled to scope takes it through build, first-quarter operation and handover — because the real work is not launch, it is the quarter afterwards when thresholds get argued about and owners learn to answer for their numbers. Never hourly; the incentive is wrong for work whose value is in restraint. I work with companies in India, the USA, the UK and Europe.

Questions

Common questions about operations dashboard consultant.

Five to nine on the main screen. That is the number a leadership team can hold in mind and genuinely act on in a weekly review, and it is the same size I use for an operations governance scorecard. Anything beyond nine and the eye stops discriminating; every metric becomes equally unimportant. This is not a limit on what you measure — teams may track dozens of operational figures — it is a limit on what reaches leadership's screen. Detail lives one click down as drill-down, surfaced when a headline metric breaches its threshold and someone asks why.

A dashboard supports a decision this week; a report explains what happened last month. The dashboard is short, thresholded, owned and read in a standing meeting. The report is longer, narrative, and read once. Companies get into trouble when they ask one artefact to do both jobs: the dashboard grows commentary tiles and historical charts until nobody can find the exceptions, and the monthly report gets stripped to numbers that lack the context to interpret them. Build both, keep them separate, and let the dashboard feed the report rather than duplicate it.

Usually because they answer no specific question, contain too much, do not reconcile with finance, or are attached to no meeting. The abandonment is almost never about the tool. The tell is a first dispute about a number that nobody can resolve, because no one owns the definition. Once a dashboard loses an argument in front of the leadership team, it rarely recovers authority. Preventing that is mostly upfront work: written definitions, reconciliation against the numbers the business already believes, named owners, and a weekly review that requires the screen to exist.

Whichever one your team can maintain without outside help. For companies between fifty and five hundred people the choice of platform is rarely the binding constraint, and migrating tools does not fix a definition problem. My practical advice is to build version one in something simple, run it manually for a quarter while the definitions settle, and only then automate the metrics that have proved stable. Automation makes definitions expensive to change, so automating first locks in your least-informed version of each metric.

One named person per metric, printed on the screen, and it should be the person who can actually change the number — not the person who produces the data. Data teams own the pipeline; operating leaders own the performance. When those two are confused, the review turns into a discussion about the accuracy of the report instead of the state of the business. Shared ownership is the same as no ownership. If two leaders genuinely both influence a metric, split it into two metrics or pick the one who is accountable for the outcome.

The build is usually the fastest part. Specifying decisions, agreeing definitions and reconciling against existing numbers takes a few weeks in most companies of this size. A first working screen can follow quickly after that. What takes a full quarter is adoption: thresholds get argued about, owners learn to answer for their numbers, and two or three metrics turn out to be wrong and get replaced. I plan for that quarter explicitly, because a dashboard handed over at launch is a dashboard handed over before anyone has had to defend a number on it.

Both, deliberately paired. Lagging metrics — delivered quality, cycle time, escaped defects — tell you what the machine produced and are what the board cares about. Leading metrics — queue ageing, first-pass yield at an early stage, capacity against booked demand — tell you what next month's lagging numbers will look like while there is still time to act. A dashboard of only lagging indicators is a post-mortem. One of only leading indicators loses its connection to outcomes anyone is accountable for. Pair each of the small number of outcomes you care about with one predictor you can move.

Reconcile before you publish, then keep reconciling on a schedule. Where operations and finance genuinely measure different things — recognised revenue versus delivered volume, for instance — do not force them to match; state the difference on the screen in one line, so the discrepancy becomes documented rather than suspicious. What destroys a dashboard is an unexplained gap discovered live in a meeting. The underlying fix is usually definitional ownership rather than data engineering: someone must be accountable for what each term means across the company, which is where a data governance workstream earns its keep.

The next step

A short conversation settles most of this — and a fixed-fee diagnostic settles the rest.

Call