Information Technology
Project Management
Managing IT Project Risk
Dr . Magdi hamoda
Outline

Defining IT Failure
 Defining Risk and Risk Management
 Risk Management Cycle
– Risk Identification
– Risk Analysis
– Risk Handling
– Risk Monitoring
What do we mean by failure?
 Lyytinen
(1988) distinguishes between “development
failure” and “use failure”
 A more detailed categorization of IT failure would
include:
– system grossly exceeds original budget
“Runaway
Systems”
– system grossly exceeds original schedule
– system never functions technically
– system functions, but quality is so poor that, for all practical
purposes, system is not usable
– system functions but is not used--users reject the system
because it is cumbersome to use or because they have no
incentive to use it
– system functions, but completely lacks originally promised
functionality or fails to fit the task it was designed to support
Some Observations about
Success/Failure
 Success/Failure
is often viewed as a binary
classification
 Success/Failure should be viewed along a
continuum
 Success is in the eyes of the beholder
Total
Failure
Total
Success
Stakeholder A
Stakeholder B
Why IT Projects Fail:
The Traditional Wisdom
 Systems
are specified and initiated by IS without
sufficient input from the user(s)
 Inadequate estimates of development cost and
time
 Lines of responsibility not clearly specified
 User acceptance test delayed until the project is
completed
 Inadequate system testing
 Implementation difficulties
Warning Signs
(Keider, 1984)
 Inadequate
status reporting
 Isolation
 Lack
of schedule changes
 Overemphasis on how a system will be built
 Premature programming
 Staff reassignments
Defining Risk and Risk
Management

A project risk is a potential problem that
would be detrimental to a project’s success
should it materialize
 Risk management is the identification and
response to potential problems with
sufficient lead time to avoid a crisis
Risk Management Cycle
Risk
Monitoring
Risk
Handling
Risk
Identification
Risk
Analysis
Risk Identification
 Business risk
– Market risk
– Shifts in business strategy or senior management
 Technical risk
– Design and development problems
– Testing and maintenance problems
– Technical uncertainty
 Project risk
– Budget
– Schedule
– Personnel
– Requirements problems
Tools for Identifying Risks
Checklists (e.g., Boehm’s top ten risk list)
 Frameworks (e.g., McFarlan’s framework)
 Questionnaires (e.g., Barki, Rivard, and
Talbot survey)

Risk Factors: What the
Literature Says . . .
 Technological
newness
 Application size
 Application complexity
 Task complexity
 Project team expertise
 Organizational environment
 Magnitude of potential loss
Barki, Rivard, and Talbot, 1993
What Project Managers Say
0
2
4
6
8
10
12
Lack of top management commitment to
the project
Failure to gain user commitment
Misunderstanding the requirements
Lack of adequate user involvement
Failure to manage end user expectations
HKG
Changing scope/objectives
USA
FIN
Lack of required know ledge/skills in the
project personnel
Lack of frozen requirements
Introduction of new technology
Insufficient/inappropriate staffing
Conflict betw een user departments
Risk Analysis

For each identified risk, evaluate the
probability of occurrence
 For each identified risk evaluate the impact
if the risk should occur
 Prioritize your risk handling effort based on
both probability and impact
Assigning Probabilities
Here we ask: “What is the likelihood that
something will go wrong?”
 Establish a scale that reflects the perceived
likelihood of a risk

– Probability scales are commonly used
– Can be qualitative or quantitative
 e.g. highly improbable, improbably, moderate,
likely, highly likely
 e.g. 0-100% probability
Example Scale for Evaluation
of Probability
Score
Probability
0
Highly unlikely (1% or less)
1
Very unlikely (1% - 24%)
2
Unlikely (25% - 49%)
3
Likely (50% - 74%)
4
Very likely (75% -94%)
5
Highly likely (95% or more)
Assessing Impact
Here we ask: “What is the damage or
impact if something does go wrong?”
 Three factors can be used to assess impact

– Nature of the risk (i.e. the problems that are
likely if it occurs)
– Scope of the risk (i.e. how serious is the risk
and how much of the project will be affected?)
– Timing of the risk (i.e. when and for how long
will the impact be felt)
Example Scale for Evaluation
of Impact
Score
Impact
0
Ignorable
1
Unimportant
2
Less important
3
Important
4
Very important / serious
5
Catastrophic / critical
Risk Matrix Example
Risk Factor
Probability
Impact
Probability x Priority
Impact
A
2
5
10
1
B
4
2
8
3
C
3
3
9
2

Risk Handling
Risk prevention
– Develop options to reduce the potential of the problem
occurring

Risk avoidance
– Accepting a lower risk (another solution) to avoid a high risk

Risk remedy
– Monitoring risk status and developing solutions to reduce
effect when risk becomes a problem

Risk assumption
– Decision to accept the risk should it occur

Risk reduction
– Obtaining additional information that will reduce risk (e.g.,
prototyping, incremental development)
Risk Monitoring

Should be done periodically
– (e.g., when certain milestones are reached, at the end
of project phases, at steering committee meetings,
etc.)



Useful to regularly assess and update project risk
exposure
Senior management should be involved in
monitoring and should be aware of exposures
Listen to the project group
Establishing Risk Referent
Levels
 Risk
referent levels can be set to define
regions of acceptable and unacceptable risks
 Three typical risk referent levels
– Cost overrun
– Schedule slippage
– Performance criteria
 Example
Projected
Schedule
Overrun
Region in which
project termination
will occur
Projected Cost Overrun
Referent level for
cost/schedule
overruns