10.3 Risk Registers, Ownership, and Risk vs Issue Distinction

10.3 Risk Registers, Ownership, and Risk vs Issue Distinction

Definition (APM BoK7 glossary): A risk register is a document listing identified risk events and their corresponding planned responses. Used interchangeably with risk log or risk repository. BoK7 (4.3.3) adds that "a risk register is used to document risks, analysis and responses, and to assign clear ownership of actions" — so when a question asks for the purpose of a risk register, the answer APM expects is a record of the risks, their impact and the actions taken to manage them.

An issue is a problem that is now breaching, or is about to breach, delegated tolerances for work on a project or programme. Issues require support from the sponsor to agree a resolution. Note the second sentence: sponsor involvement is part of the definition, not an optional escalation path.

Effective risk management demands rigorous record-keeping and unambiguous accountability. Without a centralized, shared record of uncertainties, risk intelligence remains trapped in individual team members' heads, leading to blind spots and uncoordinated responses. The primary vehicle for capturing and governing project uncertainties is the Risk Register.

Equally vital for any project professional is mastering the boundary between Risks and Issues. Candidates sitting the APM Project Fundamentals Qualification (PFQ) frequently encounter questions testing this core distinction. Confusing a risk with an issue undermines project governance: treating a current operational crisis as an uncertain future possibility delays urgent action, while treating an uncertain future threat as an immediate crisis results in wasteful panic.

---

The Project Risk Register (Risk Log)

The Risk Register is a live management document established during the Initiate stage and continuously maintained across every phase of the project lifecycle. It serves as the project's single source of truth for risk identification, assessment, ownership, and response tracking.

Essential Fields in an APM-Compliant Risk Register

BoK7’s definition is deliberately short — identified risk events and their planned responses — but in practice a register carries more. While organisations adapt templates to suit their maturity, the fields below are those a robust risk register captures:

1. Risk Identifier (ID): A unique alphanumeric reference code (e.g., RSK-001, RSK-042) used for cross-referencing in reports and meeting minutes.
2. Date Raised & Originator: When the risk was formally logged and who identified it.
3. Risk Category (Source): Classification by domain (e.g., Commercial, Technical, Environmental, Legal, Operational, Safety) to assist in trend analysis.
4. Structured Risk Description (Cause-Event-Effect): A precise narrative separating the root cause, uncertain event, and resulting impact.
5. Inherent (Pre-Mitigation) Scores: Initial qualitative ratings for Probability (P) and Impact (I), typically on a 1-to-5 scale, yielding an inherent Risk Exposure score ($P \times I$).
6. Assigned Risk Owner: A named individual with overall accountability for managing the risk.
7. Mitigation / Response Strategy & Action Plan: The chosen strategy (Avoid, Reduce, Transfer, Accept / Exploit, Enhance, Share, Reject) and specific, concrete steps to be taken.
8. Assigned Risk Actionee: The specific individual delegated to execute the practical mitigation actions.
9. Residual (Post-Mitigation) Scores: The forecast Probability and Impact scores that will remain after mitigation actions are successfully implemented.
10. Status & Target Review Date: The operational state of the risk (e.g., Identified, Assessing, Mitigating, Closed, Materialized) and the deadline for the next review.

+-------------------------------------------------------------------------------------------------------------------------+
|                                             TYPICAL RISK REGISTER EXTRACT                                                |
+----+-------------+---------------------------------------+-----------+---------+------------+------------+-------+------+
| ID | Category    | Risk Description (Cause-Event-Effect) | Inherent  | Owner   | Strategy   | Actionee   | Resid | Status|
|    |             |                                       | P x I = E |         | & Action   |            | P x I |      |
+----+-------------+---------------------------------------+-----------+---------+------------+------------+-------+------+
| 01 | Commercial  | Because supplier faces cash crunch,   | 4 x 4 =16 | J. Smith| Transfer:  | T. Brown   | 2 x 2 | Open |
|    |             | steel delivery may be delayed 3 wks,  |  (RED)    | (Procure| Fixed-cost | (Contract  |  = 4  |      |
|    |             | causing £60k site idle overheads.     |           | Lead)   | liquidated | Specialist)|(GREEN)|      |
|    |             |                                       |           |         | damages.   |            |       |      |
+----+-------------+---------------------------------------+-----------+---------+------------+------------+-------+------+

---

The Cause-Event-Effect Formulation

A frequent pitfall in project management is logging vague statements in the Risk Register, such as "Weather risk" or "Budget risk". These are not actionable risks; they fail to distinguish between facts that already exist and uncertainties that might happen.

To enforce clarity, APM recommends the Cause-Event-Effect structured syntax:

$\text{"Because of } [\mathbf{Cause}]\text{, } [\mathbf{Event}]\text{ may occur, which will lead to } [\mathbf{Effect}]\text{."}$

• Cause (The Existing Fact): A definite, present condition or operational context that creates vulnerability (e.g., "Because the development team has no prior experience with the new cloud database...").
• Event (The Uncertainty): The uncertain occurrence that may or may not happen in the future ($0% < Probability < 100%$) (e.g., "...data migration errors may occur during cutover...").
• Effect (The Impact on Objectives): The tangible consequence on time, cost, scope, or quality should the event happen (e.g., "...which will lead to a 5-day schedule delay and £25,000 in emergency contractor support costs.").

