SEI RISK PROGRAM

To enable engineers and managers to identify, sufficiently early, the risks associated with software acquisition, development, integration, and deployment, SEI conducted its SEI Risk Program so that appropriate management and mitigation strategies can be developed on a timely basis [6].

The SEI Risk Program provides a structured process, supported by methods and tools, for identifying, analyzing, and mitigating the uncertainties encountered in a specific software engineering effort. Many of the most serious issues encountered in system acquisition are the result of risks that either remain unrecognized and/or are ignored until they have already created serious consequences. This focus on risk management is important because structured techniques, even quite simple ones, can be effective in identifying risk, and approaches, procedures, and techniques do exist for risk mitigation [6].

SEI Risk Program uses the three groups of methodologies (SRE, TRM, and CRM) are based on three basic constructs for risk management developed at the SEI (risk management paradigm, risk taxonomy, and risk clinic) [6].  In the following section, the report will introduce the SRE – Software Risk Evaluation method and its constructs; risk management paradigm and risk taxonomy.

SEI Risk Management Paradigm

SEI risk management paradigm describes the different activities involved in the software development risk management (Figure 4) [6].  Communication is placed in the center of the paradigm because it controls information flows and, often, it is the largest obstacle in risk management. By using this paradigm as a framework, a risk management practice can be conducted.

Figure 4: Risk Management Activities

The main activities of the SEI Risk Paradigm are described by SEI as the following [6]:

Identify
Before risks can be managed, they must be identified. Identification surfaces risks before they become problems. The SEI has developed techniques for surfacing risks by the application of a systematic process that encourages project personnel to raise concerns and issues.

Analyze
Analysis is the conversion of risk data into risk decision-making information. Analysis provides the basis for the project manager to work on the “right” and most critical risks.

Plan
Planning turns risk information into decisions and actions. Planning involves developing actions to address individual risks, prioritizing risk actions, and creating an integrated risk management plan. The plan for a specific risk can take many forms (like mitigating the impact by a contingency plan, avoiding the risk, accepting risk and taking no further actions, studying about it to get more information etc). The key to risk action planning is to consider the future consequences of a decision made today.

Track
Tracking consists of monitoring the status of risks and the actions taken to ameliorate them. Appropriate risk metrics are identified and monitored to enable the evaluation of the status of as well as of risk mitigation plans. Tracking serves as the “watchdog” function of management.

Control
Risk control corrects deviations from planned risk actions. Once risk metrics and triggering events have been chosen, there is nothing unique about risk control. Risk control melds into project management and relies on project management processes to control risk action plans, corrects for variations from plans, responds to triggering events, and improves risk management processes.

Communicate
Risk communication lies at the center of the model to emphasize both its pervasiveness and its criticality. Without effective communication, no risk management approach can be viable. While communication facilitates interaction among the elements of the model, there are higher level communications to consider as well. In order to be analyzed and managed correctly, risks must be communicated to and between the appropriate organizational levels. This includes levels within the development project and organization, within the customer organization, and most especially, across that threshold between the developer, the customer, and, where different, the user. Because communication is pervasive, our approach is to address it as integral to every risk management activity and not as something performed outside of, or as a supplement to, other activities.

For the identification action of the paradigm, SEI developed a risk identification tool, named as Risk Taxonomy for the industry. This Risk Taxonomy is also a construct for the methodology SRE in the SEI Risk Program.

SEI Risk Taxonomy

The Risk Taxonomy is a risk identification method providing the organization developing software with a systematic interview process to identify sources of risks. The procedure follows the life cycle of software development and provides a framework for organizing data and information [6], [7].

The taxonomy organizes software development risks into three levels: class, element and attribute (Figure 5). The questionnaire consists of questions under each taxonomic attribute that are designed to elicit the range of risks and concerns potentially affecting the software projects. The application of risk taxonomy process is defined such that the questionnaire can be used in a practical and efficient manner [6], [7].

Figure 5: Taxonomy Structure

The SEI Risk Taxonomy is organized into three major classes [7]:

Product engineering
The technical aspects of the work to be accomplished

Development environment
The methods, procedures, and tools used to produce the product

Program constraints
The contractual, organizational, and operational factors within which the software is developed, but which are generally outside of the direct control of the local management.

These taxonomic classes are further divided into elements and each element is characterized by its attributes. And each attributes have specific attribute related questions to form a general questionnaire. You can find the simple questionnaire sample of the SEI Risk Taxonomy at Appendix A.

Based on the Risk Management Paradigm and Risk Taxonomy, SEI developed a risk management methodology Software Risk Evaluation (SRE).

Software Risk Evaluation Method

The SRE practice is a formal method for identifying, analyzing, communicating, and mitigating software risks. It is used for evaluating and mitigating the technical risks associated with a software project. The SRE is conducted at major milestones early and periodically in the life cycle of project.

An SRE provides a project manager with a structured early warning mechanism for anticipating and addressing project risks [2]. It also introduces a set of activities that begins the process of managing risks.

The SRE is principle based. The principles of the SRE are primarily Open Communication, Forward-Looking View, Global Perspective, and Shared Product Vision. It uses proven group techniques such as the SEI Risk Taxonomy, the Interrelationship Digraph, and structured brainstorming and interviewing techniques. The SRE minimizes interruption to project work schedules and it produces diverse views of project risk.

Benefits of the SRE Benefits of the SRE include creating a shared view of risks facing a project among the staff, creating a common framework for talking about and mitigating risks, providing a snapshot of risks. SRE enables the tracking of risks and mitigation efforts systematically. It provides decision-making information to the project manager and accelerates the creation of a shared product vision among project staff. [2]

The SRE has five main phases; contracting, risk identification and analysis (RI&A), interim report, mitigation strategy planning (MSP), and final report (Figure 6).

Figure 6: SRE Phases

Contracting Phase consists of the activities needed to identify project goals, obtain agreements for the SRE, and coordinate resources for its conduct.

In Risk Identification & Analysis (RI&A) Phase, the SRE team visits the project’s development site and conducts structured interviews with staff members to elicit risk statements. The risk statements are analyzed, prioritized with regard to impact on the project, and grouped into risk areas. The SRE team then presents these findings to the involved project staff and manager.

In Interim Report Phase, the SRE team reanalyzes the risk areas and prepares a recommendation of those to be addressed in Mitigation Strategy Planning (MSP) for the project manager. This recommendation is agreed to by the project manager before proceeding with the MSP phase.

Mitigation Strategy Planning (MSP) Phase is focused on the construction of high-level mitigation plans for the selected subset of risk areas. Project staff, management, and the SRE team work together to create goals, strategies, and activities which will mitigate the concerns identified within the risk areas. In this phase, project staff will be equipped with the necessary information, plans, and sponsorship, can begin mitigating their most critical risks.

In Final Report Phase, the mitigation strategy plans are added to the information already compiled and the final report is assembled. The final report and the associated risk data are presented to the project manager.