Project Execution and Monitoring

Risk Management Deeper Dive Part 5 – Contingency Plans

Professor of Project Management Project Execution and Monitoring, Project Planning ,
Executing Monitoring and Controlling

In the prior post I discussed risk mitigation strategies, which can reduce the potential impact of risks that haven’t occurred yet. In contrast, risk contingency plans are meant to deal with risks after they have occurred. It is sometimes amusingly referred to as “Plan B” (and “C”, “D”, etc if necessary). Contingency plans answer the question “What will we do if …”.

It can be much easier to create contingency plans in advance because you are not under the stress of the risk having already occurred and you have more time to brainstorm the potential plans. Anticipating risks and having well vetted contingency plans keeps you in control of the project and minimizes “crisis mode”.

Here are a few examples:

  • If there is a risk of testing taking longer than planned, you can have a list of additional testing resources identified to join the effort if testing falls behind.
  • If there is a risk of inclement weather disrupting outdoor activities, you can have indoor activities lined up to keep the project moving.
  • If there is a risk of a key resource leaving the project, you can have a consultant resource procured in advance to step in if needed.

As with all elements of Risk Management, conditions may change over time, so the contingency plans should be revisited on a regular basis to ensure they are still viable.

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

http://www.amazon.com/dp/b089krddvn

#projectmanagement

Advertisement

Risk Management Deeper Dive Part 4 – Risk Mitigation Strategies

Professor of Project Management Project Execution and Monitoring, Project Planning ,
Executing Monitoring and Controlling

With your risks identified, prioritized and monitored, it is now time to develop strategies for managing the risks. The first type of strategy is “Risk Mitigation”. These are actions you can take before a risk occurs that can reduce the exposure to the risk. You should brainstorm these strategies with the members of the project team you identified in the Risk Management section of your “Project Management Plan” (refer to prior posts on this topic).

There are four mitigation strategies you can employ:

  1. Risk avoidance – this is the most expensive of the risk options. You can spend money or resources to eliminate the risk. An example would be if you have a lesser skilled resource assigned to a task, which raises a risks of on-time completion and/or deliverable quality, you can spend more money for a resource skilled enough to eliminate those risks.
  2. Risk limitation – this is the most common strategy. You take some action to reduce the probability and/or impact of the risk. One example would be if you are concerned about server downtime or performance during peak loads, you can implement redundancy and load-balancing to mitigate this risk.
  3. Risk transference – involves handing off the risk to another (willing) party. Examples are buying insurance, or outsourcing services.
  4. Risk acceptance – if the cost of mitigating the risk outweigh the cost of the risk itself, you may choose to just accept the risk with no mitigation actions. This strategy is typically employed for risks with low probability and/or low impact.

Documenting your mitigation strategies puts you in control of the project. You can manage your risks or they will surely manage you.

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

http://www.amazon.com/dp/b089krddvn

Risk Management Deeper Dive Part 3 – Risk Triggers

Professor of Project Management Project Execution and Monitoring ,
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 book “Project Management For The Real World”, available in paperback and Kindle formats at

amazon.com/dp/b089krddvn

#projectmanagement

Risk Management Deeper Dive Part 2 – Risk Prioritization

Professor of Project Management Project Execution and Monitoring
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 book “Project Management For The Real World”, available in paperback and Kindle formats at

http://www.amazon.com/dp/b089krddvn

#projectmanagement

Risk Management Deeper Dive Part 1 – Risk Identification

Professor of Project Management Project Execution and Monitoring ,
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 book “Project Management For The Real World”, available in paperback and Kindle formats at

http://www.amazon.com/dp/b089krddvn

Risk Management Deeper Dive – Introduction

Professor of Project Management Project Execution and Monitoring ,
Executing Monitoring and Controlling

When I teach project management principles to non-professional PM’s, I emphasize that the two things you must do to greatly increase your chance of success are (1) create a complete Project Charter, and (2) manage risk. Those two practices, when done well, contribute to the bulk of project success.

In previous topics I discussed Risk Management in two places:

  1. The Project Charter
  2. The Project Management Plan

In the Project Charter, only the initially identified high exposure risks are typically listed and you may not yet have fully developed mitigation and contingency plans. In the Project Management Plan, the Risk Management Plan describes the process of risk management but it does not address the specific risks.

In the “Risk Management – Deeper Dive” series of posts, I will present the following topics in detail:

Part 1: Risk Identification

Part 2: Risk Prioritization (probability/impact/exposure)

Part 3: Risk Triggers

Part 4: Risk Mitigation Strategies

Part 5 : Risk Contingency Plans

Part 6: Risk Ownership

Part 7: Risk Monitoring

