WHY THIS MATTERS TO YOU

Every project has risks. The difference between a project that handles them well and one that does not is not the number of risks, it is whether they were identified before they became problems. A risk is something that might happen. An issue is something that already has.

As a BA or consultant, you are often the first person to see early warning signs of a problem. This module teaches you how to identify, document, prioritize, and respond to risks systematically.

Risks vs. Issues vs. Assumptions

These three are closely related and frequently confused. Understanding the distinction determines what you do with each one.

Type	Definition	What To Do
Risk	Something that might happen and would affect the project if it does	Log it, score it, assign a response strategy
Issue	Something that has already happened and is affecting the project now	Log it, assign an owner, resolve it
Assumption	Something treated as true for planning purposes without proof	Document it; if it turns out to be false, it becomes a risk or issue

PMP / PMBOK NOTE

The PMBOK Guide defines risk management as identifying, analyzing, planning responses to, implementing responses, and monitoring risks. The PMP exam distinguishes between threats (negative risks) and opportunities (positive risks). Many candidates study only threats; the exam also tests strategies for exploiting, sharing, and enhancing opportunities.

The Risk Register

A risk register is a log of identified risks. Every risk should have an ID, a description, a probability score, an impact score, a risk score (probability x impact), a response strategy, and an owner. It should be reviewed and updated throughout the project, not created once at kickoff and forgotten.

• Risk ID: a unique identifier for tracking
• Description: what might happen and what would be the effect
• Probability: likelihood of occurrence (High/Medium/Low or 1-5 scale)
• Impact: effect on scope, schedule, cost, or quality if it occurs
• Risk Score: probability x impact (used to prioritize)
• Response strategy: what will be done about it
• Owner: who is responsible for monitoring and responding

Risk Response Strategies

For threats (negative risks), there are four standard response strategies. For opportunities (positive risks), there are four parallel strategies. Choosing the right one depends on the probability, impact, and cost of the response.

Threat Strategies	Opportunity Strategies
Avoid: eliminate the risk by changing the plan	Exploit: ensure the opportunity happens
Transfer: shift the impact to a third party (insurance, contracts)	Share: partner with someone to capture the opportunity
Mitigate: reduce probability or impact	Enhance: increase probability or impact
Accept: acknowledge it and do nothing (active or passive)	Accept: take advantage if it occurs but do not pursue it

PMP / PMBOK NOTE

The PMP exam frequently asks which response strategy is most appropriate for a given scenario. Key test points: Avoid eliminates the risk; Mitigate reduces but does not eliminate it; Transfer shifts financial impact but not responsibility; Acceptance (passive) means no action unless the risk occurs; Acceptance (active) means setting aside a contingency reserve.

Qualitative vs. Quantitative Risk Analysis

Qualitative analysis assigns probability and impact scores to prioritize which risks to focus on. It is fast and practical for most projects. Quantitative analysis uses numerical data and statistical techniques (Monte Carlo simulation, decision trees) to model the total impact of risk on the project. Most BA and consultant roles work primarily at the qualitative level.

WHAT THEY SAY	WHAT THEY MEAN
That will not happen	This is passive acceptance without documentation; log it anyway with a low probability score
We have seen this before on other projects	Historical precedent makes this a well-defined risk; it should have a response plan ready
We are not worried about it	Make sure this is documented acceptance, not unexamined ignorance of the risk
The vendor said it would not be a problem	Vendor statements are not risk responses; verify and document

COMMON MISTAKE

MISTAKE: Building a risk register at kickoff and never reviewing it again.

What it looks like: The PM creates a thorough 40-item risk register in week one. By week six, six of those risks have become issues, two new major risks have appeared, and none of it has been updated. The register is now useless as a management tool.

Reality: Risk reviews should happen on a scheduled cadence: weekly on active projects, biweekly at minimum. The risk register is a living document, not a one-time artifact.

QUESTIONS TO ASK YOUR STAKEHOLDER

1. Is there a current risk register for this project? When was it last reviewed?
2. Are all identified risks assigned to a specific owner?
3. Are there response plans documented for high-score risks, or just identification?
4. Have any current issues on the project been traced back to risks that were previously identified but not addressed?
5. Are there opportunities (positive risks) in the register, or only threats?

Module Quiz

1. A project team identifies that a key vendor might deliver hardware late, which would delay testing. This is best classified as:

1. An issue
2. An assumption
3. A risk
4. A constraint

Answer: 3

Why it matters: It has not happened yet. It is a potential future event that would impact the project if it occurs, which is the definition of a risk.

2. A PM decides to buy insurance for potential data loss during a system migration. Which risk response strategy is this?

1. Avoid
2. Mitigate
3. Transfer
4. Accept

Answer: 3

Why it matters: Insurance transfers the financial impact of a risk to a third party. The risk still exists; you have just shifted who bears the cost if it occurs.

3. A risk has a probability of 4 and an impact of 3 on a 1-5 scale. A second risk has a probability of 2 and an impact of 5. Which should be prioritized?

1. The first risk (score 12)
2. The second risk (score 10)
3. They are equal
4. Cannot be determined without more information

Answer: 1

Why it matters: Risk score = probability x impact. First risk: 4 x 3 = 12. Second risk: 2 x 5 = 10. The first risk scores higher and should be prioritized.

4. Passive acceptance of a risk means:

1. The team will monitor the risk but has no specific response plan
2. The team has set aside contingency reserve for the risk
3. The risk has been transferred to a third party
4. The risk has been eliminated

Answer: 1

Why it matters: Passive acceptance acknowledges the risk but takes no action unless it occurs. Active acceptance sets aside contingency. Neither is wrong; the choice depends on the risk’s score and cost of response.

5. What is an opportunity in risk management terms?

1. A project bonus
2. A positive risk that could benefit the project if it occurs
3. A stakeholder request
4. A budget surplus

Answer: 2

Why it matters: Not all risks are negative. An opportunity is a positive uncertain event (e.g., a vendor delivering early, enabling faster testing). Opportunities should be managed deliberately, not just hoped for.