Risk Management: Identify, Assess, Mitigate

Execution and tracking progress was about steering the work you can see. This page is about the work you can’t see yet — the things that might go wrong but haven’t. Every project runs into surprises. The difference between a team that gets derailed by them and one that shrugs them off is almost never luck. It’s whether the surprise was thought about in advance.

This page gives you a simple, repeatable habit: name what could go wrong, judge how much each thing should worry you, decide what you’ll do about it, and revisit the list as the project moves. Done lightly and often, it is some of the cheapest insurance a project can buy — a few minutes of thinking now in exchange for not being blindsided later.

What a risk actually is

A risk is an uncertain event that, if it happened, would affect your project — usually for the worse, though good surprises count too. The key word is uncertain. A risk hasn’t happened. It might not happen. That uncertainty is exactly why people avoid thinking about it: it feels speculative, even a little pessimistic, to sit around listing things that could go wrong.

But that reluctance is the trap. The cost of naming a risk is a sentence and a minute of thought. The cost of being surprised by an unnamed risk is a scramble — done under pressure, with no plan, usually at the worst possible moment. Naming risks early is cheap insurance: you are paying a tiny premium in attention now to avoid a large, chaotic bill later.

Consider a few, across very different work:

Project                     A risk (uncertain event that would hurt it)
-------                     -------------------------------------------
Opening a second cafe       The builders finish two weeks late
Moving a hospital ward      A patient's records don't transfer correctly
Holiday warehouse rush      Seasonal staff quit in the first week
Launching a new app         The one person who knows the payment code
                             is off sick during launch week

None of these has happened. Each one might. And each one, written down, immediately invites the useful question: “so what would we do if it did?” That question is the whole discipline. A risk you’ve named is a risk you can prepare for; a risk you’ve ignored just waits to ambush you.

In practice — the sentence that saved a launch

Before a software launch, a manager spent ten minutes with the team asking one question: “What’s the thing that, if it happened, would ruin launch week?” One engineer said, quietly, “If Priya’s out sick — she’s the only one who understands the payment code.” That single sentence led to an afternoon of Priya walking a colleague through the code. She did get sick during launch week. Because the risk had been named, it was a non-event instead of a disaster. Ten minutes of listing bought a calm launch.

Assessing a risk: likelihood times impact

Once you start naming risks, you hit a new problem: there are too many. A café opening could list fifty things that might go wrong, from a late oven delivery to an alien invasion. If you treat every risk as equally urgent, you’ll either exhaust yourself or give up. So the second move is to sort them — to decide which ones actually deserve attention.

Two questions do almost all the sorting:

• Likelihood — how probable is this? Is it a near-certainty, a coin-flip, or a long shot?
• Impact — if it did happen, how badly would it hurt the project? A shrug, a bruise, or a broken leg?

You don’t need percentages or a spreadsheet. Rough bands — low, medium, high — are enough. What matters is that you consider both dimensions together, because neither alone tells you what to worry about. A near-certain event that barely matters (the office plant dies) needs no plan. A catastrophic event that will basically never happen (the building is struck by a meteor) needs no plan either. The risks that deserve your attention live where both are high.

A simple grid makes this visible:

                 IMPACT
             low        high
          +----------+----------+
     high | watch it | ACT NOW  |   High likelihood, high impact:
          |          |          |   your top priority. Plan a response.
LIKELIHOOD+----------+----------+
     low  | ignore   | have a   |   Low/high: unlikely but severe —
          |          | plan B   |   worth a contingency, not daily worry.
          +----------+----------+

The point of the grid isn’t precision — your placements are educated guesses and that’s fine. The point is triage: it forces you to spend your limited attention on the top-right corner and stop losing sleep over the bottom-left. A risk assessment that treats everything as urgent has assessed nothing.

The common trap — the risk list nobody prioritised

A common failure isn’t having no risk list — it’s having a list of forty undifferentiated worries, all marked “important,” that nobody knows how to act on. An un-prioritised list is just anxiety written down. Always force the two-question sort. If you can’t say which three risks matter most, you haven’t finished assessing — and the team will end up reacting to whichever risk shouts loudest, not the one that matters most.

The four responses: avoid, reduce, transfer, accept

