Risks, Issues & Decisions Log

Keep risks (what might happen), issues (what has happened) and decisions (what you chose and why) in one place, each with an owner and a date. You finish with a log you can review in ten minutes a week and a record that answers "why did we do that?".

Evidence: RAID-style logs and decision logs are practitioner tools with no canonical origin and no tested evidence base. Probability and impact matrices are contested in the risk literature. The dependency note rests on one small consulting survey and is marked as such. Score bands are a rule of thumb.

Use it when:

• A project or process has more than a few moving parts and several people who can create or fix problems.
• Decisions keep being reopened because nobody remembers the reasons.
• A sponsor, board or customer asks what could go wrong and what you are doing about it.

Skip it when:

• You need the one-off analysis of a single large decision: use 8.16 Board Decision Prep Sheet.
• You want a risk check for a stable operation, not a project: use 5.6 Risk & Leverage Checklist for financial risk.

Most of this template is working craft, not research. Risks, issues and decisions kept in heads and meetings decay; one written log gives accountability and a memory the project can be checked against. The most scientific-looking part deserves the most caution: probability and impact scoring is contested, and critics argue such matrices can misrank risks (Cox, 2008). Use the score to start a conversation and roughly order the list, never as measurement. Decision logs are untested practitioner convention, kept because undocumented decisions get relitigated.

So a risk must be an event you can picture, with a cause and a consequence; a category label cannot be mitigated. Rank the top few by force instead of trusting the comfortable middle of the scale. Write down the alternatives you rejected, because the real reader of a decision record is someone in the future. And look one level beyond your direct dependencies, where visibility usually ends (McKinsey, 2024; consulting practice).

A risk might happen. State it as cause, event and consequence. Score probability and impact from 1 to 5 and multiply. Choose a response: avoid, mitigate, transfer or accept.

Strong answer: (illustrative) "The only supplier of the ventilation unit has a long lead time (cause); delivery after August 1 (event); kitchen cannot open at term start (consequence). Probability 3, impact 4, score 12. Mitigate: order now with a penalty clause and ask a second supplier for a quote." Not: "Supplier risk."

Illustrative example: the project and the numbers are made up.

A municipality renovates a school kitchen that serves about 400 lunches a day. The project lead keeps the log.

Step 1: the top risk is a late delivery of the ventilation unit. Score 3 × 4 = 12. Owner: purchasing officer. Response: order now with a penalty clause and request a second quote.

Step 2: the open issue is the misplaced floor drain, owned by the site manager.

Step 3: the decision to use a standard unit is recorded with the rejected custom option and the reason: two weeks faster.

Step 4: the supplier depends on one steel plant, recovery about ten weeks; the second quote is the fallback.

Step 5: the weekly summary to the sponsor: one new risk, one issue closed, and one ask: approve a temporary catering budget if the unit is not delivered by August 1.