||DSMC RMG 4th: Risk Management Guide 4th
2.4.2 Program Products, Processes, Risk Areas, and Risk
Program risk includes all risk events and their
relationships to each other. It is a top-level assessment of impact to the
program when all risk events at the lower levels of the program are
considered. Program risk may be a roll-up of all low-level events; however,
most likely, it is a subjective evaluation of the known risks by the PMO,
based on the judgment and experience of experts. Any roll-up of program risks
must be carefully done to prevent key risk issues from "slipping through the
cracks." Identifying program risk is essential because it forces the PMO to
consider relationships among all risks and may identify potential areas of
concern that would have otherwise been overlooked.
One of the greatest strengths of a formal, continuous risk management
process is the proactive quest to identify risk events for handling and the
reduction of uncertainty that results from handling actions.
A program office has continuous demands on its time and resources. It is,
at best, difficult, and probably impossible, to assess every potential area
and process. To manage risk, the PMOs should focus on the critical areas that
could affect the outcome of their programs. Work Breakdown Structure (WBS)
product and process elements and industrial engineering and manufacturing
processes contain most of the significant risk events. Risk events are
determined by examining each WBS element and process in terms of sources or
areas of risk. Broadly speaking, these sources generally can be grouped as
cost, schedule, and performance, with the latter including technical risk.
Following are some typical risk areas:
- Threat. The sensitivity of the
program to uncertainty in the threat description, the degree to which the
system design would have to change if the threat's parameters change, or the
vulnerability of the program to foreign intelligence collection efforts
(sensitivity to threat countermeasure).
- Requirements. The sensitivity of the program to
uncertainty in the system description and requirements except for those
caused by threat uncertainty.
- Design. The ability of the system
configuration to achieve the program's engineering objectives based on the
available technology, design tools, design maturity, etc.
- Test and Evaluation (T&E). The
adequacy and capability of the T&E program to assess attainment of
significant performance specifications and determine whether the systems are
operationally effective and suitable.
- Modeling and Simulation (M&S).
The adequacy and capability of M&S to support all phases of a program
using verified, valid, and accredited M&S tools.
- Technology. The degree to which
the technology proposed for the program has been demonstrated as capable of
meeting all of the program's objectives.
- Logistics. The ability of the
system configuration to achieve the program's logistics objectives based on
the system design, maintenance concept, support system design, and
availability of support resources.
- Production. The ability of the
system configuration to achieve the program's production objectives based on
the system design, manufacturing processes chosen, and availability of
manufacturing resources such as facilities and personnel.
- Concurrency. The sensitivity of
the program to uncertainty resulting from the combining or overlapping of
life-cycle phases or activities.
- Capability of Developer. The
ability of the developer to design, develop, and manufacture the system. The
contractor should have the experience, resources, and knowledge to produce
- Cost/Funding. The ability of the
system to achieve the program's life-cycle cost objectives. This includes
the effects of budget and affordability decisions and the effects of
inherent errors in the cost estimating technique(s) used (given that the
technical requirements were properly defined).
- Management. The degree in which
program plans and strategies exist and are realistic and consistent. The
Government's acquisition team should be qualified and sufficiently staffed
to manage the program.
- Schedule. The adequacy of the time
allocated for performing the defined tasks, e.g., developmental, production,
etc. This factor includes the effects of programmatic schedule decisions,
the inherent errors in the schedule estimating technique used, and external
Critical risk processes are the developer's engineering and production processes which, historically, have caused the most difficulty during the development and/or production phases of acquisition programs. These processes include, but are not limited to, design, test, production, facilities, logistics, and management. These processes are included in the critical risk areas and are addressed separately to emphasize that they focus on processes. DoD 4245.7-M, Transition from Development to Production, describes them using templates. See Figure 2-2 for an example of the
template for product development. The templates are the result of a Defense
Science Board task force, composed of Government and industry experts, who
identified engineering processes and control methods to minimize risk in both
Government and industry. The task force defined these critical events in terms
of the templates, which are briefly discussed later. Go to the following web
site to obtain a copy of DoD 4245.7-M: http://www.dtic.mil/whs/directives/corres/html/42457m.htm.
Additional areas, such as manpower, environmental impact, systems safety and health, and systems engineering, that are analyzed during program plan development provide indicators for additional risk. The PMO should consider these areas for early assessment since failure to do so could cause dire consequences/impacts in the program's latter phases.
In addition, PMs should address the uncertainty associated with security-an area sometimes overlooked by developers but addressed in the Acquisition System Protection (ASP) section of the Deskbook and Air Force Pamphlet ASPWG PH-1, Acquisition System Protection Program Work Book, September 1994. However, in addition to the guidance given there, PMs must
recognize that, in the past, classified programs have experienced difficulty
in access, facilities, clearances, and visitor control. Failure to manage
these aspects of a classified program could adversely affect cost and