Guide to Project Risk Management

Active project risk management is a concept that has been growing momentum as of late.  Project managers are expected to know the risks inherent in their projects and give them the appropriate level of scrutiny.

Risk is defined by the Project Management Institute as an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.

Risk Management

A project is a temporary endeavor which produces a unique product, service or result.

Because it is temporary, its success of failure must be defined by critical success factors (CSF’s).  These are the factors which must be satisfied in order to consider the project a success. Things like staying on budget, meeting the deadline, and so forth.

A risk event is something which negatively affects the project’s critical success factors.

When a risk event occurs, it is no longer uncertain.  It becomes an issue.

Risk management is the process of identifying, analyzing, and mitigating the most important risks to the successful completion of the project.

A Risk Management Plan communicates to stakeholders what the most important risks to the project are and how they will be managed.

Components of Risk

There are two basic components of risk.  The formula for risk is:

Risk = Probability x Impact

• Probability:  The likelihood of a risk event happening.
• Impact:  The consequences of the event.

I will illustrate with an example.  Being hit by a subway train is an event representing a high impact, but low probability.  You step back from the train to lessen the risk, and this mitigating action is motivated by the potential impact. On the flip side, the probability of being burnt by spilled coffee is high, but the impact is low. You will probably also perform mitigation actions such as walking slowly, stopping for people walking by, etc., but in this case the risk is driven by the high probability of it happening rather than the impact.

Sometimes the probability and impact are both high, for example, iron workers working on top of newly placed beams on a highrise building.  These types of risks usually require upfront mitigation actions, or in the worst case the project cannot proceed.

All Projects Contain Risk

All projects contain risk, by definition.  Its very existence means that somebody decided to pursue the project, therefore as a minimum the project has a risk that it does not accomplish its stated objective.

Thus, it is not a worthwhile goal to attempt to eliminate all project risks.  Projects have risks by virtue of their existence, and project sponsors generally accept these risks.  The project manager must communicate these risks to ensure that stakeholders are aware of the potential consequences and understand the risks that are being taken.

There is usually one or two primary risks that are associated with the project’s goals, for example,

• designing a bridge that does not fail under the required loading.
• repairing a gas pipeline leak so that the leak is completely removed.
• building a fence that keeps the dog inside.

Generally, but not always, these will be high on the impact scale but low on probability, because the project was initiated with this goal in mind and accomplishing the primary goal of the project has already been considered.

Risk and Contingency

Each risk event can be allocated a contingency to account for the possibility of that risk event occurring.

To calculate the ideal contingency, a risk event’s two components are assigned:

• Probability in percent
• Impact in monetary (dollar), time, etc.

For example, there is a 20% probability that the project will be delayed by 5 days due to rain. The ideal contingency, then, is 20% or 5 days, or 1 day. You would add one day to the schedule to account for this risk.

Of course, it is often difficult to determine the probability and impact of a risk event. An entire industry (insurance) and profession (actuaries) is built around determining the monetary value of real world risk events. But for many risks the project manager is in an ideal position to add value to the project by performing a basic analysis themselves.

For example, let’s say you notice that a certain welder must go back and fix deficiencies 1 out of every 10 times at an average cost is $5,000. The risk is 10% x $5,000 = $500. It means that if you put a contingency of $500 into the project, it will cover that particular risk on that welder over many identical projects.  Of course, you will never have many identical projects but, statistically speaking, this is the ideal contingency.

Opportunities

Opportunities are the opposite of risk. They contain a positive instead of a negative outcome. Many projects encounter opportunities throughout their duration and this possibility should often be accounted for within the risk register to keep the project competitive.

Project Risk Management

There are 3 steps involved in good project risk management:

1. Risk Identification
2. Risk Analysis
3. Risk Response Plan Development

Identifying Risks

To provide a solid risk management plan upon which the project can depend, the most important risks must first be identified and listed in the risk register.  Some projects are inherently risky, like paving a busy freeway, or repairing an airplane engine.  In this case risk analysis is an integral part of the project, but for many smaller, less risky projects the same concepts apply.

Methods that can be used to identify risks to the critical success factors include:

