The Risk Analysis Report focuses on identifying potential risks, analyzing their impact, and proposing mitigation strategies.
The Risk report is an interim artifact during the execution of the Concept Definition life cycle phase (Kossiakoff SE P&P Chapters 7, 12).
Below are guidelines and common mistakes to be aware of as you develop your Risk Analysis Report.
The Risk Analysis Report identifies potential risks that could impact the successful development and deployment of your system. The goal is to assess these risks, categorize them by their likelihood and consequence, and develop strategies to mitigate them effectively.
Ensure that risk descriptions are framed in the "if (root cause), then (consequence)" format. This approach helps clarify both the root cause of the risk and the potential consequences, leading to a better understanding of the risk's implications.
The consequence of each risk should directly relate to either mission accomplishment (e.g., failure to meet project goals) or loss of business/return on investment (ROI) for the development of the system.
Each mitigation step should clearly indicate which risk category is being addressed—either Likelihood (L) or Consequence (C)—and by how much the risk is expected to be reduced.
When developing your mitigation plans, include milestones along the time axis of your mitigation waterfalls. These milestones help track progress and ensure that the steps are implemented as planned.
Some mitigation steps, such as adding requirements to specifications, may not directly lower risk but set the groundwork for future risk-reducing actions. While these steps are important and should be included, ensure you differentiate between groundwork and actual risk reduction. True risk reduction occurs when requirements are translated into designs that effectively decrease the likelihood or impact of a risk.
Be cautious when relying on external entities (e.g., end users) to implement mitigation steps. Since you cannot control external actions directly, focus on what is within your control, such as updating maintenance, operation, or training materials to ensure that end users are properly trained to perform necessary operations.
Likelihood vs. Consequence: Mitigation steps should either reduce the likelihood of a risk occurring or lessen the impact (consequence) if the risk does occur. Because of this, a single mitigation step cannot reduce both Likelihood and Consequence simultaneously. Instead, specify whether a mitigation step is intended to prevent the risk (lowering Likelihood) or to reduce the impact if the risk materializes (lowering Consequence).
Unclear Risk Reductions: Failing to indicate which risk category (L/C) is lowered and by how much can lead to confusion and an ineffective risk management plan. Always specify the expected impact of each mitigation step.
Inconsistent Waterfalls: Ensure that the waterfalls in your risk mitigation plan include all necessary milestones along the time axis, providing a clear timeline for implementing each mitigation step.
Overestimating the Impact of Preliminary Steps: Planning, analyzing, or conducting tests are essential preliminary steps, but they do not reduce risk by themselves. Avoid showing that risk is reduced by these steps alone; instead, show how these steps lead to effective mitigation actions that reduce the actual risk.
Although this is a separate report, you should have been tracking all of your risks to date.
The risk report should include:
Definitions of likelihood and consequences levels (I have a standard set if you need this.)
A summary list of your risks, broken out into three categories:
Developmental—Programmatic (cost and schedule)
Developmental—Technical (technology focused, impacting performance)
Operational (risks encountered during operations) [These are rare in the course since they would not occur until after development.]
For EACH risk, you should have the following:
Title
Description
Assessment (likelihood and consequences, described and plotted on a risk cube)
Mitigation steps taken DURING THIS project course.
Overachievers: future mitigation steps that would be planned for beyond this course.
Assessment of the risk at the end of the project course. [Note: You are NOT expected to eliminate, or even reduce to green, all risks by the end of the course. It’s OK to have yellow (and even red) risks!]
For each risk, include a waterfall chart tracking the risk progression throughout the project, stopping at the end of the project
Risk Report Checklist Credit: Steve Biemer