“A risk is a potential future harm that may arise from some present
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
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
5. Reactive risk management:
Does nothing about risk until something goes wrong.
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
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
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.
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..
9. Two interrelated phases,
Risk assessment involves risk identification, risk analysis,
and risk prioritization.
Risk control involves risk planning, risk mitigation, and
It is essential that risk management be done iteratively, throughout
the project, as a part of the team’s project management routine.
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.
12. Method to identify risks: creating risk item checklist.
Focuses on some subset of known and predictable risks..
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
If answers of any of the question is negatively, further steps
should be instituted without fail.
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
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.
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.
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
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
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.
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
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
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.
22. “If you know the enemy and know yourself, you need not fear the result of
a hundred battles.”