7 RISK

LEARNING OUTCOMES

When you have completed this chapter you should be able to demonstrate an understanding of the following:

7.1 INTRODUCTION

There are a number of definitions of risk, some embracing opportunities as well as threats. Arguably, the most used is the definition provided in PRINCE2, the project management standard sponsored by the UK government:

‘The chance of exposure to the adverse consequences of future events.’

Those adverse effects could be a reduction in the value delivered in the project, or even the failure of the project. They include higher development costs, delayed project completion, reduced scope and reduced performance. The adverse effect could also be a less effective completed system that fails to deliver the appropriate capability, which in turn means that the original business case is not fully realised.

In Chapter 1 we distinguished between project objectives and business objectives. Similarly, some risks are project-related – that is, they threaten the successful achievement of the project’s objectives – and others are business risks. The project team may meet the project objectives and deliver the required IT application on time and within budget. Business conditions, however, may mean the client organisation cannot exploit the application to achieve their business objectives. In the Canal Dreams ebooking enhancement scenario, a slump in the demand for canal holidays could mean that the investment in the new booking system does not pay for itself. On the other hand, risks involve opportunities as well as threats. Unexpected events might be to our advantage if we can modify our plans quickly to take account of them.

The risks come from within the project, or they could be caused by external events. If an adverse event has already occurred, this is not a risk but should be treated as a project issue – that is, a problem that needs to be resolved.

External (or environmental) risks include:

Internal risks include:

The objectives of risk management are to identify, address and minimise risks before they become threats to the successful completion of a project. However, we need to be aware of the ‘law of diminishing returns’, which suggests that the initial effort and expenditure provides the best return and that the benefits from further spending to solve a problem gradually become smaller. Buying one smoke detector for your house when you have none could make a big difference to your safety, but buying another when you already have five will probably make little difference. Actions to eliminate some risks may be prohibitively costly, difficult or lengthy and, if adopted, would adversely affect the business case.

7.2 RISK MANAGEMENT

The management of risks is similar to the management of any activity. There is a planning and control cycle similar to the one described in Chapter 3. Risk management is a continuous process throughout the life of the project. However, before managers form any plans, they need to identify the risks and make some decisions about them. A typical risk management framework is shown in Figure 7.1. Major risks have to be identified and then plans have to be made to deal with them. These plans include activities that enable other activities to be undertaken in the event of a risk turning into a real problem. For example, taking back-ups of important computer files allows them to be restored if the originals are damaged. The project is then executed and is monitored and controlled to see where risks have materialised and where appropriate actions need to be initiated.

7.3 IDENTIFYING RISKS

Before the risk identification process begins, there will be a number of facts or issues that are already known. These include particular views, trends or constraints within the project development environment. It is worth examining these facts as they often provide the causes of the risks that will eventually need to be managed.

There are a number of aids to building the initial list of risks. Many risk textbooks, application development documents and company standards provide prompt or checklists containing a number of generic business and project risks that originate from outside and inside the project. These can be used to determine which risks in the list apply to the project. One well-known list of risks is Barry Boehm’s ‘Top Ten Software Project Risks’:

(1) Personnel shortfalls – for example, developers not being familiar with the technologies needed for the project;

(2) Unrealistic schedules and budgets – in some cases this could be because not all essential requirements have been identified;

(3) Developing the wrong functions and properties;

(4) Developing the wrong user interface;

(5) Gold-plating – this is development of software functionality that is not really needed and ends up not being used;

(6) Continuous stream of requirements changes;

(7) Shortfalls in externally furnished components;

(8) Shortfalls in externally performed tasks;

(9) Real-time performance shortfalls;

(10) Straining computer-science capabilities – current technologies and expertise are not sufficiently well developed to satisfy the requirements and the project becomes effectively a research rather than a development project.

As well as generic risks applying to almost any project, there are specific risks peculiar to the circumstances of the particular project – most of the risks to the Canal Dreams ebooking enhancement project identified in Activity 7.1 were specific to that project. Methods of gathering information about specific risks include:

It is important however, in view of the law of diminishing returns, not to assume that all generic risks will be relevant. Dismiss risks not really belonging to the project. For example, an aircraft crashing into the software development laboratory is a risk, but not one usually considered unless the laboratory is under a busy flight takeoff path.

It is helpful, in identifying a risk, to recognise the true focus of the problem. For example, you should not say:

‘Development of the application software may overrun.’

Instead, you should say:

‘There is a risk that the application programmers are too inexperienced in the chosen language and therefore the application software may be completed late.’

