Risk Management is an extremely important activity in Project management and it should be applied in all cases and types of projects and initiatives.
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.
Introduction to Project Risk and Risk Management
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 management 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 Risk
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.
RISK MANAGEMENT
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
IDENTIFYING RISKS
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
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.
Building the initial list of project risks
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’:
- Personnel shortfalls – for example, developers not being familiar with the technologies needed for the project.
- Unrealistic schedules and budgets – in some cases this could be because not all essential requirements have been identified.
- Developing the wrong functions and properties.
- Developing the wrong user interface.
- Gold-plating – this is development of software functionality that is not really needed and ends up not being used.
- A continuous stream of requirements changes.
- Shortfalls in externally furnished components.
- Shortfalls in externally performed tasks.
- Real-time performance shortfalls.
- 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 the Activity 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
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.
Comments are closed.