Project Controls Dashboards: How to Build Cost and Schedule Dashboards That Drive Decisions
On most capital projects, the cost and schedule data already exist. The problem is rarely a shortage of numbers — it is that the numbers sit in separate systems, get assembled by hand into a 40-page monthly pack, and reach decision-makers two weeks after the period they describe. By the time the variance is visible, the window to act on it has closed. A project controls dashboard exists to fix exactly this gap: to turn cost, schedule, and risk data into a small set of signals a project director can read in two minutes and act on the same day.
This article covers how to build a dashboard that earns its place in the decision cycle: what distinguishes a dashboard from a report, the data architecture that keeps it trustworthy, the cost and schedule metrics that belong on it, the layout principles that make it readable, and the tooling and governance that keep it current. The aim is a dashboard that drives decisions — not a prettier version of the same data dump.
A Dashboard Is a Decision Tool, Not a Report Dump
The most common failure in project controls reporting is confusing completeness with usefulness. A monthly cost report is a record — it documents everything for audit and contractual purposes. A dashboard is an instrument — it answers a small number of decision questions at a glance. The two serve different purposes, and a dashboard that tries to be a report ends up being neither.
A useful dashboard starts from the decisions it must support, not the data available. For a project director those are typically: are we on track to finish on budget, are we on track to finish on time, what is moving against us this period, and where do I need to intervene. Every tile on the dashboard should map to one of those questions. If a number does not change a decision, it belongs in the detailed report, not on the dashboard.
This is why exception-based design matters. Rather than showing all 200 cost accounts, the dashboard surfaces the handful breaching threshold — the control accounts where the cost performance index has dropped below 0.95, or where the forecast has moved more than 2% since last period. The dashboard draws the eye to what needs attention and keeps everything else one click away.
If a number does not change a decision, it belongs in the detailed report, not on the dashboard. The discipline of a good dashboard is what it leaves out.
The Data Layer: One Source of Truth
A dashboard is only as credible as the data behind it. The fastest way to lose an audience is to present a number that contradicts the cost system, or to have two dashboards in the same meeting that disagree. Before any chart is designed, the data architecture has to be settled: every figure on the dashboard must trace to a single, governed source.
On a capital project that source is an integrated controls data model fed from three feeders — the cost system or ERP for committed and actual cost, the planning tool for schedule progress and dates, and the risk register for exposure and contingency drawdown. These are reconciled into one structured layer that the dashboard reads from, rather than the dashboard pulling raw extracts from each system independently.
The hard part of this layer is structural alignment. The schedule is organised by the work breakdown structure; the cost system is organised by the cost breakdown structure. Unless the two are mapped at the control-account level, cost and schedule cannot be shown side by side without manual stitching. Mapping the WBS to the CBS once, in the data model, is what allows earned value to be calculated automatically and the dashboard to refresh without a person reconciling spreadsheets each month.
Equally important is a single definition of each metric. “Forecast at completion” must mean the same calculation everywhere it appears. When definitions live in the data layer rather than in each analyst’s spreadsheet, the dashboard stays internally consistent and survives a change of personnel.
The Metrics That Belong on a Project Controls Dashboard
A project controls dashboard should carry a small, balanced set of cost and schedule indicators, plus the forward-looking measures that show where the project is heading rather than only where it has been.
Cost performance
- Cost performance index (CPI). Earned value divided by actual cost — the headline efficiency measure, with a trend line, not just a single period value.
- Estimate at completion (EAC) and variance at completion (VAC). The forecast final cost against budget, the single number that answers “will we finish on budget”.
- Commitment and expenditure curves. Budget, committed, and actual plotted as S-curves so the gap between commitment and spend is visible.
- Contingency drawdown. Contingency remaining against contingency forecast to be needed — an early warning that is often missing.
Schedule performance
- Schedule performance index (SPI) and float trends. Progress efficiency alongside critical-path float erosion, which often signals trouble before SPI moves.
- Milestone variance. Key dates baselined versus forecast, shown as days early or late, not buried in a Gantt chart.
- Progress S-curve. Planned versus actual percent complete, with the divergence highlighted.
The discipline is restraint. Eight to twelve well-chosen indicators carry more signal than fifty. Each should show a trend and a status against threshold, because a single-period number tells you where you are but not which way you are moving — and direction is what drives intervention.
Layout and Visual Design Principles
Layout is not decoration; it is how the dashboard guides attention. The strongest signals go top-left, where the eye lands first: the two or three KPIs that summarise overall cost and schedule health, expressed as a value, a trend, and a status colour. Supporting charts sit below, and detail tables — if present at all — go last or behind a drill-down.
Use colour as a status signal, not as decoration. Reserve red, amber, and green for threshold breaches against agreed tolerances, and define those tolerances explicitly so the colour is objective rather than an analyst’s judgement. When every chart is brightly coloured, nothing stands out; when colour is reserved for exceptions, the eye goes straight to what matters.
Match the view to the audience. A project director needs the one-page health summary; a cost engineer needs the control-account detail behind it; a steering committee needs portfolio roll-up across projects. The same data model should drive all three as tiered views, rather than each audience receiving a separate, hand-built deck that drifts out of sync with the others.
Tooling, Refresh, and Governance
Most teams build dashboards in a business-intelligence tool — Power BI, Tableau, or an equivalent — sitting on top of the integrated data model. The tool matters less than the connection beneath it. A dashboard wired directly to the cost system and planning tool refreshes itself; one rebuilt by hand each month is a report with charts, and it will fall behind the moment the analyst is on leave.
Refresh cadence should match the decision cadence. Cost actuals may only update monthly, but commitments, schedule progress, and risk often move weekly — and the dashboard should refresh on the faster cycle so it never shows the project as it was a month ago. Pair this with light governance: a named owner for the data model, version control on metric definitions, and a documented source for every tile so any figure can be traced and defended at review.
Beware the build-it-once trap. A dashboard is a product, not a deliverable; it needs an owner who prunes metrics that stopped driving decisions and adds those the project now needs. Without that ownership, dashboards accumulate vanity metrics and slowly decay back into the report dump they were meant to replace.
Common Dashboard Failures — and How to Fix Them
Four failure patterns recur often enough to be worth naming, because each is avoidable with a deliberate design choice.
- Vanity metrics. Tiles that look busy but drive no decision — total transactions processed, number of line items. Fix: delete any metric that has never changed an action.
- Stale data. A dashboard refreshed monthly when decisions are made weekly. Fix: automate the feed and set the refresh to the faster of the decision and data cycles.
- No forecast. Showing only earned value and actuals — the past — with nothing on the trajectory. Fix: lead with EAC, VAC, and float trend so the dashboard points forward.
- One size fits all. The same dense view pushed to the board and the engineer. Fix: build tiered views off one model, summary on top, detail behind a drill-down.
Key Takeaways
- Design the dashboard from the decisions it must support, not the data available — if a number changes no decision, it belongs in the report, not the dashboard.
- Build a single governed data layer first, mapping the WBS to the CBS so cost and schedule reconcile automatically and every figure traces to one source.
- Carry eight to twelve balanced cost and schedule indicators, each with a trend and a status against threshold, and lead with forward-looking measures like EAC and float.
- Use layout and colour to guide attention: strongest signals top-left, colour reserved for threshold breaches, and tiered views for director, engineer, and steering committee.
- Treat the dashboard as a living product with an owner, an automated refresh matched to the decision cadence, and governed metric definitions.