Examples of positive and negative risks in project management

Getta Byte Software

· How should the risks be prioritized?

· Who should do the prioritization of the project risks?

· How should project risks be monitored and controlled?

· Who should develop risk responses and contingency plans?

· Who should own these responses and plans?

Introduction

This week, we will explore risk management. Risk management is one of those areas in project management that separates good project managers from great project managers. A good project manager makes risk management an integral part of every phase of project work. Risks are identified, prioritized, and understood. There are clear responsibilities within the team as to whose is responsible for implementing a risk response to reduce the impact should it occur. So let's get started.

What is Risk?

*Risk: An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.

Risks can be positive, meaning beneficial to the project, or they can be negative, meaning detrimental to the project.

Many students have a difficult time visualizing positive risks. A positive risk is an opportunity that may increase the probability of success, the return on investment, or the benefits of the project. They may also be ways to reduce project costs or ways to complete the project early. There may even be methods to improve project quality or overall performance. These are all examples of positive risks.

A negative risk can be easier to understand. It is the possibility that something will go wrong, a threat to the success of the project. It is important to remember that a risk is a possibility, not a fact. It is a potential problem. At GettaByte Software, there is the potential that a power outage would occur during data transfer. The potential exists that a key resource could become unavailable due to some unforeseen circumstance, like illness. Those are threats to the success of the project.

When buying a house to renovate, there are potential risks with respect to plumbing, wiring, the foundation, and so on.

A project manager needs to consider trying to make positive risks happen while trying to prevent negative ones from occurring. To do this, a project manager can take a proactive approach to risk management. This means he or she plans a risk response should it look as though the risk will become a reality. In this way, everyone knows exactly how to prepare and respond to the risk once it does become an issue.

The Risk Management Process

A project has both good and bad risks, which are referred to as positive and negative risks or opportunities and threats. For positive risks or opportunities, the project manager can choose from a range of risk responses. For threats, a project manager has a similar range of choices. The following, as described in the PMBOK® Guide, are the risk management processes.

Plan Risk Management:

· Risk Strategy

· Defines the general approach to managing risk on the project

· Methodology

· Defines the specific, tools, approaches, organizational considerations, data, and measurements that will be used to perform risk management

· Roles and Responsibilities

· Identifies potential risk owners and defines risk owner responsibilities

· Budget (Funding)

· Allocates specific funds for risk management

· Schedule (Timing)

· Defines when and how often risk management processes will be performed during the project so risk management activities become part of the project schedule

· Risk Categories

· Defines the general categories of risks that could occur during this project into a hierarchical representation of potential sources of risk—a risk breakdown structure (RBS)

· Stakeholder Risk Tolerance

· Defines and measures risk thresholds for each project objective, determining the acceptable level of overall project risk exposure

· Definitions of Risk Probability and Impact

· Define levels of risk probability and impact to create consistency in qualitative risk analysis

Identify Risks

· Data Gathering

· Identify risks using brainstorming, checklists, interviews, or review of similar projects. Identifying risks is an iterative process throughout the life of the project. Time for risk identification should be part of every status meeting or update.

· Data Analysis

· Use tools such as SWOT analysis, root cause analysis, and others to identify additional risks.

· Risk Register

· Create a categorized risk register, including the list of identified risks, potential risk owners, and risk responses. The register is updated throughout the course of the project. Here is a look at the risk register you will be using for your project.

Risk Register

Perform Qualitative Risk Analysis

During this process, each risk is evaluated for impact and probability. Impacts and probabilities are listed on a scale of either one to three (low, medium, high), or one to five (very low, low, medium, high, very high). Shown below is a 5 by 5 impact probability matrix used to visualize risk. It is an example of a very high to very low scale matrix. Each risk is rated based on its impact and probability and given a color code. Therefore, looking at the impact (very low to very high) and comparing it on the matrix to the risk's probability (very low to very high) provides a color risk ranking for a given risk. Red risks usually require a proactive response, yellow risks monitoring and a possible contingency plan, and green risks are placed on a watchlist because they are too low in impact or probability to require an action plan. It is important to realize that risks can change in impact and probability throughout the course of the project

5 X 5 Impact and Probability Matrix

Perform Quantative Risk Analysis

This is the process of analyzing the cumulative effect of identified risks and other sources of uncertainty on project objectives. It quantifies overall project risk exposure and informs strategic decision making regarding the project. It is not required for every project. Accurate data is required so that simulations, sensitivity analyses, and decision tree analyses can be perfored.

Plan Risk Response

Once the project risks are analyzed, consider risk response strategies and plans. There are a range of potential types of responses to both opportunities and threats.

Positive Risk or Opportunity Responses:
· Exploit

