Exhibit_3e_TFITS_Risk_Management_Plan.pdf

FOR OFFICIAL USE ONLY

RISK MANAGEMENT PLAN (RMP)

TOTAL FORCE INFORMATION TECHNOLOGY

SYSTEMS (TFITS)

Version 1.0

Prepared by:

MARINE CORPS SYSTEMS COMMAND

Total Force Information Technology Systems (TFITS)

Information Systems & Infrastructure Quantico, Virginia 22134 initiator:jeffrey.smith@qinetiq-na.com;wfState:distributed;wfType:email;workflowId:0f4726397d1d4244a715d063afc5b646

TFITS-RMP-1.0 18 November 2013 ii

SIGNATURE PAGE

RISK MANAGEMENT PLAN (RMP)

REVIEWED BY:

Mr. Tony Brill Deputy Product Manager

PM IS&I, TFITS

Marine Corps Systems Command

APPROVED BY:

Mr. William Sandlin Product Manager (PdM)

PM IS&I, TFITS

Marine Corps Systems Command iii

RECORD OF CHANGE HISTORY

Date Revision Reason for Change Entered by Pages Affected

Questions concerning this Risk Management Plan should be referred to:

• Tony Brill, TFITS Deputy PdM, 703-784-4865, tony.brill@usmc.mil mailto:Tony.Brill@usmc.mil iv

TABLE OF CONTENTS

1. INTRODUCTION

1.1 PURPOSE

1.2 SCOPE

1.3 REFERENCES

2. TFITS RISK MANAGEMENT OVERVIEW AND ORGANIZATION

2.1 RISK MANAGEMENT ORGANIZATION

3. TFITS RISK MANAGEMENT PROCESS

3.1 PERFORMING RISK ASSESSMENTS

3.1.1 Risk Identification

3.1.2 Determining Risk Root Cause

3.1.3 The Risk Statement

3.2 RISK ANALYSIS

3.2.1 Purpose

3.2.2 Risk Reporting Matrix

3.2.3 Determining Likelihood of Occurrence

3.2.4 Determining Consequence of Occurrence

3.3 RISK MITIGATION PLANNING

3.3.1 Prioritizing Risk

3.3.2 Risk Mitigation Approvals

3.4 RISK MITIGATION IMPLEMENTATION

3.5 RISK TRACKING

4. ESCALATION CRITERIA

5. REPORTING

APPENDIX A: DEFINITION OF TERMS

APPENDIX B: ACRONYMS AND ABBREVIATIONS

APPENDIX C: RISK MANAGEMENT ROOT CAUSE CATEGORIES

APPENDIX D: PDM TFITS RISK MANAGEMENT BOARD CHARTER

APPENDIX E: PDM TFITS RISK REGISTER

v

FIGURE

Figure 1: PMM-110 Enterprise Risk Management Process Figure 2: TFITS Risk Management Process - Overview Figure 3: TFITS Risk Management Process Flow Figure 4: Risk Reporting Matrix Figure 5: Risk Reporting Matrix - Escalation Criteria

TABLES

Table 1: TFITS Risk Management Organizations Table 2: TFITS Risk Management Roles and Responsibilities Table 3: Risk Components Table 4: Likelihood of Occurrence Table 5: Consequence (Impact) of Occurrence Table 6: TFITS Risk Tracker Information Details

1. INTRODUCTION

The Product Manager (PdM), Total Force Information Technology Systems (TFITS) is responsible for research and development, acquisition, and sustainment of select Marine Corps logistics and support information systems. As such, one aspect of effectively managing the TFITS applications is to understand risk, risk management and implement a Risk Management Plan (RMP).

Risk management is a continuous process that is accomplished throughout the life cycle of a system. It is an organized methodology for continuously identifying and measuring the unknowns; developing mitigation options; selecting, planning, and implementing appropriate risk mitigations; and tracking the implementation to ensure successful risk reduction or elimination.

An effective RMP identifies activities to analyze risk, formulate risk mitigation strategies, and apply effective risk management processes to ensure risks are eliminated or reduced to an acceptable level.

This plan, while developed and tailored specifically to address risk and risk management within the TFITS organization, has its basis in common and accepted Department of Defense acquisition risk management practices. It also integrates seamlessly with the risk management strategies and processes established by the Program Manager, Information Systems & Infrastructure, PMM-110.

The PMM-110 Enterprise Risk Management process leverages the risk management techniques, tactics, and procedures outlined in this plan and provides for effective identification of program risk across the PMM-110 Enterprise and the strategies to accept mitigate and/or eliminate. Figure 1 provides an overview of the PMM-110 Enterprise Risk Management process.

1.1 Purpose

The purpose of the TFITS Risk Management Plan (RMP) is:

• To create an environment in which an understanding of the risks across TFITS reduces the amount of uncertainty in the decision-making processes.

• To foster the integration of risk management concepts and processes into project management and systems engineering processes in order to increase the likelihood of meeting project objectives

