1. Prepared by:
Hinal Lunagariya

2. Risk??
“A risk is a potential future harm that may arise from some present
action”
 Ex. A schedule slip or a cost overrun.
It involves uncertainty and loss.
 The loss is often considered in terms of direct financial loss, but
also can be a loss in terms of credibility, future business, and loss of
property or life.

3. “Risk in itself is not bad; risk is essential to progress, and failure is
often a key part of learning. But we must learn to balance the
possible negative consequences of risk against the potential benefits
of its associated opportunity.”- Van Scoy
Risk: Good or Bad??

4. Risk concerns future happenings (what risk might s/w project to go
awry?).
Risk involve changes, such as change of mind, opinion, actions or
places (how will changes in customer requirements, development
technologies, target environments and all other things affect
timeliness and overall success?).
Risk involves choices and the uncertainty that choice itself entails
(what methods and tools you use, how many people should be
involved ?).
Risk involves..

5. Reactive risk management:
Does nothing about risk until something goes wrong.
Fire-fighting mode.
When this fails, the project is in real jeopardy.
Proactive risk management
Begins long before technical work is initiated.
Potential risks are identified, their probability and impact are
assessed, and they are ranked by importance.
A plan for management is established.
The main concern is to avoid risk.
Risk Management Strategies

6. Project risk:
Threaten the project plan.
It identifies potential budgetary, schedule, personnel (staffing
and organisation), resource, stakeholder, and requirement
problems and their impact on a software project.
Also involves project complexity, size and the degree of
structural uncertainty.
Technical risk:
Threaten the quality and timeliness of project.
Identifies potential design, implementation, interface,
verification, and maintenance problem.
It occurs because the problem is harder to solve than yuo
thought it would be.ss
Categories of Risks..

7. Business risk:
Threaten by viability of the software to be built and often
jeopardise the project or the product.
Building excellent product that no one really wants.
That no long fits into overall business strategy for the
company.
That the sales force does not understand how to sell.
Losing the support of senior management due to a change
in focus or a change in people.
Losing budgetary or personnel commitment.
Known risk:
That can be uncovered after careful evaluation of he project
plan, the business and the technical environment and other
reliable information sources.
Categories of Risks..

8. Predictable risk:
Extrapolated from past project experiences.
Unpredictable risk:
They can and do occur, but extremely difficult to identify in
advance.
Categories of Risks..

9. Two interrelated phases,
risk assessment
Risk assessment involves risk identification, risk analysis,
and risk prioritization.
risk control
Risk control involves risk planning, risk mitigation, and
risk monitoring.
It is essential that risk management be done iteratively, throughout
the project, as a part of the team’s project management routine.
Risk management

10. Risk management

11. By identifying known and predictable risk, steps can be taken to avoid
them when possible and controlling them when necessary.
Generic risks : Potential threat to every software project.
Product-specific risks: can be only identified by those with clear
understanding of technology, the people, and the specific environment.
Risk Identification

12. Method to identify risks: creating risk item checklist.
Focuses on some subset of known and predictable risks..
Product size
Business impact
Stakeholder characteristics
Process definition
Development environment
Technology to be built
Staff size and experience
Question relevant to each of the topics can be answered for
each software project. This will help in estimating impact of
each risk.
If answers of any of the question is negatively, further steps
should be instituted without fail.
Risk Identification

13. Risk Identification
A list of risk components and drives are listed along with their
probability of occurrence.
Risk components and drivers:
Performance risk: the degree of uncertainty that the product will
meet its requirements and be fit for its intended use.
Cost risk: the degree of uncertainty that the product budget will be
maintained.
Support risk: that the resultant software will be easy to correct,
adapt and enhance.
Schedule risk: that the product schedule will be maintained and
product will be delivered on time.
Based on impact of risk driver, components can be divided into
four categories: negligible, marginal, critical, catastrophic.

14. Also called risk estimation.
It attempts to rate each risk in two ways:
1) probability that the risk is real
2) Consequences of the problems associated with them.
Risk Projection steps:
1) Establish a scale that reflects the perceived likelihood of a risk
2) Delineate the consequences of the risk
3) Estimate the impact of the risk on the project and the product.
4) Asses the overall accuracy of the risk projection so that there will
be no misunderstandings.
This helps in prioritization of risk and we can allocate resources
where they will have the most impact.
Risk Projection

15. Developing a risk table:
a. Risks: list of risks.
b. Category: project size/ business risk etc.
c. Probability is the likelihood of the risk occurring, using either a
numeric or categorical scale, as discussed in the last section.
d. Impact is the magnitude of the loss if the risk were to occur, using
either a numeric or a categorical scale.
The table is sorted according to high probability and high impact basis.
which gives us first order risk prioritization.
Cut-off line is defined for 2nd order prioritization.
Risk Projection

16. Risk Projection
Risks Category Probability Impact RMMM
Estimated size of project in LOC or FP PS 80% 2 **
Lack of needed specialization increases defects
and reworks
ST 50% 2 **
Unfamiliar areas of the product take more time
than expected to design and implement
DE 50% 2 **
Does the environment make use of a database DE 35% 3
Components developed separately cannot be
integrated easily, requiring redesign
DE 25% 3
Development of the wrong software functions
requires redesign and implementation
DE 25% 3
Development of extra software functions that
are not needed
DE 20% 3
Strict requirements for compatibility with
existing system require more testing, design, and
implementation than expected
DE 20% 3
Operation in unfamiliar software environment
causes unforeseen problems
EV 25% 4
Team members do not work well together ST 20% 4
Key personnel are available only part-time ST 20% 4

17. Risk Projection
Assessing risk impact
The factors that affect the consequences:
1. Nature of the risk: the problems that are likely if it occurs.
2. Scope of the risk: defines how serious it is?
3. Timing of the risk: when and for how long the impact will be felt.
Steps to determine consequences of a risk:
1. Determine the average probability of occurrence value for each risk
component.
2. Determine the impact for each component based on the criteria.
3. Complete the risk table and analyze the result.
Risk exposure(RE) = Probability(P) * Cost(C)

18. Risk avoidance strategy/plan.
Risk mitigation produces a situation in which the risk items are eliminated
or otherwise resolved
For ex. High turnover will have a critical impact on cost and schedule.
Steps to mitigate this risk:
Meet with current staff to determine causes for turnover
Mitigate those causes that are under your control before project starts.
Define work product standards and establish mechanisms to be sure
that all models and documents are developed in a timely manner.
Assign a backup staff member for every critical technologist.
Risk Mitigation

19. Project tracking activity with three primary objectives:
To assess whether predicted risk do occur
To ensure that risk aversion steps defined for the risk are being
properly applied.
To collect information that can be used for future risk analysis.
Risks need to be revisited at regular intervals for the team to re-evaluate
each risk to determine when new circumstances caused its probability and/or
impact to change.
 At each interval, some risks may be added to the list and others taken
away.
Risk Monitoring

20. Risk Management
Contingency planning
Actions to be taken in the event that mitigation steps have failed
and the risk has become a live problem
RMMM Plan

21. On-going and effective communication between management, the
development team, marketing, and customer representatives about project
risks is essential for effective risk management.
This communication enables the sharing of all information and is the
cornerstone of effective risk management.
Communicate

22. “If you know the enemy and know yourself, you need not fear the result of
a hundred battles.”