Project Health Dashboard

What this tool does

CM8-296 is a portfolio health dashboard. You enter one row per project per reporting period — status across four dimensions, how far through it is, what it has spent, when it now expects to finish, and the one issue most likely to derail it. It works out budget consumption against progress, schedule variance against the baseline, and, because the history is in the file rather than in somebody's head, which projects have worsened since last period.

Its purpose is narrow: to make the sponsor's decision obvious. Not to archive status, not to give every project a paragraph. The question it answers is "which project needs attention this month, and what is being asked of me?" Everything runs inside this one file — no account, no upload, no network request of any kind.

What green, amber and red actually mean

Traffic-light reporting fails more often than it works, and for one reason: nobody defines the colours, so each project manager quietly invents their own. One rates amber the moment anything is uncertain; another holds green until the day it becomes undeniable. Averaged across a portfolio the colours stop carrying information, and you get what people call watermelon reporting — green outside, red all the way through. The failure mode is not dishonesty. It is that "amber" with no definition invites people to report their own temperament, and whoever reports amber early looks worse than whoever holds green until the end. Define the colours by who has to act and the ambiguity disappears:

• Green — on track, no help needed. It will deliver to its agreed scope, date and budget. Issues exist; the team is handling them. Nothing is being asked of anybody.
• Amber — recoverable by the team. The plan has been disturbed, but the manager has a recovery action and the authority to take it. Amber is a warning, not a request, and should carry a date by which it turns green or red.
• Red — will miss unless somebody above the project acts. It cannot recover with the authority, money or people it has. Red is not a measure of how badly things are going; it is a request for a decision. A red project with nothing being asked of the sponsor is mis-rated.

Written that way, red becomes a working signal rather than an admission of failure — the only way you will ever get one early. Say so when you introduce the tool, and mean it.

Reporting by period, not from memory

The row model is deliberate. Most status reporting overwrites itself: this month's slide replaces last month's, and the only record of the trend is what anybody happens to remember. That is precisely the information you most need, because a project amber for four months is a different problem from one that turned amber yesterday.

So each project gets a new row every period rather than an edited one, and the reporting date is the period end — the date the report describes, not the date you typed it. Keep it consistent so the periods line up and the portfolio chart draws a real trend.

The worsened since last period tile is the point of the whole design: it compares every project's latest overall status with the one before and counts the drops. Only a history can produce that number, and a project that moved green to amber this month is far cheaper to fix than the same project three months later.

The four dimensions

Each report also rates four things separately: schedule (will it finish when it said?), budget (will it cost what it said?), scope (is what will be delivered still what was agreed?) and resource (are the people and skills actually available to it?). They are separated because they fail independently. A project can be perfectly on schedule precisely because it has quietly dropped a third of its scope; another can be inside budget only because the work has not started.

Which leads to the rule worth enforcing: the overall status should never be greener than its worst dimension without an explicit reason. If resource is red, the project is red, unless the manager can say in one sentence why not — "resource is red for two weeks and the critical path has four weeks of float, so the finish date is unaffected". That is legitimate. "Overall is green because we are confident" is not. Leave the setting on and the tool marks every report whose headline is greener than its detail. It is not an accusation; it is a prompt for one question.

Progress against money

The cheapest early warning in project management is the gap between how much of the work is done and how much of the money is gone. It needs no new data, and it moves before the schedule does, because money burns steadily while progress stalls quietly.

Budget used is spend divided by approved budget; the gap is percent complete minus that figure. A project 40% complete having spent 40% is in step; one 30% complete having spent 70% is in trouble whatever colour it has claimed. A gap beyond the tolerance you set — fifteen points by default — is drawn red.

Two honest limits. This is not earned value management: no planned value curve, no performance indices, and percent complete is self-reported rather than measured against a baselined work breakdown. And it is only as good as its inputs. If "spent" means invoiced value while a large committed order sits unbilled, the gap looks better than it is; if percent complete is really percent of time elapsed, it means nothing. Decide what each number means, write it in the notes, and keep it the same every period.

Forecast and baseline finish

