DRIVE

Management of Risk

Overview

A risk may be defined as the chance of exposure to the adverse consequences of future events. It is a potential problem that would have an impact on the progress of the project if it were to happen. Risk Management attempts to identify the risks that would have the greatest impact and devise a way of dealing with them so that the project has its greatest chance of success. Experience on previous projects has shown that effective risk management is an important element of overall project control.

Risks are considered from the outset of any project. Regular reviews are held throughout the life of the project to assess risks previously identified and to identify new risks.

Steps that Risk Management applies to are as follows:

Step 1: Starting up a Project The Business Brief contains a description of major risks apparent at that stage. Risks are described in subsequent Feedback Forms and the Project Proposal.
Step 2: Initiating a Project The Risk Register is developed in parallel with the Project Management Plan and the Cost Benefit Analysis
Step 3: Delivering a Project Regular risk reviews are held where new risks are identified, existing risks re-evaluated and risks that are no longer relevant deleted from the Risk Register.

The Project Manager is responsible for producing the Risk Register and keeping it up-to-date throughout the project (or this may be delegated to a project support role)

All projects carry risk, if for no other reason than the fact that they are innovative. The decision to undertake a project at a certain cost and in certain defined timescales must to some extent be based on an assessment of the risks involved: risks of timescale slippage, of cost overruns, of business benefit being eroded by the action of competitors, of changes to current legislation and so on.

The risks inevitably change during the execution of the project, and may alter substantially the original business justification for action. Risks are documented in the Risk Register and summarised for management information in a Risk Log.

Risk Management consists of six activities:

Risk Identification
Risk Analysis
Risk Prioritisation
Risk Management Planning
Risk Resolution
Risk Monitoring

Risk Identification

The first activity is to identify and list a set of all significant risks. Since risk may occur in any area of the project and its environment - technical, operational or market - risks need to be identified by the widest possible group. The normal way in which this is achieved is via a facilitated risk planning workshop (see also running a workshop and risk planning workshop template). Such a workshop brings together those responsible for the delivery of the project with representatives of those likely to be working on the project, and those likely to be affected by it. The presence of a facilitator helps to keep the workshop on track and to achieve its goals effectively.

Risks are identified during an initial brainstorming session. For a fixed period of time, the facilitator asks those present to consider “What could go wrong with ...”. Risks are listed uncritically on flipcharts or whiteboards. Then, the risks are grouped and duplicates eliminated before being uniquely identified and added to the project’s Risk Register. Some candidate risks that can be used as a starting point for a project’s Risk Register are included.

Another useful way of deriving risks is to examine any assumptions documented in the Business Brief, Project Proposal or Project Management Plan. An assumption carries with it an implied risk - if the assumption turns out to be invalid, this will be a risk. For example, a planning assumption may be that resources are available at the point they are required by the Project Schedule - the risk is that they will not be available. During the course of the project, new risks may be identified. As new risks are identified, they should be added to the Risk Register and managed as an on-going activity.

Risk Analysis

For the initial risk identification exercise, the analysis of risks would normally happen at the same workshop as the brainstorming session. Risks identified subsequently are analysed by the Project Management Team and/or Project Board.

The facilitator encourages the group to ask two questions of each risk:

“How likely is this risk to occur?” to give a probability rating

“What would be the impact if it did happen?”

to give an impact rating Probability and impact can both be scored on a High/Medium/Low scale. Alternatively, a score of 1 to 3 (or 1 to 5 if more sensitivity is required) can be assigned to each risk.

Risk Prioritisation

To prioritise risks, the ratings for probability are combined with those for impact to give an overall criticality rating. If a ‘High/Medium/Low’ rating is used, the following table should normally be used to derive the rating for criticality:

Criticality		Impact
Criticality		High	Medium	Low
Probability	High	High	Medium	Medium
	Medium	Medium	Medium	Low
	Low	Medium	Low	Low

If a numeric scoring system is used, the score for probability can be multiplied by the score for impact to give an overall score for criticality.

Whatever the system for calculating criticality, it should now be possible to identify the risks that the Project Manager must concentrate on.

Risk Management Planning

Having recognised the risks facing the project and prioritised them, the Project Manager and Project Board must decide what action to take in respect of each. It is rare that resources are available to completely address all risks, and the cost of addressing each may outweigh the possible adverse consequences. Effort therefore concentrates on the highest scored risks - often just those with ‘High’ Criticality (or an equivalent score).

The action appropriate will depend on the risk, but generally falls into the following categories:

