10.4 Risk Assessment

After the potential risks have been identified, the project team evaluates them based on their probability of occurrence and impact if they occur. This is a qualitative risk analysis method. In this textbook, we will not discuss the quantitative risk analysis process. Readers can check “11.4 Perform Quantitative Risk Analysis” in PMBOK Guide Sixth Edition for an overview of quantitative risk analysis methods^[1].

Not all risks are equal. Some risk events are more likely to happen than others, and the impact of a risk event can vary greatly. Therefore, project teams perform a qualitative risk analysis to prioritize individual project risks by assessing their probability of occurrence and impact^[2]. During the brainstorming sessions and meetings with experts, team members and other participants indicate their opinions regarding each risk. Qualitative risk analysis relies on team members’ and experts’ insights and judgments, who contribute their perspectives during brainstorming sessions and meetings. While this method enables the project team to leverage valuable experience and expertise, it inherently introduces the potential for bias, as personal experiences, recent events, or cognitive biases may influence individual opinions. To minimize these biases, the project manager should be a neutral facilitator by employing techniques such as Delphi, a structured communication technique that helps groups of experts reach a consensus on complex problems. The Delphi method allows team members to provide their assessments anonymously, reducing the influence of dominant opinions. The project manager should also encourage participants to justify their perceptions of probability and impact. This can ensure that assessments are grounded in rational explanations and provide transparency that can help moderate biases.

10.4.1   Probability

For the qualitative risk analysis, let’s use a five-scale measure for the probability: Very low, low, medium, high, and very high (Table 10.4.1). It is always possible to have more and fewer number of scales. Each level may correspond with different percentage values depending on the project, project manager, and organizational policies. Table 10.2 displays two different percentages of probability. Organizations may have an overarching policy to implement levels, percentages, and risk categories. In this case, the project manager must comply with this policy.

Table 10.4.1: Risk Probability Levels

10.4.2   Impact

The probability alone wouldn’t make sense if we disregard the impact of the risk. Just think that our project is in an area where a large earthquake hits every thirty years. Since the frequency doesn’t look high, we can give a very low probability level (5%). However, we should consider the impact of an earthquake if it occurs. Although the probability is 5%, the impact of an earthquake to disrupt project activities would be high. Even in our m-commerce project, an earthquake would have some negative effects, such as power outages, water supply problems, transportation issues, supply chain problems, and, worse, destroyed buildings, infrastructure, and fatalities. The large margin between the probability and impact is also the case for an epidemic or pandemic risk. Therefore, we can decide on a very high impact value (0.9) while the probability is 0.05.

Table 10.4.2 displays the impact levels and values for the impact of risks on schedule. Project managers can use criteria for different areas such as schedule, cost, safety, environment, and quality to determine the impact of level. A description of each impact level should be provided for each area to eliminate ambiguities. According to Table 10.4.2, if an activity takes 10 days to finish, and we find that risk may add 1 day, we have a delay of 10%. Therefore, the impact is low, and its value is 0.3.

Table 10.4.2: Description of Impact Levels Regarding Schedule

When we use several areas besides schedule, we should formulate how to generate an overall impact level. We can use a non-weighted or weighted model to combine all areas’ values. Table 10.4.3 shows the impact levels regarding cost.

Table 10.4.3: Description of Impact Levels Regarding Cost

10.4.3   Severity

Table 10.4.4 displays the risk severity score, calculated by multiplying the probability by impact percentages. In Table 10.4.4, there are three severity levels:

1. Green indicates low-level severity, which is between 0% and 15% inclusive,
2. Orange indicates medium-level severity, which is between 16% and 40% inclusive,
3. Red indicates high-level severity at 41% and above.

Table 10.4.4: Probability – Impact (Severity) Score

The risk severity scores help project managers and teams determine the risk response strategies and the amount of contingency reserves.

10.4.4   Variations in Project Risk Assessment Practices

Not all project managers conduct a formal risk assessment on projects. There may be barriers to identifying risks. David Parker and Alison Mobey ^[3] found in a phenomenological study of project managers that there was a low understanding of the tools and benefits of a structured analysis of project risks. The lack of formal risk management tools was seen as a barrier to implementing a risk management program.

Some project managers are more proactive and will develop elaborate risk management programs for their projects. Other managers are reactive and are more confident in their ability to handle unexpected events without prior planning. In contrast, some managers are risk averse and prefer to be optimistic and not consider risks or to avoid taking risks whenever possible.

In projects with low complexity, the project manager may informally track the risk items. On more complex projects, the project team may develop a list of items perceived as higher risk and track them during project reviews. On projects with greater complexity, the process for evaluating risk is more formal, with a risk assessment meeting or series of meetings during the project’s life to assess risks at different phases. On highly complex projects, an outside expert may be included in the risk assessment process, and the risk assessment plan may be more prominent in the project execution plan.

On complex projects, statistical models are sometimes used to evaluate risk because there are too many different possible combinations of risks to calculate them one at a time. These are considered quantitative risk analyses. One example of the statistical model used on projects is the Monte Carlo simulation, which simulates a possible range of outcomes by trying many different combinations of risks based on their likelihood. The output from a Monte Carlo simulation provides the project team with the probability of an event occurring within a range and for combinations of events. For example, the typical output from a Monte Carlo simulation may reflect a 10 percent chance that one of the three important pieces of equipment will be late and that the weather will also be unusually bad after the equipment arrives.