Once by using different Risk Identification techniques as
described in previous article, we have identified all the possible risk in the project life cycle, Please see First Step in Risk Analysis – Techniques for Identifying Risks, The next phases in Risk Analysis post risk Identification
phase in order of their occurrence are as follows:
- Use Organisation level risk Management Template or use Risk breakdown sheet. – Most of the organisation has templates defined for Risk Analysis. It makes no sense to reinvent the wheel. Some of key data that we need to store for each risk are defined as below:
a. Risk Definition – This explains what the risk
is.
b. Root Cause – We need to analyze what is the root
cause of the risk. Analyzing risk root cause help to identify where problem and
it is highly possible that more than one risk have the same root cause. So
countering the root cause using control can help solve multiple goals in one
go.
c. Risk Categorization – Categorization risk is
important to group risk. Risk can be classified broadly into three categories,
Technical, Internal or External risk. Classifying Risk into categories helps to
get proper input from the experts or specific team. For this risks can also be
sub-categorized. E.g.: Risk can be related to Infrastructure team or Legal
team, So we get input and control actions from the expert group in one go, and
helps to get proper inputs from the required team or individual.
d. Once we have root cause, categorization, and
risk definition. We need to provide the control action on how to avoid or
reduce the impact of risk.
e. When we define risk, the probability of happening
of a risk can vary from project to project. Probability of risk occurrence needs
to be understood and provide in the template
f. Similar to Probability, Impact of risk is very
important. Even a low probability risk can be highly critical in case its
business impact is very high. Control action is must, and should be well thought
of as it can affect business
.
g. We also need to identify in which phase risk
can turn into a loss. E.g. : Assumption which are also risk should be resolved
in requirement Phase and so on. Response of risk events occurring early in the project
should be handled first and detailed risk mitigation plan developed for the
same.
h. Risk should be quantitatively analyzed
especially with high impact, high probability, or both to generate statically
cleaner data for risk occurrence and its impact. Decision tree, distribution
models, and tornado diagrams are some example of the same.
i. Define the expected monetary value of the risk
converting to loss taking into consideration both impact and probability
j. Next Step is to assign risk to required
stakeholders. We can break the document into high to medium priority risk and
low and trivial priority risks in another document. So that major focus is not
diverted on low and trivial priority risks.
k. Once we get the response, we need to maintain
the template document used with the responses and response provider to clarify
with the Risk Owner.
- Once we have created the template, we still require regular risk meeting and risk monitoring in process, so as to add any new risk identified during the project life cycle and also to track how we are faring with the risk identified