RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

AFMC RISK MANAGEMENT PLAN TEMPLATE - READ ME FIRST

1. The 2017 DoD Risk, Issue and Opportunity [RIO] Management Guide uses the term “risk mitigation plan” to refer to the plans that are initially summarized in the Acquisition Strategy and updated as risks are identified and managed. The DoD 5000 Series and USAF policy refer to a Risk Management Plan (RMP), which is the term that shall be used in this template.

2. The AFIT/LS - Life Cycle Risk Management Group site offers information on risk and risk management concepts. The site provides several actual (redacted) program RMPs with embedded comments from AFIT SMEs to help program personnel write new RMPs. The site also provides information on AFIT/LS' two risk management courses, SYS 118 and SYS 208.

3. Additional risk management references (DoD → Joint → Air Force → Center):

• Defense Acquisition Guidebook (DAG) CH 3–4.1.5, Risk Management Process

• Defense Acquisition University (DAU) Program Manager's e-Tool Kit

• DAU / Acquisition Community Connection (ACC) - Risk Management Community

• DoDI 5000.02 , Operation of the Defense Acquisition System

• DoDI 5000.75 , Business Systems Requirements and Acquisition

• DoDI 5200.44 , Protection of Mission Critical Functions to Achieve Trusted Systems and Networks (TSN)

• DoDI 6055.01 , Safety and Occupational Health (SOH) Program

• DoD Operating and Support Cost Management Guidebook

• MIL-STD-882E , System Safety

• CJCSI 3170.01 , Joint Capabilities Integration and Development System (JCIDS); and The JCIDS Manual

• Joint Agency Cost Schedule Risk and Uncertainty Handbook (JA CSRUH)

• Air Force Acquisition App Store (AAS)

• AFI 63-101/20-101 and AFPAM 63-128, Integrated Life Cycle Management

• AFI 90-802 , Risk Management; and AFPAM 90-803, Risk Management Guidelines and Tools

• AFI 91-202 , The USAF Mishap Prevention Program

• AFI 99-103 , Capabilities-Based Test & Evaluation

• AFMAN 63-144 , Defense Business System Life Cycle Management

• AFPD 90-8 , Environment, Safety & Occupational Health Management and Risk Management

1

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

• AFLCMC Standard Process for Risk & Issue Management (RIM)

• Enterprise Risk Management Service (ERMS), AFLCMC/HIB (register at Acquisition App Store; request access to ERMS for a particular program)

• Probability/Consequence Screening (P/CS) Tool (contact AFLCMC/AZE)

• Risk Identification, Integration and Ilities (RI3) Tool (contact AFLCMC/EZSI)

2

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

Risk Management Plan

for

Program Name

Date

RMP Version Number for Life Cycle Phase(s)

Prepared byProgram Office

Approved: ____________________________

Name, Rank, Office Symbol

Title

DISTRIBUTION STATEMENT: Enter distribution letter and explanation. Reference Enclosure 4 of DoDI 5230.24, Distribution Statements on Technical Documents, and http://www.dtic.mil/dtic/submit/distribution_limitations_and_statements.html#distro_statements

3

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

1. PROGRAM SUMMARY.

Briefly describe the program, the acquisition strategy and the program management approach (i.e., how the government manages the program with different stakeholders).

This section should describe or reference the program/system top-level requirements, major activities being accomplished for the phase(s) of the life cycle that this RMP covers, and key program measurements/metrics. It should also briefly cover the existing program structure (i.e., integrated product teams (IPTs), technical reviews/assessments, program reviews/assessments, etc.). Example:

Figure 1-1: Program Reviews and Assessments (Example, Tailorable)

Note: DoDIs 5000.02 and 5000.75 state that top program risks and associated risk mitigation plans will be detailed in the applicable Acquisition Strategy (AS) document and presented at relevant decision points and milestones. AFI 63-101/20-101 states that the RMP can be incorporated into the AS or other appropriate planning document, and that the RMP should be linked to the risk management activities in other planning documents. If the RMP is part of another program document, then this RMP section simply needs to complement (not repeat) the program content of the host document.

2. RISK MANAGEMENT STRATEGY.

Provide an overview of the program's risk management (RM) strategy to implement continuous risk management, to include communication between the stakeholders mentioned in RMP section 1 and the training of the program/stakeholder team(s) in RM processes.

