Once risk has been identified and assessed, the next step requires Risk Analysis and Mitigation. As part of this step, the risk owner develops specific tasks that, when implemented, will reduce the stated risk to an acceptable level. This does not necessarily mean reducing the risk to low. Some programs consider "no risk" as "no progress" and encourage proactive pursuit of cutting edge technologies. This may require accepting some level of risk if the result leads to future gains in terms of performance, schedule and/or cost.
The risk analysis process requires localizing the source or cause of the
identified risk, being careful not to confuse symptoms with cause. It is the
source/cause which will receive the necessary resources to mitigate risk to an
acceptable level. Once this has been accomplished, Mitigation Plans must be
developed that describe what has to be done, when, by whom, the level of
effort, and the material or facilities required to mitigate risk to an
acceptable level. A proposed schedule for accomplishing these actions is
required as well as a cost estimate if possible. All assumptions used in the
development of the Mitigation Plan must be listed. Recommended mitigation
actions that require resources outside the scope of a contract, Ship Project
Directive, Work Request, or other official tasking should be clearly
identified. The risk form used by the program should also include a list of
the IPT(s), which the risk area or the Mitigation Plan may impact. When
completed and approved by the cognizant individual, the risk form is
recorded/entered into the database.
Figure 1-1, Chapter 1,
lists some ideas for developing risk Mitigation Plans that are
self-explanatory. Two items listed in the ToolBox also contain a couple of
sources that may benefit Mitigation Plan development. These include, but are
not limited to the "DoD 4245.7-M Templates" and "NAVSO P-6071 Best Practices"
manuals. These documents are often useful in developing Mitigation Plans for
Design, Test, and Manufacturing risk areas. The idea "Renegotiate
Requirements" should normally be recommended as a last resort.
Another consideration is the identification of interrelationships between
identified critical risks and risk mitigation plans. For example, in
developing risk Mitigation Plans, a common Mitigation Plan could be used to
mitigate several areas of risk (e.g., improved convection cooling techniques
could reduce system complexity by eliminating the need for forced air cooling
and improving part design margins by reducing worst case operating
temperatures). Conversely, plans developed for mitigating risks in one area
could have an adverse effect on other risks (e.g., the addition of heat sinks
to improve convection cooling could adversely increase system weight and
increase maintenance times). This type of analysis is encouraged to ensure
that a Mitigation Plan for one area of risk does not have a counter-productive
effect on one or more other risk areas.
Do not expect to avoid risk completely; every program, be it an ACAT I or
ACAT IV, will have risks. Once risks have been reported and assessed, a
mitigation strategy for every moderate and high risk should be established.
Risk resolution and workarounds can be kept off the critical path by early
identification and resolution. The program office has, as a minimum, three
risk mitigation strategies available: risk reduction/prevention, risk transfer
(sharing) and risk acceptance.
- Risk Reduction/Prevention: Mitigation
actions should clearly identify the root cause of the risk, how the root
cause will be eliminated/reduced, and who (individuals or teams) are
responsible for carrying out these actions. Progress against mitigation
actions must be tracked at appropriate intervals. While this is often done
at milestone reviews and other major program decision points, it is in the
best interest of the program to review these efforts continuously. One way
to accomplish this is through the use of Event Driven Risk Mitigation Plans
(discussed under "Reporting the Risk"), in which risk mitigation activities
are integrated with the overall program schedule and resources.
- Risk Transfer (or Sharing): In some cases,
risk consequence must be shared with another party, such as the contractor
or a participating program office. Risk can also be transferred or
reallocated to different WBS elements or subsystems. In this instance,
reallocation is appropriate only if the element to which it is reallocated
is better suited to mitigate the risk. Risk transfer may be appropriate when
the consequence of risk is high but the likelihood of occurrence is low.
Transfer techniques, for example, can include warranties or insurance
- Risk Acceptance: As stated previously, every
program has risk. Generally, the more the program pushes state-of-the-art
technology, and the greater the performance and operational requirements,
the greater the risks. In many cases, the program manager must be willing to
accept some of these inherent risks, as reduced risk would come at the
expense of a degraded mission and performance, and adversely impact budget
and schedule constraints. The key in accepting these risks is that the
program manager must ensure that these risks are identified and understood
early so that they do not become problems later and adversely impact the