Project Risk Management Plan | Project Risks Identification & How to Overcome

Risk is one of the few certainties of life. It may concern future happenings. They may be the risks that a software projects may undergo and cause planning to be in jeopardy. It may involve changes concerning the project. This may be change in customer requirements, change in development environment and technologies, change in opinions and actions of leading team members.

Risk involves choice and the uncertainty that is tagged with choice. These choices may be regarding development tools and methods, the resources and the quality standards adopted. Risk thus includes a combination of uncertainty, changes and choice. Risk can be defined as the event or circumstances which is a threat to execution of project.

 

Identifying risk and doing assessment and analysis help software team to understand and prevent potential problems and mitigate the degree of risk in software projects to a large extent. In this process, all the resources from software team including managers should be involved. Identifying risks beforehand by team will help either to avoid or manage them effectively.

 

Unmanaged risk is one of the main causes of project failure. Once the risks or what can go wrong is identified they can be ranked by the probability or likelihood of occurrence and impact. A Risk Mitigation, Monitoring and Management Plan (RMMM) can be developed to ensure that the high risks in the list are tackled and contingency planning is done.

 

In the words of Peter Drucker, ‘While it is futile to try to eliminate risk and questionable to try to minimize, it is essential that the risks taken be the right risks’. Two main risks strategies are Reactive and Proactive. Majority of software teams rely on reactive risk strategies.

 

This strategy monitors a project for risks and assigns resources to deal with them when the risks turn into problems. The team moves to fire fighting mode to correct the problem. When this happens and the problem is unresolved the project is in chaos. The more superior strategy is the proactive one, where the potential risks are identified, assessed and ranked. The contingency plan developed enables the team to respond with controlled and effective measures.

 

It is important to quantify the degree of uncertainty and loss associated with risks. For this, risks can be categorized as Project risks, Technical Risks and Market Risks. Project Risks are associated with budget, schedule, personnel, customer etc and their impact on projects delivery. Technical risks are risks associated with the design, implementation, interfaces, obsolescence and ambiguity in specification etc. Business risk is associated with the market, understanding of product, losing senior management support or focus, or budgetary requirements not met etc. All these categorizations have generic and product specific risks attached to it.

 

Risk identification is a systematic approach to specify the threats in a project. One way of doing is by a risk item checklist. This checklist can attempt to focus on predictable risks in categories such as size of the product, business impact, customer requirements, process that is adopted, environment used for development and testing, the complexity of system and knowledge and experience of the staff. The checklist can have relevant questions and answers to help planner determine the impact.

 

Assessing overall project risk can be done by proposed check list such as [SEI93], [KAR96], [KEI98] where questions have been derived from risk data obtained by surveys conducted on project managers in different countries. In any of the question has a negative answer the manager should initiate mitigations steps.

 

One such method is the guidelines given for software risk identification and abatement by the US Air force [AFC88]. In this approach the Project Manager should identify the risk drivers that affect the risk components which are Performance, Cost, Support and Schedule. The impact of each of this driver on the component is categorized as catastrophic, critical, marginal and negligible. The category versus component matrix has a characterization of potential consequences described. The impact category is decided based on characterization that best fits the scenario.

 

Risk projection or estimation attempts to rate risk based on the probability of risk occurrence and the consequence of the problem arising with the risk. A project team can list all risks no matter how remote, the probability of occurrence, probability value for each risk and the impact of each risk. The list is sorted by probability and impact.

 

A cutoff is determined to pinpoint risks that require detailed attention. Risk mitigation, monitoring or management plan should be developed for risks falling within cutoff. Three factors that affect the consequences of occurrences of risk are the nature of risk, its scope and timing.

The overall risk exposure RE is determined by

RE = P X C
where P is the Probability of occurrence and C is the cost incurred if risk occurs.

Risk Exposure needs to be computed for each risk and cost estimated. The total of risk exposure for all relevant risks can be used to adjust the cost estimate of the project. Risks should be re evaluated periodically during the course of the project life cycle as its probability and impact may keep changing.

 

Risk assessment can be computed in the form [CHA89] : [rj,lj,xj] where rj is the risk, lj is the likelihood of the risk and xj is the impact of risk. For the assessment to be useful a risk referent level must be defined. This may be represented by risk components such as performance, cost, support and schedule.

 

In software risk analysis a risk referent level has a single referent point or break point at which the decision has to be made to proceed with the project or terminate it. During risk assessment we define the risk referent level, attempt to develop a relationship between each [rj,lj,xj] and each of the referent level, predict the referent points and try to predict how compound combination of risks affects referent points.

 

In continuing Risk Management three basic processes are, monitoring identified risks, monitoring identified assumption and identifying new risks. Incorporating disciplined risk analysis, assessment techniques increases the quality of software being produced by minimizing or eradicating risks. Thus risk management, in concept referring to making decisions based on evaluation of factors that prove as a threat is critical for the overall success of a project.