Separating cause from event prevents teams from trying to "mitigate" unchangeable facts, allowing them to focus countermeasures directly on stopping the event or cushioning the effect.

---

Roles and Accountabilities: Risk Owner vs. Risk Actionee

A critical distinction in APM PFQ Assessment Criterion 7.4 is the division of responsibility between the Risk Owner and the Risk Actionee:

1. The Risk Owner (Accountability)

• The Risk Owner is a single named individual assigned formal accountability for managing, monitoring, and controlling the assigned risk.
• Key Responsibilities:
  • Evaluating and recommending the appropriate response strategy (e.g., choosing whether to mitigate or transfer).
  • Monitoring the risk environment for early-warning triggers.
  • Ensuring that adequate resources and funding are deployed for response actions.
  • Regularly updating the Risk Register and reporting status to the Project Manager and governance boards.
  • Golden Rule: Accountability cannot be delegated. Even if a team of twenty technicians works on mitigating a risk, the Risk Owner remains solely accountable to the Project Manager for the outcome.

2. The Risk Actionee (Execution)

• The Risk Actionee is the specific person or technical specialist delegated by the Risk Owner to execute practical, tactical mitigation tasks.
• Key Responsibilities:
  • Carrying out day-to-day mitigation work (e.g., configuring firewall software, conducting non-destructive metal testing, drafting an insurance rider).
  • Reporting progress, hurdles, and completion milestones back to the Risk Owner.
• Summary of Distinction: The Risk Owner has accountability for the risk; the Risk Actionee has responsibility for executing specific tasks. A Risk Owner may also act as the Risk Actionee on smaller projects, but on complex projects, the roles are typically divided.

---

The Probability-Impact (P-I) Matrix and Risk Exposure

To prioritize risks without getting bogged down in complex mathematics, project managers utilize the Probability-Impact (P-I) Matrix (often a $5 \times 5$ or $3 \times 3$ grid).

• The vertical axis plots Probability (e.g., 1 = Very Low to 5 = Very High).
• The horizontal axis plots Impact (e.g., 1 = Negligible to 5 = Critical).
• The intersecting score represents the Risk Exposure ($P \times I$).

The matrix establishes clear visual governance thresholds using a Red-Amber-Green (RAG) convention:

• Red Risks (High Priority / Extreme Exposure): Severe threats that threaten project viability. Demands mandatory proactive mitigation, significant management attention, and immediate escalation to executive sponsors.
• Amber Risks (Medium Priority / Moderate Exposure): Meaningful uncertainties that require planned countermeasures and regular monitoring during periodic risk reviews.
• Green Risks (Low Priority / Low Exposure): Minor operational uncertainties placed on a "watch list". Reviewed periodically to ensure their probability or impact has not escalated.

---

The Fundamental Distinction Between a Risk and an Issue

The boundary between a Risk and an Issue is one of the most vital principles in project management (APM PFQ AC 7.7). Misunderstanding this distinction leads to governance failure.

The Core Definitions

• Risk: An uncertain event or set of events situated in the future ($0% < Probability < 100%$). It might happen, or it might not. Risk management is fundamentally proactive—identifying threats in advance to prevent them, and identifying opportunities to capture them.
• Issue: BoK7 defines an issue as a problem that is now breaching, or is about to breach, delegated tolerances for work on a project or programme, adding that issues require support from the sponsor to agree a resolution. In other words an issue is a certain event — it is happening, or it is definitely about to — which is exactly the difference the exam tests. BoK7 (4.3.5) also separates issues from routine problems: "issues are differentiated from problems that are dealt with on a day-to-day basis by the project manager and team".

+-----------------------------------------------------------------------------------+
|                         THE RISK VS ISSUE DIVIDE                                  |
+-----------------------------------------------------------------------------------+
|  DIMENSION          | PROJECT RISK                   | PROJECT ISSUE              |
+---------------------+--------------------------------+----------------------------+
|  Certainty          | Uncertain — it may or may not happen | Certain — it is happening, or will definitely happen |
|  Temporal Focus     | Future (What might happen)     | Present (Happening now)    |
|  Management Stance  | Proactive (Anticipate/Prevent) | Reactive (Resolve/Recover) |
|  Governing Log      | Risk Register                  | Issue Log (Issue Register) |
|  Evaluation Metric  | Probability and Impact         | Actual Consequence/Urgency |
|  Key Response Focus | Avoid, Reduce, Transfer, Accept| Escalation, Fix, Recovery  |
+-----------------------------------------------------------------------------------+

The Transition: How a Risk Becomes an Issue

BoK7 notes that "issues may develop when particular risks or groups of risks actually occur", and that issues happening now "may also be causes of new risks, or result in assessment of risk likelihood and/or size of impact to change". When an identified threat event materialises during execution it undergoes an immediate formal transition:

1. The uncertainty collapses to certainty: the event is no longer potential, it is real.
2. The event ceases to be a risk. Pre-mitigation risk planning is terminated.
3. The item is updated in the Risk Register as "Materialized" and formally closed.
4. The problem is logged immediately in the Issue Log (or Issue Register).
5. If the impact of the materialized event breaches or threatens to breach delegated project tolerances, the Project Manager immediately escalates the matter to the Project Sponsor via an Exception Report.