Qualitative Risk Assessment in Project Management & Agile

Qualitative Risk Assessment is a technique of risk management processes in agile and traditional projects. Although it is labeled ‘qualitative’, it involves an estimate and a quantification of both probability and impact at occurrence. When you are assessing risks, preparing communications to the team and stakeholders or prioritizing your risk response strategies, you will find this technique useful.

This article is an introduction to qualitative risk assessment in agile projects which however is similar to predictive (or waterfall) projects.

What Is Qualitative Risk Assessment?

Qualitative risk assessment is a technique to determine the relevance of risks as a threat for some or all project goals. In this context, the probability of the materialization of a risk and the impact if it occurs are taken into account.

This assessment is based on a risk inventory which is produced during the risk identification processes. It can be managed in the form of a risk register, a risk matrix or – in an early stage – as a simple list of identified threats to the project goal.

The result of the qualitative risk assessment is a prioritization of all identified risks. This can be presented as a prioritized list, in a color coded table or as a 4-quadrant diagram. This output is used for various purposes which include inter alia:

  • determining the intensity and frequency of monitoring a particular risk,
  • developing suitable risk response strategies (read more in the risk management introduction),
  • prioritizing the requirements backlog in an agile project – in Scrum, for instance, the ranking of product and sprint backlog items usually takes the risk of items into account (creating a so-called risk adjusted backlog),
  • communicating risks to stakeholders and team members,
  • identifying areas that require particular attention during quality assurance processes (mainly in predictive types of projects).

How Do You Perform a Qualitative Risk Assessment?

If you need to perform qualitative risk analysis follow the following steps. For the qualitative risk analysis, you will need a list of identified risks, e.g. the risk register, and some data or expert judgement. The estimation involves two relevant parameters:

  • probability and
  • impact.

Follow these steps to come up with a qualitative assessment and eventually a prioritization of the risks in your project:

1) Collect the Relevant Data and Collect Expert Judgement

Gather data from interviews and meetings with team members, stakeholders and subject matter experts to get a broad input with respect to the value of the risk your project is facing. The experts will provide you with their estimates and expectations for the relevant risks.

Also, use statistics and analytics from previous projects, industry benchmarks or publicly available sources. This data will help you and the team members involved in the process to produce an estimation that is based on actual observations and historic experience.

When you use data – whether it is related to expert judgement or statistical data – make sure you have challenged the data quality, the accuracy and the applicability for your current project.

2) Assess the Probability and Impact of the Risks

Populate the parameters probability and impact for each and every risk in your risk register. The granularity of this exercise depends on the quality of your data. Project managers and agile teams often use buckets (e.g. 0-10%, 10-20% and >20% probability) to assign risks to a parameter value range. The better your data, the more detailed you can assess the risks. The advantage of using value ranges is the comparability of risk assessments across different projects.

If you need a rough risk assessment only – be it because of a lack of data available or data quality issues – you can also perform a qualitative estimation. This can also be a method of choice for small and less complex projects where the overall risk is deemed low. Thereby, assign the identified risks to the buckets

  • low,
  • medium, and
  • high

for both probability and impact. While this approach is comparatively straightforward and simple, it might affect the comparability of different estimates and across projects. This is because the definition of low, medium and high might be individual and therefore inconsistent among the team members involved.

3) Assess Other Relevant Parameters

Your project might want to consider other parameters in addition to probability and impact. This may include, for instance, the urgency and proximity (source: PMBOK 6th edition, ch. 11.3.2.3, p.424). Urgency refers to the amount of time left to implement risk responses while proximity refers to the point in time the risk might be occurring.

Further considerations may also include strategic aspects, interdependencies or the manageability of risks as well as other individually applicable criteria.

4) Categorize the Risks

Risks may be classified by their source, area of impact or thematic relations. In predictive projects, project managers may create risk breakdown structures (RBS) or reference to the work break down structure (WBS) for the first two aspects. In agile risk management, teams may use suitable alternatives for their project, e.g. linking risks to backlog items.

In any case, these types of structure and linkage will help you and your team manage and monitor the risks throughout the lifecycle of an iteration, release and project.

5) Prioritization and Presentation of Assessed Risks

The last step is the prioritization and visualization of the risks subsequent to their assessment. If probability and impact have been estimated in buckets or with actual numbers, their value can be calculated as

Value of a Risk = Probability [%] x Impact.

If you have chosen a low/medium/high classification, you can either prioritize the risks based on the combination of probability and impact (e.g. high+high, high+medium, medium+medium, medium+low, low+low) or replace them with numbers that allow you to calculate a number for ranking purposes.

Once you have sorted this list by the value of risks in descending order, the result of this step is a ranking of risks by relevance for your project.

You can then create a graphical diagram, e.g. with 4 quadrants, to determine which risks are the most relevant for your project. Alternatively, you can set a threshold figure or a classification (e.g. high+medium) as the threshold for more intense monitoring or active management of risks throughout your project.

Leave a Comment

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