Risk Management in Projects: Identify, Assess, Respond, Monitor

A risk is an uncertain event that, if it occurs, affects your project's objectives — negatively (a threat) or positively (an opportunity). Risk management is not paperwork insurance; it's the discipline of spending small amounts of attention early to avoid spending large amounts of budget late. Projects rarely die from the risks in the register — they die from the ones nobody wrote down.

Step 1 — Identify

Cast a wide net, repeatedly (not once at kickoff):

• Structured brainstorming with the people doing the work — they know where the bodies are buried.
• Checklists and prompt categories — technical, external, organisational, commercial (or a RBS if you're formal).
• Assumption analysis — every assumption in the plan is a risk wearing a disguise.
• Lessons from previous projects — the cheapest identification technique in existence, and the least used.
• Pre-mortem — "it's six months from now and the project failed; what killed it?" Reliably surfaces the risks people were too polite to raise.

Write each risk in cause–event–effect form: Because the vendor API docs are incomplete, integration may take longer than estimated, delaying UAT by up to three weeks. Vague risks ("timeline risk") produce vague responses.

Step 2 — Assess

Qualitatively score each risk on probability and impact (typically 1–5 scales), plot them on a probability-impact matrix, and let the red corner earn the attention. Add urgency where response windows are short. Quantitative techniques (expected monetary value, Monte Carlo simulation) earn their overhead on large or contractual projects; most projects live well on a disciplined qualitative pass.

Step 3 — Respond

Four strategies for threats:

• Avoid — change the plan so the risk can't occur (drop the risky component, change the approach).
• Transfer — move the impact to a third party (insurance, fixed-price contract, warranty). The risk still exists; the bill moves.
• Mitigate — reduce probability or impact (prototype early, add reviews, parallel-source).
• Accept — consciously live with it; actively (contingency reserve, trigger plan) or passively (noted, monitored).

Opportunities mirror these: exploit, share, enhance, accept. Every non-accepted risk needs an owner — a risk owned by "the team" is owned by no one.

Step 4 — Monitor

The register is a living document or it's a dead one. Review the top risks in the regular cadence (weekly on the project, per-Sprint in agile delivery), watch trigger conditions, retire what's passed, add what's new, and audit whether responses actually happened. In agile contexts, much mitigation is structural — short iterations, early integration, frequent demos are risk management by design — but explicit risk conversations still catch what cadence alone doesn't.

Risk management is tested substantially on the PMP exam across predictive and agile contexts, and features in the PMI-ACP as well — see the PMP guide for how the domains break down.

Frequently asked questions

Risk vs issue — what's the difference?

A risk is uncertain and in the future; an issue has already happened. Risks get responses; issues get actions. Keeping the lists separate keeps both honest.

How big should a contingency reserve be?

Derived from the assessed risks (not a flat percentage folklore number) — expected-value math or simulation on larger projects, informed judgment on smaller ones, always visible to the sponsor.

Who owns risk management on an agile team?

Everyone surfaces risks; the Product Owner weighs value-side risks in ordering, the team owns technical mitigation, and delivery leads keep the conversation regular.