Risk Mitigation, Monitoring, and Management (RMMM) plan

A risk management technique is usually seen in the software Project plan. This
can be divided into Risk Mitigation, Monitoring, and Management Plan
(RMMM). In this plan, all works are done as part of risk analysis. As part of the
overall project plan project manager generally uses this RMMM plan.
In some software teams, risk is documented with the help of a Risk Information
Sheet (RIS). This RIS is controlled by using a database system for easier
management of information i.e creation, priority ordering, searching, and
other analysis. After documentation of RMMM and start of a project, risk
mitigation and monitoring steps will start.
Risk Mitigation :
It is an activity used to avoid problems (Risk Avoidance).
Steps for mitigating the risks as follows.
1. Finding out the risk.
2. Removing causes that are the reason for risk creation.
3. Controlling the corresponding documents from time to time.
4. Conducting timely reviews to speed up the work.

Risk Monitoring :
It is an activity used for project tracking. It has the following primary objectives
as follows.

1. To check if predicted risks occur or not.

2. To ensure proper application of risk aversion steps defined for risk.
3. To collect data for future risk analysis.
4. To allocate what problems are caused by which risks throughout the
project.

Risk Management and planning

It assumes that the mitigation activity failed and the risk is a reality. This task is
done by Project manager when risk becomes reality and causes severe
problems.
If the project manager effectively uses project mitigation to remove risks
successfully then it is easier to manage the risks. This shows that the response
that will be taken for each risk by a manager.
Risk register : The main objective of the risk management plan is the risk
register. This risk register describes and focuses on the predicted threats to a
software project.

Example:
Let us understand RMMM with the help of an example of high staff turnover-
people leave.
Risk Mitigation:
To mitigate this risk, project management must develop a strategy for reducing
turnover. The possible steps to be taken are:
 Meet the current staff to determine causes for turnover (e.g., poor working
conditions, low pay, competitive job market).
 Mitigate those causes that are under our control before the project starts.
 Once the project commences, assume turnover will occur and develop
techniques to ensure continuity when people leave.
 Organize project teams so that information about each development
activity is widely dispersed.
 Define documentation standards and establish mechanisms to ensure that
documents are developed in a timely manner.
 Assign a backup staff member for every critical technologist.

Risk Monitoring:
As the project proceeds, risk monitoring activities commence. The project
manager monitors factors that may provide an indication of whether the risk is
becoming more or less likely. In the case of high staff turnover, the following
factors can be monitored:
 General attitude of team members based on project pressures.
 Interpersonal relationships among team members.
 Potential problems with compensation and benefits.
 The availability of jobs within the company and outside it.

Risk Management:
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 the speed“.

Drawbacks of RMMM:
 It incurs additional project costs.
 It takes additional time.
 For larger projects, implementing an RMMM may itself turn out to be
another tedious project.
 RMMM does not guarantee a risk-free project, infact, risks may also come
up after the project is delivered.

Chapter 25: Risk Management

REACTIVE VS. PROACTIVE RISK STRATEGIES

Reactive risk strategies - worrying about problems when they happen

Proactive risk strategies - begin long before technical work is initiated

Potential risks are identified

their probability and impact are assessed

they are ranked by importance

Not all risks can be avoided

Team works to develop a contingency plan that will enable it to respond in a

controlled and effective manner

SOFTWARE RISKS

Risk always involves two characteristics:

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

Must quantify:

level of uncertainty

degree of loss associated with each risk

Kinds of Risks:

Project risks threaten the project plan.

Identify potential budgetary, schedule, personnel (staffing and organization),

resource, customer, and requirements problems and their impact on a software
project

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

Identify potential design, implementation, interface, verification, and

maintenance problems.

Specification ambiguity, technical uncertainty, technical obsolescence, and

"leading-edge" technology are 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.

Top five business risks :

(1) building an excellent product or system that no one really wants (market risk)

(2) building a product that no longer fits into the overall business strategy for the
company (strategic risk)

(3) building a product that the sales force doesn't understand how to sell
(4) losing the support of senior management due to a change in focus or a change
in people (management risk)

(5) losing budgetary or personnel commitment (budget risks).

Known risks - uncovered after evaluation:

project plan

business and technical environment in which the project is being developed

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

documented requirements or software scope, poor development environment).

Predictable risks - 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 - occur, but difficult to identify in advance.

RISK IDENTIFICATION

· Attempt to specify threats to the project plan (estimates, schedule, resource

loading, etc.)

· Two types of risks:

o Generic risks - potential threat to every software project.

o Product-specific risks - identified by: those with a clear understanding of the

technology, the people, and the environment that is specific to the project at
hand.
§ Identify by looking at the project plan and the software statement of scope

§ Ask question - "What special characteristics of this product may threaten our
project plan?"

Risk item checklist

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.

Short List

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 fully in 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?

Sample Risk Checklist (Long)

Risk Components and Drivers

· U.S. Air Force pamphlet contains guidelines for software risk identification
and abatement.

· Air Force approach requires that the project manager identify the risk
drivers that affect software risk components—performance, cost, support, and
schedule.

· Risk components:

