5 Risk Planning and Responses

Understand project risk

Project risk management is a continuing cycle: identify uncertain events that could affect objectives, assess their likelihood and consequences, plan responses, assign responsibility, and monitor changes. Risks can threaten project objectives or create opportunities to help achieve them. A Risk is uncertain and may happen; an Issue is a problem that has already happened. Risk management continues throughout the project, not just during initial planning.

Identify and describe risks

Look for uncertainty across scope, schedule, cost, quality, resources, technology, suppliers, safety, and external conditions. Risk identification can draw on team discussions, lessons from similar projects, assumptions, estimates, and reviews of the work breakdown structure and schedule. Revisit identification at project milestones and when plans or conditions change.

Describe each risk using its cause, uncertain event, and effect on an objective:

Because [cause], [uncertain event] may occur, causing [effect on an objective].

For example: “Because the test environment is shared with another team, access may be delayed, pushing system testing past the planned date.” This description is more actionable than “testing delay” because it identifies a cause to monitor and an effect to plan for.

Record risks in a Risk register. A useful entry includes a unique identifier, description, affected objective, probability, impact, priority, response, owner, trigger, and status. Keep assumptions and estimates visible; uncertainty in duration or cost can itself be a risk.

Assess and prioritize

A qualitative assessment rates each risk’s Probability and Impact using agreed scales, such as low, medium, and high. Define what each rating means for the project and apply the definitions consistently. A probability–impact matrix helps the team focus on consequential risks, but ratings remain estimates rather than guarantees.

For a basic numeric screen, multiply probability by impact when the ratings use compatible scales. For example, with both scales rated from $1$ to $5$, a risk rated $4 \times 5 = 20$ would generally receive more attention than one rated $2 \times 2 = 4$. Use the project’s agreed thresholds to determine priority; a score alone does not replace judgment.

More detailed quantitative analysis may be useful when decisions depend on the combined effect of many uncertainties or on a high-consequence risk. Schedule risk analysis, for example, can estimate the likelihood of meeting a completion date and help identify schedule drivers.

Plan responses and assign owners

Choose a response that addresses the risk’s cause, likelihood, or consequence. Specify concrete actions, timing, resources, and decision points. Common responses to threats include:

• Avoid: Change the plan to eliminate the threat or its cause.

• Mitigate: Reduce the likelihood or impact.

• Transfer: Shift responsibility for some exposure to another party, while recognizing that transfer may not remove all consequences for the project.

• Accept: Take no proactive action beyond monitoring, or prepare a contingency in case the risk occurs. Acceptance can be appropriate when further action costs more than the exposure or when the risk is outside the team’s control.

A response may create a Secondary risk, a new uncertainty caused by that response, or leave a Residual risk after the response. Record and assess these risks too. Responses to opportunities can seek to capture or increase a potential benefit.

Assign one Risk owner to each risk. This person coordinates the response, monitors indicators, and reports status; action owners may also be assigned to specific tasks. The project manager remains responsible for overall project control. Naming a risk owner does not authorize that person to change approved scope, schedule, or budget baselines unilaterally.

Monitor and control risks

Review the risk register regularly in project status meetings and at phase or milestone transitions. For each priority risk, check whether its probability or impact has changed, whether response actions are complete, whether the risk has occurred, and whether new risks have emerged.

Track each Trigger, an observable condition that indicates a risk is becoming more likely or that a contingency should be activated. Close risks that are no longer relevant, but preserve their history for learning.

If a risk occurs, it becomes an issue. Implement the planned contingency or corrective action, assess effects on objectives, and use the project’s change-control process if baselines or approved plans need adjustment. Keep risk responses integrated with scope, schedule, and cost plans.

Apply the process to scenarios

For each scenario, develop a cause–event–effect risk statement, rate probability and impact using the team’s scale, choose a response, name an owner by role, identify a trigger, and state how the risk will be monitored.

• Supplier lead time: A component needed for integration comes from a single supplier whose delivery date is not confirmed. A late delivery could delay a milestone. Possible considerations include alternate suppliers, early confirmation, or schedule contingency.

• Unclear requirements: Stakeholders disagree about what counts as acceptance. Rework may increase cost and push testing later. Possible considerations include an early review and signed acceptance criteria; specify who has authority to resolve disagreements.

• Specialist availability: A specialist is shared across projects and may not be available during a critical activity. Possible considerations include booking the resource, cross-training a backup, or sequencing work differently.

• Possible opportunity: A reusable tool may become available before development begins. It could reduce effort, but its suitability is not yet verified. State how to test the tool and how to avoid depending on it before it is proven.

Worked supplier example: “Because the supplier has not confirmed the component’s delivery date, the component may arrive after integration begins, delaying the milestone and increasing labor cost.” The procurement lead could own the risk, confirm the delivery date at a set checkpoint, and qualify an alternate supplier if the date slips. The project manager should review risk status and any proposed cost or schedule changes. Record any added cost of the alternate source and assess whether switching suppliers creates new quality or compatibility risks.