Conceptualisation Stage Continued

Conceptualisation
Inputs to conceptualisation stage Influencing factors Stakeholder analysis Feasibility Risk Outputs from conceptualisation stage

Risk

Structured Approach to Risk Engineering

Risk Engineering

Risk Assessment
More...

Risk Management
More...

From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2

Structured Approach to Risk Engineering

Risk Assessment

Risk Identification checklists assumption analysis decomposition decision driver analysis

Risk Analysis system dynamics cost modelling decision analysis performance modelling network analysis quality factor analysis

From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2

Structured Approach to Risk Engineering

Risk Management

Risk Prioritisation

Risk Reduction

Risk Planning

Risk Control

Risk exposure Compound risks

Buying information Risk avoidance

Risk transfer Risk reduction leverage

Risk item planning Risk plan integration

Risk resolution Risk monitoring

Risk reporting Risk reassessment

From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2

Risk management control loop

Start Risk assessment Risk prioritisation

Risk reduction
Risk management planning

Risk resolution

From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOCD4-001-R2

Risk monitoring

End

Risk Assessment
Risk assessment

Risk identification Risk analysis

Risk assessment involves the identification and analysis of risks

From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2

Risk monitoring
Risk monitoring

Is risk plan effective? Is risk plan adequate? Are new risks identified? Is project complete?

To risk resolution To risk prioritisation To risk assessment To end

From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2

Identify

Risk Model
Upwards

Assess Allocate

Not Significant
Project Member

Containment

Control

Project Plan

Trigger

Contingency

Risk Model: part 1

Identify
Not Significant Project Member

Assess

Upwards to client/key stakeholders

Allocate More...

Risk Model: part 2

Containment

Control

Project Plan More...

Risk Model: part 3

Project Plan

Trigger

Contingency

Risk Process
Identify Key Stakeholders Identify Critical Success Factors Isolate the Baseline Plan Analyse and Assign Risks

Identify Key Stakeholders

Many people want many things from a software development project Identify the key stakeholders
the people whose wants count

Identify Critical Success Factors

Ask key stakeholders what is required for success
The answers are the critical success factors of the project, used to measure its success A risk is something that could prevent one or more of the critical success factors being met

Risks versus Issues

A risk is something that might happen
An issue is something that has happened...

...and needs to be resolved

Isolate the Baseline Plan

Risks must be associated with a plan before they can be handled
Risks could prevent the achievement of objectives
plans for achieving objectives must be in place before risks can be considered

Analyse and Assign Risks

Identify:
What are the potential risks?

Assess:
What is the impact of each risk? What is the likelihood of the risk occurring? How can the risk be prevented or identified early? What needs to be done if the risk does occur?

Allocate:
To whom can I assign the risk?

Risk Identification
Risks identified should be those considered to be risks to the achievement of the organisations, projects or departments objectives Risks should be grouped under the five headings agreed as part of the Statement of Risk Appetite. Within those headings risk should be presented with the highest residual risk first and then in descending order.

Arrows should be used to indicate whether the risk has increased, decreased or stayed the same since the last review.

Risk Appetite

The amount of risk which is judged to be tolerable and justifiable is the risk appetite

Major groupings of sources of risk

Contractual/environmental
Management/process Personnel Technical

From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2

Contractual/environmental
Unreasonable customers
Defaulting subcontractors Late delivery of components Dependencies/demands from other projects Company operation Industrial action Disasters
From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2

Management/process
Undefined/ill-defined responsibilities & authorities
Undefined procedures Unknown quality of development products Inadequate control of development products Problems and errors detected late Inadequate technical approaches Inadequate support facilities & services Lack of visibility
From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2

Personnel
Wrong people available
wrong grade wrong training wrong expertise

Wrong availability
too many people for current tasks too few people for current tasks

From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2

Technical
Requirement changes
genuine changes of mind by the customer
hidden implications emerge

Failure to meet requirement

cannot produce a feasible design

acceptance test fails

Problem or error detected

inconsistent design missing component

inadequate time for testing

From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2

Risk Assessment Tool

Consequence catastrophic

medium

negligible

low

medium

high

Probability

Risk Assessment Tool: Risk Prioritisation

Consequence catastrophic B A A

medium

negligible

D low

D medium

B high Probability

Risk Assessment Tool: Risk Prioritisation

Catastrophic Major Moderate Minor Insignificant 5 4 3 2 1 1 Rare 2 Unlikely 3 Possible 4 Likely 5 Almost certain

Severity Of Impact

Risk tolerability matrix: Green activities require no further action Yellow activities should be monitored and managed down to green where it is considered practical and cost-effective Red activities require immediate action and should be reported to the Risk Committee, however the activity may be allowed to continue given the current environment the University operates in. Black activities must immediately be referred to the Vice Chancellor and Chair of Governors.

Likelihood of occurrence

Risk Assessment: Risk Prioritisation