Naming and sorting risks is worthless if you don’t do anything with them. For each risk worth attention, you choose a response. There are four, and it helps enormously to know them by name, because they cover essentially every option you have.

Avoid

Avoid means changing the plan so the risk can’t happen at all. You remove the exposure. If a supplier is unreliable, you avoid the risk by choosing a different supplier. If a feature is technically risky and not essential, you avoid the risk by cutting the feature. Avoidance is the cleanest response — the risk simply ceases to exist — but it usually costs you something else (a different supplier, a smaller scope), so you can’t avoid everything.

Reduce

Reduce (sometimes called mitigate) means lowering the likelihood, the impact, or both — while still living with the risk. You can’t guarantee the builders finish on time, but you can reduce the impact by starting to hire staff earlier so a construction delay doesn’t also delay your opening. You can’t stop your key engineer getting sick, but you can reduce the impact by making sure a second person understands the code. Reduction is the workhorse response — most real risk management is just sensible reduction.

Transfer

Transfer means making the risk someone else’s problem to absorb — usually for a price. Insurance is the classic example: you pay a premium so that if the warehouse floods, the insurer bears the financial hit. Hiring a specialist contractor with a fixed-price contract transfers the risk of the work taking longer than expected onto them. Transfer doesn’t make the event less likely — the flood can still happen — it just moves who pays when it does.

Accept

Accept means deciding, consciously, to live with the risk and do nothing special about it. This is the correct response for risks that are low-impact, or so unlikely that preparing would cost more than the risk itself. The crucial word is consciously. Accepting a risk after looking at it is a legitimate decision. Ignoring a risk because you never named it is not acceptance — it’s negligence dressed up as calm. Often you’ll pair acceptance with a small contingency (“if it happens, here’s roughly what we’ll do”) without spending effort now.

Response   What you do                          Example
--------   -----------                          -------
Avoid      Change the plan so it can't happen   Drop the risky feature
Reduce     Lower its likelihood or impact       Cross-train a second person
Transfer   Move who bears the cost              Buy insurance; fixed-price contract
Accept     Consciously live with it             Note it; keep a rough plan B

The evidence — cheaper to fix early

A recurring finding across project and engineering research is that the cost of dealing with a problem climbs steeply the later you catch it — a risk addressed in planning is generally far cheaper to handle than the same problem discovered mid-delivery, which is in turn cheaper than fixing it after release. The exact multipliers vary and are often overstated, so treat them loosely. But the direction is reliable and it’s the whole argument for risk management: the earlier you engage with what could go wrong, the more and cheaper your options.

Keep a living risk list — not a document you write once

Here is where most risk management quietly dies. A team, usually because someone required it, writes a thorough risk document at the start of a project. It is detailed, well-intentioned, and filed away — never to be opened again. Six weeks later the project is running into risks that aren’t on it, while the document lists risks that are long since resolved. A risk list written once and forgotten is theatre.

The fix is to keep the list small and alive. It doesn’t need to be fancy — a shared table with a handful of columns is plenty:

Risk                      Likelihood  Impact  Response            Owner
----                      ----------  ------  --------            -----
Builders finish late      medium      high    Reduce: hire staff  Sam
                                              early
Key engineer off sick     low         high    Reduce: cross-train Priya
Seasonal staff quit early medium      medium  Reduce: better      Dana
                                              onboarding + buffer
Oven delivery delayed     low         low     Accept: note it     Sam

Two things make this a living list rather than a dead one:

• An owner for each real risk. A risk everyone is responsible for is a risk no one is watching. Naming one person who keeps an eye on it — and will act if it starts to materialise — is what turns a list into actual coverage.
• A regular, short review. Spend five minutes in your existing weekly check-in scanning the list: Has anything become more likely? Can we close any risks that have passed? What new risks has the last week revealed? Projects change, and so do their risks. The review is what keeps the list matched to reality.

Reviewed this way, the list stays short because you’re constantly closing resolved risks and adding fresh ones. It becomes a genuine working tool — the team’s shared picture of what to keep half an eye on — rather than a compliance artefact gathering dust.

Risk versus issue: might happen vs. already happening

There is one distinction that keeps this whole discipline clear, and confusing the two is a common source of muddle.

• A risk might happen. It lives in the future and is uncertain. You plan for it.
• An issue is happening, right now. The uncertainty is gone. You manage it.

