Software Project Management
CHAPTER THREE
RISK ANALYSIS AND MANAGEMENT
First, risk concerns future happenings. Today and yesterday are beyond active concern, as
we are already reaping what was previously sowed by our past actions. The question is, can we,
therefore, by changing our actions today, create an opportunity for a different and hopefully better
situation for ourselves tomorrow. This means, second, that risk involves change, such as changes
of mind, opinion, actions, or Places. Third, risk involves choice and the uncertainty that choice
itself entails. Thus paradoxically, risk, like death and taxes, is one of the few certainties of life.
When the risk is considered in the context of software engineering, Charette's three conceptual
underpinnings are always in evidence. The future is our concern what risks might cause the
software project to go awry? Change is our concern how will changes in customer requirements,
development technologies, target computers, and all other entities connected to the project affect
the timeliness and overall success? Last, we must grapple with choices-what methods and tools
should we use, how many people should be involved, and how much emphasis on quality is
"enough"?
3.1 REACTIVE VS. PROACTIVE RISK STRATEGIES
Reactive risk management tries to reduce the damage of potential threats and speed an
organization’s recovery from them but assumes that those threats will happen eventually. One
fundamental point about reactive risk management is that the disaster or threat must occur before
management responds. The reactive approach learns from past or current events and prepares for
future events. For example, businesses can purchase “cybersecurity insurance” to cover the costs
of a security disruption. This strategy assumes that a breach will happen at some point. Once that
breach does occur, the business might understand more about how to avoid future breaches, and
perhaps could even tailor its insurance policies accordingly. Fundamentally, however, the
organization reacts after the threat has occurred and alters its measures to prevent future potential
risks.
Proactive risk management identifies threats and aims to prevent those events from ever
happening in the first place. Proactive risk management is all about taking preventative measures
before the event to decrease its severity, and that’s a good thing to do. As the name suggests,
proactive risk management means that you identify risks before they happen and figure out ways
to avoid or alleviate the risk. It seeks to reduce the hazard’s risk potential or, even better, prevent
the threat altogether. A good example here is vulnerability testing and remediation. Any
organization of appreciable size is likely to have vulnerabilities in its software, which attackers
could find and exploit. So regular testing (or, even better, continuous testing) can help to repair
those vulnerabilities and eliminate that particular threat.
pg. 1
Software Project Management
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.
3.2 SOFTWARE RISKS
Although there has been considerable debate about the proper definition of software risk,
there is general agreement that 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.
When risks are analyzed, it is important to quantify the level of uncertainty and the degree
of loss associated with each risk. To accomplish this, different categories of risks are considered.
Project risks threaten the project plan. That is, if project risks become real, it is likely that the
project schedule will slip and that costs will increase. Project risks identify potential budgetary,
schedule, personnel (staffing and organization), resource, customer, and requirements problems
and their impact on a software project.
Technical risks threaten the quality and timeliness of the software to be produced. If a
technical risk becomes a reality, the implementation may become difficult or impossible.
Technical risks identify potential design, implementation, interface, verification, and maintenance
problems. In addition, specification ambiguity, technical uncertainty, technical obsolescence, and
"leading edge" technology are also risk factors. Technical risks occur because the problem is
harder to solve than we thought it would be.
Business risks threaten the viability of the software to be built. Business risks often
jeopardize the project or the product. Candidates for the top five business risks are (1) building an
excellent product or system that no one wants (market risk), (2) building a product that no longer
fits into the overall business strategy for the company (strategic risk), (3) building a product that
the sales force doesn't understand how to sell, (4) losing the support of senior management due to
a change in focus or a change in people (management risk), and (5) losing budgetary or personnel
commitment (budget risks). It is extremely important to note that simple categorization won't
always work. Some risks are simply unpredictable in advance.
Known risks are those that can be uncovered after careful evaluation of the project plan, the
business and technical environment in which the project is being developed, and other reliable
information sources (e.g., unrealistic delivery date, lack of documented requirements, or software
scope, poor development environment). Predictable risks are extrapolated from past project
experience (e.g., staff turnover, poor communication with the customer, dilution of staff effort as
ongoing maintenance requests are serviced). Unpredictable risks are the joker in the deck. They
can and do occur, but they are extremely difficult to identify in advance.
pg. 2
Software Project Management
3.3 RISK IDENTIFICATION
Risk identification is a systematic attempt to specify threats to the project plan (estimates,
schedule, resource loading, etc.). By identifying known and predictable risks, the project manager
takes a first step toward avoiding them when possible and controlling them when necessary. There
are two distinct types of risks for each of the categories: generic risks and product-specific risks.
Generic risks are a potential threat to every software project. Product-specific risks can be
identified only by those with a clear understanding of the technology, the people, and the
environment that is specific to the project at hand. To identify product-specific risks, the project
plan and the software statement of scope are examined and an answer to the following question is
developed: "What special characteristics of this product may threaten our project plan?"
One method for identifying risks is to create a risk item checklist. The checklist can be
used for risk identification and focuses on some subset of known and predictable risks in the
following generic subcategories:
• Product size: risks associated with the overall size of the software to be built or modified.
• Business impact: risks associated with constraints imposed by management or the
marketplace.
• Customer characteristics: risks associated with the sophistication of the customer and the
developer's ability to communicate with the customer on time.
• 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.
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. Drivers for performance, support, cost, and
schedule are discussed in answer to later questions. Several comprehensive checklists for software
project risk have been proposed in the literature. These provide useful insight into generic risks
for software projects and should be used whenever risk analysis and management are instituted.
However, a relatively short list of questions can be used to provide a preliminary indication of
whether a project is “at risk.”
pg. 3
Software Project Management
3.3.1 Assessing Overall Project Risk
The following questions have been derived from risk data obtained by surveying
experienced software project managers in different parts of the world.
The questions are ordered by their relative importance to the success of a project.
1. Have top software and customer managers formally committed to supporting 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 the project scope stable?
7. Does the software engineering team have the right mix of skills?
8. Are project requirements stable?
9. Does the project team have experience with the technology to be implemented?
10. Is the number of people on the project team adequate to do the job?
11. Do all customer/user constituencies agree on the importance of the project and on the
requirements for the system/product to be built?
If any one of these questions is answered negatively, mitigation, monitoring, and
management steps should be instituted without fail. The degree to which the project is at risk is
directly proportional to the number of negative responses to these questions
3.3.2 Risk Components and Drivers
The U.S. Air Force has written a pamphlet that contains excellent guidelines for software
risk identification 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:
• Performance risk: the degree of uncertainty that the product will meet its requirements
and be fit for its intended use.
• Cost risk: the degree of uncertainty that the project budget will be maintained
• Support risk: the degree of uncertainty that the resultant software will be easy to correct,
adapt and enhance
• Schedule risk: the degree of uncertainty that the project schedule will be maintained and
that the product will be delivered on time.
The impact of each risk driver on the risk component is divided into one of four impact categories
negligible, marginal, critical, or catastrophic.
pg. 4
Software Project Management
3.4 RISK REFINEMENT
During the early stages of project planning, a risk may be stated quite generally. As time passes
and more is learned about the project and the risk, it may be possible to refine the risk into a set
of more detailed risks, each somewhat easier to mitigate, monitor, and manage. The formulation
system is gathered from the Software Engineering Institute (SEI) and is called the CTC format
(Condition, Transition, Consequence). This format allows you to separate conditions and
consequences of the risk and thereby provides you with easier categorization and
understandability.
This general condition can be refined in the following manner:
Sub condition 1: Certain reusable components were developed by a third party with no
knowledge of internal design standards.
Sub condition 2: The design standard for component interfaces has not been solidified and may
not conform to certain existing reusable components.
Sub condition 3: Certain reusable components have been implemented in a language that is not
supported in the target environment.
3.5 RISK MITIGATION, MONITORING, AND MANAGEMENT
The goal of the risk mitigation, monitoring and management plan is to identify as many
potential risks as possible. Risk Mitigation is a problem avoidance activity, its primary objective
can be achieved by developing a plan. Risk Monitoring is a project tracking activity, its objectives
are to assess whether predicted risks do/in-fact occur, to ensure that risk aversion steps defined for
the risk are being properly applied, to collect information that can be used for future risk analysis.
Risk Management includes contingency plans that risk will occur. 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 project risk, r1. Based on history and management intuition, the likelihood,
l1, of high turnover is estimated to be 0.70 (70 percent, rather high) and the impact, x1, 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, competitive job market)
• Mitigate those causes that are under our control before the project
pg. 5
Software Project Management
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 on time.
• 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 indicate whether the risk is becoming more or less likely.
In the case of high staff turnover, the following factors can be monitored:
• A 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.
Risk management and contingency planning assume that mitigation efforts have failed and
that the risk has become a reality. Continuing the example, the project is well underway and
many 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.
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 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 the highest project priority)
3.6 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
pg. 6
Software Project Management
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 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.
3.7 THE R MMM 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
is 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. In most cases, the RIS is maintained using a database system, so that creation
and information entry, priority orders, searches, and other analysis may be accomplished easily.
Once RMMM has been documented and the project has begun, risk mitigation and
monitoring steps commence. 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; and (3) to collect information that can be used for future risk analysis. In many cases,
the problems that occur during a project can be traced to more than one risk. Another job of risk
monitoring is to attempt to allocate origin (what risk(s) caused which problems throughout the
project).
pg. 7
Software Project Management
Fig. Risk information sheet(RIS)
pg. 8
