risk and issue management

Thomas Petite Risk and Issue Management 1

Risk and Issue Management

Thomas Petite

2012


1. RISK AND ISSUE MANAGEMENT

1.1. Purpose

The Risk & Issue Management Process is used as a tool to report on, mitigate and resolve Risks & Issues. The process also provides a framework by which Risks and Issues can be escalated to the appropriate governance level for visibility and/or action.

A Risk & Issue Database should be used by Project Managers wherever possible to ensure all Program Risks & Issues are captured in a consistent format, with a common method of assessing escalation levels. Initially we will use the PM workbook until such time that the PMO initiates the move to DAPTIV.

Description

The Risks & Issues process will capture all Risks & Issues across the Program that are either the direct result of activity or the result of outside influences on the planned progress of the Program.

The potential impact (e.g. time, cost, benefit delivery or scope) on the Program will determine the level at which the Risk/Issue will be escalated. Set escalation triggers have been defined to provide guidance and consistency, although management judgment should also be used to determine the level at which a Risk/Issue should be managed.

1.2. Objectives of the process

The main objectives of the process are:

Ensure that Risk is effectively identified and managed within the Program

Provide a standard mechanism and format for defining, prioritizing, reporting and tracking Risks and Issues

Provide a framework for escalation of Risks and Issues within the Program

Allow constructive focus on each Risk or Issue and ensure that action plans are developed to mitigate the Risk or resolve the Issue.

1.3. Content

To populate the Risks & Issues database each Risk or Issue must detail:

A concise description of the Risk/Issue and its indicative impact

An escalation level appropriate to the severity and management level required to mitigate or resolve the Risk/Issue, with this being reviewed regularly by the Project Manager, Work Stream Lead, -PMO, and Program Leadership (see Governance structures)

Each Risk/Issue should have end-to-end action plans to mitigate or resolve the Risk or Issue, with appropriate owners and timeframes clearly noted and managed by the Project Manager.

1.4. Roles & Responsibilities

Project Managers are responsible for identifying, logging and managing their Risks and Issues through to conclusion.

1.4.1. PMO

Ensuring that Project Managers are aware of their role and responsibilities within the Programs Risk Management framework


Ensuring databases or Risk & Issue Logs are used to register and monitor all Program Risks and Issues

Identifying and analyzing Risks and Issues which will impact on either timing or extent of benefit realization, achievement of critical milestones or have a detrimental effect on Program Delivery

Ensuring Level 2 & 3 Risks and Issues are escalated to the Program Coordination Committee (PCC) to enable effective management for mitigation of Risks and resolution of Issues

Ensuring all Risks and Issues have appropriate end-to-end action plans in place that either mitigate the Risk, or resolve the Issue, and ensuring the actions are progressed

Immediately advising the Program Coordination Committee (PCC) of any significant developments or changes in respect of level 2 & 3 Risks and Issues

Ensuring there is a process in place for capturing, raising and reviewing Operational Risk

-PMO will police, educate and assure Risk & Issue management across the Program

Perform regular reviews of Program Risks and Issues at level 2 & above to ensure that they are being managed, correct processes are embedded, and that escalation and visibility occur where appropriate

Provide support to the PMs in scoping, analyzing, and taking appropriate actions with regard to the Risks and Issues managed at the Steering Committee Level and above

-PMO will facilitate Risk Management activity where necessary within the Program to ensure that adequate processes and controls are in place, making recommendations and ensuring that remedial action is taken when required.

1.5. SCOPE and definitions

This Risk and Issue Management Process applies to the following:

1.5.1. In scope

All Risks and Issues that may/will impact the Program

All Risks and Issues (operational & project) that may/will detrimentally impact part or all of the company as a result of the Program’s activity.

1.5.2. Out of Scope

Risks and Issues that do not result from and/or impact on the Program

1.6. Risk and Issue Definitions

1.6.1. Project Risks

A Risk is defined by PRINCE2 as

