Almost every manufacturing project I have worked on had a risk register. Almost none of them were being actively used by week four. The register was created at kick-off, populated in a workshop, and then filed somewhere it was never opened again until someone asked for it before a gate review.
This is not a discipline problem. It is a design problem. Most risk registers are built in a way that makes them difficult to maintain and easy to ignore. The structure is wrong, the ownership is unclear, and there is no natural moment in the project rhythm where reviewing it feels necessary rather than burdensome.
The good news is that fixing this is not complicated. A risk register that people actually use looks and works differently from one that does not, in a few specific and practical ways.
Why Risk Registers Stop Being Used
Before fixing the problem, it helps to understand why it happens. There are five reasons a risk register gets abandoned on manufacturing projects, and they are usually present in combination.
- 1
Too many rows. A register with 40 risks cannot be reviewed meaningfully in a status meeting. Teams stop trying. Ten to twenty actively managed risks is a workable number. More than that and the register has become a dumping ground.
- 2
No clear owners. If a risk is owned by "the team" or "engineering," nobody owns it. Every risk needs a named individual who is responsible for the mitigation action and for updating the status.
- 3
The mitigation actions are vague. "Monitor closely" and "raise at next meeting" are not mitigation actions. They are placeholders. A real mitigation action is specific, time-bound, and owned.
- 4
It lives in the wrong place. A risk register buried in a shared drive folder that nobody navigates to is a risk register nobody reviews. It needs to be where the project work happens, visible in the same view as the schedule and the issues log.
- 5
There is no review cadence. The register needs to appear on the agenda of your weekly or fortnightly project meeting. If it is not on the agenda, it is not being managed.
The Structure That Works
A risk register that gets used is one that is fast to review, easy to update, and built around ownership. Every row should contain exactly these fields, no more, no fewer.
| Field | What It Contains | Common Mistake |
|---|---|---|
| Risk ID | A simple reference number (R-001, R-002 etc.) | Not having one, which makes it impossible to reference risks in meeting notes |
| Risk Description | One sentence: the event that might happen and the consequence if it does | Vague descriptions like "supply chain issues" with no context |
| Likelihood (1–5) | How likely the risk is to occur, scored on a consistent scale | Scoring without agreeing the scale definition as a team first |
| Impact (1–5) | How severe the consequence would be for the project | Scoring impact on a different dimension than the one that matters (cost, schedule, quality) |
| Risk Score | Likelihood × Impact | Calculating this inconsistently, or not using it to prioritise attention |
| Owner | A named individual, not a role, not a team | "Engineering team" or "supplier", no individual accountability |
| Mitigation Action | What specific action will reduce the likelihood or impact, with a due date | "Monitor and escalate", which means nothing actionable |
| Status | Open / In Progress / Closed / Escalated | Never closing risks that have passed or been fully mitigated |
How to Score Risks Consistently
Inconsistent scoring is one of the most common problems in risk registers. Two team members will score the same risk differently because they have not agreed what the numbers mean. Fix this by defining the scale explicitly at the start of the project and using the same definitions for every risk.
| Score | Likelihood | Impact on Schedule | Impact on Budget |
|---|---|---|---|
| 1 | Unlikely, less than 10% chance | Less than 1 week delay | Less than 2% variance |
| 2 | Possible, 10–30% chance | 1–2 weeks delay | 2–5% variance |
| 3 | Likely, 30–60% chance | 2–4 weeks delay | 5–10% variance |
| 4 | Probable, 60–80% chance | 1–2 months delay | 10–20% variance |
| 5 | Near certain, over 80% chance | More than 2 months delay | More than 20% variance |
A risk score of 15 or above (high likelihood, high impact) should be escalated to the project sponsor immediately. A score of 9–14 is a risk that needs active mitigation and weekly review. A score of 8 or below is a known risk that should be monitored but does not require active mitigation at this point.
| Impact 1 | Impact 2 | Impact 3 | Impact 4 | Impact 5 | |
|---|---|---|---|---|---|
| Likelihood 5 | 5 | 10 | 15 | 20 | 25 |
| Likelihood 4 | 4 | 8 | 12 | 16 | 20 |
| Likelihood 3 | 3 | 6 | 9 | 12 | 15 |
| Likelihood 2 | 2 | 4 | 6 | 8 | 10 |
| Likelihood 1 | 1 | 2 | 3 | 4 | 5 |
Risks Versus Issues: Keep Them Separate
A risk is something that might happen. An issue is something that has already happened and is actively affecting the project. Many teams run these together in the same log, which creates confusion and makes it harder to manage either one well.
The practical difference matters: risks require preventive action, issues require corrective action. The owner of a risk is managing to prevent or reduce something. The owner of an issue is managing to resolve something that is already real. These are different tasks and deserve different tracking.
Combining risks and issues into a RAIDS log (Risks, Actions, Issues, Decisions, and Stakeholders) works well for smaller projects where maintaining separate registers creates overhead. What does not work is mixing risk entries and issue entries in the same rows without distinguishing between them.
How to Keep the Register Alive
The register stays alive when it is part of the normal project rhythm, not an extra thing added on top of it. Three habits make the difference.
Review it at every project meeting. Not a full line-by-line review every time, but a standing agenda item: are any red risks worse than last week, any new risks to add, any closed risks to remove? This takes five minutes when the register is in good shape.
Gate reviews must include a formal risk review. At every phase gate, the full risk register should be reviewed and re-scored. The risk profile of a project at Gate 3 is completely different from Gate 1. If you are carrying the same risks with the same scores across all four phases, the register has not been maintained.
Close risks that no longer apply. Risks that have been fully mitigated, or that the project has passed the point where they could occur, should be closed. A register full of stale risks from six months ago is as useless as no register at all.
A risk register that has not been updated in three weeks on an active project is not a risk management tool. It is a document that creates the appearance of risk management without providing any of the benefit.
Frequently Asked Questions
What should a risk register include?
A risk register should include a risk ID, a one-sentence risk description, a likelihood score, an impact score, a combined risk score (likelihood × impact), the named owner responsible for the mitigation action, the specific mitigation action with a due date, and the current status. Every risk needs a named individual owner. A risk without an owner is a concern, not a managed risk.
How often should a risk register be reviewed?
For a capital or NPI project, the risk register should be reviewed at every project status meeting, typically weekly or fortnightly. It should also be reviewed formally at each phase gate, with risks re-scored to reflect the current project state. A register reviewed less than monthly on an active project is not being managed.
What is the difference between a risk and an issue?
A risk is something that might happen. An issue is something that has already happened and is actively affecting the project. Both should be tracked, but separately. Risks require preventive action. Issues require corrective action. Many teams combine them into a RAIDS log (Risks, Actions, Issues, Decisions, and Stakeholders), which works well as long as risks and issues are clearly distinguished.
How many risks should be on a project risk register?
For most manufacturing or NPI projects, 10 to 20 active risks is a workable number. Fewer than 5 usually means the team has not thought hard enough about what could go wrong. More than 30 means the register has become a dumping ground. Focus on risks that are genuinely likely and would have a genuine impact on schedule, budget, or quality.
Book a Discovery Call
See how Arcturus Pro tracks risks, actions, issues, and decisions in one place for regulated manufacturing and med-tech project teams across Ireland and Europe. A 30-minute call, no obligation.
Book a 30-Minute Discovery Call