Steve Smith gave an informative and well-received session on risk identification.

1. Four Seasons of Risk
6th February 2013
Risk Identification
Steve Smith

2. Basis of discussion
 You have a PRAM Guide, so I will not summarise
that
 I will not address why we need RM
 I will focus on dimensions of risk identification,
largely drawn from experience, that may help to
shape your thinking and approach…
 or at least stimulate debate!

3. Identification Topics
 Context
 Techniques
 Approach
 Timing
 Framework
 Case Studies
 Conclusions

4. Project Success Criteria
 Before you start…
 Understand the Aims and Requirements
– Use them as context to check whether identified risks and
opportunities can feasibly impact the project
 Understand the boundaries/drivers
– What can the project control/influence?
– What does the business/organisation control?
– What is beyond the boundary?
– Assumptions & Dependencies cross the boundary

5. Risk Identification
 The important foundation
– Obvious; but get this wrong and all subsequent RM
activities could be undermined
 Many Standards and RM literature such as the PRAM
Guide provide a comprehensive range of tools and
techniques
– Important to select those that are right for your project and
organisation
– Don’t use them all, but use more than one

6. Characteristics of Identification
 Start top down – use any ‘breakdown structures’ with prompt
lists
 Use a few complimentary techniques
 Use understandable terminology
– The Stakeholder Test
 Visualise future situations
– Stage/phase reviews
 Use learned experience (not just checklists)
– relevant to the business
 Group risks together if ownership and cause is similar

7. When to Identify Risks?
 Many studies (and experience) shows that
risks are introduced or missed in the bid or
proposal phase
 Risk identification usually focuses on ‘the
project’, but the project really starts at
‘Gate 1’, the decision to bid
– Early risk/opportunity identification can
guide the bid phase
– Include ‘bid risk’, not just ‘project risk’

8. PESTLE
 Root cause analysis of risk impact events
often exposes ‘environmental’ factors
 The PESTLE analysis tool can be useful for
framing risk identification
 Three cases are given as examples of
impacts that could have been avoided if the
business or project environment had been
considered early enough…

9. Case 1: Resource Costs
 Recent ME metro project
 Assumption that resources could be deployed from
subsidiary in neighbouring country
 No-one checked that it was viable
 In fact, the foreign nationals were not ‘welcome’
and European replacements were 2.5 x budget
 PeStle!

10. Case 2: Requirements
 Recent ME international airport project
 Understanding of interface between own Contract
Package scope and others CP scope was not
complete
 ~€2M hardware scope not included in budget or
plans
 IT specialists were unfamiliar with construction
practices and works
 pesTle!

11. Case 3: Accessibility
 G8 nuclear security project
 Assumption that foreign contractors could operate in
Russia
 In fact only Russian-certificated organisations are
licenced to carry out ‘work’
 Several programmes had to be reconfigured and re-
tendered causing significant delays and rework costs
 pestLe!

12. …and remember
‘What gets measured, gets managed.’

13. …and remember
‘What gets measured, gets managed
…even when it’s pointless to measure and
manage it, and even if it harms the purpose
of the organisation to do so.’

14. Summary
 Get senior management and stakeholder buy-in
 Start early; include bid/proposal risks
 Start simple; top down
 Use a few techniques
 Consolidate
 Repeat at stages/phases
 Think laterally
 Good facilitators are worth their weight in EV