The first phase in risk Analysis is identifying risks and
categorization of risks. There are three categories of risks associated with
software systems, Internal Risks, External Risks and Technical risks. Risk can
be broadly classified into these categories. Categorization of risk into
categories is known as Risk breakdown structure (RBS).
In this topic, we will discuss mainly on different risk
identification techniques. In the next articles, we will discuss on what are
the different types of risks.
Risk Identification Techniques:
The first step for a successful risk analysis is to identify
all risks in the system during the planning stage. It is important for whole
group to provide inputs in risk as individuals on specific stream are in better
position to provide on the possible risks and collating all information in a
RBS or specific template as used by Organisation for risk analysis. Every
possible risk should be identified during the initial phase irrespective of its
impact. Risk can be collected from team in following ways:
- Brainstorming – In this process, the group comprising of team members collects in a room and discusses on every possible risk in the presence of a facilitator who knows the risk processes. Users can discuss on different approaches, interviewing team members of group, including as much stakeholders as possible, discussing on lesson learnt and risks found in similar project in the past projects.
- Delphi Technique – In this process, same questionnaire is sent to multiple experts by the facilitator asking for their opinions on the probable risks in the project. Once inputs are received from the expert, the facilitator shares the information back to the experts asking for their opinions again on the risks. Facilitator shares the rationale provided by different experts to the same risk with the same group. The process is continued for 2-3 rounds, and usually experts come on similar page provided based on collective rationale provided by team. For success of Delphi technique, anonymity of experts is a must and should be kept even after risk identification process completion.
- Root Cause Analysis – Once we have the identified risk, we need to know what is the condition that will cause the risk to happen. This also provides the insight on condition that may trigger a risk and it is very much possible that root cause of multiple risks be one. Using fishbone or Ishikawa technique can be used to generate risk information and extract useful information diagrammatically from the risk.
- Interview the stakeholder – Together with internal team, client can also be interview what are the different risk they feel on the project. Interviewing different stakeholders bring different perspective on the same issue.
- Assumptions– For improper information in the project, we do make assumptions. Each of the assumption you make is a risk to the Project and we should have sign off as early as possible on the assumption we have made from client Perspective.
- Checklist Analysis – Analysis checklist of risk and discussing on the risk in checklist if the risk has been discussed, and a decision has been made. This ensures each of the risk in the system is analyzed, discussed and work upon.
- Lesson Learnt and documentation from past project – Risk identified should be documented in a document as previous documents and lesson learnt acts as an important sources of risk applicable in current work.
- Using SWOT – Creating a SWOT helps to identify the strength, weakness, Opportunities and Threats. Understanding Weaknesses and threats are an important source of risk identification