Risk analysis and management

RISK ANALYSIS AND MANAGEMENT

By Hüseyin Gürsev
2011
1

• Risk Analysis and Management are a series of steps that
help a project team to understand and manage uncertainty.

What is a Risk?

• Risk is a potential problem. it might happen, it might not.
But, regardless of the outcome, it is really good idea to
identify the Risk and assess its probability of occurrence,
estimate its impact and establish a Contingency Plan
should the risk turns into a problem.

• Why Risk Analysis & Management is important?

Because lots of things can go wrong in a project.

Understanding the risk and taking proactive measures to
avoid or manage the risk is a key element of a good Project
Management.

2

TWO RISK STRATEGIES ARE

REACTIVE RISK STRATEGY
Reactive strategy monitors the Project for likely Risks. Resources are set aside to deal with
likely risks should they become actual problems.

More commonly, the Project team does nothing about Risk until something goes
wrong. Then, the team flies into action in an attempt to correct the problem rapidly. This is
called “Fire fighting mode”. When Fire fighting fails “CRISIS MANAGEMENT” takes over and
by then the project is in really jeopardy.

PROACTIVE RISK STRATEGY
Proactive Risk Strategy begins long before technical work is initiated. Proactive Risk strategy
involves with:

- Identifying all Potential Risks,
- Assessing the Probability and impacts of each Risk’,
- Ranking the Risks by their Importance.
- Then the software team establishes a Plan for managing the Risk.

This approach is considerably more intelligent strategy.
The primary objective of Proactive Risk strategy is to avoid Risk, But because not all risks can
be avoided the team works to develop a ‘’Contingency Plan’’ that will enable the team to
respond risk in a controlled and effective manner.

3

RISKS

There has been considerable debate about the proper definition
of Risk. However, there is a common agreement that Risk always
involves two characteristics.

– UNCERTAINTY (it may or may not happen)
– LOSS (If risk becomes a reality, unwanted consequences or
losses will occur)

It is important to Quantify the Level of Uncertainty and the
Degree of Loss associated with each risk. To accomplish this
different Categories of Risks are considered.

RISK CATAGORIES

- Project Risks
- Technical Risks
- Business Risks
4

RISK CATAGORIES

1. PROJECT RISKS
Project Risk is the risks that threaten the Project Plan.
If the Risks become real, it is likely that the Project Schedule will slip and that
Project Cost will increase.

Project Risks Identify Potential Risk and their Impacts on the following Project
issues:

- Budgetary problem
- Schedule
- Personnel (Staffing and Organization)
- Resource
- Customer
- Requirements Problem

Project Estimation Risk Factors
- Project complexity,
- Project Size
- Degree of Structural Uncertainty.

5

RISK CATAGORIES
2. TECHNICAL RISKS
Risks that threaten the Quantity and Timeliness of products to be produced.

(Technical Risk occurs because the problem is harder to solve than we thought it
would be).
If a Technical Risk becomes a reality, Project Implementation may become difficult
or impossible.

Technical Risks identify the following Risk problems:

• Potential Design Risk problems
• Implementation Risk problems
• Interface Risk problems
• Verification Risk problems
• Maintenance Risk problems

The followings are Technical Risk Factors

• Project Specification Ambiguity
• Technical Uncertainty
• Technical Obsolescence
• Leading-edge Technology 6

RISK CATAGORIES

3. BUSINESS RISKS
Threaten the viability of the project to be built.

Business Risks often jeopardize the project or the product.

The top five Business Risks are:

1. Building an excellent product or system that no one really wants it
(Market risk);

2. Building a product that no longer fits into the overall business
strategy of the company (Strategic risk);

3. Building a product that sales force doesn’t understand how to sell;

4. Losing the support of senior management due to a change in focus
or a change in managerial people (Management risk).

5. Losing budgetary or personnel commitment (Budget risk). 7

It is extremely important to note that simple Risk Categorization will not always work
since some risks are simply unpredictable in advance.

Risk Categorization proposed by Charlette :

- Known Risks
- Predictable Risks
- Unpredictable Risks

