Project risk register: how to build and prioritise it

A risk is something that could happen and would affect the project if it did. A risk register is the list, with its status, of everything that could go wrong (or, sometimes, better) and of what you are going to do about it. It is not there to frighten anyone or to cover your back: it is there to think in time about what, if thought about late, turns into a crisis.

What is and is not a risk

• A risk is future and uncertain: it may or may not happen. "The supplier might delay delivering the data" is a risk.
• If it has already happened, it is an issue: you resolve it, you do not watch it. "The supplier has not delivered the data" is an issue.
• If it is a request to change the scope, it is a change request.

A risk that materialises becomes an issue. Hence the importance of having recorded it earlier: you already have the response plan. The guide on issue, risk or change request explains these differences with examples.

How to identify risks

A good identification session needs no more than an hour. Some sources that tend to bear fruit:

• Similar earlier projects: what got complicated then?
• External dependencies: on the client, suppliers, other teams. Everything you do not control.
• What nobody on the team has done before: a new technology, a new type of client.
• The most uncertain estimates: where there is an "it depends", there is a risk.
• Key people: what happens if they leave or fall ill?
• The calendar: fixed dates, holidays, the client's accounting closes.

Write each risk as a sentence with cause and effect: "If the client takes long to approve the analysis, the configuration phase will start late". A sentence like that can be assessed and managed; "problems with the client" cannot.

What to record

How to prioritise: probability and impact

The classic method crosses the two axes: what is likely and high-impact goes first; what is unlikely and low-impact is recorded and left. A three-by-three matrix is enough:

For each risk worth acting on, choose a response: avoid it (change the plan so it cannot happen), mitigate it (reduce its probability or impact), transfer it (for example, with a contract or insurance) or accept it (take it on with a contingency plan if it happens). The only thing that does not work is not deciding.

How to keep the register alive

A risk register that is filled in at the start and never opened again is useless. Some habits:

1. Review it at every follow-up meeting, five minutes: has anything changed?
2. Change the status as mitigation advances: from identified to monitored, to mitigated, to closed.
3. Add new risks when they appear, and close those that no longer apply.
4. Turn into an issue those that have materialised, linking to the original risk.
5. Count how many are open: a list that keeps growing is a signal in itself.

Common mistakes

1. Recording only obvious risks ("there might be delays"): they are so generic that they cannot be managed.
2. Not putting a plan. A risk with no response is just a worry written down.
3. Overrating the matrix. Probability and impact are estimates: they serve to order the conversation, not to calculate with false precision.
4. Hiding risks from the client. A risk shared in time is usually solved with the client's help; hidden, it blows up.

How it works in PjMan

PjMan includes a risk register per project:

1. Create the risk from the project's Risks tab with title, description, probability (low, medium, high), impact (low, medium, high), priority (low, medium, high or critical), status (identified, monitoring, mitigated, closed) and contingency or mitigation plan. (Risks)
2. Link it to a phase or a task, to know which part of the plan it threatens.
3. Edit it when it changes: who edited it and when is saved, and if someone else changed it at the same time, their change is not overwritten.
4. Probability, impact and priority are three independent fields that you set: PjMan does not calculate an exposure or draw the matrix; priority is what decides what to handle first.
5. Ask the assistant for the project status: it includes open risks ordered by probability × impact, and when preparing a follow-up meeting it lists them among the topics to discuss. (Status, forecast and client report)
6. A materialised risk is recorded as an issue, with its severity, assignees and hours.

Only the owning PM creates, edits and deletes risks; project management sees them read-only and a consultant has no access to the register.

Create your account or explore the demo.

Frequently asked questions

How many risks should a project have? As many as are worth managing: in a medium project, ten to twenty well written ones are usually enough.

Are there positive risks? Yes, opportunities, but a simple register concentrates on threats. If you want to note an opportunity, do so anyway with its plan to seize it.

When do I close a risk? When it can no longer happen (the date passed, the supplier delivered) or when it has been fully mitigated and needs no monitoring.