The moment a risk materialises, it stops being a risk and becomes an issue. “The builders might finish late” is a risk. “The builders are three weeks behind and our opening is in danger” is an issue. They need different handling, and different places to live.

RISK                          ISSUE
----                          -----
Might happen (uncertain)      Is happening (certain)
Lives in the future           Lives in the present
You PLAN a response           You EXECUTE a response
Sits on the risk list         Goes on the action list / gets escalated
"What if the builders         "The builders are late — we're
 finish late?"                 activating plan B now."

Why does the distinction matter in practice? Because the two get tracked differently. Risks sit on your risk list and get reviewed. Issues need an owner and a deadline right now — they belong on your active task list, and if they’re serious enough, they get escalated to whoever can help. Mixing them up causes two failures: teams that treat every risk as a live emergency burn out on things that may never happen, while teams that treat a live issue as “just a risk we’re watching” fail to act while there’s still time.

The good news is that the work you did earlier pays off here. When a named risk becomes an issue, you already have a response planned — so you convert it into action calmly instead of scrambling. That is the entire promise of risk management: because you thought about it in advance, a nasty surprise becomes a managed event.

Case study — Apollo 13, 1970

When an oxygen tank ruptured aboard Apollo 13 in April 1970, the crew and mission control faced a genuine crisis — an issue, fully materialised, with lives at stake. What let them respond rather than panic was years of thinking about what could go wrong: rehearsed failure procedures, backup systems, and teams trained to improvise within known constraints. Famously, engineers on the ground worked out how to adapt the available materials to keep the crew’s air breathable. The lesson isn’t that they had a plan for that exact failure — they didn’t. It’s that a culture of taking risks seriously in advance gave them the systems, habits, and calm to manage the surprise. Preparation doesn’t predict every issue; it builds the muscle to handle the ones you didn’t.

How it connects

Risk management leans on everything before it. You can only judge a risk’s impact if you know what done looks like and what’s in scope. Your risk list is fed by the work breakdown and plan, whose dependencies are where many risks hide, and by honest estimation, since an over-confident estimate is itself a risk. The weekly risk review folds neatly into execution and tracking. And the biggest slow-motion risk of all — uncontrolled change — gets its own page next in scope creep and the iron triangle.

Try this

Take a project you’re running this week and spend fifteen minutes building a first risk list. Brainstorm every “what could go wrong?” you can think of — aim for at least eight. For each, mark likelihood and impact as low / medium / high, then pick your top three by that sort. For each of those three, write one response using a named option (avoid, reduce, transfer, accept) and assign an owner. Finally, put a five-minute “risk review” on next week’s check-in agenda so the list stays alive rather than becoming a one-off document.

Reflect

1. Think of a recent project surprise that hurt you. Was it genuinely unforeseeable, or was it a risk nobody had bothered to name out loud?
2. Look at how you currently handle risks. Do you actually sort them by likelihood and impact, or do you treat every worry as equally urgent?
3. For a real risk you’re carrying, which of the four responses — avoid, reduce, transfer, accept — are you using? Is it a deliberate choice, or a default you drifted into?
4. Does your team have a risk list that’s genuinely reviewed, a document written once and forgotten, or nothing at all? What would move it one step toward “living”?
5. Can you point to something on your project that is no longer a risk but a live issue — and is it being managed with an owner and a deadline, or still just “watched”?

Show reflections

1. Most painful surprises, examined honestly, were nameable in advance — someone half-knew. The value here is realising that the failure was usually not naming it, which is a cheap, fixable habit, not bad luck.
2. If everything is “important,” nothing is prioritised, and you’ll react to whatever shouts loudest. A strong answer notices whether you genuinely weigh both dimensions and can name your top few risks.
3. The four names matter because they make the choice conscious. “Accept” chosen deliberately is fine; a risk you’re accepting only because you never looked at it is the dangerous case. Check which of yours are drift versus decision.
4. The honest answer for many teams is “written once and forgotten,” or nothing. One owner per real risk and a five-minute slot in an existing meeting is usually all it takes to make a list actually live.
5. This tests the risk-versus-issue distinction. A materialised risk needs an owner and a deadline now, not continued watching. If something has already happened and you’re still “keeping an eye on it,” you’re managing it too slowly.