Project Risk Management: The Risk Register and Response Plans

What is a project risk?

A project risk is an uncertain event or circumstance that, if it occurs, would affect one or more project objectives. ^[4] The effect can be negative, a threat, or positive, an opportunity. PMI’s 2019 Standard for Risk Management in Portfolios, Programs, and Projects addresses events and conditions that may affect objectives, whether or not they could be foreseen during planning, and aims to capture opportunities and limit threats. ^[1]

In 2024 PMI updated the standard and folded its content into a practice guide that focuses on the “what” and “how” of risk management, covering the risk management life cycle and its application to portfolios, programmes and projects within an enterprise risk management approach. ^{[1, 2]}

The project risk management cycle

Risk management is not a session held at project launch and then forgotten. The PMI-RMP Examination Content Outline divides the work into five domains: strategy and planning, identification, analysis, response, and monitoring and closing. ^[3]

Planning defines risk management roles and responsibilities on the project and aligns them with a responsibility assignment matrix such as RACI. ^[3] Every stage after that both feeds and draws on the risk register, which is why the register sits at the centre of the cycle.

How should a risk be worded in the register?

The most common mistake in risk registers is mixing up cause, risk and effect. In an article published by PMI, David Hillson proposes a three-part statement: ^[4]

As a result of [a definite cause], [an uncertain event] may occur, which would lead to [an effect on objectives].

• Cause: a fact that exists now in the project or its environment, such as using an unproven technology or a shortage of specialist staff. ^[4]
• Risk: the uncertain event itself, signalled by words such as “may” or “might”. ^[4]
• Effect: the deviation from objectives if the risk occurs, such as a missed milestone or a budget overrun. ^[4]

One example from the article: a plan needs ten people but only six are available. The shortage is an existing cause, the risk is that the team may be too small for the workload, and the possible effect is schedule delay. ^[4]

Why does the separation matter? A cause is certain, so if it is logged as a risk it scores the highest probability and pushes genuine risks down the list. An effect does not exist until the risk occurs, so it cannot be managed directly. ^[4]

What goes into a risk register?

According to the PMI-RMP outline, developing the risk register involves validating risks and their triggers, assessing probability, impact and urgency, establishing each risk’s origin and owner, and classifying it as a threat or an opportunity. ^[3] These practical columns cover that:

A PMI Lebanon Chapter presentation adapted from the PMBOK Guide, Sixth Edition, shows a register with the code, event, causes, effects, breakdown category, impact on time, cost, scope and quality, score and level, and response strategy. ^[6]

Response strategies for threats and opportunities

There are five strategies for threats: ^{[5, 6]}

• Avoid: remove the root cause so the risk cannot affect the project, for example by changing the design.
• Transfer: pass the risk and liability for it to a third party, for example through insurance, warranties or subcontracting.
• Mitigate: reduce probability, impact or both to below the acceptability threshold.
• Accept: passively, by taking no action until the risk occurs and then deciding how to respond, or actively, by setting aside a contingency reserve.
• Escalate: when the project cannot manage the risk, pass it up to a higher level such as programme management.

Opportunities have counterpart strategies: exploit, to make the opportunity certain; share, with a party better placed to capture it in return for part of the benefit; enhance, by raising its probability or impact through its drivers and triggers; or take no specific action while staying ready to benefit if it arises, which Hillson calls “ignore”. ^[5]

Remember that transfer on projects usually happens through the contract or insurance, and the validity of risk-transfer clauses depends on each GCC country’s contract law and government contract conditions, so review them with a legal specialist before relying on them.

From plan to action: owner, trigger and contingency plan

Choosing the strategy is only half the job. The PMI-RMP outline calls for identifying action owners and allocating responsibilities, setting time-bound response actions, and showing their effectiveness with tools such as risk burndown charts. ^[3] Planning also covers contingency plans and workarounds. ^[3]

• Trigger and threshold: document triggers, causes and timing, and empower stakeholders to challenge existing thresholds. ^[3]
• Residual risk: what remains once the response has been implemented. It should be lower than the inherent risk; if it falls outside tolerance it needs further treatment, otherwise it goes on the watch list. ^[6]
• Secondary risk: a new risk that exists only because of the response, and which can sometimes be worse than the original. ^[6]

Hypothetical example: an online booking system for a government entity

Hypothetical example: a team is delivering an appointment booking system for a government entity, with a publicly announced launch date.

As a result of the system relying on an untested integration with the national identity platform, approval of the integration by the platform owner may be delayed, which would lead to postponement of the announced launch date.

• Assessment: medium probability, high impact on schedule and reputation, high urgency because testing is six weeks away.
• Strategy: mitigate by requesting the test environment immediately and naming a contact person at the platform owner.
• Trigger: test environment credentials not received within two weeks.
• Contingency plan: a pilot launch with temporary manual registration, subject to sponsor approval.
• Secondary risk: manual registration may increase errors, so it is added to the register with an owner and a daily check.
• Escalation: if the delay goes beyond the project manager’s authority, it is escalated to the PMO or the sponsor.

Monitoring the register and closing risks

In the PMI-RMP outline, monitoring means gathering risk-related performance data, comparing it with the baseline, analysing variances and tracking the effect on overall project risk exposure. ^[3] It then means updating the risk register, lessons learned, project management plan and change logs, and closing out expired risks. ^[3]

In practice, review high risks at every progress meeting, add new risks as soon as they appear, and give the sponsor a short report that focuses on what has changed rather than the whole register. The outline also recommends preparing reports suited to each stakeholder group. ^[3]

Conclusion

Project risk management starts with wording that separates cause from event from effect, and succeeds with a register that gives every risk an owner, a trigger and a dated response. Without tracking residual and secondary risks and closing out expired ones, the register becomes a document nobody reads.