Identify 

 

Content

1.      Objectives

2.      Identify Introduction

3.      Identify Overview

4.      Identify Diagram

5.      Risk information sheet

7.      Capturing a Statement of Risk

8.      Example 1 Risk Statements

9.      Example 2 Bad Risk Statements

10. Capturing the Context of a Risk

11. Example Context Statements

12. Case Study

13. Identify Summary

14. References

Objectives

  1. Identify Activities

  2. Capturing statements of risk

  3.  Capturing the context of a risk

  4. Case Study

 

Identify Introduction

In this module you will learn how to write risk and context statements in a standardized format using a risk information sheet. You will learn the difference between the risk statement and the risk context statement. Examples for both the risk statement and the risk context statement will be given and explained. You will read a hypothetical case study from which risk and context statements will be derived.

Identify Overview

Lets review and visualize Roger L Van Scoy’s paradigm [Van Scoy 92, p.9] and what he said. To refresh you memory, Van Scoy said:

“Risk identification is the first element in the risk management paradigm. Before risks can be managed, they must be identified. Risk identification aims to find the major risks before they adversely affect a program. We are developing techniques to discover risks by exploiting and communicating the risk knowledge of the program team.”

The paradigm illustrates a set of functions that are identified as continuous activities throughout the life cycle of a project. The Identify phase is highlighted in Figure Identify Risk Management Paradigm.

Figure Identify Risk Management Paradigm

Risk identification is the first element in the risk management paradigm. Before risks can be managed, they must be identified. Risk identification seeks to find the major risks before they adversely affect a program. The risk team uses techniques to discover risks by exploiting and communicating the risk knowledge to the program team. The risk team search for and locate risks before they become problems. Therefore, the purpose of identification is to consider risks before they become problems and to incorporate this information into the project management process and the Risk Management Plan. Anyone in a project can identify risks associated with the project. Each individual has particular knowledge about various parts of a project. During Identify, uncertainties and issues about the project are transformed into distinct (tangible) risks that can be described and measured. The risk are given an identification number (ID) and placed in a database.

During the first part of the paradigm, all risks are written with the same, two-part format. The first part is the risk statement, written as a single statement concisely specifying the cause of the concern as well as its impact. The second part may contain additional supporting details in the form of a context statement.

The intent of the risk statement is that it be clear, concise, and sufficiently informative that the risk is easily understood. The risk statements in standard format must contain two parts: the condition and the consequence. The condition-consequence format provides a complete picture of the risk, which is critical during mitigation planning. The risk statement is read as follows:

given the <condition>; there is a possibility that <consequence> will occur

Figure Risk Statement

The condition component focuses on what is currently causing concern; it must be something that is true or widely perceived to be true. This component provides information that is useful when determining how to mitigate a risk. Notice that the condition is followed by a semi-colon. The consequence component focuses on the intermediate and long-term impact of the risk. Understanding the depth and breadth of the impact is useful in determining how much time, resources, and effort should be allocated to the mitigation effort. A well-formed risk statement usually has only one condition, but may have more than one consequence. Risk statements should avoid:

Since the risk statement is to be concise, a context statement is added to provide enough additional information about the risk to ensure that other personnel can understand the original intent of the risk, particularly after time has passed. An effective context captures the what, when, where, how, and why of the risk by describing the circumstances, contributing factors, and related issues (background and additional information that are not in the risk statement).

A diagram of the complete risk and context statement are shown in Figure Risk and Context Statement there is one condition and two consequences in the risk statement. The context statement explains why this is a risk.

Figure Risk and Context Statement

Risk identification depends heavily on both open communication and a forward-looking view to encourage all personnel to bring forward new risks and to plan beyond their immediate problems. Although individual contributions play a role in risk management, teamwork improves the chances of identifying new risks by allowing personnel to combine their knowledge and understanding of the project.

Identify Diagram

The following Figure Identify Function shows three inputs and two outputs of the identify function.

 

Figure Identify Function

Inputs

1.      Individual Uncertainties: Individuals have uncertainties and issues about the project and project progress, which may or may not be risks.

2.      Group/Team Uncertainties: In group activities, individuals may together identify uncertainties and issues about the project and project progress, which may or may not be risks.

3.      Project data: The project data is supporting information that consists of items such as the schedule, budget, plans, and work breakdown structure, etc. that may provide information helpful in identifying risks (e.g. previously unknown dependencies between module development schedules).

Outputs

1.      Risk Information sheet: For each risk identified (unique ID), a statement of risk is captured along with the associated context for the risk.

2.      List of risks: The list contains all the statements of risks identified for the project. This should be in a configuration-controlled risk database.

Risk information sheet

The risk information sheet is used to record the risk information you or a team member is gathering during each paradigm function. There are 19 fields on this sheet. The shaded areas in “Figure Risk information sheet for identify” indicate the following fields that are completed during identification function of the paradigm.

Risk Information Sheet

 

The five fields of the Risk Information sheet are:

1.      ID: A unique identifier for the risk, numeric, or alphanumeric; assigned by project or organization or CM office

2.      Identified: date when the risk was identified

3.      Statement: statement of the risk

4.      Origin: Organization or person who identified the risk

5.      Context: Associated information that clarifies the risk

Capturing a Statement of Risk

Capturing a statement of risk involves considering and recording the conditions that are causing concern for a potential loss to the project, followed by a brief description of the potential consequences of these conditions. Therefore the objective is to arrive at a concise description of risk, which can be understood by everyone on the project and can be acted upon.

The following Figure Capture Statement of Risk shows the inputs and outputs for capturing a statement of risk.

Figure Capture Statement of Risk

The components and description of a statement of risk are:

Capturing the statement of risk involves considering and recording the condition that is causing concern for a potential loss to the project, followed by a brief description of the potential consequences of this condition.

During identification of risks it may be difficult to get a good description of the consequences. If all you can get is the condition, that’s okay. You’ll have a partial statement of risk and will need to describe the consequences at a later date in order to complete the statement of risk.

The condition-consequence format provides a more complete picture of the risk, which is critical during mitigation planning.

The condition component focuses on what is currently causing concern. This component provides information that is useful when determining how to mitigate a risk. The consequence component focuses on the intermediate and long-term impact of the risk. Understanding the depth and breath of the impact is useful information in determining how much time, resources, and effort (man hours) should be allocated to the mitigation tasks.

The following are good elements of a Risk Statement; therefore consider these questions when looking at a risk statement:

This is an example of one condition and more than one consequence.

We have multiple customers and an unclear procedure for identifying and resolving conflicts in customer requirement; we may get conflicts that go undetected until the design phase and that could delay implementation while we try resolving the requirement conflicts.

The goal of a risk statement is clear, concise, easily understood statements. The statement should contain sufficient information so that the risk is easily understood.

Risk statements should avoid:

Consequences should be added as soon as possible because, if all you have is the source or condition, you won’t know what you’re avoiding or preventing. Also, if all you have are the consequences, you won’t know what to mitigate.

Example 1 Risk Statements

Given that the graphical user interface (GUI) must be coded using JAVA and we do not have expertise in JAVA. Then there is concern that (possibly) the GUI code will not be completed on time and will be inefficient.

The Condition: Given that the graphical user interface (GUI) must be coded using JAVA and we do not have expertise in JAVA.

The Consequence: The GUI code will not be completed on time and will be inefficient.

Gluch [Gluch 94a] said that when writing the statement of the risk the words “given that” can be omitted, and the phrase, “then there is concern that (possibly),” can be replaced by a semicolon.

The Risk Statement: The graphical user interface (GUI) must be coded using JAVA and we do not have expertise in JAVA; the GUI code may not be completed on time and may be inefficient.

Example 2 Bad Risk Statements

Ask yourself if this is a good or bad risk statement.

This is an example of a bad risk statement because it does not tell you what the problem is with OOD or what might be the impact of using OOD.

A better statement might be:

This statement now tells you that the software engineers need training and time to train. Time to train means that you need a training schedule.This statement is better than the first. It is still not in the correct format with the condition and consequence.

A good risk statement includes both a clear condition and consequence:

Capturing the Context of a Risk

