The Risk Log
An essential tool in any project management methodology is the Risk Log or Risk Register. This provides a means of recording the identified risks, the analysis of their severity and the necessary management actions to be taken. The risk log can be a simple document or spreadsheet or can be a database system. The JISC infoNet Project Controls Database includes a risk log as part of its functionality - the link here takes you to a page where this can be downloaded and full instructions for its use are provided in the accompanying User Guide.
As a general guide any Risk Log should contain the following data fields:
| Unique ID | This may be simply a title but some kind of alphanumeric coding is likely to be useful where you are dealing with a large number of risks. |
| Description | Presented in a structured format: Condition - 'There is a risk that' Cause - 'Caused by' Consequence - 'Resulting in' |
| Probability | What is the likelihood of the risk occurring? It would be helpful to record the justification behind this analysis. |
| Impact | What will the impact be if the risk occurs? It would be helpful to record the justification behind this analysis. |
| Timescale | What is the 'Risk Window' when this risk may occur and when do you start to lose options as to how you respond? |
| Cost | What will the risk cost if it does occur? N.B. You can't assess this unless you know what your response action will be. |
| Owner | There should be a person nominated to 'own' the risk which means monitoring the situation and ensuring that necessary management actions are carried out. In a project situation this should be somebody within the project team and in all cases it should be somebody who will be impacted by the risk and who has a vested interest in addressing it. |
| Management Approach | What are the agreed response actions? These may be broken into:
|
| Residual Risk | This is the expected level of risk once all the mitigating actions are complete. |
| Early Warning Signs | What 'trigger' might alert you to the fact that the risk is about to occur? In some cases you may only choose to spend money on a response action once the trigger occurs. |
You may also want to note any interdependencies between risks i.e. where one risk occurring impacts on another risk. This is sometimes known as 'Risk Coupling'. This cross-reference alerts you to the fact that when one risk occurs a related risk also requires reviewing.
A basic database tool such as the JISC infoNet Project Controls Database is useful in allowing you to sort and report on multiple risks but it may need to be backed up by more detailed documentation justifying the analysis and response actions of individual risks. The Project Controls Database allows you to record the existence and whereabouts of related documents. A common problem with Risk Logs is that they are too simplistic. Merely having logged the risks and possibly assigned them a probability and impact (often very subjectively) can give you a warm glow and the feeling that 'That's that sorted!'. Actually that's when the real work starts. We've covered the Risk Log at this point because it is a tool for you to record the identified risks as a first step in managing them. In all probability, having identified a risk, you will have to do a lot more analysis and planning before you can fill in all of the fields with any degree of confidence and start to turn the unknown into the planned.
