| name | design-risk-register |
| description | Use when managing a project with meaningful uncertainty — logging identified risks in a structured register, scoring each by probability and impact, assigning an owner and a response, and reviewing the register regularly, rather than tracking risks informally in conversation or memory where they get forgotten or under-prioritized. |
| source | Project Management Institute (PMI), "A Guide to the Project Management Body of Knowledge (PMBOK Guide)," Risk Management knowledge area |
| tags | ["engineering","project-management","risk-register","probability-impact-matrix","project-risk","pmbok"] |
| related | ["apply-iso-31000-risk-framework","run-scenario-planning","apply-premortem"] |
Design Risk Register
Log every identified project risk in a structured register — scoring each by probability and impact, assigning a specific owner responsible for monitoring it, and defining a planned response — and review the register on a regular cadence throughout the project, rather than tracking risks informally in conversation or memory, where they tend to be forgotten, under-prioritized, or left without a clear owner.
Why This Is Best Practice
Adopted by: The Project Management Institute's PMBOK Guide documents risk register maintenance as a core practice within its Risk Management knowledge area, and the risk register (alongside the probability-impact matrix used to score entries) is standard practice across professionally managed projects in construction, IT, product development, and other project-based disciplines.
Impact: Projects that track risk only informally — through conversation, meeting notes, or memory — routinely lose track of identified risks between the point they're raised and the point they would need to be acted on, and lack a consistent way to prioritize which of many identified risks deserve the most attention; a structured register with explicit probability-impact scoring and named ownership directly addresses both gaps.
Why best: An informally tracked risk is easy to raise once and then forget, especially as a project progresses and attention shifts to more immediate concerns — a structured register with an assigned owner and a defined review cadence keeps every identified risk visible and accountable until it's explicitly resolved, closed, or accepted, rather than silently dropping out of view.
Sources: Project Management Institute, "A Guide to the Project Management Body of Knowledge (PMBOK Guide)," Risk Management knowledge area
Steps
Step 1: Log each identified risk with a clear, specific description
Log each identified project risk in the register with a clear, specific description — what could happen, and under what conditions — specific enough that someone unfamiliar with the original discussion could understand exactly what risk is being tracked.
Step 2: Score each risk by probability and impact
Score each logged risk on both probability (how likely the risk is to occur) and impact (how severe the consequence would be if it did), typically using a simple scale (e.g., low/medium/high or a numeric scale) for each dimension — this two-dimensional scoring, rather than a single combined "risk level," preserves the distinct information needed to decide how to respond.
Step 3: Assign a specific owner responsible for each risk
Assign a specific, named individual as the owner responsible for monitoring each risk and executing its planned response if the risk materializes — an unowned risk in the register tends to receive no actual attention regardless of how accurately it was scored.
Step 4: Define a planned response for each significant risk
For each risk scored as significant (based on its probability and impact), define a planned response — mitigate (reduce probability or impact), transfer (e.g., via insurance or contract), avoid (change the plan to eliminate the risk), or accept (proceed with the risk knowingly) — rather than leaving significant risks in the register without a defined response.
Step 5: Review and update the register on a regular cadence
Review the register on a regular, predetermined cadence throughout the project — checking whether logged risks have materialized, changed in probability or impact, or become newly relevant, and adding newly identified risks — rather than treating the register as a one-time exercise completed at project kickoff and left unmaintained afterward.
Rules
- Log risks with specific, clear descriptions — vague entries provide little actionable information when the register is later reviewed.
- Score every risk on both probability and impact separately, not a single combined rating that obscures which dimension actually drives the risk's priority.
- Assign a specific, named owner to every logged risk — an unowned risk receives no real ongoing attention.
- Review and update the register on a regular, predetermined cadence throughout the project, not only at project kickoff.
Examples
Structured register catching a risk informal tracking would have lost: A project team logs a supplier-dependency risk early in a project, scores it as low probability but high impact, and assigns a specific owner. Months later, during a scheduled register review, the owner notices the supplier's probability of disruption has increased due to external news, and proactively begins executing the contingency plan — a risk that informal, memory-based tracking would very plausibly have let drop out of view over that time span.
Unowned risk receiving no attention (illustrative failure mode): A different project logs several risks at kickoff but doesn't assign specific owners to them. Over the course of the project, none of these risks receive ongoing monitoring, and one materializes without any proactive response having been prepared — illustrating why ownership assignment, not just logging, is essential to the register's value.
Common Mistakes
- Logging risks with vague, non-specific descriptions — an unclear risk description provides little actionable information when later reviewed, especially by someone other than the person who originally raised it.
- Combining probability and impact into a single score rather than tracking them separately — this obscures whether a risk's priority is driven by likelihood or by severity, information needed to choose an appropriate response.
- Failing to assign a specific, named owner to each risk — an unowned risk in the register tends to receive no actual ongoing attention regardless of its score.
- Treating the register as a one-time kickoff exercise rather than reviewing it on an ongoing, predetermined cadence — risks and their probability/impact can change significantly as a project progresses.
When NOT to Use
- For a very small, short-duration project where the overhead of formal register maintenance exceeds its risk-management value — a lighter, informal risk discussion may be proportionate in this case.
- As a substitute for organization-wide enterprise risk management — a project risk register addresses risks specific to one project; see
apply-iso-31000-risk-framework for the broader, organization-level framework.
- When risks are so numerous and fast-changing that register maintenance itself becomes a larger burden than the risks it tracks — in this case, consider whether a different, more lightweight risk-tracking approach better fits the project's actual pace.
