This post is based on a presentation I made at the 2nd Annual International Conference in Kuala Lumpur:
Mastering IT Project Management – From Strategy to Execution

Why Risk Management?
– Successful risk identification, analysis, response planning, and monitoring are critical to the success of all projects.
– Project risks, unless reduced or eliminated, constitute a barrier, both real and potential, to the accomplishment of the project established goals and objectives.
– Risk management, therefore, will be critical to the project’s success in meeting its objectives.
– Proactive risk management techniques are required to identify, analyse, plan responses and monitor all potential risks to the program

Risk VS. Issue
– A risk is a potential future event that could prevent the project from achieving its objectives.
– An issue is an event (that is known, with absolute certainty) that: may prevent a current or future project task being completed as planned or prevent a project from meeting the planned scope, schedule or cost requirements.
– Issues differ from risks in that risks are future events that may occur; risks can be identified before they occur by analysis.
– Issues are only identified when they occur.
– A risk can or expire or become an issue.
– Risks may have beneficial outcomes in which case they help the project.

Main Inputs to Risk Management
– Similar projects issues logs
– Team members experience
– Project Charter
– Project Assumptions
– Project Constraints
– SME’s
– Stakeholders Risk tolerance
– Work Breakdown Structure

The 5 steps

Risk management is made up of five main steps:
– Planning
– Risk Identification
– Risk Assessment
– Risk Response Development
– Risk Monitoring and Control

This process begins with development (or review) of a risk management plan (strategy); this is where the risk management process is defined and roles and responsibilities are assigned.

To achieve maximum benefit from the risk management process, it must be viewed as an ongoing activity whose major components have multiple iterations throughout the project lifecycle.

Accordingly, once the risk management process is in place, the process steps (risk identification, risk assessment, risk response development and risk control) are periodically repeated throughout the life of the project (Design, Build, Test, Prep for Go Live)

Risk Identification

The risk identification step consists of determining which risks are likely to influence the achievement of project objectives and documenting the characteristics of each. Risk identification addresses both internal risks (which the project team can control or influence) and external risks (which the project team cannot control or influence).

Risk Identification (Characteristics)
– Risk Number
– Risk name
– Who raised the risk
– Category:
What type of risk are we facing, example of categories:
* Technical
* Economic
* Commercial
* Organisational
* Political
* Project Management
– Impact
– What Project objective is impacted if the risk occurs?

Risk Assessment (Impact)
The impact of the risk event:the impact is described in terms of quantitative measures of: H (High), M (Medium) or L (Low):
– High: A very serious impact such that there is a significant change to the project scope, schedule, cost or quality; around X USD.
– Medium: A moderate impact to the project scope, schedule, cost or quality, that would require explicit review and approval by the Programme Manager; around Y USD.
– Low: A very low impact such that no review would be required by any project stakeholder.
Note: While gathering information regarding the risk characteristics, other Subject Matter Experts and/or the Project Manager(s) must be consulted.

Risk Assessment (Likelihood)
Likelihood.
The Team Lead will consult with the Submitter or other Subject Matter Experts to determine how likely the risk event is to occur and assign one of the following values:
– Low: Incident could occur in our company; e.g. 50% likelihood
– Medium: Likely that it will happen several times per year in our company; e.g. 10-50% likelihood
– High: Likely that it will happen several times per year in this project; e.g. >50% likelihood

Risk Assessment (Tolerance)
Tolerance.The Team Lead will also assess the acceptability of the current risk responses, if any:
– Acceptable
– Needs Improvement
– Unsatisfactory
– Unacceptable
A risk is rated acceptable if we believe that the responses we have in place are adequate, and we have made a conscious decision not to implement any further mitigation actions at this time.
The other categories signify that we are not happy with the current mitigation, and will need to do something to improve it, in increasing levels of urgency.

Risk Assessment (Status)
Status
Each risk must have a status to make sure it is still relevant to follow it:
– Open: means that the risk still has to be included in risk management I.e. through the 5 steps cycle
– Closed: usually means it turned into an issue so please the refer to the issue ref. # from the issue log
– Expired: risk did not occur means successful management actions and risk is 100% mitigated

Risk Response Development

Once an assessment of project risks has been completed, the Project Team and customer are in a position to develop suitable responses.

While it is rarely possible to design a response that will guarantee achievement of any one programme/project objective, it is generally possible to design a risk response which will provide reasonable assurance of doing so. Where it is not possible (or where the cost of the risk response exceeds the perceived benefits) the objective and project business case may need to be reviewed.

The risk response is also influenced by the willingness of key stakeholders to accept a risk and its potential impact. Risk responses that are not cost effective have no place in the framework unless they are mandatory requirements imposed by internal or external regulatory bodies.

Responses generally fall into one of the following categories:
Avoidance: eliminating a specific threat, usually by eliminating the cause. This may involve changing the Project Terms of Reference or the Project Plan to reduce scope.
Mitigation: reducing the expected value of a risk by reducing the probability of occurrence or impact or both. This may involve taking specific actions (e.g. early prototyping or pilots, simplified technical architecture, extending the schedule).
Acceptance: accepting the consequences. This can be either active (develop a contingency plan to execute if the risk event occurs) or passive (accepting a plan overrun if a risk occurs).
Transfer: seeking to pass the consequence of a risk onto someone else through insurance, contract or bond.

Risk Response (Characteristics)
Action
Description of the actions to take to manage the risk
Control
How do we manage the risk response:
– Control
– Influence
– Accept
This concept will give a clear view to the stakeholders how the project team can impact the risk management
Responsibility
Who is responsible to tackle the risk, this can be 1 individual or a group
Accountability
Who at the end of the day will carry the accountability, this can only be 1 individual (inside or outside the project team).
Make sure he takes the ownership of the risk.
This individual is usually a senior person part of the steering committee who has authority to make sure the right attention across the board will be given to a specific risk.
Response typeHow do we intend to response to a specific risk?
– Avoidance: eliminating a specific threat, usually by eliminating the cause. This may involve changing the Project Terms of Reference or the Project Plan to reduce scope.
– Mitigation: reducing the expected value of a risk by reducing the probability of occurrence or impact or both. This may involve taking specific actions (e.g. early prototyping or pilots, simplified technical architecture, extending the schedule).
– Acceptance: accepting the consequences. This can be either active (develop a contingency plan to execute if the risk event occurs) or passive (accepting a plan overrun if a risk occurs).
– Transfer: seeking to pass the consequence of a risk onto someone else through insurance, contract or bond.

Risk Control

Risk management is not a one-off activity. Risks should be monitored throughout the programme/project as their likelihood or impact ratings may change or new risks may emerge. Additionally, the effectiveness of the risk responses should be periodically reassessed.

If a risk event materializes (or is about to materialize), then the need for implementation of the response (as documented in the risk register) should be raised to the Programme/Project Manager.

Risk Control (Reporting)
It is important to report on a regular basis to the steering committee the progress on risks management.

Therefore a baseline will be needed to measure against and a bubble chart to show probability and impact.

If in the register and baseline all risks must be detailed, it is preferable for the bubble chart to cluster them in order not to exceed 10-15 items.

Risks Attributes to be tracked
Identification:Risk Number
– Risk name
– Who raised the risk
– Category (TECOPP)
– What Project objective is impacted if the risk occurs?
Assessment
– Impact (H/M/L)
– Likelihood (H/M/L)
– Tolerance
* Acceptable
* Needs Improvement
* Unsatisfactory
* Unacceptable
– Status
* Open
* Closed
* Expired
Risk Response:
-Action
-Control
* Control
* Influence
* Accept
– Responsibility
– Accountability
– Response Type
* Avoidance
* Acceptance
* Mitigation
* Transfer
Risk Control
– Update registers
– Generate reporting and control charts

Baseline

Bubble Chart

Impact of Risk Management on the Schedule
Risk Management activities must be tracked in the schedule (recurrent meetings) as per described cycle
Mitigation actions MUST be tracked in the schedule
Contingency derived from the Risk Management plan MUST be tracked in the schedule (buffers clearly identified)

What is next?
A risk may or expire or become an issue (clearly mention the issues log item # in the risks log).

Basically the process only ends when the project is closed and becomes an input for project closure and lessons learned.