1. Copyright © 2009 PMI RiskSIGNovember 5-6, 2009 “Project Risk Management – An International Perspective” RiskSIG - Advancing the State of the Art A collaboration of the PMI, Rome Italy Chapter and the RiskSIG

2. Slide 2November 5-6, 2009 Copyright © 2009 PMI RiskSIG Organizational Project Risk Management u Using PMI ® ’s Latest Standards

3. Slide 3November 5-6, 2009 Copyright © 2009 PMI RiskSIG Objectives u Understand the characteristics of portfolios, programs and projects that affect risk management u Develop the basis of an Organizational Project Risk Management model

4. Slide 4November 5-6, 2009 Copyright © 2009 PMI RiskSIG 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.

5. Slide 5November 5-6, 2009 Copyright © 2009 PMI RiskSIG Organizational Project Risk Management u 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

6. Slide 6November 5-6, 2009 Copyright © 2009 PMI RiskSIG Agenda u Structural view u Risk Management across all three domains  Portfolios, programs and projects and the interdependencies u A model to link and align the different domain risk management processes and activities

7. Slide 7November 5-6, 2009 Copyright © 2009 PMI RiskSIG The Structural View u Overview of the domains: portfolio, program, project  link to mission, vision and action u Top-down view of the scope of responsibilities  Aligning the domains

8. Slide 8November 5-6, 2009 Copyright © 2009 PMI RiskSIG

9. Slide 9November 5-6, 2009 Copyright © 2009 PMI RiskSIG

10. Slide 10November 5-6, 2009 Copyright © 2009 PMI RiskSIG

11. Slide 11November 5-6, 2009 Copyright © 2009 PMI RiskSIG Understanding the Domains: Portfolios and Programs The overall intention is to achieve a value-added change u Project Portfolio Management  aims at strategic objectives. It charters… u Program Management  to provide the benefits that the strategy requires. This domain charters…

12. Slide 12November 5-6, 2009 Copyright © 2009 PMI RiskSIG Understanding the Domains: Projects … and Operations u Project Management  to create the deliverables defined within the specification of the corresponding program component. All of these lead to… u Operations,  to provide ongoing value-added service to the customer based on the capabilities and deliverables originating from the three other domains.

13. Slide 13November 5-6, 2009 Copyright © 2009 PMI RiskSIG Domain Neighbourhood Terminology Portfolio Program Project Component level Component level Sponsor level Sponsor level u Component level and Sponsor level

14. Slide 14November 5-6, 2009 Copyright © 2009 PMI RiskSIG The World of Organizational Change Management u The basis for change:  Vision – what the end state will look like  Mission – what needs to be achieved  Action – what needs to be done u 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.

15. Slide 15November 5-6, 2009 Copyright © 2009 PMI RiskSIG The World of Organizational Project Management The OPM environment is controlled by five interconnected systems 1.Strategy, rules and vision.  The ultimate authority 2.Planning for organizational change: defining the mission.  Planning to ensure long term viability. 3.Operational control.  Regulating tactical activities. 4.Monitoring and reporting.  Information collection and initial processing. 5.Action.  Planning and implementation to achieve the mission.

16. Slide 16November 5-6, 2009 Copyright © 2009 PMI RiskSIG Key Messages on Structure

17. Slide 17November 5-6, 2009 Copyright © 2009 PMI RiskSIG Message (1 of 2) u 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.

18. Slide 18November 5-6, 2009 Copyright © 2009 PMI RiskSIG Message (2 of 2) u 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

19. Slide 19November 5-6, 2009 Copyright © 2009 PMI RiskSIG Implications for Risk Management u The risks are  in the components,  between the components,  and inherent to the overall structure and content Senior Management Portfolio Program ProjectNon-ProjectProject Program Project Portfolio Project

20. Slide 20November 5-6, 2009 Copyright © 2009 PMI RiskSIG Domain Project Risk Management u Defining risk consistently for all domains u Risks in portfolios  Linking to programs or projects u Risk in programs  Linking back to portfolios  Linking to projects u Risks in projects  Linking back to programs or portfolios u Risk sharing between domains

21. Slide 21November 5-6, 2009 Copyright © 2009 PMI RiskSIG Defining Risk u Risk is “significant uncertainty” (Thank you David Hillson!)  What is significant depends on what matters to you u For portfolios, it is achieving the strategy u For programs, it is the outcomes and their benefits u For projects, it is related to the deliverables

22. Slide 22November 5-6, 2009 Copyright © 2009 PMI RiskSIG A risk is … u 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

23. Slide 23November 5-6, 2009 Copyright © 2009 PMI RiskSIG Types of Portfolio Risk u Structural risks  From the composition of the portfolio Interactions, resources, etc.  From the way the portfolio is managed governance risks – maybe a separate category u Component risks  at the strategic portfolio level  or escalated from the program domain u Overall risks  The conjugated effect of the risks they do not even sum statistically!

24. Slide 24November 5-6, 2009 Copyright © 2009 PMI RiskSIG Charting Portfolio Risks

