Project Risk Management

Every project carries a quiet question underneath the timeline: what could go wrong, and what would we do about it? Risk management is just the habit of answering that question on purpose, early and out loud, instead of being surprised later. It sounds heavy, but in practice it is mostly common sense written down so the team can act on it together. Once you understand the few moving parts, the risk section of any status meeting stops being a box-ticking ritual and starts being one of the most useful conversations you have.

A risk is not an issue

The first distinction to nail is risk versus issue, because people mix them up constantly. A risk is something that might happen — it lives in the future and it is uncertain. “The vendor might miss the deadline” is a risk. An issue is something that has happened — it is here now and it needs handling. “The vendor missed the deadline” is an issue.

The reason this matters is timing. A risk gives you room to plan; an issue demands a reaction. Good teams spend energy on risks precisely so they have fewer issues. When a risk you ignored turns into an issue, that is usually the most expensive way to learn the lesson. So when someone reports a problem, quietly ask yourself: is this still a maybe, or has it already landed? The answer tells you whether you are managing risk or managing damage.

The risk register and how risks get scored

Teams keep their risks in a risk register — a simple living list of everything that might go wrong, who is watching it, and what the plan is. Nothing fancy: often a spreadsheet. The point is that risks are written down where everyone can see them, not floating around as private worries.

For each risk, two questions set its priority. Likelihood asks how probable it is. Impact asks how much it would hurt if it happened. Multiply the two together — likelihood × impact — and you get a rough score that tells you which risks deserve real attention. A risk that is unlikely and low-impact can be noted and left alone. A risk that is likely and would sink the project goes straight to the top of the list.

The four responses

Once a risk is scored, you choose what to do about it. There are four classic responses, and naming them out loud keeps the team honest about which one they have actually picked.

Avoid means changing the plan so the risk disappears entirely — dropping the risky feature, picking a proven tool instead of a shiny one. Reduce (sometimes called mitigate) means lowering the likelihood or the impact: adding a backup supplier, building in extra testing, starting the hard part early. Transfer means handing the risk to someone better placed to carry it — buying insurance, or writing a contract clause that puts a missed deadline on the vendor. Accept means deciding, deliberately, to live with it: the risk is small enough, or fixing it costs more than it is worth, so you note it and move on.

Accepting a risk on purpose is a real choice, not laziness. The danger is unconsciously accepting risks you never discussed — that is just hoping. Writing “accepted” in the register turns a silent gamble into a decision the team owns together.

Rule of thumb: every risk in your register needs a named owner and a chosen response. A risk with no owner is a risk nobody is actually watching.

Owners and contingency

A risk owner is the single person responsible for keeping an eye on a given risk and acting if it starts to materialize. Not the whole team — one name. This is the difference between “someone should watch the vendor” and “Priya is watching the vendor.” The first is a wish; the second gets done.

Finally, sensible projects hold back a contingency — a deliberate buffer of time, money, or both, set aside for the risks you cannot fully eliminate. If you know things sometimes slip, you plan for some slippage rather than promising a date that assumes everything goes perfectly. A schedule with zero buffer is not optimistic; it is fragile. Contingency is what lets a project absorb a normal bump without turning every small surprise into a crisis.

How to use it

In your next planning or status meeting, separate the maybes from the here-and-nows. Try: “Is that a risk or an issue — has it actually happened yet?” When a worry comes up, push gently toward action: “Should we put that in the register? Who’s the owner?” When the team debates a worry, name the response: “Are we trying to avoid this, reduce it, transfer it, or just accept it?” And when a plan looks suspiciously tight, ask: “How much contingency do we have if this slips?” These small phrases move a team from worrying to managing — which is the whole game.

Spot the risk or issue

Read each statement and decide whether it’s a risk (uncertain future) or an issue (already happened), then tap a card to flip it and check your answer.

Sort the risk responses

Drag each scenario into the correct response type — or tap a scenario, then tap a response. Hit Check placement when you’re done.