• To provide a framework for prioritizing risks and properly allocating enterprise resources to manage them more efficiently and effectively.

Figure 1: PMM-110 Enterprise Risk Management Process

1.2 Scope

This RMP applies to all TFITS programs, including those already fielded to the operating forces as well as any new system acquisitions. This RMP shall be adhered to as a program transitions from inception through disposal to identify, assess, and mitigate risks that have an impact on overall cost, schedule, and/or performance.

This RMP is not intended to dictate specific risk management practices of individual prime contractors.

1.3 References

Department of Defense Instruction 5000.02, Operation of the Defense Acquisition System, 2 December 2008 Risk Management Guide for DoD Acquisition, 6th Edition, August 2006 Marine Corps Systems Command Order (MCSCO) 5000.3, Naval Systems Command Risk Management Policy, 6 June 2008 U.S. Department of Defense Extension to: A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 4tht Edition, June 2008 Program Manager, Information Systems & Infrastructure, PMM-110 Enterprise Risk Management Plan (Draft) 6 Feb 2013

2. TFITS RISK MANAGEMENT OVERVIEW AND ORGANIZATION

Effective risk management depends on risk management planning; early identification and analyses of risks; early implementation of corrective actions; continuous monitoring and reassessment; and communication, documentation, and coordination.

The PdM TFITS risk management process consists of the following basic methodology to manage program risks:

Risk Identification Risk Analysis Risk Mitigation Planning Risk Mitigation Plan Implementation Risk Tracking

The TFITS risk management process, outlined in Section 3, will support the concepts and requirements delineated in the PMM 110 Risk Management Plan.

Figure 2 is an overview of the TFITS Risk Management Process and the integration with PMM-110 Enterprise Risk Management process.

Figure 2: TFITS Risk Management Process - Overview

2.1 Risk Management Organization

The PdM TFITS risk management organization consists of separate but tightly coordinated tiers of risk management incorporating all stakeholders with a vested interest in the success of each TFITS program. Each tier is both individually and collectively responsible for executing appropriate tasks for effective and proactive risk management (Table 1).

Table 1: TFITS Risk Management Organizations

Tier Description

Tier III IPT

The Tier III IPT is the lowest tier in the hierarchical risk management relationship and where TFITS Projects are managed. Project Managers (PjMs) are responsible for the day-to-day management of the assigned Project including the implementation of risk management as described in this plan.

Tier II IPT

The Tier II IPT provides an oversight function to Tier III and is responsible for engaging the PjMs. Tier II Leads coordinate the review and assessment of Tier III risks while implementing risk management at the portfolio level. Tier III and Tier risks are escalated to the TFITS Risk Management Board (RMB) based on criteria provided by PdM

TFITS.

Tier I IPT

The Tier I IPT consists of the Product Manager (PdM), Deputy Product Manager (DPdM) and the Assistant Product Managers (APdM). Tier I provides oversight to the Tier II Leads as well as implementing risk management at the Product level.

TFITS Risk Management Board (RMB) TFITS RMB includes the PdM, DPdM, APdM and Tier II Leads.

Personnel in the Tiers will work in concert to effectively identify, mitigate, and track project and program risks. The PjM is responsible for the day-to-day activities involved in managing his/her project risks.

Specific roles and responsibilities are assigned to the risk management organizations as shown in Table 2.

Table 2: TFITS Risk Management Roles and Responsibilities

Risk Management Organization Primary Roles and Responsibilities

Tier III IPT

• Identify project / Tier III level risks; engage subject matter experts where applicable in primary risk discussions.

• Draft candidate risk statements as needed.

• Add, review, and update, as necessary, relevant project risks and mitigation strategies in the TFITS Risk Management Tool.

• Establish correlation between the Integrated Master Schedule (IMS) and risk mitigation step activities.

• Review/update mitigation step progress with completion dates.

Tier II IPT

• Identify Tier II level risk and mitigation strategies (beyond the purview of the PjM).

• Review and approve Tier II and respective III level risks and mitigation strategies and updates to open, active risk, within authority.

• Provide recommendations and proposed mitigation steps on risks elevated to the TFITS RMB

• Ensure that risks are well prepared for presentation to the TFITS

RMB

Tier I IPT

• Identify Tier I level risk and mitigation strategies.

• Provide recommendations and proposed mitigation steps on risks elevated to the

TFITS RMB

• Ensure that risks are well prepared for presentation to the TFITS RMB

• Review, prepare, and finalize all recommendations for Tier I level risk actions to the

TFITS RMB

TFITS RMB

• Review and approval of candidate risks and updates to open, active program risks

• Adjudicate any risk conflicts (inter, intra, or other platform)

• Approve final disposition for risk mitigation plans and activities

• Allocate resources needed to ensure risk handling/mitigation

• Resolve any action items; identify new action items (primarily issues)

• Develop and present recommendations to the PM in risk and related topics

• Review, prepare, and finalize all recommendations for Tier I level risk actions to be escalated to the PMM-110 ERMB