The RM strategy briefly describes the program's structured approach to identifying, assessing and managing risks. It should also give an overview of the program's processes for regularly updating and reviewing risk assessments based on new developments or actions taken. Example text:

In Program X, risk management is one of the key responsibilities of both the PM and the Chief Engineer (CE). The CE addresses technical risks and ensures RM training for personnel to ensure that effective risk assessment is built into their working practices. The training enables

4

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

them to carry out annual risk assessments using the program's risk templates and applications. The assessments are then collated by the program Risk Working Group to enable their assessment of the identified program risks. A prioritized profile of the top 25 risks is presented to the program Risk Management Board for their consideration, to ensure that they understand the risks to the program and approve the actions being taken. This process takes approximately 45 calendar days to complete. Progress is reviewed after 6 months, with a report sent to the PM, CE and other Risk Management Board members. All risks are reassessed annually. Ad hoc assessments and meetings may be called by the PM or CE in response to new developments that significantly affect (i.e., increase the likelihood/consequence of) any identified program risks.

The RM strategy should address both technical and non-technical risk areas to identify possible risk events that may cause cost, schedule and/or performance impacts, and should address any specific risk events that may have a critical impact on the program. An example risk area taxonomy with various risk elements is shown in Figure 2-1; example components of a RM strategy are shown in Table 2-1.

There are many AF, Joint and DoD policies that recommend or mandate some element/aspect of risk management planning as part of their requirements. For example AFI 90-802, AFI 99-103 and AFI 17-101 refer to the specific risk elements of "operational" (versus acquisition) risk management, T&E risk management and cybersecurity risk management; the JCIDS policies refer most to warfighter mission/capability risk management (which influences the program risk strategy); and the DoD 5000 series refer most to acquisition cost/schedule/performance risk management over the life cycle. The common use of "risk management," "risk plans" and "risk planning" terms in all of these policies can be confusing for many program offices, who may struggle to understand the differences in each policy's risk planning, management and documentation requirements.

Different risk elements may have different risk policies that apply just to them, with unique purposes, processes, stakeholders and applications. But all of these elements are part of the program's overall risk taxonomy such as the one shown in Figure 2-1, and as such each risk element can tailor and apply the risk processes described in section 6. Overall, the policy requirements described above are not duplicative-- they represent different risk management elements that often must run in parallel, each contributing unique inputs to different sets of stakeholders over the program/system life cycle. The risk taxonomy shows the reader what risk elements are important to this program, and the risk strategy describes how all elements contribute to the final cost, schedule and performance risk management decisions of the program.

5

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

Figure 2-1: Risk Area Taxonomy (Example, Tailorable)

Inputs Tactics, Techniques and Procedures (TTPs)

Outputs

Acquisition StrategyTechnical Strategy (see SEP)

Risk OrganizationsAssumptions & ConstraintsReq'ts (KPPs, KSAs, etc.)

Center/PEO ProcessesVendor/Contract Req'tsRisk Appetite/Tolerance

Intelligence ProductsAnalyses (CBA, AoA, etc.)

InterviewQuestionnaire

ChecklistSME/Peer Review(s)

M&S / MBSERisk Template

Risk Register / Database AppAssumption Analysis

Strengths, Weaknesses, Opportunities and Threats

(SWOT) Analysis

Risk Management PlanRisk Organization Charter(s)

Risk Governance ProcessRoles & Responsibilities

M&S / MBSE ResultsPopulated Risk Register/Data

Validated Assumption(s)SWOT Analysis Results

5x5 Risk Reporting MatrixDocumented Risk Decisions

Table 2-1: Components of a Risk Management Strategy (Example, Tailorable)

Note: The DoD RIO Management Guide states that, as part of the overall risk management strategy, programs may include aspects of opportunity and issue management planning, as appropriate. The USAF currently does not require opportunity management as part of risk management strategy; however, the current DASD(SE) Systems Engineering Plan (SEP) Outline (use required and tailorable IAW AFI 63-101/20-101) requires programs to discuss opportunity management plans in their SEP. And while the risk management strategy is predictive in nature,

6

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

it can also address program contingency planning for when negative events do occur (i.e., risks become issues)-- See Table 2-2 and section 6.

