Introduction to
Risk Management
October 2014
Technology, Engineering and Management
Department of Chemical Engineering
Sue Lounsbury, PEng, MBA, PMP






Queens University – Mech Eng 82
University of Ottawa – MBA 99
Member of PEO and PMI
30 plus years of experience
Professional field – Strategic planning and project
management with focus on risk management
Professional career includes:






Multiple construction projects in the Oil and Gas sector
Project management for Training facilities for CATSA
Project management for Long term care centres and
hospitals
Ottawa Light Rail Transit
Strategic planning and risk management for Chanceries in
Moscow, London and Paris for DFAIT
Currently working on the renovations of Parliament Hill
What would Project Management be without Dilbert?
Why do so many avoid dealing with
Project Risk Management?






Perceived as difficult to do
Tends to be the “bad news” part of projects
Results are not always tangible
Often not a priority for senior management
Often done once on a project and then
“shelved” in a nice binder and forgotten
about
Projects are not often supplied with the
resources to deal with Risk
Risk





Rarely does everything happen as planned
Uncertain events or conditions can have positive or
negative effects on the project
Risks are things that are in the future and have < 100%
chance of occurring while Issues are in the present and
have a 100% chance of occurring
Generally expressed in terms of impact/ probability and
cost
Risk tolerance is the degree of risk that an organization
can withstand in terms of financial impact and or damage
to reputation
Failure to understand the risks of a project generally leads to project failure
Example of a Project Lacking in Risk
Planning
A result of a poor risk assessment program
Risks and Project life cycle
Risk Management throughout
the Project Life Cycle

Monitoring and Control

Project
Initiation
Continuous Risk
Management
Project Execution
Monitor and Control
Project
Planning
Project
Controls


Risk management is not something that
is bolted on at the end of a project –
need to avoid a silo mentality
It is critical at all stages and requires
continuous monitoring and control
Needs to be scaled to the size of the
project
Needs to be fully integrated into the
project

Should be a standing agenda item on
at project meetings
No surprises leads to a successful
project!
What is on the Web about Risk?


Unlimited supply of information on risk management on the
web and can be a real challenge to wade your way through
it. (Google results –75 million hits for the words “risk
management”)
There are a few key guidelines and standards that stick out:








PMI PMBOK Guide (US and Canada)
PMI Practise Standard for Project Risk Management
Prince 2 (British)
AS NZS 4360: 2004 risk management standard
ISO 31000 (very new!)
Project Risk Analysis and Management Guide (PRAM)
RiskIT (targeted at IT projects)
BABok (targeted at accounting)
PMI® PMBok® Guide - 6 processes
Inputs
Outputs
•Risk Identification
•Risk Qualification
•Risk Quantitative
Analysis
•Risk response
development
•Risk response control
•Risk Identification and
prioritization
•Risk management plan
•Corrective action


PMI’s approach is the generally accepted
with in the profession in Canada and the US
Globally applicable
Risk IT®


Risk IT is an
excellent tool
focused on IT risk
Uses 3 domains
with goals and
metrics




Risk governance
Risk evaluation
Risk response
Very detailed tool
ISO 31000




Introduced in 2009
International risk
management standard
Seen as a replacement
for the AS NZS 4360
Adapted by CSA
Canada
ISO 31000
www.irr-neram.ca/pdf_files/ISO%2031000.pdf
Risk Management Plan




Detail how risk management will be structured and
executed for the project
Use to provide management with an overview of how
risks addressed
Can be a simple one page document or can be very
detailed– usually scaled to the project and the level of
risks
The lower the risk tolerance of the organization the
greater the need for a detailed plan
Failure to plan is planning for failure!
Example Contents for a Plan

Methodology:



Roles and Responsibilities








What approach will be used
What assessment tools will be utilized
Risk Response


How risks will be prioritized
What the assessment levels will be set at
Quantitative


What approach will be used for risk identification (Brainstorm, interview SAE, checklists)
Risk register format
Qualitative


At what milestones will risks be identified
How often will risk reviews be completed
Risk Identification


