A weekly project dashboard is open on the screen. Overall status: amber. Budget: 73% consumed. Progress: 68%. Five open risks, three milestones slipped. Every number is accurate — and the person looking at it still cannot say what should happen next.
That gap is the difference between a dashboard that reports information and one that helps control a project. A useful project dashboard does not compress a status report into charts. It makes deviations visible, surfaces emerging problems and makes the decisions it needs from the reader hard to miss.
Build a project dashboard designed to highlight decisions and early warnings, not just status. The test is not whether it shows the current state, but whether it helps someone see what matters early enough to act.
What a project dashboard should actually do
The PMI Lexicon of Project Management Terms defines a dashboard as a set of charts and graphs showing progress or performance against important measures of the project. That is a fair starting point, but a management dashboard has to do three things.
- Establish the current state of the project.
- Show direction — whether that state is improving or deteriorating.
- Point to where attention or a decision is required. This is the part many dashboards miss.
An older PMI paper on digital dashboards for reporting performance already framed the idea: a dashboard should give at-a-glance views of critical data pulled from different systems, including warnings, action notices and summaries of project conditions, and let the reader drill down when needed. The same paper is blunt about what makes or breaks it — success depends mostly on selecting the right measures, not on displaying as many measures as possible.
Status versus decisions: the same data, read two ways
Consider two dashboards built from the same project data.
| Area | Status |
|---|---|
| Schedule | Amber |
| Cost | Green |
| Risks | 7 open |
| Scope | Green |
| Signal | Status | Trend | Decision required |
|---|---|---|---|
| Critical milestone | 12 days late | Worsening | Approve the recovery plan |
| Forecast cost at completion | +4% | Worsening | None yet — review next cycle |
| Key supplier risk | High | Worsening | Decide on the alternative supplier by Friday |
| Scope | Stable | Stable | None |
Both contain project data. Only the second tells the reader where management attention belongs.
Status is not the same as control
Traditional reporting describes what has already happened. Control requires comparing what happened with what was expected, judging whether the difference matters, and deciding whether to act. PMI's guidance on monitoring and controlling frames the work as turning the information gathered during execution into actionable knowledge — deciding when a variance warrants corrective action and when the project should be allowed to continue unchanged. In that framing, a project issue is an observed variation from an expected result that affects a key performance indicator.
A dashboard built for control needs to connect four things.
Without that chain, a metric is often just decoration. "Schedule variance: −8 days" is information. "The critical milestone is eight days behind baseline, the gap has widened for two reporting periods, and recovery now needs either more resources or a scope decision" is management information. The second version changes the conversation.
Which information matters most
There is no universal dashboard. The right measures depend on the decisions that have to be made. In practice a project dashboard usually needs to make some combination of these visible:
- Delivery: milestones, progress, schedule variance and forecast completion.
- Cost: actual cost, committed cost, forecast at completion and material variances. Cost data is often where the lag between real spend and the plan-versus-actual view hides a problem until it is expensive.
- Scope: approved changes, pending changes and emerging scope pressure.
- Risk: top risks, exposure, trend and whether mitigation is working.
- Issues: unresolved issues, their age, severity and escalation status.
- Dependencies: critical external or cross-team dependencies and any change in their status.
- Decisions: decisions required, their owner and the date they are needed by.
The last category matters most. If a dashboard shows ten red indicators but never states whether a decision is required, it hands the interpretation back to the reader. Choosing measures that each point to a decision is the same discipline behind metrics that reveal decisions and exceptions rather than volume.
Show the direction of travel
A static status can mislead. An amber project improving quickly and an amber project deteriorating quickly should not trigger the same response.
Haringey Council's corporate delivery-plan performance framework pairs each RAG rating with a "direction of travel" column. Its criteria treat an amber rating whose metrics are "showing progress in the right direction" as a different situation from a red rating with "a negative direction of travel overall", and its guidance stresses keeping the latest metric values and the direction-of-travel column up to date so trends — not just today's colour — can be examined and challenged. Do not only answer "Where are we?" Answer "Where are we heading?" A small trend indicator often carries more management value than another detailed chart.
Use data you can verify
Dashboards become dangerous when a polished visualisation sits on weak source data. When the UK Government Digital Service described building the GOV.UK programme dashboard, in its post on what it learnt about scaling agile, it aggregated progress, scope completeness and delivery-date forecasts from verifiable data that teams produced through their day-to-day work — not from a manager's subjective status report.
That does not remove human judgement. Some risks, dependencies and stakeholder problems cannot be reduced to an automated metric. But the closer an indicator sits to observable project data, the more the dashboard can be trusted — and the dashboard should still make clear which entries are observed data, which are forecasts, which are management judgement and which are assumptions.
Build early warnings into the dashboard
Most teams know when a project is badly late. The harder problem — the job of project monitoring — is catching the weak signals while there is still time to react. Useful early-warning indicators include:
- repeated milestone slippage;
- shrinking schedule contingency;
- unresolved issues getting older;
- rising change volume;
- mitigation that is losing effectiveness;
- a growing forecast variance;
- decisions that keep being deferred;
- dependencies approaching critical dates;
- resource assumptions that keep failing.
The goal is not to build a risk engine. It is to make deterioration visible before the final KPI turns red. A PMI-funded study of early warning signs in complex projects found that emerging problems often start early but show only weak signals, and that current practice is weak at both picking those signals up and acting on them. The same pattern — many small signals that only matter in combination — is why complex projects fail even under a structured PMO. An effective dashboard should not only display outcomes; it should expose the conditions that produce them.
A practical dashboard structure
A decision-oriented dashboard can be compact. Six blocks are usually enough.
1. Overall project health
Keep the headline status, but explain it. Not "AMBER" but "AMBER — milestone recovery depends on a supplier decision by 4 September."
2. Key deviations
Show only material differences from plan. For each: baseline, actual or forecast, variance, and trend.
3. Early warnings
Indicators that are not yet failures but are deteriorating.
4. Top risks and issues
Prioritise exposure and the action required, not the count of open records.
5. Decisions required
This deserves its own block.
| Decision | Needed by | Impact if delayed |
|---|---|---|
| Approve supplier B | 4 Sep | +3 weeks of schedule exposure |
| Release contingency | 9 Sep | Recovery plan cannot start |
6. Forecast
Do not stop at today's status. Show where the project is expected to finish if nothing changes — and be clear that a forecast is not the same as a verified earned-value number.
The thirty-second test
Open your current dashboard and give yourself thirty seconds. Can you answer:
- What changed?
- What is getting worse?
- What could become critical next?
- Where is management action required?
- What happens if no action is taken?
If the answers need another meeting, another spreadsheet or a ten-page status pack, the dashboard is presenting data rather than creating visibility. A PMI article on effective status reporting makes a related point: the report should be concise enough for a decision-maker to read, with a short summary that tells them whether they need to go deeper, and links to the detail for those who do. A dashboard should work the same way. Signal first. Detail second.
From project dashboard to decision system
A dashboard is not valuable because it contains charts. It is valuable because it shortens the distance between something changing in the project and someone noticing and acting on it. The next step for most teams is to combine current state, trend, forecast, early warnings and decisions required into one management view. When that view is built for leadership rather than the delivery team, it becomes an executive project dashboard: the same signals, filtered to the decisions only leadership can make.
So the question to ask about your dashboard is not "Does it show the project status?" It is: does it help us see what matters early enough to act?
Sources
- PMI — Lexicon of Project Management Terms — definition of "dashboard".
- PMI — Tools for managing projects: digital dashboards to report performance — at-a-glance views with warnings and action notices; success depends on selecting the right measures.
- PMI — How do you know the status of your project? — monitoring and controlling as turning execution data into decisions; an issue as an observed variation from an expected result affecting a KPI.
- Haringey Council — Corporate Delivery Plan: RAG assessment criteria and direction of travel — pairing status with a direction-of-travel column.
- Government Digital Service — What we've learnt about scaling agile — the GOV.UK programme dashboard built from verifiable delivery data rather than subjective reporting.
- PMI — Early warning signs in complex projects: project failure — emerging problems start early with weak signals that practice struggles to detect and act on.
- PMI — Anatomy of an effective status report — concise reporting with a summary first and detail on demand.