FIT322: Information System Theory & Practice

Week 8: Risk

ISD Announcements
Where are we at this stage?

Identified problems/opportunities Defined IS project Determined the client requirements Analysed the requirements To recommend solution(s) - risk assessment To access risk during IS development

Outline
What is risk? Risk exposure

Why risk management? Risk management in ISD

identify, analyse, prioritise, control, plan

Case studies
Why software failed? (Charette 2005)

What is risk?
Cambridge online dictionary defines risk as:

possibility of something bad happening, and something bad that might happen

Two risk-related concepts: (1) risk event and

(2) risk exposure (of a risk event)

Risk exposure: an estimated, relative loss that is caused by the occurrence of a risk event

Risk exposure
there is a probability P of a risk event E happening, which results in a loss L

RE ( E ) = P L
(i.e. loss when compared to other likely events)

(Boehm 1991)
6

Why risk management?

risks reflect our limitations in understanding

the nature of things:

natural phenomena, people, systems software, hardware, etc.

yet, we want to improve our ability to make

decisions about things:

to strive for good results to avoid the worst (e.g. loss of income, harms, etc.)

Case: Why software failed?

4-10% company revenue spent on IT Governments spend tens of billions ($) on IT

projects each year software are getting increasingly complex: systems of systems 5-15% software projects end prematurely or shortly after delivery (~75billions in US, 2004)

failure: rework exceeds value-added work rework costs 100 x initial development cost

Case: Why software failed? (2)

A risks are associated to:

the business environment software complexity (size) software development failure to define a sensible scope (requirements, time and budget) human errors: bugs poor project management: risks, communication, training, reviewing, decision making

causes of failures:

Risk management in ISD

Risk management should be part of IS project

management Risks can occur at any stage of the ISD life cycle Risk management tasks:

identify risks analyse risks prioritise risks determine risk control activities plan risk control activities

Identify IS risks
Keil et al. (1998) studies the common risks in

software development (also applicable to ISD) The top five risks are not related to technology:

lack of top management commitment to the project failure to gain user commitment misunderstand the requirements lack of adequate user involvement failure to manage end user expectations

Common ISD risks

2010

IST332 Information Systems

12

(Keil et al. 1998)

ISD risk classification

Keil et al (1998) proposes a framework that

can be used for identifying ISD risks The framework defines four risk quadrants (or categories): customer mandate, scope/requirements, execution, environment Risks related to scope/requirements and execution are more within the control of the ISD team Risks related to customer mandate and scope/requirements are more important ones to manage

ISD risk classification (2)

control
Customer Mandate Scope/ requirements importan ce

Environment

Execution

(Keil et al. 1998)

ISD risk classification (3)

Control: how much influence can the ISD

team have on the risk outcome Importance: the level of importance of a risk as perceived by the ISD team Customer mandate: client's commitment Scope/requirements: project scope and requirements Execution: project management issues Environment: internal and external organisational issues

Customer mandate
Risks related to the lack of or inadequate

customer mandate for completing the project Not controlled but can be influenced by project managers Many of the top-rated risks fall in this quadrant:

lack of top management commitment failure to gain user commitment inadequate user involvement

Scope/requirements risks
Risks arise from the ambiguities and

uncertainties of the projects scope and requirements:

what is essential and what is desirable? is the scope subject to change over time?

Can be controlled by project managers Examples:

misunderstanding requirements not managing change properly

Execution risks
Risks arise from the actual execution of the

project Project managers have reasonable control over these risks Examples:

inappropriate or insufficient staffing lack of effective development methodology poor estimation improper definition of roles and responsibilities

Environment risks
Risks that arise from the project environment

that exists both inside and outside the organization Project managers have little or no control Examples:

changing scope/objectives (due to organisational change) conflicts between user departments

Analyse risks
The next step is to analyse the risks to

determine their exposures Analysis involves:

cost analysis of the identified risks & outcomes

performed as part of cost/benefit analysis

determine the probabilities of the risks & outcomes determine risk exposures:

use these to determine decision risk exposures

Determine the probabilities

Each risk and decision outcome is associated

with a probability This probability is determined subjectively by the team and past experience in similar projects A probability of a risk is its likelihood of occurrence in relation to other risks in the same risk category The procedure for determining probabilities is described in terms of a DFD

Determine a risk's probability

2.1

project details

Determine the relevant risk event E risk risk quadrant Q quadrant Q

2.2

risk quadrants

IS risks classification

Assign weights to Q's risks

similar past projects

weights of Q's risks, project details

2.3

Determine E's weight

E's and Q's weights, project details

2.4

project

project risk details

Calculate E's probability

Risk probability example

Project risk (E): end-users resistant to change Risk quadrant & project-specific weights:

Customer mandate:

lack of top management commitment: 1 failure to gain user commitment: 3 lack of adequate user involvement: 6

Determine E's weight: 6

Calculate E's probability: 0.6

Using risk exposures in ISD

Risk exposures are used for two purposes:

(1) to plan project risks and (2) to make project decisions involving risks Project risks are analysed and prioritised based on their exposures Project decisions are ranked based on the exposures of the risks involved:

a decision with a lower aggregated risk exposure is ranked higher

Project decisions
Making project decision involving risks can be

helped by using risk exposures Project decisions are ranked based on their decision risk exposures A decision risk exposure is an aggregated risk exposure of all the risks involved A useful technique for measuring decision risk exposure is decision risk tree:

constructed from the all the risks and the decisions that follow from taking these risks

Decision risk tree

Types of nodes: root, decision, risk, outcome Nodes:

