Project Risk Analysis

Because you can’t see its results in a direct way, project risk analysis is too often sacrificed by
project managers in the name of time or budget constraints. Compounding the problem is that small
projects just don’t seem to have the time and budget to justify the time spent on risk management.
But I would argue that if risk management is a priority on megaprojects it would have a
corresponding positive effect on small projects.

Actually, megaprojects have entire teams devoted to risk management, and PMI certification
recognizes an entire profession around it.

On small projects, in fact, risk analysis can often be spread throughout many similar projects which
incur the same risks, thereby reducing the cost of risk management activities per project. For
example, a plumbing firm could have a risk register for a commercial building project, a residential
building, a hot water tank repair project, etc.

The risk management process looks like this:

1. Risk Identification
2. Risk Analysis
1. Qualitative Analysis
2. Quantitative Analysis
3. Develop Risk Response Plans
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 Truck drivers call in sick

4 Airplane crashes into haul road

In this second step, the risks will be prioritized by their underlying

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 #4, because it is immediately deemed too unlikely to happen.

Risk Register

ID Description

1 Haul truck breaks down

2 Weather makes haul road impassable

3 Truck drivers call in sick

We then proceed to the meat and potatoes of the risk analysis. Risk analysis has two components:

1. 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.

Risk = Probability x Impact

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 a percentage or return period (eg. 6:1). For small projects I suggest
using a simple 1-10 scale.

Our 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

3 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. Since this is a small project, we’ll use the 1-10
scale. Our 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

3 Truck drivers call in sick 3 7

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 appropriately. 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 any 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

3 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 monitored 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 risk
score. This is effectively a contingency that the project should account for.

Risk Register

ID Description Probability Impact Risk Score

1 Haul truck breaks down 10% $50,000 $5,000

2 Weather makes haul road impassable 20% $50,000 $10,000

3 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 sophisticated a calculation was
done to get there.

The Risk Management Plan

The risk register and risk response plans are rolled up into and become the main part of the risk
management plan, which is a component of the overall project management plan.

In practical terms, the risk management plan can be a stand alone document or a section of the
project management plan but it still serves as a sub-section of the project management plan.