Risk Management Process

<< Risk & Change Management Concepts

Quality Concept, Producing quality software, Quality Control >>

Software Project Management (CS615)

LECTURE# 41

9. Risk and Change Management

9.4

Risk Management Process

Risk Identification

Risk Identification involves:

Identifying risks that may occur on a particular project

Determining which risks might affect the project

Documenting their characteristics

Participants in risk identification activities can include the following, where

appropriate:

Project manager

Project team leaders

Project team

Risk management team if assigned

Subject matter experts from outside the project team

Customers

End users

Other project managers

Stakeholders

Outside risk management experts

Risk Identification is an iterative process because new risks may become known

as the project progresses through its life cycle. The frequency of iteration and who

participates in each cycle will vary from case to case.

The project team should be involved in the process so that they can develop and

maintain a sense of ownership of and responsibility for the risks and associated

risk response actions. Persons outside the team may provide additional objective

information.

The Risk Identification process usually leads to the Qualitative Risk Analysis

process. Alternatively, it can lead directly to the Quantitative Risk Analysis

process when conducted by an experienced risk manager. On some occasions

simply the identification of a risk may suggest its response, and these should be

recorded for further analysis and implementation in the Risk Response Planning

process.

338

Software Project Management (CS615)

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.

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:

a) Product size-risks associated with the overall size of the software to be

built or modified.

b) Business impact-risks associated

with

constraints

imposed

management or the marketplace.

c) Customer characteristics-risks associated with the sophistication of the

customer and the developer's ability to communicate with the customer in

a timely manner.

d) Process definition-risks associated with the degree to which the software

process has been defined and is followed by the development

organization.

e) Development environment-risks associated with the availability and

quality of the tools to be used to build the product.

f) 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.

g) Staff size and experience-risks associated with the overall technical and

project experience of the software engineers who will do the work.

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

each of the topics can be answered for each software project.

339

Software Project Management (CS615)

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" are listed along with their

probability of occurrence.

A number of comprehensive checklists for software project risk have been pro-

posed 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."

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?

Table 1 displays a sample risk identification questionnaire.

Table 1: Sample Risk Identification Questionnaire

Yes/No/Not Applicable

(NA)

Risk Description

Are requirements changing continuously during

product development?

Do the changing requirements affect each of the

following:

Quality

Functionality

Schedule

Integration

Design

Testing

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?

340

Software Project Management (CS615)

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

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 controlling 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

341

Software Project Management (CS615)

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?

Risk Identification involves identifying risks that may occur on a particular

project and determining which risks might affect the project and documenting

their characteristics.

ii.

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 2: Risk Analysis Table

Probability of

Impact on

Risk Factor

Risk

Occurrence

Project

(Probability x

Description

(0 1)

(1 10)

Impact)

Table 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

342

Software Project Management (CS615)

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.

iii.

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:

1. Risk avoidance

2. Risk monitoring

3. Contingency planning

1. 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 3 displays the format of a risk

management plan.

Table 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)

343

Software Project Management (CS615)

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.

2. 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 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.

344

Software Project Management (CS615)

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.

3. 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.

iv.

Managing Risks: An Example

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

345

Software Project Management (CS615)

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.

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

risks to the project are described in Table 4.

Table 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 5.

Table 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

Performance

Massive tuning

Till

risk due to

of architecture

the

May

high volume

0.6

4.2

Architect

during the

end of

of data to be

design phase

the

processed

and conducting

project

346

Software Project Management (CS615)

a proof of

concepts for

the design

Using the

Till

Cross-

lowest

the

May

browser

0.6

3.0

Developer

compatible

end of

compatibility

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

future changes

development

project

and

enhancement

In Table 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.

9.5

Risk Components and Drivers

347

Software Project Management (CS615)

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:

a) Performance risk - the degree of uncertainty that the product will meet its

requirements and be fit for its intended use.

b) Cost risk - the degree of uncertainty that the project budget will be

maintained.

c) Support risk - the degree of uncertainty that the resultant software will be

easy to correct, adapt, and enhance.

d) 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 2, 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 2: Impact assessment

Components/Category

Performance Support

Cost

Schedule

1 Failure to meet the

Failure results in increased

Catastrophic

requirement would result in

costs and schedule delays

mission failure

with expected values of

$500 K

2 Significant

Non

Significant Unavoidable

degradation to responsive or financial

IOC

non

unsupportable shortages,

achievement

software

budget

of technical

overrun

performance

likely

1 Failure to meet the

Failure results in operational

Critical

requirement would degrade

delays and/or increased costs

system performance to a point with expected $100 K to $

where mission success is

500 K

questionable

348

Software Project Management (CS615)

Possible

Minor delays

Some

2 Some

reduction in

in software

shortage of slippage in

modification

financial

IOC

technical

resources,

performance

possible

overruns

1 Failure to meet the

Costs, impacts and / or

Marginal

requirement would result in

recoverable schedule slips

degradation of secondary

with expected value of $ 1 K

mission

to $ 100 K

2 Minimal to

Responsive

Sufficient Realistic

small

software

financial

achievable

reduction in

support

resources

schedule

technical

performance

1 Failure to meet the

Error results in minor cost

Negligible

requirement would create

and / or schedule impact

inconvenience or non

with expected value of less

operational impact

than $ 1 K

2 No reduction

Easily

Possible

Early

in technical

supportable

budget

achievable IOC

performance

software

under run

Note:

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

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

9.6

Developing a Risk Table

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

projection. A sample risk table is illustrated below.

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%

Staff inexperienced

80%

Staff turnover will be high

60%

349

Software Project Management (CS615)

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 given earlier.

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 the sample risk table, 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 2: Risk and management concern

Very

high

High

Impact

Disregard

risk factor

Management

concern

Very low

Probability

occurrence

1.0

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 table, and low-probability risks drop to the bottom. This

accomplishes first order risk prioritization. The project manager studies the

350

Software Project Management (CS615)

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 2, 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.

9.7

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

9.8

Risk Mitigation, Monitoring, and Management

351

Software Project Management (CS615)

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

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

conditions, low pay, and 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.

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.

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

352

Software Project Management (CS615)

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 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).

9.9

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.

353

Software Project Management (CS615)

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

9.10

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. 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:

1. To assess whether predicted risks 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.

354

Software Project Management (CS615)

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).

355

Table of Contents: