1.3 The Risk Management Lifecycle

The Seven Risk Processes

Project risk management is a repeatable lifecycle. PMI organizes it into seven processes that flow in order but loop back constantly:

1. Plan Risk Management — decide how risk will be handled; produces the risk management plan.

2. Identify Risks — find individual risks and sources of overall risk; first populates the risk register and risk report.

3. Perform Qualitative Risk Analysis — subjectively prioritize risks by probability and impact.

4. Perform Quantitative Risk Analysis — numerically model the effect of prioritized risks on overall outcomes.

5. Plan Risk Responses — choose strategies for threats and opportunities.

6. Implement Risk Responses — carry out the agreed actions.

7. Monitor Risks — track risks, watch triggers, find new risks, and confirm responses work.

A helpful flow mnemonic: Plan → Identify → Analyze → Respond → Monitor. Note that Implement Risk Responses is its own process — planning a response and actually executing it are deliberately separated. A response sitting in the register but never carried out is a frequent root cause of risk events, which is exactly why PMI made implementation a distinct step.

Plan Risk Management is the only process that normally runs once. Everything after it cycles. The plan it produces defines the rules of the game: the methodology, roles and responsibilities, funding for risk activities, the timing and frequency of risk reviews, the risk categories (often as an RBS), and the agreed probability and impact definitions that every later analysis will use.

Qualitative vs. Quantitative Analysis

Both processes "analyze," but they answer different questions, and confusing them is a classic exam trap.

Qualitative always comes first and feeds a short list into quantitative analysis. On small projects, quantitative analysis is often skipped entirely — a frequently tested point.

Qualitative analysis can also assess urgency, proximity (how soon a risk could hit), detectability, and data quality, then categorize risks to spot concentrations. Quantitative analysis, by contrast, produces overall numbers — a probable cost range or the odds of meeting the deadline — using tools like Monte Carlo simulation and sensitivity analysis covered later in this guide.

High-Level Inputs and Outputs

You do not need to memorize every input, but you should recognize the pattern:

• Plan Risk Management takes the project charter and stakeholder register; it outputs the risk management plan (methodology, roles, P-I definitions, reporting formats).
• Identify Risks outputs new entries in the risk register and updates to the risk report.
• Plan Risk Responses outputs updated register entries plus changes to budgets and the contingency reserve.
• Monitor Risks outputs work-performance information, change requests, and updated documents.

A recurring exam pattern hides the order of these processes. If a question gives you a fresh list of identified risks and asks what to do next, the answer is qualitative analysis — prioritize before you model or respond. If it asks how to decide which threats are worth a numeric model, that is the handoff from qualitative to quantitative analysis. Never jump straight from identification to response planning.

How the Processes Iterate

Risk management is not a one-time event. Plan Risk Management usually happens once, early. But Identify, Analyze, Respond, and Monitor repeat throughout the project:

• New risks appear as the work unfolds and as assumptions are tested.
• Existing risks change probability or impact as conditions shift.
• Responses create secondary risks that must themselves be analyzed.

Each iteration may be triggered by a phase gate, a major change, a missed milestone, or a scheduled risk review. This iterative habit is why agile and hybrid projects reassess risk every sprint, and why even predictive projects revisit the register at every gate rather than treating identification as a one-time kickoff exercise.

The Living Artifacts

Two documents thread through every process:

• The risk register records individual risks — description, owner, probability, impact, chosen response, action owner, and status. It is created in Identify Risks and updated in every later process.
• The risk report summarizes overall project risk and the most significant individual risks for stakeholders.

Think register = detail, report = summary. Both are evolving artifacts: they grow during identification, gain ratings during analysis, gain strategies during response planning, and shed closed risks during monitoring.

The register typically carries, per risk: a unique ID, the risk description, category, probability, impact, a calculated risk score, the chosen response, the risk owner (accountable for monitoring), the action owner (executes the response), and current status. As risks are addressed, the register also begins tracking residual and secondary risks — leftover and newly created exposures that you will study in the response chapter.

Because the register and report feed every later decision, keeping them current is itself a monitoring activity. A stale register is a classic exam wrong-answer trap: the right move is usually to update the risk register before reporting or escalating.