Project Risk Analysis

risk analysis

Risk analysis is an often omitted area of project management, probably because you can’t see its results in a direct way.  On top of that, small projects just don’t seem like they have the time and budget to justify the time spent.  But I would argue that analyzing risk is one of the easiest ways to prevent major headaches later on, and it pays for itself in costs that don’t appear but otherwise would.

On small projects, in fact, risk analysis can often be spread throughout many similar projects which incur the same risks, thereby reducing the cost per project.

During the initial Risk Identification step (step 1), a risk register was completed which was simply a list of the most important risks to the project.  For example, the initial risk register might look like this:

Risk Register
ID Description
1 Haul truck breaks down
2 Weather makes haul road impassable
3 Airplane crashes into haul road
4 Truck drivers call in sick

In this second step, the risks will be prioritized by their underlying factors, probability and impact.  More specifically, the following columns might be added:

  1. Probability
  2. Impact
  3. Priority

From those, the highest priority risks will be identified for the third step, which is risk response planning.

It is okay, even recommended, that the original list have some risks that are determined insignificant and will be struck off.  The focus during the first step was on ensuring nothing was missed.  In our example we will strike off risk #3, because it is immediately deemed too unlikely to happen.

Risk Register
ID Description
1 Haul truck breaks down
2 Weather makes haul road impassable
4 Truck drivers call in sick

I know this is a funny example, but in real life you will have borderline items that aren’t nearly as obvious, and it is best to make sure you don’t miss anything.

We then proceed to risk analysis, which has two components:

  1. Qualitative Risk Analysis
  2. Quantitative Risk Analysis

Qualitative Risk Analysis

In the qualitative risk analysis phase, a probability and an impact score is given to each risk.  Since risk has two components, probability and impact, both need to be considered.

Probability

Assessing the probability of an uncertain event is a difficult task.  In the insurance industry, actuaries use similar events with known statistical outcomes to determine a standard “distribution” for an unknown event.  Here are some ideas to determine the probability of an event happening:

  1. Determine how often the event actually occurred on previous projects.  Many projects have tasks that have been performed on other projects.  For example, if an event occurred twice in ten previous projects, the probability of the event might be approximately 20%.
  2. Compare to a known probability.  The odds of throwing a dice and landing on a six are obviously 6:1.  The odds of giving birth to twins is 70:1.  Maybe you have a known probability of an event within your company or project.  Compare your uncertain outcome to something certain.
  3. Decompose the risk into constituent parts.  Are there any sub-events that contain a known probability, which can then result in a better estimation of the whole?
  4. Ask experts to rank the risks as “high/medium/low.”  Then average the answers into a score out of 10.  Using broad categories to assign probabilities makes it clear which one the event belongs in, then averaging the result into a greater distribution utilizes the wisdom of crowds.

Probability can be stated in percent or return period (eg. 6:1).  For smaller projects however, I suggest using a simple 1-10 scale.  The example risk register now looks like this:

Risk Register
ID Description Probability
1 Haul truck breaks down 7
2 Weather makes haul road impassable 8
4 Truck drivers call in sick 3

Impact

The impact of the event is often easier to define but can be a range of possibilities rather than an exact number.  There are many different aspects of the project which can be impacted, but the most common are:

  1. Cost
  2. Schedule
  3. Quality (technical performance)

Impact can be stated in monetary terms (i.e. dollar, euro, etc.).  However, for small projects I would recommend simply using an empirical scale of 1-10.  The example risk register now looks like this:

Risk Register
ID Description Probability Impact
1 Haul truck breaks down 7 9
2 Weather makes haul road impassable 8 9
4 Truck drivers call in sick 3 7

My assumptions are that risks #1 and #2 will shut down the operation but risk #4 could result in partial success, hence the lower impact score.

Priority

The purpose of risk analysis is to determine the overall priority of a risk so that further action can be taken on the most important ones.  There are two primary ways to amalgamate the probability and impact into an overall priority:

  1. If you’ve stated the probability in percent (or return period) and the impact in monetary terms (dollars, etc.), you can simply multiply them to obtain the risk level.  This value essentially functions as a contingency.  If you performed the exact same project many times, this amount would be the ideal contingency.
  2. If you’ve simply ranked or prioritized each risk on a scale of 1-10 (or similar) you can multiply the values to obtain a priority level.  This number will not have an meaning outside of individually ranking the risks.

In our example, since we used 1-10 rankings for both we can simply multiply them to get a priority:

Risk Register
ID Description Probability Impact Score Priority
1 Haul truck breaks down 7 9 63 2
2 Weather makes haul road impassable 8 9 72 1
4 Truck drivers call in sick 3 7 21 3

Based on this analysis the weather (risk #2) should be the highest priority.  If the probability and impact are considered severe enough you might proceed to step 3, the preparation of risk response plans, for this risk and any other risk for which it is deemed appropriate.

Based on the priority of the list, the bottom risks can be removed altogether or added to a “watch list.”  The watch list could be looked at throughout the project to ensure they do not increase in probability and/or impact to the point of requiring response plans or other action.

Quantitative Risk Analysis

The second component of risk analysis consists of turning the probabilities and impacts into quantifiable project budget impacts.  This is done via simulations such as Monte Carlo analysis and generally requires project management software.  Unlike the qualitative analysis, the probabilities must be in percent form and the impacts in monetary (i.e. dollar, euro) form.

In the simplest of quantitative risk analyses, a probability and impact can be multiplied into a contingency.

Risk Register
ID Description Probability Impact Contingency
1 Haul truck breaks down 10% $50,000 $5,000
2 Weather makes haul road impassable 20% $50,000 $10,000
4 Truck drivers call in sick 2% $20,000 $400

In a Monte Carlo analysis, the probability and impact are given a distribution (normal distribution, beta distribution, etc.).  Then, a random result is picked from the distribution to simulate the occurrence of the risk.  The actual cost to the project by the event is calculated, and the test is run many times which results in a distribution curve of the project’s actual budget.  Thus, it gives you a probability range of actual costs for the project, which is great for management presentations.  However, like any analysis it’s garbage in, garbage out, and the confidence level of the results are never better than the initial inputs regardless of how complicated a calculation was done to get there.

About Bernie Roseke, P.Eng., PMP

Bernie Roseke, P.Eng., PMP, is the president of Roseke Engineering. As a bridge engineer and project manager, he manages projects ranging from small, local bridges to multi-million dollar projects. He is also the technical brains behind ProjectEngineer, the online project management system for engineers. He is a licensed professional engineer, certified project manager, and six sigma black belt. He lives in Lethbridge, Alberta, Canada, with his wife and two kids.

View all posts by Bernie Roseke, P.Eng., PMP

Leave a Reply

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

*