Project Risk Assessment

Project Risk Assessment

One the processes that I often have trouble defining is “Risk Assessment” as it often seems to be used to describe different or multiple processes that take place as part of a larger project risk management process. At Intaver Institute, typically we will hear about processes that involve risk assessment, plan, monitor and control. In these cases, you can replace assessment with identification and scoring. So in this context, a risk assessment involves in identifying events that could impact your project and then scoring each risk based it probable impact on key project objectives.

Risk identification is the process of identifying events that could happen during project execution that could have a positive (opportunity) or negative (threat) impact on key project objectives. When identifying risks, it often helps to have a Risk Breakdown structure (RBS). An RBS defines the organization areas in which risks can occur. Often an RBS is divided into internal or external sources of risk or as in the example below, it is organized by different classifications. For example, when identifying risks, if you looked at People > Stakeholder Management this would involve both internal and external stakeholders and understanding their specific interests in the project.

Risk identification is a process of capturing and defining information regarding these events. This information is often referred to as “Risk Properties” and are recorded in a risk register. The most important property is the risk statement. While there are several definitions of what a risk statement should include, at a very basic level it is an “if …. then..” statement. An example, could be “Feedback from key stakeholders has been delayed and incomplete, if communications with key stakeholders are not managed properly, then key project objectives may not be met.” Once the risk statement is completed, the next step is to record additional information about the risk such as: When was it identified, who identified it, when could it occur, etc.

The next step of the risk assessment is scoring. To score a risk requires two data points: the probability that the risk will occur and how it will impact project objectives such as cost, schedule, technical performance, reputation, etc. Of the two, probability is the most difficult. Often this can be caused by definitional issues, such as if you ask a group what “Very Likely” mean in terms as a %. You will find, as we did, that this can range from as high as 95% to as low as 50%. But most often this difficulty arises from a lack of knowledge. Your team may have identified a risk, but it may or may not have occurred in any previous projects. If you had one previous similar project and the risk occurred, does this mean that the probability is 100%? Calculating probability often requires several different methods. Most common method to set a baseline probability is to use the relative frequency analysis. By looking at past projects, you can see how often the risk was identified  vs. how often it actually occurred. This will provide a good starting point. For example if you had 20 previous projects where the risk was identified and it occurred in 7, you would have 35% probability.  You can now use other sources of information such as expert opinion, subject matter experts to validate the probability or shift it up or down. Often this will be due to unique characteristics of a project that can include contractors, customers, locales, changes to regulatory environments and additional factors.  Taking into account these factors, your team can generate a reasonable accurate risk probability. Risk probability can be defined as either a % or range defined by a probability matrix. Probability matrixes map labels or indexes to ranges in probability. In these cases a “Very High” probability might be defined as “greater than 1 in 2”.

The next step is to evaluate possible impacts on project objectives. In our practice, objectives are risk categories such as schedule, budget, performance, reputation, and safety. It is important that once you have defined your risk categories that you define the impact of each risk on all of the categories, regardless of how small or non-existent they may be. Like probability impacts can be quantitative, shown as relative of fixed impacts on cost or duration; or, qualitative where as in probability, an impact matrix is used to define ranges of impacts such as an cost impact between 10 and 20% of the budget could be evaluated as “High” or “4” out of a possible 5.

Once you have identified the probability and impact, you can then calculate a risk score. Typically, risk score = probability x impact. A simple quantitative risk score could be probability 50% x Impact 75% =37.5%. Another example, might have probability and impact scores that range from 1-5, which is extremely common. In this case, you might have risk with Medium (3) probability and Very High (5) impact where the risk score = (3)*(5) = 15. With multiple impacts, the score can be calculated using the highest impact of any one category or the average impact on all categories.

Once risks have been scored the final step in the assessment process is prioritizing or ranking risks to identify those risks that should be handled first and the level of effort that is required. A common tool for this final step is plotting the risks on a probability and impact matrix. In the example below, where the risk is located on the matrix dictates the level of management oversight and effort required to ensure the risk is managed properly. Commonly all risks that fall on a red cell must have a fully developed risk plan, yellow indicates less effort is required, green indicates risks that can safely accepted and no further management required though they should be monitored over the course of the project.

Probability and Impact Matrix

So risk assessment is a combination of two processes: identification and scoring with the goal of prioritizing and ensuring that sufficient resources are allocated to each risk in accordance with the threat or opportunity that it represents to a project. Even within this definition, the process can vary widely in its implementation, especially as you compare qualitative vs quantitative risk assessments. It is important to modify the risk assessment process with the scale of the projects. For relatively small-scale projects, simple risks assessment should suffice. For large or strategic projects, quantitative risk assessments should be considered.