Transcript Project Risk Symposium

November 5-6, 2009
Copyright © 2009 PMI RiskSIG
A collaboration of the
PMI, Rome Italy Chapter
and the RiskSIG
“Project Risk Management –
An International Perspective”
RiskSIG - Advancing the State of the Art
Organizational Project Risk
Management

Using PMI®’s Latest Standards
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 2
Objectives
Understand the characteristics of portfolios,
programs and projects that affect risk
management
 Develop the basis of an Organizational
Project Risk Management model

November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 3
Discovering
Organizational Project
Management
The application of knowledge, skills, tools
and techniques to organizational
management, as well as to project, program
and portfolio activities to achieve the aims
of the organization through projects.
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 4
Organizational Project Risk
Management

The integrated set of coherent risk
management practices within the
organizational project management
environment
It is the rock on which to
build the separate
risk management policies
and practices for each domain
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 5
Agenda
Structural view
 Risk Management across all three domains

Portfolios, programs and projects
• and the interdependencies

A model to link and align the different
domain risk management processes and
activities
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 6
The Structural View

Overview of the domains: portfolio,
program, project
link to mission, vision and action

Top-down view of the scope of
responsibilities
Aligning the domains
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 7
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 8
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 9
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 10
Understanding the Domains:
Portfolios and Programs
The overall intention is to achieve a value-added
change

Project Portfolio Management
 aims at strategic objectives.
• It charters…

Program Management
 to provide the benefits that the strategy requires.
• This domain charters…
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 11
Understanding the Domains:
Projects … and Operations

Project Management
 to create the deliverables defined within the
specification of the corresponding program component.
• All of these lead to…

Operations,
 to provide ongoing value-added service to the customer
based on the capabilities and deliverables originating
from the three other domains.
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 12
Domain Neighbourhood
Terminology

Component level and Sponsor level
Portfolio
Sponsor
level
Component
level
Program
Sponsor
level
Component
level
Project
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 13
The World of Organizational
Change Management

The basis for change:
 Vision – what the end state will look like
 Mission – what needs to be achieved
 Action – what needs to be done

Two additional definitions are also needed:
 Governance – how it needs to be controlled
 Objective – a description of how success will be
evaluated.
• This is normally based on the mission statement, with the
addition of success metrics.
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 14
The World of Organizational
Project Management
The OPM environment is controlled by five interconnected systems
1.
2.
3.
4.
5.
Strategy, rules and vision.
 The ultimate authority
Planning for organizational change: defining the mission.
 Planning to ensure long term viability.
Operational control.
 Regulating tactical activities.
Monitoring and reporting.
 Information collection and initial processing.
Action.
 Planning and implementation to achieve the mission.
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 15
Key Messages on Structure
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 16
Message (1 of 2)

The dominion of each domain
 Effective allocation of responsibilities and teamwork requires a
clear definition of the type of outcome required from the work:
• Project Portfolio Management aims at strategic objectives.
• Program Management provides the benefits that the strategy
requires.
• Project Management creates the deliverables defined within
the specification of the corresponding program component.
• Operations provides ongoing value-added service to the
customer based on the capabilities and deliverables originating
from the three other domains.
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 17
Message (2 of 2)

Visualizing the outcome
 A coherent picture of what is required and how it is to
be achieved requires a structured approach:
• Vision – what the end state will look like.
• Mission – what needs to be achieved.
• Action – what needs to be done
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 18
Implications for Risk
Management

The risks are
in the components,
between the components,
and inherent to the overall structure and content
Senior Management
Portfolio
Portfolio
Program
Project
Non-Project
Program
Project
Project
Project
Project
Project
Project
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 19
Domain Project
Risk Management


Defining risk consistently for all domains
Risks in portfolios
 Linking to programs or projects

Risk in programs
 Linking back to portfolios
 Linking to projects

Risks in projects
 Linking back to programs or portfolios

Risk sharing between domains
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 20
Defining Risk

Risk is “significant uncertainty”
• (Thank you David Hillson!)
What is significant depends on what matters to
you
For portfolios, it is achieving the strategy
 For programs, it is the outcomes and their
benefits
 For projects, it is related to the deliverables

November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 21
A risk is …

An event or series of events that could
affect the success of the endeavour
the effect is measured in terms of the effect on
the corresponding success parameters
• … for better or for worse
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 22
Types of Portfolio Risk

Structural risks
 From the composition of the portfolio
• Interactions, resources, etc.
 From the way the portfolio is managed
• governance risks – maybe a separate category

Component risks
 at the strategic portfolio level
 or escalated from the program domain

Overall risks
 The conjugated effect of the risks
• they do not even sum statistically!
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 23
Charting Portfolio Risks
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 24
Steps in Portfolio Risk
Management
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 25
Portfolio Processes and Risk
Management
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 26
Linking Portfolio Management to
the other Domains
Component
Execution &
Reporting
Develop
Portfolio Risk
Responses
Monitor and
Control
Portfolio Risks
Identify
Portfolio
Risks
Authorize
Components
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 27
The Missing Link?

