Risk Analysis and Management

Article by: Lavanya, N. & Malarvizhi, T. Risk analysis and management: a vital key to effective project management. Paper presented at PMI® Global Congress (Asia Pacific, Sydney, New South Wales, Australia. Newtown Square, PA: Project Management Institute)

Program Managers, Nokia Siemens Networks

Abstract

Risk Analysis and Management is a key project management practice to ensure that the least number of surprises occur while your project is underway. 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. This improves the chance of successful project completion and reduces the consequences of those risks.

This paper presents the structured Risk Management process followed at Nokia Siemens Networks that helps avoid crisis situations and incorporate learning from past mistakes. It highlights that effective and early risk identification and management secures the achievement of project objectives, leading to reduced rework costs.

Introduction
Project team members at various levels identify and handle risks in different flavours. However, this will be ineffective without a structured risk management framework, as this leads to:

• Incomplete impact evaluation, leading to loss of:

            1. Knowledge of the overall impact on the project objectives, like scope, time, cost, and quality
            2. Identification of secondary or new risks arising from the already identified risks

• Lack of transparency and a communication gap within and outside the team

• Thus, it is very important for any project organization to set up an effective risk management framework. Instituting such a practice as a project team culture ensures:

• Conscious and focused risk identification and management

• Project progress as desired, with the least amount of deviations or surprise, and in line with project and organizational objectives

• Early and effective communication of project issues to organization and project stakeholders

• An effective team building tool, as team buy-in and acceptance is assured

Exhibit 1 shows that risk management is an iterative process and each facet of risk management should be planned and followed during each phase of the project..

Exhibit 1 – Risk Management Process

The risk management framework followed at Nokia Siemens Networks provides guidelines for:

• Continuous risk identification

• Risk evaluation

• Risk mitigation and contingency measure definition

• Risk monitoring and control

• Risk identification efficiency measurement

The risk management framework also provides templates and tools, such as:

• A risk register for each project to track the risks and issues identified

• A risk checklist, which is a guideline to identify risks based on the project life cycle phases

• A risk repository, which is all the risks identified across projects so far

Risk Management Framework

Risk Management Plan

The organization-mandated risk management framework is reviewed and tailored to define the project risk management plan when the project is initiated. The risk management plan includes these definitions and guidelines:

• List of possible risk sources and categories

• Impact and probability matrix

• Risk reduction and action plan

• Contingency plan

• Risk threshold and metrics

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

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

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

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

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

4. Risk Impact

1. High – Catastrophic (Rating A – 100)

2. Medium – Critical (Rating B – 50)

3. 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.

References

Siemens Quality Management System – Process documents. Available from the company intranet site.
(pmi.org)