An operational dashboard is the small set of indicators that tell you whether delivered work is behaving in production, each with a named owner and a defined response at a stated threshold. It is a standing instrument of the Learn practice rather than a reporting exercise: it exists so that a change in something you shipped reaches a specific person fast enough for them to act. Before you build one, settle the only question that makes it useful. What number, at what value, causes whom to do what?
How does an operational dashboard work?
An operational dashboard works by pairing every indicator with a threshold and a response, so that reading it produces an action rather than an impression. Each row has three parts: the measure (what is counted, and where the number comes from), the threshold (the value that means something has changed), and the response (who is told, what they do, and how fast). Remove any one of the three and the row stops functioning. A measure with no threshold is trivia. A threshold with no response is an alarm nobody is obliged to answer. A response with no owner is a suggestion.
The indicators fall into two groups worth keeping separate. Leading indicators move first and buy you time: queue depth, error rate, people abandoning a new flow partway through, the share of transactions taking the manual fallback path. Lagging indicators confirm the result and are what the value realization review later reads: cost per transaction, turnaround time, retention, volume handled per staff member. Both belong on the dashboard, but they are read on different rhythms. Leading indicators are watched weekly by the operational owner. Lagging indicators are read at the portfolio review, where nobody should be surprised by them.
What belongs on an operational dashboard, and what does not?
Keep it to the indicators that would change someone's behavior this week, plus the ones that confirm the objective the work was approved on. For a single initiative that is usually five to nine rows. Past that, the dashboard is being used as a data catalogue.
Include:
- The one or two measures the initiative's measurable objective was written against, with the pre-release baseline beside them.
- Operational health for the system that was handed over: availability, error rate, and the size of whatever backlog the system feeds.
- Adoption, whenever the benefit depends on people using the thing. A feature almost nobody has taken up cannot move a portfolio number, and the dashboard should say so before the review does.
- Support load: tickets attributable to the release, and how long they sit.
Leave off anything nobody has agreed to act on, anything already visible in a team's own tooling, and anything that needs a person to assemble it by hand each week. A number somebody re-keys from a spreadsheet stops being current the week that person takes leave.
What does a good operational dashboard look like?
A good dashboard starts from the objective the initiative was approved on, with its baseline, and adds the early warning signs the operational owner would actually watch for. Every row has a number that means something has changed, one named person who acts when it is crossed, and a data source that refreshes without anyone re-keying it. Reading it produces a short list of things to do, not a general impression, and rows that nobody has acted on in a few months get removed.
If you cannot say who acts and what they do when a number crosses its threshold, leave the number off. Rows that exist only to be shown accumulate faster than rows that exist to be acted on, and they are what teaches people to stop reading. When a response is needed and the fix is not urgent, it lands on the improvement backlog.
What does an operational dashboard look like in practice?
Take a hypothetical county permitting agency that has replaced a paper intake with an online application. The approved objective is to cut median time from application to first decision from 21 days to 10, measured 90 days after go-live. Its dashboard holds six rows: the turnaround measure itself, the share of applications arriving online, applications returned as incomplete, portal errors, support tickets, and staff hours spent on manual re-entry, each with a named owner and a response.
The online share is the row that earns its place. Median turnaround looks fine at day 30, because only the straightforward applications are arriving online. The online share sits well below target, which means the number the initiative was approved on is being measured on a favorable subset of the work. That is visible weeks before the value review, which is enough time to do something about it.
What goes wrong with operational dashboards?
The failures are predictable.
Building it after go-live. The instrumentation you need is cheap during development and awkward to retrofit. Specify the indicators during Focus, at the same time as the objective.
Reporting availability instead of outcome. Green infrastructure metrics tell you the system is up. They say nothing about whether it is producing the result it was funded for, and a dashboard made only of them will read healthy for a year on an initiative that changed nothing.
Setting thresholds to whatever the number currently is. That guarantees the dashboard never triggers. Set thresholds against the objective and the pre-release baseline instead.
Team ownership instead of person ownership. "Platform team" is not an owner. Rotations are fine, as long as the roster resolves to a name on the day.
No expiry. Rows outlive the initiative that created them and nobody removes them. Review at 60 to 90 days and cut.
Operational dashboard vs status report vs steering-committee deck
These three get confused because they often carry the same numbers. They differ in who acts on them, and how quickly.
| Operational dashboard | Status report | Steering-committee deck | |
|---|---|---|---|
| Question it answers | Is the delivered thing behaving? | Is the work progressing to plan? | Should the investment change? |
| Time horizon | Now, continuously | The last reporting period | The next decision cycle |
| Read by | The named operational owner | Delivery leads and the PMO | The investment decision authority |
| Action it produces | A defined response at a threshold | A correction to the plan | Scale, sustain, or retire |
| Lives for | As long as the system runs | As long as the project runs | One meeting |
A status report covers work in flight and stops when the project closes. An operational dashboard starts at the hand-off and runs as long as the system does. A steering deck is a decision instrument, and it should be assembled from the dashboard rather than built in parallel with it. If the deck contains numbers the dashboard does not, somebody is recomputing, and the two versions will disagree at the worst possible moment.
This vocabulary sits inside the wider set in agile portfolio management terms. Specifying a first dashboard against a real objective is part of a PPM4Agile implementation, and it is normally the cheapest piece of the Learn practice to put in place, because most of the underlying data already exists somewhere in the organization.