“The chance of exposure to the adverse consequences of future events”

The key features of a Risk are therefore its potential (negative) impact, its uncertainty and the fact that it lies in the future.

Term Definition

Risk A project Risk, from a Program perspective, is one that would have a potential negative impact on benefits delivery, cost or customer service.

Risk Owner The person responsible for tracking a risk’s progress through to closure. Ownership is determined by the level within the governance structure impacted by the risk. This is shown in the table below.


N.B. Initial ownership will rest with the manager by whom it was raised. The ownership of a risk may change as it is (re)evaluated.

Action Owner The person responsible for carrying out actions associated with mitigating a risk. The action owner will be assigned by the risk owner.

Risk Trigger An event that may indicate a risk is about to materialize.

Program

Project

· Status

· Issues

· Risks

Project

· Status

· Issues

· RisksWork Stream(s)

Project

· Status

· Issues

· Risks

Project

· Status

· Issues

· RisksProject(s)

PMOPgM Lead Work Stream Lead, Work

Stream PM Project Manager

Type of risk Definition Owner

Program · Risk impacts a Program key deliverable

OR

· Risk impacts one or more work streams within the Program and cannot be mitigated within the constraint of a work stream.

Program Manager

Work Stream Risk impacts a project key deliverable but can be contained within the work stream constraints.

Work Stream Lead or Work Stream PM

Project Risk impacts a project, key deliverable but can be contained within project constraints.

Project Manager

1.6.2. Project Issues

Term Definition

Issue An Issue is defined as

“Something that has happened or will definitely happen in the future and threatens the success of a project”

The key feature of an Issue is therefore its negative impact, immediacy and certainty.

Owner The ‘owner’ of an issue is the person responsible for tracking its progress through to closure. Ownership is determined by the level within the governance structure impacted by the issue. This is shown in the table below.


N.B. Initial ownership will rest with the manager by whom it was raised. The ownership of an issue may change as it is (re)evaluated.

Type of issue Definition Owner

Program · Issue impacts a Program key deliverable

OR

· Issue impacts multiple projects within the Program and cannot be mitigated within the constraints of a project.

Program Manager

Work Stream Issue impacts a work stream key deliverable but can be contained within the work stream constraints.

Work Stream Lead or Work Stream PM

Project Issue impacts a project key deliverable but can be contained within project constraints.

Project Manager

1.7. Risks & Issues Process Flow

1.7.1. New Risk or Issue identified and logged in Database or Risk & Issue Log with owner and action plan

Once a Risk or Issue has been identified the following actions should be taken: - Assign ownership to the Risk or Issue. Each Risk and Issue must have an owner (single point

of responsibility) recorded against it who has overall responsibility for its management and is ultimately accountable for its control.

- Develop an appropriate action plan to resolve the Risk or Issue as quickly as possible.

1.7.2. Escalation Level Assessed

The Risk or Issue should be checked against existing Risk & Issue Log records and if a match is found consolidated in a related record

If there is no existing related record a new record should be created in the Risk & Issue Log

The Risk or Issue should be assessed for impact to the Project/ Work Stream /Program and the Level of Risk or Issue calculated from the formulae contained within later Sections of the risks and issues process

The escalation level is determined by Project Manager or Work Stream Lead.

Work Stream Lead or Work Stream PM should be reviewing logs on a Bi Weekly basis.

1.7.3. Risk or Issue meets criteria for escalation to Level 2 (High) or above

The Project, Work Stream Lead or Work Stream PM decides whether the Risk or Issue meets Level 2 criteria or above

If the Risk or Issue is assessed at Level 2 or above then it is forwarded to the -PMO by the Work Stream PM or Work Stream Lead

If it is assessed as below Level 2 then it is managed within the PM or Work Stream PM


1.7.4. -PMO reviews Risk/Issue with Project/Work Stream Lead to agree level/action plan

