risk exposures

8/3/2019 Risk Exposures

1/29


2/29

Risk management

Risk management is concerned with identifyingrisks and drawing up plans to minimise theireffect on a project.

A risk is a probability that some adversecircumstance will occur.

Project risks affect schedule or resources

Product risks affect the quality or performance of the

software being developed

Business risks affect the organisation developing orprocuring the software


3/29

The risk management process

Risk identification

Identify project, product and business risks

Risk analysis Assess the likelihood and consequences of these risks

Risk planning

Draw up plans to avoid or minimise the effects of the

risk

Risk monitoring

Monitor the risks throughout the project


4/29

Levels of Risk Management

1. Crisis Management - everythings broken

2. Fix on failure - something broke?

Fix it!3. Risk mitigation - what will we do when it

breaks?


5/29

Levels of Risk Management

4. Prevention - how keep it from breaking?

5. Eliminate root causes - why could it break?

PLEASE strive for the last two levels


6/29

Risk Assessment & Control

Risk Assessment

Identification what are the risks? Make a list!

(Or borrow one for ideas)

Analysis assess risk likelihood and impact; find

possible alternatives

Prioritization which risks to focus on? Sort risks

by impact

...


7/29

Risk Assessment & Control

Risk Control

Management planning mitigation planning,

ensure consistency among plans

Resolution actively manage and resolve each risk

when it occurs

Monitoring track progress toward risk

resolution; and identify new risks


8/29

Risk Identification

Look for risks

In all of the major areas of the project - resources,

tools, process, and product

In management areas - cost, schedule, level of

effort

In the Classic Mistakes and Fundamentals

In every area your customer cares about!


9/29

Risk Identification

Categories of schedule risks

Schedule creation

Organization and management Development environment

End users

Customers

Contractors

...


10/29

Risk Identification

More schedule risks

Requirements

Product External environment

Personnel

Design and implementation

Process


11/29

Risk Identification

Risk identification has two

different meanings:

Define what risks might occur (as previously

described), and then analyze them

Be able to tell when a risk has taken place (which

sets the stage for risk monitoring and mitigation)


12/29

Risks and risk types

Risk type Possible risksTechnology The database used in the system cannot process as

many transactions per second as expected.Software components which should be reused containdefects which limit their functionality.

People It is impossible to recruit staff with the skills required.Key staff are ill and unavailable at critical times.Required training for staff is not available.

Organisational The organisation is restructured so that differentmanagement are responsible for the project.Organisational financial problems force reductions in theproject budget.

Tools The code generated by CASE tools is inefficient.CASE tools cannot be integrated.

Requirements Changes to requirements which require major designrework are proposed.Customers fail to understand the impact of requirements

changes.Estimation The time required to develop the software is

underestimated.The rate of defect repair is underestimated.The size of the software is underestimated.


13/29

Risk Analysis

Risk Exposure (Impact) Calculation

Estimate Size ofLoss; what is result of risk?

Estimate Probability of loss, based on corporatehistory, industry norms, or educated guesses

Multiply Size & Probability to get task Overrun due

to that risk


14/29

Risk Analysis

Add task Overrun to the estimated task duration

Repeat for every significant risk


15/29

Risk analysis

Risk Probability Effects

Organisational financial problems forcereductions in the project budget.

Low Catastrophic

It is impossible to recruit staff with the skillsrequired for the project.

High Catastrophic

Key staff are ill at critical times in the project. Moderate SeriousSoftware components which should be reusedcontain defects which limit their functionality.

Moderate Serious

Changes to requirements which require majordesign rework are proposed.

Moderate Serious

The organisation is restructured so that differentmanagement are responsible for the project.

High Serious

The database used in the system cannot processas many transactions per second as expected.

Moderate Serious

The time required to develop the software isunderestimated.

High Serious

CASE tools cannot be integrated. High TolerableCustomers fail to understand the impact ofrequirements changes.

Moderate Tolerable

Required training for staff is not available. Moderate Tolerable

The rate of defect repair is underestimated. Moderate TolerableThe size of the software is underestimated. High Tolerable

The code generated by CASE tools is inefficient. Moderate Insignificant


16/29

Risk Exposure Calculation

Suppose task 3.6, Define requirements for

GUI, has an estimated duration of 30 days.


17/29

Risk Exposure Calculation

If we know, based on historic data, that there is

a 20% chance of this task running over by 10

days, the task overrun is 0.20*10 = 2 days.

Hence in the schedule we should allow 30 + 2 =

32 days for this task, not just 30.


18/29

Risk Prioritization

Sort risks by descending task overrun

This will automatically identify risks with the

highest task overrunFocus on those risks most, since you have the

most to lose if you dont!


19/29

Risk Control

Risk Management Planning

Risk Resolution

Risk Monitoring


20/29


For each risk, identify how risk is to be

identified, managed, monitored, and closed

out. Consider:

What is the risk,

Where and When might the risk occur,

Who is responsible for managing that risk,

Why does the risk exist, and

How will the risk be handled if it occurs?


21/29


Similar to security analysis:

Identify threats

Prevent threats

Detect threats (not trivial with

information systems!)

Mitigate (reduce) the effects of the threats


22/29

Risk Resolution

Avoid the risk (have someone else do it)

Transfer risk to another area (e.g. redesign)

Investigate the risk to better understand it (e.g. use prototype or

consultant to clarify)Eliminate the cause of the risk

(defect prevention)

...


23/29

Risk Resolution

Assume the risk will occur and cope with minor impact

Publicize the risk - well known risks are easier to avoid, and

less shocking if they

do occur

Control the risk - implement

mitigation strategy

Remember the risk - keep lessons learned!


24/29

Risk Monitoring

Develop and maintain top 10 risk list

Conduct postmortems after each major project

event (milestone) - collect and record lessonslearned

Assign a risk officer - a devils advocate, if you

will - to keep pestering with what if...

situations

Dont be afraid to discuss risks openly


25/29

Top 10 Risks List

Develop a list of the ten most serious risks, their

status, and mitigation plans

Review and update each weekRaises awareness of risks, and helps detect

(identify) them


26/29

Risk Management Tasks

Develop Risk Management Plan

May take from one week to several months,

depending on project size

Results in approval of Risk Management Plan


27/29


Update Risk List at a weekly status meeting

Update existing risks, add new ones as needed

Reevaluate Risk Management Plan every 3months to year, depending on project size


28/29


Be sure to account for the following ongoing risk

management activities:

Risk identification (what could happen?)

Risk management planning

Risk analysis and prioritization (what would result?)

Risk resolution (mitigation strategy)

Risk monitoring (has it happened?)


29/29


For each risk, describe:

Risk number, name, and description

The Loss Hours, Probability, and Impact of each

risk; sorted by descending Impact

How each risk will be: prevented (keep it from

happening), identified (know when it has

happened), and mitigated (managed once it hashappened)

risk exposures

Documents