risk register

Also called: risk log, risk list

A short shared list of the project's risks, each with probability, impact in days or money on a written scale, an owner, a trigger and the chosen response. A dozen live risks with owners beat a long list nobody reads.

A risk register is the project's shared list of live risks, one row each. A row that people actually use has six parts: the risk written as cause, event and consequence; a probability; an impact; one owner; a trigger; and the next action for this week. Columns beyond that tend to stay empty.

Two written definitions at the top make the numbers comparable. First, a probability scale: words like "likely" mean one in three to one person and almost certain to another, so give each word a number (for example rare 5 %, unlikely 20 %, possible 50 %, likely 80 %). Second, impact in units the project already counts: working days of schedule lost, or money against the budget. Exposure is probability × impact, and it only makes sense within one unit: rank day risks with day risks and money risks with money risks. Multiplying a probability by a 1-to-5 "impact score" gives a number with no unit; calling that money is a common and misleading mistake.

Exposure is an average over many imagined versions of the project, and you run only one. So after ranking, ask of every row: "If this happens, can we still deliver?" A rare event that would stop the project keeps its place on the short list whatever its exposure.

The owner is the person best placed to notice the risk starting, not the most senior one. A trigger is an observable early sign with a date and a number ("fewer than 9 of 12 topics reviewed by 8 December"), not "keep an eye on it". Keep the register short, around ten live risks, and review it briefly every week inside the regular status: close risks whose date has passed, move risks that happened to the issue list, add new ones.

Example

Klasna's physics launch scores its risks on the scale rare 5 %, unlikely 20 %, possible 50 %, likely 80 %; impact is working days lost before the 1 February opening, or UAH over the 600,000 UAH ceiling.

Risk	Probability	Impact	Exposure
Checkout contractor delivers late	50 %	10 days	5.0 days
Final curriculum review slips	50 %	7 days	3.5 days
A vetted tutor leaves in January	50 %	6 days	3.0 days
Checkout fails the payment provider's review	20 %	10 days	2.0 days
Illustrator delivers late	50 %	4 days	2.0 days
Provider holds the account	5 %	30 days	1.5 days
Ad prices rise in January	80 %	30,000 UAH	24,000 UAH
Test places learners at the wrong level	50 %	24,000 UAH	12,000 UAH

Day risks total 5.0 + 3.5 + 3.0 + 2.0 + 2.0 + 1.5 = 17.0 days; money risks 24,000 + 12,000 = 36,000 UAH. The two totals are never added together. The provider hold sits at the bottom by exposure, yet if it happens no package of any subject sells for weeks, so it stays on the short list with a response (a second payment route agreed in advance). A full row for the top risk: owner Danylo; trigger "no working checkout on the test site by 4 January"; next action "a checkout demo from the contractor every Friday".

Common mistakes

No written scale. "Likely" then means different things to different people, and the ranking is noise.
Unscaled scores turned into money. 50 % × "impact 4" is not 2 of anything; use days or currency.
Adding days to money. Compare exposures only within one unit, or convert with a stated assumption.
Dropping rare catastrophic risks. A small average can hide an event that would stop the project.
A long list with no owners. Forty unowned rows protect nothing; ten owned rows with triggers, reviewed weekly, do.

Learn it in the course

A short risk register people actually use · Score each risk on written scales (probability, and impact in days or money), give it an owner, a trigger and a next action, and keep the list short enough to review every week.
Case: the launch risk register · Take the team's raw forty-line list, sort out the issues, assumptions and dependencies, score the real risks in days or money, add the missing ones, and send Leo the top five with owners, responses and triggers.
Break the work down from deliverables · Deliverables first, tasks second: a tree that covers all the work of the physics launch and nothing twice, flattened into a list with owners and effort ranges.
Changes without a committee, and a decision log · Route every change through one door, write a short impact note in days and money, let a named person decide, and record each decision in a few lines.