Loss of: How long can we do without?

Impact(s) of doing without? Vulnerabilities? Contingency in

case of disaster?

IT Equipment 3 DaysAfter 3 days cannot schedule production or track orders

No backup generatorSingle Point of Failure (SPoF) SME

Use legacy "paper system" for 3 days

Facility 0 Days No productionBuilding in FEMA Flood Zone APerimeter security

Use COOP to move to alt location; salvage & restart ops

Key Personnel 1 Day Degraded operations; low service levels Too many SPoFs

Train alternates; adjust shifts of available staff

Raw Materials 30 Days (before new deliveries)

None until "on hand" supply is exhausted

Single supplier for material XYZ

Search for alternate supplier

Shipping System 30 Days (in)2 Days (out)

No suppliesNo deliveries

Location; design of entrance/exit None

Utilities 0 Hours (power)0 Hours (water)

Production line shuts down, IT down

Single power feedNo backup supply None

Table 2-2: Contingency Planning (Example, Tailorable)

Contingency plans are special measures that are taken if a risk becomes an issue. However, these are not handling plans because unlike a risk handling plan a contingency plan is not implemented until after the negative event has occurred. In other words:

Risk handling = proactive planning, proactive implementation. Contingency planning = proactive planning, reactive implementation. Issue management = reactive planning, reactive implementation.

3. DEFINITIONS.

Provide terms and definitions specific to the program/system discussed in this RMP.

DoD and USAF policies allow PMs flexibility in constructing their risk management programs. However, definitions used by the program management office (PMO) should be consistent with DoD/USAF definitions such as those in the DoD 5000 series, the Defense Acquisition Guidebook (DAG), AFI 63-101/20-101 and AFPAM 63-128. For the specific cases of risk likelihood and consequence criteria, AFI 63-101/20-101 refers the PM to the definitions in AFI Attachment 3.

For the purposes of this RMP template, the terms risk, issue and opportunity are defined as follows:

Risk is a potential future event or condition that may have a negative effect on achieving program objectives for cost, schedule and performance. Risks are defined by (1) the likelihood (0 < probability < 1) of an undesired event or condition, and (2) the consequences, impact or severity of the undesired event if it occurs.

7

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

Issue is an event or condition with negative effect that has occurred (such as a realized risk), or is certain to occur (probability = 1), and should be addressed.

Opportunity is a potential future event with benefits to the program’s cost, schedule and/or performance baseline.

Note: Additional definitions can be found in the DoD Dictionary of Military and Associated Terms.

4. RISK WORKING GROUP(S) AND RISK MANAGEMENT BOARD(S).

Describe the formation, leadership, membership and purpose of the program risk team(s).

There is currently no statutory or regulatory requirement for an Air Force program to charter a team called a Risk Working Group (RWG) or Risk Management Board (RMB); but most PMOs recognize the need to develop working-level and management-level teams to perform needed risk management activities for the program. The "RWG" and "RMB" terms are recommended by the DoD RIO Management Guide and will be used for this template. See Figure 4-1 for an example risk team hierarchy.

For risk management teams, several options are available and are tailorable by the program, including but not limited to:

Conduct the risk analysis as part of the normal IPT activity of the program office;

Establish one or more dedicated risk analysis teams (temporary or permanent);

Establish a government-industry team, supported by contract(s); and

Request an outside (independent) team.

AFPAM 63-128 states that "Life Cycle Risk Management (LCRM) is not an exclusively technical activity. It is an integrated approach to managing all of the program's cost, schedule and performance risks. That is why within each program office, LCRM must be executed by cross-functional teams that could include cost analysts, contracting officers, acquisition intelligence analysts, sustainment planners, schedulers, sub-system managers, and other specialists in addition to engineering."

PMOs may create one or more RWGs led by a member of the Systems Engineering (SE) IPT or other PMO staff, with representatives from other IPTs as needed. The program should describe the roles and responsibilities of the RWG in a charter or equivalent document. An effective RWG is empowered to draw on expertise from inside the program and from identified sources outside the program to develop individual risk plans and recommendations for the RMB.

