Attach_0017_ARGSM_System_Risk_Management_Plan_31Jan2018.pdf

W31P4Q-19-X-XXXX

Attachment #0017 31 January 2018

ARSGM RISK MANAGEMENT PLAN

1. Purpose. This Risk Management Plan provides steps to Identify, Analyze, Plan, Track, Control, Communicate and mitigate risks within the Aviation Rockets and Small Guided

Munitions Product Office (ARSGM). Note: Department of Defense Instruction (DoDI)

5000.02, Operation of the Defense Acquisition System, requires program managers (PM) to implement effective risk management with the goal of mitigating risks and creating opportunities that could have a positive impact on meeting performance objectives as well as thresholds.

2. Scope. This Risk Management Plan applies to all personnel working on ARSGM programs in all phases of the life cycle. Each ARSGM Integrated Product Team (IPT) and Working Group

(WG) is required to address risks for any action planned or taken and track risks and risk mitigations.

3. Definitions. All ARSGM personnel are to be familiar with the terms below and accept responsibility for risk assessment (identifying, analyzing, and quantifying risks - see

Enclosure 2).

a. Risks are future events or conditions that may have a negative effect on achieving program objectives for cost, schedule, and performance. Risks mandate a mitigation plan.

b. Issues are events or conditions with negative effect that have occurred (such as realized risks) or are certain to occur (probability of 1) in the future that should be addressed.

c. Concerns are watch items or matter were a doubt exists in the ability to meet objectives. An analysis of concerns will identify those that actually become risks.

d. Opportunities are potential future benefits to the program’s cost, schedule, and/or performance baseline, usually achieved through proactive steps that include reallocation of resources.

4. Functions. Each ARSGM Product will have a risk manager. A risk manager for all of

ARSGM products will be appointed who will report risk related problems directly to the

ARSGM Product Director. A risk agenda item will be part of each Program Management

Review (PMR) or Technical Interface Meeting (TIM).

a. Risk Working Group

• The ARSGM risk working group consists of the IPT and WG leads.

• Meets once a quarter one month prior to a PMR or a TIM.

• Reviews the risks owned by the IPTs.

• Assesses and recommends whether risks should be elevated to the ARSGM risk manager or Product Director.

• Determines whether mitigation plans are adequate.

• Approves and tracks the status of IPT-level or WG-level risk mitigation plans.

• Approves risk closure for IPT-level risks and notifies the risk Manager or

Product Director of closure.

31 January 2018

b. Risk Manager (RM)

• Manages the risk process and tools for effective use by teams.

• Serves as advisor at IPT and WG program risk meetings.

• Maintains the ARSGM Risk Management Plan and risk register.

• Facilitates risk identification and analysis evaluations.

• Completes an initial screening of risks.

• Prepares risk briefings, reports, and documents required for program reviews.

• Utilizes a 5 x 5 risk cube with red, yellow and green to show likelihood and consequences of risks.

• Ensures that SOWs and contracts for ARSGM products include a contractor Risk

Management Plan IAW the DoD Risk, Issue, and Opportunity Management Guide

c. Independent Product Teams (IPTs), Working Groups (WGs) and ARSGM personnel

• Develop and implement the risk planning outlined in this Risk Management

Plan

• Identify internal and external risks in accordance with the procedures documented in the program’s contractually approved Risk Management Plan.

• Recommend to the Risk Manager and Product Director which risks should be tracked as program-level or special interest risks.

• Identify risks that impact multiple IPTs or WGs, coordinate risk management efforts with affected IPTs and WGs, and recommend to the RM which IPT should take the lead in managing the risk.

• Continually conduct risk analysis to ensure sufficient, relevant, and timely information is provided to decision makers.

• Recommend risk mitigation options, estimate funding requirements, support implementation of the selected mitigation plan, and track progress of efforts.

• Prepare Risk Burn-Down schedules for risk briefings and reports.

• Monitor risk burn-down effectiveness and report program-level risk status to the

PD and RM using the reporting requirements documented in the program’s approved Risk Management Plan.

• Assist the PD, as required, in reporting risk status to senior management personnel (PM/PEO/MDA) and other stakeholder personnel.

• Periodically revisit previously identified risks to verify the risk analysis results are still accurate as the program progresses or changes over time.

• Support engineering trade-off analyses to ensure risk elements are considered during performance, cost, and schedule trade space excursions.

• Review High and Serious Safety Hazards that may require a redesign to mitigate the hazard to an acceptable level.

• Monitoring in-service usage, problem reports, parts availability/obsolescence, engineering modifications, technology insertions, and operational hazard risks.

The Service support organizations often work with the program offices

6. References.

a. Department of Defense Risk, Issue, and Opportunity Management Guide for Defense

Acquisition Programs dated June 2015

7. General. See Enclosures

ENCLOSURE 1: GLOSSARY

Issue An issue is a risk that has realized (happened) – requires management action to minimize impact on the program.

Risk Risk is a measure of future uncertainties in achieving the program goals and objectives commensurate with cost, schedule, and performance objectives. Risks mandate a mitigation plan to reduce the likelihood of occurrence if they are yellow or red.

Watch List A watch list is any matter about which a doubt exists in ability to meet objectives. An analysis of concerns will identify those that actually become risks.

Risk Register A Risk Register is a Risk Management tool used by program personnel that provides a means of recording the identified risks, the risk analysis and the necessary management actions to be taken. It can be a simple document, spreadsheet or computer database system and acts as a central repository for all risks identified by the project.

