What do you do when a project is on track but a sudden problem threatens to derail it completely? This chapter explains how to spot those problems before they happen (risk management) and how to fix them when they do happen (issue resolution), which is essential for passing the PMP exam because it tests your ability to keep a project moving forward no matter what surprises come up.
Jump to a section
A simple way to picture Risk Management and Issue Resolution
You decide to host a backyard get-together, and this decision immediately leads to a need to manage uncertainty. That uncertainty is called risk, and how you handle it determines whether your party is a success or a disaster.
First, you identify risks: what if it rains? What if the grill runs out of gas mid-cooking? What if your vegetarian friend finds nothing to eat? These are all potential future problems that *might* happen, but haven't happened yet. You then analyse them: rain is highly likely and would ruin the outdoor seating, so it's a high-priority risk. Running out of gas is less likely if you have a full tank, so it's a medium priority. You then plan responses: you buy a large pop-up canopy to mitigate the rain risk, buy a spare gas canister to mitigate the gas risk, and prepare a vegetable platter to mitigate the dietary risk. This is your risk management plan.
On the day of the party, a risk becomes reality: it starts drizzling. You immediately deploy the canopy. That's risk response execution. But then a new problem appears that you didn't anticipate: a neighbour complains about the noise at 9 PM. This is an issue — a current problem that is already happening. You cannot mitigate it in advance; you must resolve it now by turning down the music or moving the party inside. This distinction — managing the future (risks) versus managing the present (issues) — is the entire point of risk management and issue resolution.
Risk management and issue resolution are two sides of the same coin: keeping your project from failing. A risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives. An issue is a problem that has already occurred and needs immediate attention. The key difference is time: risks are future possibilities, issues are present realities.
Let us start with risk management. The process has four main steps: identify risks, analyse risks, plan risk responses, and implement risk responses. The goal is not to eliminate all risks — that is impossible — but to make informed decisions about which risks to act on and which to accept.
Identifying risks means listing everything that could go wrong (or right — positive risks are called opportunities). You use techniques like brainstorming with your team, reviewing historical data from similar projects, and creating checklists. For example, if you are building a mobile app, a risk might be that the app store rejects your submission, delaying the launch.
Analysing risks involves figuring out how likely each risk is and how big an impact it would have. This is often done with a probability and impact matrix, which is a grid that ranks risks as high, medium, or low priority. A risk that is very likely and would cause a huge delay (like a key developer quitting) becomes a high priority. A risk that is unlikely and would only cause a minor inconvenience (like a temporary internet outage) becomes a low priority.
Planning risk responses means deciding what you will do about each high- and medium-priority risk. The main response strategies for threats (negative risks) are:
Avoid: change the project plan to eliminate the risk entirely. For example, if a third-party vendor is unreliable, you switch to a more reliable vendor.
Mitigate: reduce the probability or impact of the risk. For example, you add extra testing to reduce the chance of software bugs.
Transfer: shift the financial impact of the risk to a third party, usually through insurance or a fixed-price contract. For example, you buy cyber insurance to cover the cost of a data breach.
Accept: acknowledge the risk and take no proactive action, often because it is low priority or the cost of action is too high. You may create a contingency reserve (a pool of money or time set aside to handle the risk if it occurs).
For positive risks (opportunities), the strategies are exploit (make sure it happens), enhance (increase its probability), share (partner with someone to capture it), and accept (do nothing but be ready to benefit).
Implementing risk responses is the action phase: you execute the planned responses as risks arise. You also monitor risks throughout the project, looking for new risks and reassessing existing ones. This is called risk monitoring and controlling.
Now, issue resolution is different. An issue is a problem that is already happening. It has zero uncertainty — it is a fact. For example, a server crashed, a team member quit, or a client changed a requirement after work had begun. Issues are managed through a process often called issue management or issue resolution. The steps are:
Identify the issue: someone reports a problem.
Log the issue in an issue log: a document that tracks what the issue is, who reported it, when it happened, its severity, and who is responsible for resolving it.
Analyse the issue: figure out the root cause and the impact on the project (schedule delay, cost increase, quality degradation).
Develop a response: decide on corrective action. This could be a workaround (a temporary fix to keep things moving), a change request (a formal proposal to alter the project baseline), or a corrective action (a fix that prevents recurrence).
Implement the response and verify that the issue is resolved.
The PMP exam emphasizes that risk management is proactive (you plan ahead) whereas issue resolution is reactive (you respond to a current problem). However, good risk management reduces the number of issues you face, because you have already identified and mitigated many potential problems.
Identify Risks
The project manager and team brainstorm all possible uncertain events that could affect the project. Tools like brainstorming, Delphi technique, checklists, and SWOT analysis are used. The output is a list of risks entered into the risk register, each with a unique ID and description.
Perform Qualitative Risk Analysis
Each risk is assessed for its probability of occurrence and potential impact on the project. Using a probability and impact matrix, risks are prioritised as high, medium, or low. This helps decide which risks need a detailed response plan.
Perform Quantitative Risk Analysis (if needed)
For high-priority risks on complex projects, numerical analysis techniques like decision tree analysis, Monte Carlo simulation, or sensitivity analysis are used to estimate the overall project risk exposure in terms of cost and schedule buffers.
Plan Risk Responses
For each high- and medium-priority risk, the team decides on a response strategy (avoid, mitigate, transfer, accept, or escalate for threats; exploit, enhance, share, or accept for opportunities). A contingency plan and fallback plan are documented, along with the risk owner who will implement the response.
Implement Risk Responses
When a risk trigger occurs (a signal that the risk is about to happen), the risk owner executes the planned response. The project manager updates the risk register with the status of the response and monitors for residual or secondary risks.
Monitor Risks
Throughout the project, the PM reviews the risk register regularly, identifies new risks, reassesses existing risks, and updates the probability and impact if conditions change. This step also involves tracking the effectiveness of responses and closing out risks that are no longer relevant.
Resolve Issues
When an issue arises, it is logged in the issue log with a description, severity, and assigned owner. The team performs root cause analysis, develops a corrective action or workaround, implements it, and verifies the issue is fully resolved before closing it.
An IT project manager at a mid-sized e-commerce company is overseeing the launch of a new mobile app. The project has a six-month timeline and a budget of £500,000. Here is how risk management and issue resolution play out in practice.
First, the PM holds a risk identification workshop with the development team, quality assurance testers, and marketing team. They brainstorm risks using a technique called SWOT analysis (Strengths, Weaknesses, Opportunities, Threats). They identify dozens of risks, including:
The app might not pass Apple's app store review (high probability, high impact).
A key developer might leave mid-project (medium probability, high impact).
The payment gateway integration might have security vulnerabilities (medium probability, high impact).
The marketing team might not have the app ready assets in time for the launch date (high probability, low impact).
The server costs might exceed budget due to unexpected user traffic (low probability, high impact).
The PM analyses these risks using a probability and impact matrix. The app store rejection risk scores a 20 out of 25 on the risk matrix, making it a top priority. The PM plans a response: they allocate two extra weeks in the schedule for app store review resubmissions (contingency reserve) and hire an app store specialist consultant (avoidance strategy).
Six weeks into development, a risk becomes reality: the lead iOS developer resigns. This was a medium-priority risk, but it has now become an issue. The PM immediately logs it in the issue log with severity 'high' and assigns the lead Android developer to act as interim iOS developer while she contacts a recruitment agency. She also escalates to the project sponsor, informing them of a potential two-week delay. This is corrective action to an issue.
Simultaneously, the PM continues monitoring other risks. The payment gateway vendor releases a security patch, which reduces the security vulnerability risk. The PM updates the risk register to reflect this lower probability. She also identifies a new risk: the marketing team's new hire is learning the branding guidelines, which might slow down asset delivery. She adds this risk to the register and plans a minor mitigation by asking marketing to provide rough drafts early.
Two weeks before launch, a new issue arises: the app crashes on older iPhone models during beta testing. The PM convenes an urgent meeting with the QA lead and developers. They analyse the root cause: a memory leak in the image rendering library. The team develops a workaround (compressing images before loading) and a long-term fix (replacing the library in the next update). The PM logs the issue, implements the workaround, and updates the project documentation.
Throughout the project, the PM maintains a risk register and an issue log, both of which are reviewed weekly with the team. The risk register lists each risk, its probability, impact, response strategy, and owner. The issue log lists each issue, its discovery date, description, severity, assigned owner, and resolution status. By the launch date, 87% of identified risks have been managed (either avoided, mitigated, or transferred) and all 14 issues were resolved within their target resolution times. The app launches on time and within budget, demonstrating the value of proactive risk management and disciplined issue resolution.
The PMP exam dedicates significant weight to the Perform Quantitative Risk Analysis and Plan Risk Responses processes. You must memorise the difference between a risk and an issue, and know exactly which process is used for each. Here is what to focus on:
First, know the risk management processes in order: Identify Risks, Perform Qualitative Risk Analysis, Perform Quantitative Risk Analysis, Plan Risk Responses, Implement Risk Responses, and Monitor Risks. The exam loves asking which process comes next in a given scenario.
Second, understand the tools and techniques for each process. For Identify Risks, the exam often tests documentation reviews, brainstorming, Delphi technique (anonymous expert consensus), and SWOT analysis. For qualitative analysis, they test the probability and impact matrix and risk urgency assessment. For quantitative analysis, they test decision tree analysis (expected monetary value), Monte Carlo simulation, and sensitivity analysis (tornado diagram).
Third, know the risk response strategies thoroughly. The exam presents scenarios and asks you to identify which strategy is being used. Common traps: they describe 'avoiding' a risk when it is really 'mitigating' (e.g., adding testing is mitigation, not avoidance — avoidance means changing the plan so the risk cannot happen). They also love 'transfer' versus 'mitigate': buying insurance is transfer, buying a backup server is mitigate.
Fourth, understand the difference between a contingency reserve and a management reserve. A contingency reserve is for known-unknowns (risks you identified) and is managed by the project manager. A management reserve is for unknown-unknowns (risks you never imagined) and requires approval from management.
Fifth, know the issue resolution process: log, analyse, respond, verify. The exam rarely tests the full issue management process in depth, but they do test the distinction between a workaround (an unplanned fix for an issue, because no risk response existed) and a corrective action (a planned fix based on a risk response).
Common exam traps include:
They describe a risk that has already occurred and ask you to choose the next action. The correct answer is usually 'log it as an issue in the issue log', not 'update the risk register' (though you do update the risk register later).
They present a scenario where a risk's probability or impact changes mid-project and ask what to do. The correct answer is to 'perform qualitative analysis again' or 'reassess the risk'.
They ask about 'residual risk' (risk that remains after a response is implemented, e.g., a mitigation reduces the risk but does not eliminate it completely) versus 'secondary risk' (a new risk created by a risk response, e.g., switching vendors introduces a different risk).
They test 'fallback plan' (a plan B used if the primary response fails) versus 'contingency plan' (the primary response for a risk).
Memorise the risk register fields: risk ID, description, probability, impact, risk score (probability x impact), response strategy, trigger (what signals the risk is about to happen), owner, and status. The issue log fields: issue ID, description, date identified, severity, owner, status, resolution date.
A risk is an uncertain future event that may positively or negatively affect the project, while an issue is a current problem that is already happening and requires immediate corrective action.
The five risk response strategies for threats are avoid, mitigate, transfer, accept, and escalate, each with a distinct application scenario that the PMP exam will test.
The risk register tracks identified risks with their probability, impact, response owner, and trigger, whereas the issue log tracks current problems with severity, status, and resolution date.
Contingency reserves are set aside for known-unknowns (risks you identified) and can be used by the project manager without additional approval, while management reserves require sponsor authorisation.
Residual risk is the leftover risk after a response is implemented, and secondary risk is a completely new risk created by that response — both must be documented and monitored.
Risk management is a continuous cycle of identifying, analysing, responding, and monitoring, not a one-time planning activity at the start of the project.
These come up on the exam all the time. Here's how to tell them apart.
Risk
Uncertain future event that may or may not happen
Documented in risk register with probability and impact
Managed proactively with planned responses
Issue
Certain current problem that has already occurred
Documented in issue log with severity and resolution
Managed reactively with corrective action or workaround
Avoid (Risk Response)
Eliminates the risk by changing the project plan
Example: choosing a different vendor to avoid the risk of a strike
Zero residual risk remains after avoidance
Mitigate (Risk Response)
Reduces the probability or impact of the risk
Example: adding backups to reduce the impact of data loss
Residual risk remains after mitigation
Contingency Reserve
Set aside for known-unknowns (identified risks)
Part of the project cost baseline
Controlled by the project manager without sponsor approval
Management Reserve
Set aside for unknown-unknowns (unidentified risks)
Not part of the project cost baseline
Requires sponsor or management approval to use
Qualitative Risk Analysis
Subjective assessment of probability and impact
Uses a probability and impact matrix with ratings like high/medium/low
Performed on all projects as part of standard process
Quantitative Risk Analysis
Numerical analysis using actual data or simulations
Uses tools like Monte Carlo simulation or decision tree analysis
Performed only on high-priority risks in complex projects
Residual Risk
Remaining risk after a response is implemented
Example: after adding firewalls, a small risk of cyberattack remains
Exists because no response can eliminate all risks
Secondary Risk
New risk created directly by implementing a response
Example: switching vendors introduces a new delivery delay risk
Must be identified and managed separately from the original risk
Mistake
Risks are always negative; issues are the same as risks but worse.
Correct
Risks can be positive (opportunities) or negative (threats). Issues are always negative because they are current problems that need resolution. You manage risks proactively and issues reactively.
Beginners associate 'risk' with danger, so they forget about opportunities. The IT industry often uses 'risk' to mean only threats, but PMP explicitly includes positive risks.
Mistake
Once you plan a risk response, you are done with that risk.
Correct
Risk management is a continuous process. You must monitor risks throughout the project, reassess their probability and impact, and update the risk register. A planned response may become obsolete if conditions change.
People treat planning as a one-time activity because many non-project contexts (like personal insurance) have a one-off decision. Projects are dynamic, so risks change constantly.
Mistake
All risks can be eliminated through careful planning.
Correct
No project can eliminate all risks. Some risks are unknown (unknown-unknowns) and cannot be identified in advance. Even known risks may be accepted because the cost of mitigation exceeds the potential impact.
This comes from a perfectionist mindset. Beginners want to believe they can control everything. The PMP exam reinforces that some uncertainty is unavoidable and must be accepted.
Mistake
An issue log and a risk register are the same thing, just for different time periods.
Correct
They are separate documents with different structures. The risk register lists future uncertain events with probability and impact scores. The issue logs lists current problems with severity and resolution actions. They are not interchangeable.
Both documents track things that could affect the project, so beginners conflate them. However, PMP treats them as distinct artifacts with distinct processes.
Mistake
The project manager is solely responsible for identifying and managing all risks.
Correct
Risk management is a team effort. The project manager facilitates the process, but every team member, stakeholder, and subject matter expert should contribute to identifying and monitoring risks. A PM who tries to do it alone will miss critical risks.
This stems from a traditional hierarchical view of project management where the PM is the 'boss' who makes all decisions. Modern agile and iterative approaches emphasize collective ownership.
Mistake
Quantitative risk analysis (using numbers like Monte Carlo simulation) is always required for every project.
Correct
Quantitative risk analysis is optional and typically used only for large, complex, or high-stakes projects. Most projects rely on qualitative analysis (probability and impact matrix) which is simpler and sufficient.
Beginners assume that because quantitative analysis sounds more sophisticated and 'scientific', it must always be performed. PMP explicitly states it is performed only when needed and when data is available.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A risk is an uncertain event that has not happened yet but could affect the project positively or negatively. An issue is a problem that has already occurred and requires immediate resolution. You manage risks proactively; you react to issues.
Yes, you should document all identified risks in the risk register, even low-priority ones. This ensures they are not forgotten and can be monitored. However, you may choose to accept low-priority risks without detailed response plans.
A workaround is an unplanned fix for an issue when no risk response existed or the planned response failed. A corrective action is a planned fix that was part of a risk response strategy. Workarounds are reactive; corrective actions are proactive.
Yes, when a risk actually occurs, it becomes an issue. For example, the risk 'server might crash' becomes an issue 'server crashed' as soon as it happens. You then log it in the issue log and resolve it using your planned response or a workaround.
A contingency reserve is money or time set aside for known-unknowns (risks you identified). It is part of the project budget and controlled by the project manager. A management reserve is for unknown-unknowns (unforeseeable events) and requires sponsor approval to use.
There are five strategies for threats: avoid (remove the risk entirely), mitigate (reduce its probability or impact), transfer (shift financial risk to a third party), accept (take no action, but set aside a contingency), and escalate (pass to someone with more authority).
Secondary risk is a new risk that is created as a direct result of implementing a risk response. For example, if you mitigate the risk of a vendor delay by switching to a new vendor, the new vendor may introduce a quality risk. You must identify and manage secondary risks.
You've finished Risk Management and Issue Resolution. Continue through the PMP study guide to build a complete picture of the exam.
Done with this chapter?