Page 177 -

148 PART TWO MANAGING SOFTWARE PROJECTS

6.3 RISK IDENTIFICATION

Risk identification is a systematic attempt to specify threats to the project plan (esti-
mates, schedule, resource loading, etc.). By identifying known and predictable risks,
the project manager takes a first step toward avoiding them when possible and con-
trolling them when necessary.
There are two distinct types of risks for each of the categories that have been pre-
Although generic risks sented in Section 6.2: generic risks and product-specific risks. Generic risks are a
are important to potential threat to every software project. Product-specific risks can be identified only
consider, usually the
product-specific risks by those with a clear understanding of the technology, the people, and the environ-
cause the most ment that is specific to the project at hand. To identify product-specific risks, the proj-
headaches. Be certain ect plan and the software statement of scope are examined and an answer to the
to spend the time to following question is developed: "What special characteristics of this product may
identify as many threaten our project plan?"
product-specific risks as
possible. 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 cus-
tomer and the developer's ability to communicate with the customer in a
timely manner.
Risk item checklist • Process definition—risks associated with the degree to which the software
process has been defined and is followed by the development organiza-
tion.
• 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 ques-
tions 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" [AFC88] are listed along with their probability