Risk Identification

Risk Identification
Risks are to be identified and dealt with as early as possible in the project. Risk identification is
done throughout the project life cycle, with special emphasis during the key milestones.
Risk identification is one of the key topics in the regular project status and reporting meetings.
Some risks may be readily apparent to the project team—known risks; others will take more rigor
to uncover, but are still predictable.
The medium for recording all identified risks throughout the project is the risk register, which is
stored in the central project server.
The following tools and guidelines are used to identify risks in a structured and disciplined way,
which ensures that no significant potential risk is overlooked.
1. Risk Sources
Exhibit 2 – Risk Sources
2. Risk Category
Risk category provides a list of areas that are prone to risk events. The organization
recommends high-level, standard categories, which have to be extended based on the project
type.
Exhibit 3 – Organization-Provided Standard Risk Categories
Risk Analysis
Risk analysis involves examining how project outcomes and objectives might change due to the
impact of the risk event.
Once the risks are identified, they are analysed to identify the qualitative and quantitative impact
of the risk on the project so that appropriate steps can be taken to mitigate them. The following
guidelines are used to analyse risks.
3. Probability of Risk Occurrence
a. High probability – (80 % ≤ x ≤ 100%)
b. Medium-high probability – (60 % ≤ x < 80%)
c. Medium-Low probability – (30 % ≤ x < 60%)
d. Low probability (0 % < x < 30%)
4. Risk Impact
a. High – Catastrophic (Rating A – 100)
b. Medium – Critical (Rating B – 50)
c. Low – Marginal (Rating C – 10)
As a guideline for Impact Classification the following matrix is used:
Exhibit 4 – Impact classification guideline

The score represents bottom thresholds for the classification of risks assuming “normal”
conditions. An upgrade of the score to the next or even next + 1 level is necessary, if the risk is
impacted by critical factors such as:
 How important the specific customer is

 Whether the project is critical for the further development of the relationship with the customer
 The risk is already in the focus of the customer
 Specific penalties for deviations from project targets are agreed in the contract with the
customer
5. Risk Exposure
Risk Exposure or Risk Score is the value determined by multiplying the Impact Rating with Risk
Probability as shown in Exhibit 5.
Exhibit 5 – Impact-Probability Matrix

The colours represent the urgency of risk response planning and determine reporting levels.
6. Risk Occurrence Timeframe
The timeframe in which this risk will have an impact is identified. This is classified into one of the
following:
Exhibit 6 – Risk occurrence timeframe

In addition to classifying risks according to the above guidelines, it is also necessary to describe
the impact on cost, schedule, scope, and quality in as much detail as possible based on the
nature of the risk.
7. Risk Classification Examples:

Exhibit 7 – Risk Classification Examples
Risk Response Planning
There may not be quick solutions to reduce or eliminate all the risks facing a project. Some risks
may need to be managed and reduced strategically over longer periods. Therefore, action plans
should be worked out to reduce these risks. These action plans should include:
 Risk description with risk assessment

 Description of the action to reduce the risk
 Owner of the risk action
 Committed completion date of the risk action
All risk action plans should be allotted to the person identified to carry out the action plan.
1. Risk Response Plans
For each risk, a risk response must be documented in the risk register in agreement with the
stakeholders. This should be ensured by the project manager.
Risk response plans are aimed at the following targets:
1. Eliminating the risk
2. Lowering the probability of risk occurrence
3. Lowering the impact of the risk on the project objectives

Risk response plans usually impact time and costs. It is therefore mandatory that the time and
cost for the defined response plan are calculated as precisely as possible. This also assists in
selecting a response plan from the alternatives, and in verifying whether the response plan is
costlier or has more impact on one of the project objectives than the risk itself.
After successfully implementing a set of response plans, the score of a risk could be lowered in
consultation with the stakeholders.
Examples:
Exhibit 8 – Risk response - Examples
2. Risk Triggers
For each risk a trigger must be documented in the risk register. The trigger identifies the risk
symptoms or warning signs. It indicates that a risk has occurred or is about to occur. The risk
trigger also gives an indication of when a certain risk is expected to occur.
Examples:
Exhibit 9 – Risk Trigger Examples
3. Risk Ownership
The ground rule is that responsibility for managing all risks in the project lies with the project
manager.
Based on this ground rule a Risk Owner (who is not necessarily the project manager) must be
determined and named in the Risk Register. The Risk Owner is normally the one who can best
monitor the risk trigger, but can also be the one who can best drive the defined
countermeasures. The Risk Owner is responsible for immediately reporting any changes in the
risk trigger status and for driving the defined countermeasures.
Examples:
Exhibit 10 – Risk Owner Examples
Risk Monitoring and Control
Risk monitoring and control includes:
 Identifying new risks and planning for them

 Keeping track of existing risks to check if:
 Reassessment of risks is necessary
 Any of risk conditions have been triggered
 Monitor any risks that could become more critical over time
 Tackle the remaining risks that require a longer-term, planned, and managed approach with