The PM establishes and typically chairs the government RMB as a senior group supporting program (cost/schedule/performance) risk management. The RMB usually includes representatives from the various functions in the program office such as program management, SE, logistics, T&E, RWG lead, contracting, warfighter/user representatives, and other SMEs depending on the agenda. As with the RWG, the RMB should have a charter; and RMB actions/decisions should be documented in meeting minutes or other approved methods. Ultimately the RWG/RMB charters and structures should define decision-making responsibilities and authorities for program risk management.

8

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

Both the government and contractor will generally be engaged in managing risks of mutual interest and responsibility. Programs should therefore consider integrating government-contractor RWGs and RMBs where practical. The contract type and terms may have a bearing on the decision-making authority, and therefore the contracting officer representatives may need to be engaged.

RWG and RMB charters can be referenced in the RMP or included as RMP attachments.

Figure 4-1: Risk Team Hierarchy (Example, Tailorable)

5. ROLES AND RESPONSIBILITIES.

The previous RMP sections describe the overall risk management strategy for the program and the teams/processes that will help execute that strategy. In this section, describe the specific roles, responsibilities and authorities within the program's RM processes for:

• Identifying, adding, modifying, and reporting risks;

• Providing resources to address risks;

• Developing criteria to determine whether a candidate risk is accepted;

• Changing likelihood and consequence of a risk; and

• Closing/retiring a risk.

This section assigns roles and responsibilities for specific tasks such as those above; and for specific risk areas where additional expertise is needed or unique responsibilities are assigned by law or policy. Some examples of unique risk areas addressed by DoD and Service policies include environment, safety and occupational health (ESOH) hazards, cybersecurity, and intelligence/counterintelligence threats.

9

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

This section can also reference and/or include the risk-related roles and responsibilities of the contractor members of the program team. The PMO and contractor(s) should clearly define their roles and responsibilities in the AS, SEP, Systems Engineering Management Plan (SEMP) and RMP. Contractor roles and responsibilities should include both primary and sub-contractors, and should consider how risk information and actions will be passed between the contractor teams and the program's U.S. Government teams.

6. RISK PROCESS.

Describe the program's methodology, meeting schedule and guidance for implementing the RMP according to the tailorable five-step RM process (Figure 6-1):

Figure 6-1: Life Cycle Risk Management (LCRM) Process

This section describes the how the program implements each of the five RM process steps, and describes any special areas to consider while implementing those steps. The guidance should be general enough to allow the program’s risk management team(s) flexibility in managing their parts of the program risk, yet specific enough to ensure a common and coordinated approach to the program's LRCM.

The section should also address how the information associated with each step of the program's RM process will be documented and made available to all participants in the process, and how risks will be tracked (to include the identification of specific metrics if appropriate).

The section should list the risk tools that the PMO and contractor(s) use to perform LCRM. Preferably the program office and contractor(s) should use the same tool(s) and data formats. If

10

Tracking

Handling /

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

they use different tools, the tools should be capable of exchanging needed data-- this section would then include a description of how (and when) the information would be transferred.

6.1. LCRM Step 1 - Risk Process Planning. Process planning consists of the program’s activities to develop, document and implement steps the program will take to mitigate individual risks. This subsection should describe or reference the program’s risk management expectations, risk management organization(s) (e.g., RWG, RMB), planning ground rules/assumptions, candidate risk areas/categories, use of risk management tools, and details on the training of program personnel. It should also mention how often the RMP will be reviewed and updated. Typically RMP updates are not always required but should at least be considered (1) whenever the acquisition or support strategy changes or there is a major change in program emphasis; (2) in preparation for major decision points; (3) concurrent with the review and update of other program plans if necessary; (4) from results and findings from event-based technical reviews; and (5) in preparation for a Program Objective Memorandum (POM) submission.

Note: The O&S phase of a weapon system (or the Capability Support phase of a Defense Business System (DBS)) may seem far away when the program is in its early life cycle phases; but it is in those early phases that critical decisions will be made that will establish operations/sustainment/support costs, schedules and capabilities-- see Figure 6-2 as an example. It is therefore imperative that programs plan RM activities to identify and reduce

operations/sustainment/support risks as early in the program life cycle as possible. The DoD Operating and Support Cost Management Guidebook (page 1 reference) can support this effort.

Figure 6-2: Early Decisions Drive Operations/Sustainment/Support Costs

11

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

