Risk Management

  1. Identify the risk. The first phase of the risk management process is to identify and define potential project risks with your team. After all, you can only manage risks if you know what they are.
  2. Analyze the risk. After identifying the risks, determine their likelihood and potential impact to your project. Serious risks with a high probability of occurring pose the greatest threat.
  3. Evaluate the risk. Next, use the results of your risk analysis to determine which risks to prioritize.
  4. Treat the risk. During this phase, make a plan for how to treat and manage each risk. You might choose to ignore minor risks, but serious risks need detailed mitigation plans.
  5. Monitor and control the risk. Finally, assign team members to monitor, track, and mitigate risks if the need arises.


Ref.: Effective strategies for exploiting opportunities

Some examples of opportunities include:

  • Completing a milestone ahead of schedule
  • Discounted materials
  • Availability of additional resources (people, investments, equipment)

Fishbone diagram

Fishbone diagrams—also known as Ishikawa diagrams or cause-and-effect diagrams

Root cause is the initial cause of a situation that introduces a problem or risk. The purpose of using fishbone diagrams in risk management is to identify the root cause of a potential problem for a project or program.

Step 1) Define the problem

State the problem "trouble delivering products to downtown office buildings on time." Add the problem to the head of his fishbone diagram.

Step 2) Identify the categories

The types of categories that could be causing the problem. These categories will change depending on the type of problem or industry. Some common examples of categories include "people," "technology," "materials," "transportation," "money," "time," "environment," and "procedures."

Step 3) Brainstorm the causes

Brainstorm areas of concern within each category. Reaches out to your team for help in identifying these possible causes. Fill in the lists with some of the causes that could be related to each category.

Step 4) Analyze the causes

Analyze the causes to identify the root cause of the existing problem so you can figure out how to mitigate it for the current project.


Single point of failure risks

Once you have identified your risks and ranked them, give special attention to the risks that could have a catastrophic effect on your team's ability to complete the project. A single point of failure is a risk that, if it were to materialize, could cause a significant amount of disruption to your project and could even shut it down. You should plan for these risks early on in the project.

For example, a lot of projects use subject matter experts (SMEs)—team members with a deep understanding of a particular job, process, department, function, technology, machine, material, or type of equipment. SMEs are involved to advise you throughout the project life cycle. Having only one SME familiar with a critical system on your team is an example of a single point of failure risk. This SME will only offer one perspective, and if they are the only person advising on the system, there is no one to offer another perspective.

Mitigation Plan


This strategy seeks to sidestep—or avoid—the situation as a whole.


Mitigating a risk involves trying to minimize the catastrophic effects that it could have on the project. The key to minimizing risk starts with realizing that the risk exists. That is why you will usually hear mitigation strategies referred to as workarounds.


The strategy of transferring shifts the responsibility of handling the risk to someone else.


Accept the risk as the normal cost of doing business. Active acceptance of risk usually means setting aside extra funds to pay your way out of trouble. Passive acceptance of risk is the "do nothing" approach. While passive acceptance may be reasonable for smaller risks, it is not recommended for most single point of failure risks. It is also important to be proactive and mitigate risks ahead of time whenever possible, as this may save you from having to accept risks.

Types of task dependencies:

  • Finish to Start
  • Finish to Finish
  • Start to Start
  • Start to Finish