The -PMO and Program Lead review Risks and Issues submitted at Level 2 and above to ascertain whether they have been assessed correctly and/or whether they should be escalated (from Level 2 to Level 3).

Review the action plan to ensure the plan: -

- Seeks to resolve the underlying cause of Risks and Issues.

- Details the name of the person responsible for completing the action and the due date.

- Must be in the future. No actions should be showing as overdue - where an action has not been achieved by its due date, it should be re-forecast with reason/explanation.

1.7.5. Risk or Issue agreed as Level 2 or above

The Risk or Issue is presented at the Steering Committee

If it is agreed at Level 1 or below the PM, Work Stream Lead, or Work Stream PM will manage the Risk or Issue at the appropriate level.

1.7.6. Update Risk and Issue in the Risk & Issue Log

Risks and Issues should be updated as follows:

- Resolution date is current week: mandatory status update

- Resolution date is overdue: mandatory status update

- Resolution date is future: optional status update as newly acquired information dictates

1.7.7. Steering Committee advised for resolution and/or visibility guidance

The Program Lead advises the Steering Committee of any Risks or Issues of Level 2 or above

The -PMO report contains summary detail of each Level 2 or above Risk and Issue including action plans, mitigation strategies together with an indication as of when the Risk or Issue will be de-escalated

The Risk or Issue will be reviewed on an ongoing basis by the -PMO/Steering Committee until it has been resolved or de-escalated.

1.7.8. Continue to manage at PM Level

The Risks or Issues to be monitored by PM, Work Stream Lead or Work Stream PM until they are resolved or are considered appropriate to de-escalate.

1.7.9. Risk or Issue managed within the work stream, the -PMO will review all Level 1 & below Risks & Issues with the PM, Work Stream Lead or Work Stream PM

Where the Risk or Issue has been agreed at Level 1 or below it is managed at Project Work Stream Level

To ensure Governance/Due Diligence is maintained, the -PMO will:

- Regularly review all Risks or Issues at Level 1 and above with the Work Stream PM and Work Stream Lead

- Provide feedback and guidance on Level 1 Risks and Issues

- Make recommendations on process improvements and instill best practices

- Recommend escalations/de-escalations as well as closures


1.7.10. Action Plan Achieved

On completion of the action plan the Risk or Issue should be assessed by the PM to determine if the Risk or Issue can be closed.

1.7.11. Risk or Issue Resolved

Once agreement has been reached that the Risk or Issue has been resolved and sanction provided to de-escalate or close, the Risk & Issue Log should be updated.

1.8. Risk & Issue Escalation & Assessment

1.8.1. Risks

A project Risk, from a program perspective, is one that would have a potential negative impact on delivery timing or cost.

Risk owners are asked to provide as scoring of 1 - 3 on the TIMING IMPACT, FINANCIAL IMPACT and PROBABILITY of a Risk occurring and the USERBASE AFFECTED.

Impact - Any potential adverse effect to benefits delivery, project cost, benefit and service quality – extra costs and delayed benefits should be added (or subtracted) to give a true indication of the impact of the Risk.

Probability - Actual likelihood of the Risk occurring

Quantitative Analysis

In order for the impact to be accurately and consistently monitored across the Program, Work Stream and Projects, the following Risk impact scoring system should be applied. These ratings are intended as guidelines only as there should always be scope for subjective judgment. A Risk therefore can be escalated irrespective of the impact score where the involvement of more senior management will be of benefit in resolving the Risk.

A. Timing Impact

Delay period as it affects the “User base Affected” that you have chosen. If you feel there is no impact then you should identify it as a “1 – Low: < 1 Week”; as the field must be completed with a category.

B. Financial Impact

The “Financial” impact is scored based upon the “User base Affected” category that you have chosen. If you have defined it at the Project level, then you should assess the financial impact, i.e. additional cost incurred, at the project level. If the team feels there is “no impact” for this category, then you should pick a score of 1 – Low <$50K (you will be required to input the actual financial impact when submitting the risk, if there is “no impact” you would enter $0).

