Risk Response vs. Issue Resolution: What Should the Project Manager Do Next?
admino
Risk Response vs. Issue Resolution: What Should the Project Manager Do Next?
Recognizing whether a situation is a risk or an issue is important on the PMP® exam.
But that is only the beginning.
The harder question is often:
Now that I understand what has happened, what should the project manager do next?
A candidate may correctly identify a risk but still choose the wrong response. Or recognize an issue and immediately jump to escalation, root-cause analysis, or change control before understanding what the situation actually requires.
The key is to determine where the scenario currently is in the response sequence.
Sometimes the project manager needs to analyze.
Sometimes an existing response should be implemented.
Sometimes the issue needs investigation.
And sometimes the decision belongs to someone else.
The goal is not to memorize one universal response.
It is to identify what has already happened, what preparation already exists, and what action logically belongs next.
1. Start With the Basic Distinction
The core difference is simple:
Risk → uncertainty
Issue → present reality
A risk is something that may happen.
An issue is something that has happened or already exists.
For example:
A critical supplier may miss the delivery date.
That is a risk.
Now suppose:
The supplier confirms that the shipment will be three weeks late.
The uncertainty is gone.
The project now has an issue.
But PMP questions often go one step further:
What should the project manager do next?
That depends on more than the label.
2. Risk Response Is Proactive
Risk management prepares the project for uncertainty.
When a risk is identified, the team may:
- analyze probability and impact,
- prioritize the risk,
- determine a response,
- assign a risk owner,
- identify triggers,
- prepare contingency actions,
- monitor the risk.
Consider:
A project depends on regulatory approval. The team identifies a risk that approval may be delayed and develops an appropriate response.
At this stage, the event has not necessarily happened.
The team is preparing for what might happen.
That is risk response.
3. Issue Resolution Deals With What Exists Now
Now suppose:
The regulatory approval has been delayed by six weeks.
The project manager is no longer asking:
“What if approval is delayed?”
The question is:
“Approval is delayed. What do we do now?”
Issue resolution may involve:
- understanding the impact,
- investigating the cause,
- determining options,
- assigning responsibility,
- taking corrective action,
- communicating with stakeholders,
- escalating when appropriate.
The distinction is:
Risk management prepares for uncertainty. Issue management responds to reality.
4. When the Trigger Occurs, the Sequence Changes
This is where scenario questions become more interesting.
Suppose the team previously identified this risk:
A specialized supplier may be unable to deliver a component on time.
The team then:
- analyzed the risk,
- assigned an owner,
- defined a trigger,
- created an approved contingency response.
Later, the supplier confirms that it cannot deliver.
What should the project manager do?
A tempting answer may be:
Perform another risk analysis.
But the scenario has already moved beyond that stage.
The risk was identified.
The response was planned.
The trigger has occurred.
If the approved response is still appropriate, the logical next step may be to activate it.
A risk trigger is an identified condition or event that signals a change in the risk situation and may indicate that a planned response should be activated.
This reflects a recurring Project Reasoning Lab principle:
Do not solve an earlier stage of the problem when the scenario has already moved beyond it.
5. Not Every Issue Has a Planned Response
Now consider:
During testing, the team discovers an unexpected integration failure that was never identified as a risk.
There may be no existing contingency response.
The project manager should not pretend one exists.
The first appropriate steps may instead include:
- understanding what happened,
- assessing impact,
- investigating the cause,
- identifying options,
- determining the appropriate response.
This creates an important distinction:
Known risk with a valid planned response
The next step may be to execute the response.
New issue with no prepared response
The next step may be to assess and determine the resolution.
The word issue does not automatically tell you what to do.
The context does.
6. Avoid Automatic Responses
Several PMP answers can sound correct because they involve familiar project-management actions.
But each belongs only in the right situation.
Root-Cause Analysis
Useful when the cause must be understood before a lasting response can be chosen.
But it is not automatically the first step in every issue.
If an approved recovery procedure exists and immediate restoration is required, the response may come first.
Change Request
Relevant when the chosen response requires a controlled project change.
An issue does not automatically mean a change request is required.
Escalation
Appropriate when authority, governance, compliance, contractual limits, or organizational boundaries require another level of decision-making.
An issue does not automatically need escalation.
A better question is:
What does this situation require now?
7. Authority Can Determine the Next Step
Suppose an issue requires an additional $500,000 beyond the project manager’s approved authority.
The project manager may:
- assess the issue,
- determine impact,
- develop options,
- make a recommendation.
But the project manager may not have authority to approve the additional funding.
The next step therefore depends partly on:
Who owns the decision?
That may be:
- project manager,
- team,
- product owner,
- sponsor,
- steering committee,
- governance body,
- compliance function.
A good solution can still be the wrong answer if the wrong person is taking the action.
8. Scenario: The Planned Response Already Exists
Consider:
A project identified the risk that a primary supplier might fail to deliver a critical component. An alternate supplier was preapproved as part of the contingency response. The primary supplier now confirms that it cannot deliver.
Which action fits best?
Option A
Perform a new analysis to determine whether supplier failure could affect the project.
Option B
Activate the approved contingency response.
The risk has already been identified and analyzed.
The event has occurred.
An appropriate response already exists.
Unless the scenario tells you that the response is no longer appropriate, Option B fits the current stage better.
The lesson is not:
Always execute the contingency.
It is:
Recognize when the scenario tells you that analysis and planning have already happened.
9. Scenario: No Response Exists
Now consider:
During implementation, a previously unknown technical dependency causes a major integration failure. The cause and full impact are not yet understood.
Here, jumping directly to a solution would be premature.
The project manager may need to:
- understand the situation,
- assess the impact,
- investigate the cause,
- identify options,
- implement the appropriate response.
Compare that with the previous scenario.
Both involve issues.
But the decision process is at a different stage.
10. Think in Terms of Sequence
A scenario may move through stages such as:
Uncertainty identified
↓
Risk analyzed
↓
Response planned
↓
Trigger occurs
↓
Issue exists
↓
Response implemented
↓
Impact assessed
↓
Change initiated if required.
Not every scenario follows every step, and some steps may occur in a different order depending on the situation.
The point is not to memorize this as a rigid process.
The point is to ask:
Where am I in the sequence right now?
That prevents a common PMP mistake:
choosing an action that belongs earlier or later than the scenario itself.
11. The Project Reasoning Lab TRACE Check
When a PMP question asks what to do about a risk or issue, use the TRACE Check.
T — Type
Ask:
What kind of situation exists right now?
Is it:
- uncertainty,
- an active issue,
- a triggered risk,
- a requested change?
Identify the condition before reacting to the terminology.
R — Response
Ask:
Does an appropriate response already exist?
Was the risk previously:
- identified,
- analyzed,
- assigned,
- given a response,
- associated with a trigger?
If yes, do not automatically restart the process.
A — Authority
Ask:
Who has authority to take the required action?
Can the:
- team act,
- project manager decide,
- product owner decide,
- sponsor approve,
- governance body authorize?
Authority matters.
C — Consequences
Ask:
What is the current impact?
Consider:
- scope,
- schedule,
- cost,
- quality,
- risk,
- stakeholders,
- benefits,
- compliance.
This helps determine urgency and response level.
E — Execute
Finally ask:
What action logically belongs next?
That may mean:
- continue monitoring,
- implement a planned response,
- investigate,
- resolve the issue,
- communicate,
- submit a change,
- escalate.
The correct action depends on the situation already established.
12. Quick Comparison
| Situation | Key Question | Likely Reasoning Direction |
|---|---|---|
| Risk has not occurred | What might happen? | Analyze, plan, monitor |
| Trigger condition is reached | Is the planned response now appropriate? | Prepare or activate response |
| Identified risk materializes | Does an appropriate response already exist? | Implement response if appropriate |
| Unexpected issue occurs | What happened and what is the impact? | Assess and determine resolution |
| Cause must be understood | Why is this happening? | Investigate/root-cause analysis |
| Response changes controlled elements | What must change? | Follow the applicable change process |
| Decision exceeds PM authority | Who owns the decision? | Escalate appropriately |
This is a reasoning guide, not an automatic answer key.
13. Avoid Absolute Rules
Be cautious with advice such as:
Always analyze first.
Always escalate issues.
Always submit a change request.
Always perform root-cause analysis.
Each may be appropriate in some scenarios.
None should replace understanding the facts.
A better principle is:
Determine where the scenario currently is, then choose the action that belongs at that point.
Final Takeaway
The difference between risk response and issue resolution is not simply:
future vs. present.
That distinction helps identify the situation.
The harder PMP skill is determining what happens next.
Ask:
Has the event happened?
Was it already identified?
Was a response already planned?
Has the trigger occurred?
What is the current impact?
Who has authority to act?
Does the response require formal change or escalation?
Sometimes the project manager should investigate.
Sometimes the project manager should escalate.
Sometimes the project manager should initiate change.
And sometimes the right action is simply to execute the response that was already prepared for exactly this situation.
Don’t restart the reasoning process when the scenario has already moved forward. Identify where you are—then take the next appropriate action.
