Project Risk Management: A Practical Process

Most project risk registers are produced at initiation to satisfy a governance requirement and never opened again. This guide covers the process as something that changes outcomes rather than something that fills a template.

Quick answer: Risk management is a five-step loop: identify what could go wrong, assess how likely and how damaging each is, decide a response, assign an owner, and review regularly.

The value is entirely in the responses — a register listing forty risks with no owners and no actions is documentation, not management.

What Risk Management Is Actually For

Risk management exists to make you act early on things that have not happened yet, while acting is still cheap.

Risks versus issues

A risk is something that might happen. An issue is something that has happened and is affecting the project now.

The distinction matters because the response differs. Risks get mitigation — action to reduce likelihood or impact before the event. Issues get resolution. Registers that mix the two produce confusion about which items need pre-emptive action.

The point is the response, not the register

Identifying a risk changes nothing. Deciding what to do about it, assigning someone, and doing it is the whole mechanism.

This is why register length is a poor indicator of quality. A project tracking six risks with active owned mitigations is better managed than one tracking sixty with none.

Why most registers are useless

Three reasons, and they compound. Risks are written vaguely, so no action follows. Nobody owns them, so nothing happens. Nobody reviews them, so they describe a project that has moved on.

Each is straightforward to fix, and fixing all three is what separates risk management from risk documentation.

The Five-Step Process

Step Activity Output Frequency 1. Identify Surface what could go wrong Risk statements At initiation, then continuously 2. Assess

Likelihood and impact

impact Prioritised list On identification, then at review 3. Respond Choose avoid, reduce, transfer or accept Response with owner and date On identification

4. Monitor Track whether responses are happening Updated register Weekly or fortnightly 5. Close

Close risks that have passed

passed or materialised Clean register At each review

Identifying Risks Properly

Identification works best with the people doing the work, prompted by categories, and written as cause, event and effect rather than as a single vague noun.

Ask the people doing the work

A risk workshop run by the project manager alone produces the risks the project manager can imagine.

The people building, delivering or operating know where the fragility is. Half an hour with them surfaces risks that no amount of desk analysis would, and it also means the eventual mitigations are ones they believe in.

Use categories to prompt recall

Unstructured "what could go wrong?" produces a short list dominated by whatever happened on the last project.

Prompt by category: technical, resource, external supplier, regulatory, commercial, organisational, dependency. Each category prompts a different set of memories, and coverage improves substantially.

Write risks as cause, event, effect

"Resourcing" is not a risk statement. "Because the integration specialist is shared with two other projects, they may be unavailable in March, which would delay the API work by up to three weeks" is.

The three-part structure forces specificity. It also makes the response obvious — you can act on the cause, the likelihood or the effect, and a vague noun gives you nothing to act on.

Assessing and Prioritising

Score likelihood and impact to sort the list, but treat the scores as a sorting aid rather than a precise measurement, and concentrate attention on the top handful.

Likelihood and impact Score each on a simple scale — low, medium, high, or one to five. Multiply or plot on a grid to get a rough priority.

Keep the scale coarse. Finer scales imply precision the underlying judgement does not support, and they generate arguments about whether something is a three or a four that produce no better decision.

Where scoring helps and where it misleads

Scoring is useful for sorting a long list quickly and for making relative judgement explicit.

It misleads when the product of two guesses is treated as a measurement. A high-impact low-likelihood risk and a low-impact high-likelihood risk can score identically and require completely different responses, so read the components rather than only the total.

Focusing on the top few

Most projects can genuinely manage five to eight risks actively. Beyond that, attention thins and nothing is properly tracked.

Keep the full list, but designate the top handful as actively managed with owned mitigations and regular review. The rest are monitored — visible, but not consuming attention until they move.

Responding to Risk

There are four responses — avoid, reduce, transfer, accept — and every one of them needs a named owner and a date, including acceptance.

The four responses

Avoid: change the plan so the risk cannot occur. Choose a different supplier, remove the dependency, change the approach.

Reduce: lower the likelihood or the impact. Prototype early, arrange backup resource, phase the delivery.

Transfer: move the consequence to someone better placed to bear it — insurance, a contractual term, a supplier warranty.

Accept: decide deliberately to carry it, usually because mitigation costs more than the expected impact.

Every response needs an owner and a date

A mitigation with no owner does not happen. A mitigation with no date happens eventually, which for a risk with a March deadline is the same as not happening.

Track mitigations as tasks with owners and due dates rather than as text in a register column.

Keeping them in the same system as the project work — as tasks alongside everything else, which any project tool supports — is what makes them visible enough to actually get done.

Accepting risk deliberately

Acceptance is a legitimate response and an underused one. Not every risk warrants mitigation.

What matters is that acceptance is explicit and recorded, with the sponsor aware. "We considered this and decided to carry it" is a defensible position; "nobody did anything about it" is not, and they look identical afterwards unless the decision was written down.

Keeping the Register Alive

Review on a fixed rhythm, close risks that have passed, and convert those that materialise into issues rather than leaving them in the risk list.

Review on a rhythm

Fortnightly for most projects, weekly for high-risk ones. Fifteen minutes: are the top risks still the top risks, are mitigations happening, has anything new appeared?

A register reviewed three times during a project is a control. One reviewed at initiation is paperwork.

Close risks that have passed A risk about a supplier's delivery in February is not a risk in April. Close it.

Registers that only grow become unreadable, and the genuinely live risks get lost among historical ones. Closing is as important as adding.

Convert risks that materialise into issues

When a risk occurs, it stops being a risk. Move it to the issue log with a resolution owner.

Leaving materialised risks in the risk register confuses the two categories and obscures how many things are actually going wrong right now. Many teams combine both in a RAID log — risks, assumptions, issues, dependencies — which keeps the categories distinct while holding them in one place.