3. TFITS RISK MANAGEMENT PROCESS

The TFITS Risk Management Process is a methodology for continuously identifying and analyzing potential risks; identifying the root cause, selecting, implementing appropriate risk mitigations; and tracking and monitoring the mitigations to ensure successful risk reduction.

Figure 3 provides an overview of the TFITS risk management process flow.

Figure 3: TFITS Risk Management Process Flow

3.1 Performing Risk Assessments

Risk Assessment, identifies and analyzes program areas to discover risk events and their potential impacts. Risk Assessment is accomplished by conducting risk identification and analysis.

3.1.1 Risk Identification

Risk identification, the question “what can go wrong” by brainstorming and introducing risk scenarios surrounding project activities (i.e., development, fielding, and sustainment) and milestones that, if they fail to occur, could cause delay in the design, production, or delivery of the system, adversely affect the system’s performance, or increase program cost. Each identified risk is tied to a root cause.

3.1.2 Determining Risk Root Cause

A risk root cause is the most basic reason for the presence of a risk. It is one of three components (Table 3) which are the foundations in determining how to appropriately handle a risk. A risk root cause is identified by asking “why”, multiple times, until the source(s) is discovered. Appendix C outlines the root causes grouped by cost, schedule and performance categories. Accordingly, the effects of a risk, or the likelihood and consequence, should be tied to risk root causes.

Table 3: Risk Components

Risk Components Description

Risk Root Cause If eliminated or corrected, would prevent potential consequences from occurring.

Likelihood of Occurrence The probability assessed at the present time of that future root cause occurring.

Consequence of Occurrence The impact of that future Root Cause.

3.1.3 The Risk Statement

Identified risks are described and communicated in the form of risk statements. A risk statement provides the clarity and the descriptive information required for an assessment of the risk's occurrence probability and areas of impact. Using the Condition-If-Then format helps communicate and evaluate a risk and develop a mitigation strategy. A well-written risk statement contains two components:

• The “IF” is the risk event associated with a root cause.

• The “THEN” is the consequence, or set of consequences, that will impact the project

(cost, schedule, performance) if the risk event occurs.

The risk statement will also withstand, and should therefore address the “So what?” question.

Asking “so what?” of a risk statement ensures the identification of the real impact to the project has been addressed by the risk statement.

Example:

• If Project xyz does not receive a MS C decision from the MDA by 31 Aug Then there will not be enough time to award the Production contract by the end of September causing the project to lose the expiring PMC funds and leaving the program with a significant funding deficiency and an indefinite delay in delivering this critical warfighting capability to the Marines.

3.2 Risk Analysis

3.2.1 Purpose

The intent of risk analysis is to answer the question “How big is the risk?” by:

• Considering the likelihood of the root cause occurrence

• Identifying the possible consequences in terms of performance, schedule, and cost.

• Identifying the risk level using the Risk Reporting Matrix shown in Figure 4.

3.2.2 Risk Reporting Matrix

Each undesirable event that might affect the success of the program (performance, schedule, and cost) should be identified and assessed as to the likelihood and consequence of occurrence. A standard format for evaluation and reporting of program risk assessment findings facilitates common understanding of program risks at all levels of management. The Risk Reporting Matrix (Figure 4) is typically used to determine 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).

Figure 4: Risk Reporting Matrix

3.2.3 Determining Likelihood of Occurrence

To evaluate the likelihood of a risk during the risk analysis process, the TFITS projects will use the five levels of probability identified in Table 4. For example, if the root cause has an estimated 50 percent probability of occurring, the corresponding likelihood of occurrence is Level 3. Determining the risk likelihood is a subjective analysis using experience of the individual, team and their knowledge of the project.

Table 4: Likelihood of Occurrence

Level Likelihood Probability of Occurrence

5 Near Certainty ~90% 4 Highly Likely ~70% 3 Likely ~50% 2 Low Likelihood ~30% 1 Not Likely ~10%

3.2.4 Determining Consequence of Occurrence

To evaluate the consequence (impact) of a risk during the risk analysis process, the TFITS project will use the five levels identified in Table 5. Determining the risk consequence is a subjective analysis using experience of the individual, team and their knowledge of the project.

Table 5: Consequence (Impact) of Occurrence

Level Technical Performance Schedule Cost

1 Minimal or no consequence to technical performance Minimal or no impact Minimal or no impact

Minor reduction in technical performance or supportability, can be tolerated with little or no impact on program

Able to meet scheduled or planned dates ~ 30 Days Delay

1-3% cost growth or ~ 10% funding decrease

Moderate reduction in technical performance or supportability with limited impact on program objectives

Minor slip to planned events

~ <= 3 Months

~5% cost growth or

~15% funding decrease

Significant degradation in technical performance or major shortfall in supportability; may jeopardize program success

Scheduled/planned events seriously impacted ~ 6 Months Delay

~5 - 9% cost growth or

~15% funding decrease

