This document discusses risk analysis and management for systems projects. It defines risks as things that can negatively impact cost, time or effort. The key steps are: 1) Identifying risks through categories like human, technical etc. 2) Assigning probabilities and costs to risks. 3) Prioritizing risks through a risk register and triage. 4) Creating a decision tree to evaluate options. 5) Developing strategies like avoid, transfer or mitigate risks. Effective communication is also important.

1. +
Risk Analysis
Systems Analysis and Design
Michael Heron

2. +
Introduction
 Good project management requires several things, as
discussed.
 Effective analysis of problems
 Effective subdivision of tasks
 Effective motivation and leadership.
 However, managing the project is more than just hoping
everything goes right.
 It requires a full appreciation of the risks that might impact on a
project as time goes by.
 The way in which this risk management will be performed will
vary from method to method.

3. +
Risks
 A large part of controlling is risk management.
 And this is done through risk analysis.
 A risk in the context of a project is ‘something that can
potentially negatively impact the cost, timeframe or effort to
develop a software project’
 They won’t definitely happen – that’s why it’s a risk and not a
constraint.
 We need to estimate the possibility of the risk occuring and then
calculate our options in dealing with it.
 The weighting of a risk is probability multiplied by the cost of
the event.

4. +
Risks
This is a terrible way to travel. I go to meetings my boss doesn’t want to attend. I take notes.
I’ll get back to you. Wherever I’m going, I’ll be there to apply the formula. I’ll keep the secret
intact. It’s simple arithmetic. It’s a story problem.
If a new car built by my company leaves Chicago travelling west at 60 miles per hour, and the
rear differential locks up, and the car crashes and burns with everyone trapped inside, does
my company issue a recall?
You take the population of vehicles in the field (A), and multiply it by the probability rate of
failure (B), then multiply the result by the average cost of an out-of-court settlement (C).
A times B times C equals X. This is what it will cost if we don’t initiate a recall.
If X is greater than the cost of a recall, we recall the cars and no-one gets hurt.
If X is less than the cost of a recall, then we don’t recall.
Fight Club, Chuck Palahniuk

5. +
Risk Management
 Risk management is a core process that must be performed.
 And it must be performed early. Risks are never cheaper to deal with
than before they are encountered.
 Everyone must be aware of possible risks.
 Not to worry them, but to ensure they are prepared to work around them
if they occur.
 Everyone must be aware of how risks are to be managed and who
is responsible for managing them.
 Ownership is easiest to apply before a risk is encountered.
 Risks must be triaged – you need to deal with the most important
ones first. Risks that will end a project must be dealt with before
those that will derail a schedule.

6. +
Risk Analysis
 Before we can analyse a risk, we must identify it. They come in a
variety of flavours:
 Human
 Staff turnover, staff illness, death, bus factor
 Operational
 Changes in management, changes in logistics, access to resources
 Reputation
 Bad products relating to future market problems, lack of future
opportunities
 Procedural
 Employee fraud, employee theft
 Project
 Over runs, requirements change, scope underestimation

7. +
Risk Analysis
 Other risks:
 Financial
 Business failures, stock market reverberations, unemployment,
product competition
 Technical
 Technical obsolescence, hardware unavailability
 Natural
 Acts of god
 Political
 Change in laws, change in political context
 Misc
 Everything else

8. +
Risk Analysis
 It’s very easy to overlook threats.
 So we need a systematic approach that minimises the chances that
we will miss them.
 We go over each task in a system, and assess it against the
risk categories outlined above.
 Making a note of anything in those categories that can potentially
impact upon us.
 In many cases, risks won’t actually exist, but different
categories will apply to different risks in often surprising ways.

9. +
Risk Weighting
 When you have analysed the total number of possible risks,
you need to assign a weighting to these.
 How likely you think they’re going to be.
 You then need to identify a cost.
 How expensive they will be in terms of time or money or other
measures.
 This information will then help you identify the chances and
costs of a particular option.
 What does it cost if everything goes right?
 What does it cost if everything goes wrong?
 What does it cost in the ‘most likely’ scenario?

10. +
Risk Register
 Recording risks is traditionally done in a formal document such
as a risk register.
 This is the central repository for all risks identified by the project
team.
 It contains several key pieces of information:
 Probability
 Impact
 Counter Measures
 Risk Owner
 Risk Score (impact * probability)
 Outline of mitigation.

11. +
Types of Risk Assessment
 Risks can generally be categorised in two systems.
 Qualitative where descriptive terms are used to describe impact