root node is a decision node that only has risk nodes as children a risk node has decision or outcome nodes as children a decision node has risk or outcome nodes as children all the leaf nodes are outcomes

Each leaf node is associated to a cost item

Decision risk tree (2)

Types of edges: decision, risk, outcome

decision edges (representing decisions) connect a decision node to its child risk nodes risk edges (representing risks) connect a risk node to its child decision nodes outcome edges (representing outcomes) connect outcome nodes to parent

Edges other than those connected to the root

are labelled with risk probabilities

Decision risk tree example

Two ISD project decisions:

D1: develop the IS in-house D2: purchase a packaged solution

Each decision is evaluated in terms of the

risks related to project overrun:

R1: overrun due to failure to fully define user requirements at the start R2: overrun due to insufficient staffing R3: overrun due to significant hardwareimposed R4: overrun due to some modifications

Decision risk tree example (2)

Project decisions that follow from taking the

risks associated to D1, D2:

D3: continue to invest D4: terminate (i.e. total failure)

0.6, D3
3

$15,000 $50,000 $20,000 $50,000 $30,000 $50,000 $15,000 $75,000

0.5, R1

develop in-house
0.4, R2
1 4

0.4, D4 0.6, D3 0.4, D4

D1

0.1, R3

0.6, D3
5

risks related to project overrun

D2
2

0.4, D4 0.7, D3 0.3, D4

0.8, R1

purchase
2010

0.2, R4
7
IST332 Information Systems

0.7, D3 0.3, D4

$12,000
30 $75,000

Decision risk exposure

The risk exposure of a decision D, RE(D), is the the risk exposure of its child risk node E

RE ( D ) = RE (E)
The risk exposure of an internal node N, RE(N), is the sum of all the risk exposures of all its child nodes C1, , Cn

RE ( N ) =
2010

RE (Ci )
1
31

IST332 Information Systems

Decision risk exposure table

RE Decisions 1 RE $31,100 Risk Nodes 1 RE $14,500 $12,800 $3,800 1 2 3 Risks 0.5 0.4 0.1 Decisions 3 4 3 4 3 4 0.6 0.4 0.6 0.4 0.6 0.4 0.7 0.3 0.7 0.3 Outcomes $15,000 $50,000 $20,000 $50,000 $30,000 $50,000 $15,000 $75,000 $12,000 $75,000 32

$31,100

$32,580
2010

$32,580

$26,400 1 $6,180 4
IST332 Information Systems

0.8 3 4 0.2 3 4

Decision ranking
RE Decisions 1 RE $31,100 Risk Nodes 1 RE $14,500 $12,800 $3,800 1 2 3 Risks 0.5 0.4 0.1 Decisions 3 4 3 4 3 4 0.6 0.4 0.6 0.4 0.6 0.4 0.7 0.3 0.7 0.3 Outcomes $15,000 $50,000 $20,000 $50,000 $30,000 $50,000 $15,000 $75,000 $12,000 $75,000 33

$31,100

D1 is ranked higher than D2 $32,580

2010

$32,580

$26,400 1 $6,180 4
IST332 Information Systems

0.8 3 4 0.2 3 4

Prioritise risks
Project risks are ranked based on their

exposures during the project:

exposures are reviewed as the project progresses

Risks are ranked higher if they have higher

risk exposures

(the opposite of project decisions)

Higher ranked risks are to be addressed first

before other risks

Determine risk control activities

A risk can be mitigated by taking suitable

project actions (or control activities) Risk control activities are proposed and refined through experience in running realworld projects Risk control activities are grouped according to the four risk quadrants

Risk control activities by risk categories

Customer Mandate
- strategic alignment - consider all stakeholders views - communication - create and maintain relationships - require both manager and user commitment (use incentives) - encourage managers support

Scope and Requirements

- educate managers/users about the impacts of change - be prepared for change - use a risk-driven ISD method - focus on the essentials

Environment
- contingency plans - scenarios

Execution
- use sound project management - use a disciplined ISD method - test new technologies early - use slack time - parallel change-over
36

(Keil et al. 1998 & Richard 2006)

2010

Plan risk control activities

In a risk-driven ISD approach, risk control

planning is performed as part of project planning For each risk item:

convert risk control activities into project tasks construct an item project plan for these tasks organise/combine the item project plans to form a risk project plan merge the risk project plan into the overall project plan

For all risk items:

Risk item project plan example

A risk management plan for the risk control

activities of the risk item concerning 'Software fault-tolerance features'

2010

IST332 Information Systems

38

Risk item project plan example (2)

Phase I: prepare for prototype development

2010

IST332 Information Systems

39

Risk item project plan example (3)

2010

Phase II: develop a prototype with key features

IST332 Information Systems

40

Risk item project plan example (4)

Phase III: evaluate prototype & plan for fault-tolerance features

2010

IST332 Information Systems

41

Summary
Understand the nature of IS risks and the need to effectively manage them Introduces risk exposure and how to measure Introduces a risk management method in ISD involving identifying, analysing, prioritising, controlling and planning risks

References

Alter S., Information system: Foundation of E-Business, 4th ed. New Jersey: Pearson Education Inc., 2002

Richard L. Van Horn et al., Information System Solutions: A Project Approach, McGraw Hill, 2006
Charette, R.N., Why software failed, IEEE Spectrum, 42(9), 2005 Boehm B. W., Software risk management: principles and practices , IEEE Computer Society, 1991 Keil M., Cule P.E., Lyytinen K., Schmidt R.C., A framework for identifying software project risks, ACM: Communications of ACM, 41(11), 1998