C. Probability - % likelihood

Every Risk identified must have a probability score otherwise it wouldn’t be identified to begin with. Scoring defined below:

Low - less than a 10% chance of occurring

Medium – 10% - 50% chance of occurring

High – 51% - 100% chance of occurring

D. User base Affected – Levels defined below

Project Level - one of your sub-projects within your work stream

Work Stream – if an entire work stream is affected

Project Level – if it affects the entire Project (or multiple Projects within a work stream)


Program – affects entire program

Cross-Program – affects multiple Programs within the Company

RISK SCORING CHART

Timing Impact Financial Impact Probability

Scoring Delay Period Scoring Cost Impact Scoring % Likelihood

1 - Low < 1 Week 1 - Low < $50K 1 – Low Less than 10% 2 - Med 1 – 3 Weeks 2 - Med $50K - $100K 2 – Med 10% - 50% 3 - High > 3 Weeks 3 - High > $100K 3 – High 51% - 100%

User base Affected

Scoring Level

1 Project 2 Work Stream 3 Program 4 Cross-Program

Risk Prioritization

Once the appropriate weightings have been applied to Timing Impact, Financial Impact, Probability and Userbase respectively, the Risk score can be calculated. This calculation is shown below:

Identified Risk

Timing Impact

+ Financial Impact

+ Probability + User base Affected

Risk Score

A 3 + 3 + 3 + 4 13 B 3 + 2 + 1 + 2 8 C 2 + 1 + 1 + 1 5

The Risk score allows Risks to be prioritized in terms of resource, escalation and resolution forums.

Risk Escalation

In order to ensure each Risk is escalated to the appropriate level, the following escalation guidelines should be used. If the escalation score does not accurately represent the escalation level then this can be changed manually

Risk Score Escalation

Level Escalate To Action

1 - 4 0 - Low No escalation PM manage

5 - 7 1 - Medium PM notify Work Stream PM manage

8 - 10 2 - High PM or Work Stream Lead notify -PMO -PMO escalate as required to Steering Committee

11+ 3 - Critical PM notify -PMO -PMO escalate as required to Steering Committee

Using the examples highlighted above;

Risk A would be escalated to level 3 - Critical


Risk B would be escalated to level 2 - High

Risk C would be escalated to level 1 - Medium

Risk & Issue Logs For owners maintaining a Risk & Issue Log it is recommended that the quantitative analysis be undertaken using the criterion above.

1.8.2. Issues

Issue owners are asked to provide as scoring of 1 - 3 on the TIMING IMPACT and FINANCIAL IMPACT and the USERBASE AFFECTED associated with an Issue occurring.

Quantitative Analysis

In order for the impact to be accurately and consistently monitored across Programs, the following Issue impact scoring system should be applied. These ratings are intended as guidelines only as there should always be scope for subjective judgment. An Issue therefore can be escalated irrespective of the impact score where the involvement of more senior management will be of benefit in resolving the Issue.

A. Timing Impact

Delay period as it affects the “User base Affected” that you have chosen. If you feel there is no impact then you should identify it as a “1 – Low: < 1 Week”; as the field must be completed with a category.

B. Financial Impact

The “Financial” impact is scored based upon the “User base Affected” category that you have chosen. If you have defined it at the Project level, then you should assess the financial impact, i.e. additional cost incurred, at the project level (See Issue Scoring Chart below)

C. User base Affected – Levels defined below

Project Level – if an entire project is affected

Work Stream Level – if it affects the entire work stream (or multiple Projects within a work stream)

Program – affects entire program

Cross-Program – affects multiple Programs within the company

ISSUE SCORING CHART

Timing Impact Financial Impact

Scoring Delay Period Scoring Cost Impact

1 - Low < 1 Week 1 - Low < $50K 2 - Med 1 – 3 Weeks 2 - Med $50K - $100K 3 - High > 3 Weeks 3 - High > $100K

