Project Management Guide

Published: 2026-10-30 · Reviewed: 2026-11-04

Risk Registers Without the Bureaucracy

Hearing “risk register” makes most people picture a spreadsheet with 80 rows, probability matrices, and a consultant’s invoice. That version is designed for construction megaprojects and government contracts. Yours doesn’t need to be.

A risk register for a normal business project is a simple list of things that could go wrong, written down before they go wrong, with a rough plan for each. That’s it. The goal isn’t to predict the future, it’s to stop being surprised by the predictable.

Why This Matters

Ask any experienced manager what went wrong on their last project, and listen to how they describe it: “the supplier was late,” “the budget ran out,” “the key person left,” “the software didn’t do what we expected.” Then ask: was that really unforeseeable? Almost always, someone saw it coming. They just didn’t say it, or didn’t write it down, or there was no plan when it happened.

A risk register does two practical things. First, writing a risk down forces you to think about it properly, how bad would it be, what would we do. Second, reviewing the list regularly means risks get attention while they’re still small. A late supplier spotted in week two is a phone call; the same supplier spotted in week ten is a crisis.

It also makes the project calmer. Anxiety about a project usually comes from vague dread, “what if something goes wrong?” A risk list turns vague dread into specific items, each with a plan. Specific problems are manageable; vague dread isn’t.

Key Concepts

Risk vs issue. A risk is something that might happen. An issue is something that has happened. The register holds risks. When a risk comes true, it moves off the risk list and onto the issue list (or just into your status report’s blockers). Keeping them separate matters: risks get prevention, issues get action.

Probability and impact, kept simple. You don’t need a 5×5 matrix. Three levels each is enough: probability, unlikely, possible, likely; impact, minor, moderate, serious. A risk that’s likely and serious gets your attention. A risk that’s unlikely and minor gets a line in the register and nothing more.

Response: avoid, reduce, accept, transfer. For each risk, pick one response. Avoid: change the plan so the risk can’t happen. Reduce: take steps to make it less likely or less damaging. Accept: decide the risk is small enough to live with, and note that you decided that. Transfer: push the risk to someone else, for example, a fixed-price contract transfers cost-overrun risk to the supplier.

Owner. Every risk has one person responsible for watching it. Not fixing it necessarily, watching it. The owner checks whether the risk is getting more likely and triggers the response plan if it does.

Trigger. The early warning sign. “If the supplier hasn’t confirmed by the 15th, we switch to plan B.” Triggers turn risks from background worry into monitored items with tripwires.

Practical Steps

1. Brainstorm risks at the start. Get the people involved in a room (or a call) for 30 minutes. Ask: “what could go wrong with this project?” Write down everything, no debating yet. Typical categories: people (key person leaves, supplier fails), money (costs overrun, funding delayed), time (approvals slow, dependencies late), technical (software doesn’t work, equipment fails), external (regulation changes, weather, market shifts).

2. Score each risk simply. For each one, mark probability (unlikely / possible / likely) and impact (minor / moderate / serious). This takes five minutes and immediately shows you where to focus. You probably have 10–20 risks; only 3–5 will be high priority.

3. Write a one-line response for each. What’s the plan? “If X happens, we do Y.” For accepted risks, the line is “accept, impact minor, monitoring only.” Keep it short. A response you can’t explain in one line is too complicated.

4. Assign an owner to each risk. One name per risk. The owner’s job: keep an eye on it and raise the alarm if it gets more likely. Most owners will never need to act, that’s the point of watching.

5. Review the register with your status reports. Spend five minutes each cycle: any new risks? Any old risks now more or less likely? Any risks that happened (move them to issues)? This keeps the register alive. A risk register written once and never reviewed is decoration.

6. Close out retired risks. When a risk can no longer happen, the delivery arrived, the contract is signed, mark it closed. This keeps the list short and focused on what still matters. A register that only grows becomes unusable.

Common Mistakes

Listing everything. A 60-row risk register for a small project is a sign you brainstormed without filtering. Merge duplicates, drop the trivial, and keep the list to what you can review in five minutes. Twenty rows is a lot for a small project; ten is usually enough.

No owners. A risk with no owner is just a worry written down. It gets reviewed by nobody and acted on by nobody. Assign a name to every row.

Treating it as a one-off exercise. Risks change. A supplier that was reliable becomes unreliable. A deadline that was comfortable becomes tight. The register is only useful if it’s reviewed regularly, tie it to your status report rhythm.

Confusing risks with issues. If the supplier is already two weeks late, that’s not a risk, it’s an issue, it needs action now, not monitoring. Move it to your blockers and deal with it. The register is for what’s still ahead of you.

Over-precision. Scoring a risk as “37% probability” is false precision. Unlikely / possible / likely is honest about what you actually know. The register is a thinking tool, not a prediction engine.

Planning responses you’ll never execute. “We’ll hire a backup supplier” is only a response if you’d actually do it. If the real answer is “we’d just absorb the delay,” write that down. Honest acceptance beats fantasy planning.

Using it to assign blame. “I told you this was a risk” is the fastest way to make people stop contributing risks. The register is a team tool. When a risk materialises despite the plan, the lesson goes in the lessons learned, not in a performance review.

Relevant Templates