(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.)

--Quote--
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:

• Contingency
  
• Reduction
  
• Accept
  
• Prevent
  
• Transfer
  

Remember: nearly every risk can be treated in more than one way.  You have options. 

Let’s look at each one.

Contingency
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.

Reduction
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

• How close we are to capacity
  
• Speed of responses from servers as indicator of normal/peak running
  
• Intruder detection, etc, etc
  

Accept
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.

Prevent
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.

Transfer
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”).

At Portfolio and Programme levels, leadership (rather than management) starts to come in to focus.

The infographic (right) is a good distillation of required qualities and behaviours, however, I'd prefer to label the columns as "Managers" on the left and "Leaders" on the right.

To me, Leadership has not changed over the decades.  The workplace has not changed.  We always have (and always will) need both managers and leaders. 

Managers "push" people along, Leaders attract followers.

Managers concentrate on the "Who" and How",  leaders on the "What" and "Why".

During the last 2 weeks, twice I have been asked to explain the differences between these three "levels" of Change Management.

One of those for whom I needed to explain the difference was a Recruitment Consultant who "specialises in project management".  Slightly worrying.  I hope he doesn't confuse Daily Rates as well.

For 2-3 years now I have carried around a number of laminated graphics which help explain concepts that many of us use daily but are alien to others.  One of these this Venn diagram, the work of Jerry Buckoff which I accompany with the following description: