In a recent blogpost, Dr Eoin Clarke included a link to the NHS Risk Register for London. In anticipation of the publication – or, more likely, leaking – of Andrew Lansley’s Health and Social Care Bill risk register I have put together this introductory guide.
Every project should have a comprehensive risk register, owned and updated by the project manager. It’s a critical project control document. When there is a programme divided into separate projects, the programme manager will be responsible for bringing together the risks from the separate projects and managing risks to the overall programme.
The success of a project is measured by criteria agreed early in the project and can be visualised as a point or small area within a triangle, the apexes of which are Time, Budget, and Quality. A risk is the threat of an event which will have an impact on the success of the project. Delays, for example, may impact timescales (and budget, if unplanned resource is purchased to get back on schedule).
It is vital that the Quality criteria are agreed and carefully defined. When, as is the case with the NHS Reforms, a service is being changed the quality criteria should set out comprehensively and measurably what the service will be when the project completes. Note that this has to be measurable. It is unsurprisingly a far more complex challenge to agree “SMART” criteria for Quality than for making Time and Budget measurable. Moreover, there is likely to be another set of risks: risks to those parts of the service which the project is not directly changing.
Those possible side-effects of the project may be controlled through a separate “service” risk register, helping the managers of the ongoing service to identify and mitigate the risks that the project may create for the ongoing service. This makes it obvious that the project people and the service people must collaborate and communicate successfully in order to manage risks.
A Risk Register then must comprehensively set out the threats to delivering on time, on budget, and to agreed quality; and it must be used as a control tool to “manage” the identified risks. It is very much a live document, constantly used, reviewed, and updated and provides key information for project progress reporting.
Bearing this in mind, time to have a look at the London NHS risk register.
Sequence number should be unique in this register, and the identifier should be unique for all the risk registers in the programme. This Identifier starts with TR which probably means Transition. It’s categorised as London-Wide, and sub-categorised as Reputational, Clinical, and Financial. I’m not clear what Priority # means at this point.
Remember the risk is the unplanned occurrence. That should be separated from what might cause the risk, what might trigger it (cause it to happen), and what the impacts might be. If you imagine a risk that the price of some component you needed to purchase for your project may rise over the project lifetime, you could record what might cause that (a rise in sub-component prices, perhaps), what might trigger the risk (speculation in the commodity markets) and what the impacts might be (starting with how much more the component will cost, and whether there will be delays in delivery).
The reason for breaking each risk down this way is to work out how you will “manage” it. You have a number of options: you could do one or more of the following:
- Accept risk. Do nothing. You might do this if the probability of it being triggered is relatively low, or if the impacts are not severe. Remember you have to consider the total cost of the risk management.
- Transfer risk. If you agree a contract with the supplier with a fixed price and fixed date (and penalties), you can transfer risk to the supplier. There is one major caveat: you cannot transfer reputational risk. If your supplier fails you might protect your budget, but you will still take the reputational hit.
- Control causes or triggers, to prevent the event from occurring. (For example, buy all of the component you require at the current price and hold it as inventory)
- Mitigate one or more of the impacts.
Back to the document. Risk TR003 (an identifier perhaps optimistically based on there being less than 1000 risks on such a major set of changes) has a very general title “Delivery of major service changes”. The title doesn’t look like a risk at all, but a (vaguely defined) objective. Unsurprisingly, it is not clear what the actual risk is.
It looks as if the risk may be that “the necessary transformation” will not be delivered on schedule, but the words used are “at pace”. The risk is not that there may be “insufficient focus” – that’s a cause which needs explaining – and it’s not stated exactly whose “focus” will be “insufficient”.
The sentence beginning “This applies both … ” hides at least one other risk; that “proposed changes” will “emerge” that are not yet planned, which may impact the full implementation of known changes “not yet fully implemented”.
The second paragraph is not defining the risk but the impact or “consequence” (singular), and is not only vague but reads in large part like a fallacious argument, full of questions begged. (What is the “clear clinical case for change”? What are the “significant improvements” to be delivered?)
In sum, it’s difficult to work out from this definition of the risk exactly what the risk is, and therefore exactly what actions should be taken. What it definitely does reveal is that this “Transition” is a major risk to another programme of work, and will trigger major risks to itself (in the “emerging changes”).
Even from just this one risk, the register gives the sense of a programme which is not under adequate programme or project control.
The next column is headed “Proximity Date”, meaning presumably when the risk may be triggered. For risk TR003, this date is “ongoing”. In other words, this risk – whatever it really is – has been triggered, and is no longer a risk but has become an issue. The impacts are happening, and must be mitigated using the planned actions. According to the next column, this risk should have been reviewed in October 2011.
Even a relatively small project may populate a large risk register, and clearly not all risks are equal. It is necessary to prioritise the risks, and a straightforward way to do this is to multiply the probability of the risk occurring by the impact of the risk occurs, and then sort the risks in descending sequence by the results. Prior to mitigation, this risk scores 20 (though given the “ongoing” proximity, the 4 for likelihood looks lower than it should be.
Remembering that according to this risk, improvements in the health of Londoners are being “undermined”, the mitigation does not inspire much confidence. The existing mitigation “provides an opportunity”, the planned mitigation has a dependency on yet to be published plans and includes yet another assumption (this time about the capability of NHS London), while a reconfiguration guide will be published before Oct, 2011.
I am therefore not surprised to see that after mitigation, the score for this risk has not moved. The risk (whatever it actually is) has not been controlled. Insufficient or inappropriate mitigation has been done. It is a project failure, and quite possibly triggering risks to existing service.
The Assurance (it’s not clear what is being assured) is provided by monthly meetings and two IAS studies. Given that this is an issue and no longer a risk, and by its own definition the health improvements needed by Londoners are being “undermined”, I would be looking for more urgent and positive action. Now who’s running this project?
Footnote on Transferring Risk
This is exactly what Apple has done changing a major component at late (and very short) notice, and its suppliers’ employees have to work round-the-clock on additional shifts to incorporate that change into production by the release date. Apple allegedly mitigates the reputational impact by including clauses in supplier contracts that prevent the supplier from revealing its contracts with Apple. One suspects there is also an implied threat that Apple will readily move contacts to other suppliers. The supplier then transfers at least some of the risk to its employees – “work hard at your job today, or search hard for a job tomorrow”.