Transcript Risk Management - MMU SCMDT

Project Management
Risk Management
Plan


Introduction
Project planning


Project planning


Gantt chart and WBS
Network analysis I
Project planning

Network analysis II
• Project planning
– Resource analysis
• Budgets and cost
control
• Risk management
• Project teams
Project Disasters
• Hi-tech Toilet – Failsafe error
• Mars Orbiter – units error
• Arianne 5 – data conversion error
What is Risk?
• Risk is the possibility of suffering loss
• Possible – but not certain, so it is
expressed as probability
• Loss - is any unwanted consequence that
might occur
Risk in IS Projects
• In a development project, the loss
describes the impact to the project which
could be in the form of diminished quality
of the end product, increased costs,
delayed completion, or failure.
SEI
Risk Management
• Four Main Steps
Risk
Risk Risk Response
Risk Response
IdentificationAssessmentDevelopment Control
• Before these activities?
Plan Risk Management Process
Risk Identification
• The possible risk is determined by a number of
interrelated factors such as:
– Nature of the Project
– Aggressive or Conservative Schedule/Budget
– Skills and motivation of the Project Team
Risk Identification
• Risks can be identified by analysing:
– Historical Information
• Project Files, Commercial Databases, Project team knowledge etc.
– Work Breakdown Structure
– Internal and External Factors
Risk Identification
• Techniques:
– Checklists – e.g. Boehm
– Brainstorming
– Causal/Cognitive Mapping
IS Projects and Risk
• Identify the possible sources of risk in a
typical IS project?
• See Pressman, 1998 Chapter 6.
IS Project Risks
•
•
•
•
•
•
•
One of our Team members is missing
The person with the plans is ill
Haven’t used VB much before
Database design problems
Systems broke when I fixed a bug
System doesn’t meet requirements
It worked when I tried it at home
Likelihood
• What is the likelihood of risk?
– Expressed as a Probability (Percentage)
– Example – There is a 5% chance of a programmer
breaking their big toe whilst coding in any 6 month
period
Impact
• What impact will it have on the project?
– Example – A broken toe on average results in the loss of 20
working days for a programmer
– Expected Value of Loss/Profit
• Expected Value = Loss/Profit x Likelihood
• -20 x 0.05 = -1
• So we will lose 1 day of coding per programmer on a 6 month
project
Urgency
• How urgently do we need to deal with it?
– Immediate remedy or Can it wait?
– Additional means of prioritising action
Example Risk Assessment
Team Conflict and Injuries
Description:
Teammates in the group might have conflicts with one another
throughout the semester. Injuries might result from conflict, accidents,
and other mishaps throughout the semester.
How to
Avoid It:
If any of the teammates show signs of conflict against one another, we
need to mediate between them in order to make our team working
smoothly and such throughout the whole semester. Thus that will reduce
a factor for injury. However, for the other factors of injury, we need to
make sure that we take good care of ourselves such that no harm will
befall upon us (such as carpal tunnel syndrome, leg breaking, finger
breaking, etc).
What It Will
Affect:
If there is a large enough conflict, we might lose some teammates.
Same with for injuries, if the injury is bad enough to cause teammates to
not be able to work on the project.
Possible
Likelihood:
3/100 chance
The Real World Lab: http://www.cc.gatech.edu/classes/RWL/Web/
Quantifying Risk
• Programmer has 5% chance of breaking toe in
any 6 month period
– Broken toe results in the loss of 20 programmer days
– Cost of a programmer-day = £500
• Expected Loss per year due to broken toes
– 2 x (0.05 x -20) = -2 days
– Expected loss = -£1000
Techniques
•
•
•
•
Risk Map/Probability Impact Matrix
Hazard Control Matrix
Payoff Matrix
Decision Tree
Risk Map
Likelihood of Occurrence
High
Medium
Low
Risk Map
Likelihood of Occurrence
High
Scale of impact
Large
Medium
Small
Medium
Low
Risk Map
Likelihood of Occurrence
High
Scale of impact
Large
Medium
Small
Medium
Low
Risk Map
Likelihood of Occurrence
High
Medium
Scale of impact
Large
Low
B
A
C
Medium
Small
D
Risk Map
• List the risks in
order of priority
Likelihood of Occurrence
High
Medium
• What else can we
use to help
prioritise?
Scale of impact
Large
Low
B
A
C
Medium
Small
D
Hazard Control Matrix
Errors
Lost data
Computer Unauthorized Fire
and
and
Failure
Access
omissions documents
Fraud
Input
controls
Processing
controls
Output
controls
Storage
controls
Operating
system
controls
Records
management
Accounting
controls
Contingency
plan
Physical
security
From Curtis, G (1998) "Business Information Systems" Addison Wesley
Hazard Control Matrix
Errors
Lost data
Computer Unauthorized Fire
and
and
Failure
Access
omissions documents
Fraud
Input
controls
Processing
controls
Output
controls
Storage
controls
Operating
system
controls
Records
management
Accounting
controls
Contingency
plan
Physical
security
From Curtis, G (1998) "Business Information Systems" Addison Wesley
Hazard Control Matrix
Errors
Lost data
Computer Unauthorized Fire
and
and
Failure
Access
omissions documents
Input
controls