Develop Portfolio Risk Responses may need
action from a component
There is a need for the following output
parameter: Directives Regarding Components
• This comes from Review and Report Portfolio
Performance!
– It is not clear how Develop Portfolio Risk Responses
communicates with this process
• It also needs to be an input to the Program and the
Project Management change control process
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 28
Program Risks

Business environment
 Any conflict with the portfolio?

Portfolio-related
 Whose priority matters?

Program-level (structural)
 Related to the architecture, “roadmap” and benefits map

Impacts on benefits and outcomes
 The combined effects of component risks

Operations level
 Related to transitioning components
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 29
Charting Program Risks
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 30
Linking to the Program
Components

In the same way as for portfolios, the
program-level risk response planning
process may have to invoke change control
within its components
In this case by invoking project-level Integrated
Change Control or the Control Scope process
• Direct and Manage Program Execution needs an
extra Output: Program Component Directive
– That becomes an Input for the component-level change
management process
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 31
Project Risks

From the point of view of integrated risk
management it is important that the project
manager has
Full authority of the risks within their level of
authority
An understanding of the success criteria at the
sponsor’s level
The ability to escalate effectively any issues
outside their control
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 32
Delegated Risks

Risks can be delegated to the components:
These are risks the domain manager feels would
be better dealt with at the component level
There needs to be a delegation (and negotiation)
process for the component manager to
incorporate the work into their scope
• Once again this should be included in the change
management process at the component level
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 33
Escalated Risks

Effective communication must be two-way
In the same way that risks and actions can be
delegated to components,
the components must have the ability to
escalate issues and requests back to the
sponsor-level
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 34
Linking back from the
Program

Some program-level decisions or actions
may be beyond the level of authority of the
component manager
This can be linked through the Program Issues
Register – which is managed at the program
level
• But Provide Governance Oversight needs to have a
new parameter, Escalation Request as an Output
– and this needs to be an Input to a Portfolio Management
Process (Review and Report Portfolio Performance)
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 35
Project Escalation

In the same way as for programs, project
managers need to be able to request support
from the sponsor-level
e.g. by issuing an Escalation Request
This is missing from the PMBOK® Guide
• There is no coordinated issue management process
• Direct and Manage Project Execution could be the
right place for it
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 36
Organizational Project
Risk Management
Aligning domain risks
 Process communications between domains
 Risk consolidation between domains
 Future work

November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 37
Alignment of Risks
In order to allow each domain to be
“interested” in the risks of the related
domains, their risks must be aligned
 This requires that their definitions of
“significance” should be consistent with
each other

November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 38
Aligning Success Criteria
Vision
Project Mgmt
Mission
Project Mgmt
Action
Project Mgmt
Action
Program Mgmt
Mission
Program Mgmt
Vision
Program Mgmt
Action
Portfolio Mgmt
Mission
Portfolio Mgmt
Vision
Org. Strategy
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 39
Delegation and Escalation
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 40
Delegation between Domains

Where should the other domain’s risk “hand-offs”
be handled initially?
• as a Portfolio or Program Component Directive
 Out from?
• Governance (portfolios) or Integration Management
(programs)
 In to?
• I suggested Change Management
 Effect
• The delegator remains accountable for the risk at their level
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 41
Escalation between Domains

The PMBOK® Guide does not provide
projects with any links to intractable issues
This would belong in Integration
• to issue a Project Escalation Request

Programs do have an issue management
process
Governance needs to be able to
Both of
which are
MISSING
from the
standards
• issue a Program Escalation Request
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 42
Future Work:
Domain Consolidation

“No domain is an island”
Consolidating risks up the model
• Consolidating “composite” risks
• Consolidating contingency
• Overall domain risk

Here are 3 questions I will leave you with
I do not have the answers
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 43
Consolidating Component
Risks and their Causes

How to address risks in several components
that, individually are “not significant”
But could sum to be significant
Depend on the same root cause

Asking component managers for too much
risk information leads to overload
Too little and you miss these “composite” risks
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 44
Consolidating Contingency

Consider contingency buffers
• … only those rolled-up from the project level
How should the program portfolio contingency
buffers be calculated?
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 45
Overall Risk Exposure

Assuming you know the risk profile for
each component
• Impact-probability distribution
How should you calculate the sponsor-level
overall risk
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 46
Final Word

Align the levels
Vision, mission, action

Link the processes
across the levels

Consolidate the overall risk
From one level to the next
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 47
Time for Questions
Crispin (“Kik”) Piney, B.Sc., PgMP
+33 (0)680 11 57 77
[email protected]
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
Slide 48
November 5-6, 2009
Copyright © 2009 PMI RiskSIG
A collaboration of the
PMI, Rome Italy Chapter
and the RiskSIG
“Project Risk Management –
An International Perspective”
RiskSIG - Advancing the State of the Art