Risk Identification

The objectives of risk identification are to :
(1) identify and categorize risks that could affect the project and
(2) document these risks.
The outcome of risk identification is a list of risks. For non-complex, low-cost projects, the risks may be kept simply as a list of red flag items. The items can then be assigned to individual team members to watch throughout the project development process and used for risk allocation purposes, as described later in this document. For complex, high-cost projects, the risks can feed the rigorous process of assessment, analysis, mitigation and planning, allocation, and monitoring and updating described in this document.

The risk identification process begins with the team compiling the project's risk events. The identification process will vary, depending on the nature of the project and the risk management skills of the team members, but most identification processes begin with an examination of issues and concerns created by the project development team. These issues and concerns can be derived from an examination of the project description, work breakdown structure, cost estimate, design and construction schedule, procurement plan, or general risk checklists. Checklists and databases can be created for recurring risks, but project team experience and subjective analysis almost always will be required to identify project specific risks. The team should examine and identify project events by reducing them to a level of detail that permits an evaluator to understand the significance of any risk and identify its causes, (i.e., risk drivers).

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.