Severe degradation in technical performance; Cannot meet KPP or key technical/supportability threshold; will jeopardize program success

Cannot meet key event(s) or milestone(s) > 6 Months Delay

>= 10% cost growth or

~20% funding decrease

The following paragraphs provide relevant questions to ask in assessing performance, schedule, and cost root causes.

Performance (P) Considerations Is there an impact to technical performance and to what level? If so, this risk has a performance consequence. These risks generally have associated schedule and cost impacts, but should be carried as a performance risk.

• Operational (e.g., Initial Capabilities Document (ICD), Capability Development

Document (CDD), Capability Production Document (CPD), threats, suitability, effectiveness).

• Technical (e.g., SEP, Technology Readiness Levels, specifications, TEMP, technical baselines, standards, materiel readiness)

• Management (e.g., organization, staffing levels, personnel qualifications/experience, funding, management processes, planning, documentation, logistics)

Schedule (S) Considerations Is there an impact to schedule performance and to what level? If the risk does not have a first order performance impact, then ask this question. If the risk does impact the critical path, then it impacts both schedule and cost, but should be carried as a schedule risk.

Were any problems that caused schedule slips identified as risks prior to their occurrence? If not, why not? If yes, why didn’t the associated mitigation plan succeed? The IPTs should analyze impact of the risk to the IMS and the critical path(s), to include:

• Evaluating baseline schedule inputs (durations and network logic);

• Incorporating technical assessment and schedule uncertainty inputs to the program schedule model;

• Evaluating impacts to program schedule based on technical team assessment;

• Performing schedule analysis on the program IMS, incorporating the potential impact from all contract schedules and associated government activities;

• Quantifying schedule excursions reflecting the effects of cost risks, including resource constraints;

• Providing a government schedule assessment for cost analysis and fiscal year planning, reflecting the technical foundation, activity definition, and inputs from technical and cost areas; and

• Documenting the schedule basis and risk impacts for the risk assessment.

• Projecting an independent forecast of the planned completion dates for major milestones.

Cost (C) Considerations Does the risk only impact life-cycle cost? If so, with no performance or schedule impacts, the risk is a cost risk, and may impact estimates and assessments such as:

• Building on technical and schedule assessment results;

• Translating performance and schedule risks into life-cycle cost;

• Deriving life-cycle cost estimates by integrating technical assessment and schedule risk impacts on resources;

• Establishing budgetary requirements consistent with fiscal year planning;

• Determining if the adequacy and phasing of funding supports the technical and acquisition approaches;

• Providing program life-cycle cost excursions from near-term budget execution impacts and external budget changes and constraints; and

• Documenting the cost basis and risk impacts.

NOTE: Cost and funding are not the same. Cost is related to the amount of money required to acquire and sustain a commodity, and funding is the amount of money available to acquire and sustain that commodity.

3.3 Risk Mitigation Planning

Risk Mitigation Planning answers the question “What is the program approach for addressing this potential unfavorable consequence?” One or more of these mitigation options may apply:

• Avoiding risk by eliminating the root cause and/or the consequence,

• Controlling the cause or consequence,

• Transferring the risk, and/or

• Assuming the level of risk and continuing on the current program plan.

Risk mitigation planning is the activity that identifies, evaluates, and selects options to set risk at acceptable levels given program constraints and objectives. Risk mitigation planning is intended to enable program success. It includes the specifics of what should be done, when it should be accomplished, who is responsible, and the funding required to implement the risk mitigation plan. The most appropriate program approach is selected from the mitigation options listed above and documented in a risk mitigation plan. The risk mitigation plan, developed by the PjM, needs to be realistic, achievable, measurable, and documented and should address the following:

• 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 impacts, likelihood of occurrence, consequence, whether the risk is within the control of the program)

• Why the risk exists (root cause)

• The options for mitigation (possible alternatives to alleviate the risk)

• Definition of events and activities intended to reduce the risk, success criteria for each plan event, and subsequent “risk level if successful” values

• Risk status

• The fallback approach (describes the approach and expected decision date for considering implementation)

• A management recommendation (whether budget or time is to be allocated)

• Appropriate approval levels (Tier II IPT and/or PdM)

• Identified resource needs.

3.3.1 Prioritizing Risk

Prioritizing risks consists of evaluating the assigned likelihood and consequence criteria, determining the risk rating, and reviewing the collective results for all risks identified within a program. Reviewing all program risk ratings will determine the prioritization of each risk and the order in which it should be addressed. If more than one risk shares the same rating, the PjM will set the priority. The Tier II IPT may adjust priority on review.

The corresponding likelihood and consequence levels of each individual risk will be plotted on the Risk Reporting Matrix (Figure 3) to define the risk rating of Low (green), Moderate (yellow), and High (red).

Low Risk (green): Has a “very unlikely” to “unlikely” probability of occurring and/or minimal to marginal potential for increase in cost, disruption of schedule, or degradation of performance should the risk transpire. Normal program management attention should result in adequate handling of the risk.