25. Slide 25November 5-6, 2009 Copyright © 2009 PMI RiskSIG Steps in Portfolio Risk Management

26. Slide 26November 5-6, 2009 Copyright © 2009 PMI RiskSIG Portfolio Processes and Risk Management

27. Slide 27November 5-6, 2009 Copyright © 2009 PMI RiskSIG Linking Portfolio Management to the other Domains Identify Portfolio Risks Develop Portfolio Risk Responses Monitor and Control Portfolio Risks Authorize Components Component Execution & Reporting

28. Slide 28November 5-6, 2009 Copyright © 2009 PMI RiskSIG The Missing Link? u 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

29. Slide 29November 5-6, 2009 Copyright © 2009 PMI RiskSIG Program Risks u Business environment  Any conflict with the portfolio? u Portfolio-related  Whose priority matters? u Program-level (structural)  Related to the architecture, “roadmap” and benefits map u Impacts on benefits and outcomes  The combined effects of component risks u Operations level  Related to transitioning components

30. Slide 30November 5-6, 2009 Copyright © 2009 PMI RiskSIG Charting Program Risks

31. Slide 31November 5-6, 2009 Copyright © 2009 PMI RiskSIG Linking to the Program Components u 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

32. Slide 32November 5-6, 2009 Copyright © 2009 PMI RiskSIG Project Risks u 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

33. Slide 33November 5-6, 2009 Copyright © 2009 PMI RiskSIG Delegated Risks u 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

34. Slide 34November 5-6, 2009 Copyright © 2009 PMI RiskSIG Escalated Risks u 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

35. Slide 35November 5-6, 2009 Copyright © 2009 PMI RiskSIG Linking back from the Program u 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)

36. Slide 36November 5-6, 2009 Copyright © 2009 PMI RiskSIG Project Escalation u 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

37. Slide 37November 5-6, 2009 Copyright © 2009 PMI RiskSIG Organizational Project Risk Management u Aligning domain risks u Process communications between domains u Risk consolidation between domains u Future work

38. Slide 38November 5-6, 2009 Copyright © 2009 PMI RiskSIG Alignment of Risks u In order to allow each domain to be “interested” in the risks of the related domains, their risks must be aligned u This requires that their definitions of “significance” should be consistent with each other

39. Slide 39November 5-6, 2009 Copyright © 2009 PMI RiskSIG Is my domain’s significance relevant to yours? Aligning Success Criteria Vision Project Mgmt Vision Program Mgmt Mission Program Mgmt Mission Portfolio Mgmt Action Program Mgmt Action Portfolio Mgmt Vision Org. Strategy Mission Project Mgmt Action Project Mgmt

40. Slide 40November 5-6, 2009 Copyright © 2009 PMI RiskSIG Delegation and Escalation

41. Slide 41November 5-6, 2009 Copyright © 2009 PMI RiskSIG Delegation between Domains u 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

42. Slide 42November 5-6, 2009 Copyright © 2009 PMI RiskSIG Escalation between Domains u The PMBOK ® Guide does not provide projects with any links to intractable issues  This would belong in Integration to issue a Project Escalation Request u Programs do have an issue management process  Governance needs to be able to issue a Program Escalation Request Both of which are MISSING from the standards

43. Slide 43November 5-6, 2009 Copyright © 2009 PMI RiskSIG Future Work: Domain Consolidation u “No domain is an island”  Consolidating risks up the model Consolidating “composite” risks Consolidating contingency Overall domain risk u Here are 3 questions I will leave you with  I do not have the answers

44. Slide 44November 5-6, 2009 Copyright © 2009 PMI RiskSIG Consolidating Component Risks and their Causes u How to address risks in several components that, individually are “not significant”  But could sum to be significant  Depend on the same root cause u Asking component managers for too much risk information leads to overload  Too little and you miss these “composite” risks

45. Slide 45November 5-6, 2009 Copyright © 2009 PMI RiskSIG Consolidating Contingency u Consider contingency buffers … only those rolled-up from the project level  How should the program portfolio contingency buffers be calculated?

46. Slide 46November 5-6, 2009 Copyright © 2009 PMI RiskSIG Overall Risk Exposure u Assuming you know the risk profile for each component Impact-probability distribution  How should you calculate the sponsor-level overall risk

47. Slide 47November 5-6, 2009 Copyright © 2009 PMI RiskSIG Final Word u Align the levels  Vision, mission, action u Link the processes  across the levels u Consolidate the overall risk  From one level to the next

48. Slide 48November 5-6, 2009 Copyright © 2009 PMI RiskSIG Time for Questions Crispin (“Kik”) Piney, B.Sc., PgMP +33 (0)680 11 57 77 kik@PROject-beneFITS.com

49. Copyright © 2009 PMI RiskSIGNovember 5-6, 2009 “Project Risk Management – An International Perspective” RiskSIG - Advancing the State of the Art A collaboration of the PMI, Rome Italy Chapter and the RiskSIG