6.2. LCRM Step 2 - Risk Identification. This subsection describes the process and procedures for examining the program's key/critical risk areas to identify and document the associated risks. The subsection should explain how the program will determine the chain(s) of cause and effect, contributing causes, and/or the root cause(s). This section should also explain how each identified risk will be assigned ownership and responsibility.

Note: Many RM policies and guides describe risk identification as a search for a simple "cause and effect" statement, i.e., a single cause leading to a single (bad) effect. In reality program risks often have more than one contributing cause, and may have more than one effect. Identifying all the contributing causes enables the program stakeholders to interfere with the chain of events that would lead to the risk becoming a real cost/schedule/performance issue. See Figure 6-3 for details. PMs should generally focus government and contractor efforts on risks which they can influence or control, and elevate significant risks for which they do not have control to the next decision level.

Figure 6-3: LCRM Step 2 - Risk Identification

6.3. LCRM Step 3 - Risk Analysis. Risk analysis answers the questions, "What are the likelihood and consequence of the risk?" and "How big is this risk compared to others?" During risk analysis, the program should:

12

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

Estimate the likelihood the risk event will occur, in the context of its dependencies, timeframes, etc.

Estimate the consequences in terms of cost, schedule and performance.

Prioritize the risk.

This subsection summarizes the analysis process for the program that lead to the determination of risks and their prioritization. It may include an overview and scope of the analysis process; sources of information; information to be reported and formats; description of how risk information is retained; and analysis techniques and tools (such as parametric analysis, Monte Carlo simulation, reliability calculations, Program Evaluation & Review Technique (PERT) analysis for schedules, etc.). Optimally the analysis would be based upon scientific calculations (e.g., fault tree analysis) or historical data, but it may have to rely upon expert judgment in many cases. See Figure 6-4 for details.

Figure 6-4: LCRM Step 3 - Risk Analysis

Typically only the most severe consequence from a cause or causes is placed on the risk reporting matrix for program reviews. Programs should use the standard Life Cycle Risk Management 5x5 reporting matrix, likelihood criteria and consequence criteria to report program

13

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

risk-- reference AFI 63-101/20-101 and AFPAM 63-128. Remember that the 5x5 matrix is a reporting tool, not an analysis tool.

Note: Programs should ensure that contractors/vendors use the same risk likelihood and consequence criteria that the government program uses (such as the criteria in AFI 63-101/20-101 Attachment 3). This helps to ensure a consistent and "apples to apples" comparison of reported risks throughout the risk management processes.

All moderate and high risks must be reported, and should use the standard 5x5 risk reporting matrix as a part of program, technical, and Milestone decision reviews. In addition, a collection of low risks that have a compounding effect equal to a single moderate or high risk should be presented on the reporting matrix IAW AFI 63-101/20-101 and AFPAM 63-128. Mission assurance and system safety risks identified using MIL-STD-882E will be translated and reported as described in AFI 63-101/20-101 Attachment 3. Program managers may develop additional consequence criteria if needed, but must describe these in the RMP. The risk analysis and reporting should also contain the results of the Failure Modes, Effects and Criticality Analysis (FMECA) per AFMCI 63-1201. If the likelihood or consequence cannot be reasonably assessed, it may be separately reported as a “concern.”

6.4. LCRM Step 4 - Risk Handling/Correction. This subsection explains in general how the program will take actions to address the identified risks, and describes risk measures, indicators and/or trigger levels which will be used to track the effectiveness of handling actions. See Figure 6-5 for details.

Note: Over the last few years DoD and AF policy offices have alternated use of the words "handling" and "mitigating" in their guidance. AFPAM 63-128 currently states that "risk handling is the preferred and more encompassing term to recognize that there are potentially multiple options to manage risks rather than simply mitigating the risk." This template follows the AFPAM guidance, listing "mitigate" as one of several risk handling options available to a program.

14

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

Figure 6-5: LRCM Step 4 - Risk Handling/Correction

Note: After identification and analysis of risks, programs often refer to ongoing "baseline" activities as risk handling activities, without the requisite changes to their planning, requirements or budget/resource allocations. This approach is typically insufficient. In most situations, relying on previously planned program activities results in a program’s de facto acceptance of the risk.