• • Brainstorming
    Whether alone or in a group, brainstorming involves focusing on quantity over quality.  Just write everything you can think of on paper, and then come back and narrow down the list.
  • Checklists
    A checklist that is specific to your organization or type of project is best.  You can start with our checklist but it’s best to edit it to make it more specific.
  • Subject matter experts
    There is no substitute to having experts in the subject matter advising you of the potential risks involved with the work.  Often they are in other departments but their advice has no equal.
  • Documentation review
    This involves learning about the project, its technical details, and its people.  Most of them time there are standard parts which have been performed many times before, and the stakeholders are aware of the risks. But it’s the non-standard items that should be scrutinized for potential risks that nobody thought about.
  • Lessons learned
    Few organizations keep a written record of lessons learned, but it is an invaluable tool.  It’s a highly visible record of problems encountered, mistakes made, and what the project manager would do differently in future projects.  When you’re starting a new project and you spend a few minutes reading that, how can you go wrong?
  • SWOT Analysis
    A Strengths-Weaknesses-Opportunities-Threats analysis will assist in drawing out the risks inherent in the project.  Particularly the Weaknesses and Threats quadrants can yield some new risks you didn’t think of before.
  • Delphi technique
    This method involves querying a group of people or subject matter experts, then sharing all of the answers anonymously with the whole group and letting them revise their original answers.  After several rounds a consensus should emerge.
  • Assumptions analysis
    Every project contains certain underlying assumptions upon which its business case is built.  Identifying these assumptions, and analyzing their reliability, can result in the identification of new risks.
  • Influence Diagrams
    Drawing out a simple decision network for the major turning points within a project can yield the important risks.

Obviously it is not possible to list all potential project risks.  The real world contains too many variables.  For example, the risk of an airplane crashing into the project office has a high impact, but a probability so low as to preclude it from consideration in the risk register. The goal is to find the most important risk events, and at this stage quantity is more important than quality. In the next step the risk register will be prioritized and the least important purged from the list.

Creating a list of project risks not even so much for you, the project manager, as it is for the project sponsors, the initiators of the project, and other stakeholders.  Stakeholders have an uncanny way of assuming there is no risk.  They tend to have ideal views of the project whereby everything will run smoothly and nothing bad will happen (probably because they don’t want to think about it). Thus, serving a client, manager, or stakeholder with a risk register makes it plainly obvious that unexpected events can occur and they are being planned for. When they happen, those same stakeholders tend to give the project manager a much longer leash.

Risk Analysis

After identifying the major risks, the next step is prioritizing them according to probability and impact.  This quickly identifies which need more attention and which do not.

It does not matter what scale is used but 1-10 or High-medium-low work well.  This is an excellent communication tool for project stakeholders who see that the risks have been considered and the appropriate amount of analysis given.

The normal risk analysis steps are:

1. Qualitative Analysis
   The risks are given a score on both constituent parts, probability and impact.  For small projects, the scale can be 1-10, A-E, or something simple.  For larger projects it might be more prudent to use 1-100 (i.e. percentage) for probability and the actual value for impact (dollar value, days of delay, etc.). This allows for a determination of the contingency as described above.
2. Quantitative Analysis
   This step assigns a value to each risk. As stated above, a simple contingency calculation (10% chance of losing $5,000 = $500) is one form. The insurance industry uses tools such as Monte Carlo simulations, statistical models, and probability distributions. For small projects, you can assign a 1-10 rating to both probability and impact, and multiply them together.
3. Risk Prioritization
   As an administrative step, the risks are ranked in order of priority, from highest to lowest, and the lowest ones which are designated insignificant are removed. The top risks are designated for the development of risk response plans.

Developing Response Plans

Response plans should be developed for the primary risks to the project.  This ensures that not just that the appropriate action is taken when the risk event occurs, but that the project manager is comfortable with the risk responses and is able to take fast, decisive action for anything that happens.

For every risk, there are 4 possible responses:

1. Avoid.  Eliminate the threat or protect the project from its impact.  Here is a list of common actions that can eliminate risks.
   1. Change the scope of the project.
   2. Extend the schedule to eliminate a risk to timely project completion.
   3. Change project objectives.
   4. Clarify requirements to eliminate ambiguities and misunderstandings.
   5. Gain expertise to remove technical risks.
2. Transfer.  This involves moving the impact of the risk to a third party.  Direct methods might be through the use of insurance, warranties, or performance bonds.  Indirect methods such as unit price contracts instead of lump sum (or vice versa depending on which side of the contract you’re on), legal opinions, and so forth.
3. Mitigation.  Reduce the probability or impact of the risk.  This is not always possible and often comes with a price that must be balanced against the value of performing the mitigating action.
4. Accept.  All projects contain risk.  As a minimum, there is the risk that it does not accomplish its objective.  Thus stakeholders, by definition, must accept certain risks.  Accepting risk is a strategy like any other, and communication of the risk with the applicable stakeholders can often reduce the outfall of the risk.  Risk acceptance can be passive, whereby the consequences are dealt with after the risk occurs, or active, whereby contingencies (time, budget, etc.) are built in to allow for the consequences of the risk to the project.