Describe the event in a sentence
Use a cause–event–consequence sentence. For example: if a contributor delivers a file late, the editor may lose the planned review window, delaying the agreed release. This is more actionable than a row saying delays. Define the project outcome and scope first; a risk record cannot fix an undefined delivery. Keep guesses about likelihood visibly separate from observed facts.
Give the response to an actual role
Ask who can take a useful action before the event and who needs to know if it occurs. A response should change something specific: confirm an earlier file handover, reserve a review slot or agree a smaller initial scope. Do not allocate work to a person who has not accepted it. Add a trigger that can be observed without inventing a percentage probability or claiming a consultant has assessed the project.
Keep risk and issue states separate
When the uncertain event actually happens, record the observation and move the immediate work into an issue or task record. Preserve a link to the original risk so the reason for the response remains clear. Closing the risk because a file was uploaded can be premature if the actual concern was acceptance before the review slot. Ask whether the relevant uncertainty has really ended.
Review at a useful point
Set a date or project milestone when an owner will check the assumptions. Review after a scope or schedule change as well as on the calendar. Record what changed and why rather than repeatedly copying the same unresolved row. Keep a small live register understandable to the team; a long list with no owners or evidence of follow-up can hide the few decisions that matter.
Read the drawing as text
A preview may arrive late: risk R1. When Wednesday arrives without the preview, record issue I1 and an owner’s next action. Acceptance is a separate check.
Work through an example
In a fictional recording project, the final artwork must be reviewed on Friday. Risk R1 concerns a late image delivery. Its action is to ask for a preview by Wednesday, owned by the coordinator. On Wednesday no preview arrives: the observation becomes issue I1, and the coordinator asks whether Friday’s scope should change. The worksheet makes no numerical forecast of success.
Illustrative example; figures, people and organisations in the worked record are fictional.
The example record
Risk R1
- Observation or uncertainty
- Preview may arrive too late
- Next action
- Coordinator confirms Wednesday preview
Trigger
- Observation or uncertainty
- Wednesday preview not received
- Next action
- Open issue I1
Issue I1
- Observation or uncertainty
- Preview is now late
- Next action
- Agree revised scope or route
Review
- Observation or uncertainty
- Friday acceptance point
- Next action
- Record actual outcome
Download blank worksheet (.csv) ↗Download worked example (.csv) ↗
Keep your own record
Use the result within its scope
A useful closure records the evidence and date, not just a green colour. Risk planning cannot guarantee delivery or replace a professional financial, engineering or safety assessment when the project requires one.