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
· Risks
Work Stream(s)
Project
· Status
· Issues
· Risks
Project
· Status
· Issues
· Risks
Project(s)
PMO
PgM 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
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
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:
IMPACT
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

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Risk and issue management (20)

Recently uploaded (20)

Risk and issue management