Risk Management Deeper Dive Part 3 – Risk Triggers

Executing Monitoring and Controlling

In this series Part 1, I addressed Risk Identification. In Part 2, I addressed Risk Probability, Impact and Exposure. In this entry I will discuss the concept of the “Risk Trigger”.

An important aspect of Risk Management is knowing and detecting that the risk has occurred. This is know as a “Risk Trigger”. In some cases it may be obvious. An example of this would be a risk such as “If the project team loses key resource “A”, then the task estimates assigned to “A” will need to be extended which may impact key milestone commitments”. In most cases the PM will know when they have lost a key resource. However, in the case of very large project teams, the key resource may be embedded deep in the project hierarchy, hiding the loss unless there is a communication plan to notify the PM

Your risk triggers must define the method you will use to monitor the risk. For example, if there is a possible change to a government regulation that will impact your project, you can engage your Legal team to monitor the status of this regulation on a regular basis and report any changes directly to the PM.

Here is another example: if there is a risk your server capacity is insufficient to meet peak demand, you might direct your technical team to establish monitors for CPU and disk usage and raise a flag if they are approaching the safe limits.

The lesson here is don’t assume you will just know when a risk has occurred. Define Risk Triggers (even the obvious ones) for all of your risks.

Now that you know your risks, exposures, and when they occur, the next step is to manage them with mitigation and contingency plans. I will tackle these topics in the upcoming posts.

Note: Much more detail on Risk Management can be found in my Kindle book “Project Management For The Real World”, available at

https://www.amazon.com/author/lettera

Advertisement

Risk Management Deeper Dive Part 2 – Risk Prioritization

Executing Monitoring and Controlling

After you have identified your risks, the next step is to prioritize them. We do that by assigning a probability rating and an impact rating, then combining the two to determine your exposure (i.e. priority).

The Risk Probability is a measure of the likelihood of the risk occurring. In most cases it is difficult to assign an exact probability. It usually will be sufficient to define probabilities as “High”, “Medium”, and “Low” and define these probabilities as ranges. Here is an example of the ranges I typically use:

  • High = 70% or greater probability
  • Medium = between 40 – 69 % probability
  • Low = less than 40% probability

You can use whatever definition you choose as long as all of the parties helping you assign probability are aware of the defined ranges.

The Risk Impact is a measure of the effect of the Risk occurrence on the schedule, scope, budget and quality of the project. Again, since in most cases this may be difficult to quantify, using ranges represented by “High”, “Medium” and “Low” will suffice. Here is an example of range definitions for Risk Impact:

  • High = greater than 10% impact on one or more of schedule, scope, budget and quality
  • Medium = 5-10% impact on one or more of schedule, scope, budget and quality
  • Low = less than 5% impact on one or more of schedule, scope, budget and quality

The Risk Exposure is a product of both the Risk Probability and the Risk Impact. It is also measured as “High”, “Medium” and “Low” if that is the way you defined the probability and impact. Here is how the Risk Exposure can be determined:

  •  Probability (High) + Impact (High) = Exposure (High)
  •  Probability (High) + Impact (Medium) = Exposure (High)
  •  Probability (High) + Impact (Low) = Exposure (Low)
  •  Probability (Medium) + Impact (High) = Exposure (High)
  •  Probability (Medium) + Impact (Medium) = Exposure (Medium)
  •  Probability (Medium) + Impact (Low) = Exposure (Low)
  •  Probability (Low) + Impact (High) = Exposure (Medium – but watch closely due to impact)
  •  Probability (Low) + Impact (Medium) = Exposure (Medium)
  •  Probability (Low) + Impact (Low) = Exposure (Low)

Now that you have your Risk Exposure determined you should monitor and act on them in order of exposure, with the ones rated “High” given the most attention. This will help you allocate your risk management resources appropriately.

Note: Much more detail on Risk Management can be found in my Kindle book “Project Management For The Real World”, available at

https://www.amazon.com/author/lettera

Risk Management Deeper Dive Part 1 – Risk Identification

Executing Monitoring and Controlling

The first step in managing risk is to identify the risks you need to manage. This is the most important step in risk management and something new project managers tend to struggle with. I will present some techniques that have over the years have worked well for me.

  1. What worries you? – You can ask this question to your project team members and stakeholders. Do this first individually, then in groups. Many do not understand the term “risk” as it applies to projects and may come up with a blank if you ask them about risks. Everyone can relate to the term “worry” and I have found this helpful. You may get answers such as “I don’t have enough resources” or “the timeline is too tight” or “I don’t have enough expertise on my team in this area”. These types of answers are a great start in risk identification.
  2. The “Pre-Mortem” – We are familiar with doing “lessons learned” and “post-mortems” on projects. Doing a “Pre-Mortem” can help identify risks. You ask the project team and stakeholders  “It’s 9 months from now, the project is over and it was a disaster. What are the reasons?”. Your mind works better at identifying risk when looking backwards so this technique can be very effective. You may get responses like “The Sponsor wasn’t involved in decision making” or “We didn’t train the staff on the new tools”. These types of answers are risks that need to be managed. You can also ask the opposite question: “It’s 9 months from now, the project is over and it was wildly successful. Why?”. Responses like “Mary Jones was assigned as the technical lead” or “The Steering Committee made prompt decisions” will help you identify risks and mitigate them.
  3. Risk Breakdown Structure(RBS) – if you Google this term you will find many examples. An RBS is simply a hierarchy of areas in which risks can occur. You would present each of these areas to the team and brainstorm potential risks for each area. Here is a sample RBS:
  • Technical
  • Technology
  • Complexity of Interfaces
  • Performance and Reliability
  • Quality
  • External
  • Vendors
  • Regulatory
  • Market
  • Customer
  • Weather
  • Environmental
  • Government
  • Internal
  • Dependencies on other projects
  • Resources
  • Funding
  • Requirements
  • Resistance to change
  • Inexperience
  • Schedule
  • Equipment
  • Quality
  • Customer Satisfaction
  • Project Management
  • Estimates
  • Plans
  • Controls
  • Communications
  • Scope

You should state your risks in a consistent manner. A common way to phrase your identified risks are: “If (risk event occurs), then (impact to project in terms of scope, schedule, cost, quality)”

Here is an example: “If the vendor is late delivering Component X, then we may not be able to meet the project milestone for the first build”. Note that I stated “may” not “won’t”. Remember, risks are probabilities, not certainties. If it is a certainty, it is an issue, not a risk.

Note: Much more detail on Risk Management can be found in my Kindle book “Project Management For The Real World”, available at

https://www.amazon.com/author/lettera