Moderate Risk (yellow): Has a “possible” likelihood of occurring, and a moderate chance of increase in cost, disruption of schedule, or degradation of performance should the risk transpire. Special action and management attention will be applied to adequately handle the risk to an acceptable level.

High Risk (red): Has a “likely” to “near certainty” likelihood of occurrence and would cause critical to catastrophic increases in cost, disruption of schedule, and/or degradation of performance should the risk transpire. Significant additional action and high priority management attention and reporting will be required to appropriately handle the risk to an acceptable level.

3.3.2 Risk Mitigation Approvals

The Tier III IPT has the authority to approve risk mitigation strategies for Low (green) risks that do not require the expenditure of funds.

The Tier II IPT (chaired by the IPT Lead or his designated representative) has the authority to approve risk mitigation strategies for moderate yellow risks (1, 5 – 5, 1) that do not require the expenditure of funds. The Tier II IPT may, at their discretion, request a presentation to and an approval from the RMB.

High yellow and red risks (2,5 – 5,2) and any other risks that require expenditure of funds to mitigate will have risk mitigation strategies approved by the RMB.

In all cases, the PjM formulates risk mitigation plans, as previously described. The PjM should not wait for final approval to begin implementation of any risk mitigation plan not involving the expenditure of funds. In the event of concerns regarding a particular risk mitigation plan, the PjM should contact the Tier II IPT and/or PdM as appropriate.

3.4 Risk Mitigation Implementation

Risk Mitigation Implementation is simply the execution of the approved Risk Mitigation Plan. The PjM and other interested stakeholders will work together to complete the actions outlined in the Risk Mitigation Plan.

3.5 Risk Tracking

