Day 7: Build a Risk Register People Will Use

The Concept

A risk is an uncertain event that could affect the project. An issue is something that has already happened. An assumption is something the plan currently treats as true. Keeping these categories separate helps the team choose the right response.

Risk registers fail when they become lists of vague concerns: resource risk, technology risk, stakeholder risk. A useful entry describes what could happen, why it could happen, and what the team will do before or after it happens.

Write risks as cause and effect

Use this sentence: Because [cause], [event] may happen, which would affect [objective]. For example: because the data owner is supporting another launch, the validation review may move by two weeks, which would delay testing.

This structure makes the risk discussable. It also helps AI suggest a prevention action and an early warning sign without turning the register into generic advice.

Review the register in the room

Risk ownership is not delegation of blame. The owner is the person best placed to notice the warning sign and coordinate the response. A project manager can maintain the register, but cannot personally own every risk.

Example: make a vague risk useful

“Stakeholders may not adopt the new process” is too broad to guide action. A more useful statement might be: “Because regional managers have not seen the new approval workflow, they may continue using the old form during the first month, which could create duplicate requests and delay reporting.”

That version gives the team something to work with. The early warning sign could be repeated questions about where to submit a request. The prevention action could be a short manager walkthrough and a clear transition date. The contingency could be a temporary review of both channels while the old form is retired. The risk is no longer an abstract concern; it is a sequence the team can observe and influence.

Choose response before rating

Likelihood and impact ratings are useful only when they support a decision. First ask what the team can do:

• Avoid: change the approach so the risk no longer applies.
• Reduce: lower the chance or consequence through preparation.
• Transfer: move responsibility through a contract, control, or specialist.
• Accept: acknowledge the exposure and define when it will be revisited.

For opportunities, use the same discipline in the other direction: pursue, strengthen, share, or accept. AI can propose response options, but the team must choose based on authority, cost, timing, and appetite for uncertainty.

Separate the register from the issue log

If a vendor has already missed a delivery date, that is an issue. It may create new risks, but it should not remain hidden in a future-tense risk statement. Record the issue, its current impact, the owner, and the immediate decision needed. Keeping present problems visible prevents the risk register from becoming a place where urgent work disappears.

Set a review rhythm

Review active risks at a cadence that matches the project. A high-change launch may need a weekly review; a stable internal improvement may need a review at each milestone. Close risks that are no longer credible, update assumptions that changed, and promote emerging concerns instead of preserving an outdated list for its own sake.

A final check before sharing

Ask whether each entry contains a cause, an uncertain event, an effect, a warning sign, an owner, and a response. If one of those is missing, label the gap rather than letting polished language hide it. The goal is not to predict everything. The goal is to help the team notice and respond earlier.

Use evidence to improve the register

At each review, ask what has changed since the last conversation. Has a warning sign appeared? Did a prevention action reduce exposure? Did a new fact increase or reduce confidence? Write the reason for a changed rating in one sentence. This makes the register a record of learning instead of a set of unexplained colours.

Do not reward the team for having a long list. Reward the behaviour the list enables: earlier escalation, clearer choices, and fewer surprises. Close entries when the exposure has passed, but preserve the decision history where it may help a future project.

Keep the active list short enough to discuss. Archive closed risks separately so the current register remains a decision tool, not a historical catalogue.

Give each active risk a next review date. Without that date, even a well-written response can become stale while the project moves around it.

Review the date whenever the project reaches a meaningful decision or milestone.

Use this today

Limit the active register to risks that could change the outcome, timeline, cost, quality, or trust. For each, ask the owner: “What would we notice first?” That answer is often more useful than a red, amber, green rating.

Remember this

• Specific risks lead to specific actions.
• Separate uncertainty, current problems, and assumptions.
• A risk register is useful only when people review and act on it.