User base Affected

Scoring Level

1 Project 2 Work Stream 3 Program


4 Cross-Program

Issue Prioritization

Once the appropriate weightings have been applied to Timing Impact, Financial Impact, and User base respectively, the Issue score can be calculated. This calculation is shown below:

This calculation is shown below; the Issue score allows Issues to be prioritized in terms of resource, escalation and resolution forums.

Identified Issue

Timing Impact

+ Financial Impact

+ Userbase Affected

Issue Score

A 3 + 3 + 4 10 B 3 + 2 + 3 8 C 2 + 1 + 1 4

The Issue score allows Issues to be prioritized in terms of resource, escalation and resolution forums.

Issue Escalation

In order to ensure each Issue is escalated to the appropriate level, the following escalation guidelines should be used. If the escalation score does not accurately represent the escalation level then this can be changed manually

Risk Score Escalation

Level Escalate To Action

1 - 4 0 - Low No escalation PM manage

5 - 7 1 - Medium PM notify Work Stream Lead PM manage

8 - 9 2 - High PM or Work Stream Lead notify -PMO -PMO escalate as required to Steering Committee

10+ 3 - Critical Work Stream PM or Work Stream Lead notify -PMO

-PMO escalate as required Steering Committee

Using the examples highlighted above;

Issue A would be escalated to level 3 - Critical

Issue B would be escalated to level 2 - High

Issue C would be escalated to level 0 - Low

Risk & Issue Logs For owners maintaining a Risk & Issue Log it is recommended that the quantitative analysis be undertaken using the criterion above.

1.9. Roles and Responsibilities

Responsibilities are divided into the following sections and are in addition to any other Program requirements:


1.9.1. Project Managers, Work Stream PM, or Work Stream Lead

Responsible for:

Ensuring Risks and Issues that will impact timing, costs, extent of benefit realization ($ or headcount), or achievement of critical milestones are identified

Ensuring Risks and Issues are logged onto the central Risk & Issue Log

Ensuring end-to-end action plans for all Risks and Issues are in place

Identifying and analyzing Risks and Issues in terms of both impact on benefit delivery (FTE, costs and critical milestones) and Operational Impact in terms of financial, customer or reputational damage resulting from Program activity

Assessment of the probability (for Risks) and impact, and establishing ownership for the Risk or Issue at the appropriate level

Reporting the up-to-date position on all Risks and Issue raised to the -PMO through regular weekly reporting process

Identifying and seeking to resolve the underlying cause of Risks and Issues

Ensuring all Risks and Issues have appropriate end-to-end action plans in place that either mitigate the Risk, or resolve the Issue, and ensuring the actions are progressed

Ensuring level 2 & 3 Risks and Issues are escalated to -PMO to enable effective management for mitigation of Risks and resolution of Issues

Immediately advising the -PMO of any significant developments visibility of Project level Risks and Issues that may require escalation or changes in respect of level 2 & 3 Risks and Issues

Regularly reporting progress and updates to, and requesting action where appropriate from the Steering Committee.

1.9.2. -PMO

Responsible for:

Ensuring that Work Stream PM’s or Work Stream Leads are aware of their role and responsibilities as defined within the Section above

Ensuring appropriate Project and team members have access to and are trained to use the appropriate tools or where databases are accessible

Ensuring there is a process in place for capturing, raising and reviewing Operational Risk

Ensuring Risk and Issue management processes are adhered to by the Work Stream PM’s

Ensuring a centralized Risks & Issues Log is used to register and monitor all Program Risks and Issues

Ensuring that all Risks and Issues are up to date in the Risk & Issue Log

Monitoring Risks and Issues to ensure that no actions are overdue

Overseeing escalation and prioritization undertaken by PMs

Regular review of Program Risks and Issues at level 2 & above to ensure that they are being managed, correct processes are embedded, and that escalation and visibility occur where appropriate

