what a risk actually is

A risk is an uncertain event that, if it happens, affects the project's objectives. Most of what gets discussed is threats — risks with a negative effect — but the same framework applies to opportunities, uncertain events that would help the project if they occurred. A risk is not the same as an issue: a risk is still uncertain; an issue is a risk (or an unforeseen problem) that has already happened and now needs managing, not predicting.

identifying risks

Risks surface through structured techniques, not just waiting for someone to mention one in a meeting: brainstorming with the project team, checklists built from risks that hit similar past projects, reviewing the assumptions baked into the plan (an assumption that turns out false is a risk that already existed, just unnoticed), and pulling in subject-matter experts for the areas the core team knows least about.
Every identified risk goes into a risk register — a living document tracking each risk's description, category, probability, impact, an assigned owner, and its response plan. The register is the single place the whole team looks to know what's being watched.

assessing risks: the probability/impact matrix

Qualitative risk assessment scores each risk on two axes — how likely it is (probability) and how bad it would be if it happened (impact) — typically on a simple scale like Low/Medium/High for each. Plotting risks on a probability×impact grid quickly sorts them by priority: a high-probability, high-impact risk needs a response plan now; a low-probability, low-impact one might just get logged and watched.
Low impactMedium impactHigh impact
High probabilityMediumHighCritical
Medium probabilityLowMediumHigh
Low probabilityLowLowMedium
For risks big enough to justify the extra effort, quantitative risk assessment puts numbers behind the qualitative score — expected monetary value (probability × cost impact, in dollars), sensitivity analysis (which risk actually moves the outcome most), or a Monte Carlo simulation across the whole schedule.

response strategies

Once a risk is scored, it needs a deliberate response — "hope it doesn't happen" is not a strategy. For threats:
  • Avoid — change the plan to eliminate the risk entirely (e.g. drop a risky dependency on an unproven vendor)
  • Mitigate — reduce the probability or impact (e.g. add automated tests to catch a category of bug earlier)
  • Transfer — shift the impact to someone else (e.g. insurance, or a fixed-price vendor contract that puts cost-overrun risk on the vendor)
  • Accept — acknowledge it and do nothing proactive, usually because the cost of a response exceeds the risk itself; often paired with a contingency reserve
Opportunities get the mirror-image treatment: exploit (make it happen), enhance (increase its probability or impact), share (partner with someone better positioned to capture it), or accept.

a short example

A team launching a new checkout feature identifies a risk: the third-party payment API has a rate limit that could throttle transactions during a planned flash sale. Probability: medium (the sale is expected to spike traffic well above normal). Impact: high (failed checkouts during the sale directly cost revenue). Response: mitigate by negotiating a temporary rate-limit increase with the payment provider ahead of the sale, and by building a request queue as a fallback if the limit is still hit. The risk owner — the engineer who built the payment integration — watches real-time API latency during the sale as the trigger that would signal the mitigation isn't holding.

practical notes

A risk register written once at kickoff and never revisited is close to useless — review it on a regular cadence, since new risks appear and old ones can shrink or disappear as the project moves forward.
Every risk needs a named owner, not "the team." A risk everyone is responsible for is a risk no one is actually watching.

related topics

reference