Consequence The outcome of a future occurrence expressed qualitatively or quantitatively, being a loss, injury, disadvantage or gain. However, the consequence varies with each risk in terms of cost, schedule and impact on health, human life, or some other critical factor. The consequence has to be weighted in terms of the probability of it occurring.

Probability A risk is an event that "may" occur. The probability of it occurring can range anywhere from just above 0 percent to just below 100 percent.

(Note: It can't be exactly 100 percent, because then it would be a certainty, not a risk. And it can't be exactly 0 percent, or it wouldn't be a risk.)

Risk Mitigation The process of dealing with risks in order to reduce the severity of risk to an acceptable level.

http://www.acqnotes.com/Tasks/Risk%20Identification.html http://www.acqnotes.com/Tasks/Risk%20Analysis.html

31 January 2018

ENCLOSURE 2: CONSEQUENCE AND LIKLIHOOD CRITERIA

Consequence Criteria

Level Cost Schedule Performance

5 Critical Impact

10% or greater increase over objective values

Cost increase causes program to exceed affordability caps

Schedule slip will require a major schedule re-baselining

Precludes program from meeting its APB schedule threshold dates

Degradation precludes system from meeting a KPP or key technical/supportability threshold;

will jeopardize program success

Precludes program from meeting its schedule threshold dates

4 Significant Impact

5% - <10% increase over objective values

Costs exceed life cycle ownership cost KSA

Schedule deviations will slip program to within 2 months of approved threshold schedule date.

Schedule slip puts funding at risk

Fielding of capability to operational units delayed by more than 6 months

Degradation impairs ability to meet a KSA. Technical design or supportability margin exhausted in key areas.

Significant performance impact affecting system-of-system interdependencies. Work arounds required to meet mission objectives.

3 Moderate Impact

1% - <5% increase over objective values

Manageable with PEO or Service assistance

Can meet objective schedule dates, but other non-key events may slip.

Schedule slip impacts synchronization with interdependent programs by greater than 2 months.

Unable to meet lower tier attributes, TPMs, or CTPs

Design or supportability margins reduced.

Minor performance impact affecting System-of-System interdependencies. Work arounds required to achieve mission tasks.

2 Minor Impact Costs that drive unit production cost increase of <1% over budget

Cost increase, but can be managed internally

Some schedule slip, but can meet objective dates and key event dates.

Reduced technical performance or supportability; can be tolerated with little impact on program objectives.

Design margins reduced, within trade space.

1 Minimal Impact

Minimal impact. Cost expected to meet approved funding levels.

Minimal schedule impact. Minimal consequences to meeting technical performance or supportability requirements.

Design margins will be met;

margin to planned tripwires.

Likelihood Criteria

Level Likelihood Probability of Occurrence

5 Near Certainty >80% to < 99%

4 Highly Likely >60% to < 80%

3 Likely >40% to < 60%

2 Low Likelihood >20% to < 40%

1 Not Likely > 1% to < 20%

Note: These are recommended program management activities. The items listed under the

IPTs are risk mitigation activities that apply to all phases of a program. Maybe there is something here that could be added to the IPT list but otherwise I would delete the high-lighted areas.

Suggested Activities in the EMD Phase to Reduce Risk Additional risk management activities to reduce risk exposure in this phase include the following:

• Continue knowledge point reviews, CSB meetings, and assessment of framing assumptions as in the TMRR phase. When not making a change to KPPs could jeopardize a program’s utility or affordability, coordinate with the Joint Requirements Oversight Council.

• Update requirements trace and risk assessment for the draft Capability Production Document

(CPD).

• Conduct early risk-focused developmental testing with adequate time for necessary regression tests.

• Work with the operational test and evaluation community for early participation, requirements trace, and assessment.

• Require contractor testing with predefined success criteria to facilitate resolving integration activities and failure modes before the start of government testing.

• Establish and manage size, weight, power, and cooling (SWAP-C) performance and R&M allocations for all subsystems.

• Align logistics analysis, training, and support systems with system development.

• Plan technology refresh cycles to be implemented in the P&D and O&S phases to address technology obsolescence risks.

Production and Deployment Phase The purpose of the P&D phase is to produce and deliver requirements-compliant products to receiving military organizations. The design must be stable enough to commit to production prior to entering this phase.

Following Milestone C, the program continues to mitigate risks to successful completion of

Initial Operational Test and Evaluation (IOT&E) and the Physical Configuration Audit (PCA).

The PCA verifies and validates that the product built is compliant with the design and meets the

CPD. It also identifies technical risks for fielding and sustainment.

Suggested Activities in the P&D Phase to Reduce Risk Additional activities to reduce risk exposure in the P&D phase include the following:

• Conduct a thorough PCA to verify production does not introduce new risks.

31 January 2018

• Address risk associated with new requirements, follow-on increments, or deferred activities.

• Work with the Defense Contract Management Agency (DCMA) to assess production schedule risks. Identify and assess delivery schedule dependencies with external programs/users.

• Identify sustaining engineering needs and fund as appropriate.

Operations and Support Phase In the Operations and Support (O&S) phase, the risk activities include monitoring in-service usage, problem reports, parts availability/obsolescence, engineering modifications, technology insertions, and operational hazard risks. The Service support organizations often work with the program offices. During this phase, programs should plan for and establish In-Service Reviews

(ISR). The ISR is a multi-disciplined assessment to characterize the in-service health of the deployed system and the enabling system elements (training, user manuals, documentation, etc.).

Risk management activities in the course of the ISR include risk assessment of operational hazards, product baseline integrity, supply chain status, determination of acceptable operational hazard risk, and in-service usage/support risk.