6.4.1. Risk Handling/Correction Options (Proactive Planning, Proactive Action). This answers the question, "What's the plan to address the risk?" or "Should the risk be accepted, transferred, monitored or mitigated?" Handling plans to address individual risks are developed separately from the RMP and are "tactical" in nature. The defined "strategic" processes in the RMP should generally explain how the program will select from the various risk handling/correction options when considering each individual risk, and should list assumptions used in that process. Example text:

An individual risk handling plan will include the specifics of what should be done; when it should be accomplished; who is responsible; the resulting cost, schedule, and performance impact(s); and the resources required to implement the individual risk mitigation plan. Recommended handling actions that require resources outside the scope of a contract or official tasking should be clearly identified; and the functional areas, risk categories and/or other risk handling plans that may be impacted should also be listed/referenced.

15

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

Figure 6-6 shows an example application of "default" program risk handling/correction options which can be tailored to individual risks.

Lik

elih

ood

5 Monitor Mitigate Mitigate Mitigate Avoid

4 Monitor Mitigate Mitigate Mitigate Mitigate

3 Accept Monitor Mitigate Mitigate Mitigate

2 Accept Accept Monitor Mitigate Mitigate

1 Accept Accept Monitor Monitor Transfer

1 2 3 4 5

Consequence

Figure 6-6: Program General Strategy for Risk Handling/Correction Options (Example)

The risk handling plan can include a risk burn-down plan, consisting of time-phased handling activities with specific success criteria. This detail allows the program to track progress in

reducing the risk to an acceptable level or to closure. Figure 6-7 shows an example risk burn-down chart.

Figure 6-7: Risk Burn-Down Chart

16

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

Note: Meetings are not part of a burn-down chart-- meetings do not burn down risk.

6.4.2. Contingency Planning (Proactive Planning, Reactive Action). Formal decisions to proceed (e.g., Milestone decisions, Acquisition Strategy Panels) constitute approval of a program’s current risk analysis and its handling/correction plans. But inherent with this step is developing contingency plans for if/when a key risk becomes an issue. Contingency plans typically require definition of a specific triggering event for implementation of a particular contingency plan. The level of detail for the triggering event and the contingency plan depends on the program life cycle phase and the nature of the risk to be addressed; however, there should be enough detail to allow an estimate of the effort required and technical scope needed based on system complexity.

6.4.3. Issue Management (Reactive Planning, Reactive Action). Issue management is complementary to the risk management process. Programs can take advantage of the common practices between issue and risk management (and the handling/correction options) while recognizing the distinctive characteristics of each. For some programs the ongoing baseline activities of the program office serve as the "issue management" function for the PMO; but others may wish to consider establishing an issue-specific team or having issue management operate as part of the RWG/RMB. However issues are addressed in the PMO, the key is to focus on both issues and risks so that attention on current problems (issues) will not overtake efforts to manage risks.

Programs should determine the urgency of an issue in order to prioritize its resolution, document a corrective action plan (sometimes referred to as a Plan of Action and Milestones (POA&M)), and include an Estimate at Completion (EAC) in the IMS. The program should update identified issues periodically and review them during regularly scheduled program meetings, program reviews and/or technical reviews until the issues are resolved. The program leadership (RMB or equivalent) should assign an owner for each approved issue. Programs may consider combining the risk and issue databases/registers into a single source for ease of management.

Issues should be analyzed using the program’s risk management consequence criteria, and the results entered into the issue database/register. Unlike opportunities and risks, no evaluation of issue likelihood is necessary as the issue probability = 1. Using the top row from the 5x5 risk reporting matrix (the row representing the highest likelihood), the issue consequence value is converted to an issue level using an issue reporting matrix like the one in Figure 6-8. The green, yellow, and red regions on the issue reporting matrix indicate areas of low, moderate and high issue level, respectively.

17

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

Figure 6-8: Issue Reporting Matrix

6.5. LCRM Step 5 - Risk Tracking. Risk tracking answers the question, "How has the risk changed," or "How are the risk handling plans working?" Risk tracking includes a continuous process to systematically track and evaluate the performance of risk handling plans against established metrics throughout the acquisition process. See Figure 6-9 for more details. Not all risk handling will be successful-- the program office should reevaluate the risk handling implementation approach and associated activities to determine effectiveness and whether or not changes are needed.

