SWOT and PESTLE analysis make it possible to highlight several risks on a project (risk analysis), but this also applies to business strategy and technological monitoring (for the positioning of the company).
Risks are problems that could arise as a result of a decision (to be defined via a SWOT and PESTLE analysis). It is important to identify them before launching the project so that you know what you are facing. Once you know this, you can analyze the likelihood of these risks occurring and put measures in place to stop them in their tracks. And if it's too late, risk analysis can prevent the problem from happening again.
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 true. 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. When it comes to project management, both are at the planning stage, but qualitative analysis comes After quantitative analysis if you do both.
- Qualitative risk analysis is subjective . The goal is to determine risk severity by predicting the likelihood and impact of a risk. You will typically run these on all identified risks within a project, as well as across all project types. Risks are typically presented in a risk assessment matrix, which is then used to explain the risks to stakeholders concerned. This method risk assessment is the most effective, but is generally difficult to finance or budget for, due to the lack of numerical estimates.
- A quantitative risk analysis is objective. It relies on data, which is used to analyze budget risks, deadline overruns, scope creep and resource overruns. A quantitative risk analysis deals with numbers and is therefore limited by the available data. While it's always best to conduct a full quantitative risk analysis (more on this a little later), it's not always possible or practical to deploy the big guns for a small task.
In the first case, it is up to human judgment to quantify the risks. In quantitative analysis, KPIs mathematically allow risk to be calculated.
Risk classification
Risks must be identified and classified according to three use cases:
- 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. - 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 ranking number with a risk urgency rating to find the “risk sensitivity rating.” This can help managers better prioritize their risks. - 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 already noted, the project team can use two methods to determine the contingency allowance, depending on the level of the project: the stochastic (probabilistic) method or the deterministic method.
When the project team has used a stochastic approach, it must verify the adequacy of the contingency provision in the form of a top-down assessment. This involves reviewing the figure against industry benchmarks, previous projects and/or industry reviews. literature – similar to a deterministic approach to estimating a contingency provision.
This sensory check helps the project team identify and overcome biases of optimism and pessimism and increases confidence that the risk register and contingency provision 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 University of Melbourne study).
For Tier 1 and 2 projects, the recommended P-value is P90 (see box below). Using the P90 value provides an appropriate balance between minimizing the risk that the project will require additional budgetary funding and not unnecessarily tying up scarce budgetary funds.
EN 
FR