Risk Identification

The first step in a good risk management plan is the identification of risks.  The other phases of project risk management are built on the foundation built here.  A comprehensive list of potential risks to the project must be developed, calleda Risk Register.

Clearly it is not feasible to attempt to identify all risks to a project – Maybe a plane will crash into your office.  But in this initial step it is important to be open minded at first, then revisit the list and narrow it down to the most important.  Since risk has two components – probability and impact – you can proceed to eliminate risks that are too low in one or the other category.

In fact, an airplane crashing into your office might be a high impact event, but contain a probability so low that it isn’t a significant risk to the success of the project.

Risk planning needs to scale to the size of the project.  Small projects should still have a risk register, but only enough time should be spent on it to create a corresponding amount of value.  Medium size projects should have a well developed risk register, and megaprojects generally tend to a have professional risk analysis.

How to Identify Risks

There are many different techniques that can be used to identify project risks, including the following:

• Checklists
  If you don’t already have one, try to develop a checklist for risks that is specific to your organization.  This will allow you to quickly realize which ones are the most important and in which circumstances they apply.  We have a checklist which can be a good starting point, but it is better to have a more specific one.
• Lessons learned
  Only once have I encountered an organization that maintains a lessons learned database, but it is an amazing tool for them.  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?
• Subject matter experts
  There is essentially no substitute to having experts who know the subject matter advising you of the risks involved with the work.  Often they are in other departments but their advice is second-to-none.
• Documentation review
  This involves learning about the project, its technical details, and its people.  Pay close attention to the unusual parts, the ones that aren’t everyday, simple tasks.
• 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.
• 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 later.
• 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.

Terminology

Any good description of the risk event will suffice, but the Project Management Institute provides a guideline for the risk description which is comprehensive and ensures you will have the basics covered.

• Event may occur, causing Impact.
• If Cause exists, Event may occur, leading to Effect.

Simply replace the bold words with your project specific details.

Related Risks

Often it is difficult to keep risks completely independent of each other.  Some risks occur together if a certain root cause occurs, or some risks will generate other risks.  The most common situation is when the occurrence of a risk changes the risk profile of another risk on the register.  What was once a minor risk to be aware of turns into a major worry that requires project management time.

It is desirable to keep the list as independent as possible, but keeping it completely independent is impossible.  At some point you will have to make the decision as to whether two risks are so interrelated that they should be considered one risk or kept separate.

The Risk Register will Change

Throughout the project, the risk register will be in a constant state of change.  The project manager is constantly designating risks on the register as expired because the associated tasks are complete.

But at any time, a risk can occur and the other risks should be reassessed.  One of the following three things could occur:

1. Eliminated the risk
2. Changed the priority (probability and/or impact)
3. Triggered the risk event

Project Closure

At the end of the project, the risk register should be certified as closed and each risk given one of three designations:

1. Did not occur
2. Occurred and contingency plan invoked
3. Occurred with an impact to the project (scope, time, cost, etc.)

Data Within the Risk Register

A good risk register has the following six columns:

• Description of risk
• Probability
• Impact
• Priority
• Triggers
• Response plan

In this article we have been focused only on the first column.  The next two columns, probability and impact, fall under Risk Analysis.