Note that this risk statement is only appropriate when it is set in the context of the given project. In this example, it is a fact that the programmers are inexperienced in the chosen language. This fact, or issue, is not a risk but a cause of a potential risk. A risk has an element of uncertainty about it. The fact that there is limited experience of the chosen programming language only becomes a risk in our project if the difficulty of the design and coding of the application software makes demands that are too great for the inexperienced programmers.

7.4 ASSESSING THE RISK

7.4.1 Risk evaluation criteria

We recognised that we may not be able to take action for all possible risks identified. Therefore there is a need to prioritise the risks, but before this can happen there is a need to evaluate the risk itself. The evaluation is based on two key criteria:

Together, risk and impact give an idea of the magnitude of the risk – the risk exposure. A third factor is the proximity of the risk, which takes account of the fact that the magnitude of the risk may vary throughout the project – for example, once coding has been successfully completed some risks relating to coding disappear.

7.4.2 Risk exposure

We noted above that the impact, or severity, is the adverse effect that the risk will have on the project should it materialise. This impact may be a longer development time, a reduction in the scope of the deliverable, a reduction in the performance of the deliverable, or an increase in the resources needed. The scope and the performance are often combined as a reduction in quality. The increased resources, both of materials and labour, are usually referred to as increased costs. Should a risk occur, it may impact time, cost or quality, and of course any impact will affect the business case.

A risk can be viewed as an opportunity. Let us examine the example above, of developing application software in a chosen language (say Java) with which developers are not familiar. The plan for the software development tasks may increase the expected duration of the tasks to take account of the developers’ lack of experience. If, however, the developers were able to pick up Java very quickly their tasks may be completed earlier than scheduled. In this case the project manager ought to exploit this opportunity and start the next task as soon as possible. The time gained here will be a useful buffer if problems occur later in the project.

Impact is not the only issue that affects the seriousness of a risk (or risk exposure). A risk could cause immense damage if it occurs – as in the example above of the aircraft crashing into a workplace – but in practice be dismissed because of the minute probability of it occurring.

7.4.3 Risk proximity

The proximity relates to the time period in the project when the risk may occur. Risk evaluation may identify that a given risk is more likely to occur during a particular activity, or that after a certain project milestone it will no longer be applicable, or that the impact could change depending on when the risk occurs. The risk of inexperienced Java programmers delaying completion of work will have an impact on the software development stage. Once the milestone marking the end of software coding has been successfully passed, this will no longer be a risk. In Chapter 1, it was noted that uncertainty about a project was greatest at the beginning because of all the unknowns associated with a new project. As knowledge is gained about the application and technical domains during the project, much of this uncertainty is reduced.

7.5 QUANTITATIVE APPROACHES TO RISK

Risk assessment can be quantitative – based on seemingly precise mathematical values – or qualitative – based on broader management intuition.

When a quantitative approach is used, probability is represented as either a percentage between 0 per cent and 100 per cent or a value in the range of 0.00 to 1.00. Zero per cent or 0.0 means there is absolutely no chance of something happening, while 100 per cent or 1.00 means it is absolutely certain that something will happen. A probability of 0.40 means there is a 4 out of 10 chance of something happening.

Impact is most conveniently measured as a money value reflecting the financial loss of the risk should it actually occur, but is sometimes measured in time (that is, the amount of delay caused).

The values of probability and impact can be multiplied to create a risk exposure. For example, if there were a 0.10 probability of IT equipment worth £20,000 being stolen, that the risk exposure would be 0.10 × £20,000 – that is, £2,000. (Note that all the numbers here are picked for ease of the arithmetic, not because they are realistic.) Crudely, this risk exposure value can be compared to the amount that might be paid as an insurance premium. If there were 100 organisations with IT equipment of the same value and the same chance of theft and they all contributed £2,000 to a pool, the pool would be big enough for 10 per cent of them to withdraw £20,000 if they were robbed. (This is a simplified model: in real life the 10 per cent would have to be based on an average over several years. It is unlikely that it would be exactly 10 per cent in any one year.)

Risk exposure = impact × probability

An advantage of the quantitative model is it is easy to assess the effectiveness of a risk reduction action. Say that in the above example an organisation decided to buy a burglar alarm for £1,500 (Once again, this figure has been picked simply to make the calculation easier) and it is estimated that it would reduce the probability of a successful theft to 1 per cent (or 0.01).

A risk reduction leverage can be calculated as follows:

Risk reduction leverage (RRL) = (RE_before − RE_after) / cost of risk reduction

RE_before is the risk exposure before the risk reduction action is taken – that is, £2,000. RE_after is the risk exposure after the action (the installation of the burglar alarm) – that is, £20,000 × 0.01, or £200.

The calculation of RRL is therefore (£2,000−£200) / £1,500) = 1.2.