Risk Impact Likelihood Severity (Impact * Likelihood) 9 Tracker Action/Contingency

Insufficient disk space Insufficient memory Version 2.0 of the database is a bit buggy Requirements not too detailed. Users not available for CAT.

Vic

(Action) Investigate cost & lead time for upgrade. (No action at present)

Ian

27

Kami

(Action) Send Kami on early training course. (Contingency) Use version 1.0. (Action) Check on progress and choose best areas for phased delivery. (Action) Check user plans (Contingency) Use external testers.

40

Vic

36

Ian

Risk Assessment Form

Title of Process/Procedure/ Experiment: Brief description of work involved: Significant hazards: Significant risks: Risk Rating: Likelihood Severity Low 1 1 Medium 2 2 High 3 3

Risk Rating Total (Likelihood x Severity): Risk (Low = 1-3, Medium = 4,6 High = 9): Groups at risk (staff, students, etc):

........................... ......................................

Special risk groups (disabled persons, maintenance workers etc):

www.londonmet.ac.uk/fms/MRSite/acad/fls/Risk%20Assessment%20Form%20Dec09.doc

Risk Assessment
Risk Title Raw Risk Risk Controls Residual risk Financial Further M itigations Required L S Sc L S Sc Impact Risks associated with support systems and processes, and in particular management and quality assurance 5 5 25 Data Quality Management Programme Board 4 4 16 millions Funding project approach applied Risk Owner Failure to provide accurate funding returns DC E Director of Finance Development of the Office of Institutional Effectiveness Detailed report to Audit Committee. Quality Assurance provided by Internal and External Audit. CEO

Reputatio nal damage

Risk Assessment
Raw risk calculation Likelihood of occurrence (L) graded on a scale of 1 to 5 (rare/ unlikely/ possible/ likely/ almost certain)
Severity of impact (S) graded on a scale of 1 to 5 (insignificant/ minor/ moderate/ major/ catastrophic) The raw risk score (Sc) calculated by multiplying the likelihood of occurrence and severity of impact scores.

Risk Assessment
Risk controls The controls actually in place not those to be put in place or those that should be in place Some controls designed to reduce likelihood of risk occurring (e.g. back-up files to reduce risk of loss) Other controls designed to reduce severity of impact (e.g. insuring against the risk)

Addressing Risk: Treat

Most risks will be addressed in this way. The purpose of treatment is that whilst continuing with the activity giving rise to the risk, action (control) is taken constrain the risk to an acceptable level Such controls can be further sub-divided according to their particular purpose

Addressing Risk: Tolerate

Exposure may be tolerated without further action Even if not tolerable, ability to do anything about some risks may be limited, or the cost of taking any action may be disproportionate to the potential benefit gained Response may be to tolerate the existing level of risk This option may be supplemented by contingency planning for handling the impacts that will arise if the risk is realised

Addressing Risk: Transfer

For some risks the best response may be to transfer them

conventional insurance paying a third party to take the risk in another way
Good for mitigating financial risks or risks to assets Transfer of risks may be considered either reduce the exposure another organisation more capable of managing risk Some risks are not (fully) transferable, e.g. reputational risk

Addressing Risk: Terminate

Some risks will only be treatable, or containable to acceptable levels, by terminating the activity Option to terminate activities may be severely limited and will almost certainly require approval of key stakeholders This option can be particularly important in project management if it becomes clear that the projected cost / benefit relationship is in jeopardy

Addressing Risk: Take the Opportunity

Not an alternative should also be considered whenever tolerating transferring treating a risk Two aspects:
1. While mitigating threats, an opportunity arises to exploit positive impact. E.g. if funding is at risk in a major project, are controls good enough to justify increasing investment to gain greater advantages?

2. Positive opportunities arise without generating threats. E.g. lower costs of goods/services allows other resources to be re-deployed

Risk
Containment action versus contingency plan
containment action action taken before the risk occurs might prevent the risk from taking place reduce the impact should the risk occur is it cost-effective, or better to leave as it is? contingency plan plan of action made before the risk occurs alternative plan triggered by the risk occurring funds need to be set aside in case the plan is needed

Outputs
Feasibility report to contain:
Project goals, objectives & scope Stakeholders Constraints Success criteria Feasibility analysis & risk level Scope of the next stage of project Go/no-go recommendation

References & further reading

Burke, R (2003), Project Management: Planning and Control

Techniques, Wiley (or more recent editions) Field, M & Keller, L (1998), Project Management, International Thomson Business Press Maylor, H (1999), Project Management (2nd Edition), Pitman Publishing Ould M A (1992), Strategies for Software Engineering: The Management of Risk and Quality, John Wiley & Sons, Inc. Redmill F (1995) Risk Management is for Everyone, IText Volume 1, Issue 1, pages 58 - 60, Oxford University Press. Rook P & Cowderoy A, (1993), Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2, GOAL ESPRIT 6283