How will risk be funded – mitigation or occurrence
Risk Contingency – what are the authority levels for spending it
Scheduling


Ensure you have the right people at the table with the right levels of authority
Governance
Budgeting


What approach will be used
What tools will be used
What will be the response strategies
Monitoring and Control


Risk reviews, communications
Lessons learned
Paying for Risk



Well run projects usually identify part of the budget to
cover risk
Over and above the normal contingency carried on
projects for site conditions, client direction, design issues
etc.
The funds are for either:




Reducing impact of a risk by taking some action (eg hiring an
additional inspector)
covering the cost of a residual risk if it occurs
Access to this money is usually at a higher level within
the management.
Amounts range depending on the risk tolerance level of
the organization

PWGSC carries a large level of risk; very little risk tolerance within
its culture
Risk Identification






Done as early as possible in a project
Done often in a project
Start at a high level and move to a more detailed approach
once more project information is available
Bring in as many perspectives as you can
Identify opportunities as well as threats
Describe risks carefully –focus on cause and impact



Evaluate the impact on your projects objectives
For easier identification and management of risks divide
them into categories. As examples:





schedule slippage is not a risk – it is an outcome
Technical
External
Project Management ( internal team)
Organizational
Make sure all assumptions are clearly stated
Risk Breakdown Structure – (looks like a WBS!)
Technical
External
Organizational
Project
Management
Requirements
Regulatory (JHA)
Project
authorities
Estimating
Technology
Subcontractors/
supliers
Governance
Planning
Complexity an/or
interfaces
Market conditions
Resources
Controlling
Performance
Customers
Dependencies
Communications
Reliability
Weather
Funding
Quality
Site restrictions
Can be used for reports, Software development or anything
that fits a definition of a project. The following is an example
for a report on a new business opportunity
Research
Hypothesis
Report
preparation
Report
delivery
Requirements
Planning
Report
presentation
Previous
studies
Designing
drawings
rehearsals
interviews
Testing/
modeling
presentation
Question
Site visit
estimate
Printing/
binding
delivery
Economic
modeling
Industry specific:
Pharmaceutical Development
Clinical
Manufacturing
Regulatory
Organizational
Commercial
Project
Management
Toxicity
Complexity of
process
Local Regulatory
atmosphere
Resource
availability
Target population
Resources
Efficacy
Stability
International
requirements
Governance
Profitability
Technical
expertise
Drug interactions
Scale – up
Communications
Marketing
Schedule
constraints
Database
systems
Investment
required
Budget
constraints
Oil and Gas project example
Technical
Management
Commercial
Requirements
Strategy
Contractual
Technology
Organization
Financial
Interfaces
Project
Management
Regulatory
Performance
Resources
Agreements
Reliability
Communications
Reputation
Quality
Health and
Safety
Safety
Wellington Renovation Project
Design
Project
Environment
Organization /
Management
Contract/
Tender and
Award
Construction /
Commissioning
/ BCC
Heritage
Material costs
Governance
Contracting
requirements
Schedule
constraints
Site conditions
Labour
availability
Project team
Approval
process
Site
restrictions
Security
Public attitude
Funding
Contractibility
Safety
Technology
Competing
projects
commissioning
Risk Register



Tool used to capture the identified risks,
their impacts and probability and the
steps that need to be taken
Used as an interactive tool to monitor
progress of risk responses
Assigns responsibility for risk actions
Example risk sheet
Wellington
PROJECT:
RISK #
RISK OWNER:
DATE
REV #
DESCRIPTION:
LIKELIHOOD
CATEGORY
RISK NAME:
H
M
L
L
M
H
IMPACT
Score
RANK
4
LIKELIHOOD
IMPACT
@ risk K$/m o.
RESERVE
COST IMPACT
0
SCHEDULE IMPACT
0
QUALITY IMPACT
PUBLIC/POLITICAL IMPACT
PAA
RESPONSE
#
ACTION
WHO
CLOSURE
WHEN
Organization /
Management
Open
Unclear governance and
approval structure
Design
Open
Security design
Design
Open
Lessons learned from La
accoustics and FFE. Benefitting from lessons learned THIS
Prom with regard to
IS AN OPPORTUNITY - this should apply to lessons learned
MM/ISS; design
at LaProm and at RCR
3600
Delays to completing the design
leading to delays in over all
schedule
H
H
H
9
Reduce
9.7
cost savings could be made by
avoiding rework
H
H
M
8
Reject
develop enhance goverance tools and
decision making tools
H
M
M
7
Thierry Montpetit
M
M
M
5
thierry Montpetit
Mod
H
H
M
7
Thierry Montpetit
Easy Imminent
H
L
M
6
Thierry Montpetit
Diff
clearly lay out security requirements in the
contract document- try to remove the
0
security requirements from stage 1,
nothing done for stage 2 at this time
L
L
L
1
Henri Behamdouni
Easy Distant
build a mock up for design and for
constructability
M
M
L
4
Henri Behamdouni
Mod
Mid Term
M
M
M
5
Thierry Montpetit
Mod
Overdue
M
M
M
5
Thierry Montpetit
Diff
Imminent
H
M
H
8
Thierry Montpetit
Diff
Overdue
M
M
L
4
Thierry Montpetit
Diff
Imminent
M
L
M
4
Matthew Delean
Mod
Overdue
present options to the Senate and HoC to
2430 establish an implementation strategy for 1800
the security systems in the building
Application of lessons learned impacting the MM/ISS,
-$960 information for accoustics, MM/ISS and
delays of up to 2 years if the funds
are not realized and GC method H
of contracting required
H
M
8
Reduce
13.0
Contract / Tender
Open
& Award
Security clearance levels
cause delay
security clearance requirements will become more restrictive;
impacts the trades by restricting who can enter and add
delays getting workers on the site,
delays. If access to the work site is restricted for any reason,
unplanned shutdowns and
M
there could be delays in construction that add cost to the
restricted hours of work
project. This includes proposed enhanced security clearance
requirements currently being developed
H
M
7
Reduce
1.44
$960
Construction /
Commissioning / Open
BCC
not meeting the STC
Challanging STC rating is difficult to meet - requires extensive delays due to inspection
requirement on the offices quality checks
restrictions
H
M
H
7
Reduce
2.9
240
Contract/ Tender
Open
and Award
Ability to issue the 4 trade RPCD may not approve the idea to have PWGSC issue 4
packages
trade packages with PCL as the constructor
need these packages to recover
schedule loss
H
M
H
7
Reduce
2.1
Wellington team to work with PCL to
0 address the issues relating to Div 1 and
impact on contracts
Contract/ Tender
Open
and Award
RPCD does not support
using CM
delays getting the project back on
H
schedule
H
M
7
Reduce
3.8
0
Project
Environment
Open
Construction /
Commissioning / Open
BCC
Design
Open
RPCD is unfamiliar with using CM with a GMP
Negative perception of
project
Project could be viewed as MPs spending money on
themselves rather than an infrastructure project that
benefits the public. Lack of communication, competing
priorities for funding Update - project did receive partial
funding in April 2010 through the MC
Schedule slippage
Schedule slippage increases greater than current 6 month
delay
Changing Technology
End Date
31-Mar-09
22-Aug-10
01-Aug-08
27-Nov-14
31-Oct-15
22-Aug-16
01-Dec-08
22-Aug-09
31-Oct-08
22-Aug-16
Overdue
0
Furniture
MC process restricts access to funding - limiting contracting
ability. Puts the project at risk of being cancelled
Open
Overdue
Start Date
setting up workshops to capture
-1.92
Lack of Available funds
Organization /
Management
0
Owner
Proximity
4.32
Manageability
Reduce
Score
9
Cost
H
Schedule
H
Type
Probability
significant delays could occur due
to lack of understanding of
H
decision making process on
complicated issues
Impact
note: Additional responses
highlighted on individual risk sheets
Total Cost
budget impact
(k$)
Approver may be known but process of gaining necessary
approvals is unknown
Procedures change often. Process of gaining approvals is
unclear. Lack of access to decision makers due to
organizational hierarcy. This has been elevated - governance
recognized as a central issue and risk
To date a security consultant has not been assigned to the
project. This will be a critical function to allow the design to
move forward for the base Building and Fit up. Update:
Services have been tendered and a proponent is waiting on
Contracting to give the Green Light
Score
Description
Cost
Title
Schedule
Status
Probability
RBS
schedule impact
(months)
Example risk register
move to CM approach to allow multiple
540 smaller contracts to be awarded with the
available funding
1000
piggy back on the work underway at West
Block
Exploit business case - forward plan $0 promote fully funding project as a
positive way to create Canadian jobs
Negative publicity;completion of
M
project may be delayed
M
H
6
Accept
0.58
increased time
H
M
M
6
Reduce
3.8
640
break out smaller packages to advance
some work
Technology will likely change between now and 2015; design
assumptions is based on what is currently available;
Decisions may be made too late;
Introduction of new technology may supercede what has been delays to design; delays to
M
done; decisions may be delayed to incorporate best possible schedule
technical solutions.
L
M
5
Reduce
1.08
$1,800
establish a design process that allow a
late selection on technology
50000
0
Imminent
Qualitative Risk Analysis