Because an RRL is greater than 1.0, it means that the reduction action is worthwhile. (This could be compared to the cost of the burglar alarm being offset by a reduction in insurance premiums.)

There are a few problems with the practical application of quantitative risk assessment, including the following:

7.6 THE QUALITATIVE APPROACH TO PROJECT RISK ASSESSMENT

Because of these problems, modern practice in project risk management tends to adopt a more qualitative approach, and it is on this that we will focus in the remainder of this chapter.

7.6.1 Risk probability

While quantitative risk assessment requires access to data about past projects, there is a wider range of approaches to obtaining qualitative assessments including interviewing experts or stakeholders and brainstorming in a workshop. Various qualitative descriptions of probability can be used to describe the probability of a risk occurring, such as ‘extremely likely’, ‘very high’, ‘high’, ‘medium’,’ low’, ‘very low’ or ‘improbable’. Similar descriptions are used in the qualitative assessment of the impact the risk will have on cost, quality or time.

Quantitative values can still be assessed but these will be expressed as being within a range – for example, a 20–50 per cent probability of occurrence – and then be mapped to one of the categories of the probability and the impact (see Tables 7.1 to 7.4).

The Delphi method (see Chapter 6) is a more formal version of the expert approach to risk assessment. Risk assessment is very closely associated with effort estimation and in some cases can be carried out at the same time.

7.6.2 Prioritising risks

Once the evaluations or risk probability and impact have taken place, the risks can be prioritised to ensure that the risk management effort is placed where it is needed most. We have already seen that where a quantitative approach has been taken, a risk exposure value can be calculated. The bigger this value is, the more serious it is. However, this calculation cannot be done if we have made qualitative assessments. To aid decision making for qualitative assessment, a probability impact grid, sometimes known as a summary risk profile, can be used (see Figure 7.2). In the grid the numbers uniquely identify each risk. Some organisations will have three probability impact grids to cover the impacts on time, cost and quality respectively. Other organisations combine them. Organisations refine their understanding of the risk profiles over time and become able to judge more accurately the threat of a risk and the action to be taken to deal with it.

7.7 DECIDING THE APPROPRIATE ACTIONS

Uncertainty about a project due to the risks identified can be reduced by taking mitigating action. Mitigation is defined as an action to reduce, transfer or eliminate a risk. Any mitigating action chosen will consequently mean revisiting the project schedule, the development costs, the functional scope and the performance of the deliverables and updating them, if necessary, to take account of the chosen action. In addition to the option of adopting one or more mitigating actions for a given risk, the project team could decide to take no action at all or to develop a contingency plan.

7.7.1 Accepting the risk

The organisation could accept the risk and take no further action other than to monitor it. It could be argued that taking no action is not, strictly speaking, a form of mitigation, but it is mentioned here for the sake of completeness. This option could be chosen if the risk probability is low, the impact is acceptable, or it is thought that none of the other actions listed below would be appropriate. The actions might be rejected because the cost of action outweighs the impact cost – the risk reduction leverage measures this – or because it is not practical in the particular context. In the case of the programmers’ Java inexperience, the cost of action was judged to exceed the cost of the impact of the risk.

7.7.2 Preventing the risk

This is sometimes called ′risk avoidance′. The organisation could prevent the risk from occurring by changing the activity in which the risk is embedded. In the example above, where the programmers’ inexperience of the chosen language is a risk, the risk might be prevented by deciding to develop the application software in the language with which they are familiar.

7.7.3 Reducing the risk

The organisation could still take the planned action but reduce the probability of the risk occurring or the impact of the risk. Again any reduction action will take place before the expected risk occurs. In the above example, if it was decided to reduce the possible impact on the project deadline, steps could be taken to try to ensure that the development was not late despite the inexperience of the programmers. For example, one or more specialists experienced in the chosen language could be recruited to join the development team to act as advisers to reduce technical misunderstandings of the features of the ‘new’ programming language.

7.7.4 Transferring the risk

The organisation may take action to transfer the risk to another party. For example, an organisation with inexperienced programmers could contract the work out to a software house. If the software house was working to a fixed-price contract then the problem of possible cost over-runs would be transferred to them.

7.7.5 Contingency

The organisation may decide not to take any action before the risk occurs, but instead to plan an action to be taken once the risk occurs, or if it becomes more certain that the risk will occur. For example, it is very difficult to think of many practical ways of eliminating the possibility of key staff becoming ill at a critical point in the project. Contingency planning might identify staff who could cover the role of a staff member made unavailable in such circumstances. This action differs from other actions as generally it only incurs costs if the risk materialises. As with all actions, there will be costs associated with managing the risk (see Section 7.5). There may also be costs associated with creating the conditions which would allow the contingency action to take place, as is the case when back-ups of files have to be taken to allow the contingency action of restoring files if they are corrupted.

