Risk Management - Procedures/Writing Risk Statements

For additional information on risk management best practices and lessons learned, please see the Risk Management topic and articles in the online MITRE Systems Engineering Guide.

"IF - THEN" Risk Statement

Example:

Requirement reads: "Use Common Operational Picture (COP) in DII COE Release 1.5"
Identified risk: availability of DII COE version 1.5 when needed

Risk statement:

IF DII COE version 1.5 is more than 1 month late,
THEN Program xyz release 1 will experience a day for day schedule slip

Condition Present and Associated Risk Event Risk Statement

Writing the Risk Statement: Identified risks are described and communicated to management in the form of risk statements. A risk statement provides the clarity and descriptive information required for a reasoned and defensible assessment of the risk's occurrence probability and areas of impact. A well-written risk statement contains two components. They are a statement of the Condition Present and the Associated Risk Event (or events).

Example 1: Risk Statement

"A large part of the software must now be written in C++; the time required to train the development team in C++ will extend the project's schedule by 3 months".
Here, the Condition Present is {A large part of the software must now be written in C++}; the Associated Risk Event is {the time required to train the development team in this language will extend the project's schedule by 3 months}.

In a risk statement, the Condition Present is itself an event; it is an event that has occurred or is presently occurring. Associated Risk Events are future events that might occur because of the Condition Present.

The Condition Present acts as the departure point from which one or more Associated Risk Events may originate. Example 2 illustrates how three risk events A1, A2, and A3 originate from a single condition.

Example 2: Condition Present

{Version 1.0 (v1.0) of the enterprise system architecture is not yet defined; furthermore, the schedule required to deliver the architecture is highly compressed and not synchronized to the major funding and review milestones of the systems being upgraded to comply to this architecture.}

Risk Events:
A1 = {Milestone funding and review schedules for each system being upgraded will slip by more than 3 months due to the time required for them to properly apply and demonstrate compliance to the v1.0 architecture.}
A2 = {Once v1.0 is delivered, the current designs of the systems being upgraded may be inadequate to support the interoperability requirements of users.}
A3 = {The systems being upgraded may design functionality that is significantly less in scope than v1.0 will require.}