A review of a Health Service risk register
On the 27 March 2012 the draft National Health Service transition risk log
(PDF) was leaked to the press. It is dated 28 September 2010 and is headed 'draft for discussion'.
A case study of a real life Risk Register
The National Health Service Risk Register is a great case study, unfortunately in 'how not to do' a Risk Register.
Press comment on the leaked document has focussed on the content of risks and the lack of mitigating actions for some risks. It is true that some of the risks sound scary, suggesting negative impacts on performance and emergency preparedness, but this is the purpose of risk management: all possible scenarios need to be considered.
The real issue with the Health Service Risk Register is that it doesn't meet Risk Management Best Practices. stakeholdermap.com
In this article I will review this early draft of the NHS risk register against project management and risk management best practice and identify what we can expect to be added or clarified in future versions.
Overview of the register
The register leaked to the press is a draft for discussion, it captures the input of multiple contributors who been working to identify the possible risks to the transition project. We can see this in the varying format of risk descriptions. Clearly the register is a work in progress and has rightly attempted to capture as many potential risks as possible.
For each risk the register considers proximity, likelihood and impact, the latter two on a scale of 1 to 5.
Each risk has a unique ID and area and most contain some suggestions for treating the risk. At the moment these mainly relate to reducing of likelihood of the risk occurring.
What needs to be improved in the Risk Register?
Hover your mouse over this image to see some of the problems with this risk register.
Some journalists have expressed dismay at what they see as a lack of detail in the register, but it is important to note that it is a very early draft. Risk registers are working documents that should be continuously refined and updated over the course of a project. In future versions there should be improvements in the following areas:
Additional areas of risk
The papers have expressed concern about the number of risks, but in future versions of the risk log there should be more areas of risk. Several risk management guides recommend the use of the ancroynm PESTLE (political, economic, social, technological, legal, environmental) to identify risks.
There should be more risks in the register particularly around the social, environmental, and legal considerations relating to the transition.
Clearer risk descriptions
In September 2010 the NHS transition project team
won't have had a detailed understanding of all of the risks in the register and more importantly their possible effects. However, it should have been possible to identify high level risk responses for each risk. Many of the risks don't have any mitigating actions, because the risk itself needs more definition.
For example the description for risk ID 31 states
'Deterioration in industrial relations'
This is not a risk description. It describes what would happen if some unknown risk was realised. It describes an effect not a cause.
The next step will be for the team to work out what risk events could lead to a deterioration in industrial relations and document mitigating actions against each one (there are probably many).
The description for 34 is more developed but the risk is not yet clearly stated:
'Staff morale. Maintaining staff morale in a time of change
will require strong leadership behaviours across the
Failure mode and effect analysis (FMEA)
would help the team to define this risk more clearly and reveal actions that could be taken to treat the risk; as in the example below:
||Cause of failure
Mitigating or avoiding action
Low staff morale
Poor change management
Reduction in performance
Increase in staff turnover
Delays in implementing bill
Negative impact on business as usual
- Provide training on leading change
- Identify strong leaders and arrange for them to mentor others.
- Define what it means to be a strong leader and communicate to the sector.
- Transfer the cause of this risk to a partner i.e. outsource the leadership of the change.
- Limit the impact of the risk by putting plans in place to improve morale if a drop in performance is noted.
[these are just suggestions, you can probably think of many other ways to treat this risk]
For more information on the use of FMEA in project management risk analysis see Lock, 2007, p.101-02
The Office of Government Commerce, publish a Glossary of Terms and Definitions on their Best Management Practice website. Risk is defined as 'An uncertain event or set of events which, should it occur, will have an effect on the achievement of objectives.' (Office of Government Commerce, 2008
). Risk 22 appears to describe something that has already occurred:
'At present there is significant variability in transition cost
estimates. (particularly redundancy costs relating to the
ability to TUPE staff from PCTs to GP consortia / public
Again the risk is not clearly stated, but it is possible that what is described here is an issue
rather than a risk.
The wording suggests that there is already a significant variability in transition cost estimates which the team need to manage. If this is the case then the risk 22 should disappear from the risk log and be entered in the issue log for day to day monitoring and management (Office of Government Commerce, 2005 p.285 - 287
In the next version there are many other descriptions which will have been re-written clearly stating the cause and effect of each risk. We can expect to see risk descriptions following a structure for example: 'There is a risk of x because of y. This will cause z'. Following this structure the description for risk 34 could read:
'There is a risk that staff morale will be negatively impacted because of weak leadership during the transition. This will cause a reduction in performance and increased staff turnover which will delay the bill and negatively impact on business as usual'
Clarification of mitigating actions
Steps that the team will take to treat each risk are defined in the mitigating actions column. Many of the risks have mitigating actions aka risk treatments, but some will need to be clarified in order to produce clear actions and to define who will be responsible for each action. For example risk 10 has the following mitigation action:
'Ministerial agreement on roles requires
careful work and close alignment between
commissioning and provision strands.'
Is the action for ministers to agree roles or for someone, presumably a civil servant, to ensure close alignment in the roles that ministers agree? Which department/person will be responsible for this action?
The mitigating action for risk 18 should be more detailed.
'Requires challenge to ensure that players
are incentivised to develop new system in
line with principles of Liberating the NHS .'
The use of the word 'challenge' appears misplaced. Perhaps this should be replaced with 'action' or 'action plan'. A definition of 'players' is needed along with a reference to the principles of Liberating the NHS. The task of developing an incentivisation scheme is likely to be a project in itself. Perhaps this project is already in progress in which case an action is needed to input into the scheme.
Consideration of additional risk treatments
Project management and risk management methods differ in their descriptions and naming of the possible risk treatments or responses available
, but they generally fall under the following options:
- Accept that the risk is present, but decide to take no action, usually because the likelihood and/or impact of the risk occuring is low.
- Avoid the risk by doing something differently or not carrying out the activity likely to generate the risk.
- Limit the risk by authorising activities step by step. For example splitting an activity into phases with funding or authorisation of expenditure dependent on a review at the end of each phase.
- Reduce the likelihood that the risk will occur.
- Reduce the impact if the risk does occur, also known as contingency.
- Share the risk with another party. For example undertaking a project as a joint venture.
- Transfer the risk to another party, for example through insurance.
Most of the risk mitigating actions identified in the risk register attempt to reduce the likelihood that the risk will occur, some seem to consider how to reduce impact, but there doesn't appear to be any suggestion of accepting, avoiding, limiting, sharing or transferring risks
. It is possible that these simply aren't viable options, but I suspect they may become suitable treatments once more detailed work has been completed.
Addition of risk owners
Sadly the risk log is often where risk management begins and ends - the 'identify and run' approach to risk management.
Identifying and analysing risks is very important, but becomes a worthless exercise if the risk treatments are not completed.
Not assigning risk owners is a classic way to ensure that mitigating actions are not carried out.
Each risk must be assigned a single responsible owner who will ensure mitigating actions are completed, monitor progress and report back to the project board or steering group. At the moment it is probably not possible to name individuals, but at least the team could try to identify a department or body.
Addition of review and target dates
The likelihood of 'identify and run' can be increased by the lack of review or target dates for a risk. Review dates enable the project board to monitor progress and make corrections when actions are off course. Once a project plan is formed the team could also add the target dates for completion of the risk actions to the plan.
The risk log makes interesting reading and it is clear that careful consideration is being given to the risks associated with the transition project. This represents the first step in the risk management life cycle and in the next version we can expect to see more risks, greater clarity in the risk descriptions, more mitigating actions and the addition of risk owners.
A final note
The government has not published the final register, but in February they lost a Freedom of Information request to keep the risk register secret so we may see an updated version soon.
Free Risk template
If you need to manage risk or create a risk register download this free risk template
. The template contains all of the information you will need to capture and manage your risks and suggests some tips to help you produce a complete risk log.
Read more on Risk Management
Risk Register best practices - references
Watt, N. and Ramesh, R.(2012). Health reforms could damage NHS, warns draft risk register. The Guardian.
27 March. Available at: http://www.guardian.co.uk/politics/2012/mar/27/health-reforms-damage-nhs-risk-register?CMP=twt_gu (Accessed 27 March 2012).
Lock, D. (2007). Project Management.
9th edn. Aldershot: Gower. Latest edition Project Management
Office of Government Commerce. (2008). Glossary of Terms and Definitions. v06. The Office of Government Commerce.
Available at: http://www.best-management-practice.com/gempdf/OGC_Common_Glossary_English_v06_2008.pdf (Accessed 14 April 2012).