Risk Management

 

Why, What, How?

Risk is inevitable in everything we do. There may be commonplace risks that are almost inevitable, for example, the risk that a member of the team is sick for part of the project. There may be some unlikely but high impact risks, for example, the risk that the solution could cause the destruction of the organisation (see the case studies below).

The good Project Manager will constantly assess the risks and take action as needed. There are three possible outcomes for each risk:

The process for managing risks is:

Risk Management - available as a PowerPoint slide

 

Why is it hard to believe you could personally destroy the organisation?

 

Case Study

A European retail and wholesale bank replaced its core operational systems following their "Rapid Implementation Plan" (RIP). Their previous systems were obsolete and inadequate. As they needed the space for the new hardware when it was ready, they physically removed and scrapped the old hardware to switch over immediately to the new system.

Very soon, major problems were found with the new system. It did not correctly calculate interest and consequently was misstating customers' balances. Very large amounts of money were vanishing in the accounts. There was no possibility of reverting to the previous system.

Our review identified the problems and external teams were brought in to fix the system and to correct the accounts. The one thing we could not fix was their reputation. The bank was no longer a viable profit-making entity, but, thanks to our work, it was able to cease retail trading in an orderly fashion.

 

Case Study

A global telecomms service provider had built new customer and billing systems. To save time and cost, no one had bothered to document the system. Some time later they realised that this was causing operational difficulties in running the system.

Our work was to retro-document the systems. As no one knew any of the detail we did this by examining the code and deciphering what it did. One element of the billing algorithm was particularly strange. When we explained it to the Finance Director he said "no it can't work like that - if it did we'd be bankrupt". It did, they were.

 

Assessing risks

Statisticians love to play with the mathematics of risk. The basic formula is simple:

probability of the risk times costs if it happens equals expected cost from this risk

Equally simple is the rationale to apply when considering avoiding actions: if the cost of the avoiding action is less than the reduction in the expected cost of the risk then it is worthwhile.

             
  Quantifying Risks and Justifying Avoidance Actions  
             
  Probability  

.5

     
x Financial impact  

10,000

x    
= Expectation of losses  

5,000

 

5,000

 
             
  Cost of avoidance or risk reduction  

2,000

 

2,000

-
             
  Probability after effect of avoidance / reduction actions  

.1

     
x Financial impact after effect of avoidance / reduction actions  

10,000

x    
= Revised expectation of losses  

1,000

 

1,000

-
             
  Net benefit from actions      

2,000

 

Note that you can reduce the expected cost of a risk either by reducing its probability, or by reducing its impact.

This guidance is mathematically sound, but there are several practical problems with relying solely upon such logic, for example:

Suppose you tell the Project Sponsor that there is a 1 in 10,000 chance that you might destroy the organisation. Assuming you are not fired immediately, how much would it be worth to reduce that risk to 1 in a million? How much would they pay to reduce it to zero (assuming that could ever be possible)?

Suppose that the risk would not damage the project or its planned benefits but it would damage your third party contractors. This is not uncommon where a fixed price contract has been agreed. The risk might be that the availability of departmental resources fails to meet the planned level. When the contractor runs late and has to put in more resources - it is probably the organisation's fault but it may be the contractor's risk and to the contractor's cost.

Suppose there is a minute risk of with an enormous consequence. Think about this bizarre example:

How does the chance of the Project Sponsor being run over by a bus compare with the chance of their being killed by an asteroid strike? Bus accidents happen every day, so you would assume that was the more common risk even though they usually only harm one person at a time. Asteroid strikes are extremely unusual, say one case in every 500,000 years, but when they occur they might kill say a quarter of the world's 6 billion people. If you work out the statistics, the chance of being killed by an asteroid strike is only 25,000 to 1. Some claim that is more probable than a bus accident. It is in the same ballpark as dying in an aircraft accident and it is much more likely than winning the top prize in a lottery

Now trying telling your boss that you have calculated it is worth spending 1.5 billion on asteroid risk avoidance and see what the response is. You would be crazy unless, maybe, your boss is the President of the United States.

There is no easy answer to any of these difficulties. The bottom line is that the Project Manager needs to discuss and agree the appropriate response to all significant risks that have been identified.

 

Assessing risks at the start of the project

During the Project Definition, the headline risks should be considered as part of the overall benefit model. At this stage, you will not be dealing with a full catalogue of risks, consequences and actions. You will focus on the main areas that affect either the justification of the project or the manner in which it will be carried out.

It is unwise to rely solely on your own judgement. You would normally include some questions about risk when talking to the various participants about the project's scope and objectives. You might also instigate some specific activities to examine risk, for example additional interviews, workshops and brainstorming sessions. Where there is a specialist area involved, you should consult with an appropriate expert, eg web-server sizing, change management, etc.

