Risk Assessment: the Generic Concept

1
Risk Assessment the Generic Concept

• COMM80 Risk Assessment of Systems Change
• Unit 6

2
Objectives of Session Coverage

• To understand the importance of risk assessment.
• To consider some generic techniques e.g.
  prioritisation, ranking.
• To introduce two specific techniques
  (not dealt within in detail here)
• To consider the use of software support tools.

3
Why Assess Risks?How Assess Risks?

• Why? Because cant monitor all risks in a project
  
• so need to monitor and control the most
  significant ones.
• How?
• Quantify assign a value to each risk
• Prioritise use the risk value to assign a
  priority typically high, medium, low (or some
  numerical scale within a project).
• Rank compare risks within a project against
  their risk value to determine their relative
  importance.

4
Risk Quantification

• Risk (probability of occurrence) x (impact).
• Need to measure or estimate probability and
  impact.
• These are not absolute values but judgements made
  by decision makers.
• Probability is defined on a scale 0 to 1
  (impossible to certain) or 0 to 100
• Impact is defined on a (user defined) scale
• e.g.scale 0 to 10 no impact (0) to catastrophic
  (10)

5
Generic techniques

• There are many techniques for risk assessment.
• Generic/standard techniques include
• Prioritisation and Ranking,
• Analytical Hierarchy Process,
• Decision Trees,
• Bayesian Belief Networks.

6
Quantifying/ Ranking/Prioritising

• This basic approach will be illustrated using the
  Risk RadarTM software to provide examples.
• Risk RadarTM (V2.02) is a free software product.
• Developed by Integrated Computer Engineering, Inc
  (ICE) under a DoD contract
• Available from
• www.iceinceUSA.com and
• www.spmn.com (Software Program Managers Network
  (SPMN)).

7
Risk RadarTM Provides

• standard database functions to add and delete
  risks,
• specialised functions for prioritising and
  retiring project risks.
• Including prioritisation of risks through
  automatic sorting and risk-specific movement.
• the option of a user-defined risk management plan
  and a log of historical events for each risk.

8
Risk Radar - Initial form
9
Set Up Project
10
Risk Documentation
11
Information About Individual Risks

• For each risk recorded additional information is
  held - such as
• the area of the project it affects,
• where control resides,
• etc.

12
Prioritisation

• Subjective estimates are made
• based on professional judgement of the
• probability that a risk will occur and
• its negative impact on the project if it does.

• risk exposure probability impact value.

• risk exposure probability impact value.

• risk exposure probability impact value.

13
Prioritisation

• Risk impact could be broken down and quantified
  into all kinds of impacts areas, such as the
  schedule impact in terms of days or cost impact
  in financial terms,
• in reality, it is not possible to quantify these
  impacts with any degree of accuracy.
• Adding multiple impact areas adds complexity to
  the risk management process for little
  quantitative benefit.
• The impact rating system only suggests the total
  impact the risk could have on a specific project.

14
Prioritisation

• Risk RadarTM does not assign any meaning to an
  impact value.
• The project team must define the meanings and
  keep to them.
• These numbers are, usually based on past
  professional experience.
• The software uses risk exposure as a means to
  rank risks relative to one another within a
  project.
• It is inappropriate to compare risks across
  projects solely based on numerical factors such
  as probability, impact, or exposure.

15
Prioritising Risks in Risk Radar
The upper figure shows risks ranked according to
exposure rate. However, if a risk manager felt
that Poor Interface Design should have a higher
ranking than Poor Data Quality they could be
re-arranged them manually as shown below.
16
View Risk Impact
17
View Risk Impact
18
Change in risks profile over time
April
to July