Risk Register

What goes in

Each risk gets one row: description, assessment, response, owner. The description works best as a cause-event-impact sentence: "if the lead developer leaves (event) during an active hiring market (cause), the payment module slips a month (impact)." Assessment grades probability and impact — a five-by-five multiplication is common — and multiplies them into a score. That score is a qualitative scale for relative priority, not a quantified exposure amount. The response, for threats, picks among avoid, transfer, mitigate, accept (opportunities have the symmetric exploit, share, enhance, accept); finally an owner is named to watch it. The four threat strategies differ in kind: avoid changes the plan to remove the cause, transfer hands it off via insurance or contract, mitigate reduces probability or impact. Accept takes the risk knowingly — actively, with a contingency prepared, or passively, doing nothing until it occurs.

Why it matters

It converts worry into something manageable. The floating "should we be concerned about that?" gains a score, an owner, and a response the moment it lands in the register. Scores create priority: you cannot prepare for every risk, but you can concentrate the team's attention and budget on the top-scoring few. Link risks to WBS tasks and the plan itself shows which work is carrying danger — and where schedule buffers belong.

Common misconceptions

The first trap: a register written once at kickoff and forgotten. Risks are born, grow, and expire over time, so the register lives only with regular review. Second, confusing risks with issues: a risk has not happened yet; once it happens it stops being a risk, converts to an issue, and moves to separate management. Third, mistaking a long register for good management — ten living responses beat a sleeping list of one hundred every time.