The PjM is responsible for entering all data elements (Table 6) of the approved Risk Mitigation Plan into the TFITS Risk Tracker (https://mcscviper.usmc.mil/sites/isi_tfits/SitePages/Risk%20Tracker.aspx). The PjM will track the risk and update its status within the database if changes occur or if the mitigation plan requires adjustment.

Table 6: TFITS Risk Tracker Information Details

Item Description Risk Title Brief description of the risk.

Functional Area Choice Functional area impacted: Programmatic, Funding, Project Name Name of Project Risk ID An automatically generated unique identifier Risk / Issue Selection If Brief description of the risk event Then Brief description of the consequence Likelihood Possibility rating Consequence Impact rating Category Selection Visibility Selection Mitigation Strategy 1 Details the risk mitigation strategy.

Mitigation Strategy 2 Details the risk mitigation strategy.

Mitigation Strategy 3 Details the risk mitigation strategy.

Mitigation Strategy 4 Details the risk mitigation strategy.

Mitigation Strategy 5 Details the risk mitigation strategy.

Assumptions / Constraints Status Selection Risk Priority Selection Assign to Person or group to whom risk is assigned

Competency Managed Metadata Project Acronym Lookup Field Tier II Lookup Field PjM Approved Selection Yes/No Risk Rating Calculated field based on Likelihood and Consequence Handling Strategy Originator Owner

Risk Tracking is designed to ensure the execution of the Risk Mitigation Plan is successful and progressing as planned. Tracking can happen in two ways, informally and formally.

https://mcscviper.usmc.mil/sites/isi_tfits/SitePages/Risk%20Tracker.aspx

Informal Tracking: The PjM reviews the identified risk and determines if the timeline to complete the mitigation strategy is effective and on track and reports to the approval authority as necessary.

Formal Tracking: The updated progress and impact of the Risk Mitigation Plan is presented to the Tier II IPT during the scheduled Tier II IPT meetings or to the PdM during PMRs or as required due to a significant change in the risk.

4. ESCALATION CRITERIA

PdM TFITS requires risk escalation and mitigation plan approval on risks that meet the following criteria:

• Risks in (2,5 – 5,2) shape on the risk matrix by virtue of their likelihoods and consequence.

• Risks that shift from yellow to red.

• Risks that shift from green to yellow or green to red.

• The PjM’s and Tier II Lead’s top risk.

• Risk that have consequences for other TFITS projects.

• Risks for which a planned/scheduled mitigation step date has slipped or passed.

• Risks for APBA/ABM cost or schedule breaches.

• Risks whose root cause(s) are at agencies external to MCSC (HQMC C4 / I&L /

MCNOSC, e.g.).

• Risks that have become issues.

• Risks whose mitigation plans include avoiding the risk or accepting the risk.

• All green or yellow risks requiring the expenditure of funds to mitigate.

Figure 5: Risk Reporting Matrix - Escalation Criteria

The following is the TFITS RMB criteria for escalating risks to the PMM-110 Enterprise Risk Management Board:

• Risks in (2,5 – 5,2) shape on the risk matrix by virtue of their likelihoods and consequence.

• Risks for APBA/ABM cost or schedule breaches.

• The PdM’s top risk as determined by the TFITS RMB.

• Risks that have consequences for other PdMs.

• Risks that shift from yellow to red within a timeframe specified by the RMB.

• Risks whose root cause(s) are at agencies external to MCSC (HQMC C4 / I&L /

MCNOSC, e.g.).

• Risks that shift from green to yellow or green to red within a timeframe specified by the

RMB.

• Risks for which a planned/scheduled mitigation step date has slipped or passed.

• Risks that have become issues (for post-mortem analysis)

• Risks whose mitigation plans include avoiding the risk or accepting the risk.

5. REPORTING

In addition to risks reported in Program Management Reviews (PMRs), a Risk Register will be produced at each Tier II IPT and submitted in advance to the Risk Management Board Secretariat in preparation for the RMB to be conducted on the third Thursday of each month as part of the Tier I Integrated Product Team (IPT) meeting.

The TFITS RMB will produce the following reports after the scheduled monthly meeting:

• TFITS Risk Register (summary)

• TFITS Risk Register (PMM-110 escalated risks)

The reports are a product of the TFITS Risk Tracker located at the PdM TFITS SharePoint site (https://mcscviper.usmc.mil/sites/isi_tfits/SitePages/Risk%20Tracker.aspx). Example risk register is contained in appendix E.

https://mcscviper.usmc.mil/sites/isi_tfits/SitePages/Risk%20Tracker.aspx

Appendix A: Definition of Terms

Consequence A resulting effect; the impact arising from risk.

Root Cause

The reason which, if eliminated or corrected, would prevent a potential consequence from occurring. It is the most basic reason for the presence of a risk.

Risk

A measure of future uncertainties in achieving program performance goals within defined cost and schedule constraints. It has three components: a future root cause, a likelihood assessed at the present time of that future root cause occurring, and the consequence of that future occurrence.

Issue

A problem or consequence which has occurred due to the realization of a root cause. A current issue was likely a risk in the past that was ignored or not successfully mitigated.

Likelihood The chance or probability of a risk occurring.

Mitigate Plan of action to make the likelihood or consequence of a risk less harsh, severe, or adversely impacting.

Performance Risk

The risk associated with the evolution of the design, production, and supportability of PM TFITS systems affecting the level of performance necessary to meet the operational requirements.

Probability The chance or likelihood that an event will occur or has occurred.

Realized Risk A risk that has occurred and become an issue.

Realized Risk Mitigation Strategy

The clean-up effort or action that is required to recover from the impact of the issue.

Residual Risk The level of risk that remains after mitigation steps have been implemented.

Risk A measure of future uncertainties in achieving program goals within defined cost, schedule, and performance constraints.

Risk Acceptance An informed decision to accept the consequences and likelihood of a particular risk.

Risk Analysis

The activity of examining each identified risk to refine the description of the risk, isolate the root cause, determine the likelihood and consequence, and set risk mitigation priorities. It refines each risk in terms of the likelihood, consequence, and relationship to other risk areas or processes.

Risk Identification The activity that examines each element of a program to identify future root causes and sets the stage for their successful management.

Risk Database A repository of risks identified for each project.

Risk Management

An organized method for continuously identifying and measuring risks;

developing mitigation options; selecting, and implementing the appropriate mitigations; tracking risks; and accepting and transferring risks when there is no further prudence to mitigate.

Risk Mitigation Strategy

Risk Mitigation Strategy is a series of activities and/or steps designed to reduce the risk of occurrence and/or consequence it’s execution.

Risk Reporting Matrix

A color coded block diagram used in risk analysis which yields risk ratings based on corresponding consequence and likelihood levels.

SharePoint Risk Tracker A repository of risks identified for each project in a SharePoint database.

Appendix B: Acronyms and Abbreviations

APBA Acquisition Performance Baseline Agreement APB Acquisition Program Baseline CDD Capability Development Document CPD Capability Production Document DoD Department of Defense ESOH Environment, Safety, and Occupational Health EVM Earned Value Management ICD Initial Capabilities Document IMP Integrated Master Plan IMS Integrated Master Schedule IPT Integrated Product Team KPP Key Performance Parameters MCEITS Marine Corps Enterprise Information Technology Services MCSCO Marine Corps Systems Command Order MDA Milestone Decision Authority TFITS Total Force Information Technology Systems PdM Product Manager PjM Project Manager PM Program Manager PMBOK Project Management Body of Knowledge

RIN Risk Identification Number RM Risk Management RMP Risk Management Plan RMB Risk Management Board SEP Systems Engineering Plan SME Subject Matter Expert TEMP Test and Evaluation Master Plan WBS Work Breakdown Structure

Appendix C: Risk Management Root Cause Categories

Risk Root Cause by Risk Category:

COST

Cost The ability to achieve the program’s life-cycle support objectives

Budget Sensitivity to budget variations and reductions and the resultant program turbulence

SCHEDULE

Concurrency Sensitivity to uncertainty resulting from combining or overlapping efforts

Schedule

Sufficient schedule to complete tasks Effects of programmatic schedule decisions, the inherent errors in schedule estimating, and external physical constraints

Earned Value Management (EVM) System

The adequacy of the contractor’s Earned Value Management process and the realism of the integrated baseline for managing the program.

PERFORMANCE

Threat

Sensitivity of the program to uncertainty in the threat description Degree to which the system design would have to change if the threat’s parameters change

Requirements Operational needs; attributes; performance; constraints; readiness [Key Performance Parameters (KPPs)]; technology; design process

Technical Baseline

Ability to meet the program’s engineering objectives Reliability, Supportability, Maintainability Baseline well defined point of time Capability of the test and evaluation program to assess significant performance specifications to determine if the system is operationally effective, suitable, and interoperable

Test & Evaluation

Capability of the test and evaluation program to assess significant performance specifications to determine if the system is operationally effective, suitable, and interoperable

Modeling & Simulation

Capability to support all life-cycle phases of a program using verified, validated, and accredited models and simulations

Production/Facilities

Ability of the system configuration to achieve the programs production objectives based on design, manufacturing process, and development/maintenance resources

Industrial Capabilities

Level of ability, knowledge, and experience of contractors to design, develop, and support the system

Management The degree the strategies exist and are realistic and consistent and/or sufficiently staffed with required resources

External Factors Availability of external resources (government) required for support (facilities, resources, personnel, government furnished equipment)

Technology The degree the proposed technology has demonstrated sufficient maturity to be realistically capable of meeting all program objectives

Logistics Ability of system configuration and associated documentation to achieve the program’s logistics objectives

Appendix D: PdM TFITS Risk Management Board Charter

Team Name Level of Team PdM TFITS RMB Tier I Purpose This Charter governs the PdM, TFITS Risk Management Board (RMB) and defines its roles and responsibilities, procedures, meetings, and membership.

The TFITS RMB meets monthly to review risks elevated to the PdM level by Tier 2 IPTs and/or TFITS APdMs. The purpose of the review is to understand and concur with each risk including the impact/consequence assessment and the proposed mitigation strategy. Risks reviewed during a RMB sessions will be evaluated for escalation to PMM-110 using criteria provided in the “PMM-110 Enterprise Risk Management Strategy”.

In addition, the RMB prioritizes PdM Level Risks and coordinates submission of the monthly Risk Report to PMM-110.

Team Products/Services

• TFITS Risk Register (Summary)

• TFITS Risk Register (PMM-110 Elevated Risks)

• Risk analysis, concurrence and mitigation approval

• Risk Management Decision Support

• Resource allocation to support mitigation

Team Membership Function/

(Competency) Individual Team Responsibility

RMB Chair 1. Preside over the TFITS RMB.

2. Review all elevated risks and mitigation strategies.

3. Review and evaluate the benefits and/or additional risks associated with the proposed mitigation strategy.

4. Provide to the appropriate risk owner, final risk management approval/disapproval and recommendations.

5. Request additional or clarifying information from the risk owner.

6. Approve the RMB minutes and action items.

7. Assign, monitor, and retire RMB action items.

8. Identify any specific topics needed to be addressed during upcoming Tier I IPTs.

RMB Secretariat 1. Update and maintain risk management documentation to include the most current concurrence state of each risk, and Risk Mitigation and Contingency Plans associated with each risk.

2. Capture concurrence with and/or recommended revisions to Risk

PdM TFITS Risk Management Board Charter

Mitigation/Contingency Plans at the conclusion of each Risk Board.

3. Maintain the top risk list for each Risk Board meeting.

4. Prepare an agenda for each meeting.

5. Coordinate time and location of the RMB meeting, and notify attendees.

6. Facilitate the Risk Board meeting.

7. Create or update action items following each Risk Board meeting.

8. Write and publish meeting minutes, and distribute to all members and participants in the Risk Board meeting.

RMB Members 1. Review and disposition all new risk statements and risk severities.

A disposition is either a concurrence or rejection of a risk as it is written, and includes acknowledgement or assignment of a Risk Owner.

2. Review and disposition all risks that require Risk Mitigation or Contingency Plans.

3. Concur with and/or recommend revisions to Risk Mitigation/Contingency Plans.

4. Communicate risks in accordance with the risk escalation process described in the TFITS Risk Management Plan.

5. Respond to action items within assigned due dates.

Team Agreements

1. RMB Meetings:

Consistent, Proactive Participation.

RMB members shall:

- Provide timely input/comments to assigned actions.

- Send an empowered substitute when not able to attend or arrange with the

Chair to provide appropriate input within 2 working days of the scheduled meeting.

Meeting Summaries. Brief summaries with action items/suspense dates/responsible parties and attendees shall be prepared and provided to members following the meeting.

2. Values Pledge:

Communications between members. Direct and open communication normally flows between the tiers as a means of exchanging information. Building trust is vital. The RMB will coordinate its activities in a manner to foster cooperation and reduce duplication of efforts.

3. Accountability Commitment:

Qualified, Empowered Team Members. Members must be knowledgeable and able to speak for their functional area in any decision-making process. Members shall inform the Chair of any limitations on their ability to speak on behalf of their functional area.

4. Decision Making Process:

Reasonable Disagreement. Members shall focus on reaching the best business decision for PdM TFITS. Reasonable disagreement can be anticipated while the RMB will strive for consensus on all issues.

5. Conflict Resolution Protocol:

Open Discussions. Members shall discuss all issues with frankness. Information and recommendations shall be shared with all team members.

Authority/Accountability/Boundaries

The PdM TFITS RMB will be guided by the applicable legal and regulatory policies and directives as delineated by the Program Manager, Information Systems & Infrastructure and higher headquarters.

• PMM-110 Risk Management Strategy (RMS)

• PMM-110 Risk Management Plan

• PdM TFITS Risk Management Plan

Metrics and Progress TFITS risk measures enable an open forum for dialogues on risk identification, risk analysis and risk communication among the PdM Staff and IPT leads throughout the TFITS risk management process. The value of these metrics is demonstrated by the ability to manage and allocate resources based on prioritized risks and assessments of the reduction of programmatic uncertainty in order to achieve PdM’s objectives. The following employs the Goal/Question/Metrics approach to align performance measurement with overall goals.

Risk Management Goal 1: "To ensure all programs are implementing risk management, correctly capturing and reporting risks and following the escalation process."

Questions:

1. For each project, what are the total number of active risks and what are the %s by functional area?

2. For each project, how many risks are escalated to the RMB?

3. For each project, how many risks were modified by the RMB (likeliness/consequence changed, If/Then statement updated, etc.)?

4. For each project, how many risks were approved by the RMB?

5. How many risks were escalated to the PMM110 RMB?

Metrics:

1. Total number of active risks (by project).

2. Percentage of risks by functional area (by project).

3. Number of risks escalated to the TFITS RMB (by project).

4. Number of risks modified by the RMB (by project).

5. Number of risks approved by the RMB (by project).

6. Number of risks escalated to PMM110 RMB.

Risk Management Goal 2 “To measure the success of risk mitigation in order to improve it.”

Questions:

1. For each project, how many risks are successfully being mitigated?

2. For each project, how many risks become issues?

Metrics:

1. Number of risk mitigation steps executed on time (by project).

2. Number of risk mitigation steps executed on time that had the desired effect on the risk (by project).

3. Number of risks that become issues (by project).

Review and Approval

Approved by:

________SAMPLE______________ _____________________________________

Mr. D. Corbin Date of Approval (to be reviewed semi-annually) Program Manager, Information Systems & Infrastructure

Submitted by:

__________SAMPLE_____________ _____________________________________

Mr. W. Sandlin Date of Submittal Product Manager, TFITS

Appendix E: PdM TFITS Risk Register

Priority Ranking

Risk Number

Risk Title Project Name

Functional Area

Risk / Issue If Then Probability Consequenc e Risk

Status Risk

Handling Risk Owner Trend

Systems Engineering

Staffing TFITS Tier 1 Performance Issue If adequate systems engineering support is not provided to TFITS Projects then the Projects will not be able to provide 1) appropriate oversight of contracted development activities which results in government not leading the direction of the systems, 2) requires additional engineering oversight be contracted out, 3) impacts the ability for standardization and implementation of common processes, 4) planning for migration to MCEITS, 5) lack of forward thinking for system modernization and

