Risk isn't only bad news: the two-sided definition and the seven-step loop
The PMBOK defines risk as an uncertain event that, if it occurs, has an effect on project objectives — and note that the effect can be negative (a threat) or positive (an opportunity). 'A module might finish ahead of schedule' is just as much a risk as 'the vendor might deliver late.'
Internationally, the ISO 31000 standard raises risk-management thinking to the organizational level. The core mindset: uncertainty cannot be eliminated, but it can be identified, assessed, responded to, and monitored — turning 'something might go wrong' into 'we have a plan.'
Risk management is not a one-time exercise at kickoff; it is a continuous loop that runs through the whole project. The PMBOK breaks it into seven steps:
1. Plan risk management — set the approach and roles;
2. Identify risks — list everything that 'might go wrong / might turn out well' as completely as possible;
3. Qualitative analysis — quick ranking by probability × impact;
4. Quantitative analysis (optional) — put numbers on the risks that matter;
5. Plan risk responses — pick a strategy for each risk;
6. Implement responses — turn strategies into action;
7. Monitor continuously — new risks emerge and old ones change, so loop back and update.
Identify and assess: writing the register, screening with the P-I matrix, computing EMV
Identifying risks means listing everything that 'might go wrong / might turn out well' as completely as possible. Common techniques: brainstorming, checklists (common risks from past projects), expert judgment, assumption analysis (treat every assumption as a potential risk and ask 'what if it doesn't hold?'), and SWOT. The earlier and more completely you identify, the more initiative you keep.
The output is the risk register — a living document where each entry records: risk description, owner, probability, impact, and planned response. Two key points: (1) the register must be continuously updated (new risks keep emerging as the project advances), not written once and archived; (2) each risk should be described as 'cause → uncertain event → effect,' not a vague 'there is risk.'
Once you have a pile of identified risks, run qualitative analysis first for a quick ranking: rate each risk's probability (low/medium/high) and impact (low/medium/high) and plot it on the probability-impact (P-I) matrix — risks landing in the 'high probability × high impact' red zone get watched and treated first, while 'low × low' ones can be accepted or observed for now. It is subjective and judgment-based, but fast, cheap, and the most commonly used first screen — concentrating limited attention on the critical few.
For large projects, or for the high-priority risks the first screen surfaces, follow up with quantitative analysis: (1) Expected Monetary Value, EMV = probability × monetary impact — e.g., a 30% chance of losing ¥100k gives EMV = −¥30k — used to compare risk sizes and size the contingency reserve; (2) Monte Carlo simulation — massive random sampling over schedule/cost to get 'the probability of finishing on time' and 'the most likely cost range.' Qualitative answers 'which risks matter'; quantitative answers 'how much they matter and how much buffer to hold' — and you only quantify the critical few, not every entry.
Respond and backstop: four moves for threats, four for opportunities, two kinds of reserves
For threats (negative risks), the PMBOK offers four response strategies:
- Avoid — change the plan and eliminate the root cause so the risk cannot happen at all (cut high-risk scope, switch to mature technology);
- Transfer — shift the impact to a third party instead of bearing it yourself (buy insurance, outsource, contract clauses);
- Mitigate — reduce the probability or the impact (more testing, redundancy, prototypes);
- Accept — take no proactive action: active acceptance sets a contingency reserve as a backstop, passive acceptance just deals with it if it happens.
PMBOK 6 also adds escalate: risks beyond the project's authority go up to management/the organization. Which move to pick depends on the risk's size versus the cost of the response — not every risk is worth paying to avoid.
For opportunities (positive risks) there are four matching moves:
- Exploit — make sure the opportunity definitely happens by committing your strongest resources;
- Share — partner with someone capable to capture it together (joint ventures, alliances);
- Enhance — increase the opportunity's probability or payoff;
- Accept — don't chase it, but welcome it if it comes.
For example, if a module finishes faster than expected (an opportunity), the project manager can commit the strongest resources and start the next phase early on the momentum — that's exploiting.
Projects need buffers for uncertainty, but there are two kinds: for known risks — the ones you identified and put in the register — hold a contingency reserve (time/money), usually counted inside the cost/schedule baseline and spendable at the project manager's discretion; for unknown-unknowns — the ones you never thought of and cannot identify in advance — hold a management reserve, sitting above the baseline, whose use typically requires management approval. Known risks are covered by plans plus contingency; unknown risks by the management-reserve backstop — don't conflate the two, and don't pretend the project will have zero surprises and hold no buffer at all.
自测 · 学完检查一下
想真正动手做题、记进度、攒连胜？到互动课里练。
According to the PMBOK definition, which statement about 'risk' is correct?
答案：A risk is an uncertain event that, if it occurs, has an effect on project objectives — the effect can be negative (a threat) or positive (an opportunity)
The PMBOK defines risk as 'an uncertain event that, if it occurs, has an effect on project objectives' — the effect can be negative (threat) or positive (opportunity), so capturing upside is part of risk management too. A risk is an uncertain event that has not yet occurred, not a problem that already has; and uncertainty cannot be eliminated — only identified, assessed, responded to, and monitored, turning 'something might go wrong' into 'we have a plan.' (Sources: PMBOK Guide (6th ed.) — Project Risk Management; ISO 31000:2018)
True or False: According to the PMBOK, risk management is a continuous loop running through the whole project — plan risk management → identify risks → qualitative analysis → quantitative analysis (optional) → plan responses → implement responses → monitor continuously — not a one-time exercise at kickoff.
答案：True
True. The PMBOK breaks project risk management into seven steps that run as a loop: (1) plan risk management → (2) identify risks → (3) qualitative analysis → (4) quantitative analysis (optional) → (5) plan responses → (6) implement responses → (7) continuous monitoring. New risks keep emerging as the project advances and existing risks' probability/impact keep changing, so you must monitor throughout and loop back to update the register; ISO 31000:2018 likewise lists continuous monitoring and communication as components of risk management. (Sources: PMBOK Guide (6th ed.) — Project Risk Management; ISO 31000:2018)
The team is starting a risk register. Which practice is correct?
答案：Each entry records the risk description, owner, probability, impact, and planned response — and the register is continuously updated as the project advances
The risk register is a living document; each entry records: risk description, owner, probability, impact, and planned response. A risk without an owner has nobody tracking it; without probability/impact it cannot be prioritized; without a response it is a record, not management. And the register must be continuously updated (new risks keep emerging, old ones change) — writing it once and archiving it is just going through the motions. (Sources: PMBOK Guide (6th ed.) — Identify Risks; ISO 31000:2018 — Risk identification)
True or False: Writing a single line — 'this project has technical risk' — in the risk register counts as a proper risk description; the vaguer the wording, the broader and safer the coverage.
答案：False
False. Risks should be described as 'cause → uncertain event → effect,' not a vague 'there is risk': e.g., 'because the core module depends on a third-party API (cause), the vendor may deliver late (uncertain event), pushing integration testing back two weeks (effect).' A vague description cannot be assigned a probability, an impact, or a response; a structured one gives the subsequent qualitative/quantitative analysis and response planning something to grip. (Source: PMBOK Guide (6th ed.) — Identify Risks)
You have identified 30 risks but the team's capacity is limited. After qualitative analysis, risk A lands in 'high probability × high impact' and risk B in 'low probability × low impact.' Per the probability-impact matrix, what should you do next?
答案：Watch and respond to red-zone risk A first; 'low × low' risks like B can be accepted or observed for now
The whole point of qualitative analysis is fast ranking: rate each risk's probability and impact, plot them on the P-I matrix — risks in the 'high probability × high impact' red zone get watched and treated first, while 'low × low' ones can be accepted or observed. It is subjective and judgment-based but fast and cheap — the most commonly used first screen, concentrating limited attention on the critical few instead of spreading effort evenly over a long list; quantitative analysis (e.g., Monte Carlo) is heavier and reserved for the high-priority risks the first screen surfaces, not every entry. (Source: PMBOK Guide (6th ed.) — Perform Qualitative Risk Analysis)
A risk has a 20% probability of occurring, and if it occurs it will cause a loss of ¥500k. Using Expected Monetary Value (EMV), what is this risk's EMV?
答案：−¥100k — EMV = 20% × (−¥500k)
Expected Monetary Value = probability × monetary impact = 20% × (−¥500k) = −¥100k (likewise, a 30% chance of losing ¥100k gives EMV = −¥30k). It folds probability and impact into one number, used to compare risk sizes and size the contingency reserve — neither provisioning the full worst case nor counting zero because it hasn't happened. Quantitative analysis is more rigorous but heavier, so it is normally applied only to the high-priority risks surfaced by qualitative screening. (Source: PMBOK Guide (6th ed.) — Perform Quantitative Risk Analysis)
Precision equipment could be damaged in long-haul transport, so the team buys shipping insurance and lets the insurer bear the loss. Which of the four threat-response strategies is this?
答案：Transfer — shift the impact to a third party
Buying insurance is the classic transfer: shift the risk's impact to a third party instead of bearing it yourself — outsourcing and contract clauses fall in the same bucket. Distinguish: avoid changes the plan and eliminates the root cause so the risk cannot happen at all (cut high-risk scope, switch to mature technology); mitigate lowers the probability or impact (more testing, redundancy, prototypes); accept takes no proactive action (active acceptance sets a contingency reserve as a backstop). PMBOK 6 also adds escalate: risks beyond the project's authority go up to management/the organization. (Source: PMBOK Guide (6th ed.) — Plan Risk Responses (threats))
A core module finishes two weeks ahead of schedule (a positive risk — an opportunity). The project manager immediately commits the strongest resources to make sure the next phase starts early on this momentum, so the opportunity is captured with certainty. Which of the four opportunity-response strategies is this?
答案：Exploit — commit the strongest resources to make sure the opportunity definitely happens
'Committing the strongest resources to make sure it definitely happens' is exploit — the first of the PMBOK's opportunity responses; a module finishing faster than expected and the team starting the next phase early on the momentum is its textbook example. The four moves: exploit = ensure the opportunity is certainly captured; share = joint ventures/alliances with a capable partner to capture it together; enhance = raise its probability or payoff; accept = don't chase it, welcome it if it comes. Watching only threats while ignoring opportunities is doing half the job of risk management. (Source: PMBOK Guide (6th ed.) — Plan Risk Responses (opportunities))
True or False: Known risks — identified and entered in the register — are backstopped by a contingency reserve, normally counted inside the cost/schedule baseline and spendable at the project manager's discretion; unknown-unknowns rely on a management reserve, held above the baseline, whose use typically requires management approval.
答案：True
True. The two reserves map to two kinds of uncertainty: known risks (identified and placed in the register) get a contingency reserve (time/money), usually counted inside the cost/schedule baseline and usable at the project manager's discretion; unknown risks (never anticipated, impossible to identify in advance) get a management reserve, held above the baseline and typically requiring management approval to use. Known risks are covered by plans plus contingency, unknown risks by the management-reserve backstop — don't conflate the two, and don't pretend the project will have zero surprises and hold no buffer at all. (Source: PMBOK Guide (6th ed.) — Contingency vs Management Reserve)
True or False: As long as the team has set up a risk register, risk management is being done properly.
答案：False
False. This is a classic misconception: a register with no owners, no responses, and nobody following up is just a piece of paper; real risk management is the closed loop of 'identify → assess → owned responses → continuous monitoring,' and its output is not a document but fewer surprises and faster reactions. The other two common misconceptions: 'list the risks once at kickoff and you're done' (wrong — new risks keep emerging, so monitor throughout and keep updating) and 'risk only means bad things' (wrong — the PMBOK explicitly includes opportunities; defending against threats while ignoring upside is half the job). (Sources: PMBOK Guide (6th ed.) / ISO 31000:2018)