||RMG 6th Edition: Risk Management Guide for DoD Acquisition
3.3. Identification of Root Causes
Identification of Root Causes
Program offices should examine their programs and identify root causes by
reducing program elements to a level of detail that permits an evaluator to
understand the significance of any risk and identify its causes. This is
a practical way of addressing the large and diverse number of risks that often
occur in acquisition programs. For example, a WBS level 4 or 5 element
may be made up of several root causes associated with a specification or
function, e.g., potential failure to meet turbine blade vibration requirements
for an engine turbine design.
Root causes are identified by examining each WBS product and process
element in terms of the sources or areas of risk. Root causes are those
potential events that evaluators (after examining scenarios, WBS, or
processes) determine would adversely affect the program at any time in its
An approach for identifying and compiling a list of root causes is to:
- List WBS product or process elements,
- Examine each in terms of risk sources or areas,
- Determine what could go wrong, and
- Ask “why” multiple times until the source(s) is discovered.
The risk identification activity should be applied early and continuously
in the acquisition process, essentially from the time performance and
readiness requirements are developed. The program office should develop
and employ a formalized risk identification procedure, and all personnel
should be responsible for using the procedure to identify risks.
Specific opportunities to identify risks (e.g., at event-driven technical
reviews) and explore root causes against objective measures (e.g., meeting the
entry criteria for an upcoming technical review, requirements stability,
technical maturity, software lines of code and reuse ratios, critical paths or
near critical paths) should not be overlooked. If technical reviews are
schedule, vice event driven, their usefulness as risk assessment tools can be
impacted, and the full benefits of risk assessment may not be achieved.
The early identification and assessment of critical risks allows for the
formulation of risk mitigation approaches and the streamlining of both the
program definition and the Request For Proposal (RFP) processes around those
critical product and process risks. Risk identification should be done
again following any major program change or restructure such as significant
schedule adjustment, requirements change, or scope change to the contract.
Typical risk sources include:
- 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
- Requirements. The sensitivity of the program to uncertainty
in the system description and requirements, excluding those caused by threat
uncertainty. Requirements include operational needs, attributes,
performance and readiness parameters (including KPPs), constraints,
technology, design processes, and WBS elements.
- Technical Baseline. The ability of the system configuration
to achieve the program's engineering objectives based on the available
technology, design tools, design maturity, etc. Program uncertainties
and the processes associated with the “ilities” (reliability,
supportability, maintainability, etc.) must be considered. The system
configuration is an agreed-to description (an approved and released document
or a set of documents) of the attributes of a product, at a point in time,
which serves as a basis for defining change.
- Test and Evaluation. The adequacy and capability of the
test and evaluation program to assess attainment of significant performance
specifications and determine whether the system is operationally effective,
operationally suitable, and interoperable.
- Modeling and Simulation (M&S). The adequacy and
capability of M&S to support all life-cycle phases of a program using
verified, validated, and accredited models and simulations.
- Technology. The degree to which the technology proposed for
the program has demonstrated sufficient maturity to be realistically capable
of meeting all of the program's objectives.
- Logistics. The ability of the system configuration and
associated documentation to achieve the program's logistics objectives based
on the system design, maintenance concept, support system design, and
availability of support data and resources.
- Production/Facilities. 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 (repair resources in the sustainment phase).
- Concurrency. The sensitivity of the program to uncertainty
resulting from the combining or overlapping of life-cycle phases or
- Industrial Capabilities. The abilities, experience,
resources, and knowledge of the contractors to design, develop, manufacture,
and support the system.
- Cost. The ability of the system to achieve the program's
life-cycle support 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 and taking into account known and unknown program
- Management. The degree to which program plans and
strategies exist and are realistic and consistent. The government’s
acquisition and support team should be qualified and sufficiently staffed to
manage the program.
- Schedule. The sufficiency of the time allocated for
performing the defined acquisition tasks. This factor includes the
effects of programmatic schedule decisions, the inherent errors in schedule
estimating, and external physical constraints.
- External Factors. The availability of government resources
external to the program office that are required to support the program such
as facilities, resources, personnel, government furnished equipment,
- Budget. The sensitivity of the program to budget variations
and reductions and the resultant program turbulence.
- Earned Value Management System. The adequacy of the
contractor’s EVM process and the realism of the integrated baseline for
managing the program.
Developers’ engineering and manufacturing processes that historically have
caused the most difficulty during the development phases of acquisition
programs are frequently termed critical risk processes. These processes
include, but are not limited to, design, test and evaluation, production,
facilities, logistics, and management. DoD 4245.7-M,
Transition from Development to Production, describes these
processes using templates. 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.
Additional areas, such as manpower, ESOH, and systems engineering, that are
analyzed during program plan development provide indicators for additional
risk. The program office should consider these areas for early
assessment, since failure to do so could cause significant consequences in the
program's latter phases.
In addition, PMs should address the uncertainty associated with security –
an area sometimes overlooked by developers but addressed under the topic of
acquisition system protection in the Defense Acquisition Guidebook
(DAG), as well as in DoDD
5200.1, DoD Information Security Program; DoDD
5200.39, Security, Intelligence, and Counterintelligence Support to
Acquisition Program Protection; and DoD
5200.1-M, Acquisition Systems Protection Program. 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 impact schedules. Not only are
classified programs at risk, but any program that encompasses Information
Assurance is burdened by ever increasing security requirements and
certifications. These risks must be identified as early as possible as
they affect design, development, test, and certification requirements that
will impose schedule challenges to the program.