To create a simple project risk register, list the uncertain events that could change an agreed project objective, name the signal that would trigger a response, assign one owner, and write the next action. Four columns can be a useful starting point for a small project. Add scoring only when the comparison will change a decision.
A register should help a team notice a change while it can still choose what to do. It is not a prediction of everything that could go wrong, and it is not a second task list. Keep it small enough to review when the project changes.
Start with the project decision
Before you open a spreadsheet, write down the project result and the next commitment that matters. That might be a launch date, an agreed scope, a handoff, or a decision to continue. A possible event belongs on the risk register when it could change one of those things.
This gives the list an edge. If every remote possibility goes in, the important items become harder to see. If the project has formal safety, legal, financial, regulatory, or contract requirements, use the required process and escalation path. This simple format is for work where a compact working view is appropriate.
Separate a risk, an issue, and an action
Use a practical distinction: a risk could happen; an issue is happening now or has already happened; an action is work someone has agreed to do. They may be connected, but they need different records.
- Risk: The venue may not confirm the date before invitations are scheduled.
- Issue: The venue has declined the date.
- Action: Ask the venue about the alternate date by Thursday.
Once a risk occurs, update its status and manage the present problem directly. Keep the response task in the action list with an owner and due point. The Journal's project action-item guide covers that separate record.
Use four fields that lead to a response
A simple project risk register can start with four columns. Add another field only when it helps someone make or carry out a decision.
| Field | What to write |
|---|---|
| Scenario | What uncertain event could affect which objective or commitment? |
| Trigger | What observable signal means the team should respond or escalate? |
| Owner | Who will watch for the trigger and bring the next decision forward? |
| Response | What will happen if the trigger appears, and by what date or decision point? |
Write a scenario as a complete thought: “Because [condition], [event] may happen, which could [effect on the project objective]. If [trigger], [owner] will [response] by [date or decision point].”
For example, imagine a small team preparing invitations for a workshop. The date is not confirmed in writing. The scenario is that confirmation may arrive too late for the planned invitation date, forcing the team to hold or change the announcement. The trigger is no written confirmation by Wednesday at noon. The event lead owns it. The response is to ask for a decision that afternoon and take the alternate date to the sponsor by Thursday if confirmation is still missing. That row tells the team what to watch and what choice comes next; it does not pretend the venue will or will not confirm.
Make the trigger observable
“The venue is a risk” is too vague to guide a response. “No written confirmation by Thursday at noon” is observable. A useful trigger can be a date, a missing approval, a result outside an agreed range, or a dependency that has not arrived.
Keep the trigger separate from the cause and the consequence. A supplier being busy may explain why a delivery could slip; the delivery arriving after the install date is the event; a missed opening is the consequence; no dispatch notice by Tuesday may be the trigger. When those parts are clear, the response can match the actual decision.
If the trigger sits outside the team's authority, name who can make that call and how the issue will reach them. An owner is responsible for bringing forward the signal and the decision. The owner is not automatically the person who can remove every cause.
Do not score what you cannot use
Templates often offer likelihood and impact scores. Those can help compare a longer list, but a number is useful only when the scale is defined and the ranking could change the response. For a short project list, start with three questions:
- Could this change the project's agreed result, next commitment, or ability to continue?
- Would acting now reduce the chance or consequence, or is the only useful move to wait for a signal?
- Who has the authority to make the next decision?
If two risks compete for limited time or money, define a small scale before assigning scores. Write what “low,” “medium,” and “high” mean for this project. Do not let a score hide the assumptions behind it, and do not add a 5-by-5 matrix when every row already has an obvious owner and response.
Use the project's baseline to define what could actually move. A risk only makes sense against a result, scope, or date the team has agreed to. If those commitments are still vague, the project baseline guide can help set the reference point first. For a formal public-sector reference, the UK Government's Orange Book treats risk management as part of planning and decisions. Use the requirements that govern your own project.
Review the register when the work changes
A risk register is a working note, not a one-time kickoff attachment. Set a next review point for each active risk: a milestone, an approval date, a delivery, or a choice the team already expects to make. Reopen the row when new information changes the scenario, trigger, owner, or response.
At each review, decide whether to keep watching, take an action, raise the decision to someone with authority, or close the risk because it no longer affects the project. If it has become an issue, move it into the present-tense work and record the response. Keep the reason for a major decision nearby so the team does not repeat the same discussion without new evidence.
A copy-ready small project risk log
Start with one row per meaningful uncertainty:
- Project objective: What result or commitment could change?
- Scenario: Because ___, ___ may happen, which could ___.
- Trigger: What will tell us to act?
- Owner: Who will watch and raise the decision?
- Response: If the trigger appears, we will ___ by ___.
- Next review: What date or project event should bring this row back?
For a very small project, this can live beside the plan the team already uses. If your organization requires a formal risk register, use this format only where it fits that process. The goal is a shared, current view that helps the people doing the work make the next decision.
Build yourself on purpose does not mean pretending uncertainty is gone or carrying every decision alone. Name the risk plainly, invite the person with the right context, and keep the response attached to the objective. For more practical building frameworks, return to The Self Made Journal.
If a quiet layer belongs in your workday rotation, see the live Standard Issue Crewneck listing for current garment details and its size guide. Apparel can be part of the uniform; the decisions still belong to the people building the work.
0 comments