KNOWN RISKS
Can be uncovered after careful evaluation of the Project Plan, the Business and the
Technical Environment and other reliable information sources.
(e.g. Unrealistic Delivery Date, Lack of Documented Requirements or project Scope, Poor
Development Environment).

PREDICTABLE RISKS

These are extrapolated from past Project experience
(e.g. Staff turnover, Poor communication with the customer, Dilution of staff effort as ongoing maintenance
requests are serviced).

UNPREDICTABLE RISKS
Unpredictable Risks are the joker in the deck. They can do occur, but they are extremely difficult to
identify in advance.
8

THE SEVEN PRINCIPLES OF RISK MANAGEMENT

These Principles provide a Framework to accomplish
effective Risk Management:-

1. MAINTAIN A GLOBAL PERSPECTIVE
2. TAKE A FORWARD-LOOKING VIEW
3. ENCOURAGE OPEN COMMUNICATION
4. INTEGRATE RISK INTO SOFTWARE POPROCESS
5. EMPHASIZE A CONTINIOUS PROCESS
6. DEVELOP A SHARED PRODUCT VISION
7. ENCOURAGE TEAMWORK

9

RISK IDENTIFICATION

Risk Identification is a systematic attempt to specify threats to the Project
Plan ( Project Estimates, Schedule, Resource loading, etc).

By identifying the Known and Predictable Risks, the Project Manager takes a
first step toward avoiding them when possible and controlling them when
necessary.

All type of Risks can be presented as:

– GENERIC RISKS (threats to every Project)

– PRODUCT- SPECIFIC RISKS (Can be identified only by those people with a
clear understanding of the technology, the people, and environment that is
specific to the project at hand )

To identify Product- Specific Risks, the Project plan and the Software Scope
are examined and an answer to the following question is developed:
10
“What special characteristics of this product may threaten our Project plan?”

One method for identifying Risks is to create a RISK ITEM CHECKLIST.

RISK ITEM CHECKLIST.

Risk Item Checklist can be used for Risk Identification and focuses on some subset of
Known and Predictable Risks in the following generic subcategories:

Product Size - Risks associated with the overall size of the Software to be built or modified)
Business Impact - Risks associated with constraints imposed by management or by the
marketplace.
Customer Characteristics – Risks associated with Sophistication of the customer and the
developers ability to communicate with the customer in a timely
manner.
Process Definition – Risks associated with Software Process Definition followed by the
development organization)
Development Environment – Risks are associated with availability and quality of the tools to
be used to built the product)
Technology to be built – Risks associated with complexity of the system to be built and the
newness of the technology.
Staff size and experience – Risks associated with overall technical and Project experience of
the Software engineers who will do the work)

The answers to these questions allow the Project Manager to Estimate the
11
Impact of risk.

1.1 ASSESSING OVERALL PROJECT RISK

These questions have derived from Risk data by surveying experienced Software
Project Management in different part of the success of a Project:-

a) Have top Software and Customer Managers formally committed to support the Project?
b) Are End-users enthusiastically committed to the Project and the System/Product to be built?
c) Are requirements fully understood by Software Engineering team and their Customers?
d) Have Customers been involved fully in the definition of requirements?
e) Do End-users have realistic expectations?
f) Is Project Scope stable?
g) Does the Software Engineering team have the right mix of skills?
h) Are Project requirements stable?
i) Does the Project team have experience with the technology to be implemented?
j) Is the number of People on the Project team adequate to do the job?
k) Do all Customer/user constituencies agree on the importance of the Project and on the
requirements for the System/product to be built?

• If any one of these questions is answered negatively, The Risk Mitigation, Monitoring, and
Management steps should be instituted without fail. (See RMMM Plan)

• The degree to which the Project is at Risk is directly proportional to the number of negative
responses to these questions.

12

1.2 RISK COMPONENTS AND DRIVERS ( Risk Referents)
ProjectRisk Components are:
- SCHEDULE RISK - The Degree of Uncertainty that project schedule will be
maintained and that product will be delivered on time.

- COST RISK - The Degree of Uncertainty that the project budget will be
maintained.

