Information Technology

Project Management

Managing IT Project Risk

 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
 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 Risk
Monitoring Identification

Risk Risk
Handling 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
 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
Region in which
 Example Projected project termination Referent level for
Schedule will occur cost/schedule
Overrun overruns

Projected Cost Overrun