ZeePedia

Risk Management Process

<< Risk & Change Management Concepts
Quality Concept, Producing quality software, Quality Control >>
img
Software Project Management (CS615)
LECTURE# 41
9. Risk and Change Management
9.4
Risk Management Process
i.
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
img
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
by
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
img
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:
a.
Why is the risk important?
b.
What information is needed to track the status of the risk?
c.
Who is responsible for the risk management activity?
d.
What resources are needed to perform the activity?
e.
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
SN
(NA)
A.
Risk Description
Are requirements changing continuously during
1)
product development?
Do the changing requirements affect each of the
2)
following:
Quality
Functionality
Schedule
Integration
Design
Testing
3)
Are the external interfaces changing?
Are the requirements missing or incompletely
4)
specified?
5)
Are there any missing requirements?
Can these requirements be incorporated into the
6)
system?
Does the client have unwritten requirements or
7)
expectations?
340
img
Software Project Management (CS615)
8)
Is there a way to capture these requirements?
9)
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?
B.
Product Design
Do you encounter problem in meeting functionality
1)
requirements?
Are there any specified algorithms that may not
2)
satisfy the requirements?
Will the design and/or implementation be difficult to
3)
achieve?
Are there any requirements or functions that are
4)
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
341
img
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
img
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
on
Risk
of
Factor
Mitigation
Start  End
Project
Responsibility
Description Occurrence
(Probability
Steps
Date Date
(1 ­
(0 ­ 1)
x Impact)
10)
343
img
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
img
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
img
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
on
Risk
of
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
3
2.4
Staff
Manager
the need
15
15
commencement
of project
Performance
Massive tuning
Till
risk due to
of architecture
the
May
high volume
0.6
7
4.2
Architect
during the
end of
15
of data to be
design phase
the
processed
and conducting
project
346
img
Software Project Management (CS615)
a proof of
concepts for
the design
Using the
Till
Cross-
lowest
the
May
browser
0.6
5
3.0
Developer
compatible
end of
15
compatibility
browser for
the
development
project
Ensuring all
details
pertaining to
Till
the technology
Involvement
the
Project
is available and
of new
0.5
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
8
4.8
Architect
end of
during
accommodate
15
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
img
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
img
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
PS
60%
2
Larger number of users than planned
PS
30%
3
Less reuse than planned
PS
70%
2
End-users resist system
BU
40%
3
Delivery deadline will be lightened
BU
50%
2
Funding will be lost
CU
40%
1
Customer will change requirements
PS
80%
2
Technology will not meet expectations
TE
30%
1
Lack of training on tools
DE
80%
3
Staff inexperienced
ST
80%
2
Staff turnover will be high
ST
60%
2
349
img
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
0
Probability
Of
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
img
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
img
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
img
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
img
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
img
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:
  1. Introduction & Fundamentals
  2. Goals of Project management
  3. Project Dimensions, Software Development Lifecycle
  4. Cost Management, Project vs. Program Management, Project Success
  5. Project Management’s nine Knowledge Areas
  6. Team leader, Project Organization, Organizational structure
  7. Project Execution Fundamentals Tracking
  8. Organizational Issues and Project Management
  9. Managing Processes: Project Plan, Managing Quality, Project Execution, Project Initiation
  10. Project Execution: Product Implementation, Project Closedown
  11. Problems in Software Projects, Process- related Problems
  12. Product-related Problems, Technology-related problems
  13. Requirements Management, Requirements analysis
  14. Requirements Elicitation for Software
  15. The Software Requirements Specification
  16. Attributes of Software Design, Key Features of Design
  17. Software Configuration Management Vs Software Maintenance
  18. Quality Assurance Management, Quality Factors
  19. Software Quality Assurance Activities
  20. Software Process, PM Process Groups, Links, PM Phase interactions
  21. Initiating Process: Inputs, Outputs, Tools and Techniques
  22. Planning Process Tasks, Executing Process Tasks, Controlling Process Tasks
  23. Project Planning Objectives, Primary Planning Steps
  24. Tools and Techniques for SDP, Outputs from SDP, SDP Execution
  25. PLANNING: Elements of SDP
  26. Life cycle Models: Spiral Model, Statement of Requirement, Data Item Descriptions
  27. Organizational Systems
  28. ORGANIZATIONAL PLANNING, Organizational Management Tools
  29. Estimation - Concepts
  30. Decomposition Techniques, Estimation – Tools
  31. Estimation – Tools
  32. Work Breakdown Structure
  33. WBS- A Mandatory Management Tool
  34. Characteristics of a High-Quality WBS
  35. Work Breakdown Structure (WBS)
  36. WBS- Major Steps, WBS Implementation, high level WBS tasks
  37. Schedule: Scheduling Fundamentals
  38. Scheduling Tools: GANTT CHARTS, PERT, CPM
  39. Risk and Change Management: Risk Management Concepts
  40. Risk & Change Management Concepts
  41. Risk Management Process
  42. Quality Concept, Producing quality software, Quality Control
  43. Managing Tasks in Microsoft Project 2000
  44. Commissioning & Migration