- PERFORMANCE RISK - The Degree of Uncertainty that the product will meet its
requirements and be fit for its intended use.

- SUPPORT RISK - The Degree of Uncertainty that the resultant product will be
easy to correct, adapt, and enhance.

The Impact of each Risk Driver or the Risk Component is divided into one of the four
Impact Categories:-

IMPACT CATAGORIES Impact Values
Catastrophic 1
Critical 2
Marginal 3
Negligible 4
13

2. RISK PROJECTION (RISK ESTIMATION)

Risk Projection attempts to rate each Risk in two ways:
1. The Likelihood or Probability (%) that the Risk is real.

2. The Consequence of the problems associated with the Risk,
should it occur.

The Project Manager, Project Planner, other Managers and Technical
staff, perform the following four Risks Projection activities:
1. Establish a scale that reflects the Perceived Likelihood of a Risk
2. Delineate (describe) the Consequences of the Risk
3. Estimate the Impact of the Risk on the Project and the Product
4. Note the overall accuracy of the Risk Projection so that there
will be no misunderstanding.

14

RISK TABLE
Developing a Risk Table provides a Project Manager with a simple technique for Risk
Projection.

The Project Manager studies the Risk Table and defines a Cutoff Line. This implies that
only Risks that are above the Cutoff Line will be given further attention.

- High Probability and High Impact Risks on the Risk Table are considered as
First Order Risk Prioritization.

- Risks below that Cut-off Line are re-evaluated to accomplish the Second- Risk
Order Prioritization.

Risk Impact and Probability have a distinct influence on Management
concern:-.
- A Risk Factor that has a High Impact but a very Low Probability of occurrence
should not absorb a significant amount of Management time.

- A High Impact risk with Moderate to High Probability of occurrence should be
carried forward into the Risk Analysis steps.

‘’ All Risks that lie above the Cutoff Line must be managed.’’

15

2.2 ASSESSING RISK IMPACT

Three Factors affect the consequences that are likely if a Risk
does occur.

a) Nature of Risk
b) Scope of Risk
c) Timing of Risk

- Nature of the Risk indicates the problems that are likely if it occurs.

- The Scope of Risk combines the severity (How serious is it?)
which is overall distribution of Risk. (How much of the project will
be affected and How any Customers are harmed?).

- Timing of a Risk considers when and for how long the Impact
will be felt. In most cases a Project Manager might want the
bad news to occur as soon as possible, but in some cases the
longer the delay the better.
16


2.2.1 RISK EXPOSURE

The following steps will have to be considered when determining the
overall consequences of a Risk.

1. Determine the ‘Average Probability of Occurrence Value’ for each Risk
Component.
2. Determine the Impact for each Risk Component.
3. Complete the Risk Table and analyze the results.

The Overall Risk Exposure is determined by using the following
relationship.

RE = (P * C)

where P= Probability of occurrence for a Risk
C= Cost of the Project should the Risk occurs

17

RISK EXPOSURE EXAMPLE

Assume that the Software team defines a Project Risk as follows:

RISK IDENTIFICATION:

Only 70% of Software Components scheduled for reuse will, in fact, be integrated into the
new Application. The remaining Functionality will have to be custom developed (This means that
30% software will be new components that will have to be developed internally)

RISK PROBABILITY : 80% (There is a likely 80% Risk involve)

RISK IMPACT :

60 Reusable Software components were planned. If only 70% can be used for integration
into the new application then:- ;

(60 * 30) / 100 = 18 New Components would have to be developed from scratch in
addition to other Custom Software that has been scheduled for development.

- Average LOC for one Component is 100 LOC
- Cost for each LOC is $14

The Overall Cost (impact) to develop the 18 component is:-

(18 * 100 * 14) = $25,250

RISK EXPOSURE RE = (P * C)
18
RE = (0.80 * 25,250) = $20.200


Risk Exposure can be computed for each Risk in the Risk Table,
once an Estimate of a Cost is made.

- The Total Risk Exposure for all Risk in the table above the
Cut-off line can provide a means for adjusting the Final Cost
Estimate for a Project.