Review of Weekly Progress Reports to identify trends and possible Risks and Issues that have not been raised or logged

To drive out the Risks and Issues across the Program, the -PMO will undertake where possible Risk Workshops as and where necessary with Project Managers.

1.10. Risk reporting

Another way to provide an overall risk assessment for a Project or Program is to use a Heat Map. A Heat map can serve two important roles.


Provide management information on overall Risk to a Project/Program

Show (if based on some proximity factor) which risks to focus on

This plots all the risks using Risk Proximity (when the risks are likely to materialize). This is an important factor as it further clarifies which risks on which to focus. For example, it is better to focus on a low rated risk that may occur next week, than a high rated risk that is predicted to

materialize in six months.

1.11. Set up and putting into practice

It is essential to get project managers engaged in the Risk Management Process as soon as is possible. This can be broken down into six easy steps:

1. Early visibility of risks and issues already associated with the Program

2. Engaging PMs once set up to rollout the Risk Management process

3. Setting up a singular Database or Risk & Issue Log and assist them in setting up

4. Assisting PMs in embedding and using the process and tools

5. Commence weekly reporting to the -PMO

6. Monitor and communicate issues in process or quality within the project

Even before the Weekly Progress Reporting commences, Risks and Issues will already start to be recorded in various activities and formats such as:

Business Cases

Presentations and workshops

Planning sessions

Scoping documentation

It is important that these are captured at an early stage, reviewed and given ownership within the various Projects. The Project Manager should coordinate and drive this activity from the Programs’ outset ensuring quality is optimized at all opportunities.

The following diagram highlights why it is essential at the offset to ensure the Risk Management Process is set up and embedded throughout the Program:

IMP

AC

T

High Medium High High

Medium Medium Medium High

Low Low Low Medium

Low Medium High

PROBABILITY


Once Weekly Progress Reporting is set up, it is essential to put into place a singular method (Risk & Issue Log) or Database that will enable the Program as a whole to record, monitor, manage and escalate risks and issues throughout the life of the Program.

· The -PMO will be responsible for driving this activity and ensuring it is understood, embedded and utilized in accordance with the process standards and procedures detailed in the previous sections. The -PMO is also responsible for ensuring that the PMs are aware of their roles and responsibilities in relation to Risk Management as well as the other controls.

1.12. Best Practices

The following are examples of Best Practices that should be utilized and communicated throughout the Program to ensure quality is embedded from the Projects upwards.

What makes a good risk or issue? Common Failings

IDENTIFICATION Early identification of Risks and proactive management to mitigate

Risks not being identified until they become Issues (problems)

DESCRIPTION Concise “plain English” description Poor identification of the real Risk/Issue (too broadly or narrowly defined)

ANALYSIS Quantified impacts (as much as possible)

Inadequate quantification leads to an inappropriate strategy and action plan

MANAGEMENT A clear action plan – with identified Outputs

Inappropriate actions which are not action orientated and clearly defined

REVIEW Review Process No review process in place which ensures actions are complete and effective


Concise Description

Use “plain English” rather than jargon

Think of the reader - “would an unrelated Project Manager be able to understand this?”

Think of the “big picture” when describing the problem - “what does this mean to the Program?”

Impact Assessment

Use “plain English”

Quantify as much as possible - especially Financials

Put any quantification in context with the original Business Case submission e.g. “costs in 2011 will increase by $50K from $75K to $125K”

Ensure you quantify for all applicable periods not just 2011 e.g. 2012, 2013…

Action Plans

Use “plain English” (will the reader understand this?)

Focus on “Outputs” rather than “inputs” e.g. rather than, “there is a meeting to discuss…” ensure the output is clearly presented; “a recommendations paper will be presented to the Program Steering Committee on…”

Ensure the action(s) will mitigate or resolve the Risk or Issue

Review & update due/overdue actions regularly

If Impacts have changed as a result of an Action then ensure the Impact section is updated

risk and issue management

Leadership & Management