Page 174 -

CHAPTER

6 RISK ANALYSIS AND
MANAGEMENT

KEY n his book on risk analysis and management, Robert Charette [CHA89] pre-
CONCEPTS I sents a conceptual definition of risk:
assessment . . . . 154
components and
drivers . . . . . . . . 149 First, risk concerns future happenings. Today and yesterday are beyond active con-
cern, as we are already reaping what was previously sowed by our past actions. The
identification . . . 148
question is, can we, therefore, by changing our actions today, create an opportunity
mitigation. . . . . . 156
for a different and hopefully better situation for ourselves tomorrow. This means,
monitoring . . . . . 157
second, that risk involves change, such as in changes of mind, opinion, actions, or
projection . . . . . . 151 places . . . [Third,] risk involves choice, and the uncertainty that choice itself entails.
refinement . . . . . 156 Thus paradoxically, risk, like death and taxes, is one of the few certainties of life.
risk exposure . . 153
When risk is considered in the context of software engineering, Charette's three
risk strategies. . 146 conceptual underpinnings are always in evidence. The future is our concern—
risk table . . . . . . 151 what risks might cause the software project to go awry? Change is our con-
RMMM plan. . . . 159 cern—how will changes in customer requirements, development technologies,
safety and target computers, and all other entities connected to the project affect timeli-
hazards . . . . . . . 158 ness and overall success? Last, we must grapple with choices—what methods
and tools should we use, how many people should be involved, how much
emphasis on quality is "enough"?

QUICK What is it? Risk analysis and Lots of things can go wrong, and frankly, many
LOOK management are a series of steps often do. It’s for this reason that being prepared—
that help a software team to understanding the risks and taking proactive mea-
understand and manage uncertainty. Many prob- sures to avoid or manage them—is a key element
lems can plague a software project. A risk is a of good software project management.
potential problem—it might happen, it might not. What are the steps? Recognizing what can go
But, regardless of the outcome, it’s a really good wrong is the first step, called “risk identification.”
idea to identify it, assess its probability of occur- Next, each risk is analyzed to determine the like-
rence, estimate its impact, and establish a con- lihood that it will occur and the damage that it
tingency plan should the problem actually occur. will do if it does occur. Once this information is
Who does it? Everyone involved in the software established, risks are ranked, by probability and
process—managers, software engineers, and cus- impact. Finally, a plan is developed to manage
tomers—participate in risk analysis and man- those risks with high probability and high
agement. impact.
Why is it important? Think about the Boy Scout motto: What is the work product? A risk mitigation, moni-
“Be prepared.” Software is a difficult undertaking. toring, and management (RMMM) plan or

145