• Project Risks threaten the project plan. These risks include potential budgetary, schedule, personnel, resource, customer, and requirements problems, and if they become real, it is likely that the project schedule will slip and that costs will increase.
• Technical Risks threaten the quality and timeliness of the software to be produced. These risks identify potential design, implementation, interfacing, verification, and maintenance problems. Technical risks occur because the problem is harder to solve than we thought it would be, and if they become a reality, implementation may become difficult or impossible.
• Business Risks threaten the viability of the software to be built. It is important to note that simple categorization won't always work, and that some risks are simply unpredictable in advance. These risks often jeopardize the project or product.
• Known Risks are those that can be uncovered after careful evaluation of the project plan, the business and technical environment in which the project is being developed, and other reliable information sources.
• Predictable Risks are extrapolated from past project experience (e.g., staff turnover, poor communication with the customer, dilution of staff effort as ongoing maintenance requests are serviced.)
• Unpredictable Risks can and do occur, but they are extremely difficult to identify in advance.

Risk Identification

Risk Identification is a systematic attempt to specify threats to the project plan. By identifying the known and predictable risks, the project manager takes a first step toward avoiding them when possible and controlling them when necessary. There are two types of risks: Generic Risks are a potential threat to every software project, and Product-Specific Risks can only be identified by those with a clear understanding of the technology, people, and environment that is specific to the project at hand.

One method for identifying risks is to create a risk item checklist which can be used for risk identification and focuses on some subset of known and predictable risks in the following generic subcategories: product size, business impact, customer characteristics, process definition, development environment, technology to be built, staff size and experience.

Product Size Risks-- It is said that 'project risk is directly proportional to product size'. The following is a risk item checklist identifying generic risks associated with product size. The information is then compared to past experience, and if a large percentage deviation occurs or if numbers are similar, but past results were considerably less than satisfactory, risk is high.

• Estimated size of the product in LOC or FP?
• Degree of confidence in estimated size estimate?
• Estimated size of product in number of programs, files, transactions?
• Percentage deviation in size of product from average for previous products?
• Size of database created or used by the product?
• Number of users of the product?
• Number of projected changes to the requirements for the product? before delivery? after delivery?
• Amount of reused software?

Business Impact Risks-- Below is a checklist which identifies generic risks associated with business impact. Each response must be compared to past experience, and if a large percentage deviation occurs or if numbers are similar, but past results were considerably less than satisfactory, risk is high.

• Effect of this product on company revenue?
• Visibility of this product to senior management?
• Reasonableness of delivery deadline?
• Number of customers who will use this product and the consistency of their needs relative to the product?
• Number of other products/systems with which this product must be interoperable?
• Sophistication of end users?
• Amount and quality of product documentation that must be produced and delivered to the customer?
• Governmental constraints on the construction of the product?
• Costs associated with late delivery?
• Costs associated with a defective product?

Customer Related Risks-- It is important to note that: customers have different needs, customers have different personalities, customers also have varied associations with their suppliers, and customers are often contradictory. The following checklist identifies generic risks associated with different customers. If the answer to any of these questions is 'no', further investigation should be undertaken to assess risk potential.

• Have you worked with the customer in the past?
• Does the customer have a solid idea of what is required? Has the customer spent the time to write it down?
• Will the customer agree to spend time in formal requirements gathering meetings to identify project scope?
• Is the customer willing to establish rapid communication links with the developer?
• Is the customer willing to participate in reviews?
• Is the customer technically sophisticated in the product area?
• Is the customer willing to let people do their job--that is, will the customer resist looking over your shoulder during technically detailed work?
• Does the customer understand the software process?

Process Risks-- If a majority of the following questions are answered 'no', software process is weak and risk is high.

Process Issues

• Does your senior management support a written policy statement that emphasizes the importance of a standard process for software development?
• Has your organization developed a written description of the software process to be used on this project?
• Are staff members 'signed up' to the software process as it is documented and willing to use it?
• Is the software process used for other projects?
• Has your organization developed or acquired a series of software engineering training courses for managers and technical staff?
• Are published software engineering standards provided for every software developer and software manager?
• Have document outlines and examples been developed for all deliverables defined as part of the software process?
• Are formal technical reviews of the requirements specification, design, and code conducted regularly?
• Are formal technical reviews of test procedures and test cases conducted regularly?
• Are the results of each formal technical review documented, including errors found and resources used?
• Is there some mechanism for ensuring that work conducted on a project conforms with software engineering standards?
• Is configuration management used to maintain consistency among system/software requirements, design, code, and test cases?
• Is a mechanism used for controlling changes to customer requirements that impact the software?
• Is there a documented statement of work, a software requirements specification, and a software development plan for each subcontract?
• Is a procedure followed for tracking and reviewing the performance of subcontractors?

