All courses > Business administration > Project management ::

PMP Exam Prep Companion: Risk and Issues—Uncertainty, Responses, and the Right Next Step

Capítulo 9

Estimated reading time: 9 minutes

Risks vs. Issues: Same Topic, Different Time

Risk is an uncertain event or condition that might happen in the future and would affect objectives (scope, schedule, cost, quality, benefits). It can be a threat (negative) or an opportunity (positive).

Issue is a current problem: something has already happened, is happening now, or is certain enough that uncertainty is no longer the main factor. Issues require immediate action, escalation if needed, and tracking to closure.

Aspect	Risk	Issue
Timing	Future, uncertain	Now (or already occurred)
Language clues	“might,” “could,” “if,” “potential,” “possible”	“is delayed,” “failed,” “missing,” “defect found,” “vendor didn’t deliver”
Main artifact	Risk register (and risk report)	Issue log
Primary action	Plan responses; monitor triggers	Assign owner; resolve; track to closure
Exam trap	Treating a risk like an issue (or vice versa)	Jumping to a fix without logging/communicating

Quick test

If uncertainty remains: it’s a risk.
If it’s already true (or happening): it’s an issue.

Risk Identification: Finding What Could Happen (Threats and Opportunities)

Risk identification is about building a usable list of uncertainties that matter—then keeping it current as the project changes.

Step-by-step: identify risks in a practical way

Start with objectives and assumptions. Ask: “What must be true for success?” Each assumption can hide a risk.
Scan common sources. Requirements clarity, technical complexity, suppliers, approvals, environment, staffing, dependencies, interfaces, security/compliance.
Use structured prompts. Examples: “If X happens, then Y impact occurs.” “What could cause rework?” “What could accelerate delivery?”
Capture both threats and opportunities. Opportunities are not “nice-to-haves”; they can be planned and pursued.
Document clearly in the risk register. Include cause, event, effect, owner, triggers, and initial response ideas.

Risk statement format (exam-friendly)

Use a clear cause–event–impact structure:

Because <cause>, <event> may occur, resulting in <impact>.

Example (threat): “Because the vendor is onboarding new staff, integration defects may increase, resulting in rework and schedule slip.”

Continue in our app.

Listen to the audio with the screen off.
Earn a certificate upon completion.
Over 5000 courses for you to explore!

Or continue reading below...

Download the app

Example (opportunity): “Because the team has reusable components, development may be faster, resulting in earlier release and cost savings.”

Qualitative Risk Analysis (High Level): Prioritize What Matters

Qualitative analysis is a fast way to rank risks so the team focuses effort where it pays off. On the exam, this often appears as “what should the PM do next?” when there are many risks and limited time.

Step-by-step: qualitative analysis at a high level

Estimate probability and impact. Use a simple scale (e.g., Low/Medium/High) or 1–5.
Consider urgency and proximity. A medium risk happening next week may outrank a higher risk that’s far away.
Check detectability and triggers. If you can’t detect it early, you may need stronger planning.
Assign an owner. Every significant risk needs someone accountable to monitor triggers and execute responses.
Prioritize and decide response intensity. Top risks get detailed responses; low risks may be accepted with monitoring.

Simple probability–impact thinking

In exam scenarios, you may not see a full matrix. You can still reason:

High probability + high impact → plan a strong response (avoid/mitigate/transfer; exploit/enhance/share).
Low probability + low impact → accept and monitor.
High impact but low probability → consider transfer (threat) or contingency planning.

Risk Response Strategies: Choose the Right Lever

Response strategies differ for threats vs. opportunities. A common exam mistake is using a threat strategy on an opportunity (or the reverse).

Threat response strategies (negative risks)

Avoid: Change the plan so the risk can’t happen (remove the cause). Example: remove a risky feature from scope or choose a proven technology instead of an experimental one.
Mitigate: Reduce probability and/or impact. Example: add automated tests to reduce defect risk; run a prototype to reduce technical uncertainty.
Transfer: Shift financial impact/ownership to a third party (not eliminating the risk). Example: insurance, warranties, fixed-price contract for a well-defined deliverable.
Accept: Acknowledge and monitor; take action only if it occurs. Acceptance can be passive (no specific plan) or active (contingency plan and reserves).

Opportunity response strategies (positive risks)

Exploit: Make sure the opportunity happens. Example: assign your best engineer to ensure a performance improvement is delivered.
Enhance: Increase probability and/or benefit. Example: add a small spike to increase chances of reusing a component.
Share: Partner with another party to capture the benefit. Example: collaborate with a vendor who has a specialized accelerator library.
Accept: Take advantage if it happens; no extra effort to force it.

Choosing a strategy: quick decision cues

If the risk is unacceptable and you can change the plan: avoid.
If you can reduce likelihood/impact cost-effectively: mitigate.
If a third party can better handle the financial exposure: transfer.
If it’s minor or too expensive to address: accept (often with monitoring).
If it’s a valuable opportunity and you want certainty: exploit.

Contingency vs. Fallback: Plan A vs. Plan B

These terms show up frequently in exam questions about “what do you do when the risk occurs?”

Contingency plan

A contingency plan is the planned response you execute if a specific risk event occurs (or if a trigger indicates it’s imminent). It is tied to a known risk and is part of active acceptance or other strategies.