A good technique for presenting these issues is to use a risk matrix showing the probability of different headline risks in comparison with their relative impact on the project's goals.

Risk Matrix - also available as a PowerPoint slide

This focuses attention on the areas where the project plan will need to address key issues and where specific actions and techniques may be required. Note how this example suggests that the biggest area of concern tends to be with the "people issues". The human element of a solution is often the most overlooked aspect.

The other thing you should do early on is to decide upon the procedures and technology for managing risk. In most cases you will use some form of technology, preferably as part of a set of integrated Project Office tools. The procedures should make it easy for all participants to submit their thoughts and concerns. Always capture the thought. You may dismiss it later if appropriate, but you should always consider and assess the input.

 

Assessing risks at the start of each phase

When you prepare in detail for each phase of work you should look at the risks in detail. Try to identify all realistic risks that should be considered. In most cases, it will be worth capturing the information electronically in a risk register. It should show:

Here are some examples of risks and what you might do about them.

Risk

Probability

Impact

Response

Team members leave or become sick High Low Ensure the plan has contingency built into it to allow for less than expected resource availability.
Key team member becomes available Medium Medium Ensure project procedures include good knowledge sharing and documentation so that the thought process, designs and decisions are not lost.
Solution does not meet the business needs Low High Ensure good participation and collaboration involving representatives and resources from all concerned areas of the business (and external parties where appropriate).
Insufficient participation from the business units and users High Medium Ensure the Project Sponsor and supporting sponsors are aware of the importance of promoting and rewarding participation. Agree how they will convey that message.
Significant change in the business and its consequent needs (eg restructuring, mergers etc) Medium High Business needs frequently change, so plan the project so that it could adjust rapidly at relatively low cost, for example, a number of short incremental steps towards the goal could be easier and cheaper to re-direct than one enormously long delivery project.
Technical solution has major flaws Low High Invest in appropriate levels of testing. Consider a period of parallel running. Have a fallback contingency plan to revert to a previous system if necessary.
Technical solution has operational flaws High Low Put in place an "early care" programme to deal with immediate snags. Ensure processes, resources and responsibilities for on-going maintenance are established well before live date.
System failures High Medium Invest now in fault tolerant components and adequate redundant contingency resources. Ensure the plan includes appropriate backup, recovery, and disaster recovery procedures (and tests them).
Hardware, network or system sizings inadequate to meet live demands. Medium Medium Sizing calculations are always difficult. Many successful eSolutions have been swamped by demand. Make sure the systems you use can be scaled up by a significant factor before any need to move to a different technological platform.
Users fail to use the new system effectively and efficiently Medium Medium Plan for a detailed Training Needs Analysis and put in place an appropriate training programme. Consider how to coach and support users after live date.
Users resist the changes High High Use change management experts to assess the issues and create a change programme. Co-ordinate communications and sponsorship activities to convey the message. Confront big issues early in the project (not just before live operation).

 

These example risks are common to most projects. Also, consider the specific risks for your project, for example:

Needless to say, the results of the risk assessment are not for your eyes only. The risks and implications should be discussed with the relevant leaders and participants. Planned responses to those risks should be agreed by the Project Sponsor and Steering Committee.

 

Managing the risk

Risk management should be seen as a continuous process throughout the project. Once the initial risk register and procedures have been established the Project Manager, Project Office staff, and all project participants should be alert for new, changing or occurring risks. Participants should be briefed on the importance of this and the specific procedures. Procedures for reporting risk should be as easy as possible. Feedback from all participants should be encouraged and rewarded.

The Project Office would normally review the risk register proactively on a regular basis. They would check the status of potential issues, for example, by calling the responsible party and checking if there has been any change in status. The Project Manager should also review the register on a regular basis and take action as required. Headline information on risks would be reported to the leadership along with the other project performance data.

As risks actually occur they need to be managed. Where a contingency plan had already been formulated, the Project Manager should be able to take immediate action to mitigate the impact.

 

Case Study

Oresund Bridge During the construction of the spectacular Oresund bridge and tunnel, which connects Sweden to Denmark, risk analysis showed that the project was unlikely to meet its planned opening date upon which its financial viability was calculated. Mitigating actions and alternative scenarios were considered leading to significant changes in approach. After the mitigating actions were applied, the risk analysis showed high confidence that Oresund could be opened three months early - which it was. Early opening easily paid for the specialist risk management work.

 

 
ePMbook - click to re-load
Copyright   Simon Wallace, 1999-2014