Ranking of the risks relative to each other, based on the impact
on the project
Most simply:









High
Medium
Low
Agree upon prior to assessing risks
Assessed prior to taking any risk response and again after to
help determine any residual
Reassess throughout the project as the it evolves and external
conditions change
Risks are typically defined by their Probability of Occurrence
and the Impact they would have on the project if they occurred.
An easy approach that most understand
Consistency in applying the concepts is key in identifying the
critical risks
Risk Qualification
Risk Scoring
PROBABILITY SCALE
Low
1% to 20%
Event is unlikely to happen
Medium
20% - 67%
Event may reasonably occur
High
67%-99%
Event is likely to occur
Medium
>1 week and <4 weeks
>100 k$, < 500 k$
could impact functionality
signficiant neg press coverage
High
greater than 4 weeks
Greater than 500 k$
does not meet requirements
severe impact to reputation
IMPACT SCALES AND TYPES
Low
less than 1 wk
less than 100 k$
minor issues
minor impact
Schedule
costs
Quality
political
IMPACT
Probability and Impact Scoring
Low
4
3
1
High
Medium
low
PROBABILITY
Medium
7
5
3
High
9
7
4
KEY
Up to 3
low
4 to 6
med
7 to 9
high
5 x 5 matrix
Im pact
Likelihood
Low
Medium-Low
Medium
Medium-High
High
High
6
7
8
9
10
Medium -High
5
6
7
8
9
Medium
4
5
6
7
8
Medium -Low
3
4
5
6
7
Low
2
3
4
5
6
NB: 2 l owest combined score (impact + l ikelihood), 10 hi ghest combined score (impa ct + l ikelihood)
Heat maps
http://www.tbs-sct.gc.ca/tbs-sct/rm-gr/guides/gcrp-gepro03-eng.asp
PWGSC corporate risk approach
Project Risk based on objective
relative weighting
objective
cost
time
scope
relative weight
15%
60%
25%
name of risk
risk type
political pressure
external
STC rating not met
technical
organzational funding not approved
Project objectives weighted
independently from the risks
prob
4
7
9
cost
2
4
6
impact
time
8
6
8
scope
0
4
3
cost
8
28
54
Risk Score
time
32
42
72
Risk score
calculated by
multiplying
probability by impact
scope
0
28
27
total
score
20.4
36.4
58.05
Total score is the sum of
the risk score x the
objective relative weight
Alternate ways of communicating
Risks
Risk #
Risk
risk 0
risk 1
Inflation
Unforeseen building conditions
M
L
M
L
4
1
risk 11
risk 12
risk 14
Change in Key personnel
Changes in Government Policy
Stakeholder responsibility for Project
Outcomes
Undefined Security requirement
Dependency on other projects
M
L
H
M
M
M
4
2
6
M
H
L
H
2
9
H
L
M
L
6
1
risk 38
risk 4
Changing technology
Undefined Emergency Services
Requirement
Loss of Corporate Knowledge
Lack of PWGSC resources
M
M
M
L
4
4
risk 41
risk 42
Heritage restoration
Access to site
L
H
L
M
1
6
risk 43
risk 45
risk 46
Principal consultant’s shortage
Lengthy approval process
Expanding shale
L
H
L
M
L
L
2
3
1
risk 7
risk 9
Sound proofing
Lack of mobilization Space
M
H
L
M
2
6
risk 15
risk 16
risk 27
risk 33
probability impact
score
Quantitative Risk Analysis






