Almost every structured project creates a risk register at the start. Very few look at it again. That pattern is so widespread that it is worth discussing not better methods but the reason it is abandoned.
The reason is usually that the register was created for the wrong purpose. It exists because the process requires it — not because somebody wanted to answer a question with it. A document without a question does not get maintained, however well it is built.
A risk is not a state
The most common craft error sits in the wording. "Unclear requirements" is not a risk but a description of a state. It cannot be assessed, because it is unclear what is supposed to happen, and no measure can be derived from it.
A usable entry states a possible occurrence with its consequence: "If requirements are not signed off by the end of the concept phase, delivery slips by at least four weeks." That form can be assessed, it names a moment, and it makes visible whether the measure is working.
Consistency matters more than the scale
Much is debated about assessment scales. Three levels or five, numbers or colours — that is secondary. What is decisive is that everyone assesses the same way. If one person rates everything high and another rates everything medium, the prioritisation is worthless however fine the scale.
What works in practice is a coarse scale with two or three anchor examples: what counts as high impact, how do you recognise medium? Setting those examples once costs half an hour and makes assessments comparable across people and time.
Four responses, and one gets confused
For every risk there are four routes: avoid, reduce, transfer, accept. The fourth is the most misunderstood. Accepting is a legitimate and often correct decision — where the cost of a measure exceeds the impact, anything else would be uneconomic.
The difference between accepting and ignoring lies solely in the documentation. An accepted risk is assessed, named and carries a deliberate decision. An ignored one is not written down. If it occurs, the difference is substantial: in the first case it was a judgement, in the second an omission.
The risks that are systematically missing
Registers contain mostly technical and schedule risks, because those are easiest to name. Three other categories are systematically under-represented. Personnel risks: what happens if the one person who understands a particular system leaves? Organisational: what if the client changes role and the successor has different priorities? And dependencies on third parties whose schedule the project cannot influence.
Those three are uncomfortable, because their measures are inconvenient — spreading knowledge costs time, and naming a dependency can read as distrust. That is exactly why they are missing, and exactly why they hit projects more often than the technical risk everyone wrote down.
Risks and issues belong separated
A risk may occur; an issue has occurred. Kept in the same register, the issues displace the risks, because they are urgent. Before long the risk register has become a to-do list — and the forward-looking function it was created for is lost.
What keeps a register alive
Two things make the difference. First, a fixed, short review slot: fifteen minutes answering three questions — is the risk still current, is the measure working, has anything new appeared? Second, a named person per entry. A risk that belongs to the project belongs to nobody.
And a rule about size: ten seriously maintained entries are far superior to fifty filed ones. The completeness of a register is not a mark of quality — its effect is.