and probability.
 Quantitative where the specific costs are outlined in real terms of
financial cost and statistical probability.
 Qualitative allows for risks to be quickly categorized and
compared for triage.
 The subtle relationship between traits may make that difficult for the
quantitative representation.
 Quantitative ensures risks are fully understood.
 You must understand them in order to generate the data.

12. +
Risk Triage
 You most likely won’t have a chance to deal with every possible
risk.
 There will just be too many.
 All of them are going to be a problem if they occur. For some
risks, the consequences and likely way to deal with them may
be easier to appreciate when they occur.
 Risk triage is the process by which you look at the full range of
possible risks and decide which ones you will deal with
proactively.
 Before they occur, to mitigate their impact.

13. +
Risk Triage
 First of all, we need to look at the risk score (impact *
probability)
 Higher risk score means that you are going to want to mitigate these
as much as possible.
 Lower risk score means you might want to leave it out of triage.
 There are edge cases.
 A low probability event with a show stopping impact probably needs
to be mitigated regardless of the probability.
 A high probability event with a low impact maybe doesn’t need a lot
of thought put into it.
 Do you want to spend two days mitigating a £100 risk?

14. +
Decision Trees
 This information feeds into your decision tree, which is a way
of representing the cost and benefits of various paths through a
project you might take.
 Consider the unseen university feasibility example.
 For this, you need the tasks you identified (early on as part of
the requirements gathering).
 You need the data regarding risks and costs.
 You need the plain ol’ vanilla costings given to you by the client
(or generated via your own research).
 And you make a tree of it.

15. +
Decision Trees
• It’s drawn from left to
right.
• On the left hand side
we mark out a
decision we have to
make, in this case
‘develop a system or
not’
• We then draw
subsystems that
indicate all our
possible options.
• Simple decisions are
a box.
• Complex outcomes
are a circle.

16. +
Decision Trees
 Next, we need
to assign
costs to each
of the possible
outcomes.
 Start at the
right hand side
and assign a
score to each
of the
outcomes
representing
its worth.

17. +
Decision Trees
 Next, assign
probabilities to
each outcome.
 Based on your
risk analysis.
 Some of this
you are just
going to guess.
 But the more
certain you
can be, the
better.

18. +
Decision Trees
 Once we have this, we assign a cash value to each node.
 For uncertain outcomes, this is the sum of all possible outcomes
modified by probability.
 For our ‘formal software development’ node on the previous
slide, the cost of the node would be:
Option Probability Value Result
Good outcome 0.3 £500,000 £150,000
Moderate Outcome 0.4 £200,000 £80,000
Bad Outcome 0.3 £50,000 £15,000
Total: £245,000

19. +
Decision Trees
 We can then
use this
information to
give us our
‘most likely
best path’
 The potential
financial return
versus the
cost gives us
the likely
benefit of the
decision.

20. +
Risk Management Strategies
 Knowing what the risks are and the costs is one thing, but we need to
manage these as far as possible.
 Based on our risk triage.
 We can decide between one of three strategies.
 Avoid it – recontextualize the project so that the risk is removed.
 If you’re planning to buy cheap software from an untested vendor, buy it at a
higher cost from a more reliable source.
 Transfer it – place the risk on another party through some mutually beneficial
agreement.
 Insurance is a good example of this.
 Mitigate it
 Minimise the chances it will occur – if a team member is at risk of not
completing a task, make sure they’re given the appropriate support at an early
stage before they fail.
 Minimise the cost if it occurs – have a safety net in place for if the worst comes
to the worst.

21. +
Risk Communication
 Risks shouldn’t be hidden from the rest of the team.
 Everyone needs to know that someone has spent time thinking about what could
go wrong.
 Risk communication is healthy in a project.
 Be sure to communicate them with all project stakeholders, including clients.
 A good, solid risk management plan will increase rather than decrease
confidence.
 We all know things can go wrong. We like to see people with a plan for dealing
with it.
 Having people thinking about risks is useful.
 They might think of things you didn’t.
 Communicating the chance of risks is important in managing perceptions.

22. +
Conclusion
 Risk analysis is an important part of managing a systems
project.
 It requires several things to generate an effective strategy.
 Analysis of risks from all possible directions.
 Building of a risk register of all possible risks.
 Development of a risk triage for how risks will be dealt with
proactivity.
 Development of a decision tree to show the likely cost and benefit
of certain outcomes.
 Ongoing development of a risk management plan.
 Ongoing communication with all project stakeholders.