Assessing Risk in the Real World

Thanks for sharing Ramiro.

I am not familiar with all of the risk response strategies you mentioned. Are you citing a source other than PMBOK?

I've copied the below from the book "Bullet Dodging - A Risk Management Handbook for ICT Projects", which is inline with PMBOK 6th edition.

7.6 Risk Response Plans for Negative Risks (Threats)
PMBOK recognizes five generic ways of treating risk for negative risks (i.e., threats). The risk response plan options are described below:

7.6.1 Escalate
PMBOK 6th edition has introduced the concept of escalating risks. If the threat is outside the scope of the project, or if the risk response plan would be beyond the PMs authority, then consider escalating the risk. Such threats should be managed at a level above the project (i.e., program, portfolio, or otherwise, as appropriate).
The PM should manage the notifications and communicate the escalation as appropriate. Obviously, people need to accept the risk if you escalate to them, so any escalation of risk should be a collaborative process. Record escalated threats in the risk register but dont manage them at the project level any longer.

7.6.2 Avoid
Evade risk completely by removing the cause of the risk or by changing the project planning or scope so that the risk no longer exists. This type of response plan is typically reserved for high priority risks, usually threats with both a high probability of occurring and a high impact.
Removing the threat from the scope of the project enables you to completely remove the probability of the risk occurring.
Examples of actions that project managers may take to avoid particular threats include
" Isolate the project objectives from the risks impact
" Removing the cause of a threat
" Extending the schedule
" Changing the project strategy
" Reducing scope
" Clarifying requirements
" Obtaining more information
" Improving communications
" Acquiring expertise

7.6.3 Transfer
Transfer risk entails shifting the responsibility for the risk to a third party. The risk still exists, but the responsibility rests elsewhere. If the risk occurs, the impact will be felt by the third party.
Third parties who agree to manage the risk and bear the brunt of the impact if they occur, only do so at a price. There is a premium that the project will have to pay if they want to transfer the risk.
Examples of types of transfer of risk include but are not limited to
" Insure against the risk
" Issue or acquire performance bonds
" Negotiate warranties/guarantees and
" Enter into third-party agreements
It is rare that you can transfer all the inherent risk. When you use the transfer risk response, there is usually a residual and/or secondary risk that remains. If you have transferred a risk and you dont have a residual and/or secondary risk, it is worth revisiting the risk to check that you havent missed a lingering uncertainty.

7.6.4 Mitigate
Define the action you are going to take to reduce the probability and/or reduce the impact of the risk being realized. Mitigating risks early in the project is often easier and less expensive than dealing with a risk after it has occurred. Mitigation is the most often employed risk response strategy in ICT projects.
Examples of actions that we can take to mitigate risks include but are not limited to
" Develop a prototype
" Target factors that increase the severity of the impact
" Target factors that increase the probability
" Designing redundancies into systems

7.6.5 Accept
Do nothing active to treat the risk. Take no immediate action on the risk; the risk is to remain on the risk register and include it in the monitor and review process.
There are two types of accept risk response plans: passive acceptance and active acceptance.
Passive acceptance of a risk requires no action beyond documenting the decision.
Active acceptance involves some further action. Actions could include, but are not limited to, one of the points below or any combination of the three.
" Setting aside some contingency reserves to offset the effect of the risk
" Producing a contingency plan
" Producing a fallback plan to enact if the risk is realized

7.7 Risk Response Plans for Positive Risks (Opportunities)
The risk response plans for opportunities are similar but distinct from the risk response plans for threats.

7.7.1 Escalate
PMBOK 6th edition has introduced the concept of escalating risks.
Opportunities that are outside of the scope of the project and/or outside of the PMs authority can be escalated up to a level above the project. Escalate them to be managed at the program or portfolio level or to some other level specific to your organization.
Escalate them to the level that would be affected if the opportunity occurred. The PM manages the notifications and communicates the escalation as appropriate.
Obviously, the person you escalate the opportunity to needs to accept the opportunity, so any escalation should be a collaborative process. Record escalated opportunities in the risk register but dont manage them at the project level any longer.

7.7.2 Exploit
High priority opportunities that the organization wants to ensure that they reap the benefits of can be addressed with the exploit risk response plan. Exploiting is the equivalent/inverse of the threat response avoid. As avoid seeks to reduce the probability of a threat to 0%, exploit seeks to increase the probability of an opportunity to 100%.
Examples of exploit risk response plans include
" Assigning an organizations most talented resources to the project to help reduce the schedule
" Using new technologies to reduce costs and duration
" Using technology upgrades to reduce costs and duration

7.7.3 Share
Sharing involves transferring some of the opportunity risk to a third party. If the risk occurs, the positive risk will benefit both parties. Sharing opportunities is the equivalent/inverse of transfer for threats.
The sharing risk response plan can be a great way of improving your likelihood of achieving the associated benefits. This can be especially true if the third party that you are sharing with has something that you dont have. They might have the capability, capacity, knowledge, or resources that would enhance the probability of the opportunity occurring or that would improve the benefits that you could achieve through the opportunity.
Third parties are unlikely to take on uncertainty for free. They will want a risk premium that the project will have to pay if they want to share the opportunity. Or, they may insist on favorable terms of the sharing agreement such that they receive the lions share of the benefits.
Examples of types of share risk response plans include but are not limited to
" Forming risk-sharing partnerships
" Creating special-purpose companies
" Entering into joint ventures

7.7.4 Enhance
Enhance entails defining the actions you are going to take to increase the probability and/or increase the impact of the opportunity being realized. Enhance for opportunities is the equivalent/inverse of mitigate for threats.
Examples of actions that we can take to mitigate risks include but are not limited to
" Assigning more qualified resources to the project
" Upgrading technologies to reduce costs and duration
" Developing a prototype
" Targeting factors that increase the severity of the impact
" Designing redundancies into systems

7.7.5 Accept
Take no active action. Take no immediate action regarding the opportunity. Leave the opportunity on the risk register and include it in the monitor and review process. This strategy might be the most appropriate when the opportunity is insignificant or if the cost/benefit ratio is not high enough to justify action.
Note: Passive acceptance of an opportunity requires no action beyond documenting the decision. Active acceptance involves some further action, either setting aside some contingency reserve of time, money and/or resources to take advantage of the opportunity should it be realized.

Posted: Jun 2, 2021 1:15 AM