Plan Risk Management / Techniques

2.4.1T Plan Risk Management / Techniques

Use One of Five Strategies for the Risk Response (2.4.1T.P1)

You should create a risk response for all “high” risks. There are a number of options that the project manager should consider for responses.

Leave it. In this approach, the project manager looks at a high risk and decides to do nothing. This can happen for one of two reasons.

The project manager may feel that the risk should be managed, but that the cost and effort of managing the risk is more than the impact of the risk event itself. In this case you would rather deal with the costs of the risk occurring that the cost of trying to manage the risk. The risk event has some probability of occurrence, which means that it is possible the event will not happen anyway.

There may not be any reasonable and practical activities available to manage the risk. This is different from the prior reason where the cost was more than the benefit. In this case, there is no practical way to manage the risk, even if the risk has been identified as high. For instance, it is possible that there is a risk of your sponsor leaving and a new sponsor canceling the project. In fact, you may know that the sponsor is up for a promotion and that this scenario has some possibility of occurring. However, you may not be in a position to do much about it as long as the current sponsor is in place, and you may just need to leave it and see how events play out.

Monitor the risk. In this case, the project manager does not proactively manage the risk, but monitors it to see whether it is more or less likely to occur as time goes on. If it looks more likely to occur, the team must formulate a different response at a later time. This is a good approach if you have identified a risk that should be managed, but the risk event is far off in the future. For instance, if your risk event is nine months in the future, it may not make sense to spend resources to manage the risk at this time. A better approach might be to monitor the risk on a monthly basis. It is possible that over time the risk will go away because of other circumstances. However, if it does not go away, the team will still need to manage the risk in the coming months.

Another reason to monitor the risk is if the risk probability is low. Rather than put a plan in place immediately, the project manager creates a plan only if it looks more likely that the risk will occur. The disadvantage in this approach is that the delay in addressing the risk might make it less likely that the risk can be successfully managed in the future.

Avoid the risk. Avoiding the risk means that the condition that is causing the problem is eliminated. For example, if you find that a part of the project has high risk associated with it, that whole part of the project can be eliminated. The risks associated with a particular vendor, for instance, might be avoided if another vendor is used instead. This is a very effective way to eliminate risks but obviously can be used only in certain unique circumstances. In another example, you may have a project risk associated with implementing a solution in multiple locations. Once the risk is identified, the sponsor may change the scope of the project to only implement in one location. In this way, the risk of implementing at multiple locations has been avoided.
Move the risk. In some instances, the responsibility for managing a risk can be removed from the project by assigning the risk to another entity or third party. For instance, you may identify a risk associated with a new technology. Outsourcing the function to a third party might eliminate that risk for the project team. The risk event is still there, but now some other entity is dealing with it. The third party might have particular expertise that allows them to do the work without the risk. Even if the risk is still present, it now is up to another party to resolve.

Another example of moving the risk is buying insurance. In a simple example, you may have a very fragile and valuable piece of equipment that needs to be shipped to your project team. There is some risk that the material will be damaged. You might move the financial risk by purchasing insurance on the shipment. Of course, if the shipment is damaged, you may still lose time waiting for a replacement part to be shipped. However, you no longer have the financial risk. In exchange for an insurance premium payment, the insurer now has the financial risk.

Mitigate the risk. In most cases, this is the approach to take. Mitigating the risk means that you put in place a set of proactive steps to ensure that the risk does not occur. Another purpose of mitigation is to ensure that if the risk occurs, the negative impact of the risk is minimized. In many cases it may not be possible to totally eliminate a risk event, but given that you have time to prepare, you should be able to minimize the probability of the event occurring, or minimize the impact to the project if the risk event does occur. (For the purposes of the TenStep Project Management Process, it is generally assumed that Risk Management Plans are put in place to mitigate the risk.)

Think of Positive Risk as a Way Gain Benefit (2.4.1T.P2)

Risk is usually associated with potential events that have a negative impact on the project. However, there is also a concept of opportunity risk or positive risk. In these instances, the project manager or project team may introduce risk to try to gain a benefit. For instance, a team may decide to utilize a new technology on its project because they think it will result in dramatic effort and cost savings. Of course, there is also a chance the new technology will not work. However, the team introduces the risk because the potential for gain. This is an example of intelligent risk taking or positive risk. See 2.4.4T Positive Risk for more details.

(Note: the TenStep Project Management Process assumes that the risks you are managing are negative risks. These risks need to be addressed so that the underlying potential problem does not occur.)

Make Sure Your Risks Must Have Some Level of Uncertainty (2.4.1T.P3)

If an event is identified as a risk, there has to be some level of uncertainty involved. In other words, if an event has a zero percent likelihood of occurring, it would not make sense to identify it as a risk. It is not even a low risk. It is not a risk at all. On the other hand, if an event is 100% certain to occur, it is also not a risk. It is not even a high risk. It is a fact. (Sometimes these 100% “risk” events are also called constraints. A constraint is an event or limitation that impacts your project and must be planned around. For instance, you may not be able to get a resource you need until 30 days after the project starts. This is a constraint, not a risk. This constraint may cause a scheduling risk, but the constraint itself is not a risk.)

A risk has some probability between 0% and 100% chance of occurring. If an event has a zero percent chance of occurring, it should be ignored. If it has a 100% chance of occurring, it is a fact (and perhaps a constraint). When you are managing risks, be sure to focus on the risks and not on facts and fictions.

Distinguish Between Risks, Causes and Effects (2.4.1T.P4)

There is a cause for every risk and an effect if the risk occurs. When the project risks are identified, make sure that the risk itself is noted and not the cause or effect of the risk. The cause is a situation that exists that sets up a potential risk. In general, the cause is a fact or a certainty for the project. On the other hand, the effect is the likely outcome if the risk occurs.

