Risk management activities of a project typically includes risk management planning, risk identification, qualitative and quantitative analysis of the risks, risk response planning and monitoring and control of the risks.
Risk register -
Risk register is the most used tool in the above processes starting with risk identification. One can build risk register in a simple excel sheet or it can be put as share point and web based tool. Contents of a risk register should be risk ID, risk description, risk category, risk identified date, cause of the risk, descriptive impact of the risk, risk probability, risk impact, risk score, risk priority, risk response, response owner, response action due date, current status, response impact and comment. These fields are populated in different stages of risk management processes.
Quantitative risk analysis –
Estimating probability and impact values of a risk is a key process in risk management process. This process is called quantitative risk analysis. Accuracy of this process impacts response planning, monitoring and control and overall project execution considerably. It’s better practice to put the guidelines in risk register template itself to avoid any confusion. These guidelines are designed in risk management planning process. Probability value will be always between 0.1 and 0.9. Often risk impacts are not tangible enough to be quantified in terms of EMV(Expected Monetary Value). Therefore, having quantitative risk impact value also between 0.1 and .9 is a good idea and general practice. Quantitative risk analysis is repeated many times during monitoring and control phase of the project and risk register is updated subsequently. A risk turns into issue or opportunity when its probability value becomes 1. Again, it’s a good practice to record risk action response impact during risk response planning as planned impact and response action effect after the risk has occurred as actual impact. We can document this impact in terms of %. This helps evaluating the risk response planning. Risk info which can’t be categorized into any field of the risk register should be added as comment in last. Once the risk turns into issue, it can be maintained or monitored separately as issue log or in the same risk register depending on the choice.