Managing risk is a key project management best practice. I strongly suggest you make this one of the first areas of mastering project management.

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

http://www.amazon.com/dp/b089krddvn

Kick The Field Goal! What American Football Can Teach Us About Project Management

Professor of Project Management General, Project Execution and Monitoring

With the NFL season about to begin I thought I would share a project management lesson I learned many years ago from, oddly enough, watching an NFL telecast. The color analyst was the legendary John Madden.

Team A was trailing Team B 21-0 but it was still early (mid second quarter). They were confronted with a 4th down and goal to go situation from the 5 yard line. Fans of Team A, concerned with the large deficit, were no doubt screaming for their team to go for the touchdown. This is when Madden made the point that resonated with me from a project management perspective:

“I would kick the field goal here. The longer you are at 0 points, the harder it becomes to move off of 0. Once you have points you have something to build on.”

There are those in the modern sports analytics field who might argue this but that is not the point of this post. Madden’s comment made me realize that the longer a project goes without delivering business value (known as the “Business Objectives” of the project), the harder it gets to deliver them. Some of the main reasons for this are:

  1. Business or IT Management and Stakeholders continue to propose grand ideas which significantly increase the scope without going through formal Scope Change Management.
  2. The Project lacks a Charter or Definition with sufficient detail, making “scope creep” hard to define.
  3. The Project is trying to deliver the Project Objectives all at once instead of a phased approach which can deliver some business value earlier.

I recommend having well defined Business and Project Objectives. Manage Scope jealously. Deliver at least some of the Business Value as early as possible and in phases.

The longer a project drags on without delivering something, the harder it gets to deliver anything. So”Kick the Field Goal”. Get off of “zero” as soon as possible. Your business and project (and your career) will be the better for it.

A reminder that my Kindle book “Project Management For The Real World” is available at

http://www.amazon.com/dp/B089KRDDVN

Project Status Reporting

Professor of Project Management Project Execution and Monitoring ,
Executing Monitoring and Controlling

Your Project Status Reports, like all communications, will vary with the audience. For large projects, your two main audiences are the Executive Steering Committee and the Project Sponsors. All status reports should have heading level information such as the Project Name and Number, a brief description, and the date and author(s) of the report.

Listed here are the elements I recommend including on the status report, with the designation “ESC” if you should include this item on the Executive Steering Committee report and “PS” for inclusion on the Project Sponsor report.

  • The Project Health Scorecard (defined in the posts preceding this one) – ESC, PS
  • High Impact Issues – ESC, PS
  • High Exposure Risks – ESC, PS
  • Upcoming Major Milestones and dates – ESC, PS
  • Key activities completed since the last report – PS
  • Upcoming key activities – PS
  • Upcoming dates where key project team members have a planned absence – PS
  • Call-outs (comments of significance you want to include in the report but don’t fit into the other categories) – ESC, PS

You can use MS Word, Excel or PowerPoint to format the report. Make it pleasing to the eye and uncluttered. In a future post, I will show you how to design a status report page on your SharePoint Project Site.

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

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

The Project Health Scorecard Part 6 – Risk

Professor of Project Management Project Execution and Monitoring ,

Executing Monitoring and Controlling

Here is the suggested guidance for the status of the Project Risk Health:

Your Risk Health is Green if all of these are true:

  • Issues and risks are documented in a central repository
  • Risks have triggers, mitigation and contingency plans for high-exposure and high-impact risks
  • Risks are reviewed on a regular basis by the project manager and risk/issue owners;

Your Risk Health is Yellow if any of these are true:

  • Issues and risks are defined in a central repository but not reviewed on a regular basis by the project manager and risk/issue owners
  • Risks have no mitigation and contingency plans associated with the high-exposure items

Your Risk Health is Red if any of these are true:

  • Issues and risks are not documented in a central repository
  • Risks are not formally managed.

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

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

The Project Health Scorecard Part 5 – Resources

Professor of Project Management Project Execution and Monitoring ,

Executing Monitoring and Controlling

Here is the suggested guidance for the status of the Project Resource Health:

Your Resource Health is Green if ALL of these are true:

  • Stakeholders are attending required meetings
  • Resources are meeting their commitments
  • The team matches the skill-sets defined in the project roles matrix

Your Resource Health is Yellow if ANY of these are true:

  • Stakeholders are not always attending required meetings
  • Stakeholders are not always meeting their commitments
  • Some parts of the team do not match the skill-sets defined in the project roles matrix.

Your Resource Health is Red if ANY of these are true:

  • Stakeholders are not defined
  • Stakeholders are consistently not attending required meetings
  • Resources are not meeting their commitments
  • Critical parts of the team do not match the skill-sets defined in the project roles matrix

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

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