- Risk Exposure can also be used to predict the Probable increase in
Staff Resource required at various points during the Project
Schedule.

The Project team should revisit the Risk Table at regular intervals,
re-evaluating each Risk to determine when new circumstances cause
its Probability and Impact to change.

As a consequence of revisiting the Risk table, it may be necessary
to add new Risks to the Table, remove some Risks that are no
longer relevant, and change the relative positions of others.
19

3. RISK REFINEMENT

During early stages of Project Planning, a Risk may be stated quite generally. As
time passes and more is learned about the Project and the Risk, it may be possible
to refine the Risk into a set of more detailed Risks, each somewhat easier to
Mitigate, Monitor, and Manage.

One way to Refine the Risk is to represent the Risk in (CTC) format:
CONDITION – TRANSITION - CONSEQUENCE

Using CTC Format the Risk is stated in the following form:

GIVEN THAT <CONDITION> THEN THERE IS A CONCERN THAT (POSSIBLY) <CONSEQUENCE>

Using that CTC Format For the previous Risk Exposure example, we can write Risk
in the following CTC format:-

‘’Given that all Reusable Software Components must conform to specific Design
Standards and that some do not conform then there is concern that (possible)
only 70% of the planned reusable modules may actually be integrated into the as-
built System, resulting in the need to custom engineer the remaining 30% of
components.

This General Condition can be refined into Sub-condition
(i.e; Sub-condition 1, Sub-condition 2 …… etc) 20

4. RISK MITIGATION, MONITORING, AND MANAGEMENT
(RMMM)
All of the Risk Analysis activities presented to this point have a
single goal. That is:– ‘To assist the Project team in developing a
Strategy for dealing with Risk ’.

An Effective Risk Strategy must consider the following three issues.

- RISK MITIGATION (AVOIDANCE)
- RISK MONITORING
- RISK MANAGEMENT AND CONTINGENCY PLANNING

If a Software team adopts a Proactive Approach to Risk, Avoidance
of Risk is always be the best strategy.

21


(RMMM)

Risk Avoidance is achieved by developing a Plan for Risk
Mitigation.

For Example :- Assume that “High Staff Turnover” is
noted as a Project Risk (R1).

• Based on Past history and Management Intuition,
the Likelihood (L1) for High Staff turnover is Estimated
to be 70% which is rather high.

• The Impact (x1) is Project Critical - (That is, high
Turnover will have a Critical Impact on Project Cost
and Schedules.

R1 High Staff Turnover
L1 = 0.70
x1 = 2 22


(RMMM)
To Mitigate “High Staff Turnover Project Risk’’ ( R1)
Project Management must develop a strategy for reducing Staff Turnover.

Among the possible steps to be taken are:-

a) Meet with current Staff to determine causes for turnover such as poor
working conditions, low pay, competitive job market etc

b) Mitigate those conditions that are under your control before the Project
starts

c) Once the Project commences, assume turnover will occur and develop
techniques to ensure continuity.

d) Organize Project teams so that information about each development
activity is widely dispersed.

e) Define Documentation Standards and establish mechanisms to be sure
that documents are developed in a timely manner.

f) Conduct peer reviews of all work so that more than one person is “up to
speed”.

g) Assign a ‘’Backup’’ Staff member for every critical technologist. 23

(RISK MONITORING

As the Project proceeds, Risk Monitoring activities commence.

- The Project Manager monitors factors that may provide an
indication of whether the risk is becoming more or less likely.

- For example: in the case of High Staff Turnover, the following
factors can be monitored:
- General attitude of Staff Team members based on Project
pressures.
- The degree to which the Team has jelled.
- Interpersonal relationship among Team member.
- Potential problems with compensation (Salaries) and benefit.
- The availability of jobs within the company and outside of the
company.

Additionally the Project Manager should monitor the effectiveness
of Risk Mitigation steps .
24

5. RISK MANAGEMENT AND CONTINGENCY PLANNING

Risk Management and Contingency Planning is based on an
assumption that the Risk Mitigation efforts have failed and that the
risk has become a reality.

Assume that a Project is well underway and a number of team
members announced that they will be leaving.
If the Mitigation Strategy has been properly followed,

• The Staff Backup must be available, Information is already
documented, and Knowledge has been dispersed across the
team.

• The Project Manager may have to be temporarily re-focus
Resources to those functions that are fully staffed, enabling
newcomers, who must be added to the team to “Get up to speed.”

• Those individuals who are leaving are asked to stop all work and
spend their last weeks in “Knowledge transfer mode.” This might
include Video-based knowledge capture; the development of
‘’Commentary Documents’’ and/or meeting with other team
members who will remain on the Project.
25


It is important to note that RMMM incur additional Project Cost.
For example; Spending the time to Backup every Critical technologist
cost money).

