Risk registers that drive action

0:00 'Weather' is not a risk

Open almost any risk register and you'll find entries like these. Weather. Permits. Resources. Supply chain. They look like risks. They're not. They're topics. You can't assign an owner to 'weather', you can't estimate its impact, and you can't tell when it's been dealt with. In this lecture you'll learn to write risks that can actually be managed, using a cause, event and effect structure, to assess them consistently, to choose the right response strategy for threats and opportunities, and to link each significant risk to the cost, schedule and contingency it affects. By the end you'll be able to turn a list of vague worries into a register that drives action every week, rather than a document that gets updated once and forgotten.

0:54 Why it matters

Why does this matter? Because risk management is about making uncertainty visible early enough to do something about it. A risk you spot in design costs a conversation. The same risk spotted on site costs rework, delay and often a dispute. But a register only helps if it drives action. The ones that work are linked: each significant risk points at the control account and schedule activities it affects, has a cost and time impact range, and connects to contingency. The ones that fail are lists produced in a workshop at the start, then updated once a quarter because someone asks. Here's a simple test: when did a risk entry last cause somebody to do something differently?

1:45 The concept: a clear risk statement

Here's the structure. Because, then the cause. There is a risk that, then the uncertain event. Which would, then the effect on your objectives. For example: because the grid operator's approval process is new, there is a risk that connection approval is delayed beyond month six, which would delay energisation and revenue by up to two months and add standby costs. Now you know what to watch, who might own it, what to do about it and roughly how much it matters. Think of it like a doctor's diagnosis. 'You feel unwell' is a topic. 'Because of this, there's a risk of that, which would cause these symptoms' is a diagnosis you can treat. And remember, risks can be positive too. An opportunity is an uncertain event that would help your objectives.

2:42 Assess and respond

Next, assess. Most teams start with a probability and impact matrix, and that's fine, if the scales are defined in concrete terms. High impact might mean more than two hundred and fifty thousand or more than four weeks' delay. Without definitions, one person's 'high' is another's 'medium' and the scores mean nothing. Then plan a response. For threats: avoid, by changing the plan. Transfer, through insurance or contract. Mitigate, by reducing probability or impact. Accept, actively with contingency or passively. Or escalate, if it's outside the project's authority. For opportunities, the mirror images: exploit, share, enhance, accept or escalate. Every high risk gets an owner with enough authority, and at least one action with a date.

3:32 Worked example one: rewriting vague risks

Let's rewrite one. The register says 'Permits'. I ask: which permit, and what's uncertain about it? The answer: the road-closure permit for the western section. The council has a new online process, and nobody on the team has used it yet. So: because the council's road-closure process is new to the team, there is a risk that the permit for the western section is not granted before week twelve, which would delay the drainage works by up to three weeks and push the critical path. Owner: planning lead. Trigger: no acknowledgement within thirty days of submission. Action: a pre-application meeting with the council by the fifteenth of April. In two minutes, a word has become something you can manage.

4:24 Worked example two: a Riyadh logistics park

Now the realistic scenario. A fictional logistics park developer near Riyadh identified sixty-four risks in a workshop. The register became a document nobody read. The controls lead introduced three rules. One: every risk must be written as cause, event, effect. Two: every high risk must have at least one action with a date. Three: the steering committee sees only the top ten by score, plus anything new or escalated. That's it. Within two months, the number of risk actions completed each period had tripled, and two major risks, utility capacity and a customs clearance delay, were closed early through mitigation. Nothing clever. Just a register designed for decisions rather than for completeness.

5:13 Watch me do it: a register that scores itself

Let me show you the register I'd build in a spreadsheet, and the same logic works in SharePoint lists, Jira or a dedicated risk tool. Columns for ID, the cause-event-effect statement, owner, probability from one to five, cost impact and time impact. Impact scores come from lookups against the defined scales, so nobody debates what 'high' means. The score is probability times the higher of the two impact scores, and a rating column converts that into low, medium, high or very high. Then two columns I find invaluable: last updated date, and days since update. Anything open and not touched in thirty days turns amber. Finally, a filtered view: top ten by score, plus anything new or escalated. That's the page the steering committee sees.

6:07 Link risk to cost and schedule

A risk register becomes a controls tool when each significant risk is linked. Linked to the WBS or control account it affects. Given a cost and schedule impact range, with a minimum, most likely and maximum, not a single guess. Linked to contingency, so every drawdown references a risk ID. And mapped to specific schedule activities, so it can feed quantitative analysis in the next lesson. That's what lets you answer questions like: do we have enough contingency left for the risks that remain? Which risks threaten the handover date? And that's also what lets any AI or analytics tool do something useful with your register, because the links give it structure.

6:56 Common mistakes and AI

The common mistakes. Topics instead of risk statements. Registers updated once at the start and then ignored. No owners, or owners without the authority to act. Only threats, with opportunities never considered. Scoring that everyone interprets differently. And confusing issues, which are already happening, with risks, which might happen. Now AI. Language models are genuinely good at suggesting risks from similar past projects, detecting duplicates, rewriting vague entries into cause, event and effect, and flagging stale risks. Use them. But an AI-generated risk list is a prompt for discussion, not a finished register. The human owner validates every suggestion, because only people who know the project can judge whether a risk is real.

7:45 Recap and try this now

Let's recap. A risk is an uncertain event that would affect your objectives, written as cause, event and effect. Assess it with scales defined in concrete terms. Choose a response: for threats, avoid, transfer, mitigate, accept or escalate, and for opportunities, exploit, share, enhance, accept or escalate. Give every significant risk an owner with authority and a dated action, and link it to the WBS, an impact range, contingency and the schedule. Keep it alive by reviewing the top risks at every project meeting, asking whether probability or impact has changed, whether actions are done and whether any trigger has fired. Your try-this-now: take five vague risks from a project you know, such as weather or permits, and rewrite them as cause, event and effect statements, each with an owner and one action.