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.

Risk probability

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 For more information about quality management, read the Quality control and quality assurance in Project Management and Agile practices.

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 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. Read Assessing the Risk in Project management and Quantitative approaches to risk.

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

Prioritising risks

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. Read more about Risk Management in Project Management practices.

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 gridRisk tolerance in Risk management


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.

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 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.

Avoiding 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.

Reducing the risk

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.

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 overruns would be transferred to them.

Leave a Reply

Your email address will not be published. Required fields are marked *