risk action plans
 Risk reclassification
For the risks that cannot be closed, the criticality has to go down over a period of time due to
implementing the action plan. If this is not the case then the action plan might not be effective
and should be re-examined.
 Risk reporting
The risk register is continuously updated, from risk identification through risk response planning
and status update during risk monitoring and control. This project risk register is the primary risk
reporting tool and is available in the central project server, which is accessible to all
stakeholders.
Risk monitoring and controlling or risk review is an iterative process that uses progress status
reports and deliverable status to monitor and control risks. This is enabled by various status
reports, such as quality reports, progress reports, follow-up reports, and so forth.
Risk Reviews are a mandatory item of milestone meetings and/or regular project meetings, but
they can also be executed during separately planned risk review meetings. These risk reviews
must be held regularly. The frequency could also be determined based on the overall risk level of
a project.
Risk Threshold
The risk priorities have to be set to direct focus where it is most critical. The risks with the highest
risk exposure rating are the highest priority.
Risks with Exposure Low can be dropped from the mitigation plans, but may need to be revisited
later in the project.
The organizational mandate is that if the projects have at least one “Very High” risk or more than
3 “High” risks, guidance should be sought from management and stakeholders, as the project
may be at high risk of failure. This is the recommended risk threshold. Projects can customize
the threshold based on project needs.
Risk Efficiency measurement
Risk Metrics
The efficiency of risk analysis and management is measured by capturing the following metrics
during project closure. The analysis results are used to decipher lessons learned, which is
updated in the organization's lessons learned database.
 Number of risks that occurred / Number of risks that were identified

 Was the impact of the risks as severe as originally thought?
 How many risks recurred?
 How do the actual problems and issues faced in a project differ from the anticipated risks?
Risk Audit
This is an independent expert analysis of risks, with recommendations to enhance maturity or

effectiveness of risk management in the organization. This evaluates:
 How good are we at identifying risk?

 Exhaustiveness and granularity of risks identified
 Effectiveness of mitigation or contingency plan
 Linkage of project risks to organizational risks
This is not a “process adherence” audit, but an aid to enhance the quality of risk identification
and risk analysis. This is also used as a forum to benchmark and identify good practices of risk
management among various projects in the organization.
The risk audit is done by a group of independent domain or technical experts through
documentation review and interviews. The key deliverables of this risk audit are:
 Customized checklist to evaluate the risks of a project

 Identify areas of importance for risk analysis for a project (risk taxonomy)
 Risk radar – risk-prone areas of the product group
 Potential additional risks identified based on the review
 Top 10 risks in the organization from key projects, which requires management attention
Conclusion
Risk management is becoming the most challenging aspect of managing software projects.
While we can never predict the future with certainty, we can apply a simple and streamlined risk
management process to predict the uncertainties in the projects and minimize the occurrence or
impact of these uncertainties.
Risk management not only helps in avoiding crisis situations but also aids in remembering and
learning from past mistakes. This improves the chance of successful project completion and
reduces the consequences of those risks.
This certainly is not the end of the journey for us on the effective risk management. It is a
constant learning process to be able to constantly improve our practices to increase our process
efficiency.

Risk Identification

Uploaded by

Copyright:

Available Formats

Risk Identification

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Risk Identification

Uploaded by

Copyright:

Available Formats

Risk Identification

Exhibit 2 – Risk Sources

3. Probability of Risk Occurrence

a. High probability – (80 % ≤ x ≤ 100%)

b. Medium-high probability – (60 % ≤ x < 80%)

c. Medium-Low probability – (30 % ≤ x < 60%)

d. Low probability (0 % < x < 30%)

a. High – Catastrophic (Rating A – 100)

b. Medium – Critical (Rating B – 50)

c. Low – Marginal (Rating C – 10)

As a guideline for Impact Classification the following matrix is used:

Exhibit 4 – Impact classification guideline

 How important the specific customer is

Exhibit 5 – Impact-Probability Matrix

6. Risk Occurrence Timeframe

Exhibit 6 – Risk occurrence timeframe

7. Risk Classification Examples:

Risk Response Planning

 Risk description with risk assessment

1. Risk Response Plans

1. Eliminating the risk

2. Lowering the probability of risk occurrence

3. Lowering the impact of the risk on the project objectives

Exhibit 8 – Risk response - Examples

Exhibit 9 – Risk Trigger Examples

Exhibit 10 – Risk Owner Examples

Risk Monitoring and Control

Risk monitoring and control includes:

 Identifying new risks and planning for them

 Reassessment of risks is necessary

 Any of risk conditions have been triggered

Risk Efficiency measurement

 Number of risks that occurred / Number of risks that were identified

This is an independent expert analysis of risks, with recommendations to enhance maturity or

 How good are we at identifying risk?

 Customized checklist to evaluate the risks of a project

You might also like