The risk statement provides a brief, concise description and consequence of the risk. Capturing the context of a risk involves recording the additional information regarding the circumstances, events and interrelationships within the project that may affect the risk. The context statement captures more details then the risk statement.

The objective is to provide enough additional content about the information in the risk statement to ensure that other team personnel can understand the intent of the risk in the future.

Figure Capturing the Contest of a Risk shows the inputs and outputs for capturing the context of a risk.

Figure Capturing the Context of a Risk

In most cases, context is being captured in parallel as a statement of risk is identified.

An effective context statement captures the what, when, where, how, and why of the risk by describing the circumstances described in the risk statement, contributing factors, related issues, and potential consequences of the risk. It is especially effective when it can be used later when time and current circumstances have changed the perceptions of the risk.

The structure of the context is informal text, which may consist of brief comments through one or more sentences of explanation. The textual comments may include information on personnel, technical, or management issues, communication, or other pertinent aspects of the project. While the original version of the context is generated as part of the identification, it is often modified and expanded as a normal part of the risk management process. This is done to reflect the most current risk information.

Example Context Statements:

The Risk statement is: Given that the graphical user interface (GUI) must be coded using JAVA and we do not have expertise in JAVA. Then there is concern that (possibly) the GUI code will not be completed on time and will be inefficient.

Example of the Context Statement: The graphical user interface is an important part of the system and we do not have anyone trained in the JAVA language. We all have been studying the JAVA language but is complex and only one person in the group has graphics experience and that is with C++ on the PC.

Consider these questions when righting the context statement:

1.      Can you identify which risk statement this context is associated with?

2.      Is it clear what the source or cause of the risk is?

3.      Is it clear what the impact might be?

4.      Would you know who to assign the risk to for mitigation? Would they know what to do?

5.      Would you be able to tell if the risk has gone away?

The context statement provides value-added information that supports or expands the risk statement. The team members should be able to identify which risk it is associated with additional conditions, source, and possible impacts that might be able to mitigate the risk.

This is an example of a context statement using the following risk statement:

This is the first time that the software staff will use OOD; the staff may have a lower-than-expected productivity rate and schedules may slip because of the associated learning curve.

The risk team member wrote the following risk context statement

It’s a typical AERO project - new concepts without training.

In your opinion is this good or bad context statement?

This is an example of a good risk statement with bad context. You should ask yourself or the person that wrote the risk statement the following questions:

1.      What does typical mean?

2.      Why is there no training?

3.      How much resources are needed

4.      What is the anticipated schedule slip?

As a risk evaluator you should realize that a good context statement explains what is going on so they can actually do something about this risk (mitigate the risk). But if all they ever saw was the risk statement, could they remember or trust new people to understand what the risk statement is really talking about? The risk statement and context statement must support each other. The risk statement should be able to stand-alone and context statement provides valuable insight.

Using the same risk statement this is a good context statement example.

Good context statement:

Object oriented development is a very different approach that requires special training. There will be a learning curve until the staff is up to speed. The time and resources must be built in for this or the schedule and budget will overrun.

In this context statement you can identify the risk statement associated with it. Another way is to apply a unique risk number or identifier to make sure these were linked. The best method is to establish a database with automatic linkage. From this context statement it is clear what the source or cause of the risk is. The context statement should also be clear as to what the impact of the risk might be. From the context statement it should be clear who should be assigned the risk for mitigation and that they know what to do with the risk.

Some information that is missing is that there is no clear procedure or responsibility for communicating with end users. Someone on the team needs to be identified and take care of notification. Also, the context statement should be able to tell if the risk has gone away.

Case Study

TBD

 

 

 

Identify Summary

It is important to capture for each risk:

References

[Gluch 94a]Gluch, David P.A. Construct for describing Software Development Risk (CMU/SEI-94-TR-14, ADA284922). Pittsburgh, PA.: Software Engineering Institute, Carnegie Mellon University, 1994.

[Carr]Carr, Marvin; Konda, Suresh; Monarch, Ira; Ulrich, Carol; & Walker, Clay. Taxonomy-Based Risk Identification (CMU/SEI-93-TR-6, ADA266992). Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 1993.

Software Engineering Institute, Carnegie Mellon University