When selecting the mitigating actions to be taken, it may well be that more than one action is appropriate for a particular risk, or that a chosen action can mitigate more than one risk. For example, in the case of the Canal Dreams ebooking enhancement project, retraining some of the current telesales team to work in the new network support centre might not only reduce demotivation but also reduce the risk of not finding suitable staff to operate the new network support centre.

Because the action chosen will have an impact on the original project plans, it is important to ensure that the benefits of the action outweigh the benefits of inaction – the calculation of risk reduction leverage could contribute to this. How many actions to approve, and in relation to which risks, are key decisions in risk management. Initial focus is likely to be on the show-stoppers – risks that would prevent completion of the project.

Where a quantitative approach has been adopted, the risk exposure figures for individual risks could be summed to get an overall project risk exposure. If necessary, a number of actions could be planned to reduce the risk exposure of the project to a level acceptable. Alternatively actions could be taken to address just the highest priority risks.

With the qualitative approach, a risk tolerance line has been shown on the probability impact grid in Figure 7.2. The organisation will not approve a project with risks that occur above this line. Therefore action would be taken to ensure a new position on the grid for these risks by reducing their probability or impact, or both.

7.8 PLANNING, MONITORING AND CONTROL

In the paragraphs above, it has been assumed that the risk identification, risk assessment and mitigating actions have occurred in the earlier stages of a project, during the project planning. However, all of the processes described above will continue throughout the life of the project, as new risks may be identified at any time, and there may also be secondary risks that result from actions to reduce initial risks. For example, outsourcing software development to a software house because of the inexperience of in-house developers will itself generate new risks. The monitoring of risks should be part of the project control cycle (see Chapter 3). The monitoring process is most likely to be a mixture of regular timed reviews and reviews held after significant events, particularly the end of a project stage. It is important to have a structured project risk plan to document the planning and to facilitate the monitoring and control process. This will consist of a risk register, also known as a risk log, which lists all the risks identified with the project (see Figure 7.3).

Typical headings are shown in the form, but others could be added – for example, a risk category or the earliest date that the risk could occur. Initially, not all entries would be completed. As risk assessment is an iterative process, entries such as the post-risk management values are entered after the appropriate actions have been approved and the risk plans formulated.

For each risk in the risk register, an individual risk record will be created (see Figure 7.4). Note that Figure 7.4 shows the probability and impacts both before and after any agreed mitigating action is taken – see the lines for ‘pre-risk management’ and ‘post-risk management’. In addition to the risk register and risk records, plans of the actions chosen need to be documented. As noted earlier, there is not necessarily a one-to-one relationship between a risk and a risk plan. An individual risk may necessitate a number of plans before the risk exposure is reduced to an acceptable level, or there may be one plan that addresses a number of identified risks.

Figures 7.3 and 7.4 refer to a risk owner. The risk owner is responsible for ensuring adequate management of the risk, including how and at what intervals a risk will be monitored. If the nature of a risk changes during this process, it may be necessary to revise earlier risk mitigation plans.

7.9 SUMMARY

Managing risk is a continuous process. It involves identifying the risks and analysing them to establish their probability, impact, proximity, exposure and priority. Remedial actions need to be determined and plans produced to implement these actions, followed by scheduled monitoring and appropriate control. The whole risk management process needs to be made visible by adopting sound communication mechanisms.

‘Murphy’s law’ states that ‘anything that can go wrong, will go wrong’. Undoubtedly risks will occur in your project. Most of the risks that you will experience have already been identified in previous projects. Learn the lessons from those. To ensure that those risks have the least impact, you need to adopt structured risk management within your overall project planning.

SAMPLE QUESTIONS

1. Which of the following best defines a contingency action?

(a) An activity that is planned to take place if a risk materialises

(b) An action taken at the start of a project which reduces the potential damage if a certain risk does materialise

(c) An agreement that the users accept a particular risk

(d) An activity which prevents a risk from materialising

2. What is maintenance of a risk log designed to do?

(a) eliminate risk

(b) save money

(c) control risk

(d) prevent system development failure

3. Which of the lists below best identifies what is examined when a risk is assessed?

(a) Probability, proximity, owner

(b) Impact, probability, team experience

(c) Cost, benefit, business case

(d) Probability, proximity, impact

4. Which of the following is NOT an action that would mitigate a risk?

(a) accept it

(b) prevent it

(c) reduce it

(d) transfer it

ANSWERS TO SAMPLE QUESTIONS

1. (a) 2. (c) 3. (d) 4. (a)

POINTERS FOR ACTIVITIES