Risk Management

Object-Oriented Software Engineering

2

The Concept of Risk

• A risk is defined as a variable that can take a value that endangers or eliminates success for a project.

• In plain terms, a risk is whatever may stand in our way to success and is currently unknown or uncertain.

• We can qualify risks further as direct or indirect:

– Direct risk: The project has a large degree of control– Indirect risk: The project has little or no control

3

Risk Attributes

• We can also add two important attributes:– The probability of occurrence– The impact on the project (severity)

• These two attributes can be combined in a single risk magnitude indicator, and five discrete values are sufficient:

– High, – Significant, – Moderate, – Minor, – Low.

4

How to Cope with Risks

• Three main routes are possible:– Risk avoidance:

• Reorganize project so that it cannot be affected by the risk.

– Risk transfer: • Reorganize project so that someone or something else bears

the risk (the customer, vendor, bank, or another element).

– Risk acceptance: • Decide to live with the risk. • Monitor its symptoms and determine what to do if it materializes.

5

Types of Risks

• Risks that can be avoided or worked around

• Risks that cannot be avoided

– “What if the project leader in this 15-person team leaves the company?”

– Retire this by preparing a backup person.

From: Software EngineeringAn Object-Oriented PerspectiveBy: Eric J. Braude

6

A Way to Compute Risk Priorities

Likelihood

1 to 10

Impact

1 to 10

Retirement

Cost

1 to 10

Priority Computation

Resulting priority

(1=least likely) (1=least impact)

(1=lowest cost) (Lowest number

handled first)

Highest Risk

10 10 1 (11-10) x (11-10) x 1

1

Lowest Risk 1 1 10 (11-1) x (11-1) x 10

1000

From: Software EngineeringAn Object-Oriented PerspectiveBy: Eric J. Braude

Risk Management

From Software Engineering R7

By

Sommerville

8

Important Goals for Project Management

• Deliver the software to customer at the agreed time

• Keep overall costs within budget

• Deliver software that meets customer’s expectations

• Maintain a happy and well-functioning development team

9

Software Characteristics

• Product is intangible– Software project managers cannot see progress by looking at the

artifact that is being constructed.– They rely on others to produce evidence that they can use to

review the progress

• Large software projects are often ‘one-off’ projects– Large software projects are usually different in some ways from

previous projects

• Software processes are variable and organization-specific– Engineering process for bridges and buildings is well understood– Software processes vary from one organization to another

10

Software Project Manager’s Responsibility

• Project planning– Planning, estimating and scheduling project development, and

assigning people to tasks

• Reporting– Reporting on progress of a project to customers and managers of

the company

• Risk management– Assessing and monitoring risks, and taking action when they arise

• People management– Managing a team of people

• Proposal writing– Writing a proposal to win a contract

11

Risk Category

• Risks may be categorized into:

1. Project Risks– Risks that affect project schedule or resources: the loss of an

experienced designer.

2. Product Risks– Risks that affect quality or performance of the software: failure

of a purchased component to perform as expected

3. Business Risk– Risks that affect organization developing or procuring software:

a competitor introducing a new product

12

Risk Management Process

RiskIdentification

RiskAnalysis

RiskPlanning

RiskMonitoring

List of Potential Risks

PrioritizedRisk List

Risk AvoidanceAnd Contingency

Plans

RiskAssessment

13

Risk Management Process

1. Risk identification– Identify possible project, product, and business risks

2. Risk analysis– Assess the likelihood and consequences of these risks

3. Risk planning– Make plans to address the risk by avoiding it or minimizing its

effects on the project

4. Risk monitoring– Assess risk and plans for risk mitigation and revise these when

we learn more about the risk

14

Risk Identification (Risk Types)

• Technology risks– Derive from software or hardware technologies that are used to

develop system

• People risks– Associated with people in the development team

• Organizational risks– Derive from organizational environment

• Tools risks– Derive from software tools and other support tools used to develop

• Requirement risks– Derive from changes to customer requirements and process of

managing the requirements changes

• Estimation risks– Derive from management estimates of resources required to build

15

Risks and Risk Types (Risk Identification)

Risk Type Possible Risks

Technology Database used cannot process as many transactions per second as expected.

Reused SW components contain defects which limit their functionality.

People It is impossible to recruit staff with skills required.

Key staff are ill and unavailable at critical times.

Required training for staff is not available.

Organizational Organization is restructured so that different managements are possible for the project.

Organizational financial problems force reductions in project budget.

Tools The code generated by CASE tools is inefficient.

CASE tools cannot be integrated.

Requirements Changes to requirements which require major design rework are proposed.

Customers fail to understand the impact of requirements changes.

Estimation The time required to developed SW is underestimated.

The rate of defect repair is underestimated.

The size of the software is underestimated.

16

Risks Analysis

• Probability of the risk might be assessed as:– Very low ( <10% )– Low ( 10-25% )– Moderate ( 25-50% )– High ( 50-75% )– Very high ( >75% )

• Effects of risk might be assessed as:– Catastrophic (threaten the survival of project)– Serious (would cause major delays)– Tolerable (delays and within allowed contingency)– Insignificant

17

Risks Analysis

Risk Probability Effects

Financial problems force reductions in project budget. Low Catastrophic

It is impossible to recruit staff with skills required for the project. High Catastrophic

Key staff are ill at critical times in the project Moderate Serious

Customers fail to understand the impact of requirements changes. Moderate Tolerable

The code generated by CASE tools is inefficient. Moderate Insignificant

18

Risk Planning (Strategies)

1. Avoidance strategies– Probability that risk will arise will be reduced– i.e. Defective components (see next slide)

2. Minimization strategies– Impact of the risk will be reduced– i.e. Staff illness (see next slide)

3. Contingency plans– We are prepared for the worst and have strategy in place to

deal with it.– i.e. Organizational financial problem (see next slide)

19

Risks Management Strategies

Risk Strategy

Organizational financial problem

Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of business.

Recruitment problems Alert customer of potential difficulties an possibility of delays, investigate buying-in components

Staff illness Reorganize team so that there is more overlap of work and people therefore understand each other’s jobs

Defective components Replace potentially defective components with bought-in components of know reliability

Requirements changes Derive traceability information to assess requirements change impact, maximize information hiding in the design.

Database performance Investigate the possibility of buying a higher-performance database.

20

Risk Monitoring

• Checking that our assumptions about the product, process, and business risks have not changed

• Regularly assess each of the identified risks to decide whether or not that risk is becoming more or less problem

• Think about whether or not the effects of the risk have changed– Look at other factors, such as the number of requirements change

requests

21

Risk Factors

Risk Type Potential indicators

Technology Late delivery of hardware of support SW, many reported technology problems.

People Poor staff morale, poor relationships amongst team members, job availability.

Organizational Organizational gossip, lack of action by senior management.

Tools Reluctance by team members to use tools, complaints about CASE tools, demands for higher-powered workstations.

Requirements Many requirements change requests, customer complaints.

Estimation Failure to meet agreed schedule, failure to clear reported defects.