Note: The latest USAF guidance calls this activity "risk tracking," but the DoD RIO Management Guide refers to it "risk monitoring." This template will use "tracking" to refer to this fifth step in the LCRM process. In this RMP template the term "monitoring" is used for one of the risk handling/correction options in Step 4, and should not be confused with the "continuous monitoring" requirements for a program's information technology (IT) Risk Management Framework (RMF) process described in AFI 17-101. See paragraph 6.4 and AFPAM 63-128 for more details on risk tracking.

Figure 6-9: LCRM Step 5 - Risk Tracking

Risk tracking is performed as part of technical reviews, RWG/RMB meetings and program reviews using a risk management tool. Documentation may include reports for the PM, CE and other key decision authorities. Risk burn-down charts are one option to help track risks.

7. RISK PROCESS IN RELATION TO OTHER PROGRAM MANAGEMENT TOOLS.

18

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

Briefly describe other key management tools that the program office and contractor(s) use, and how they integrate with the program's risk management tool(s) and processes.

If risk is considered to be "uncertainty that matters," then the purpose of risk management is to get sufficient, relevant and timely information about uncertainties to make better decisions and effectively address the risks that the program is most concerned about. Risk management enables the program to proactively allocate its limited program resources to key risks to maximize the probability of program success. Since allocating resources can impact a program's budget, schedule and system capabilities, there will likely be a need to exchange risk-related information between various program tools used by different stakeholders.

The risk management process should be integrated with other program management and systems engineering functions/tools during all phases of the program. Examples of program management tools that could be included in this section are the Work Breakdown Structure (WBS), Integrated Master Plan (IMP), Integrated Master Schedule (IMS) and Earned Value Management (EVM). Technical Performance Measures (TPMs) are an example of a relevant systems engineering tool. Collectively these tools, along with cost, schedule and performance risk analyses, help the PM gain insight into balancing program requirements and constraints against cost, schedule and performance risks.

The PMO and contractor(s) should use the same tools. If they use different tools, the tools should be capable of exchanging data-- this section would then include a description of how (and when) the data would be transferred.

8. RISK COST/SCHEDULE/PERFORMANCE (C/S/P) EVALUATION TECHNIQUES.

Provide a summary of the cost, schedule and performance evaluation processes, including procedures for evaluating risks:

• Overview and scope of the C/S/P evaluation processes.

• Sources of C/S/P information.

• Planned frequency of C/S/P assessments.

• Evaluation products and formats.

• C/S/P evaluation techniques and tools.

• C/S/P likelihood and consequence parameters/thresholds.

Using the five-step RM process discussed in section 6, the PMO is required to identify risks and assess the potential cost, schedule and/or performance impacts of each of those risks. This RMP section provides the details on how the program determines the C/S/P impacts for each identified risk.

Many of the program management tools mentioned in section 7 (WBS, IMP, IMS, EVM, etc.) can provide baseline information and functions useful to C/S/P evaluations. Additional C/S/P-unique tools and techniques may also be required. Example:

Schedule. The schedule risk analysis (SRA) uses task duration uncertainties in combination with a statistical simulation technique (typically Monte Carlo method) to analyze the level of

19

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

confidence in meeting selected program dates. The program uses the latest IMS after checking to ensure that the underlying schedule data are free of potential errors that could have an adverse impact on the SRA results. Both the SRA and the IMS are updated on a recurring basis (at least semiannually) over the course of the program. The results of the SRA are used not as a definitive forecast but as an indicator of the program’s likely schedule progression and completion without additional risk mitigation actions. As such the analysis informs management actions, supports “what-if” evaluations, and provides inputs for prioritizing risk mitigation approaches and control activities. The results of an SRA are typically displayed as a histogram (an approximation to a probability density function) providing the frequency of schedule outcomes (dates) and an S-Curve (a cumulative distribution function) providing the cumulative probability of achieving dates associated with given milestones or overall program completion. Other outputs include a probabilistic critical path and schedule sensitivity analysis.

The C/S/P likelihood and consequence thresholds are provided in AFI 63-101/20-101 and AFPAM 63-128. These thresholds may be tailored with approval from the Milestone Decision Authority (MDA).

9. COMMUNICATION AND FEEDBACK PROCESS.

Describe the process for communicating and/or elevating the status of potential, current and retired risks that may exist to all personnel involved in risk management.