Prevent it from happening. Put some sort of countermeasures in place that will prevent the risk ever happening. Or, if it does happen, put the project in a position where it would have no impact.
Reduce the risk. Plan some action to reduce the probability of the risk occurring, or to reduce its potential impact on the business. This type of containment action will often be included in the Project Schedule (see Project Planning and Estimating).
Transfer the risk to someone else. Take action at the planning stage to remove the risk from the project scope. This may be by negotiation with other departments to take some of the responsibilities from the project, by the negotiation of penalty clauses in supplier contracts, or by the purchase of suitable insurance.
Decide what to do if the risk becomes a reality. Plan some types of action to be taken if and only if the risk occurs. This might be included in a separate plan and is normally associated with a trigger event (an event which will cause the plan to be put into effect). The only direct cost of this type of action is that associated with the planning function - unless, of course, the trigger event occurs (in which case the cost is that of the contingency plan).
Accept the risk. The Project Board may simply decide to accept the risk as it stands, and to face the consequences on a ‘fix on fail’ basis if the risk should occur. This course of action is taken where the risk is unavoidable or the expense of avoiding it would far outweigh the costs of allowing the risk to happen.

The actions decided to avoid risks (preventative actions) and the actions that will need to be taken in the event that the risk happens (contingent actions) are added to the Risk Register for those risks considered important enough to require action. For each risk on the Risk Register, an individual is nominated to ‘own’ the risk (that is, to monitor the probability of it occurring and the planned action). The risk owner will usually be the Project Manager or a member of the Project Board.

Risk Resolution

Once the risks have been recognised and appropriate preventative/contingent actions planned, resources must be sought to put these actions in place. No risk is ‘cost-free’. The costs involved in associated actions should all be identified and added to the project Cost Benefit Analysis (or business case).

It is the responsibility of the Risk Owner to seek the resources required by the favoured risk action(s), and of the Board to decide whether such action(s) should be taken by the Project itself under the management of the Project Manager or by a separate project team. In the latter case, the cost of the action should still be incorporated into the Project’s Cost Benefit Analysis.

Action taken in respect of risks is controlled as for any other planned work, and may be managed on a daily basis by the Project Manager, a Team Manager or other individual nominated by the Risk Owner. The only constraint is that progress against this part of the plan should be separately reported to the Risk Owner. Once a risk has been resolved, in one way or another, the outcome should be added to the Risk Register. At the same time, the risk should have its status changed from Open to Closed and the Date Closed added to the Risk Register.

Risk Monitoring

During the delivery of the project, the risks identified in the Risk Register should be regularly monitored in order to:

ensure that the actions put in place within the plan to mitigate the risks remain appropriate and commensurate with the risk
evaluate whether the original scores assigned to the risks are still correct
check for the occurrence of any ‘trigger’ events, causing the project to invoke an existing contingency plan
consider the possibility of significant new risks arising
ensure that the project remains viable in the face of the changing risks

When a new risk is identified with a high criticality rating, action should be incorporated into the Project Schedule to address the risk appropriately.

The Risk Log will help to identify which risks need to be monitored. Like the identification of new risks, the regular monitoring of risks is a key activity of the Project Management Team.

Depending on project circumstances, the monitoring can be done by a group consisting of the Project Manager and Team Managers or it can be the Project Board together with the Project Manager. The group monitoring risks should:

ask the risk owner to provide an estimate of costs of actions
judge the effectiveness of the countermeasures in place and the continued need for them
re-evaluate each risk on a regular basis to ensure that action remains appropriate, and that the right risks are managed
appoint risk owners to manage any new risks as necessary

Since the regular review of all risks at every meeting can become unnecessarily onerous, it may be decided to review only High/Very High risks on a regular basis. This might be done using a system of ‘top ten’ risks where the risks with the ten highest scores are considered in detail.

A ‘Next Review Date’ can be added to the risk if it is not likely to happen for some time - this helps to avoid spending time evaluating risks that are not urgent.

Templates

Risk Process (Diagram)

Risk Register

Risk Log

Risk Planning Workshop

Risks to Consider

Hints & Tips

Deal with risks early - the earlier a risk is exposed the easier it is to manage and contain.

It should be second nature for every Project Manager to ask "What are the risks of taking or not taking this action?"

It is often better to have a shorter list of 'real' risks which are being actively managed rather than a long list which 'looks impresive'

Try to make it easy for anyone to raise a risk - take on the paperwork yourself if necessary - business people outside the immediate project team often identify the risks that will save you!

Try to encourage active participation in monitoring reviews - so often it is scheduled at the end of a meeting when everyone is ready to leave or just 'going through the motions' because the methodology says you have to have a risk register.

What is success?

Is each risk uniquely identified?

Are scores or ratings for Probability and Impact reasonable?

Does every risk have an owner who is actively managing it?

Is the overall Criticality rating/score consistent with the Probability and Impact?

Have preventative and/or contingent actions been defined for all high Criticality risks?

Is it clear why closed risks are no longer current? Has a date closed been provided?