In the discourse on enterprise risk management, probably one of the least discussed issues is the risk register or risk log. What is a risk register? Information regarding the ID, assessment and mitigation of risk must somehow be recorded and managed in a sort of matrix – but how should it be done?
This entails questions about the appropriate number of columns; the right headings; the right order; and the terminology used. You must create or borrow an adjunct Likelihood and Consequence schema, and decide how the project risk log fits into a business intelligence regime. What is the technology, and what are the rules to report and escalate risks?
Of course the approach to risk information management will depend on the nature of the business. There is no single design; an IT risk register will have criteria not found in a generic project management risk register.
In the pdf posted here Risk Register-Risk Log Examples I’ve got excerpts, with sources cited, from four risk register templates. If we go through them in some detail, it could be useful to help you design the features you need to build a consistent approach.
In the first one, there are four columns. Evidently they’re talking about a construction site. The first column is called Risk Category, listing “existing structure” and “site conditions”. To my mind, those aren’t really risk categories; they are just parts of the (physical) context. Instead, if we called “site” context element A, and “structure” context element B, then we could apply to both of them many risk categories, that is, sources of risk; e.g., approvals; physical condition; weather hazards; safety and security; etc. Hate to be picky, but I think risk categories (abstract realms of risk) and context (whatever it is you are studying) are confused here.
In this same risk log template, the second and third columns (circled) are “Description” and “Consequence”. It’s not worthwhile splitting those into two separate columns. You can see that there’s content duplication in two cells in the second row. Although some people like to list several consequences for one risk; I prefer to have one line item identifying the root cause, if possible. This first risk register template is more like a facsimile than a working example.
The second example, by contrast, is more practical. Although not as elaborate as a full blown project management risk log, you could do a lot worse than this risk register to concisely note, date, assess and manage your risks. Purists will not like the word ‘hazard’ equated with the word ‘risk’ in the third column. Notice the column circled; they call action “new controls” whereas we would normally call that treatment or mitigation. This risk register does not permit much analysis, though – not even a ranking of the risks.
So far, then, we can see that there is a lot of variation not just in the design, but in how the terminology is used.
In the next post, we’ll finish the review of sample risk registers and discuss implications for the design of a risk register template for your organization.