Risk Management

Pranay Srivastava
Dec 2008

Agenda

Risk Management
 Introduction
 Risk Introduction
 Risk Class
 Risk Planning
 Risk Life Cycle
 Top Software Risks.
 What is Risk Management?

Risk management is the structured approach of managing

uncertainty through
 Risk assessment
 Developing strategies to manage it, and
 Risk mitigation using available resources

Risk Management aims to reduce the various risks to an

accepted level

Improper risk management could result in spending resource

in planning/tracking risks that are not likely to occur and
could be used more profitably elsewhere.

Risk Introduction

Possibility that an action/event will adversely/beneficially

effect the ability of the organization to achieve objectives

Types of risk
 Market
 Technology
 Financial
 Organizational
 Safety
 ...
 Risk Classification

Software Project Risks

 Resource constraints, external interfaces, inter team/inter-
group coordination problems, inadequate funding, etc

Software Process Risks

 Undocumented software process, lack of effective peer
reviews, poor requirements management, ineffective planning,
etc

Software Product Risks

 Lack of domain expertise, complex design, poorly defined
interfaces, poor knowledge of legacy system(s), etc.

Risk Class

Known knowns
 Risks known to the team as possible risk category and also as
reality for the project
 Described in the project plan and managed on an ongoing basis

Known unknowns
 Risks known to the team as possible risk category but not as a
reality for the project
 Described in the risk management plan, prioritized, & tracked
on an ongoing basis

Unknown unknowns
 Risks unknown to the team as possible risk category and also as
reality for the project
 Project team/management identifies corrective action once the
risk occurs.
 Risk Planning

Decide the
 Methodology
 Roles & responsibilities
 Timing
 Risk Categories
 Reporting Format
 Tracking frequency
 etc.

Risk Life Cycle

Plan Risk
Identify Risk Analyze Risk
Response

Resolve /
Manage Risk*
Close Risk
 Manage Risk

Monitor Risk Warning Yes

Scenario sign visible

No

Inform Take Corrective

Stakeholder Action

Identify Risk

Document potential favorable/unfavorable outcomes

associated with the risk

Tools
 Project document review
 Information gathering
 Assumption Analysis
 Diagramming Techniques i.e. Cause-effect diagram, flow chart,
influence diagram.
 Analyze Risk

What is the impact i.e. Severity

 Rate on a 3/5 point scale

What are the chances i.e. Probability

 Rate on a 3/5 point scale

What is the risk exposure i.e. Severity * Impact

Risk Response planning required if risk exposure if more

than specified threshold

Over time, the change in risk exposure indicates impact of

other factors.

Risk Response Types

Avoid Risk
 Change the project execution to eliminate the risk by removing
the underlying cause
 Clarify requirements
 Modify contracts
 Involve stakeholders/customers
 Strict “Change control”

Transfer Risk
 Shift the risk to a 3rd party (for a fee)
 Reduces the impact of the risk but does not reduce the risk
 Outsource with penalty clause
 Buy insurance
 Warrantee
 Plan Risk Response

Mitigate Risk
 Reduce the risk probability and/or impact to an acceptable
threshold
 Weekly/Daily back-up of the systems
 Incremental software development
 Adequate documentation
 Shadow staff on project

Accept Risk
 Usually “ONLY” documents the risk
 Passive Document the risk
 Project team decides corrective action when the risk occurs
 Active Establish a reserve
 Project team utilizes management reserve, after management
approval.

Manage Risk

Monitor scenario at pre-decided frequency

Take corrective action when risk occurs

 If no action was planned then decide on the corrective action
 If corrective action ineffective then identify new corrective
action

Could identify new risks

Report status of active risk and risk that have changed.

 Resolve Risk

Close a risk when no longer applicable

 After a hardware has been received the risk of hardware delay
is closed
 Ensures focus on active risks

Update learnings into Organization Risk database.

Top 10 Software Risks

Unrealistic schedules and budgets

Continuous requirement changes

Unclear/misunderstood scope/objectives

Lack of senior management commitment

Insufficient end-user involvement

Misunderstood requirements

Gold plating

Ineffective project management

Inadequate knowledge/skills

Developing the wrong functions.
 Problem With Risk Analysis

Risk analysis can over estimates the risk and thus cause
excessive mitigation effort

Risk analysis could be too accurate hence no risk occurs and

perceived not to contribute any value
 Many people believe Y2K risk did not exist

Risk analysis takes form of organizational snag-hunting i.e.

blaming

Risk analysis over-relies on number and not on

analysis/common sense

Act of Risk analysis impedes project success i.e. self-

fulfilling prophecy.

Risk Questionnaire

Are the requirements unstable? Incomplete? Missing? Unclear?

Will the requirements result in product that the customer has in
mind?

Are the requirement technically feasible?

Does the requirements specify something never done before?

Does the requirements specify a product more complex than done
earlier?

Will the implementation be difficult to understand or maintain?

Are the reliability/availability needs difficult to meet?

Are the safety requirements infeasible / not demonstrable?

Are the security requirements more stringent than current state
of practice?
 Risk Questionnaire

Will the system will be difficult to use because of poor
human interface?

Is the documentation adequate to design, implement, and
test the system?

Does the development system support all phases, activities,
and functions?

How easy is the development environment to use?

Is there little prior experience with the development
environment?

Does the development environment suffer from software
bugs, down-time, etc?

Is there timely expert or vendor support for the
development environment?

Risk Questionnaire

Are management metrics defined and development progress
tracked?

Are project personnel trained and used appropriately?

Are there adequate procedures and resources to assure
product quality?

Are the build/change/deployment procedures adequate?

Is the schedule inadequate?

Is the staff inexperienced i.e. domain knowledge, technical
skills?

Is the project understaffed?

Is the funding insufficient?

Are the facilities adequate for building and delivering the
product?