Risk identification is a systematic attempt to specify threats to the project plan (estimates, schedule, resource loading, etc.). By identi...
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 : 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:
There are two distinct types of risks : 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 in a timely manner.
• 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.
A number of 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 is instituted. However, a relatively short list of questions can be used to provide a preliminary indication of whether a project is “at risk.”
Assessing Overall Project Risk
The following questions have derived from risk data obtained by surveying experienced software project managers in different part 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 support 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 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.
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.