Processing
controls

Output
controls

Fraud
Storage
controls
Operating
system
controls
Records
management

Accounting
controls

Contingency
plan
Physical
security
From Curtis, G (1998) "Business Information Systems" Addison Wesley
Hazard Control Matrix
Errors
Lost data
Computer Unauthorized Fire
and
and
Failure
Access
omissions documents
Fraud
Input
controls


Processing
controls

Output
controls








Storage
controls


Operating
system
controls
Records
management


Accounting
controls





Contingency
plan

Physical
security




From Curtis, G (1998) "Business Information Systems" Addison Wesley
Identification and Assessment
• Problems
– Not a particularly interesting task
– Needs experience to do well
• Are these good reasons to not do it?
Risk Response Development
• How are we going to deal with risks when they
occur?
– What about those we weren’t expecting?
Control Systems
• Preventive Control
– Stops undesirable events (disturbances) from
occurring (see Curtis, 1998 Chapter 8)
• Feedback Control
– Doesn’t attempt to prevent unpredictable
disturbances
– Is able to recover from effects
• Systems will usually combine both
Risk Control
• Goals of Control
–
–
–
–
–
Prevention
Detection
Minimise Loss
Recovery
Investigation
H. A. Simon
• Risk Response
– Avoidance
• Prevention
– Mitigation
• Transfer
– Acceptance
Cadle and Yeates
Quantifying Risk
• Programmer has 5% chance of breaking toe in any 6
month period
– Broken toe results in the loss of 20 programmer days
– Cost of a programmer-day = £500
• Expected Loss per year due to broken toes
– 2 x (0.05 x -20) = -2 days
– Expected loss = -£1000
• Therefore this much is available to be spent on
preventative measures (e.g. titanium shoes)
Risk Control
• Mitigation by Procurement of
goods/services
• Contingency Planning
• Use Alternative Strategies
• Insurance
• See also Lockyer and Gordon, 1996 Ch.7
IS Projects and Risk
• What can be done to prevent or mitigate
the previously identified IS risks?
IS Project Risks
• Team members don’t exist
– Careful distribution of tasks early on
• The person with the plans is ill
– Make sure information is shared and distributed
• Haven’t used VB much before
– Get to the implementation stage early or prototype
• Database design problems
– Early test of info requirements
• Systems broke when I fixed a bug
– Change control process
• System doesn’t meet requirements
– More careful design or better use of use cases
Risk Response Control
• Implement Risk Responses
• Identify new Risks
– Implement new responses
Risk Register
• Can be used to keep information about identified
risks (Yeates and Cadle Ch. 13)
–
–
–
–
–
–
Title and description
Risk Status - e.g. candidate, live, closed
Potential impact
Risk owner
Actions
Action Log
Risk Ownership
• Risk owner is someone who:
– Has sufficient information concerning the risk
– Has the necessary resources to do something
about the risk
– Possesses the authority to do something
about the risk
COTS Software Risks
• Integration
– Difficulties with integrating data formats/protocols
• Upgrading
– Using supplier upgrades vs old versions
• No Source code
– How easy/necessary is it to enhance the system?
• Supplier Failures or Buyouts
– Problems of suppliers/products going out of business
or being bought out
Hughes and Cotterell, 2006
Mitigation of COTS Risks
• Carefully manage the introduction of updates
• Continually monitor COTS vendors and their markets
• COTS Development will never be cheaper than bespoke
development – do not use it as a cost cutting exercise
• Watch the major influences on COTS development cost
and keep them to a minimum
• Form partnerships with vendors rather than maintaining
continuous conflict with them
• Use wrappers to protect the system and its components
Plan


Introduction
Project planning


Project planning


Gantt chart and WBS
Network analysis I
Project planning

Network analysis II
• Project planning
– Resource analysis
• Budgets and cost
control
• Risk management
• Project teams