5.21 Perform Quantitative Risk Analysis

5.21 Perform Quantitative Risk Analysis
Inputs Tools & Techniques Outputs

Replace this with term.

Purpose & When to Use

  • Estimate the likelihood of meeting key dates and budgets using numbers, not just ratings.
  • Size cost and schedule contingency based on modeled uncertainty.
  • Identify which risks and assumptions drive the most variance.
  • Compare alternatives or response strategies using expected value and scenarios.
  • Use after qualitative risk prioritization, and on projects that are large, complex, or have tight targets or high uncertainty.
  • Repeat at major milestones or after significant scope, estimate, or risk changes.

Mini Flow (How It’s Done)

  • Confirm inputs and data quality: risk register with well-defined risks, schedule network, cost estimates, assumptions, and constraints.
  • Build the model: add uncertainty to durations and costs (e.g., three-point estimates) and include discrete risk events with probabilities and impacts.
  • Select distributions and dependencies: choose suitable probability distributions and model correlations where variables move together.
  • Run analysis: use simulation for cost and/or schedule, perform sensitivity checks (e.g., tornado charts), and use decision trees or expected value where choices exist.
  • Interpret results: review percentiles (e.g., P50, P80), ranges, probability of meeting targets, and the top risk drivers.
  • Decide and update: propose contingency reserves, refine risk responses, adjust targets if needed, and update the risk report and risk register.
  • Communicate and iterate: explain assumptions and confidence levels, then rerun when plans or risks change.

Quality & Acceptance Checklist

  • Scope, schedule, and cost models reflect the current baseline and logic ties are valid.
  • Key threats and opportunities are modeled, with clear probabilities and impacts.
  • Uncertainty ranges for major estimates are justified and sourced.
  • Chosen distributions and correlations are reasonable and documented.
  • Outputs include percentiles, probability of meeting key targets, and a list of main risk drivers.
  • Recommended contingency is traceable to analysis results, not arbitrary padding.
  • Assumptions, data quality limits, and scenario choices are recorded.
  • Stakeholders reviewed results and understand confidence levels and implications.

Common Mistakes & Exam Traps

  • Confusing qualitative with quantitative analysis; quantitative uses numeric models and probabilities, not just risk ratings.
  • Assuming it is required on every project; it is used when the benefit outweighs the effort and data is sufficient.
  • Ignoring opportunities; include positive impacts as well as threats in the model.
  • Leaving out correlations; dependencies between variables can materially change ranges.
  • Using point estimates only; always include uncertainty ranges for key costs and durations.
  • Misreading percentiles; P80 is not a guarantee, it is a confidence level under stated assumptions.
  • Double counting reserves; contingency comes from analysis for known-unknowns, while management reserve is separate for unknown-unknowns.
  • Running simulations on a weak schedule; missing logic ties or unrealistic calendars produce misleading results.

PMP Example Question

Your sponsor asks for the probability of finishing within the approved budget and a data-backed recommendation for cost contingency. You have already prioritized risks using likelihood and impact scores. What should you do next?

  1. Add a fixed percentage contingency based on organizational policy.
  2. Perform quantitative risk analysis using a cost model with uncertainties and discrete risks.
  3. Update the risk register with more qualitative categories.
  4. Request management reserve to cover unknown risks.

Correct Answer: B β€” Perform quantitative risk analysis using a cost model with uncertainties and discrete risks.

Explanation: The sponsor wants probabilities and defensible contingency. This requires quantitative analysis using a numerical model, not qualitative scoring or arbitrary percentages.

AI Systems with Claude, for Scrum Masters and Project Managers

Most AI pilots in project management do not fail on the model. They fail because somebody pointed the thing at a decision instead of at a task. This course is built around that distinction, and around the work that follows once you get it right.

Eight teaching sections, taught against one running project from the first lecture to the last. You watch a system get built, then you build the same one against your own sprint. Nothing here is a demo that works only on the example.

You finish with five working systems and you keep them. The sprint report machine turns your board export and standup notes into the report you currently write by hand. The retro intelligence system tells you what the team keeps saying, not just what it said this time. The stakeholder comms engine drafts the update in the register the audience expects. The backlog health monitor flags the quiet decay nobody has time to check for. The risk and dependency tracker follows the chains that actually bite.

Seventy-six working files ship with it, across four sections, so every system is built against real sprint data rather than material invented for a slide. Four sprints of retrospectives, board exports, standup notes, backlog and risk data.

Explore the Course


Build an ICS/OT cybersecurity foundation that fits the real environment

Standard IT controls can disrupt the industrial systems they are meant to protect. Learn how to assess OT risk, design zones and conduits, apply IEC 62443 security levels, use MITRE ATT&CK for ICS, and establish passive asset visibility without risking production. Eight reconstructed incidents connect attacker techniques to the controls that failed, giving you the vocabulary and judgment to make credible security decisions from day one.

Explore the Course