Effective Risk Management

Risk is an undesirable occurrence of an event that might have a negative impact on the project if it materializes. Since it has a negative impact, each and every risk identified has to be addressed accordingly (contingency plans). There has to be a preventive mechanism (mitigation) or process that if available needs to be identified. Risk Management is all about predicting the risks that could affect the project, chart out the mitigation plans and devise contingency plans to reduce the potential damage that they may cause, realize the materialization of the risk immediately and take corrective action, track such risks to closure.

Risk Management must be fully integrated into all phases of software development life cycle for the success of any project with more emphasis during the planning and definition phase. Risk Management is not a very difficult task but requires a lot of foresight. It is natural for any software project to face certain risks during its project life cycle.

A risk is an event that may or may not take place, but the impact of the same would be very adverse. Risks may have an impact on the following:

• Schedule
• Effort (and thereby cost)
• Quality of the product
• Scope of testing

Anticipating such risks is an essential part of the project management responsibilities. An effective risk management strategy would:

• Anticipate and identify the risks that might occur in the project life cycle
• Assess the probability of their occurrences
• Guesstimate the impact
• Establish mitigation and contingency plans

The Grand Plan
The challenge here is how to go about formulating Risk Management plan and put it to use efficiently. This can be tackled with ease with some role-play on the part of the managers. Those who want to manage risks effectively should put on different thinking hats for each of these activities.

The Astrologer's Cap–Predict the potential Risks
Risks should be identified at the beginning of the project and should be revisited on an on going basis throughout the project life cycle. Generally risks can pose threats in the following areas:

Schedule: Unrealistic schedules, exclusion of certain activities when chalking out a schedule etc. could be deterrents to project delivery on time. Unstable communication link can be considered as a probable risk if testing is carried out from a remote location.

Client: Ambiguous requirements definition, clarifications on issues not being readily available, frequent changes to the requirements etc. could cause chaos during project execution.

Human Resources: Non-availability of sufficient resources with the skill level expected in the project are not available; Attrition of resources–Appropriate training schedules must be planned for resources to balance the knowledge level to be at par with resources quitting. Underestimating the training effort may have an impact in the project delivery.

System Resources: Non-availability of /delay in procuring all critical computer resources either hardware and software tools or licenses for software will have an adverse impact.

Quality: Compound factors like lack of resources along with a tight delivery schedule and frequent changes to requirements will have an impact on the quality of the product tested.

The Scorer's Cap–Measure and Rank the Risks
Risk can be measured by the probability of its occurrence and the impact that it might cause, should it materialize. The measures of Low/Medium/High can be used based on probability of its occurrence. For example, if the likelihood of a risk materializing is high but the impact or the damage is low, then a Low priority can be assigned. On the other hand, if the probability of a risk is less and the impact on the project is more, then such a risk can be categorized as High risk and an appropriate strategy could be defined to mitigate the same. Use of prudence is advised while evaluating and prioritizing the risks.

The Alchemist's Cap–Find the panacea for the Risks identified
How best would you manage the project if any the risks identified actually take place?

A risk management plan should be devised with appropriate mitigation and contingency plans on having identified and measured the risks. Testing phase is one such mitigation plan as it prevents the risk of the defects from reaching the end customer.

Risk Mitigation should be aimed at minimizing the probability of occurrence of a risk. A Contingency Plan should be aimed at an action to be performed on the failure of the mitigation. There may be instances when the risk is so small that it might not require mitigation or a contingency plan. In such cases it is worth accepting the risk. A simple risk management plan should have the following defined for every risk that has been identified:

• Probability of occurrence
• Impact of Risk
• Severity–how critical is the failure
• Priority of Risk–the order in which they need to be addressed
• Mitigation Plan
• Contingency Plan
• Responsibility/Owner

The Tracker's Cap–Track the Risks
A well-devised management plan will lose its sanctity if the risks are not tracked throughout the life cycle of the project. It is imperative that the risks are frequently reviewed / revised during the project meetings. The mitigation and contingency plans should be executed as soon as the risk is identified.

The risks should also be tracked to find out the damage caused on the factors that were anticipated earlier and to evaluate the effectiveness of the remedial measures. A simple excel sheet can be maintained for tracking the risks encountered in the project with the following information recorded:

• Risk Materialized
• Date on which the risk materialized
• Impact it caused
• Escalation procedure followed
• Corrective action taken to overcome the risk
• Status of the risk
• Date on which it was Closed/Resolved

A feather in your cap!
A well-defined Risk Management plan identifying the risks, prioritizing them and defining mitigation/contingency plans will ensure that the course of action is readily available if risks are encountered and thereby reduce the panic and chaos. Being forearmed is a battle half won. If you have appropriate tools in place for handling risks when encountered, it would translate into successful project execution. So, hurry up…keep the different thinking caps ready!