All projects involve some risk. The earlier these are identified, the sooner they can be evaluated and countermeasures, where necessary, put in place. For this reason, risk identification needs to begin during the Definition Phase.
Typical threats to projects might include:
- A change in management policy or strategy
- Changes in legislation
- A failure or delays to the implementation of new technology
- Withdrawal of a partner
- A supplier’s failure to deliver
- Greater than anticipated resistance to the project
- Budget cuts
- Loss of project personnel
- Loss of public support or adverse public opinion
- Failure or delays to an interfacing project
- Poor estimation of time or cost.
The Office of Government Commerce (OGC) recommends that risks should be expressed the form of cause-event-effect (or impact). An example is illustrated in the diagram below.
So, to be clear, suppliers, budgets, stairs, and so on are not risks. The risks are 'a supplier failing to deliver', 'a budget being cut', 'someone falling down stairs', etc.
In deciding what countermeasures are appropriate, a number of factors need to be taken into account:
- The magnitude of the risk in terms of its probability of occurrence and the impact it would have
- When the risk might occur
- The practicality/cost of any response to the risk.
Risk responses can be defined in five broad areas:
- Prevention – taking action to stop the threat occurring or preventing it from impacting on the project
- Reduction – taking action to reduce the likelihood of the threat occurring or limiting the impact it has on the project
- Transference – passing responsibility for the risk to a third party, for example, by taking out insurance cover
- Acceptance – tolerating the risk either because nothing can be done at reasonable cost, or the magnitude of the risk is at an acceptable level
- Contingency – planning actions to take in response to the risk occurring.
In practice, we usually give consideration to both mitigating and contingent action when determining our response. Although the Project's governing body, e.g. the Project Board, has ultimate responsibility for risk, the Project Manager is responsible for ensuring risks are identified, evaluated, recorded and regularly reviewed. Ownership for each risk should be allocated to an individual who becomes responsible for monitoring the risk. Risk owners may include members of the Project Board.
As mentioned above, our response to any risk is partly influenced by the magnitude of the risk. We calculate this by multiplying the probability of the risk materialising by a factor that indicates the seriousness of the impact. In practice, unless you have a lot of data to draw on, the risk rating will be subjective, based on assumptions of the likelihood of something happening and the probable consequence. However, it is still a useful exercise as it allows us to compare risks against each other and gauge whether or not we should be making a positive response or simply accepting the risk as being too low not to cause concern.
A typical project risk is that of a supplier failing to deliver and jeopardising a milestone because they have underestimated the effort needed to meet your requirement. If you have not dealt with this supplier before, you might consider this to be of medium probability (M). The milestone is an important one and, if missed, could threaten the end date of the project. The impact is, therefore, regarded as high (H). Using the matrix below, this would give you a risk rating of 6, the second highest. Clearly, some mitigating action needs to be taken to reduce this risk. You might consider setting an earlier delivery date to give you a contingency if things go wrong, or obtaining references for the supplier before commissioning them. Increased confidence in the supplier’s ability to meet your target might lower the probability score to low (L), now giving a rating of 3.
The Risk Register
Information about risks should be recorded in a risk log or risk register. This is a dynamic document that is updated and added to throughout the project and subject to periodic review. It is usually presented in a spreadsheet format and includes:
Some organizations refer to the risks before countermeasures have been identified as ‘gross’ risk and recalculate the risk rating after the countermeasures have been identified to give a ‘net’ risk rating. So, taking the example above, the gross risk would be 6 and the net risk 3.
- Risk number
- Description of the risk (remember, this is an event)
- The impact (H/M/L)
- The likelihood (H/M/L)
- The date the risk was identified/defined
- The risk owner