What a risk is

A risk is something uncertain that could affect the work if it happens. An issue is already happening. A risk can still be prevented, reduced, accepted, transferred, escalated or monitored.

For a project team, a risk is often about scope, delivery, cost, quality, testing, security, data, decisions or dependencies. For a BAU team, a risk is often about service stability, support capacity, knowledge gaps, vendor support, changes, incidents or fragile systems.

Write enough to be useful

Use the pattern: IF this cause or condition happens or continues, THEN this event or consequence may occur, RESULTING IN this delivery, service, security, cost, quality, people or reputation impact.

Example: If firewall changes remain in the shared backlog, then testing may be delayed, resulting in a missed release window and extra replanning.

Do not overwork the wording

The first version can be rough. Capture the concern, give it an owner, score it, and add the next action. Improve the wording during review if the risk becomes important. Do not leave real concerns outside the tool because the wording is not perfect.

Good places to find risks

• Anything waiting on one person, one vendor, one environment or one approval.
• Work that is moving slower than expected.
• Defects, incidents, missed meetings, rework or unclear decisions.
• Security findings, access issues, data quality concerns and migration errors.
• Support teams showing signs of overload or repeated manual workarounds.
• Dates that rely on assumptions rather than confirmed commitments.

Likelihood scoring

Likelihood is about how credible the risk is during the period you are reviewing. Score what is likely to happen, not how worried people feel. Use evidence where possible: trend, dependency status, current backlog, vendor response, defect rate, incident history or decision delay.

Impact scoring

Impact is about the effect if the risk happens. Consider delay, cost, service stability, security exposure, user harm, compliance, reputation, recovery effort and leadership attention. Score the credible effect, not the worst imaginable story unless that is genuinely plausible.

Response choices

• Avoid: change the plan so the risk no longer applies.
• Reduce: take action to lower likelihood or impact.
• Transfer: move some ownership or impact through contract, insurance or another party.
• Accept: knowingly live with the risk and record why.
• Escalate: take it to someone who can decide, fund, unblock or prioritise.
• Monitor: keep watching when action is not needed yet.

Weekly process

1. Start with severe, high, overdue and review-due risks.
2. Ask the owner what changed since the last review.
3. Update likelihood, impact, status, due date and next action.
4. Add a dated note. Keep earlier notes so the story is retained.
5. Add new risks from incidents, stand-ups, vendor meetings and stakeholder feedback.
6. Close risks that no longer apply and write why they were closed.
7. Export a backup after the review if the data matters.

Good weekly questions

• What could stop the next milestone, release, change or service outcome?
• What are we relying on that is not fully under our control?
• What is getting harder, slower, more expensive or less stable?
• Where are we waiting for a decision, approval, environment, vendor or specialist?
• What has changed since last week?
• What is not being said because everyone is being polite?

How to use the dashboard

Click summary cards, heatmap cells, top risks, overdue actions, breakdown rows, chart bubbles and word cloud terms to focus the register. The dashboard is not just a view. It is a way to steer the next discussion.

How to use notes

Add a short note after every meaningful conversation or decision. Notes are appended rather than replaced so the risk keeps its history. Use notes for decisions, owner comments, score changes, action changes, escalation outcomes and closure reasons.

When to escalate

Escalate when the team cannot reduce the risk alone, when an owner is missing, when a decision is needed, when a date or budget may change, or when the risk affects another team, vendor, sponsor, service owner or portfolio.

When to close

Close a risk when the uncertainty has passed, the work is complete, the risk became an issue and is managed elsewhere, the exposure is accepted, or the risk is no longer relevant. Add a final note so people understand why it was closed.