Look at the following example. Let’s say that a project solution needs to be implemented in all of a company's worldwide locations, including those in developing countries. If the telecommunications lines are not upgraded on time where necessary, the solution will not be viable in those locations.

In the previous example, what is the risk?

Is it a risk that you have to implement the solution in developing countries? No, that is the cause. It is a fact or a requirement.
Is it a risk that the solution will not be available in certain countries? No, that is the potential effect of what might occur in this scenario.
Is it a risk that the necessary telecommunications upgrades are not performed on time? Yes, this is where the uncertainty lies.

Try to Include Budget and Schedule for Unknown Risks (2.4.1T.P5)

A project manager can request a risk contingency budget based on a qualitative risk analysis at the beginning of a project. However, risk identification is not something that only happens at the beginning of a project. The project manager needs to assess risks throughout the project. Therefore, it can make sense for medium to large projects to include time and budget for unknown risks as a part of your estimating process. This would especially make sense for projects that have a number of high-risk events. If you do an effective job of periodically reassessing risks, you may find new risks to manage that were not included in the original risk contingency budget. There is some industry evidence that a 5% contingency can be added to the project for dealing with risks that are unknown when the project starts. (Remember that the time to mitigate and manage known risks should be included in the original estimate.)

Include Team Members in Risk Identification (2.4.1T.P6)

If team members are familiar with the circumstances of the project, they can take an active role in identifying and evaluating project risks. Joint participation from the team can help identify project risks, lay out effective actions to manage the risk and provide consensus and buy-in for execution.

Weigh the Cost of the Risk Management Plan Against the Level of Risk (2.4.1T.P7)

All projects have some risk, and the activities associated with managing risks obviously have a cost. The project manager and clients should make sure that the effort and cost associated with managing the risks do not exceed the threat to the project if the risk occurs. For high risks, this is normally not the case. However, if you are managing medium risks, make sure that the costs and benefits associated with responding to the risk make sense for the project. If the cost of managing the risk is more than the risk impact to the project, it does not make sense to manage the risk in that manner. It is possible that if the cost of managing the risk is greater than the risk impact, you may choose to just leave the risk alone and allow.

Understand the Risk Tolerance Level in Your Organization (2.4.1T.P8)

All projects have risks and all risks have the potential for negatively impacting the project. You use risk management to determine the risks that are important enough to manage. During the risk identification process, you may encounter many risks that have some likelihood to occur and have a marginal impact to the project. The question to ask is whether the risk has enough impact on the project to worry about (this same question occurs for both qualitative and quantitative approaches). The answer says something about your risk tolerance.

For example, let’s say you identify a risk that is very likely to occur, but has an impact of $100 and one-half day duration. You may choose not to manage it. You cannot list this as an assumption since there is a good chance the risk will occur. However, the impact is small enough that you are willing to absorb the cost if it occurs, rather than deal with managing the risk (which would probably be more costly). Therefore you would choose a risk management strategy of leaving the risk.

In the prior example, the numbers were fairly trivial and the risk was easier to ignore. But, ratchet the impact up a little higher. Let’s say the risk now was $500 and one day duration. What about $100,000 and three months duration? Of course, the answers are all relative based on the size of the project. If your project had a $20,000 budget, a $1,000 risk impact might be worth managing. If your project budget is one million dollars, the risk impact of $1,000 would just be marginal.

When you are performing risk identification, you need to determine your tolerance level for risks. This will help you focus on the risks that are important and above your tolerance level, while ignoring risks where the impact falls below the tolerance level. Risk tolerance is also cultural in your organization. Some organizations are bigger risk-takers and will accept a higher level of risk on projects. They will also tend to have a higher threshold before they chose to manage a risk.

On the other hand, some organizations are more risk-averse. They will tend to accept less risky projects and they will also tend to have a lower threshold to manage risks. For example, let’s say you have a similar project in both organizations. The project managers in these risk-averse organizations will tend to manage risks that a project manager in the other organization might choose to leave.

Use Decision Trees to Analyze Multiple, Related Risks (2.4.1T.P9)

One way to calculate the financial results of an interdependency of risk on a project is to use a decision tree. A decision tree is a technique for determining the overall risk associated with a series of risks. Decision trees are a good technique when you have the following characteristics:

Risk probabilities of one risk are based on the results of a prior risk. That is, the risks are related.
There are a small number of probable results for each decision point – not a large number. If there are a large number of potential outcomes, this technique can be very complex.
There are monetary implications of the risk calculations.

Look at the following decision tree example.

This decision tree shows two risks. Risk A has two outcomes. Outcome 1 is 20% likely to occur and outcome 2 is 80% likely to occur. The monetary value of Risk A is $10,000. If outcome A occurs, a second Risk B is introduced and there are three likely outcomes, 1.1, 1.2 and 1.3. The monetary value of Risk B is $30,000. Using the decision tree, you see that the financial risks of the various outcomes are as follows:

1.1	$9,500	($10,000 * .2) + ($30,000 * .25)
1.2	$23,000	($10,000 * .2) + ($30,000 * .70)
1.3	$3,500	($10,000 * .2) + ($30,000 * .05).
2	$8,000	($10,000 * .8)

Your objective may still be to mitigate Risk A so that it does not occur. However if you are not able to successfully mitigate the risk, this analysis show you that you should try to achieve outcome 1.3 if possible. It has the smallest risk impact. If you don’t think you can achieve outcome 1.3, you should try for outcome 2. Even though the risk implication of outcome 2 is much larger than the risk implication of outcome 1, there is a second risk associated with outcome 1 and that Risk B has a 95% probability of pushing the total risk value higher still.