(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.
· Impact of each risk driver on the risk component is divided into one of four
impact categories—negligible, marginal, critical, or catastrophic

Figure 1 - Risk Characterization Table

RISK PROJECTION (AKA RISK ESTIMATION)

Attempts to rate each risk in two ways

· The probability that the risk is real

· The consequences of the problems associated with the risk, should it occur.
Project planner, along with other managers and technical staff, performs four risk
projection activities:

(1) establish a measure 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

(4) note the overall accuracy of the risk projection so that there will be no
misunderstandings.

Developing a Risk Table

Risk table provides a project manager with a simple technique for risk projection

Figure 2 - Risk Table

Steps in Setting up Risk Table

(1) Project team begins by listing all risks in the first column of the table.
Accomplished with the help of the risk item checklists.

(2) Each risk is categorized in the second column

(e.g., PS implies a project size risk, BU implies a business risk).

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

(4) Individual team members are polled in round-robin fashion until their
assessment of risk probability begins to converge.

Assessing Impact of Each Risk

(1) Each risk component is assessed using the Risk Charcterization Table (Figure
1) and impact category is determined.

(2) Categories for each of the four risk components—performance, support, cost,
and schedule—are averaged to determine an overall impact value.

1. A risk that is 100 percent probable is a constraint on the software project.

2. The risk table should be implemented as a spreadsheet model. This enables

easy manipulation and sorting of the entries.

3. A weighted average can be used if one risk component has more significance
for the project.

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

(4) Project manager studies the resultant sorted table and defines a cutoff line.

· 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 below the line are re-evaluated to accomplish second-order
prioritization.

· Risk impact and probability have a distinct influence on management

concern.

o Risk factor with a high impact but a very low probability of occurrence should
not absorb a significant amount of management time.

o 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 a Risk Mitigation,

Monitoring and Management Plan

Assessing Risk Impact

· Three factors determine the consequences if a risk occurs:

o Nature of the risk - the problems that are likely if it occurs.

o e.g., 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.

o Scope of a risk - combines the severity with its overall distribution (how much
of the project will be affected or how many customers are harmed?).

o Timing of a risk - when and how long the impact will be felt.

· Steps recommended to determine the overall consequences of a risk:

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

Using Figure 1, determine the impact for each component based on the criteria
shown.
Complete the risk table and analyze the results as described in the preceding
sections.

Overall risk exposure, RE, determined using:

RE = P x C

P is the probability of occurrence for a risk

C is the the cost to the project should the risk occur.

Example

Assume the software team defines a project risk in the following manner:

Risk identification.

· Only 70 percent of the software components scheduled for reuse will 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 Assessment

· Have established a set of triplets of the form:

[ri, li, xi]

where

ri is risk

li is the likelihood (probability) of the risk

xi is the impact of the risk.

· During risk assessment :

o further examine the accuracy of the estimates that were made during risk
projection

o attempt to rank the risks that have been uncovered

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

· Must Define a risk referent level

o performance, cost, support, and schedule represent risk referent levels.

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

o 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 are
equally weighted.

· Referent level rarely represented as a smooth line on a graph.

· Most cases - a region in which there are areas of uncertainty

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

1. Define the risk referent levels for the project.

2. Attempt to develop a relationship between each (ri, li, xi) 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.

RISK REFINEMENT

· A risk may be stated generally during early stages of project planning.

· With time, more is learned about the project and the risk

o may be possible to refine the risk into a set of more detailed risks

· Represent risk in condition-transition-consequence (CTC) format.

o Stated in the following form:

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

· Using CTC format for the reuse 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:

Subcondition 1. Certain reusable components were developed by a third party

with no knowledge of internal design standards.
Subcondition 2. The design standard for component interfaces has not been
solidified and may not conform to certain existing reusable components.

Subcondition 3. Certain reusable components have been implemented in a

language that is not supported on the target environment.

RISK MITIGATION, MONITORING, AND MANAGEMENT

Effective strategy must consider three issues:

risk avoidance

risk monitoring

risk management and contingency planning

· Proactive approach to risk - avoidance strategy.

· Develop risk mitigation plan.

· e.g. assume high staff turnover is noted as a project risk, r1.

· Based on past history

o the likelihood, l1, of high turnover is estimated to be 0.70

o the impact, x1, is projected at level 2.

o So… high turnover will have a critical impact on project cost and schedule.

· Develop a strategy to mitigate this risk for reducing turnover.

· Possible steps to be taken

Meet with current staff to determine causes for turnover (e.g., poor working
conditions, low pay, competitive job market).
Mitigate those causes that are under our control before the project starts.

Once the project commences, assume turnover will occur and develop techniques
to ensure continuity when people leave.

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.

· Project manager monitors for likelihood of risk

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

· Project manager should monitor the effectiveness of risk mitigation steps.

· Risk management and contingency planning assumes that mitigation efforts

have failed and that the risk has become a reality.

e.g., the project is underway and a number of people announce that they will be
leaving.

· Mitigation strategy makes sure:

§ backup is available
§ information is documented

§ knowledge has been dispersed across the team.

· RMMM steps incur additional project cost

e.g. spending time to "backup" every critical technologist costs money.

· Large project - 30 or 40 risks.

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

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

THE RMMM PLAN

· Risk Mitigation, Monitoring and Management Plan (RMMM) - documents all

work performed as part of risk analysis and is used by the project manager as part
of the overall project plan.

· Alternative to RMMM - risk information sheet (RIS)

RIS is maintained using a database system, so that creation and information entry,
priority ordering, searches, and other analysis may be accomplished easily.
Risk monitoring is a project tracking activity

Three primary objectives:

assess whether predicted risks do, in fact, occur

ensure that risk aversion steps defined for the risk are being properly applied

collect information that can be used for future risk analysis.

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