Risk Management is not a difficult task, but does require foresight. Sainath discusses identifying potential risks and charting an action plan to manage risks.
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:
- 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