Project Dashboard¶

At a glance

Purpose: Show the few measures that tell a reader whether the project is in trouble, on one page — with thresholds agreed in advance so the colour means something.
Use it when: At every reporting cycle, for a steering committee or sponsor. It supplements the status report; it does not replace its narrative.
Owner: The project manager; thresholds agreed with the sponsor.
Related: Module 11 · Lab 18 · Lab 22
Spreadsheet version: csv/project-dashboard.csv

How to use this template¶

Choose few measures — six to ten. A dashboard with thirty numbers is a data dump and will be read as one: nobody will notice which of them changed.
Define thresholds before you need them. If the colour is chosen after seeing the number, the dashboard reports opinion, and the conversation becomes about the colour.
Mix lagging and leading measures: cost and schedule variance are lagging; defect detection rate, requirement volatility, and blocked-work counts are leading.
Show trend, not just level. A single Amber reading means little; three consecutive Amber readings mean the previous actions did not work.
State what the reader should do. A dashboard that does not lead to a decision is decoration.

Field descriptions¶

Area	Suggested measure	Threshold example	Watch out for
Schedule	Schedule variance, or milestone slip in days	Green ≤ 2 days, Amber ≤ 5, Red > 5	Percentages that hide which milestone slipped
Cost	Cost variance, and cost performance index	Green ≥ 0.95, Amber 0.85–0.95, Red < 0.85	Measures with no agreed currency or baseline
Scope	Requirements added or changed since baseline	Green 0, Amber ≤ 2, Red > 2	Scope growth reported as progress
Quality	Open P1/P2 defects; defect escape rate	Green 0 P1, ≤ 2 P2	Counting defects without severity
Risk	Open exposure above threshold; top risk trend	Green ≤ 2, Amber 3–4, Red ≥ 5	Registers frozen at identification
Delivery	Items completed against forecast	Green ± 10%, Amber ± 20%	Forecasts without a stated basis
Team	Blocked work items; unplanned absence	Green 0 blocked, Amber ≤ 2	Absence reported only after the fact
Stakeholders	Decisions outstanding beyond their due date	Green 0, Amber 1, Red > 1	Decisions nobody recorded needing

Blank template¶

# Project Dashboard — [Project name]

| | |
| --- | --- |
| **Period** | [Start] – [End] |
| **Prepared by** | [Who] |
| **Baseline reference** | [Baseline version and date] |
| **Overall** | [Green / Amber / Red] |

## 1. Measures

| Area | Measure | This period | Last period | Threshold (G / A / R) | Status | Trend |
| --- | --- | --- | --- | --- | --- | --- |
| Schedule | [Variance in days] | | | 2 / 5 / >5 | | |
| Cost | [Variance; CPI] | | | 0.95 / 0.85 / <0.85 | | |
| Scope | [Changes since baseline] | | | 0 / 2 / >2 | | |
| Quality | [Open P1 / P2] | | | 0 / 2 / >2 | | |
| Risk | [Open exposure ≥ threshold] | | | 2 / 4 / ≥5 | | |
| Delivery | [Completed vs forecast] | | | ±10% / ±20% / >20% | | |
| Team | [Blocked items] | | | 0 / 2 / >2 | | |

## 2. Top risks and issues

| ID | Item | Exposure or severity | Response | Owner | Trend |
| --- | --- | --- | --- | --- | --- |

## 3. Decisions needed from this forum

| Decision | Needed by | Options | Impact if delayed |
| --- | --- | --- | --- |

## 4. Milestones

| Milestone | Baseline date | Forecast | Variance | Status |
| --- | --- | --- | --- | --- |

## 5. What changed since last period

[Three or four sentences. If nothing changed, say so — a dashboard that is always the same colour is
either a stable project or an unread one.]

## 6. Data quality note

[Which measures are measured, which are estimated, and what is not being measured at all. A dashboard
should state its own limitations.]

## 7. Thresholds and their origin

| Measure | Green | Amber | Red | Agreed with |
| --- | --- | --- | --- | --- |

Worked example¶

From Lab 18, on the analytics dashboard project — invented figures for teaching:

Area	Measure	This period	Last period	Threshold	Status	Trend
Cost	CPI	0.94	0.97	0.95 / 0.85	Amber	↓
Schedule	SPI	0.92	0.98	0.95 / 0.85	Amber	↓
Schedule	Milestone slip (days)	3	0	2 / 5	Amber	↓
Quality	Open P1 / P2	0 / 3	0 / 1	0 / 2	Amber	↓
Risk	Open exposure ≥ 6	4	3	2 / 4	Amber	↓

Four measures degrading in the same period is a different situation from one, and the dashboard is built to make that pattern visible at a glance rather than across four paragraphs of prose. Even so, the numbers alone do not explain themselves:

SPI is a ratio of value earned to value planned, so a front-loaded baseline makes it look better early and worse later. This project had exactly that baseline pattern, which is why the third row — a plain count of days slipped against a named milestone — is on the dashboard as a cross-check, and why the period-on-period movement matters more than the level. Lab 18 works this discrepancy through in full.
The status column is deliberately all Amber. The project is not in crisis, and reporting Red would trigger escalation the project does not need. Where that line sits is a judgement, which is why the threshold table is part of the artefact.

Common mistakes¶

Thresholds set after the fact. The dashboard then reports the reporter's comfort level, not the project's condition, and the discussion shifts to the colour.
Too many measures. Attention is the scarce resource; six to ten is a practical ceiling.
Only lagging measures. Cost and schedule variance tell you about the past. Add leading indicators such as defect detection and blocked work if the point is to act early.
No trend column. A level with no direction is half the information.
Percentages of unknown wholes. "80% complete" is meaningless without the basis of the percentage, which is why the schedule and cost rows use days and indices.
No data-quality note. Readers assume measured precision where estimates are being reported.
No decisions section. A dashboard that cannot produce an action is a report nobody needs.
Aggregating the whole project into one colour. Combining scope, cost, and quality hides which dimension is failing — the same aggregation error as balancing only total resource capacity.