Key Concepts
Projects build new things, so surprises are expected, and planning for them is the responsible alternative to hoping for the best. Risk management asks four questions: what might happen, how likely is it, how bad or good would it be, and what can we do about it now. The level of formality changes with the project; the questions do not.
Since projects build new products and services, we should expect surprises along the way. Some are pleasant; most are not. Rather than just hoping for the best, the responsible thing is to plan for these uncertainties. That is what risk management is for. The discipline applies whether the project is short or long, predictive or agile, simple or highly regulated. The level of formality changes; the underlying questions do not. What might happen, how likely is it, how bad would it be, and what can we do about it now?
Let’s start with some definitions:
Risk
An uncertain event or condition that, if it occurs, will have a positive or negative effect on the project. Positive risks are called opportunities; negative risks are called threats. For an outdoor picnic at a petting zoo grand opening, rain is a threat (lower attendance), and unusually warm weather is an opportunity (extra ice-cream sales).
Risk Trigger
An event or situation that suggests a risk is about to occur or has occurred. Triggers are warning signs or risk symptoms. Dark storm clouds gathering at the picnic grounds is a trigger for the rain risk.
Issue
A risk that has occurred. It is no longer a possibility of harm, loss, or gain, so we cannot call it a risk any more. It has converted from risk to issue. Heavy rain at the picnic is the issue.
Risk Appetite
Risk appetite is the amount of uncertainty an organization or person is willing to accept in anticipation of a reward. Some organizations have a low appetite for risk and prefer low-risk projects. Others are happy to pursue a variety of initiatives knowing only a small percentage will be successful.
Risk Threshold
Risk threshold (formerly called risk tolerance) is the measure of acceptable variation around an objective that reflects the risk appetite of the organization and stakeholders. For example, a 10% cost overrun may be acceptable; anything above that may not be.
Risk Management Processes
The PMBOK® Eighth Edition outlines the following risk processes. These steps provide a valuable framework for reviewing risk management activities.
[The flow of this module follows the ECO Tasks, but referring back to this process flow will help you see where elements fit in the whole process.]
3.5.1 Identify Risks
Identify Risks
Identifying risks deals with finding individual project risks and sources of overall project risk, then documenting their characteristics. The activity combines several techniques.
Expert Judgment
Use individuals or groups who, based on their experience and domain expertise, can generate insights into risks. Engage the team in this activity. The doers of the work often have better insights into what can go wrong than the coordinators do.
Brainstorming
Structured workshops with multidisciplinary participants generate and record potential risks. Brainstorming works best when the group is diverse and the person running the session is willing to push past the first round of obvious answers.
Checklists
Lessons learned documents, old risk registers, and issue logs from similar projects all serve as starting checklists. Sometimes generic industry lists of common risks are available to prompt ideas. Checklists are an efficient way to bring forward what the organization already knows can go wrong.
Interviews
Risks can be identified by interviewing project participants beyond the immediate team, other stakeholders, and subject matter experts. Interviews surface risks that group sessions miss because some people are more comfortable raising concerns one-to-one.
Root Cause Analysis with Cause and Effect Diagrams
A technique designed to uncover the underlying risk. It often uses cause and effect diagrams such as fishbone diagrams. Working backwards from a known concern, the team explores what could be driving it, which often surfaces additional related risks.
Assumption and Constraint Analysis
Project estimates of benefits and value delivered are based on assumptions and constraints. This activity examines these assumptions and constraints and asks what might jeopardize them or make them invalid. The exercise turns implicit project bets into explicit risks.
SWOT Analysis
SWOT (Strengths, Weaknesses, Opportunities, Threats) examines the project from each of these perspectives, starting with the strengths and weaknesses of the project, organization, and business area. From the strengths, opportunities are investigated; from the weaknesses, threats are examined.
Document Analysis
Risks can be identified by reviewing project documents such as plans, constraints, previous project files, contracts, agreements, and technical specifications. Uncertainty, ambiguity, or inconsistencies in these documents are often indicators of risks worth recording.
3.5.2 Analyze Risks
Once risks are identified, we analyze them to understand which deserve focused attention. Analysis happens in two passes: a qualitative pass that prioritizes the list, and a quantitative pass for the risks where numbers add value.
Qualitative Risk Analysis
Qualitative risk analysis is the process of categorizing and prioritizing the individual project risks for further analysis. It assesses probability of occurrence, impact, and other characteristics.
There are several ways to classify risks. Two popular approaches are effect-based and source-based:
- Effect-based – classifies by the effect of the risk on:
- time
- cost
- scope
- quality
- resources.
- Source-based – classifies by where the risk originates:
- internal to the project
- external, technical
- non-technical
- industry-specific
- generic.
Assess Impact and Probability
For each risk identified, assign impact and probability scores. We are usually working at the High/Medium/Low level here; numerical refinement happens in quantitative analysis.
For a threat about having no experienced people to help put up the big-top tent for a launch event, we might assign High probability and High impact.
Some organizations also calculate Severity (or Risk Exposure) as the product of Impact and Probability. Risks can then be ranked by severity, and we may decide not to actively manage the lowest-probability, lowest-impact risks at all.
Risks can be ranked by their severity (risk exposure) scores, and we may decide not to actively manage low probability, low impact risks.
Quantitative Risk Analysis
Quantitative risk analysis numerically analyzes the combined effect of identified individual risks and other sources of uncertainty on overall project objectives. Common techniques include:
Expected Monetary Value (EMV)
By assigning a financial value to a risk impact and a percentage to its probability, we can calculate an expected monetary value.
If we assess the probability of a hot day at our picnic at 25% and our estimate for ice-cream sales at $2,000, the EMV is 25% × $2,000 = $500.
Decision Tree Analysis
Decision trees show the consequences of different choices under uncertainty. They help compare options where each branch has its own probabilities and outcomes. The expected value of each branch can be calculated and compared, which gives a basis for choosing among approaches that look similar at first glance.
Monte Carlo Simulation
Monte Carlo simulation runs a project model thousands of times with varying inputs based on probability distributions. The output is a range of possible outcomes with the probability of each. It is particularly useful for schedule and cost analysis on projects where multiple risks interact.
3.5.3 Monitor and Control Risks
Monitor Risks is the process of monitoring the implementation of agreed-upon risk responses. It also covers tracking identified risks, identifying and analyzing new risks, and evaluating risk process effectiveness throughout the project. Without monitoring, the risk register becomes a snapshot from project start that bears no resemblance to current reality.
Risk Management is always an iterative process. Even with traditional predictive projects the final Monitor Risks step includes the ongoing assessment and processing of risks. So, rather than viewing the risk management process as a linear, single-pass procedure, it can be more helpful to view it as iterative.
Now we see the Monitor Risks step links back into the ongoing process of Identify Risks that looks for new or escalating risks and runs them through the risk management process. The process is cyclical and iterative until the project completes. Then it can be handed to operations or program management to assist with long-term benefits management.
Within agile life cycle projects, these activities repeat every iteration.
Risk Audits
Risk audits review the effectiveness of risk responses and the risk management process itself. They ask whether responses are working, whether new risks have emerged, and whether the way we are running risk management is fit for the project as it actually exists today.
Variance and Trend Analysis
Variance and trend analysis on schedule, cost, and quality measures often surfaces risks before someone names them. A growing schedule variance trend is the project telling us something. The discipline is to read it as a risk signal rather than as a presentation problem.
Reserve Analysis
Reserve analysis tracks the contingency reserve over the project life cycle. As risks occur and we draw against the reserve, we want to confirm there is still enough left to handle the risks ahead. A reserve that is depleting faster than risks are retiring is a leading indicator of trouble.
3.5.4 Develop a Risk Management Plan
The Risk Management Plan describes how the risk management process will be tailored and undertaken for the project. It can be a stand-alone document or a section of the project management plan. We tailor the plan to the project; the process for a six-person team erecting a big-top tent one afternoon will differ from a 300-person, 18-month medical device project. Common sections include:
- Risk Strategy – the general approach to managing risk on this project.
- Methodology – specific approaches, tools, and data sources for performing risk management.
- Roles and Responsibilities – who will be responsible for each type of activity in the plan.
- Funding – funds needed for risk management activities, including contingency and management reserves.
- Timing – when and how often risk management processes will be performed, and how risk activities are included in the project schedule.
- Risk Categories – groupings for individual project risks. Common categories include technical (scope, technology, technical processes), management (organizational structure, recruiting, communications), commercial (suppliers, vendors, procurement, subcontractors), and external (exchange rates, competition, regulatory). These categories can be visualized in a Risk Breakdown Structure (RBS).
- Stakeholder Risk Appetite – description of stakeholder risk appetites and the thresholds around what they accept for each project objective. For example, up to two-weeks variance around scheduled release dates.
- Definitions of Probability and Impact – specific to the project context and reflecting key stakeholder appetite. We may generate our own definitions or start from organizational ones.
- Probability and Impact Matrix – a table that combines probability and impact for both threats and opportunities, showing severity.
For example, we might estimate the threat of heavy rain at the picnic to have an Impact score of Very High (0.8) and a Probability of Moderate (0.5). Severity is the product of Impact and Probability.
Severity = Impact x Probability
= 0.8 x 0.5
= 0.4
(Shown with the red ”R” above)
Likewise, we may rate the opportunity of “Warm enough to sell ice-cream” as Impact Moderate (0.2) and Probability Low (0.3), giving a Severity of 0.2 x 0.3 = 0.06 shown with “IC”.
- Reporting Formats – how the outcomes of the risk management process will be documented, analyzed, and communicated. This includes the format and fields of the risk register.
- Tracking – how risk activities will be recorded and how the risk management process will be audited.
All of these sections collectively make the Risk Management Plan.
Some small agile projects do not produce a Risk Management Plan. Instead, they just create a risk list. By doing so, they accept any risk management approach described in the project charter (which for an agile project is likely brief also), or provided by the PMO or Agile Community of Practice. While agile methods may appear to not document their approach to handling risks, it is a core part of prioritizing work and evaluating progress.
Agile projects prioritize user stories based on business value and risk, aiming to drive down risk (avoid or mitigate threats) early in the life cycle. Practices such as risk-based spikes, risk-adjusted backlogs, and risk burndown graphs are used to address and monitor risks throughout the project life cycle.
3.5.5 Maintain a Risk Register
(For example, poor IT security).
After the identification activities, risks are documented in the Risk Register. The level of detail varies based on size, complexity, and criticality of the project. As a minimum, the risk register should contain:
- List of identified risks – an ID for unique tracking and a description of the risk.
- Potential risk owner – someone identified to track, monitor, and potentially help manage the risk.
- List of potential risk responses – where risk responses were identified, they are recorded for consideration during the Plan Risk Responses stage.
On larger projects the register also captures probability, impact, severity, trigger conditions, response strategy, residual risk, and current status (open, monitoring, retired, occurred).
IT Security Risks
IT security has become one of the most common risk register entries on modern projects. Examples that should sit in plain sight on the register include:
- Unauthorized access to customer data through inadequate authentication controls
- Vulnerabilities introduced by third-party libraries or vendor integrations
- Loss of operational data due to insufficient backup and recovery design
- Phishing or social engineering attacks against project team members during build
- Misconfigured cloud services exposing data to the public internet
“Poor IT security” is rarely a single risk; it is a category that breaks down into specific, ownable items. Naming them lets specific people own and respond to them.
Risk-Adjusted Backlogs
Risk-adjusted backlogs is the name given to backlogs that have risk response activities incorporated into them. They are created by working with the Product Owner to add threat avoidance and mitigation activities and opportunity enablement work into the backlog.
It is a collaborative discussion between the Scrum Master or team representatives and the product owner. The team can explain the risk impact, should it occur and the product owner estimates and compares the expected monetary value of a risk with the value of the stories in the backlog.
Ultimately it is the product owner who prioritizes the backlog. However, when they learn about the potential impacts of risks, they can decide if and where risk response action should be placed.
By avoiding or reducing threats closer to their identification, the horizon of risk that the project is exposed to shortens. In addition, by making changes earlier in the lifecycle, the costs of changes are reduced. On the flip side, capitalizing on opportunities is like getting investments done early; they have longer to accumulate. These are the compounding benefits of early and rapid risk & opportunity management.
Getting the risk response actions into the backlog is how these tasks are scheduled and undertaken. We want to ensure that all our risk management work is not supplemental to the project plan but baked right in. All too often, risk management is an activity done upfront or alongside the project but never really integrated into the day-to-day activities of the project. By inserting these new stories into the backlog, we drive risk management actions from analysis to action.
3.5.6 Execute a Risk Management Plan
(For example, risk response for security and managing sustainability risks.)
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
Plan Risk Responses develops options, selects strategies, and agrees actions to address overall project risk exposure and to treat individual project risks. Spending the time and cost to identify and analyze risks but then not doing enough to avoid or reduce threats, or to exploit opportunities, is wasteful and demoralizing. Risk responses should be added to the project plan or product backlog so they get implemented when needed.
Threat Response Strategies
- Escalate – transfer to someone outside the project. Convince the powers that be that the risk is significant enough to be handled at the program or portfolio level.
- Avoid – take evasive action. Find a way to eliminate the source of the risk. Use a different approach or technology that does not contain the risk.
- Transfer – move the risk to a group better equipped to handle it. This can include taking out insurance, which exchanges exposure for a known premium.
- Mitigate – make the risk smaller. Through actions, reduce the probability of the risk occurring, the impact if it does, or both.
- Accept – for low-priority risks or those we cannot avoid or reduce, we may have to accept the risk. The best response is often a contingency reserve to handle the risk if it occurs.
Opportunity Response Strategies
Opportunities represent the positive things that can go in our favor. These we want to guarantee, make the most of and share with as many people as can benefit from them. Strategies include:
- Escalate – transfer to someone better able to confirm the opportunity occurs. Often someone with more influence or authority at program, portfolio, or sponsor level.
- Exploit – try to drive the probability up to 100% and maximize impact. Assign our best people to it early and give them what they need.
- Share – transfer the opportunity to others, inside or outside our organization, to maximize the value derived and captured.
- Enhance – similar to exploit but to a lesser degree. Increase probability and impact by working on the causes and prioritizing this work for early delivery.
- Accept – sometimes there is little we can do to increase the likelihood (such as good weather). We can be ready and prepared so we do not let it pass us by unrealized.
Security Risk Responses
IT security risk responses tend to be a blend of avoid, mitigate, and transfer. Avoid responses include not collecting sensitive data we do not need. Mitigate responses include encryption, access controls, code reviews focused on security, penetration testing during development, and rehearsed incident response procedures. Transfer responses include cyber insurance and using vetted third-party providers for high-risk capabilities such as payment processing. The discipline is the same as for any other risk: name the response, assign an owner, and add the work to the plan or backlog.
Sustainability Risk Responses
Sustainability risks have moved from a side concern to an explicit project category. These include emissions or pollution from project activities, supply-chain practices that conflict with the organization’s commitments, regulatory exposure from new environmental rules, and reputational risk from social or environmental harm. Responses follow the same threat strategies. Avoid means choosing a lower-impact material or process. Mitigate means redesigning to cut emissions or waste. Transfer means confirming the supplier carries the certifications and accountability we need. Accept with contingency means holding reserve to handle expected impacts the project cannot eliminate. Reporting against sustainability commitments is increasingly part of project governance, so the responses also have to feed measurable evidence back into the status reports the steering committee sees.
3.5.7 Communicate the Status of a Risk Impact on the Project
Risk identification, analysis, and response are wasted effort if the people who need the information do not have it. Communicating risk status is the discipline that closes the loop.
Useful risk communication has a few practical features:
- Audience-specific framing – team members need risks expressed as work in the backlog or plan; sponsors and the steering committee need risks expressed as business impact, exposure, and reserve consumption.
- Visible top risks – a Top-N risks list on a dashboard or information radiator confirms the most material risks stay in front of decision makers between formal reports.
- Trend over snapshot – a single risk score in isolation tells us little. The same score relative to last reporting period, or relative to the planned burndown, says whether the project is moving in the right direction.
- Reserve consumption – reporting how much contingency or management reserve has been used, and against which risks, gives governance the data to decide if a reserve top-up is needed.
- Triggered escalations – when a risk crosses an agreed threshold, escalation is automatic, not optional. The reporting cadence supports the escalation rule, not the other way around.
Risk Burndown Charts
Risk burndown charts plot total project risk exposure over time. As risks are retired (occurred and resolved, or no longer applicable), the line goes down. As new risks are identified, the line goes up. A flat or rising risk burndown deep into a project is a clear signal to leadership that something is not working as planned, even if every individual status indicator is green.
Deliverables and Tools
- Risk Management Plan – The document describing how risk management will be tailored and undertaken for the project, including strategy, methodology, roles, funding, timing, categories, definitions of probability and impact, the probability and impact matrix, reporting formats, and tracking.
- Risk Register – The repository of identified risks, including ID, description, owner, probability, impact, severity, trigger conditions, response strategy, residual risk, and current status.
- Risk Breakdown Structure (RBS) – A hierarchical decomposition of risk categories, typically covering technical, management, commercial, and external groupings.
- Probability and Impact Matrix – A table that combines probability and impact for both threats and opportunities to produce a severity rating used for prioritization.
- Risk Appetite and Risk Threshold – Risk appetite is the uncertainty an organization is willing to accept for a reward. Risk threshold (formerly tolerance) is the measure of acceptable variation around an objective that reflects that appetite.
- Risk Trigger – An event or situation indicating that a risk is about to occur or has occurred. Acts as a warning sign.
- SWOT Analysis – A risk identification technique examining the project from Strengths, Weaknesses, Opportunities, and Threats perspectives.
- Cause and Effect Diagram (Fishbone, Ishikawa) – A visual tool used in root cause analysis to surface underlying drivers behind a known risk or concern.
- Assumption and Constraint Analysis – Examination of project assumptions and constraints to identify what could invalidate them, turning implicit bets into explicit risks.
- Document Analysis – Review of plans, contracts, agreements, and technical specifications to surface uncertainty, ambiguity, or inconsistencies that may signal risks.
- Expected Monetary Value (EMV) – A quantitative technique that multiplies a risk’s probability by its financial impact to give an expected value.
- Decision Tree Analysis – A branching diagram that models decisions and their outcomes under uncertainty, with expected values calculated for each branch.
- Monte Carlo Simulation – A modelling technique that runs the project many times with varying inputs to produce a probability distribution of possible outcomes.
- Risk Audits – Structured reviews of the effectiveness of risk responses and the risk management process itself.
- Variance and Trend Analysis – Analysis of schedule, cost, and quality variance over time to surface risks before they are named.
- Reserve Analysis – Tracking of the contingency reserve over the project life cycle to confirm enough remains to handle the risks still ahead.
- Contingency Reserve and Management Reserve – Contingency reserve covers identified risks and sits within the cost baseline. Management reserve covers unknown unknowns and is controlled by the sponsor.
- Risk-Adjusted Backlog – A backlog where risk response activities are interleaved with feature work, so risk reduction is scheduled and delivered alongside value.
- Risk Burndown Chart – A chart plotting total project risk exposure over time. A flat or rising line late in a project is a leading indicator of trouble.
- Top-N Risks List – A visible list of the most material risks, kept in front of decision makers between formal reports.
Related Topics
- 2.1 Develop an integrated project management plan and plan delivery
- 2.2 Develop and manage project scope
- 2.5 Plan and manage procurement
- 2.6 Plan and manage finance
- 2.7 Plan and optimize quality of products and deliverables
- 9 Evaluate project status
- 3.1 Define and establish project governance
- 3.2 Plan and manage project compliance
- 3.3 Manage and control changes
- 3.4 Remove impediments and manage issues
- 3.8 Evaluate external business environment changes
- Sustainability and the 2026 PMP Exam: What Candidates Need to Know
- PMP Mind Map
FAQ
What is a risk?
An uncertain event or condition that, if it occurs, will have a positive or negative effect on the project.
Does risk management differ between agile and predictive projects?
The level of formality changes, but the underlying questions stay the same.
What are the core questions of risk management?
What might happen, how likely is it, how bad or good would it be, and what can we do about it now.
How does this task fit into the 2026 PMP exam?
Task 3.5 sits in the Business Environment domain of the 2026 Exam Content Outline. The 2026 PMP Exam page has the domain and task breakdown and what changed in the new exam.
