Identify risks up front

Successful risk management starts at the beginning of a project with the identification of risks: potential happenings that may throw a spanner in the works of your project. This and the following two chapters look at the and issue-management process. This chapter considers the risk-identification phase done at the beginning of a project. Chapter 20 continues the risk-management process by discussing risk response and management.

Chapter 21 explains the difference between risks and issues and how issues can also be managed effectively.

D R I V I N G S T R A I G H T I N

The lifecycle of the UK government’s Ministry of Defence projects includes an initial assessment phase before time, cost and performance targets are agreed and the project is formally approved. The purpose of the assessment phase is to identify and understand the critical risks and put in place plans to manage and mitigate against such risks. The Ministry of Defence’s recommendation, based on their past 40 years of experience, is that about 15 per cent of the initial procurement costs should be spent on this phase.

The Support Vehicle Project is a procurement initiative to replace the cur­

rent fleet of ageing cargo vehicles with new cargo and recovery vehicles and recovery trailers.³⁵ In March 2001, it was decided to bypass the assessment phase and approve the entire project straight off. The decision was taken because the team believed that the technology was established and there was already enough information about the project. However, skipping this phase meant that critical risks were not identified and the project was sig­

nificantly delayed. ‘Nineteen months of the delay to the Support Vehicle Project are directly attributable to the decision to bypass the assessment phase,’ says the Ministry of Defence’s Major Projects Report.³⁶ As a result, the project missed the opportunity to examine risks and plan mitigating actions early on. The tasks had to be done after the project had been given formal agreement to proceed.

Identification means taking the time to note down everything that might go wrong, including key resources moving off the project, changes to the legislative framework, system testing taking longer than planned, changes to internal priorities, any concerns about using new technology, and so on. The project manager alone cannot identify all the potential risks, and so involving the project team will help generate a comprehensive list.

Elkington and Smallman have studied the risk-management process from an academic perspective and arrived at this set of guidelines for risk identi­

fication:³⁷

Project Management in the Real World

• Identify the obvious risks first.

• Think of the who, why, what or when of the project, and identify risks relating to those.

• Consider risks that apply to the management of a project as opposed to the deliverable of your project, such as resources.

• Identify positive as well as negative risks, for example the impact of one task being completed much earlier than expected.³⁸

• Use your imagination to cover everything: removing risks from the list is much easier than managing risks you never identified.

• Involve others by working in small groups or holding informal inter­

views.

Once you have identified as many risks as possible, the next stage is to apply some sense of priority assessment to each item. You will have a very varied list of risks, some of which will seem small and pointless, but others very significant. There are two attributes that should be considered for each risk: likelihood and impact.

• Likelihood: the chance of the risk occurring. Unless it is a very sci­

entific event, you’ll have to take a best guess based on your gut feel about this.

• Impact: how serious the outcome of the risk would be if it materialized.

The impact could be to the project schedule, budget or the quality of deliverables. Again, you will probably find yourself being less than scientific when it comes to assessing this.

Each of the two attributes is given a value, and these values are multiplied together to calculate the overall risk assessment. ‘Research shows that the severity of the potential consequences of a risk produces a greater concern than its probability in evaluating the overall level of risk,’ write Baccarini, Salm and Love in Industrial Management and Data Systems. ‘For example, a low-probability/high-consequence risk is typically considered as being higher than a high-probability/low-consequence risk.’³⁹

Figure 19.1 shows a risk matrix and two examples of risk assessment in practice. The first example is the lack of resources for user testing. There’s a possibility that users would not be available to carry out testing when needed, as they all have operational priorities. This has been assessed as 4 on the risk likelihood scale. The impact on the project timescales would be moderate (assessed as 3).

The likelihood of facing an office flood is tiny. This has been assessed as 1 on the matrix. The impact on the project if the office was flooded out would be severe, and that has been rated as 5.

Combining the likelihood and impact scores gives each risk a relative priority. User availability for testing (4×3=12) is a more significant risk than flooding (1×5=5). Once each risk on your list has been assessed and given a score based on its priority, you will be in a position to consider how best to manage it, which is discussed in the next chapter.

Identify risks up front

Figure 19.1 Matrix for calculating risk priority

G O L D E N R U L E S

Identification should be done early in the project and involve the project team. Each risk should be assessed according to impact and likelihood.