Figure 6-1 shows the five-step LCRM process. While each step in that figure was discussed in section 6, the one part of the figure that was not discussed explicitly was the "communication and feedback" portion in the center. That portion is often assumed by program stakeholders to just be true-- that all persons involved in each of the five steps will communicate with each other and provide feedback on each step to ensure good data, products and processes. But this is not always the case ... stakeholders sometimes work in relative isolation on their part of the five-step process, and sometimes do not have opportunity to provide or receive feedback on the status of current risks, the emergence of new risks, the development/solution of problems within the program's RM processes, and results/decisions from other parts of the program's RM hierarchy.

This RMP section should describe how personnel involved in the program's RM processes can communicate and/or elevate the status of potential/current/retired risks, and get feedback about the performance, effects and/or results of their actions and decisions. This is important to support the transition and update of info between the RM process steps, the program life cycle phases, and responsible government/contractor organizations.

One tool to improve communication and feedback can be use of a "risk register" or database as a central repository for all risks identified by the program team-- Table 9-1 below shows an excerpt from a sample format. The register can be used to describe and track risks, and to record actions approved by the RMB. It can include information for each risk such as risk category,

20

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

risk statement, likelihood, consequence, planned handling/mitigation measures, the risk owner, WBS/IMS linkage and, where applicable, expected closure dates and documentation of changes. It can also include rationale for the selection of a particular risk handling/mitigation option, and it can serve as a source for lessons learned during or at the end of key program events.

Table 9-1: Risk Register (Excerpt, Example)

21

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

Acronyms

ACC Acquisition Community Connection

AF Air Force

AFI Air Force Instruction

AFIT Air Force Institute of Technology

AFLCMC Air Force Life Cycle Management Center

AFMAN Air Force Manual

AFMC Air Force Materiel Command

AFPAM Air Force Pamphlet

AFPD Air Force Policy Directive

AoA Analysis of Alternatives

AS Acquisition Strategy

C/S/P Cost/Schedule/Performance

CBA Capabilities Based Assessment

CE Chief Engineer

CJCSI Chairman of the Joint Chiefs of Staff Instruction

COOP Continuity of Operations Plan

DAG Defense Acquisition Guidebook

DAU Defense Acquisition University

DBS Defense Business System

DoD Department of Defense

DoDD Department of Defense Directive

DoDI Department of Defense Instruction

EAC Estimate at Completion

ERMS Enterprise Risk Management Service

ESOH Environment, Safety and Occupational Health

EVM Earned Value Management

FEMA Federal Emergency Management Agency

FMECA Failure Mode, Effects and Criticality Analysis

ID Identification

IMP Integrated Master Plan

IMS Integrated Master Schedule

22

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

IOT&E Initial Operational Test and Evaluation

IPT Integrated Product Team

IT Information Technology

KPP Key Performance Parameter

KSA Key System Attribute

LCRM Life Cycle Risk Management

MBSE Model-Based Systems Engineering

MDA Milestone Decision Authority

M&S Modeling and Simulation

O&S Operations and Sustainment

PEO Program Executive Office or Program Executive Officer

PERT Program Evaluation & Review Technique

PESHE Programmatic Environment, Safety and Occupational Health Evaluation

PM Program Manager

PMO Program Management Office

POA&M Plan of Action & Milestones

POM Program Objective Memorandum

PRB Program Review Board

P/CS Probability/Consequence Screening (Tool)

RIM Risk & Issue Management

RIO Risk, Issue and Opportunity

RI3 Risk Identification, Integration and Ilities (Tool)

RM Risk Management

RMF Risk Management Framework

RMP Risk Management Plan

RMB Risk Management Board

RWG Risk Working Group

SE Systems Engineering

SEMP Systems Engineering Management Plan

SEP Systems Engineering Plan

SME Subject Matter Expert

SPoF Single Point of Failure

SRA Schedule Risk Analysis

23

RKTM002 Risk Management Plan Template 13 September 2017 OPR: HQ AFMC/ENS, DSN 787-4311

SWOT Strengths, Weaknesses, Opportunities and Threats

TPM Technical Performance Measure

TRB Technical Review Board

TSN Trusted Systems and Networks

T&E Test and Evaluation

UAV Unmanned Air Vehicle

USAF United States Air Force

WBS Work Breakdown Structure

24