Thursday, July 31, 2008

Risk Response Planning Strategies

Shamsher Haider PMP

You’ve made your risk management plan, identified the risks and done quantitative analysis and qualitative risk analysis. Now how do you do your risk response planning?























For risk response planning you must have your risk register and your risk management plan at hand. You would be more interested in planning for high risks first of all and risk management plan comes handy for the situation because it has the threshold definitions for low, medium and high risks. Risk register, the most important artifact in risk management process contains the list of identified risks ranked and prioritized after qualitative and quantitative risk analysis.



The risk register will tell whether the risk under consideration is a threat or an opportunity. Yes a risk can be an opportunity as well! As defined by PMI, project risk is an uncertain event or condition that, if it occurs, has a positive or a negative effect on at least one project objective, such as time, cost, scope, or quality. The strategy for managing the risk under consideration will largely depend on its being a threat or an opportunity.



Strategies for Threats:

Avoid: This means staying clear of the risk altogether. While avoidance obviously is the best possible course, it might not be feasible in all circumstances, e.g. the impact of the cost of avoidance might dominate the benefits of avoiding the risk. Avoidance can be accomplished by changing the process or the resources to attain an objective or sometimes modifying the objective itself to avoid the risks involved. An example of avoiding risk could be avoiding use of untested third party components in the software design, or avoiding inclusion of an inexperienced resource in the project team.

Mitigate: This means trying to reduce the probability and/or impact of the risk. Reduction in probability of occurrence would reduce the likelihood of its occurrence and reduction in impact would imply a lesser loss if the risk event occurs. 100% mitigation would be equivalent to avoidance. An example of mitigation would be an early verification of the requirements by prototyping before moving on to full fledged development.

Transfer: This implies transferring the liability of risk to a third party. While this strategy does not eliminate or mitigate the risk or its consequences itself, it transfers the responsibility of its management to someone else. Insurance is a classical example of this strategy. By buying insurance you transfer your risk to the insurance company by paying the risk premium. Fixed Cost contract is yet another example of risk transfer strategy. In a fixed cost contract the risk is transferred to the seller.

Strategies for Opportunities:

Exploit: This strategy involves removing all uncertainties pertaining to a positive risk and making sure that the risk event occurs. An example could be a situation where the seller will pay an incentive fee if work is completed a week ahead of the completion deadline. Ordinarily there is a probability that the work might get completed earlier, but if we plan to exploit this situation, we will plan to complete the work a week ahead to turn this uncertainty into a certain event.

Enhance: This strategy involves planning for increasing the size of the opportunity by increasing its impact and /or the probability of its occurrence. Identification of the root cause of the presence of an opportunity can help focus on the root cause and enhance its impact and / or probability.

Share: This strategy involves sharing the fruits of an opportunity with a third party because you do not have the capability to exploit it alone. Suppose your competitor is set to launch a new product six months from now, and you identify the opportunity that by launching a product with similar features a month before your competitor’s launch you can wrest the market away. In this particular scenario the situation becomes complicated because you have all the resources to launch your product in five months except a portion requiring device driver and hardware level programming. You can launch a joint venture with another company specializing in device driver programming to share the opportunity

Strategy for Threats and Opportunities:

Accept: Sometimes we identify a risk but realize that time and / or resources required to formulate and enact response strategies overweigh the results of the effort. In such a case we just accept the risk. If we plan to face the occurrence as it is, it is called passive acceptance. On the other hand if we develop a contingency reserve to handle the situation if the risk occurs, we call it active acceptance.

Contingent Response Strategy:

Also known as contingency planning, this strategy involves development of alternatives to deal with the situation after the risk has occurred. Active acceptance of risks leads to contingency planning, whereby we anticipate a risk to occur and instead of trying to mitigate or eliminate its occurrence we plan what to do when the event occurs. Contingency reserves are a commonly used tool to handle the occurrence of a risk event. Contingency reserve can imply allocation of cash, time or resources to cope with the situation when the risk event has occurred.
Fallback plans can be developed for high impact risks. A fallback plan as the name suggests, is the backup plan, in case the original contingency plan doesn’t work out as planned. An example could be identification of risk that a certain .Net programmer will resign in middle of the project. Since under the current circumstances you can do nothing to mitigate or eliminate the risk you accept it but develop a contingency plan to hire a certain programmer on hourly wages. To cope with the situation if no programmer is available on hourly wages at the time of resignation of your programmer, you develop a fall back plan of temporarily moving a software engineer from a certain low priority project to work on the assignment till an alternative can be hired.

3 comments:

Thomas said...

Some of the tools in the project management software are applicable to several business models. They are the driving force that makes online Project Management Software successful. It's important to know everything associated with your project whether it is a logistical problem like supplies and money, or whether it is a time tracking issue.

robert said...

Ask yourself who was responsible for identifying and collecting project requirements and were they empowered and accountable? Were they the most appropriate people or just the most senior or worse still – self-appointed?

robert said...

The key is still doing the re-engineering process well and the application system will just a tool to follow the processes. I put some of my thoughts about Electric Management System in this blog. Feel free to read and comment. Project Management Software