Keep the workbook as the maintained source. A dashboard is useful when it helps the group choose its next response, not when it replaces an unresolved question with a confident-looking score.
Use a register with stable risk IDs
Create columns for Risk ID, uncertain event, consequence if it happens, evidence or assumption, supplied likelihood label, supplied impact label, response, owner, response state, review date, and source reference. Put the team's rating definitions on a separate Definitions sheet.
Do not multiply labels or convert them to numeric probabilities unless the team has supplied that method. “High” does not mean 80% merely because a dashboard needs a chart. If definitions are missing, display rating definitions not supplied and discuss the response without pretending to know the ranking.
Three fictional rollout uncertainties
Original fictional register for a community website launch. Review as of October 20, 2026; dates are local calendar dates. Sample likelihood/impact labels are supplied here without definitions, so they are retained as labels and not used to compute scores.
| Risk ID | Uncertain event and evidence | Supplied labels | Proposed response | Owner / next review |
|---|---|---|---|---|
| R01 | Final content approval may arrive after the launch cutoff; approval request unanswered | Likelihood High; impact High | Ask approver for a decision and prepare a scope option for the project lead | Elena / Oct 19 |
| R02 | A volunteer may be unavailable for launch checks; availability is an assumption | Likelihood Medium; impact Medium | Confirm availability and identify who can cover the agreed checks | Marcus / Oct 22 |
| R03 | Backup launch-event venue may not be available; no confirmation supplied | Likelihood Unknown; impact Medium | Ask venue contact to confirm the booking status | Dana / Oct 21 |
R01's review date is before the stated as-of date, so it is overdue for review. That flag does not mean the content approval has failed or that the proposed response has been completed. R03's likelihood remains Unknown; missing evidence is not a low rating.
If the launch cutoff has already passed without approval, record the actual issue through the team's issue process. Retain a link to the former risk so the history is understandable. Do not keep an event that has already occurred described only as a future possibility.
Build the dashboard around response work
Give the Excel summary a visible as-of date and show three useful views: responses awaiting confirmation, reviews before the as-of date, and risks with missing evidence or definitions. Trace each summary item to its unique Risk ID.
Use filters on the register's response state and review date. Validate the source rows before relying on category totals. If two rows share R02, resolve whether they are duplicate entries or separate risks needing separate IDs; otherwise the dashboard may count one uncertainty twice.
For R01, the next discussion is “Who will get the approver's answer, and what decision does the project lead need if it is delayed?” That is more actionable than re-reading High/High. Show evidence, owner, and response together without marking the action done simply because someone selected its row.
Generate the Excel planning structure
Prepare an Excel risk-register and dashboard specification in US English.
Project and as-of date: [enter]
Date convention: [enter]
Risk rows and evidence: [paste approved records with unique IDs]
Rating definitions and scoring method: [paste or NOT SUPPLIED]
Response owners, states, and review dates: [paste]
Existing issues already encountered: [paste separately]
Maintained workbook location: [enter]
Return a Register column structure, a Definitions sheet, and a dashboard
plan linked to the source IDs. Preserve supplied ratings and show missing
definitions; do not invent probabilities or numeric scores. Separate future
uncertainties from occurred issues. Flag duplicate IDs and unknown dates.
Define overdue review as review date strictly before the supplied as-of date;
today is due today. Keep proposed response work separate from completed work.
Show owner, evidence, response state, and review date beside each exception.
Keep the output Excel-first. Provide any suggested formulas with their column
assumptions, not a claim that they were tested in my workbook. An optional
HTML meeting snapshot may be offered separately; it must not imply Excel
sync, automatic mitigation, or replacement of the maintained register.
Before the review ends, resolve who will seek each missing answer and when the register will be checked again. Record actual response progress in Excel. The next dashboard should show what changed in the source rows, including what is still unknown.
Optional: read a risk-response snapshot in NOS
If you also prepare an HTML meeting snapshot, NOS can save and display the risk evidence beside the response owner and date. Use it for a readable discussion packet while maintaining the register, rating definitions, and action updates in Excel.
