Page 176 -

CHAPTER 6 RISK ANALYSIS AND MANAGEMENT 147

• Uncertainty—the risk may or may not happen; that is, there are no 100% prob-
able risks. 1

• 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
? What types likely that project schedule will slip and that costs will increase. Project risks identify
of risks are
we likely to potential budgetary, schedule, personnel (staffing and organization), resource, cus-
encounter as the tomer, and requirements problems and their impact on a software project. In Chap-
software is built?
ter 5, project complexity, size, and the degree of structural uncertainty were also
defined as project (and estimation) risk factors.
Technical risks threaten the quality and timeliness of the software to be produced.
If a technical risk becomes a reality, implementation may become difficult or impos-
sible. Technical risks identify potential design, implementation, interface, verifica-
tion, and maintenance problems. In addition, specification ambiguity, technical
uncertainty, technical obsolescence, and "leading-edge" technology are also risk fac-
tors. 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 a 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 com-
pany (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 com-
mitment (budget risks). It is extremely important to note that simple categorization
won't always work. Some risks are simply unpredictable in advance.
Another general categorization of risks has been proposed by Charette [CHA89].
“[Today,] no one has Known risks are those that can be uncovered after careful evaluation of the project
the luxury of getting plan, the business and technical environment in which the project is being devel-
to know a task so oped, and other reliable information sources (e.g., unrealistic delivery date, lack of
well that it holds no documented requirements or software scope, poor development environment). Pre-
surprises, and
surprises mean dictable risks are extrapolated from past project experience (e.g., staff turnover, poor
risk.” communication with the customer, dilution of staff effort as ongoing maintenance
Stephen Grey 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.

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