Two dates doing two jobs. The baseline finish is what was agreed at approval; it does not move unless the project is formally re-baselined, and if it moves quietly it has stopped being a baseline. The forecast finish is the date you honestly expect today. Schedule variance is the distance between them, and positive means late.

The discipline is small and unpopular: move the forecast the period it moves. Holding the date one more month costs nothing today and feels less like defeat, but a date nobody believes is worse than a later date everybody can plan around — other teams are booking installers, training and cutover windows against it. A project that slips two days a month for a year and reports the same finish throughout has not managed its schedule; it has hidden it.

Escalation, and naming the top issue

The escalation checkbox means one thing: this project needs a decision the project manager cannot take. More money, a scope freeze, a person released from another team, a supplier confronted. It is not a complaint and not a severity flag — it is an item for an agenda, and it should always be paired with the decision requested, written in the commentary. A request repeated three periods running, as in the sample data, is itself the finding.

The top issue is one sentence naming the single thing most likely to derail this project. Two tests: would somebody outside the project understand it, and does it name something specific? "Resourcing pressures" fails both. "The single integration developer has been unavailable for four consecutive weeks and no cover has been approved" passes both. The tool insists on one before accepting a red status, because a red project without a named cause is a mood rather than a report.

What this is not

This is a delivery dashboard, easily confused with a business one. The Executive KPI Dashboard reports how the organisation is performing — revenue, service levels, quality, headcount. This reports how a set of change initiatives is being delivered. Do not merge them: the two move on different clocks.

It is also not a substitute for the detail underneath. Individual risks and issues belong in a RAID Log; deliverable-by-deliverable acceptance belongs in a Milestone & Deliverable Tracker; the task sequence inside one project belongs in a Gantt Chart Planner. This tool carries one line per project per period. If it starts growing columns of detail, the detail belongs elsewhere.

The spreadsheet workflow

Status is often collected by email or on a shared sheet before anybody assembles the pack, and retyping it wastes the hour you should spend reading it.

• Spreadsheet template saves a CSV whose headings are exactly this tool's column names, with a guidance row explaining what each expects — the date format and the accepted values for phase and the status lists.
• Circulate it, collect one row per project, then delete the guidance row and save as CSV.
• Import spreadsheet reads it back. Columns match by heading, so order does not matter and extra columns are ignored. Rows failing validation — a red project with no top issue — are skipped and reported by row number, and importing appends to the history rather than replacing it.

The file is read inside your browser. Nothing is uploaded.

The formulas

Budget used shows "—" whenever the approved budget is missing or zero, because a percentage of nothing is not a small percentage. Blank number fields stay blank: an unentered spend is never read as a spend of zero, so a project with no budget figures drops out of the money calculations rather than dragging the portfolio percentage down. The portfolio figure sums the latest report from each project — never the whole history, which would count the same spend three times.

FAQ

Weekly, fortnightly or monthly? Whatever matches the pace at which decisions are actually taken. Monthly suits most portfolios; reporting faster than you can act generates paper.

A project reported twice in one period — which counts? The later reporting date, so a correction can simply be added as a new row.

Should closed projects stay in the file? Yes. Set the phase to closed and stop adding rows; they drop out of the current period naturally and the history stays available.

Why can I not enter 100% complete on a live project? Because it is almost always a reporting artefact — the work finished and the phase was never updated. Set the phase to closed.

Saving your work

Reports, settings and the report header are written to this browser's local storage as you type. That storage belongs to one browser on one computer. Treat Export .json as the real save — one file containing everything, which Import .json restores anywhere; because the value here is the history, keep a dated export after each reporting cycle. Export CSV gives you every report in the current filter. Reset erases everything, with no undo.

Accuracy & disclaimer

The arithmetic is simple and the tool performs it faithfully: percentages of budget, differences between dates, comparisons between one period and the last. Everything that decides whether the dashboard is worth reading sits above that arithmetic — whether the statuses are honest, whether percent complete reflects work rather than time, whether spend means invoiced or committed, and whether the top issue is the real one.

The tool cannot see a project that was not reported, or a problem nobody wrote down. It does not run earned value analysis and does not model the plan beneath each project. It is a reporting and calculation aid, not an assurance review and not an assessment of any project's true condition.