6) optimization of hardware and software architectures.

5 3 Open Avoid Pete Sandlin Increasing

Undocumented Business Rules/Functionality

Total Force Retention System

Performance Issue If system test and GAT efforts continue to reveal poorly captured requirements, then the TFRS modernization effort will continue to experience schedule slips which in turn will impact the system integrator's ability to work on other scheduled priorities.

5 3 Open Avoid Tammy Nguyen Stable

4 Gap in vendor support

MAGTF

Deployment Support System II

(MDSS II)

Contracts Risk

If the Contract award (full and open re-compete) for MDSS II PDSS is delayed beyond 25 May 2013 creating a gap in vendor support then the software will be unsupported by third and second party vendors. This is a big IA no-no and may result in a DATO. In additon to the DATO all helpdesk support will cease leaving the Marines will fewer options in resolving system issues resulting in possible delayed deployment operations.

5 2 Open Avoid Chris Hegland Stable

6 ODSE Interface

Secure Personnel Accountabilit y

Performance Issue If ARI does not fix the images on the SPA NIPR staging server, then SPA's reporting capability will be degraded which in turn will impact USMC commanders force assessments.

5 2 Open Avoid Danny Franco Stable

1 IRB Certification TFITS Tier 1 Cost Risk If the out of cycle certification process is not formalized and standard procedures implemented then lack of certification of TFITS funds in 8 MCPC's will cause missed deadlines to award contract options. These missed deadlines will impact ability for the TFITS to guarantee 95% system availability as is done today.

4 5 Open Avoid Pete Sandlin Stable

SubmitButton1: