CS615 - Software Project Management - Lecture Handout 41

User Rating:  / 0
PoorBest 

Related Content: CS615 - VU Lectures, Handouts, PPT Slides, Assignments, Quizzes, Papers & Books of Software Project Management

Risk and Change Management

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

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:

  1. Product size-risks associated with the overall size of the software to be built or modified.
  2. Business impact-risks associated with constraints imposed by management or the marketplace.
  3. Customer characteristics-risks associated with the sophistication of the customer and the developer's ability to communicate with the customer in a timely manner.
  4. Process definition-risks associated with the degree to which the software process has been defined and is followed by the development organization.
  5. Development environment-risks associated with the availability and quality of the tools to be used to build the product.
  6. 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.
  7. 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.

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

During risk identification, you obtain answers to the following queries:

  1. Why is the risk important?
  2. What information is needed to track the status of the risk?
  3. Who is responsible for the risk management activity?
  4. What resources are needed to perform the activity?
  5. 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

SN   Yes/No/Not Applicable
(NA)
A. Risk Description  
1 Are requirements changing continuously during
product development?
 
2 Do the changing requirements affect each of the
following:
 
  Quality  
  Functionality  
  Schedule  
  Integration  
  Design  
  Testing  
3 Are the external interfaces changing?  
4 Are the requirements missing or incompletely
specified?
 
5 Are there any missing requirements?  
6 Can these requirements be incorporated into the
system?
 
7 Does the client have unwritten requirements or
expectations?
 
8 Is there a way to capture these requirements?  
9 Are requirements unclear or in need of interpretation?  
10 Are you able to understand the requirements as
written?
 
11 Will the requirements lead to the product the client
wants?
 
12 Are there any requirements that may not specify what
the client really wants?
 
B. Product Design  
1 Do you encounter problem in meeting functionality
requirements?
 
2 Are there any specified algorithms that may not
satisfy the requirements?
 
3 Will the design and/or implementation be difficult to
achieve?
 
4 Are there any requirements or functions that are
difficult to design?
 
C. Reusability  
1 Are you reusing the program?  
2 Do you foresee any problems in documentations?  
3 Do you foresee any problems in performance?  
4 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 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.

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

Risk
Description
Probability of
Occurrence
(0 – 1)
Impact on
Project
(1 – 10)
Risk Factor
(Probability x
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 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.

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

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

Risk
Description
Probability
of
Occurrence
(0 – 1)
Impact
on
Project
(1 –
10)
Risk
Factor
(Probability
x Impact)
Mitigation
Steps
Responsibility Start
Date
End
Date
               
               
               
               

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

Risk
Description
Probability
of
Occurrence
(0 – 1)
Impact
on
Project
(1 –
10)
Risk
Factor
(Probability
x Impact)
Mitigation
Steps
Responsibility Start
Date
End
Date
Inexperience
Staff
0.8 3 2.4 Project
Manager
Conducting
training
sessions before
the need
commencement
of project
May
15
July
15
Performance
risk due to
high volume
of data to be
processed
0.6 7 4.2 Architect Massive tuning
of architecture
during the
design phase
and conducting a proof of
concepts for
the design
May
15
Till
the
end of
the
project
Crossbrowser
compatibility
0.6 5 3.0 Developer Using the
lowest
compatible
browser for
development
May
15
Till
the
end of
the
project
Involvement
of new
technology
0.5 5 2.5 Project
Manager
Ensuring all
details
pertaining to
the technology
is available and
keeping in
close touch
with the
technology
vendor
May Till
the
end of
the
project
Design
changes
during
development
0.6 8 4.8 Architect Designing a
flexible
architecture
that can
accommodate
future changes
and
enhancement
May
15
Till
the
end of
the
project

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.

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:

  1. Performance risk - the degree of uncertainty that the product will meet its requirements and be fit for its intended use.
  2. Cost risk - the degree of uncertainty that the project budget will be maintained.
  3. Support risk - the degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance.
  4. 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
Catastrophic 1 Failure to meet the
requirement would result in
mission failure
Failure results in increased
costs and schedule delays
with expected values of
$500 K
2 Significant
degradation to
non
achievement
of technical
performance
Non
responsive or
unsupportable
software
Significant
financial
shortages,
budget
overrun
likely
Unavoidable
IOC
Critical 1 Failure to meet the
requirement would degrade
system performance to a point
where mission success is
questionable
Failure results in operational
delays and/or increased costs
with expected $100 K to $
500 K
2 Some
reduction in
technical
performance
Minor delays
in software
modification
Some
shortage of
financial
resources,
possible
overruns
Possible
slippage in
IOC
Marginal 1 Failure to meet the
requirement would result in
degradation of secondary
mission
Costs, impacts and / or
recoverable schedule slips
with expected value of $ 1 K
to $ 100 K
2 Minimal to
small
reduction in
technical
performance
Responsive
software
support
Sufficient
financial
resources
Realistic
achievable
schedule
Negligible 1 Failure to meet the
requirement would create
inconvenience or non
operational impact
Error results in minor cost
and / or schedule impact
with expected value of less
than $ 1 K
2 No reduction
in technical
performance
Easily
supportable
software
Possible
budget
under run
Early
achievable IOC

Note:

  1. The potential consequence of undetected software errors or faults.
  2. The potential consequence if the desired outcome is not achieved.

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
Larger number of users than planned
Less reuse than planned
End-users resist system
Delivery deadline will be lightened
Funding will be lost
Customer will change requirements
Technology will not meet expectations
Lack of training on tools
Staff inexperienced
Staff turnover will be high
PS
PS
PS
BU
BU
CU
PS
TE
DE
ST
ST
60%
30%
70%
40%
50%
40%
80%
30%
80%
80%
60%
2
3
2
3
2
1
2
1
3
2
2
 

Impact values:

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

Risk and management concern

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

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.

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

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

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

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.

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