Part of Risk Management, therefore, is to evaluate when the
Benefits accrued by the RMMM steps are outweighed by the Cost
associated with implementing them.
(In essence the Project Manager performs a classic Cost /
Benefit Analysis.)

If Risk Mitigation step for High Staff turnover will increase both
Project Costs and Duration by an Estimation of 15%, but the
predominant Cost factor is ‘’Back-up critical technologist’’
Management may decide not to implement this step.

On the other hand, If Risk Mitigation steps are projected to
increase Costs by 5% and Duration by only 3%, Management will
likely put all into place.

For a large Project, 30 or 40 Risks may be identified. If between 3
or 7 Risk Management steps are identified for each, the Risk
Management may become a Project in itself. 26


We adapt the Pareto ‘80 - 20 Rule’ to Software Risk.

Experience indicates that 80% of Overall Project Risk (Project
failure) can be accounted by 20% of the Identified Risks.

So the work performed during early part of the Risk Analysis is to
identify and document which of the Risks reside in that 20%.

For this reason, some of the Risk Identified, Assessed, and
Projected may not make into the RMMM plan. Since they do not
fall into the Critical 20% (the Risks with Highest Project priority)

27


SAFETY RISK AND HAZARDS
Safety Hazard Analysis are Software Quality Assurance Activities
that focus on the Identification and Assessment of Potential
Hazards that may affect Software negatively and cause an entire
System to fail.

If Hazard can be identified early in the Software Engineering
process, Software Design features can be specified that will either
eliminate or control Potential hazards.

Risk is not limited to the Software Project itself. Risks can occur
after the Software has been successfully developed and delivered
to the Customer. These Risks are typically associated with the
consequences of Software Failure in the filed.

28


THE RMMM PLAN

A Risk Management Strategy can be included in the Software
Project Plan or the Risk Management Steps can be organized
into a separate Risk Mitigation, Monitoring and Management
Plan (RMMM) Plan.

The RMMM Plan documents all work performed as part of Risk
Analysis and is used by the Project Manager as part of the
overall Project Plan.

Some Software Teams do not developed RMMM Plan rather, each
Risk is documented individually using a ‘Risk Information Sheet’
(RIS).

In most cases RIS is maintained on project database.
29


Once RMMM has been documented and the Project has begun Risk
Mitigation and Monitoring step commence.

- Risk Mitigation is a Problem avoidance activity.

- Risk Monitoring is a Project tracking activity with three primary
objectives.
1. To assess whether Predicted Risk do, in fact, occur
2. To ensure that Risk Aversion steps defined for the Risk
are being properly applied
3. To collect information that can be used for future Risk Analysis

Another job of Risk Monitoring is to attempt to allocate origin
(What risks) caused which problems throughout the Project.
Software Risk Analysis can absorb a significant amount of Project
Planning effort since Risk Identification, Projection; Assessment,
Management, and Monitoring all take time and money; But the effort
is well worth it.
A Chinese General, who lived 2500 years ago said: “If you know the enemy and
know yourself, you need not fear the result of a hundred battles”. For the
Software Project Manager, the enemy is “Risk
30


A Chinese General, who lived 2500 years ago said: “If you know
the enemy and know yourself, you need not fear the result of a
hundred battles”.

For the Software Project Manager, the enemy is “Risk”.

31

Risk analysis and management

More Related Content

What's hot (20)

Viewers also liked (10)

Similar to Risk analysis and management (20)

Risk analysis and management