When you have completed this chapter you should be able to demonstrate an understanding of the following:
• identification and prioritisation of risks;
• assessment of the probability and impact of risks, that is risk exposure;
• risk reduction activities versus contingency actions;
• typical risks associated with information systems;
• assessment of the value of risk reduction activities;
• maintenance of risk registers.
However carefully a project plan is assembled, it will be based on assumptions that could turn out to be wrong. There is always, to a greater or lesser extent, an element of risk, which has been defined in PRINCE2 as:
‘The chance of exposure to the adverse consequences of future events.’
Risks are always made up of cause and effect. An unwelcome outcome, such as the late delivery of the product of a project, could have a number of causes, such as an estimate being wrong, staff not being available or a requirement being changed.
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 and can be problematic even if the project objectives have been fully met. In this context ‘business’ describes the general field of activity of organisations regardless of whether they are in the public or private sector. One can, for example, talk of schools being in the business of teaching.
Project risks can relate to development, such as delayed delivery, which can strike during the execution of a project. Operational project risks emerge when the delivered system is put into action, that is made operational – an example of this is vulnerability to cyber-attacks – and are usually caused by incomplete requirement gathering or poor quality deliverables. There is an overlap between quality and risk management as it is likely that the product qualities described in Section 5.3 could be redefined as risks, that is the possibility of operational systems going wrong.
Business risks occur when the planned benefits of a correctly delivered project are not achieved because of external business factors. In the Water Holiday Company scenario, a slump in the demand for boating holidays could mean that the investment in the new integrated 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.
When a risk actually occurs, it becomes a project issue – that is, a problem that needs to be resolved. Risk management actions can reduce the probability of the project issue emerging or define actions to reduce the damage it causes.
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 provide 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. The cost when a risk actually occurs needs to be balanced against the costs of actions to reduce the likelihood of the risk occurring.
The management of risks is similar to the management of any activity. There is a control cycle for tracking risks – see Figure 7.1 – similar to the project control cycle described in Section 3.1. This risk management cycle is repeated throughout a project.
Figure 7.1 shows how major risks are identified and then plans 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 data 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.
Although risk is being treated as a separate topic in this chapter, risk planning is embedded as part of general project planning. As planning takes place, assumptions will have to be made; for example, that a particular resource will be available when needed. An assumption that could turn out to be incorrect becomes a risk. Risks can be eliminated at the planning stage by changing the way a project is implemented. For example, risks associated with developing software can be removed by buying in existing software functionality.
During the implementation of the plan, the monitoring of risks would be integrated in generic project control – see Chapter 3.
Generic risks that affect nearly all projects are probably best dealt with by adoption of relevant, recognised, good preventative practices.
Figure 7.1 Risk management cycle
The risk identification process begins with the gathering of potential problems or issues that are already known. These include particular views, trends or constraints within the project development environment. These recognised problems often indicate the causes of the risks that will eventually need to be managed.
ACTIVITY 7.1
Reread the Water Holiday Company integration project scenario in Chapter 1 and identify features of the project or its environment which you think could lead to difficulties.
There are a number of aids to building the initial list of risks. Specialist risk publications, application development guidelines and company standards provide prompts 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. Some of these checklists relate to projects in a particular industrial sector, like the well-known Barry Boehm ‘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. A 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.
Not all risks in a generic list will be relevant to a specific project. Some can be discounted at once. For example, shortfalls in externally performed tasks would not be relevant to a project which is completely in-house. Others may be dropped after the more detailed assessment described in Section 7.4.
As well as generic risks applying to almost any project, there are specific risks peculiar to the circumstances of the particular project – the areas of potential risks to the Water Holiday Company integration project identified in Activity 7.1 were specific to that project. Methods of gathering information about specific risks include:
• interviewing experts or stakeholders within the project;
• brainstorming workshops with stakeholders to identify risks – the discussion of a risk by one member may lead to others recognising further risks;
• searching past project documentation, particularly any ‘lessons learnt’ reports.
It is helpful, in identifying a risk, to recognise the true focus of the problem. As noted already, delays in activities can be caused by a variety of factors, so 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. The risk still 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.
Given the list of possible issues generated in Activity 7.1, identify five possible risks for the Water Holiday Company integration project.
We have to recognise that we may not be able to take action for all possible risks identified. Therefore, we need to prioritise the risks, but before this can happen we need to evaluate the risk itself.
The evaluation of the seriousness of a risk is based on two key criteria:
• the probability that the risk will occur;
• the impact that the risk will have, should it occur.
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.
We noted above that the impact, or severity of a risk, is the adverse effect that the risk will have on the project should it materialise. This impact might 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. The turning of a risk into a real issue needing action could affect the business case because of increased costs or reduced benefits.
A risk can be viewed as an opportunity. Let’s examine the example on the previous page, of developing application software in a language (say Java) with which developers are not familiar. The plan for the software development could increase the expected duration of the coding tasks to take account of the developers’ lack of experience. If, however, the developers were able to pick up Java very quickly, their tasks could be completed earlier than scheduled. In this case the project manager ought to exploit this opportunity and start the next tasks as soon as possible. The time gained here will be a useful buffer if other 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 of an aircraft crashing into a workplace – but in practice be dismissed because of the minute probability of it occurring.
The proximity relates to the period in the project when the risk could occur. A given risk is more likely to occur during one or more particular activities. After a certain project milestone it might no longer be applicable, or at least have a reduced impact. The risk of inexperienced Java programmers delaying completion of work will affect the software development stage. Once the software coding is over, 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.
Risk assessment can be quantitative – based on seemingly precise mathematical values – or qualitative – based on broader management intuition.
Quantitative risk assessment
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. 0 per cent or 0.00 means there is absolutely no chance of something happening, while 100 per cent or 1.00 means it is absolutely certain that it 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 monetary 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 for probability and potential impact of a particular risk can be used to calculate risk exposure.
Risk exposure = impact × probability
For example, if there were a 0.10 probability of IT equipment worth £20,000 being stolen, the risk exposure would be £20,000 × 0.10, 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.)
An advantage of the quantitative model is that 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 easy) 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) = (REbefore − REafter) / cost of risk reduction
REbefore is the risk exposure before the risk reduction action is taken – that is, £2,000.
REafter 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 the 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:
• Unless you have a very large set of data about past occurrences of the particular risk, identifying the probability of a risk may end up as guesswork.
• In our simplistic example, the cost of the theft was exactly £20,000. In practice the amount of damage can vary, and so this value could be guesswork. Where there is a large amount of data about past occurrences of the risk, it may be possible to produce a table showing the probability of different ranges of cost – but this kind of information is unlikely to be available to a project planner.
• Quantitative risk exposure values are based on the principle that when risks actually occur, the situation can be remedied by using resources put aside to meet possible losses. However, this assumption does not hold where the loss caused by a particularly large risk occurring is simply too large and would exhaust the fund. The bankruptcy of the client organisation might be an example of these show-stoppers.
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.
While quantitative risk assessment requires access to data about past projects, other approaches to obtaining qualitative assessments were noted in Section 7.3, 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 Section 6.3.2) 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.
Table 7.1 Mapping qualitative and quantitative assessments of risk probability
| Index | Impact level | |
| 4 | High | Greater than 50% chance that the risk will occur |
| 3 | Significant | 30–50% chance that the risk will occur |
| 2 | Moderate | 10–29% chance that the risk will occur |
| 1 | Low | Less than 10% chance that the risk will occur |
Table 7.2 Mapping qualitative and quantitative assessments of cost impact
| Index | Impact level | |
| 4 | High | Greater than 20% above project cost tolerance |
| 3 | Significant | Up to 20% above the project cost tolerance |
| 2 | Moderate | Greater than 50% of the project cost tolerance but still within it |
| 1 | Low | Within 50% of cost tolerance |
Table 7.3 Mapping qualitative and quantitative assessments of scope impact
| Index | Impact level | |
| 4 | High | Inability to meet mandatory project functionality |
| 3 | Significant | Shortfalls in key functionality |
| 2 | Moderate | Shortfalls in secondary functionality |
| 1 | Low | Some minor functions missing |
Table 7.4 Mapping qualitative and quantitative assessments of time impact
| Index | Impact level | |
| 4 | High | Greater than 20% above project time tolerance |
| 3 | Significant | Up to 20% above the project time tolerance |
| 2 | Moderate | Greater than 50% of the project time tolerance but still within it |
| 1 | Low | Within 50% of project time tolerance |
Once the evaluations of 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.
Figure 7.2 Probability impact grid
Uncertainty about a project due to the risks identified can be reduced by taking risk management actions. These actions aim to reduce, transfer or eliminate a risk. They are additional tasks that could affect the schedule, costs, functional scope and quality of the deliverables. An alternative is to take no action to reduce the possible occurrence of the risk; instead a contingency plan could be put in place consisting of actions to reduce the damage caused once the risk had actually materialised.
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 a risk management action, but it is mentioned here as a possible option. 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 in Section 7.5 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.
This is sometimes called ‘risk prevention’. The organisation could prevent the risk from occurring by removing or replacing the activity in which the risk is embedded. In the example where the programmers’ inexperience of the chosen language is a risk, the risk might be prevented by deciding to use an existing vendor-supplied application.
The organisation could still take the planned action, but reduce the probability of the risk occurring. Again, any reduction action will take place before the expected risk occurs. In the software development example above, 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.
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 overruns would be transferred to them.
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 that 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.
Explain the risk management actions that could be taken to reduce the risks to the Water Holiday Company integration project scenario that were noted as a result of Activity 7.2.
When selecting the risk management actions to be taken, it may well be that some actions are appropriate not just for one particular risk, but for several. For example, there is a risk that a delivered software function might not perform at the outset to the satisfaction of users, so that time is wasted in re-work. Two risk management actions are identified: to have a walkthrough of the interface design with users to ensure their requirements are met; and to have a peer review of the code to reduce faults in it. It happens that the peer review of code also identifies changes that reduce the risks of the code being difficult to maintain in the future.
The action chosen will have an impact on plans. In the above example, two new review activities need to be inserted into the project schedule. It is important to ensure that the benefits of these actions outweigh the benefits of inaction. Two extra reviews might take up two days, say, so the reduction in testing and correction would need to be more than this for it to be worthwhile.
Key decisions in risk management are how many risk management actions to approve and in relation to which risks. 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 an acceptable level. As we saw in Section 7.5 with the discussion of risk reduction leverage, these actions would incur costs.
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.
The risk identification, risk assessment and the selection of risk management actions occur primarily during project planning, but the processes described above will also continue throughout the life of the project as new risks are identified. 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 relating to the reliability of the external suppliers.
The monitoring of risks should be part of the project control cycle (see Chapter 3). The monitoring process is usually a mixture of periodic reviews – say once a month – and reviews after milestones, such as 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), and the individual risk records (see Figure 7.4). Typical headings are shown in the figures, but others could be added – for example, a risk category or the earliest date that the risk could occur. Initially, only the risk description and owner need be recorded. The post-risk management values and plan number 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 risk management 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 chosen actions 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 management action plans.
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.
Most of the risks that you will experience will already have happened on a previous project. A key aspect of risk management is learning from past projects. This is the main reason for the writing of a lessons learnt report at the end of a project, as mentioned back in Section 1.4.10.
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 that reduces the potential damage if a certain risk does materialise
c. An agreement that the users accept a particular risk
d. An activity that 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 reduce a risk?
a. accept it
b. prevent it
c. reduce it
d. transfer it
Among the facts that could lead to difficulties in the Water Holiday Company integration project are:
• Two sets of employees, some of which are at a high managerial level, are to be merged. There could be conflicts between the two.
• Two different holiday booking systems are to be merged. There will almost certainly be different detailed requirements relating to the different types of boating holidays.
• More specifically, there could be incompatibilities between database structures of the systems to be merged.
• Some staff will need to be made redundant in order to gain the cost benefits of the merger. Some staff may leave of their own accord if they do not approve of changes. They may take their skills and expertise to competitors. In any case, specialist skills and knowledge could be lost.
• IT aspects of integration depend on physical prerequisites such as the completion of the new merged service centre.
• Technical issues when the integrated system is launched may lead to the system going off-line or having reduced availability. This could lose potential business.
• There is a danger of the previous customers of Canal Dreams and Minotours not being aware of the new Water Holiday Company identity.
• Possible changes in international trading relationships could affect cross-border businesses such as Minotours.
Note that these are issues of concern at the point where the first plans are being made. They might feature as ‘risks’ in the business case document. Some of the concerns will be eliminated at the planning stage through the choice of project activities that address them.
The following risks might be identified. Other risks can certainly be added.
| Issue | Possible risk |
| There could be conflicts between the two sets of staff from Canal Dreams and Minotours | 1. Differences in views on new system functionality lead to delays in reaching agreement |
| Two different holiday booking systems are to be merged | 2. Failure to identify requirements of both sets of system users leads to an incomplete set of functions |
| There could also be incompatibilities between database structures of the systems to be merged | 3. Failure to take account of data needs of both sets of system users leads to shortcomings in merged organisational database |
| Specialist skills and knowledge could be lost | 4. Lack of access to knowledgeable system users leads to incorrect/incomplete assumptions about requirements |
5. Knowledgeable system users not available for acceptance testing, and other tasks associated with transfer to operational use |
|
| IT aspects of integration depend on physical prerequisites such as the completion of the new merged service centre | 6. Delayed access to new premises means installation of new IT infrastructure delayed |
| Technical issues when the integrated system is initiated may lead to systems going off-line or having reduced availability | 7. Technical issues when the integrated system is initiated 8. Lack of availability of new system impacts bookings |
| Previous customers of Canal Dreams and Minotours not being aware of new Water Holiday Company identity | 9. Lack of links from the old businesses’ websites to the new website leads to lost customers |
| Possible changes in international trading relationships | 10. In most cases above, there are things we don’t know, but we can find out. In this case, we can speculate but not find out for sure. Risk avoidance is probably the right approach (see 7.7.2) |
Note that the actions below are just suggestions. You may be able to find other, perhaps more effective, risk management actions.