The goal of project risk management should include establishing the objectives to increase chances and impact of positive risks occurring while simultaneously decreasing the chances or impact of negative risks occurring. Risk avoidance is a risk response strategy to eliminate such risk from affecting the project.
Risk avoidance would considered if a project is running the risk of being in jeopardy. Risk avoidance may involve making changes to certain aspects of the project or changing the objective in order to eliminate the threat or reduce the problem as close to zero as possible.
Avoid Risk PMBOK Definition
Risk avoidance is when the project team acts to eliminate the threat or protect the project from its impact. This approach is vital to exposing risks that could lead to loss for throughout a project.
PMBOK®, 6th edition, ch. 11.5.2.4 STRATEGIES FOR THREATS
Avoid Risk in Project Management
Project Risk Management includes the processes of conducting risk management planning, dentification, analysis, response planning ie. avoid risk, response implementation, and monitoring risk on a project. (PMBOK®, 6th edition, ch. 11).
Project managers and leaders utilize best practices in risk management in similar ways that they would in any other project. (i.e., marketing, sales, development, operations). In software development, there are four best practices to implement when it comes to completing a project:
When navigating through these best practices, it is beneficial to start with tackling the bigger risks and working towards the smaller ones. Identifying the high level risks is imperative before navigating to the micro-level risks that are unique to your particular project.
How to Avoid Risk Examples
Avoidance may involve changing some aspect of the project risk management plan or changing the objective that is in jeopardy in order to eliminate the threat entirely, reducing its probability of occurrence to zero. Something to consider is that if there is a particular method for executing your project that will lead to a result that will cause significant harm within your project, it is beneficial that you avoid that method completely.
The success of a software development project is contingent on the amount of risk that corresponds to each project and the team’s ability to respond to the risk. This allows for the chances of a project’s success to be optimized.
Risk Avoidance vs Risk Reduction (Mitigation)
In risk mitigation, action is taken to reduce the probability of occurrence and/or impact of a threat (PMBOK®, 6th edition, ch. 11.5.2.4). Being proactive to mitigating a problem early has shown to be more effective than seeking to repair damages within a project after a problem has already occurred.
Reducing risk within a project would involve implementing a simple process in comparison to a complex one, executing more tests, or choosing to execute a system with a process that is known to be more stable.
Mitigation may involve prototype development to reduce the risk of scaling up from a bench-scale model of a process or product. In places where it may not be possible to reduce the chances of risk, a response for mitigation may allow for the amount of impact to be reduced through targeting factors that contribute to the severity of a problem. For example, a repetitive coding within software may reduce the impact of a failure of the original component.
How to Transfer Risk vs Avoid Risk
If there is a potential for a devastating problem occurring within a project, the best option for your team would be to share the responsibility of the risk. Transferring risk entails taking ownership of a problem and moving it to a third party to handle the risk and deal with the impact of the problem if the it occurs (PMBOK®, 6th edition, ch. 11.5.2.4).
The ability to transfer risk transfer will often require payment of some sort in the form of a risk premium to the party that will be handling the problem. Traditional forms of transferring risk would include utilizing insurance, performance bonds, warranties, guarantees, etc.
In software development specifically, it may also include shifting the accountability to stakeholders. Even if the probability of the risk occurring may not necessarily high, the fact that the probability exists allows for the transfer to be safest for your team.
How to Accept Risk vs Avoid Risk
Every project will have unavoidable risks that come as a part of the process. Sometimes these risk can be beneficial in the long run and therefore becomes necessary. Risk acceptance acknowledges the existence of a threat, but no proactive action is taken.
This method may be ideal for low-priority threats, and it may also be implemented where it is not possible or cost-effective to address a threat in any other way (PMBOK®, 6th edition, ch. 11.5.2.4).
The primary goal when it comes to accepting risk is to consistently monitory the risk and adjust your management plan in the event of changes. An example of accepting risk within software development would come by the team moving from developing new updates to older software.
There may be some risk related to the reception of stakeholders for the short term, but it is a necessary risk to create progress for a product to have better features.
There are active and passive ways of acceptance. A method for active acceptance is establishing a contingency reserve that would include time, money, or resources to utilize in the event that the threat occurs. Passive acceptance doesn’t involve proactive actions outside of the occasional evaluation of the problem to ensure that it does not have significant change.
Residual Risks vs Inherent Risks
- Inherent risk represents the amount of risk that exists before any action has been taken to make changes to the risk level.
- Residual risk are risks that still remain after all of the risk responses have been implemented (PMBOK®, 6th edition, ch.11.5.3.3)
Inherent Risk
Inherent risks generally lead to significant problems because it means there is absolutely no method for responding to or avoiding the risk. Some examples of inherent risks would be developing a website without any security protection against viruses or any methods of keeping data that is meant to be confidential safe.
Residual Risk
The work towards residual risk, which also known as control risks, will be contingent on your teams ability to navigate through the problem. If the risk is below a level that is deemed acceptable, your team may not feel the need to do anything but accept it. But if the level is above what is manageable to accept, your team will need to discover another way to reduce the risks, which would require reassessing the residual risk once new responses are put into place.