SOFTWARE ENGINEERING

Slide Set 05: Risk Management

 Risk
• According to Webster’s Dictionary,

– Risk is the possibility of suffering loss.

• Any decisions that we take generally carries some amount of

risk hence result in a gain or loss for us. In both cases, we must
bear the consequences.

• In simple terms, this results in taking a risk.

• Risk-taking entails making a choice.

Risk Management 2
 Risk
• Risk involves change in some form like a change in place, a
change in profession and change in opinion.

• Software engineering also entails many risks.

– What are the risks pertaining to the software project?

– How will any change, inherent or circumstantial, affect the

performance of the project?

– At every step, we must make a choice be it the selection of

people for the project or the selection of equipment to be
used.

Risk Management 3
 Risk Strategies
• There are two commonly used strategies to deal with risks
in software engineering:

1. Reactive Strategies

2. Proactive Strategies.

Risk Management 4
 Reactive Strategies
• There is a phrase “cross the bridge when you come across it”,
which when applied to a software project would mean taking
care of problems as and when we come across them without
planning for them in advance.

• This is termed as “Reactive strategy”, which means we react to

the problem.

• With reactive strategies, the team does nothing about risks until
something goes wrong.

• When a problem arises, the team goes into action and takes
initiative to solve the problem.
Risk Management 5
 Reactive Strategies
• Reactive strategy can be depicted as figure 5.1.

Problem occurs Takes action

Figure 5.1 Reactive Strategies

Risk Management 6
 Reactive Strategies
• Assume that there was a software project in progress with three
software engineers involved in all kinds of responsibilities.

• The firm never accounted for the fact that any one of them may leave. It
simply took for granted the continuance of the staff. But, all of a
sudden, two of the engineers leave the project.

• In such a situation, the entire burden falls upon the lone software
engineer.

• Due to shortage of time, it may so happen that the firm is unable to hire
new staff immediately and the project may have to be abandoned or
delayed.

Risk Management 7
 Reactive Strategies
• In the given example, reactive strategy would mean hiring and training
new staff after the earlier staff has quit.

• Had the problem been foreseen, the engineers who plan to quit could
be made to train the new staff and then leave.

Risk Management 8
 Proactive Strategies
• Proactive means taking the initiative.

• Proactive strategy with respect to a software project would

mean acting in advance, predicting that a problem may
arise and taking precautionary measures for it.

• Identification of risks that may occur, prioritizing them and

planning solution strategies to deal with these risks are
part of proactive strategy.

Risk Management 9
 Proactive Strategies
• Figure 5.2 illustrates this strategy.

Predicts Problem Takes

Problem occurs Action

Figure 5.2 Proactive Strategies

Risk Management 10
 Characteristics of Risk
• Any kind of risk possesses two characteristics:

– Uncertainty:

• Uncertainty is probability estimation about whether the

foreseen risk will actually occur.

– Loss:

• If the risk becomes a reality, unwanted consequences or losses

will occur.

• Loss is the direct consequence of the risk actually taking place.

Risk Management 11
 Software Risks
• Risks can be categorized into several categories:

1. Project Risks

2. Business Risks

3. Technical Risks

4. Predictable Risks

5. Unpredictable Risks

Risk Management 12
 Project Risks
• These affect or threaten any project plan that has been laid.

• Project risks can cause time delays or increase in cost.

• These risks include personnel, customer, resource,

budgetary, scheduling and requirement risks.

Risk Management 13
 Business Risks
• Business risks affect the viability of the software to be built.

• Business risks can come in various forms:

1. Building an excellent product or system that no one really

wants (market risk).

2. Building a product that no longer fits into the overall

business strategy for the company (strategic risk).

3. Building a product that the sales force doesn't understand

how to sell.

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

5. Losing budgetary or personnel commitment (budget

risks).

6. Sometimes, business risks are unpredictable too.

Risk Management 15
 Technical Risks
• These risks can have an effect on the creation and completion of
software.

• In case such a risk becomes real, implementation could become

difficult and even impossible.

• Technical risks can occur within any of these stages:

– Implementation
– Interfacing
– Verification
– Design
– Maintenance
Risk Management 16
 Technical Risks
• The causes for technical risks could be software
obsolescence, technical uncertainty, and ambiguity in
specifications.

Risk Management 17
 Predictable Risks
• Certain risks like unrealistic delivery date, lack of
documented requirements or software scope can be
predicted by evaluating the project plan and the
environment under which the project will be developed.

• Predictable risks can be identified from past project

experience.

Risk Management 18
 Unpredictable Risks
• These are the risks that may occur but cannot be
predicted in advance.

Risk Management 19
 The Risk Management Process

Risk Risk
Risk Analysis Risk Planning
Identification Monitoring

List of Risk Avoidance

Prioritize Risk
Potential & Contingency
Risk List Assessment
Risks Plan

Figure 5.3 Risk Management Process

Risk Management 20
The Risk Management Process
1. Risk Identification: Possible project, product and business
risks are identified.

2. Risk Analysis: The likelihood and consequences of these

risks are assessed.

3. Risk Planning: Plans to address the risk either by avoiding it

or minimizing its effects on the project are drawn up.

4. Risk Monitoring: The risk is constantly assessed and plans

for risk mitigation are revised as more information about
the risk becomes available.
Risk Management 21
 Risk Identification
• Risk Identification is a systematic attempt to specify factors that
may affect the project plan.

• It is important to identify the known and predictable risks so

that they can be avoided or controlled.

• For each of the risks listed in the previous section, there are two
types of risks:

1. Generic Risks

2. Product-Specific Risks

Risk Management 22
 Risk Identification
• Generic risks can affect any software project whereas
product specific risks can be identified by those who are
familiar with the technology, the people and the project at
hand.

• Detailed examination of the project plan is necessary

to find out and identify the product specific risks.

Risk Management 23
 Risk Identification
• A risk item checklist is generally created to help in identification
of risks as well as focus on different categories of risks.

• The checklist will consist of the following parameters:

– Product Size
– Customer Characteristics
– Process Definition
– Business Impact
– Development Environment
– Technology
– Risk Associated with Staff Size and Experience

Risk Management 24
 Product Size
• This is the risk associated with the overall size of the
software to be built or modified.

• Project risk is directly proportional to product size.

Risk Management 25
 Product Size
• Questions that may be asked to check product size can be
drawn as follows:

– Estimated lines of code or function points

– Confidence in a size estimate
– Deviation of past projects from the estimate
– Size of the database created or used by the software
– Number of users
– Number of projected requirement changes
– Amount of reused software

Risk Management 26
 Customer Characteristics
• These are the risks associated with the sophistication of
the customer and the ability of the developer to
communicate with the customer in a timely manner.

• Customers have different needs and different personalities.

• They also have varied associations with their suppliers and

most customers are often contradictory.

Risk Management 27
 Customer Characteristics
• Questions that may be asked to check the customer characteristics are
as given below:

– Have we worked with the customer before?

– Does the customer know what he wants?
– Will the customer spend time to formally define the
requirements and scope of the project at a meeting?
– Is the customer willing to communicate closely with the
developer?
– Will the customer participate in reviews?
– Is the customer technically sophisticated in the product area?
– Will the customer let the process occur without looking over our
shoulder during technically detailed work?
– Does the customer understand the software process?
Risk Management 28
 Process Risk
• These risks are associated with the degree to which the software
process has been defined and followed by the development
organization.

• Questions that may be asked to check process definition risks

are as given below:

– Does management support a written policy that stresses

the use of a development process?
– Are staff members willing to use the process?
– Is the process similar for all projects?
– Are standards published and available for all developers
and managers?

Risk Management 29
 Process Risk
– Are the standards being followed?
– How are the aspects of the process being monitored?
– What software tools are being used in the
development of the project?

Risk Management 30
 Business Impact
• These are the risks associated with constraints posed by
the management or the market.

• Some parameters that can affect business impact are given

below:

– Effect of the product on company income

– Visibility of the product to senior management
– Number of customers using the end product and how
stable their needs remain

Risk Management 31
 Business Impact
– Knowledge levels of end users, level of documentation
needed for the customer
– Governmental constraints
– Cost of late delivery
– Cost of a defective product

Risk Management 32
 Development Environment
• These are risks associated with the availability and quality
of the tools that may be used to build the product.

• If defective materials and tools are used in any trade, the

end product will not meet the specified requirement.

• Good, proper tools are a pre-requisite to any trade.

Risk Management 33
 Development Environment
• The checklist drawn to check the development environment will
be based on the availability of the following:

– Process and project management tools

– Analysis and design tools
– Appropriate tools for the project
– Appropriate compilers and code generators
– Testing tools
– Database or data stores
– Integration of tools with each other
– Trained staff
– Help for using the tools

Risk Management 34
 Technology
• These are risks associated with the complexity of the
system and the unfamiliarity with the new technology.

• The checklist for technology parameters is as given below:

– Is the technology new to our organization?

– Does the customer demand new algorithms or input
or output technology?
– Does the software interface with new or unproven
software?

Risk Management 35
 Technology
– Is a specialized interface demanded by the product
requirements?
– Is the type of software to be developed new to our
organization?
– Are we using new analysis, design or testing methods
for this project?
– Are the required development methods
unconventional?
– Do the requirements put excessive performance
constraints on the product?

Risk Management 36
Risk Associated with Staff Size and Experience

• In addition to all the above factors, we must also assess

staff size and experience.

• The questions that will help us arise at the right conclusion

are as follows:

– Are the best people available?

– Do the people have the right combination of skills?
– Are there enough people?

Risk Management 37
Risk Associated with Staff Size and Experience

– Is the staff committed for the entire duration of the

project?
– Is there any staff working part time on the project?
– Does the staff have the necessary training?
– Will the change in staff be low enough to maintain
continuity?

Risk Management 38
 Assessing Overall Project Risks
• The following questions can help to assess overall project
risks:

– Have top software and customer managers formally

committed to support the project?
– Are end-users enthusiastically committed to the
project and the system/product to be built?
– Are requirements fully understood by the software
engineering team and their customers?
– Have customers been involved fully in the definition
of requirements?

Risk Management 39
Assessing Overall Project Risks
– Do end-users have realistic expectations?
– Is project scope stable?
– Does the software engineering team have the right mix of
skills?
– Are project requirements stable?
– Does the project team have experience with the
technology to be implemented?
– Is the number of people on the project team adequate to
do the job?
– Do all customer/user constituencies agree on the
importance of the project and on the requirements for the
system/product to be built?

Risk Management 40
 Assessing Overall Project Risks
• If any one of these questions is answered negatively,
mitigation, monitoring, and management steps should be
instituted without fail.

• The degree to which the project is at risk is directly

proportional to the number of negative responses to
these questions.

Risk Management 41
 Risk Analysis
• During the risk analysis process, you have to consider each
identified risk and make a judgment about the probability
and the seriousness of it.

• The probability of the risk might be assessed as very low

(<10%), low (10-25%), moderate (25-50%), high (50-
75%) or very high (>75%).

• The effects of the risk might be assessed as catastrophic,

serious, tolerable or insignificant.

Risk Management 42
 Risk Analysis
• Tabulate the results of this analysis process using a table
ordered according to the seriousness of the risk.

• The overall risk exposure is calculated as:

RE = P×C

– Where,
• P = the probability of occurring for a risk and
• C = the cost to the project should the risk occur.

Risk Management 43
 Risk Analysis
• Risk exposure can be computed for each risk in the risk
table, once an estimate of the cost of the risk is made.

• The total risk exposure for all risks (above the cut-off in the
risk table) can provide a means for adjusting the final cost
estimate for a project.

Risk Management 44
 Risk Table – An Example
Risk Probability Effects

Organizational financial problems force

Low Catastrophic
reductions in the project budget.

It is impossible to recruit staff with the Catastrophic

High
skills required for the project.

Key staff are ill at critical times in the

Moderate Serious
project.

Software components which should be

reused contain defects which limit their Moderate Serious
functionality.

Changes to requirements which require

Moderate Serious
major design rework are proposed.
Risk Management 45
 Risk Mitigation
• If a software team adopts a proactive approach to risk,
avoidance is always the best strategy.

• This is achieved by developing a plan for Risk Mitigation.

Risk Management 46
 Risk Mitigation
• To mitigate risks, project management must develop a strategy
for reducing turnover.

• Among the possible steps to be taken are:

– Meet with current staff to determine causes for turnover

(e.g., Poor working conditions, low pay, competitive job
market).
– Mitigate those causes that are under our control before
the project starts.
– Once the project commences, assume turnover will occur
and develop techniques to ensure continuity when people
leave.
Risk Management 47
 Risk Mitigation
– Organize project teams so that information about each
development activity is widely dispersed.
– Define documentation standards and establish
mechanisms to be sure that documents are developed in a
timely manner.
– Conduct peer reviews of all work (so that more than one
person is "up to speed”).
– Assign a backup staff member for every critical
technologist.

Risk Management 48
 Risk Monitoring
• Risk monitoring involves regularly assessing each of the
identified risks to decide whether or not that risk is
becoming more or less probable and whether the effects of
the risk have changed.

• Risk monitoring should be a continuous process, and, at

every management progress review, you should consider
and discuss each of the key risks separately.

• The table on the next slide gives some examples of factors

that may be helpful in assessing these risk types.

Risk Management 49
 Risk Factors
Risk Type Potential Indicators

Late delivery of hardware or support software, many reported

Technology
technology problems.
Poor staff morale, Poor relationships amongst team members,
People
job availability.

Organizational Organizational gossip, lack of action by senior management.

Reluctance by team members to use tools, complaints about

Tools
CASE tools, demands for higher-powered workstations.

Requirements Many requirements change requests, customer complaints.

Failure to meet agreed schedule, failure to clear reported

Estimation
defects.

Risk Management 50