Technical Issues

• Are facilitated application specification techniques used to aid in communication between the customer and developer?
• Are specific methods used for software analysis?
• Do you use a specific method for data and architectural design?
• Is more than 90 percent of your code written in a high-order language?
• Are specific conventions for code documentation defined and used?
• Do you use specific methods for test case design?
• Are software tools used to support planning and tracking activities?
• Are configuration management software tools used to control and track change activity throughout the software process?
• Are software tools used to support the software analysis and design process?
• Are tools used to create software prototypes?
• Are software tools used to support the testing process?
• Are software tools used to support the production and management of documentation?
• Are quality metrics collected for all software projects?
• Are productivity metrics collected for all software projects?

Technology Risk-- It is very difficult to foresee technology risks, much less plan for them. If the answer to any of the following questions associated with technology to be built is 'yes', further investigation should be undertaken to assess risk potential.

• Is the technology to be built new to your organization?
• Do the customer's requirements demand the creation of new algorithms or input or output technology?
• Does the software interface with new or unproven hardware?
• Does the software to be built interface with vendor supplied software products that are unproven?
• Does the software to be built interface with a database system whose function and performance have not been proven in this application area?
• Is a specialized user interface demanded by product requirements?
• Do requirements for the product demand the creation of program components that are unlike any previously developed by your organization?
• Do requirements demand the use of new analysis, design, or testing methods?
• Do requirements demand the use of unconventional software development methods, such as formal methods, AI-based approaches, and artificial neural networks?
• Do requirements put excessive performance constraints on the product?
• Is the customer uncertain that the functionality requested is "doable"?

Development Environment Risk-- supports the project team, the process, and the product. If a majority of the following questions are answered 'no', the software development environment is weak and risk is high.

• Is a software project management tool available?
• Is a software process management tool available?
• Are tools for analysis and design available?
• Do analysis and design tools deliver methods that are appropriate for the product to be built?
• Are compilers or code generators available and appropriate for the product to be built?
• Are testing tools available and appropriate for the product to be built?
• Are software configuration management tools available?
• Does the environment make use of a database or repository?
• Are all software tools integrated with one another?
• Have members of the project team received training in each of the tools?
• Are local experts available to answer questions about the tools?
• Is on-line help and documentation for the tools adequate?

Risks Associated with Staff Size and Experience-- If the answer to any of the following questions is 'no', further investigation should be undertaken to assess risk potential.

• Are the best people available?
• Do the people have the right combination of skills?
• Are enough people available?
• Are staff committed for entire duration of the project?
• Will some project staff be working only part time on this project?
• Do staff have the right expectations about the job at hand?
• Have staff received necessary training?
• Will turnover among staff be low enough to allow continuity?

Risk Projection-- also called risk estimation, attempts to rate each risk in two ways--the likelihood or probability that the risk is real and the consequences of the problems associated with the risk, should it occur. There are four risk projection activities: (1) Establish a scale that reflects the perceived likelihood of a risk; (2) Delineate the consequences of the risk; (3) Estimate the impact of the risk on the project and product; (4) Note the overall accuracy of the risk projection so that there will be no misunderstandings.

Risk Assessment-- involves the further examination of the accuracy of the estimates that were made during risk projection. Risk Assessment attempts to prioritize the risks that have been uncovered, and begin thinking about ways to control and/or avert risks that are likely to occur.

Steps in risk assessment:

1. Define the risk referent levels (performance, cost, support, and schedule) for the project

2. Attempt to develop a relationship between each [ri, li, xi] and each of the referent levels

3. Predict the set of referent points that define a region of termination, bounded by a curve or areas of uncertainty.

4. Try to predict how compound combinations of risks will affect a referent level.

RMMM Plan-- The risk management steps can be organized into a separate Risk Mitigation, Monitoring, and Management Plan (RMMM). The RMMM Plan documents all work performed as part of risk analysis and is used by the project manager as part of the overall Project Plan. For an outline of the RMMM Plan, see the Pressman textbook, page 149.

Comments: reithel@bus.olemiss.edu