Risk Analysis 101

Welcome
Data Science

SWOT and PESTLE analysis can highlight several risks on a project (risk analysis), but this also applies to business strategy and technology monitoring (for the company's positioning).

Risk analysis

Risks are problems that could arise as a result of a decision (to be defined through a SWOT and PESTLE analysis). It is important to identify them before launching the project so you know what you are facing. Once you know this, you can analyze the likelihood of these risks occurring and implement measures to mitigate them. And if it's too late, the risk analysis can prevent the problem from recurring.

The severity of a risk is defined according to two categories:’ effect that the risk could have on the project and the probability that it comes to pass. Then, there is a third optional category: the precision (we'll come back to what this means a little later).

There are two types of risk analysis: qualitative and quantitative. In project management, both are used at the planning stage, but qualitative analysis comes later. After quantitative analysis if you do both.

  • Qualitative risk analysis is subjective . The goal is to determine the severity of the risk by predicting its probability and impact. You will typically perform these analyses on all identified risks within a project, as well as across all project types. Risks are generally presented in a risk assessment matrix, which is then used to explain the risks to stakeholders. stakeholders concerned. This method Risk assessment is the most effective, but it is generally difficult to finance or budget, due to the lack of numerical estimates.
  • A quantitative risk analysis is objective. It relies on data, which is used to analyze budget risks, schedule overruns, scope drift, and resource overruns. A quantitative risk analysis focuses on numbers and is therefore limited by the available data. While it is always preferable to conduct a comprehensive quantitative risk analysis (more on this later), it is not always possible or practical to deploy such extensive resources for a small task.

In the first case, it is human judgment that quantifies the risks. In quantitative analysis, KPIs allow for the mathematical calculation of risk.

Risk classification

The risks must be identified and classified according to three use cases:

  1. Group them according to their causes.
    It's easier to categorize risks if you look at their common causes. You can manage a smaller number of more manageable clusters instead of managing many separate items.
  2. Examine their urgency
    As part of a qualitative risk analysis, you will examine the threat level of each risk. Project managers can then go further and combine the risk classification number with a risk urgency assessment to find the "risk sensitivity score." This can help managers better prioritize their risks.
  3. Add precision
    If a project has many risks, it can be difficult to decide which one to tackle first. A risk ranking system based on the position of each risk in a risk matrix can help managers establish priorities.

Data powers all risk assessments, but some data sets are more reliable than others. There precision defines the confidence given to the estimates. This doesn't tell project managers anything about the severity of the risk, but it does tell them to what extent one can trust a judgment.

Budgetary qualification of risks

Cost estimates for all projects must include a contingency allowance that reflects the risks associated with the project options. As previously mentioned, the project team can use two methods to determine the contingency allowance, depending on the project level: the stochastic (probabilistic) method or the deterministic method.

When the project team has used a stochastic approach, it must verify the appropriateness of the contingency provision through a top-down evaluation. This involves examining the figure against industry benchmarks, previous projects, and/or reviews of literature – similar to a deterministic approach to estimating a contingency provision.

This sensory verification helps the project team identify and overcome optimism and pessimism biases and increases confidence that the risk register and contingency allowance are appropriate. The project team must provide evidence in the business case supporting the justification for the contingency allowance estimate.

Here is a table showing budget overruns (2008 study by the University of Melbourne).

For level 1 and 2 projects, the recommended P-value is P90 (see the box below). Using P90 strikes an appropriate balance between minimizing the risk that the project will require additional budget funding and avoiding the unnecessary tying up of scarce budgetary resources.