A more sophisticated approach to risk analysis
Provides numerical analysis of the impact of all risk simultaneously on top
project objectives
Provide “what if” scenario opportunities
Helps to more accurately identify risk that are high priority and where risk
response can have the greatest impact
Often is used to help determine contingency
Software is used for this approach






Pertmaster (Primavera)
@ Risk
Crystal Ball ( now owned by Oracle)
Monte Carlo simulation approach
Based on optimistic, realistic and pessimistic views and can be set under a
number of different distribution models including triangular, Beta, uniform or
Normal distribution
Can provide correlation between schedule elements that are impacted by
the same forces
Outputs




Outputs provide histograms showing the
certainty of the project objective (schedule or
budget) and the likelihood of delivery the project
at the expected levels
Schedule models help define what items critical
even if they are not on the critical path
Allows contingencies to be established
Tornado diagrams help to illustrate the items
with the highest level or correlation and
therefore what is driving project uncertainty
Output example: Histogram
Example of output: Tornado
Other Tools






Probability Analysis
Delphi Method
Monte Carlo
Decision Tree Analysis
Utility Theory
Decision Theory
Risk Response
Reduce
Share
Avoid


Risk/
opportunity
Transfer
Expoit
Enhance
Finance (Accept)


Determine root cause
Avoid, mitigate or transfer
where possible
Develop contingency plans
for significant risks
Document and review
regularly
Risk Triggers



Events or actions that move a risk from a
probability of <100%
Important to be able to identify what the
triggers are for risks where possible
Once triggered they are no longer a risk
– they now are issues that will need to
be addressed
Monitoring and Controlling




Ongoing risk monitoring is one of the hardest parts of
managing risks
Involve as many stakeholder and SME as possible
Have separate reviews for risk on large projects or
incorporate in team meetings on smaller ones
Timing for reviews:




Report risks



Key milestones
At least once per year
After trigger points occur on top risks
Report top 10 risks monthly
Create a risk dashboard or one pager
Lever Lessons Learned

Run lesson learned sessions after key milestones or phases in the project
Do it all over again!

Repeat the cycle





Meaningful times in the project
Key milestones
Not less than once per year
At times of significant change in the project – between
end of design and start of constructions
Can do mini risk reviews on specific project element
during the project to assist in decision making
Conclusion


Make Risk a part of your project just like
cost and schedule
Make sure you understand the risk
tolerance of your organization


Tailor the risk plan to fit the project


Get the appropriate level of resources you need to match
Make use of the appropriate tools that are available
Communicate, communicate, communicate!

Get it on as a standing item on the team meetings agenda
Reading opportunities

Enterprise Risk Management – Integrated
framework


Project and Program Risk Management – A guide to
managing project risks and opportunities



Max Wideman, Editor, Project Management Instit
A Guide to project Management Body of Knowledge
– PMBOK 4th Edition
Identifying and Managing Project Risk – Essential
Tools for failure proofing Your project


www.theiia.org/iia/download.cfm?file=9229
Tom Kendrick
Risk and Decision Analysis in Projects

( 2nd ed) – John Schuyler
Another video in closing
Project Scenario: Alice in Wonderland



It almost time for the Queens Engineering Science Formal,
listed as one of the Ten Best Black Tie events in North America
Science Formal is a massive student run project with a $80 000
budget, 35 000 hours of construction, 600 students and a year's
worth of careful planning to produce.
Your project is head organizer of this Formal
and you need a Risk Management Plan:




Build a Risk Breakdown Structure
Brainstorm risks
Rank risks (Probability of occurrence, impact cost,
schedule)
Develop risk response for High risks
Photos from past Formals