Risks
A structured approach to managing and monitoring risk.
Definition: Risk is a term that refers to events, which, if they occur, may have a negative impact on a project and bring unwanted
consequences. It is not unusual to have some confusion between a risk, an issue, and a change request. They can be differentiated as follows:
|
Item |
Description |
|
Risk |
Something negative that may happen in the future. |
|
Issue |
Something that is occurring now and has to be resolved. Unresolved issues may put the project at risk. |
|
Change Request |
A request that seeks permission for a specific course of action to be taken (perhaps to resolve an issue or a risk). |
Risks are possible events. Events that are actually happening are issues. A risk always has the possibility of becoming an issue.
There is an inter-relationship between Issues, Risks and Change Requests
as the results of one may trigger the other as per the following diagram:
A risk can be viewed from two dimensions:
-
Impact – Scope /Cost/Quality
-
Probability of Occurrence – The greater the likelihood of the events, the greater the risk.
The Ernst & Young Navigator Systems Series defines a risk management strategy as a means of minimizing the probability and impact of a known risk factor on the project. There are
four ways of managing risk:
-
Acceptance – live with the risk by accepting the consequences and develop a contingency plan to execute should the risk event occur.
-
Mitigation – take action to reduce the impact and/or probability of the risk.
-
Avoidance – change the circumstances that are creating the risk, usually by eliminating the cause.
-
Transfer – forward a risk to the appropriate body, outside the Project.
Top
Purpose of Risk Management
All projects have risks. A risk is not negative in itself; instead, a risk can become negative if it is not planned for. Risk management helps you:
-
Anticipating and identifying areas of project risk.
-
Minimizing the impact of identified risks.
-
Reducing the likelihood of identified risks.
-
Monitoring risk areas for early detection and action.
Goals of Risk Management
A series of related goals and accomplishments are identified as:
-
Complying with the Risk Management Policy.
-
Using a risk management as an effective communication tool, which encourages the communication of risk activities for current and emerging risks.
-
Allowing for risk preparedness to be conducted systematically.
-
Encouraging a proactive approach in reducing the impact and/or probability of risk by instituting a cycle of continuous risk management planning.
-
Defining a process to manage risk.
-
Defining a standard approach for impact analysis on risks.
Top
The Risk Management Process
Answering, “yes” to these questions identifies a risk.
-
Open the Risk Incident
A Risk incident can be initiated by anybody on the project and logged into Program Support Log.
A Status of ‘new’ is automatically assigned. All ‘new’ Risk incidents are reviewed at the Project Huddle
The Business or Project Office has the responsibility to update and track all risks from the Program Support Log.
The Business or Project Office also has the responsibility to review all newly identified risks to determine if a similar risk is already in progress or completed. A scan is done of the
existing risks to determine if there is similar one already logged. If a similar risk is already in progress, then it may be appropriate to merge the risks and the status of the new risk is
changed to “Merged”. If there is not a similar risk in progress, then an impact and probability analysis must be conducted on the identified risk.
-
Analyze the Change Request
Risk Analysis is the process of examining the identified risk and determining and documenting the impact to the project. Analyzing a risk includes an assessment of its impact
and probability to generate a risk Impact level (Ranking) and a recommended course of action. A risk can be withdrawn at any point by the
originator
prior to the completion of the analysis.
The Business or Project Office will include any newly received risks as an agenda item for the Project Huddle Meeting. The Project Huddle is responsible for vetting the newly identified risk
and assigning an individual to conduct a risk analysis. The analysis should be assigned to an individual with the relevant expertise. A target end date for the analysis will also be decided.
The Business or Project Office is responsible to update the Program Support Log with the name of the person assigned to perform the analysis and the target end date. The status of the risk is
changed to ‘Under Investigation’.
Impact Analysis
The impact analysis answers the question,
what would happen if the risk occurred?
Impact Analysis is done against three factors: Scope, Cost, Quality, plus the Probability of Occurrence.
The probability of the risk occurring is not only dependent on the statistical concept of chance; it must also take into account the level of difficulty to address the risk.
The probability of the risk is assessed against two factors:
- Likelihood - how likely is it that the risk will occur?
- Resolution - how difficult would it be to resolve the risk?
Establish the Risk Level
The risk level establishes the priority of the risk. The Expected Value of the risk is the numeric Impact Score (highest impact score) multiplied by the numeric Probability Score (lowest
probability score).
Probability Score
Probability Score X Impact Score = Expected Value
A rating level of Urgent, High, Medium or Low is based on the Expected value.
Once the Risk Level is entered into the Program Support Log, the status of the risk is be changed to "Completed Analysis". Any notes, assumptions, and sources of information
that were used to conduct the analysis should be entered into the Analysis Description Text field of the Program Support Log. Other Areas and Stakeholders impacted by the risk must be
identified. A recommended course of action to resolve the risk must be provided. It will be up to Approval Authority to approve a recommended course of action
The Risk response Plan encompasses a wide variety of activities. For instance, change requests may be required, and the corresponding activities may have to be added to the appropriate
detailed project plan.
-
Resolve the Risk / Selecting a Course Of Action
With the analysis completed, the appropriate Approval Authority can be selected. There are two important considerations for selecting the
Approval Authority.
First, which organization will be primarily responsible for implementing the recommendation?
Second, the higher the ranking of a risk level (Urgent, High, Medium or Low), the higher the level of Approval Authority required. As a guideline, consider the following:
• Urgent – Directory (or Project Sponsor or Steering Committee)
• High – Director
• Medium – Manager, Director
• Low – Project or Team Leader, Manager, Director
At the Project Huddle Meeting, all risks that have completed analysis will be reviewed and an Approval Authority will be determined. The Approval Authority will be notified
that the risk has been analyzed and is ready for review. The detail of impact analysis and recommended course of action must be provided to the Approval Authority. The Approval Authority will
decide upon the course of action.
The possible courses of action are:
|
Action |
Description |
|
Accept |
Live with the risk and develop a contingency plan to execute should the risk event occur. |
|
Mitigate |
Take steps to reduce the impact and/or probability of the risk. |
|
Avoid |
Change the circumstances that are creating the risk, usually by eliminating the cause. |
|
Transfer |
Transfer the risk to the appropriate body, outside the Project |
When a risk is accepted, a Contingency Plan should be considered. A Contingency Plan describes activities that are invoked if the risk occurs. The Contingency Plan should be
added to the detailed project plan as a deliverable. The Program Support Log is updated to reflect that a Contingency Plan is being developed and the status of the risk is changed to
“Monitor”.
The Approval Authority may choose to initiate some activities to try and mitigate (reduce) a risk. The Approval Authority will assign an individual with relevant expertise and authority to
mitigate the risk and will also decide the target end date for the task. The resource assigned to mitigate the risk and a target end date will be entered in the Program Support Log and the
status of the risk is changed to “In Progress”. The Analysis Description text field of the Program Support Log should be updated by entering any notes, assumptions sources of information and
attaching any supporting documents or URL's that were used to mitigate the risk. The activities that are required to mitigate a risk should be added to the detailed project plan as a
deliverable.
The Approval Authority should be notified (Except Steering Committee) when risk mitigation actions are completed. Update to the Steering committee should be provided via
Steering Committee Reports. The Approval Authority will review the risk and decide if any further activity is required to close the risk. If no further action is required, then the status of
the risk is changed to "Completed".
Based on the analysis, the Approval Authority may choose to avoid or transfer a risk. The Approval Authority will update the Program Support Log with the rational for
transferring or avoiding the risk and the status of the risk is set to “Completed”.
Only the Approval Authority can close the risk.
NOTE: Sometimes a risk may require both mitigating and contingency actions.
Top
Track and Control
The Business or Project Office is responsible for monitoring progress made against risks. The timely resolution of risks is an important element of project success. The Project Huddle Meeting
is the forum used to discuss the progress.
Control is the process in which risk mitigation and contingency activities are managed. As part of control, if the mitigating or contingency actions are not completed in a
timely manner, a risk must be escalated to the next level of accountability.
The following triggers may result in a reassessment of a risk:
• Scope change to the project (through change control or scope creep)
• Frequent changes in people assigned to the risk
• Change in technology associated with the risk
• Lack of or an insufficient action plan for the risk
• New issue that may impact the risk
• New risk that may impact the original risk, resulting in a cascade effect
• Changes to available money and time to handle the risk
• Changes to available expertise to deal with the risk
Risk Management Process Summary
|
