2 Risk Management Planning and Governance

Connect risks to objectives

Begin by clarifying what the project is meant to achieve and why it matters to the business. Objectives may include delivering a product by a target date, staying within an approved budget, meeting regulatory obligations, protecting customers, or realizing expected benefits. These objectives provide the context for deciding which uncertainties matter and how serious their effects could be.

Describe risks in relation to objectives rather than as vague concerns. A useful format is cause, uncertain event, and effect. For example: “Because the supplier has not completed performance testing, a critical component may arrive late, delaying launch and reducing expected first-year revenue.” This statement identifies a cause, a possible event, and consequences for both delivery and the business case.

Consider opportunities as well as threats. Early access to a new technology, for example, might allow the project to reduce operating costs, but only if it can be tested without compromising launch readiness. Recording both threats and opportunities helps decision-makers consider how uncertainty affects value, not only schedule and cost.

Set governance and accountability

Governance establishes who makes decisions, who manages risks day to day, and how information moves between the project and the organization. Roles vary by organization, but the plan commonly clarifies these accountabilities:

• Sponsor or senior accountable executive: Owns the business case and provides oversight; makes or secures decisions on risks beyond the project manager’s authority.

• Project manager: Coordinates the risk process, ensures risks are reviewed and recorded, and reports the project’s overall exposure.

• Risk owner: Monitors a particular risk, recommends action, and keeps its status current. The owner should have sufficient authority or access to influence it.

• Response or action owner: Carries out a specific agreed response and may be a different person from the risk owner.

• Project team and stakeholders: Identify and assess risks, contribute expertise, and raise new information promptly.

• Governance board or risk function, where applicable: Provides challenge, oversight, specialist support, and decisions on escalation or acceptance.

Clear accountabilities help ensure risks are actively managed rather than merely listed. Define who can approve responses, use contingency or management reserves, accept residual exposure, and escalate a risk. Governance should also specify who receives a risk that exceeds the project’s authority or appetite and how quickly it must be escalated.

Define criteria and thresholds

Establish risk criteria before scoring risks so the team applies them consistently. Criteria can include probability of occurrence, impact if the risk occurs, and effects on cost, schedule, scope, quality, safety, compliance, reputation, and benefits. They may also account for time to impact, proximity, or urgency, the level of exposure the organization is willing to accept, and thresholds for action, escalation, or senior approval.

For a simple qualitative approach, define probability and impact scales—such as low, medium, and high—with practical descriptions for each level. A probability-impact matrix can help compare risks and determine which need immediate attention.

Thresholds should reflect organizational risk appetite and project objectives. The same potential cost increase may be tolerable on one project but unacceptable on another. Criteria can also set a threshold for overall exposure or a trigger requiring a forecast, business case, or delivery approach to be reconsidered. Specify how quickly a risk that exceeds the project’s authority or appetite is escalated and to whom.

Document the process and keep it current

The Risk management plan explains how the project will manage uncertainty. It is a working agreement, not simply a list of current risks, and should be tailored to the project’s size, complexity, delivery approach, and context. It may be part of the wider project plan or a separate document.

A practical plan typically records:

1. Objectives and scope: Which project objectives and stages are covered, and how risks will be linked to business outcomes.

2. Method and tools: How the team will identify, assess, prioritize, respond to, and monitor risks; which templates, categories, and analysis techniques will be used.

3. Roles and authority: Risk owners, decision rights, approval levels, and escalation routes.

4. Criteria and thresholds: Scales, scoring rules, appetite, tolerance, and triggers for action or escalation.

5. Timing and resources: When risk activities and reviews occur, and the people, time, budget, or reserves available to support them.

6. Communication and records: How risks are reported, where the Risk register is kept, and what information reports must include.

7. Review and change arrangements: How the plan and criteria are updated when project conditions, assumptions, or business priorities change.

Keep the Risk management plan distinct from the Risk register: the plan describes the approach, while the register records specific risks, assessments, owners, actions, and status. The process is iterative: teams identify and assess risks, agree on responses, assign owners, and monitor whether responses are working. New risks can emerge and existing risks can change, so conduct reviews at planned intervals and when important decisions or changes arise.

Apply governance to a launch-delay risk

Consider a project that depends on a supplier’s untested component. The team records the cause, uncertain delivery delay, and possible effects on launch, revenue, and customer commitments. It applies the agreed probability and impact criteria, assigns a risk owner, and selects responses such as requesting test evidence, qualifying a backup supplier, or preparing a revised launch sequence.

The plan states who can fund these actions, when the risk must be escalated, and how its status is reported. If the exposure threatens expected benefits beyond the sponsor’s tolerance, governance can consider changing the delivery strategy or revisiting the business case.

• Project risk management