Project risks: five is enough

Risk management has a bad reputation in small teams, and deservedly so: it usually shows up as a forty-row table that is filled in once and never opened again.

That is a shame, because the useful core fits on one page and costs twenty minutes a month.

A risk is not a problem

The difference is tense, and it decides what to do.

	Risk	Problem
Tense	might happen	has happened
Question	How likely, how bad?	Who fixes it by when?
Belongs in	the risk list	the board, as a ticket

The most common mistake in risk lists is that half the entries are already problems. Those do not belong in the list, they belong in the work.

Five, not forty

A risk list with forty rows says nobody prioritised. Five is the right number — the five where you would actually do something.

Anything below that costs maintenance and returns nothing. If a sixth seems important enough, another one drops out. That is not sloppiness, that is the actual work.

Rating without false precision

Two questions, three levels each. No percentages, no scoring systems with decimal places — they fake a precision that does not exist.

	low	medium	high
Likelihood	unlikely	could well happen	expect it
Impact	a few days	the date wobbles	the project fails

Which gives the matrix:

	Impact low	medium	high
L. high	watch	act	act
L. medium	accept	watch	act
L. low	accept	accept	watch

Three cells say "act". If more than two of your risks land there, the project is cut too large.

Four ways to respond

For every risk in an "act" cell, one is chosen — and written down:

Avoid. Change the plan so the risk disappears. Most expensive, most certain. Example: take the boring interface instead of the untested one.

Reduce. Lower the likelihood or the impact. Example: test the risky assumption early instead of late.

Transfer. Someone else carries it — contract, insurance, supplier. Rarely worthwhile in small projects.

Accept. Deliberately do nothing, but know it is there and hold a plan B. Entirely legitimate, as long as it is said out loud.

What is not an option: record it and move on. A risk without a chosen response is a note, not a measure.

Template to copy

Risk	L.	I.	Response	Who	By when
Client does not sign off the design in time	high	med	reduce: fixed deadline at kickoff	Jey	Sep 24
Photos fail in bad weather	med	low	accept, backup date in calendar	Tom	—
Booking takes longer than estimated	med	high	reduce: start early, core first	Jey	Sep 30
Accountant does not respond	low	high	reduce: approach a second firm	Jey	Oct 6

Six columns, four rows. The last two make the difference: a risk without a name and a date does not get worked on.

When to review

Every two weeks, ten minutes, in the same meeting as the status report. Three questions:

1. Has one of them happened? → out of the list, onto the board as a problem.
2. Has one become less likely? → downgrade or delete.
3. Has something new appeared? → then something else drops out.

A risk list that does not change over three months is not stable — it is not being read.

In ORBYLOX

The list lives as a note in the project. Every risk in an "act" cell also gets a ticket with an owner and a due date — otherwise it stays a row in a table, and nobody works on rows in tables.

If a risk materialises, the ticket moves onto the board and becomes ordinary work. The deadline reminder handles the date so nobody has to remember it.