The recently released Department of Defense Risk, Issue, and Opportunity Management (DoD RIO) Guide for Defense Acquisition Programs discusses the importance of communicating risks through the use of structured risk statements. It describes how well-structured risk statements help all stakeholders better understand the program risks and enhance system engineering planning and communications. This article expands on that discussion and shares some of our more frequent recommendations for programs to improve risk statements.
A risk statement summarizes a potential problem that needs to be addressed. The statement communicates the potential adverse event or condition and its consequences on program objectives should the risk be realized. The statement informs other members of the extended program team, program leadership and stakeholders to make them aware and possibly help them make decisions in consideration of the risk.
A clear risk statement ensures that people across organizational boundaries or geographically distributed groups, such as in a system of systems, possess a common understanding of the problem. Poorly written risk statements do not achieve these goals and can be counterproductive. This article further discusses the elements of a good risk statement, various acceptable formats, and examples of weak risk statements, showing how they can be improved.
Elements of a Good Risk Statement
The recently published DoD RIO Guide indicates a good risk statement will include two or, potentially, three elements: the potential event or condition, the consequences and, if known, the cause of the event.
The potential event is a future possible happening that could have an impact on the program objectives. In short, the uncertain event describes something that can go wrong. It might be associated with design or development, technology failure, supplier problem, or any other item that might cause an undesirable condition that will impact program objectives.
If either the root cause or the proximate cause is known, it is helpful to describe it in the risk statement. Including the cause helps clarify what is driving the risk and later will help the program develop a mitigation plan. The mitigation aimed at reducing likelihood may address the proximate cause rather than the root cause. For example, the batteries Program X uses are not reliable and keep failing, so the program manager (PM) elects to switch to a different supplier. In this case, the proximate cause is that batteries keep failing reliability and the solution is to replace them with different batteries. Theoretically, the root cause might have been a bad production process, sloppy quality control, bad specifications, or bad design, etc., or a combination of these causes. These are important factors to investigate if you are the battery manufacturer or a battery PM, but the Program X PM does not address them because the solution to “proximate” cause (bad battery) is to buy from a different source.
Finally, the consequences are the impact the event or condition will have on a program, usually expressed in terms of cost, schedule, or performance. This part of the statement describes the outcome for the program if the risk event or condition is realized.
Risk Statement Format
There are several generally accepted ways to write a risk statement. While the DoD RIO Guide highlights the “if-then” construct, there are other equally acceptable methods of defining the key elements of potential event or condition, consequences, and cause (if known). The guide suggests a program adopt one approach and instill a disciplined practice of using that approach. Here are a few approaches to consider:
The following are examples of poorly formed risk statements with a rationale for why they are inadequate.
An important element of risk management is a clear articulation of the risks. The key requirement for a good risk statement is that it clearly identifies the event or condition, the consequences on program objectives, and cause (if known). Disciplined use of structured formats can help in describing a risk, produce more effective risk statements, and avoid weak statements that lead to confusion. Risks should be monitored and statements updated (a living document/plan) as the program progresses and gains knowledge. The DoD RIO Guide provides additional information on risk and the nature of potential risk drivers as the program moves across life-cycle phases.
James Thompson is the director of Major Program Support in the Office of the Deputy Assistant Secretary of Defense for Systems Engineering (ODASD[SE]). He is the lead for independent technical risk assessments, providing support to major defense acquisition programs, and informing relevant technical authorities and communities regarding best practices for systems engineering. Stephen Stump is the Land Expeditionary Warfare Program Support Team lead in the ODASD(SE).
The authors may be contacted through firstname.lastname@example.org and email@example.com.