Example: “If the permit approval is delayed beyond 10 business days, use the pre-approved alternate site layout.”

Fallback plan

A fallback plan is what you do if the contingency plan doesn’t work or is no longer viable. It’s a backup to the backup.

Example: “If the alternate site layout is rejected, lease temporary modular space for 3 months.”

Exam clue

Contingency answers “What will we do if the risk happens?”
Fallback answers “What will we do if our contingency fails?”

The “If/Then” Exam Approach: A Reliable Next-Step Pattern

Many PMP questions are really testing whether you can choose the correct next action without skipping governance steps. Use this pattern to avoid rushing into a solution.

If/Then decision flow

IF the situation is uncertain and future-oriented → treat it as a RISK (log/assess/plan/monitor).  IF the situation is happening now or already occurred → treat it as an ISSUE (log/assign/resolve/escalate).  THEN check: is there an approved plan already?  IF yes → execute the plan (risk response or issue resolution approach).  IF no → analyze options, get approval as needed, then implement.  THEN update the appropriate register/log and communicate to stakeholders.

What “check if there is a plan” means in practice

For a risk: Is there a documented response (contingency), an owner, triggers, and reserves?
For an issue: Is there an agreed workaround, escalation path, or corrective action already defined?

What to update and communicate (typical exam expectations)

Risk register: new risks, updated probability/impact, response owner, triggers, response status.
Issue log: issue description, priority, owner, due date, actions, decisions, status, closure notes.
Communications: inform impacted stakeholders, especially when scope/schedule/cost/quality objectives are affected or decisions are required.

Scenario Set 1: New Threat Discovered (Not Yet Happened)

Scenario

During a vendor status call, you learn the supplier’s region may face a port strike next month. No shipments are delayed yet.

Apply the If/Then approach

Identify: This is a risk (future, uncertain).
Check plan: Is there already a response for supply disruption?
Qualitative analysis: Estimate probability (based on credible indicators) and impact (lead time, critical path exposure).
Select response: Likely mitigate (order earlier, qualify alternate supplier) or transfer (contract terms, expedited shipping clauses), or accept with contingency if low impact.
Document & communicate: Update the risk register, assign an owner, define triggers (e.g., strike announcement), and inform stakeholders affected by procurement lead times.

Exam-style trap to avoid

Don’t treat it as an issue and start expediting shipments immediately without first logging, assessing, and selecting an appropriate response based on priority and cost.

Scenario Set 2: Realized Risk (The Risk Happened)

Scenario

You had a risk: “Key developer may leave.” It occurs—your developer resigns today.

What changes now?

The uncertainty is gone. The event has occurred, so you now have an issue to manage (resource gap) even though it originated as a risk.

Apply the If/Then approach

Identify: It is now an issue (current problem).
Check plan: If you had a contingency plan (cross-training, backup resource, contractor bench), execute it.
Implement: Reassign work, onboard replacement, adjust near-term commitments as needed.
Update: Mark the risk as occurred/closed (or update residual risks), and log the active issue with owner and actions.
Communicate: Inform impacted stakeholders about impacts and the response being executed.

Contingency vs. fallback in this scenario

Contingency: Activate the pre-identified backup developer and redistribute tasks.
Fallback: If backup is unavailable, contract a specialist and reduce scope of the next increment to protect the deadline.

Scenario Set 3: Repeated Issues (A Pattern, Not a One-Off)

Scenario

For the third sprint in a row, the same type of defect appears in the payment module. The team fixes each defect, but the pattern continues.

How to think about it

Each defect found is an issue (it exists now).
The repeated pattern suggests an underlying risk (ongoing probability of recurrence) and possibly a process or design weakness.

Apply the If/Then approach

Identify: Log the current defect as an issue and assign ownership for resolution.
Check plan: If there is a defined defect management approach, follow it.
Then broaden: Create or update a risk about recurring defects (cause: unclear requirements, weak test coverage, fragile architecture).
Qualitative analysis: Probability is high (it already happened repeatedly); impact may be high (rework, customer trust, release risk).
Response: Mitigate by adding targeted automated tests, improving code reviews, clarifying acceptance criteria, or refactoring the module.
Update & communicate: Update issue log and risk register; communicate trend and mitigation plan to stakeholders who care about release readiness.

Common Exam Signals and What They Usually Mean

Question wording	Likely classification	Likely next step
“may happen,” “could occur,” “potential”	Risk	Log in risk register, assess qualitatively, plan response
“has occurred,” “is happening,” “is late,” “failed”	Issue	Log in issue log, assign owner, implement workaround/corrective action
“What should the PM do next?” with a known response already defined	Risk or issue	Execute the plan first, then update logs/registers and communicate
“Contingency plan failed”	Risk response escalation	Use fallback plan, then update documentation and communicate

Now answer the exercise about the content:

A supplier’s region may face a port strike next month, but no shipments are delayed yet. What is the most appropriate next step for the project manager?

You are right! Congratulations, now go to the next page

You missed! Try again.

This is future-oriented and uncertain, so it is a risk. The next step is to document it, assess it qualitatively, assign ownership and triggers, and plan a response rather than acting as if the problem has already occurred.