· Exploitation involves making sure that the positive risk become a reality. Tasks are added to the WBS to cause the risk outcome.

· Enhance

· Enhance means just that: enhance the probability of the risk occurring or its impact should it occur.

· Share

· Partner with another party to help ensure that the risk occurs. The benefits of the opportunity are then shared.

· Acceptance

· Acceptance can be passive or active. Active acceptance means that although no proactive action is taken to increase the likelihood that the risk will occur, a contingency plan is created. If the risk becomes a reality, the project team will be ready to take advantage of it. Passive acceptance means that nothing proactive or reactive is done concerning this risk, usually applied to green risks on the risk register.

Negative Risk or Threat Responses:
· Avoid: Avoiding a negative risk means preventing it from happening in the first place. It can be accomplished by evaluating the work or tasks that lead to the risk occurring and taking specific action to make the risk impossible.

· Mitigate: Mitigating a risk or threat means reducing the impact or the probability of the risk. When practicing risk management in the real world, stakeholders often discuss mitigation as if it were the only method to address project risk. It's important to help them realize that it is only one type of response.

· Transfer: Transferring a risk means to shift the responsibility for that risk to a third party. It is accomplished by buying insurance or hiring contractors to do the work.

· Acceptance: Acceptance can be passive or active. Active acceptance means that although no proactive action is taken to increase the likelihood that the risk will occur, a contingency plan is created. If the risk become a reality, the project team will be ready to take advantage of it. Passive acceptance means that nothing proactive or reactive is done concerning this risk, usually applied to green risks on the risk register.

Implement Risk Responses

This process involves the execution of the planned risk responses to risks that have occurred. Reviewing what was planned for the risks and what was carried out to handle the risks allows the project team to determine how well the project risks were planned and provides information that will help in future project risk responses

Monitor Risks

In this final process, the project manager monitors risks to make sure that the team has a clear plan when a risk becomes an issue. Further, the project manager continues to the maintenance of the risk register throughout the work of the project. Risk management must be a integral part of all status meetings as well as communications with stakeholders.

Contingency Reserves
According to the PMBOK® Guide - Sixth edition, a contingency fund or reserve is time or money allocated in the schedule or budget for known risks with active response strategies. The management reserve is a fund allocated to cover unknown and unforeseen events that require additional work to accomplish the project scope. Although in many organizations, contingency reserves are calculated as a fixed percentage of the project budget, it is best practice to evaluate overall project risk and fund it accordingly.

Getta Byte Software Risk Management
The team at Getta Byte has to create a risk management plan for the Getta Bill project. Let's visit with them and see how it is going.

Transcript:

Getta Byte Software

Risk Management

We need a risk management plan for our project.

We are meeting to brainstorm what the risks could be.

I don't like talking about risks. It makes them come true.

No, it doesn't. It helps us decide what to do if something goes wrong.

Network capacity could be a problem during data transfer.

Great start! Let me get it into the risk register.

Let's think about a possible response to avoid, mitigate, transfer, or accept these risks.

We still need to do qualitative analysis to decide probability and impact.

Not today, my brain hurts.

The end

Risk Management in an Agile Project
In a traditional project, risk management is conducted throughout the life of the project. New risks may emerge at any time. The impact and probability of risks can change. Therefore, the project manager has to be vigilant through every phase of the project.

In agile projects, risk management is very similar; however, it is more emergent. Beginning from the product backlog and as iterations are planned, risks are identified. Risk responses are the same and the requirement for a risk owner is the same as well. However, the gap between risk identification and the need for a response is much shorter as risks emerge during iterations. Risks are highlighted during daily stand-ups, retrospectives, reviews, and demos. Rapid and decisive action is required.

Practitioner's Corner
As a project/program/portfolio manager and a risk management professional, I have encountered a great deal of resistance to discussing and managing risk in the field. Stakeholders are willing to spend a little bit of time identifying risk, less time in prioritizing them and even less time in selecting a risk response strategy. It's as though leadership and team members believe that discussing risks too much will make them come true. In fact, the opposite is true, when I have been able to persuade my stakeholders to participate in active risk management, some risks are completely avoided and the impact of others is substantially reduced. I have found that it is always true that without talking about risk, there are more costly issues that arise later in the project.

"Missed schedules and creeping requirements are not things that just happen to you once and then go away, never to appear again. Rather, they are part of the territory. We all know that. What's odd is that we don't plan our projects as if we knew it. Instead, we plan as if our past problems are locked in the past and will never rear their ugly heads again. Of course, you know that isn't a reasonable expectation." (Tom DeMarco, Waltzing with Bears: Managing Risk on Software Projects)