Risk and Change Management: Risk Management Concepts

<< Scheduling Tools: GANTT CHARTS, PERT, CPM

Risk & Change Management Concepts >>

Software Project Management (CS615)

LECTURE # 39

9. Risk and Change Management

9.1

Risk is defined as the possibility of loss. It is the inability to achieve program

objectives within defined cost, schedule, and technical constraints. Risk

management is a set of actions that helps the project manager plan an approach to

deal with uncertain occurrences.

A software project encounters two types of risks, development process risks and

product- related risks. Some of the development process risks are developer

errors, natural disasters, disgruntled employees, and poor management objectives.

Some project related risks are incomplete requirements, unclear project

deliverables and objectives, and complexity of the product.

The steps of risk management involve risk identification, risk analysis, and risk

mitigation. Risk identification involves identifying risks. Risks are identified after

discussion with team members about the requirements documents, available

technology, resources, and other project-related factors.

Contingency planning involves maintaining an alternative plan if the original plan

fails. Contingency plans are put to use when risks become a reality.

What is it? Risk analysis and management are a series of steps that help a

software team to understand and manage uncertainty. Many problems can plague

a software project A risk is a potential problem - it might happen, it might not But

regardless of the outcome, it's a really good idea to identify it, assess its

probability of occurrence, estimate its impact, and establish a contingency plan

should the problem actually occur.

Who does it? Everyone involved in the software process managers, software

engineers and customers - participate in risk analysis and management

Why is it important? Think about the Boy Scout motto: "Be prepared" Software is

a difficult undertaking. Lots of things can go wrong, and frankly, many often do.

It's for this reason that being prepared, understanding the risks and taking

preventive measures to avoid or manage them is a key element of good software

project management.

What are the steps? Recognizing what can go wrong is the first step, called -

risk identification. Next, each risk is analyzed to determine the likelihood that it

will occur and the damage that it will do if it does occur. Once this information is

established, risks are ranked by probability and impact. Finally, a plan is

developed to manage those risks with high probability and high impact.

305

Software Project Management (CS615)

What is the work product? A risk mitigation monitoring and management

(RMMM) plan or a set of risk information sheets is produced. How do I ensure

that I've done it right? The risks that are analyzed and managed should be derived

from thorough study of the people, the product, the process and the project. The

RMMM should be revisited as the project proceeds to ensure that risks are kept up

to date. Contingency plans for risk management should be realistic.

9.2

Risk Management Concepts

Ever wondered why people insure their lives, their homes, their cars, or their

valuables? Suppose your house, along with all the valuables, is burgled. You will

be definitely disheartened. However, you will suffer less if all your valuables are

insured. At times such as these, you realize the importance of planning in advance

for the uncertain events in your life. Just as you plan for unforeseen events in your

life, project managers also need to prepare for uncertainties affecting projects. All

project management skills of a project manager can fall in the face of

uncertainties and unplanned problems.

Robert Charette [CHA89] presents a conceptual definition of risk:

First, risk concerns future happenings, Today and yesterday are beyond active

concern, as we are already reaping what was previously sowed by our past

actions, The question is, can we, therefore, by changing our actions today,

create an opportunity for a different and hopefully better situation for

ourselves tomorrow

This means, second, that risk involves change, such as in changes of mind,

opinion, actions, or places

Third risk involves choice, and the uncertainty that choice itself entails, thus

paradoxically, risk, like death and taxes, is one of the few certainties of life,

When risk is considered in the context of software engineering, Charette's three

conceptual underpinnings are always in evidence. The future is our concern

what risks might cause the software project to go awry? Change is our concern -

how will changes in customer requirements, development technologies, target

computers, and all other entities connected to the project affect timeliness and

overall success? Last, we must grapple with choices - what methods and tools

should we use, how many people should be involved, how much emphasis on

quality is "enough"?

Any project can encounter uncertainties in the form of increased costs, schedule delays,

and diminished qualities. Unless tackled, these uncertainties can lead to major project

disasters. The uncertainties encountered during project execution are the potential project

risks. Every software project has to grapple with the new risks threatening information

306

Software Project Management (CS615)

security along with the conventional risks, such as hardware failure, time and cost

escalation, defects, or resource crunch. Risk can be defined as the possibility of loss. Risk

arises due to the inability to achieve objectives within defined cost, schedule, and

technical constraints. Risk has two components. The possibility of not achieving a

particular outcome is one, and the result of failing to achieve the outcome is the other.

The former is the probability of loss, and the latter is the loss. Software project

management deals with managing both these components of risk.

According to the risk management guru Barry Boehm, "Risk management focuses the

project manager's attention on those portions of the project most likely to cause trouble

and compromise participants' win conditions." In other words, risk management is a set

of actions that helps the project manager plan to deal with uncertain occurrences. It is

through risk management that project managers assess risks and manage to reduce risks

to an acceptable level.

Software risk management is not about managing risks faced by a software organization.

Here, the focus is on managing risks encountered during software development process.

Therefore, the concern is about managing the future of a software project.

In this chapter, you will 1ook at the unforeseen events that might affect a software

project. You will also learn about the steps for managing and mitigating software project

risks.

Types of Risks

To be able to manage project risks, you must first understand what constitutes, a risk. All

uncertain occurrences are not risks. Only those occurrences that have an adverse impact

on the progress of a project are risks to the project. Risk is not a bad thing. Risk is bad

only when it results in loss for an organization. Unless there is a potential for loss, there

is no risk. Moreover, loss can be interpreted as either a bad outcome or a lost opportunity.

The tendency of most project managers is to jump at the statement this is a risk.

However, the desired reaction is to pre-empt all possible outcome and plan for them.

Project risks can be broadly categorized into development process risks and product risks.

Development Process Risks

The risks encountered during product development are categorized as development

process risks. These comprise developer errors, natural disasters, disgruntled employees,

and poor management objectives.

Developer errors could be attributed to poor training due to budgetary constraints and

inadequate skills and software tools. Ergonomic problems, environment problems, and

interruptions or distractions at office also account for developer risks. Other risks in this

category include problems in personnel acquisition and retention.

Similarly, natural disasters such as flood, cyclone, fire, storm, and snowfall are also risks

to a project.

Disgruntled employees can also become a risk to an organization. For example, a sacked

employee can use password snuffers to gain unauthorized access. A dismissed person can

307

Software Project Management (CS615)

flood the system with senseless messages. A disgruntled employee can also try to

sabotage the project work by destroying files and programs.

A poorly defined management objective is another development process risk. If the

language in the management objective is ambiguous and not stated clearly, the risk

management program will not function properly. Narrowly focused and changing

objectives that are not updated can also be counted as risks. Lack of contingency plans,

incomplete cost estimates, and unrealistic schedules are also potential risks in a project.

Similarly, unrealistic performance standards are also potential risks to the development

process. Other possible risks include contractual risks, technological risks, and

inadequate documentation of other concurrent projects.

Product Risks

Product risks crop up in the form of changing requirements during product development.

Incomplete and unclear requirements are a risk to the product during development.

Similarly, problems in meeting design specifications can also be categorized as risk to

product development.

Risks could arise if the project deliverables or objectives are not clearly defined or if

technical data is missing. The possibility of several alternatives at any given time during

the project is also a cause of concern. If errors are not recognized during the design

phase, they could turn into risks for the project. Similarly, risks could arise due to the size

and complexity of the product or while achieving client acceptance of the product.

Note:

The key idea in risk management is not to wait for a risk to materialize and

become a problem. The objective of risk management is to ensure that for each

perceived risk, you know well in advance how to tackle it.

Risk Management Process

Project Risk Management includes the processes concerned with conducting risk

management planning, identification, analysis, responses, and control on a project. The

objectives of Risk Management are to increase the probability and impacts of positive

events and decrease the probability and impacts of events adverse to project objectives.

The process of risk management begins during the analysis phase of software

development life cycle. However, the actual process of managing risks continues

throughout the product development phase. Risk management is a dynamic process

because it deals with the activities that are yet to happen. Risk management has a two-

fold agenda. First, deciding actions for preventing risks from happening, and second,

deciding actions for tackling risks that materialize. Therefore, risk management is all

about pre-empting a risk, coming up with a plan for resolving the risk, and finally

executing the plan.

Figure 6.1 displays the steps of the risk management process. Formally, articulated, risk

management process consists of three steps:

1. Risk identification

2. Risk analysis

308

Software Project Management (CS615)

3. Risk mitigation

Figure 6.1: Risk Management Process

Risk Management

Risk

Risk Identification

Analysis

Mitigation

Risk Probability

Risk Avoidance

Risk Impact

Risk Monitoring

Risk Factor

Contingency Planning

Risk Identification

In this step, the project manager gathers information about the potential risks in the

project. The project manager plans the strategies for avoiding risks or controlling them.

The project team conducts brainstorming sessions and discussions among team members

about the requirements document. They discuss the available technology, manpower,

prevailing environment, and all project-related factors. The project manager picks up the

thread from these and creates a risk log. After the risk log is prepared, the project

manager calls a meeting within the team and technical experts to discuss the risk log and

the mitigation plans. An effective way of identifying' risks is using a questionnaire.

Table 6.1 displays a sample risk identification questionnaire.

Table 6.1: Sample Risk Identification Questionnaire

Yes/No/Not Applicable

Risk Description

(NA)

Product Engineering

Are requirements changing continuously during

product development?

Do the changing requirements affect each of the

following:

Quality

Functionality

Schedule

Integration

Design

Testing

309

Software Project Management (CS615)

Are the external interfaces changing?

Are the requirements missing or incompletely

specified?

Are there any missing requirements?

Can these requirements be incorporated into the

system?

Does the client have unwritten requirements or

expectations?

Is there a way to capture these requirements?

Are requirements unclear or in need of interpretation?

Are you able to understand the requirements as

10)

written?

Will the requirements lead to the product the client

11)

wants?

Are there any requirements that may not specify what

12)

the client really wants?

Product Design

Do you encounter problem in meeting functionality

requirements?

Are there any specified algorithms that may not

satisfy the requirements?

Will the design and/or implementation be difficult to

achieve?

Are there any requirements or functions that are

difficult to design?

Reusability

Are you reusing the program?

Do you foresee any problems in documentations?

Do you foresee any problems in performance?

Do you foresee any problems in functionality?

The sample questionnaire in Table 6.1 includes an exhaustive list of risks that might be

encountered during the progress of a project. The answers to the questions in the risk

identification questionnaire enable the project manager to estimate the impact of risks. In

the sample questionnaire Table 6.1, the risks are categorized under product engineering,

product-design, and reusability. From this table, you obtain a list of risks that are relevant

to each category. You compare the information obtained from this table with past results

and estimate the criticality of risk. In short, during risk identification, you obtain answers

to the following queries:

Why is the risk important?

What information is needed to track the status of the risk?

Who is responsible for the risk management activity?

What resources are needed to perform the activity?

What is the detailed plan to improve the risk and / or mitigate it?

310

Software Project Management (CS615)

Risk Analysis

After identifying the risks, the project manager needs to analyze the risks. Uncertainty

and loss are the two characteristics of risk. The uncertainty factor in risk means that the

unknown event mayor may not happen. While analyzing risks, the project manager needs

to quantify the level of uncertainty and the degree of loss. Based on this, the project

manager plans schedules and costs. During analysis, information on risk is converted into

information on decision-making. Analysis provides the basis for the project manager to

work on the "right" risks.

Table 6.2: Risk Analysis Table

Probability of

Impact on

Risk Factor

Risk

Occurrence

Project

(Probability x

Description

(0 1)

(1 10)

Impact)

Table 6.2 displays a risk analysis format. There are various tasks involved in risk

analysis. First, the WBS elements are identified. One of the tasks in the risk analysis

phase is to describe the risk. The risk can be product-related, process-related,

organization-related, client-related, or infrastructure-related.

Second, the WBS elements are evaluated to determine the risk events. Then the project

manager quantifies the probability of occurrence of risk. The project manager can assign

probability values between 0 and 1. For example, a risk with a low probability of

occurrence is marked 0.2 while that with a high probability of occurrence is marked 0.8.

The reason why a particular risk has a high or low probability depends on the actual

circumstance of the project.

Third, the risks are rated depending on their probability of occurrence. Based on the

probability of risk, the project manager identifies the impact of the risk. The impact of

risk on cost, schedule, and quantity needs to be calculated and graded. The impact of risk

can be graded on a scale of 1 to 10, 1 being the lowest, and 10 being the highest.

Then the risk factor is calculated by multiplying the probability of risk and the impact of

risk. Finally, each risk is prioritized relative to other risks. The risk factor is used to

prioritize the identified risks. For example, the risk with a probability value 0.1 and an

impact value 2 will have minimal impact. While risks close to probability value 0.8 and

with an impact value 9 will have greater impact. Therefore, the project manager can

prioritize risks based on the probability and the impact of risks. A risk that has a high

impact and low probability will not absorb a significant amount of the project manager's

time. However, high-impact risks with moderate to high probability will catch the

attention of the project manager.

311

Software Project Management (CS615)

Risk Mitigation

Risk mitigation is the best possible approach adopted by the project manager to avoid

risks from occurring. The probability of the risk occurring and the potential impact of the

risk can be mitigated by dealing with the problem early in the project. Essentially, risk

mitigation involves three possibilities and the project manager needs to adopt a risk

mitigation strategy aimed at them. The three possibilities include:

· Risk avoidance

· Risk monitoring

· Contingency planning

Risk Avoidance

To avoid risks from occurring, the project team prepares the risk plan before the

commencement of the project. The project team identifies the potential risks and

prioritizes them based on their probability of occurrence and impact. Then, the team

prepares a plan for managing risks. In most software projects, this plan is popularly called

the risk management plan. Table 6.3 displays the format of a risk management plan.

Table 6.3: Risk Management Plan

Impact

Probability

Risk

Factor

Mitigation

Start End

Project

Responsibility

Description Occurrence

(Probability

Steps

Date Date

(1 

(0 1)

x Impact)

10)

To prepare the risk management plan, the project team first identifies and assesses the

risks associated with the project. Then, the probability of occurrence of each risk is

estimated and the possible impact is calculated. In the plan, the probable cost and damage

is also quantified. The project team also identifies the contingency plans for all the

identified risks. The contingency plan for each risk is based on the project's defined

operational software process. The plan is modified throughout the software development

life cycle of the project based on the changes taking place. The contingency plan also

includes the cost, in terms of effort, in carrying out the plan. The software risks identified

are tracked, reassessed, and re-planned at the end of each phase. The project manager

revisits the plan if significant changes are introduced in the software project.

Risk Monitoring

As the project proceeds, risk-monitoring activities commence. It is not possible to

monitor closely all the risks that are identified for the project. For example, if 100 risks

are identified for a project, only top 20 risks are monitored. There are re-planning

checkpoints where the information obtained from monitoring the risks is used to refine

the risk assessments and management plan. The project manager monitors the top 20

312

Software Project Management (CS615)

percent of the factors that may indicate the status of the risks in the project. In the case of

large teams, the project manager also needs to monitor the attitude of the team members

and their problems. This helps the project manager monitor any possible team-related

risks.

Besides monitoring the top 20 percent of the risks, the project manager needs to monitor

the mitigation steps also. Consider an example. To ensure that particular software is

browser- independent, the software is created on the lowest compatible browser. Such

software will work on any browser thus making it browser-independent. Therefore,

mitigating a project risk involves working hard at reducing the possibility that the risk

will ever occur. Mitigation includes nearly all actions that a project team takes to

overcome risks. For example, choosing a more expensive but proven technology over, a

newer, less expensive technology is a step toward mitigating project risks.

Contingency Planning

The possibility of contingency planning arises when mitigation efforts fail and risk

becomes a reality. Contingency planning is used to monitor risks and invoke a

predetermined response. According to the plan, a trigger is set up. If the trigger is

reached, the contingency plan is put into effect. Contingency planning involves

maintaining an alternative plan if the original plan fails. A simple example could be the

savings people make for a rainy day. Contingency plans are a must for the top 20 percent

of the risks identified. These plans are put to use after the risks become a reality. The

importance of contingency planning can be realized from this example. Despite the

massive attack on WTC, the stock markets in the US resumed functioning within a few

days. This was possible because the finance companies had backed up their data and

information on computers elsewhere. The contingency planning of finance companies

prevented the risk of huge data loss for the stock market.

Managing Risks: Case Study

Consider a scenario. Your organization is a vendor of software solutions. A bus transport

company the US wants you to develop a Schedule Adherence system. The team that will

develop this software is new and the platform selected for development is also new to

your organization. The project team needs to be trained intensively for this.

During this project, the team is expected to manage a large volume of data. The team has

never had any experience in managing such a large volume of data. The system also

needs to use this data to generate various MIS reports related to delays or adherence of

bus services.

The performance requirement is less than fifteen seconds for all popular browsers. Your

organization is anticipating numerous requirement changes during the development

process. The system needs to be implemented across several states in the country. The

data related to the system is highly confidential because it can provide an edge to the

competitors.

Now, as a project manager, you need to prepare a risk management plan for this project.

The project starts on May 15 and should be completed on November 15.

313

Software Project Management (CS615)

First, you need to identify the potential risks involved in the project. The potential risks to

the project are described in Table 6.4.

Table 6.4: Potential Risks to a Project

Risk Description

Inexperienced staff

Performance risk due to high volume of data to be processed

Cross-browser compatibility

Involvement of new technology

Design changes during development

After identifying the risks, you need to estimate the probability of their occurrence and

their impact on product development. Based on this, you calculate the risk factor and plan

the mitigation steps.

Your risk management plan is displayed in Table 6.5.

Table 6.5: The Risk Management Plan for Building a Schedule Adherence System

Impact

Probability

Risk

Factor

Mitigation

Start End

Project

Responsibility

Description

Occurrence

(Probability Steps

Date Date

(1 

(0 1)

x Impact)

10)

Conducting

training

Inexperience

Project

sessions before

May

July

0.8

2.4

Staff

Manager

the need

commencement

of project

Massive tuning

of architecture

Performance

Till

during the

risk due to

the

design phase

May

high volume

0.6

4.2

Architect

end of

and conducting

of data to be

the

a proof of

processed

project

concepts for

the design

Cross-

Using the

May

Till

0.6

3.0

Developer

browser

lowest

the

314

Software Project Management (CS615)

compatibility

compatible

end of

browser for

the

development

project

Ensuring all

details

pertaining to

Till

the technology

Involvement

the

Project

is available and

of new

0.5

2.5

May

end of

Manager

keeping in

technology

the

close touch

project

with the

technology

vendor

Designing a

flexible

Till

Design

architecture

the

changes

that can

May

0.6

4.8

Architect

end of

during

accommodate

the

development

future changes

project

and

enhancement

In Table 6.5, the risk factors with high values are the high priority risks. Here, the high

priority risks are design changes during development, performance risk due to high

volume of data to be processed, and cross-browser compatibility. The high priority risks

need to be monitored closely and continuously. The rest of the risks can be monitored

periodically. Certain risks need contingency planning despite being low in the priority

list. For example, the risk due to involvement of new technology is a low priority risk.

However, the probability of occurrence of this risk is 0.5, which is fairly high. This calls

for contingency planning because you may not be aware of all the details of the new

technology. Suppose the system fails to respond if the number of users exceeds a certain

number. In such a situation, you need to have a contingency plan ready. You need to

discuss with the vendor regarding a workaround for such a situation. The workaround

should be ready in the case of failure of the system.

Robert Charette [CHA89] presents a conceptual definition of risk:

First, risk concerns future happenings, Today and yesterday are beyond active concern, as

we are already reaping what was previously sowed by our past actions, The question is,

can we, therefore, by changing our actions today, create an opportunity for a different and

hopefully better situation for ourselves tomorrow, This means, second, that risk involves

change, such as in changes of mind, opinion, actions, or places...[Third] risk involves

choice, and the uncertainty that choice itself entails, Thus paradoxically, risk, like death

and taxes, is one of the few certainties of life,

315

Software Project Management (CS615)

When risk is considered in the context of software engineering, Charette's three

conceptual underpinnings are always in evidence. The future is our concern what risks

might cause the software project to go awry? Change is our concern -how will changes in

customer requirements, development technologies, target computers, and all other entities

connected to the project affect timeliness and overall success? Last, we must grapple with

choices - what methods and tools should we use, how many people should be involved,

how much emphasis on quality is "enough"?

What is it? Risk analysis and management are a series of steps that help a software team

to understand and manage uncertainty. Many problems can plague a software project A

risk is a potential problem - it might happen, it might not But regardless of the outcome,

it's a really good idea to identify it, assess its probability of occurrence, estimate its

impact, and establish a contingency plan should the problem actually occur.

Who does it? Everyone involved in the software process managers, software engineers

and customers - participate in risk analysis and management

Why is it important? Think about the Boy Scout motto: "Be prepared" Software is a

difficult undertaking. Lots of things can go wrong, and frankly, many often do. It's for

this reason that being prepared, understanding the risks and taking preventive measures to

avoid or manage them is a key element of good software project management.

What are the steps? Recognizing what can go wrong is the first step, called - risk

identification. Next, each risk is analyzed to determine the likelihood that it will occur

and the damage that it will do if it does occur. Once this information is established, risks

are ranked by probability and impact. Finally, a plan is developed to manage those risks

with high probability and high impact.

What is the work product? A risk mitigation monitoring and management (RMMM)

plan or a set of risk information sheets is produced.

How do I ensure that I've done it right? The risks that are analyzed and managed

should be derived from thorough study of the people, the product, the process and the

project. The RMMM should be revisited as the project proceeds to ensure that risks are

kept up to date. Contingency plans for risk management should be realistic.

6.1

REACTIVE VS. PROACTIVE RISK STRATEGIES

Reactive strategies have been laughingly called the "Indiana Jones School of risk

management" [THO92]. In the movies that carried his name, Indiana Jones, when faced

with overwhelming difficulty, would invariably say, "Don't worry, I'll think of

something!" Never worrying about problems until they happened, Indy would react in

some heroic way.

Sadly, the average software project manager is not Indiana Jones and the members of the

software project team are not his trusty sidekicks. Yet, the majority of software teams

rely solely on reactive risk strategies. At best, a reactive strategy monitors the project for

likely risks. Resources are set aside to deal with them, should they become actual

problems. More commonly, the software team does nothing about risks until something

goes wrong. Then, the team flies into action in an attempt to correct the problem rapidly.

316

Software Project Management (CS615)

This is often called a fire fighting mode. When this fails, "Crisis Management" [CHA92]

takes over, and the project is in real jeopardy.

A considerably more intelligent strategy for risk management is to be proactive. A

proactive strategy begins long before technical work is initiated. Potential risks are

identified, their probability and impact are assessed and they are ranked by importance.

Then, the software team establishes a plan for managing risk. The primary objective is to

avoid risk, but because not all risks can be avoided, the team works to develop a

contingency plan that will enable it to respond in a controlled and effective manner.

6.2 SOFTWARE RISKS

Although there has been considerable debate about the proper definition for software risk,

there is general agreement that risk always involves two characteristics [HIG 95]:

Uncertainty - the risk may or may not happen; that is, there are no 100 % probable

risks.

Loss - if the risk becomes a reality, unwanted consequences or losses will occur.

When risks are analyzed, 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.

Project risks threaten the project plan. That is, if project risks become real, it is likely that

project schedule will slip and that costs will increase. Project risks identify potential

budgetary, schedule, personnel (staffing and organization), resource, customer, and

requirements problems and their impact on a software project. In Chapter 5, project

complexity, size, and the degree of structural uncertainty were also defined as project

(and estimation) risk factors.

Technical risks threaten the quality and timeliness of the software to be produced. If a

technical-risk becomes a reality, implementation may become difficult or impossible.

Technical risks identify potential design, implementation, interface, verification, and

maintenance problems. In addition, specification ambiguity, technical uncertainty,

technical obsolescence, and "leading-edge" technology are also risk factors. Technical

risks occur because the problem is harder to solve than we thought it would be.

Business risks threaten the viability of the software to be built. Business risks often

jeopardize the project or the product. Candidates for the top five business risks are (1)

building a 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, (4) losing

the support of senior management due to a change in focus or a change in people

(management risk), and (5) losing budgetary or personnel commitment (budget risks). It

is extremely important to note that simple categorization won't always work. Some risks

are simply unpredictable in advance.

317

Software Project Management (CS615)

Another general categorization of risks has been proposed by Charette [CHA89J. Known

risks are those that can be uncovered after careful evaluation of the project plan, the

business and technical environment in which the project is being developed, and other

reliable information sources (e.g., unrealistic delivery date, lack of documented

requirements or software scope, poor development environment). Predictable risks 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 are the joker in the deck. They can and do occur, but they are

extremely difficult to identify in advance.

6.3 RISK IDENTIFICATION

Risk identification is a systematic attempt to specify threats to the project plan (estimates,

schedule, resource loading, etc.). By identifying known and predictable risks, the project

manager takes a first step toward avoiding them when possible and con- trolling them

when necessary.

There are two distinct types of risks for each of the categories that have been presented in

Section 6.2: generic risks and product-specific risks. Generic risks are a potential threat to

every software project. Product-specific risks can be identified only by those with a clear

understanding of the technology, the people, and the environment that is specific to the

project at hand. To identify product -specific risks, the project plan and the software

statement of scope are examined and an answer to the following question is developed:

What special characteristics of this product may threaten our project plan?

One method for identifying risks is to create a risk item checklist. The 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 the

marketplace.

Customer characteristics-risks associated with the sophistication of the customer

and the developer's ability to communicate with the customer in a timely manner.

Process definition-risks associated with the degree to which the software process

has been defined and is followed by the development organization.

Development environment-risks associated with the availability and quality of the

tools to be used to build the product.

Technology to be built-risks associated with the complexity of the system to be

built and the newness of the technology that is packaged by the system.

Staff size and experience-risks associated with the overall technical and project

experience of the software engineers who will do the work.

318

Software Project Management (CS615)

The risk item checklist can be organized in different ways. Questions relevant to each of

the topics can be answered for each software project. The answers to these questions

allow the planner to estimate the impact of risk. A different risk item checklist format

simply lists characteristics that are relevant to each generic subcategory. Finally, a set of

"risk components and drivers" [AFC88] are listed along with their probability of

occurrence. Drivers for performance, support, cost, and schedule are discussed in answer

to later questions.

A number of comprehensive checklists for software project risk have been proposed in

the literature (e.g., [SEI93], [KAR96]). These provide useful insight into generic risks for

software projects and should be used whenever risk analysis and management is

instituted. However, a relatively short list of questions [KEI98] can be used to provide a

preliminary indication of whether a project is "at risk."

6.3.1 Assessing Overall Project Risk

The following questions have derived from risk data obtained by surveying experienced

software project managers in different part of the world [KEI98]. The questions are

ordered by their relative importance to the success of a project.

1. Have top software and customer managers formally committed to support the project?

2. Are end-users enthusiastically committed to the project and the system/product to be

built?

3. Are requirements fully understood by the software engineering team and their

customers?

4. Have customers been involved fully1n the definition of requirements?

5. Do end-users have realistic expectations?

6. Is project scope stable?

7. Does the software engineering team have the right mix of skills?

8. Are project requirements stable?

9. Does the project team have experience with the technology to be implemented?

10. Is the number of people on the project team adequate to do the job?

11. Do all customer/user constituencies agree on the importance of the project and on the

requirements for the system/product to be built?

If anyone 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.

6.3.2 Risk Components and Drivers

The U.S. Air Force [AFC88j has written a pamphlet that contains excellent guidelines (or

software risk 1dentification and abatement. The Air Force approach requires that the

project manager identify the risk drivers that affect software risk components-

Performance, cost, support, and schedule. In the context of this discussion, the risk

components are defined in the following manner:

319

Software Project Management (CS615)

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 project budget will be maintained.

Support risk - the degree of uncertainty that the resultant software will be easy to

correct, adapt, and enhance.

Schedule risk - the degree of uncertainty that the project schedule will be

maintained and that the product will be delivered on time.

The impact of each risk driver on the risk component is divided into one of four impacts

categories-negligible, marginal, critical, or catastrophic. Referring to Figure 6.1

[BOE89], a characterization of the potential consequences of errors (rows labeled 1) or a

failure to achieve a desired outcome (rows labeled 2) are described. The impact category

is chosen based on the characterization that best fits the description in the table.

Figure 6.1 Impact assessment

Components/Category

Performance Support

Cost

Schedule

1 Failure

meet

the

Failure

results

Catastrophic

requirement would result in

increased

costs

and

mission failure

schedule delays with

expected values of $500

2 Significant

Non

Significant Unavoidable

degradation to responsive or

financial

IOC

non

unsupportable

shortages,

achievement

software

budget

of technical

overrun

performance

likely

1 Failure

meet

the

Failure

results

Critical

requirement would degrade

operational delays and/or

system performance to a point

increased

costs

with

where mission success is

expected $100 K to $ 500

questionable

2 Some

Minor delays

Some

Possible

reduction in in

software

shortage of slippage in

technical

modification

financial

IOC

performance

resources,

possible

overruns

1 Failure

meet

the

Costs, impacts and / or

Marginal

requirement would result in

recoverable schedule slips

degradation of secondary

with expected value of $ 1

mission

K to $ 100 K

320

Software Project Management (CS615)

to Responsive

Sufficient

Realistic

2 Minimal

small

software

financial

achievable

reduction in support

resources

schedule

technical

performance

1 Failure

meet

the

Error results in minor cost

Negligible

requirement would create

and / or schedule impact

inconvenience

non

with expected value of

operational impact

less than $ 1 K

2 No reduction Easily

Possible

Early

technical supportable

budget

achievable

performance

software

under run

IOC

Note:

(1) The potential consequence of undetected software errors or faults.

(2) The potential consequence if the desired outcome is not achieved.

6.4 RISK PROJECTION

Risk projection, also called risk estimation, attempts to rate each risk in two ways-the

likelihood or probability that the risk is real and the consequences of the problems

associated with the risk, should it occur. The project planner, along with other managers

and technical staff, performs four risk projection activities:

(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, and

(4) Note the overall accuracy of the risk projection so that there will be no

misunderstandings.

6.4.1 Developing a Risk Table

A risk table provides a project manager with a simple technique for risk projection. A

sample risk table is illustrated in figure 6.2.

Figure 6.2 Sample risk table prior to sorting

Risks

Category

Probability

Impact

RMMM

Size estimate may be significantly low

60%

Larger number of users than planned

30%

Less reuse than planned

70%

End-users resist system

40%

Delivery deadline will be lightened

50%

Funding will be lost

40%

Customer will change requirements

80%

Technology will not meet expectations

30%

Lack of training on tools

80%

321

Software Project Management (CS615)

Staff inexperienced

80%

Staff turnover will be high

60%

Impact values:

l- Catastrophic

2- Critical

3- marginal

4- Negligible

A project team begins by listing all risks (no matter how remote) in the first column of

the table. This can be accomplished with the help of the risk item check-lists referenced

in Section 6.3. Each risk is categorized in the second column (e.g., PS implies a project

size risk, BU implies a business risk). The probability of occurrence of each risk is

entered in the next column of the table. The probability value for each risk can be

estimated by team members individually. Individual team members are polled in round-

robin fashion until their assessment of risk probability begins to converge.

Next, the impact of each risk is assessed. Each risk component is assessed using the

characterization presented in Figure 6.1, and an impact category is determined. The

categories for each of .the four risk components - performance, support, cost, and

schedule - are averaged to determine an overall impact value.

Figure 6.3 Risk and management concern

Very

High

Impact

Disregard

risk factor

Management

concern

Very

low

Probability

1.0

Of occurrence

Once the first four columns of the risk table have been completed, the table is sorted by

probability and by impact. High-probability, high-impact risks percolate to the top of the

322

Software Project Management (CS615)

table, and low-probability risks drop to the bottom. This accomplishes first order risk

prioritization. The project manager studies the resultant sorted table and defines a cutoff

line. The cutoff line (drawn horizontally at some point in the table) implies that only risks

that lie above the line will be given further attention. Risks that fall below the line are re-

evaluated to accomplish second-order prioritization. Referring to Figure 6.3, 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. However, high-impact risks with moderate to high

probability and low-impact risks with high probability should be carried forward into the

risk analysis steps that follow.

All risks that lie above the cutoff line must be managed. The column labeled RMMM

contains a pointer into Risk Mitigation, Monitoring and Management Plan or

alternatively, a collection of risk information sheets developed for all risks that lie above

the cutoff. The RMMM plan and risk information sheets are discussed in Sections 6.5 and

6.6.

Risk probability can be determined by making individual estimates and then developing a

single consensus value. Although that approach is workable, more sophisticated

techniques for determining risk probability have been developed [AFC88]. Risk drivers

can be assessed on a qualitative probability scale that has the following values:

impossible, improbable, probable, and frequent. Mathematical probability can then be

associated with each qualitative value (e.g., a probability of 0.7 to 1.0 implies a highly

probable risk).

6.4.2 Assessing Risk Impact

Three factors affect the consequences that are likely if a risk does occur: its nature, its

scope, and its timing. The nature of the risk indicates the problems that are likely if it

occurs. For example, a poorly defined external interface to customer hardware (a

technical risk) will preclude early design and testing and will likely lead to system

integration problems late in a project. The scope of a risk combines the severity (just how

serious is it?) with its overall distribution (how much of the project will be affected or

how many customers are harmed?). Finally, the 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.

Returning once more to the risk analysis approach proposed by the U.S. Air Force

fAFC88), the following steps are recommended to determine the overall consequences of

a risk:

1. Determine the average probability of occurrence value for each risk component.

2. Using Figure 6.1, determine the impact for each component based on the criteria

shown.

3. Complete the risk table and analyze the results as described in the preceding sections. .

323

Software Project Management (CS615)

The overall risk exposure, RE, is determined using the following relationship [HAL98]:

RE=P x C.

where P is the probability of occurrence for a risk, and C is the cost to the project should

the risk occur.

For example, assume that the software team defines a project risk in the following

manner:

Risk identification. Only 70 percent of the software components scheduled for reuse

will, in fact, be integrated into the application. The remaining functionality will have to

be custom developed.

Risk probability. 80% (likely).

Risk impact. 60 reusable software components were planned. If only 70 percent can be

used, 18 components would have to be developed from scratch (in addition to other

custom software that has been scheduled for development). Since the average component

is 100 LOC and local data indicate that the software engineering cost for each LOC is

$14.00, the overall cost (impact) to develop the components would be 18 x 100 x 14 =

$25,200.

Risk exposure. RE = 0.80 x 25,200 - $20,200.

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 cutoff in the risk table)

can provide a means for adjusting the final cost estimate for a project. It can also be used

to predict the probable Increase In staff resources required at various points during the

project schedule.

The risk projection and analysis techniques described in Sections 6.4.1 and 6.4.2 are

applied iteratively as the software project proceeds. 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 this

activity, 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 still others.

6.4.3 Risk Assessment

At this point in the risk management process, we have established a set of triplet of the

form [CHA89]:

[rj, lj, xj]

where rj is risk, lj is the likelihood (probability) of the risk, and xj is the impact of the risk.

During risk assessment, we further examine the accuracy of the estimates that were made

during risk projection, attempt to rank the risks that have been uncovered, and begin

thinking about ways to control and/or avert risks that are likely to occur.

324

Software Project Management (CS615)

Figure 6.4 Risk referent level

Referent point (cost value, time value)

Projected

Project termination will

schedule

overrun

Projected cost overrun

For assessment to be useful, a risk referent level [CHA89] must be defined. For most

software projects, the risk components discussed earlier - performance, cost, support, and

schedule also represent risk referent levels: That is, there is a level for performance,

degradation, cost overrun, support difficulty, or schedule slippage (or any combination of

the four) that will cause the project to be terminated. If a combination of risks create

problems that cause one or more of these referent levels to be exceeded, work will stop.

In the context of software risk analysis, a risk referent level has a single point, called the

referent point or break point, at which the decision to proceed with the project or

terminate it (problems are just too great) are equally weighted. Figure 6.4 represents this

situation graphically.

In reality, the referent level can rarely be represented as a smooth line on a graph. In most

cases it is a region in which there are areas of uncertainty; that is, attempting to predict a

management decision based on the combination of referent values is often impossible.

Therefore, during risk assessment, we perform the following steps:

1. Define the risk referent levels for the project.

2. Attempt to develop a relationship between each (rj, lj, xj) and each of the referent

levels.

3. Predict the set of referent points that define a region of termination, bounded by a

curve or areas of uncertainty.

4. Try to predict how compound combinations of risks will affect a referent level.

6.5 RISK REFINEMENT

325

Software Project Management (CS615)

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 do this is to represent the risk in condition-transition-consequence (CTC) II

format [GLU94). That is, the risk is stated in the following form:

Given that <condition> then there is concern that (possibly) <consequence>.

Using the CTC format for the reuse risk noted in Section 6.4.2, we can write:

Given that all reusable software components must conform to specific design standards

and that some do not conform, then there is concern that (possibly) only 70 percent of the

planned reusable modules may actually be integrated into the as-built system, resulting in

the need to custom engineer the remaining 30 percent of components. This general

condition can be refined in the following manner:

Sub condition 1. Certain reusable components were developed by a third party with no

knowledge of internal design standards.

Sub condition 2. The design standard for component interfaces has not been solidified

and may not conform to certain existing reusable components.

Sub condition 3. Certain reusable components have been implemented in a language that

is not supported on the target environment.

The consequences associated with these refined sub conditions remains the same (i.e., 30

percent of software components must be customer engineered), but the refinement helps

to isolate the underlying risks and might lead to easier analysis and response.

6.6 RISK MITIGATION, MONITORING, AND MANAGEMENT

All of the risk analysis activities presented to this point have a single goal to assist the

project team in developing a strategy for dealing with risk. An effective strategy must

consider three issues:

risk avoidance

risk monitoring

risk management and contingency planning

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. For example, assume

that high staff turnover is noted as a project risk, rl Based on past history and

management intuition, the likelihood, ll of high turnover is estimated to be 0.70 (70 per

cent, rather high) and the impact, xl is projected at level 2. That is, high turnover will

have a critical impact on project cost and schedule.

To mitigate this risk, project management must develop a strategy for reducing turnover.

Among the possible steps to be taken are

326

Software Project Management (CS615)

o Meet with current staff to determine causes for turnover (e.g., poor working

conditions, low pay, and competitive job market).

o Mitigate those causes that are under our control before the project starts.

o Once the project commences, assume turnover will occur and develop techniques to

ensure continuity when people leave.

o Organize project teams so that information about each development activity is widely

dispersed.

o Define documentation standards and establish mechanisms to be sure that .documents

are developed in a timely manner.

o Conduct peer reviews of all work (so that more than one person is "up to speed").

o Assign a backup staff member for every critical technologist.

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. In the case of high staff turnover, the following factors can be monitored:

General attitude of team members based on project pressures.

The degree to which the team has jelled.

Interpersonal relationships among team members.

Potential problems with compensation and benefits.

The availability of jobs within the company and outside it.

In addition to monitoring these factors, the project manager should monitor the

effectiveness of risk mitigation steps. This is one mechanism for ensuring continuity,

should a critical individual leave the project. The project manager should monitor

documents carefully to ensure that each can stand on its own and that each imparts

information that would be necessary if a newcomer were forced to join the software team

somewhere in the middle of the project.

Risk management and contingency planning assumes that mitigation efforts have failed

and that the risk has become a reality. Continuing the example, the project is well

underway and a number of people announce that they will be leaving. If the mitigation

strategy has been followed, backup is available, information is documented, and

knowledge has been dispersed across the team. In addition, the project manager may

temporarily refocus resources (and readjust the project schedule) 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.

It is important to note that RMMM steps incur additional project cost. For example,

spending the time to "backup" every critical technologist costs money. Part of risk

management, therefore, is to evaluate when the benefits accrued by the RMMM steps are

outweighed by the costs associated with implementing them. In essence, the project

327

Software Project Management (CS615)

planner performs a classic cost/benefit analysis. If risk aversion steps for high turnover, it

will increase both project cost and duration by an estimated 15 percent, but the

predominant cost factor is "backup," management may decide not to implement this step.

On the other hand, if the risk aversion steps are projected to' increase costs by 5 percent

and duration by only 3 percent management will likely put all into place.

For a large project, 30 or 40 risks may be identified. If between three and seven risk

management steps are identified for each, risk management may become a project in

itself! For this reason, we adapt the Pareto 80-20 rule to software risk. Experience

indicates that 80 percent of the overall project risk (i.e., 80 percent of the potential for

project failure) can be accounted for by only 20 percent of the identified risks. The work

performed during earlier risk analysis steps will help the planner to determine which of

the risks reside in that 20 percent (e.g., risks that lead to the highest risk exposure. For

this reason, some of the risks identified, assessed, and projected may not make it into the

RMMM plan - they don't fall into the critical 20 percent (the risks with highest project

priority).

6.7 SAFETY RISKS AND 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 field.

In the early days of computing, there was reluctance to use computers (and soft- ware) to

control safety critical processes such as nuclear reactors, aircraft flight control, weapons

systems, and large-scale industrial processes. Although the probability .of failure of a

well-engineered system was small, an undetected fault in a computer- based control or

monitoring system could result in enormous economic damage or, worse, significant

human injury or loss of life. But the cost and functional benefits of Computer-based

control and monitoring far outweigh the risk. Today, computer hardware and software are

used regularly to control safety critical systems.

When software is used as part of a control system, complexity can increase by an order of

magnitude or more. Subtle design faults induced by human error-some- thing that can be

uncovered and eliminated in hardware-based conventional control-become much more

difficult to uncover when software is used.

Software safety and hazard analysis [LEV95] are software quality assurance activities

(Chapter 8) that focus on the identification and assessment of potential hazards that may

affect software negatively and cause an entire system to fail. If hazards can be identified

early in the software engineering process, software design features can be specified that

will either eliminate or control potential hazards.

6.8 THE RMMM PLAN

328

Software Project Management (CS615)

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. The RMMM plan documents all work performed as part of risk

analysis and are used by the project manager as part of the overall project plan.

Some software teams do not develop a formal RMMM document. Rather, each risk is

documented individually using a risk information sheet (RIS) [WIL97]. In most cases, the

RIS is maintained using a database system, so that creation and information entry,

priority ordering, searches, and other analysis may be accomplished easily. The format of

the RIS is illustrated in Figure 6.5.

Once RMMM has been documented and the project has begun, risk mitigation and

monitoring steps commence. As we have already discussed, risk mitigation is a problem

avoidance activity. Risk monitoring is a project tracking activity with three primary

objectives: (I) to assess whether predicted risks do, in fact, occur; (2) to ensure that risk

aversion steps defined for the risk are being properly applied; and (3) to collect

information that can be used for future risk analysis. In many cases, the problems that

occur during a project can be traced to more than one risk. Another job of risk monitoring

is to attempt to allocate origin (what risk(s) caused which problems throughout. the

project).

Risk management is not as well developed as are some of the more traditional project

management disciplines. Some organizations feel that risk management is too specialized

advanced for them. Others believe that risk management is optional. Others fear that risk

management may expose flaws in their project plans and strategies that will hurt them in

the competitive world. Certainly these organizations will not talk openly and honestly

about risk and will "shoot the messenger" that brings risk to their attention.

Risk-mature organizations overcome the barriers to practicing effective risk management

in their approach to projects.

Their organizational culture becomes "risk friendly."

Risk management gains priority to rank along with cost, time and scope management.

Decisions are made and resources are allocated based on the results of risk analysis.

The highest quality data are used for risk analysis and resources are committed to the

efforts.

Risk management is viewed as a career path in the organization and those that practice

it are treated as professionals.

Risk analysis functions are given independence in the organization even though that

may make it hard to "control."

Mature risk management organizations look to the best in class to benchmark their risk

management processes.

They use modern tools and are not disdainful of sophisticated and proven approaches.

They measure their effectiveness with metrics.

Project decisions are made on a "risk-adjusted" basis.

Continuous improvement is achieved through regular repetition.

329

Software Project Management (CS615)

They participate in professional interchanges through conferences and journals, sharing

what they have learned.

Project risk is an uncertain event or condition that, if it occurs, has a positive or a

negative effect on at least one project objective. A risk may have one or more causes and,

if it occurs, one or more impacts. For example, a cause may be requiring an

environmental permit to do work or having limited personnel assigned to design the

project. The risk event is that the permitting agency may take longer than planned to issue

a permit for some reason, or the design personnel available and assigned may not be

adequate for the task. If either of these uncertain events occurs, there may be an impact

on the project cost, schedule, or performance. Risk conditions could include aspects of

the project's or organization's environment that may contribute to project risk, such as

poor project management practices, lack of integrated management systems, concurrent

multiple projects, or dependency on external participants who cannot be controlled.

Project risk has its origins in the uncertainty that is present in all projects. Known risks

are those that have been identified and analyzed, and it may be possible to plan for those

risks using the processes described in this chapter. Unknown risks cannot be managed

proactively, and a prudent response by the project team can be to allocate general

contingency against such risks, as well as against any known risks for which it may not

be cost-effective or possible to develop a proactive response.

Organizations perceive risk as it relates to threats to project success or to opportunities to

enhance chances of project success. Risks that are threats to the project may be accepted

if the risk is in balance with the reward that may be gained by taking the risk. For

example, adopting a fast track schedule (Section 6.4) that may be overrun is a risk taken

to achieve an earlier completion date. Risks that are opportunities, such as work

acceleration that may be gained by assigning more expert staff, may be pursued to benefit

the project's objectives.

Individuals, and by extension organizations, have attitudes toward risk that affect both the

accuracy of the perception of risk and the way they respond. Attitudes about risk should

be made explicit wherever possible. A consistent approach to risk that meets the

organization's requirements should be developed for each project, and communication

about risk and its handling should be open and honest. Risk responses reflect an

organization's balance between risk-taking and risk-avoidance.

To be successful, the organization must be committed to addressing the management of

risk proactively and consistently throughout the project.

330

Software Project Management (CS615)

Figure: Project Risk Management Flow

331

Table of Contents: