Plan Risk Management Before Listing Risks
The risk workshop is usually the first risk activity a project does. Everybody comes, the facilitator works the room, and four hours later there are a hundred and forty entries on a spreadsheet. Nine months on, that spreadsheet has been reviewed eleven times, changed almost not at all, and influenced no decision anybody can point to. The workshop was not the problem. It ran before the decisions that would have made its output usable had been taken.
What should happen first is a short, dull conversation about how risk will be handled on this particular project: what counts as a risk worth recording, what the scores mean in money and days, who owns what, how often it gets looked at and by whom, and what happens when something crosses a line. Half a day at the start converts a list into a management tool.
The list is not the hard part
Identifying risks is the easy activity, which is why teams start there. Any competent group can generate plausible threats for an hour. The difficulty arrives afterwards, when somebody has to decide which of the hundred and forty deserve attention, and there is nothing in the register to decide with. Everything is scored medium because medium is what people choose when the scale has no anchor. Ownership is blank or defaults to the project manager. The review becomes a reading exercise.
Plan Risk Management, at Section 2.7.2 of the PMBOK® Guide, comes before identification for a reason that becomes obvious the first time you inherit somebody else's register. The plan sets out the approach and the register records what the approach finds. A register without its plan is a set of observations with no rules for acting on them, and the people who built it have usually left by the time that matters.
What the plan decides
Definitions come first, and they are project-specific. What is a risk here, as opposed to an issue, an assumption or a constraint? On a project with a long supply chain, a supplier's financial position is a risk worth carrying; on a six-week internal change it is noise. Writing the boundary down stops the register filling with things nobody intends to manage.
Scales come second, and they carry more weight than anything else in the plan. A three-by-three grid with the words low, medium and high means whatever the person scoring it wants. A scale that says high impact is anything above two hundred thousand pounds, or anything that moves a regulatory milestone, produces scores that can be compared and argued with.
Ownership rules come third. Decide up front that every recorded risk has a named owner who is not the project manager by default, that the owner is somebody able to act on it, and that response actions can have different owners from the risk itself. Most registers fail here quietly, and the failure shows up as a review where the project manager reports on all forty items and nobody else says anything.
Cadence and route come fourth. How often the register is reviewed, by whom, what triggers a conversation between reviews, and where a risk goes when it exceeds what the project can carry. An escalation threshold agreed in advance is worth a great deal more than a judgement call made in the week something goes wrong.
Scales that mean something on this project
Probability is the easier half. People are poor at percentages and reasonable at frequencies, so a band expressed as something that has happened on two of our last ten jobs travels further than a thirty per cent label. Where there is history, use it; where there is none, say what the band means in terms of what would have to occur.
Impact is where the work is, because a single scale rarely fits. A project can be exposed on cost, on schedule, on safety, on a regulatory obligation and on reputation, and one of those can be fatal while the others are tolerable. Setting a band for each, in the units that apply, lets a register show that an item scoring low on cost and high on regulatory exposure is the one to deal with first. It also forces a useful argument at the start, while everybody is calm, about which kind of harm this project is least able to absorb.
A contractor building a distribution unit ran the usual workshop and produced a register where ground conditions, a planning condition on lighting and a late steel delivery all scored the same. The scales were low, medium and high, and everything plausible had landed in the middle. The project manager rebuilt them with the client before identification restarted: impact bands in pounds against the contingency, in days against the sectional completion dates, and a separate band for anything touching the planning consent. Rescored, the register made an argument on its own. The planning condition went to the top, because a breach stopped occupation regardless of cost, and the steel delivery dropped, because there was float and an alternative supplier. The list barely changed. What changed was that it now said something.
How much of this a project actually needs
The plan should be proportionate to the project, and a page is enough for most. A short internal project needs agreed definitions, a named owner rule and a fortnightly look; anything more is a ceremony that will be abandoned by week three. A multi-year programme with contractual milestones and quantitative analysis needs scales that stand up to a claim, a defined route into contingency drawdown, and a clear line between what the project carries and what the sponsor carries.
The judgement to make is which parts are load-bearing for this project and which are habit inherited from a template. Getting that proportion right is a recurring call, and a structured PMP exam preparation course dwells on it, because tailoring is where most real risk decisions actually sit.
For a PMP® candidate, the distinction to hold is between the plan and the register: one defines how risk will be managed, the other records what has been found. Where a situation describes a struggling register, the thing to notice is whether the underlying problem is identification or the absence of an agreed approach. Uniform scores, blank owners and reviews that change nothing all point the same way.
Stop adding to an inherited register and spend an hour on its scales. Rescore what is already there against bands that mean something in your money and your dates, and the list will reorder itself, usually dramatically. Several items will turn out to be assumptions, a few will turn out to be issues that have already happened, and the handful left at the top will be the ones worth a conversation.
Interested in going further?
Setting scales that survive contact with a sponsor who wants everything marked high, and holding a definition of what counts, is a practical skill that separates a working register from a decorative one. Omega's PMP® Exam Preparation covers planning risk management as a tailoring decision, in predictive, adaptive and hybrid settings.
Plan Risk Management and the rest of the Risk Performance Domain are set out in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A152: The PMBOK 8 Risk Performance Domain: What It Really Covers
A153: Risk vs Issue: The Difference That Changes What You Do Next
A154: When Does a Risk Become an Issue?
A155: Risk Register vs Risk Report vs Issue Log: What Goes Where?
A157: Do Agile and Hybrid Projects Still Use Risk Registers?
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
