(Notes provided recently to a colleague explaining how to approach the management of Risk. The context is Business Continuity for a client where the client lead only considered Disaster Recovery as the solution.)
Think of DR in terms of a treatment for a specific risk.
A risk = something that might happen. If it does happen then we need to take action to resolve (what has then become) an *issue*.
The RISK is that “our systems will break therefore we will no longer be able to operate”. (Ie a Business Continuity (BC) risk in this instance).
As with all risks facing a business, there are always a number of ways to deal with each risk (so that it does not become an issue).
These “treatments” are valid at all levels within a business (project, programme, business unit or strategic) and why most Project / Programme managers are taught about managing risks within their transformation initiatives.
CRAPT is how I remember them:
Let’s look at each one.
Essentially, “a back up plan”. If this risk becomes an issue then we will take this course of action.
In BC-terms this could be your DR plan: close down one system and start up another.
We will reduce the likelihood of the risk becoming an issue (and “hope” we never have to deal with the issue).
In BC-terms this means using monitoring / early-warning systems to alert us to eg
We will accept that this risk might become an issue but have decided we can deal with the consequences.
Such an approach is valid if the costs of recovering from the issue are sigificantly lower than the cost of managing the risk.
In BC terms an example could be: in order to continue business with no interruption we need an entirely replicated parallel system ready to go. The risk is that it will not perform at the same speed. Having a same-speed system waiting in the wings will be very expensive, therefore I will *accept* there may be lower speed and deal with the consequences.
We will take whatever measures necessary to prevent the issue becoming an issue.
Often a high cost option and sometimes impossible.
In BC terms, I suppose you could prevent usage-based server outage by automatically killing non-essential processes as load increases.
In doing so, you prevent the risk becoming an issue, albeit with sacrifice elsewhere.
As near as you can get to a “not-my-problem” solution. In project terms: I have identified a risk to my project - a pile of unexpected work. This risks my budget and timeframe. However, I could fire up another project team to do that work and merge our 2 projects later on. Therefore, I have transferred the risk to someone else.
In BC-terms: I can transfer the burden of worry to another party. They will manage the risk (probably using the other treatments described above), communicating back to us the threat level for the risk becoming an issue. Client therefore manages a contract rather than the work required to manage the risk or the issue.
Other comments regarding risk management:
“Ignore” is never, ever a valid treatment
“Mitigate” – a catch all term. In fact it really is only one valid treatment (“Reduce”).