Acq Notes

The Program Manager (PM) is responsible for making sure everyone, who is required, on their team has the required risk knowledge to do their job. Training is an important part of this. Getting the program team organized and trained to follow a disciplined, repeatable process for conducting a risk assessment (identification and analysis) is critical […]

The Risk Assessment Matrix determines the level of risks identified within a program. The level of risk for each root cause is reported as low (green), moderate (yellow), or high (red). Definition: A risk assessment matrix is a matrix that is used by program personnel during a risk assessment to define the overall level of

A Risk Register is a Risk Management tool used by the Program Manager (PM) and program personnel that provides a means of recording the identified risks, the Risk Analysis of their severity, and the necessary management actions to be taken. It can be a simple document, spreadsheet, or computer database system and acts as a

A Risk Analysis may identify a number of risks that appear to be of similar ranking or severity. When too many risks are clustered at or about the same level, a method is needed to prioritize risk responses and where to apply limited resources. Such a method should be tied to mission/business needs and maximize

The objective of a well-managed risk management program is to provide a repeatable process for balancing cost, schedule, and performance goals within program funding.  This is especially true on programs with designs that approach or exceed the state-of-the-art or have tightly constrained or optimistic cost, schedule, and performance goals. Without effective risk management, the Program

The Risk Mitigation Plan should be realistic, achievable, measurable, and documented and address the following topics: [1] A descriptive title for the identified risk; The date of the plan; The point of contact responsible for controlling the identified root cause; A short description of the risk (including a summary of the performance, schedule, and resource

  The Risk Management Board (RMB) is responsible for overseeing the Risk Management Process in an organization. They report to the Program Manager (PM) and key Stakeholders. The RMB is comprised of risk professionals, subject matter experts, and stakeholders. They usually examine the work of the Risk Integrated Product Team and evaluate, prioritize and report

Risk is a measure of future uncertainties in achieving program performance goals, requirements, and objectives within defined cost, schedule, and performance constraints. Risk can be associated with all aspects of a program (e.g., threat, System Safety, technology maturity, supplier capability, design maturation, performance against plan) as these aspects relate across the Work Breakdown Structure (WBS),

The Risk Integrated Product Team (IPT) is a working-level IPT in charge of managing and implementing the Risk Management Process for a program. The team should include stakeholders, system engineers, risk professionals, Subject Matter Experts (SME), and anyone else who could help in the risk process. The Risk IPT should report to the Program Manager

Risk Identification is an ongoing and continuous activity that takes place during the Risk Management Process and throughout the life-cycle of a project. Each step in the Risk Management Process should include some level of risk identification. Project activities such as programmatic and technical meetings, risk analysis, risk planning, telecons, reviews bring to light new

Risk Handling (now called Risk Mitigation) is the process that identifies, evaluates, selects, and implements options in order to set risk at acceptable levels given program constraints and objectives. This includes the specifics on what should be done, when it should be accomplished, who is responsible, and associated cost and schedule. The most appropriate strategy

  Risk is a measure of future uncertainties in achieving program performance goals and objectives within defined cost, schedule, and performance constraints.   Risk can be associated with all aspects of a program (e.g., threat, technology maturity, supplier capability, design maturation, performance against plan,) as these aspects relate across the Work Breakdown Structure (WBS) and

A Risk has three (3) components: A future root cause (yet to happen), which, if eliminated or corrected, would prevent a potential consequence from occurring, A probability (or likelihood) assessed at the present time of that future root cause occurring, and The consequence (or effect) of that future occurrence. Consequence (effect) The outcome of a

  The following is a collection of Risk Checklists that address key reviews in the acquisition process. Alternative Systems Review (ASR) Operational Test Readiness Review (OTRR) Physical Configuration Audit (PCA) Production Readiness Review (PRR) System Requirements Review (SRR) System Verification Review (SVR) Technology Readiness Review (TRR) Updated: 6/19/2018

Programmatic Environmental, Safety, and Occupational Evaluation (PESHE) is an overall evaluation of a program’s Environmental, Safety, and Occupational Health (ESOH) risks and is required for all programs.  The PESHE is part of a program’s Risk Management/Reduction program with the goal to eliminate ESOH hazards, where possible, and manage their associated risks where hazards cannot be

Military Standard (MIL-STD) 882E “Department of Defense Standard Practice System Safety” identifies the DoD approach for identifying hazards and assessing and mitigating associated risks encountered in developing, testing, production, using, and disposing defense systems. The procedure described herein conforms to DoD Instruction (DoDI) 5000.02 “Operation of the Defense Acquisition System.” DoDI 5000.02 defines the risk acceptance

The Joint Services Weapon Safety Review (JSWSR) Process is used by two or more DoD Components in developing a joint program. It’s a collaborative process and is conducted in conjunction with, not in addition to, the existing Service-specific weapon safety review processes. A JSWSRs will be conducted: For weapons designated as joint Service weapons, including

International Organization for Standardization (ISO) 31000 is a family of standards relating to risk management. The purpose of ISO 31000:2009 provides a framework and a process for the management of risk that are applicable to any type of organization in public or private sector. ISO 31000 seeks to provide a universally recognized standard for Program

A Hazard Tracking System (HTS) is a tool used by a Program Management Office (PMO), Program Managers (PM), Systems Engineers, and Safety Manager to track safety hazards. The purpose of a HTS is to effectively manage hazard analysis data and facilitate a hazard discovery and hazard risk mitigation process. The objectives of a HTS include:

A Fault Tree Analysis (FTA) is a Risk Management tool that assesses the safety-critical functions within a system’s architecture and design. It analyzes high-level failures and identifies all lower-level (sub-system) failures that cause them. FTA is useful during the initial product design phase as a tool for driving the design through an evaluation of both

Failure Modes and Effects Analysis (FMEA) an analytical tool that is used in Risk Management to identify various ways in which systems element can fail and what’s their overall impact (consequence) to other elements and/or the overall system.  The results are processed thru Failure Modes Effects and Criticality Analysis (FMECA) in which each potential failure

Enterprise Risk Management (ERM) is a risk process used to identify, assess, manage, and control risks to exploit opportunities they might provide within an organization. It provides an overall framework for an organization’s risk management program by establishing objectives. Definition: Enterprise Risk Management is a process, effected by an entity’s board of directors, management and

An effective Risk Management Process requires a commitment on the part of the Program Manager (PM), the Program Management Office (PMO), and the contractor to be successful. A government risk management program should have a goal to share program risks with the development, production, or support contractor and not transfer all risks to a contractor.

Element 8 “Manage Life-Cycle Risk”. After the system is fielded, the system program office uses the system safety process to identify hazards and maintain the Hazard Tracking System (HTS) throughout the system’s life-cycle. This life-cycle effort considers any changes to include, but not limited to, the interfaces, users, hardware and software, mishap data, mission(s) or

Element 7 “Accept risk and document”. Before exposing people, equipment, or the environment to known system-related hazards, the risks shall be accepted by the appropriate authority as defined in DoD Instruction 5000.02 “Operation of the Defense Acquisition System”. The system configuration and associated documentation that supports the formal risk acceptance decision shall be provided to