Risk Management
Every project carries a private list of things people are quietly worried about. Risk management is the unglamorous business of writing that list down, deciding which entries deserve action now, and doing it — before the worry becomes an emergency with an audience.
In short
- A risk might happen. An issue already has. They need different handling and different meetings.
- Score by likelihood × impact, but treat the score as a sorting tool, not an answer.
- The output of risk management is not a matrix — it’s a short list of things somebody is doing this week.
- Every risk needs a named owner and a trigger: the observable event that says “act now”.
Risk, issue, assumption
Three words that get used interchangeably and shouldn’t be:
| Word | Means | Handled by |
|---|---|---|
| Risk | Something that might happen and would affect the project | Assess, decide a response, monitor for the trigger |
| Issue | Something that has happened and is affecting the project now | Resolve it — see 6.2 |
| Assumption | Something you are treating as true without proof | Write it down; each one is a risk in disguise |
The distinction earns its keep in meetings. A risk review that fills up with today’s issues stops looking forward, which is the only thing it was for.
And that last row is the cheapest source of risks you have. Go through the assumptions in your scope statement and ask of each one: what if this is wrong? Most of your real risks are already written down there, just labelled as facts.
Finding risks worth writing down
The failure mode here is a register of thirty items so generic they could belong to any project — “resources may be unavailable”, “requirements may change”. Nobody acts on those, because there’s nothing to act on.
Four prompts that produce specific ones:
- What are we assuming? Every assumption in scope, schedule and staffing.
- What is outside our control? Vendors, regulators, other teams, shared environments, approvals. External dependencies are where most real risk lives, because you can’t just work harder at them.
- What went wrong last time? Read the retrospective from a similar project. This is why closing matters — it’s the input to this step.
- What is nobody saying? Ask the team individually and anonymously if needed. The most valuable risk on most projects is one that several people privately expect and nobody has said aloud.
A well-formed risk has a cause, an event and an effect: “Because the vendor’s security review is outside our control, it may take longer than two weeks, which would delay integration testing and the cutover date.” That sentence tells you what to watch and what it costs. “Vendor risk” tells you nothing.
Scoring, and what the score is for
Two things the matrix is good for: forcing a conversation about relative severity, and giving you a defensible reason to ignore twenty items so you can act on five. Two things it is bad for: precision (the difference between a 12 and a 15 is noise) and rare-but-catastrophic risks, which sit in the pale corner and can still end the project.
The four responses
Once a risk is scored, decide what you are doing about it. There are four real answers and one fake one.
Avoid
Change the plan so the risk can’t occur. Drop the feature that needs the fragile integration; choose the boring technology. The most effective response and the least used, because it costs something visible today.
Reduce
Make it less likely or less damaging. Start the vendor review early; pair two people on the specialist task; build a rollback. Most of your register will end up here.
Transfer
Move the consequence to someone better placed to carry it — insurance, a fixed-price contract, a managed service. Note that transferring the cost doesn’t transfer the delay.
Accept
Decide it isn’t worth acting on, say so, and set aside contingency if it’s worth covering. A legitimate answer — and completely different from not having thought about it.
The fake answer is “monitor” with nothing attached. Monitoring is only a response when it names what you are watching for and what you will do when you see it — which is the next section.
Triggers: the part that makes it work
A risk with a response but no trigger tends to be discovered late anyway, because nobody knows when to start. A trigger is an observable event, ideally with a number:
- “If the vendor hasn’t returned the review by day 10, escalate to their account manager.”
- “If we log more than 3 change requests in one week, re-baseline rather than absorbing them.”
- “If the data sample shows over 5% bad records, add a cleansing task before committing to the cutover date.”
Note what these have in common: someone could tell you today whether the trigger has fired, without a judgement call. That’s the whole test.
A register people actually use
Six columns is enough: the risk (cause → event → effect), likelihood, impact, response, owner, trigger. Two rules keep it alive:
- Every risk has a person’s name on it. Not a team. A team-owned risk is an unowned risk.
- Review it on a schedule, briefly. Ten minutes a fortnight: what changed, what can be closed, what’s new. A register reviewed only when something goes wrong is a record of hindsight.
Closing risks matters as much as adding them. A register that only grows becomes noise, and noise is why nobody reads it.
Where risk management usually fails
- Written once, at kickoff. The riskiest moment of most projects is not the start — it’s the point where an assumption is first tested. A register frozen in week one is blind by week six.
- Generic entries. If the risk could be copied onto any other project unchanged, it will be acted on with the same effort: none.
- Scoring instead of deciding. A beautifully scored register with an empty response column has consumed effort and bought nothing.
- Only downside. Opportunities are risks too — “the new API might let us drop half the migration work” deserves an owner and a check just as much.
- Punishing the messenger. One dismissive response to an early warning teaches the whole team to stop giving them, and no register survives that.
How this looks in AB
The risk register lives naturally in AB Projects in two complementary places:
- The human-readable register → a “Risks” page in the project Wiki holding cause, effect, likelihood, impact, response and owner. This is the version you show a sponsor.
- The active ones → tasks typed “Risk”, each with an assignee, a due date acting as the check-in cadence, and comments as the running mitigation log. Risks that need doing behave like work, so they should live where the work lives.
Triggers can be encoded directly. A task called “If reviews slip 2 days, revise the schedule” is itself the action you would take, sitting on the schedule waiting. And the change-history tab on each Risk task becomes the evidence trail when a risk eventually materialises — you can see exactly when it was first flagged and what was tried, which is a considerably better conversation than reconstructing it from memory.
Terms used on this page
- Risk
- An uncertain event that would affect the project if it occurred. Stated well, it has a cause, an event and an effect. More →
- Issue
- A risk that has happened, or a problem that has arisen. Issues are resolved, not assessed — and they belong in a different conversation. More →
- Risk register
- The living list of risks with their assessment, response, owner and trigger. Alive if it is reviewed on a schedule; a document if it isn’t. More →
- Risk matrix
- A grid of likelihood against impact used to sort risks by how much attention they warrant. A prioritising tool, not a measurement. More →
- Mitigation
- Action taken to make a risk less likely or less damaging. The most common response, and the one that needs a task with a date rather than an intention. More →
- Trigger
- The observable event that says a risk is materialising and the response should start. Good triggers contain a number and need no judgement call. More →
- Contingency
- Time or budget held in reserve for risks you have chosen to accept. Visible and owned, or it isn’t contingency — it’s padding. More →
- Assumption
- Something treated as true for planning without proof. The richest source of real risks on any project. More →
Related reading
6.2 Issue and Change Management
What to do once a risk stops being hypothetical and becomes today’s problem.
3.1 Defining Project Scope
Where your assumptions are written down — and therefore where half your risks already are.
8.2 Lessons from Failed Projects
Risks that materialised, and the warning signs that were visible beforehand.