If this presentation is of interest visit http://www.bpugcongress.com to find out when the next event is taking place. Presentation by: John Fisher - Director, UnconfuseU Ltd & Chief Examiner, M_o_R® Many people recognise PRINCE2® and M_o_R as sister products, coming from the same OGC /APM Group stable. This view however misses an important concept that this are not sister products but a marriage between two methodologies. Very little has been published on how these two different methodologies integrate. This presentation takes the very simple concept of a single project run under the PRINCE2 methodology and shows how M_o_R can be integrated to produce an all encompassing approach that manages risk in an effective and efficient way. The presentation discusses the current (2005) version of PRINCE2 and maps it across to M_o_R demonstrating several useful approaches that Project and Risk Managers can take. Using examples throughout, the audience will gain practical understanding of the power and ease as to how to join these two methods on their projects.

1. The PRINCE2 Cityscape logo™ is a Trade Mark of the Office of Government Commerce in the United Kingdom and other countries
MSP™ is a Trade Mark of the Office of Government Commerce
M_o_R® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries
The Swirl logo™ is a Trade Mark of the Office of Government Commerce
BPUG 2009
Integration of PRINCE2™and MoR®

2. 10 things from MoR® that
can help your PRINCE2™
Project today

3. The problems
• MoR® is seen as completing the set of
three
• PRINCE2™ light on risk management
• PRINCE2™ projects still failing to manage
risk

4. Evidence
• Delivering training in both PRINCE2™ and
MoR®
• Marking MoR® Practitioner Papers
• Reviewing many projects over many years
• Role as Risk Manager
• NAO Reports

5. Solution?
• PRINCE2™ 2009
• Until then:
– Many concepts in MoR® that can be applied
to PRINCE2™ projects
– Simple, low cost but very effective

6. 1. Identifying the Context

7. Multiple use of Context in
PRINCE2™
SU4 Preparing a
Project brief SB4 Updating
The Risk Log
CS1 – MP1
Agreeing a
Work Package

8. Context Techniques
RACI
SWOT
PESTLE
PROCESS MAPS

9. 2. Risk Descriptions

10. Poor Risk Description

11. Preferred Approach
• Risks should be described in a clear and
unambiguous way
• The preferred approach is:
– Risk Cause (source of risk)
– Risk Event (threat or opportunity)
– Risk Effect (impact should it arise)

12. Question
• Is the following a well defined risk?
– Because of poor security vetting procedures
– There is a risk that an inappropriate person is
employed
– Which might mean that company secrets are
leaked to the press
So what?

13. Why is this Important?
• Description linked to mitigation actions
• Options include:
– Remove the cause
– Reduce (threat) or maximise (opportunity) the
likelihood of the event
– Reduce the effect (impact)

14. 3. Estimating for risk

15. Probability and Impact
• Projects don’t always define the estimation
scoring
• Qualitative assessment means different
view points and therefore different scores
• What do you really mean when you say a
risk has a “medium probability”?

16. Measuring Probability
Probability Criteria
Very High > 75%
High More likely to occur than not: 51%- 75%
Medium Fairly likely to occur: 26 – 50%
Low Low but not impossible: 6 – 25%
Very Low Virtually impossible: 0 – 5%
©Crown Copyright 2005 Reproduced under licence from OGC

17. Different Impacts
• Some risks will have an
impact on one or more of:
– Cost
– Time
– Resources
– Quality
– Scope
– Benefits
– Security
• Need to consider multiple
impacts.

18. 4. Appetite and Tolerance

19. Appetite and Tolerance – The
Difference
• Risk Appetite:
– Attitude towards risk taking
– Willingness to tolerate a situation
– What is and what is not acceptable
• Tolerance
– Levels of exposure which when exceeded
trigger a response
– How bad does it have to be before I escalate?

20. Appetite and Tolerance
Summary
Corporate or
Programme Appetite – 20 days delay
Management
Project Board Tolerance – 15 days delay
Project Manager Tolerance – 10 days delay

21. 5. Aggregated Risk

22. What is Aggregation?
• Aggregation is the net effect of the threat
and opportunity assessments when
combined together
• In other words “what if several risks
materialise at the same time”?
• PRINCE2™ doesn’t consider this
eventuality

23. Example
• The project has identified 3 risks causing delay to
the project:
– Risk 3 – an additional 5 days for user training
– Risk 7 – extra 4 day delay to training due to staff
sickness
– Risk 12 – delay of 10 days due to staff unavailability
for training because of operational needs
• If Project Board Risk Tolerance is 15 days,
aggregated risk exceeds this.

24. 6. Risk Owners

25. Different Definitions
• PRINCE2™:
– Risk owner should be the best person to keep an
eye on the risk
• MoR®:
– named individual who is responsible for the
management and control of all aspects of the
risks assigned to them, including the
implementation of the selected actions to address
the threats or to maximise the opportunities.

26. 7. Mitigation Actions

27. Choosing What to do
• Prevent – Remove the cause
• Reduce – Carry out an action to reduce the
probability and or impact of the risk
• Accept – The risk is below the agreed risk
appetite for the risk
• Contingency – Carry out an action to reduce
the impact of the risk when it occurs

28. Transference
• You can only transfer the financial aspects
of a risk
• Giving the risk to someone else isn’t
necessarily transferring the risk
• Common transference actions include
penalty clauses and insurance

29. Mitigation Actions and Appetite
Inherent Risk Residual Risk Risk Appetite
Where
Start Point Where we are we want
to be

30. Mitigation Actions and Appetite
Inherent Risk Risk Appetite Residual Risk
Where
Start Point we want Where we are
to be

31. Mitigation Actions and Appetite
Inherent Risk Risk Appetite
Residual Risk
Where we are
Start Point is where we
want to be

32. 8. Reporting Risk

33. No Risk Reporting in
PRINCE2™?
• PRINCE2™ reports don’t have risk in their
Annex A Product Descriptions
• Risk reporting can be integrated into
Checkpoint or Highlight Reports
• Standard measures include:
– Summary Risk Profiles
– Dashboard metrics

34. Possible Reporting Mechanisms
• Dashboard Metrics:
– New risks this period
– Closed risks this period
– BRAG Totals:
• Black 2
• Red 8
• Amber 15
• Green 1
– Trend Summary
(number rising, falling or
neutral)

35. 9. Learn the Lessons

36. Experience is the Best Teacher
• What do you do:
– When a risk materialises that you didn’t
identify?
– A mitigation didn’t work?
– Risk owners don’t own the risk?

37. Lessons Learned Log
• Make sure you review what happened and
document it
• Make changes to your risk management
processes if they aren’t working
• Carry out regular risk Healthchecks
• Formal update in SB5 Reporting Stage
End – but don’t wait that long if its urgent!

38. 10. Manage Risk

39. The Missing Piece
• Many projects:
– Have a Risk Log
– Populate the Risk Log with output from risk
workshops
– Define good risks and mitigation actions
– Totally ignore risks until the next Project
Board meeting

40. Missed Opportunities to Review
Risks
• Risk should be reviewed throughout:
– Planning
– Controlling a Stage
– Managing Product Delivery
– Stage Boundaries
– Directing a Project

41. Summary

42. 10 Simple ways to add value
1. Identifying the 5. Aggregated risk
context 6. Risk owners
2. Risk descriptions 7. Mitigation actions
3. Estimating for risk 8. Reporting risk
4. Appetite and 9. Learn the lessons
Tolerance 10.Manage the risk

43. Any Questions?