Pre-MDD Military Capability Analyses

Pre-MDD Military Capability Analyses
Initiation to Materiel Development Decision (MDD)

Lesson Objectives Examine analytical approaches that identify military capabilities, capability gaps, recommend non-materiel & materiel approaches, & recommend action Examine military capability analytical approaches Examine capability analyses & their relation to the DOTmLPF-P Change Recommendation (DCR) & Initial Capabilities Document (ICD) Summarize the essential characteristics & qualities of Capability Based Assessments (CBAs)

Pre-MDD Military Capability Analysis
Joint Concepts Capability & Requirements Analyses MS C MS B Strategic Guidance MS A Technology Development Engineering & Manufacturing Development Production & Deployment Materiel Solution Analysis Technology Opportunities & Resources ICD O&S User Needs MDD CDD CPD AoA AoA: Analysis of Alternatives CDD: Capability Development Document CPD: Capability Production Document ICD: Initial Capabilities Document\ MDD: Materiel Development Decision O&S: Operations & Support

JCIDS Approaches for Identifying DoD Capability Gaps
Include but not limited to: Operational Planning CBAs & Other Studies Exercise & Warfighting Lessons Learned JCTDs, JUONs, JEONs, & Other Experiments Joint IED Defeat Transitions Packets DBS Business Case Documents CBA: Capabilities-Base Assessment DBS: Defense Business Systems JCTD: Joint Capability Technology Demonstration JEON: Joint Emergent Operational Need JUON: Joint Urgent Operational Need

DoD Capability Analysis Outputs
Regardless of the approach used, primary output needs to describe: Mission & military problem Prior CBAs, studies, & other applicable analyses Tasks, performance standards, & conditions to meet the mission Capabilities needed to meet the mission (using one or more JCAs) Capability gaps & redundancies between the capability requirements & current or programmed force structure Operational risk for each capability gap not addressed Non-materiel & materiel approaches that would satisfy part or all of these capability gaps Recommendations for the most appropriate approach to close the capability gaps and reduce operational risk Fundamental goal: recommend action or accept risk JCA: Joint Capability Area

Three “Lanes” to Meet Warfighter Needs
“Keep right, except to pass” D E L I B R A T M G N U 0 – 2 YRS 0+ to 5 YRS CONFLICT LANE ONLY POTENTIAL 2-6+

Lane #1: The Deliberate Process
Deliberate Requirements Service, CCMD or Agency-driven Traditional route for capabilities that need significant tech development and/or are not urgent or compelling in nature “Keep right, except to pass” 0 – 2 YRS 0+ to 5 YRS 2-6+ YRS U R G E N T E M R G N T D E L I B R A T JRAC addresses Lanes #2 & #3 later this week… CONFLICT LANE ONLY POTENTIAL CONFLICT LANE

Fundamental goal is to recommend action or accept risk
Solving Gaps Paths to solving capability gaps GFM: for materiel (“little m”) approach available in Joint Force DCR: for materiel (“little m”) organic Joint Force approach or non-materiel approach ICD: when both materiel (“big M”) and non-materiel approach is needed CBA is the “typical” analytical basis to identify needed capabilities & associated capability gaps Recapitalization, replacement, & IS: NLT 90 days More complex or new mission area: NLT 180 days No extensive detail or pre-determined solution Fundamental goal is to recommend action or accept risk CBA: Capabilities-Base Assessment DCR: DOTmLPF-P Change Recommendation GFM: Global Force Management IS: Information Systems

Operational Planning (& Execution)
OPLANs & CONPLANs – CCMD roles, missions, & forces Ongoing Operations (execution): Could be JUON or component urgent need process Potential mission failure or unacceptable loss of life (now…) Anticipated Operations (planning): Could be JEON or component urgent need process Potential mission failure or unacceptable loss of life (should operations begin soon…) “If operations were to begin tomorrow, would the unfulfilled JEON then turn into a JUON?” CCMD: Combatant Command CONPLAN: Concept Plan OPLAN: Operation Plan

Other Analytical Approaches
CJCSI , Joint Lessons Learned Program Documentation reflects operational utility May lead to further analyses (CBA trigger?) & development of JCIDS documents for staffing Joint IED Defeat Transition Package Used as a source document for the CDD & CPD - JROC approval & transition to program of record (POR) JCTD – Joint Capability Technology Demonstration Only after a sufficient assessment of operational utility Outlined in JCTD website: Prototypes Used to address JUONs & JEONs (FITE) (IED robot with Tanglefoot) (JLTV)

JUONs, JEONs, & Other Experimentation
(Scan Eagle) JUON – Joint Urgent Operational Need (or component urgent needs process) May enter JCIDS without an ICD Uploaded to KM/DS JEON – Joint Emergent Operational Need (or component urgent needs process) Joint Experimentation Sufficient assessment of operational utility Outlined in CJCSI C, Joint Concept Development and Experimentation (JCD&E) NEW KM/DS: Knowledge Management/Decision Support

DBS – Business Case Documents
Information Systems (IS) that are NOT part of a weapon system NOT directly involved in military or intel missions Validated by DBSMC Uses a business case document Employs Business Capability Lifecycle (BCL) process in lieu of an ICD & CDD Still uploaded to KM/DS If joint oversight required, case document used for staffing & validation Outlined in AT&L DTM, , Acquisition Policy for Defense Business Systems (DBS), 23 Jun 2011 Lesson Learned for all these approaches: good documentation vital when using these alternatives… BCL: Business Capability Lifecycle DBSMC: Defense Business Systems Management Committee

CBA Overview CBA: Initiated by: Becomes basis for:
Validating capability needs DoD Sponsor CBA: Typical analytic basis of JCIDS Based upon: Recommends: Joint Concepts Endorsed CONOPS Formally- tasked OPLANS and CONPLANs ACTION w/o excessive rigor ISCs CCJO: Capstone Concept for Joint Operations CONPLAN: Concept Plan ISC: Integrated Security Constructs OPLAN: Operation Plan

CBA to MDD JCIDS Acq Capability Identification Requirements
ID tasks, performance, & conditions “What’s the military problem” MDD “Bridge” ID capability gaps & redundancies “Analyze the programmed force structure & doctrinal approaches” ID possible non-materiel & materiel solutions “Address gaps or accept risk” Seam Between Capabilities & Acquisition ICD AoA JCIDS Acq Capability Identification Requirements Development Conduct of a CBA

JCIDS CBA Steps Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7
Identify Military Problem Step 1 Step 2 Step 3 Step 4 Identify Military Concepts Identify Study Scope Identify Previous Studies Determine Study Scope Identify Needed Capabilities Identify Capability Gaps Identify Military Risks Identify Time-frame Admin: Post to KM/DS Studies Repository Step 5 Step 6 Step 7 Identify Non-Materiel Approaches Assess Materiel Approaches Make Recommendations Study Initiation Notice Termination Memo (if study terminated) Study Results

CBA Lit Search: Strategic Guidance
QDR CRA QDR NSHS NSS NSS NDS NDS NMS NMS CBA: Typical JCIDS analysis UCP JSCP UCP JSCP Classified Guidance GEF DPG GEF DPPG CRA: Chairman’s Risk Assessment QDR: Quadrennial Defense Review NSS: National Security Strategy NDS: National Defense Strategy NMS: National Military Strategy NSHS: National Strategy for Homeland Security UCP: Unified Command Plan GEF: Guidance on Employment of the Force DPG: Defense Planning Guidance JSCP: Joint Strategic Capabilities Plan

CBA Lit Search: Conceptual Guidance
Joint Concepts Legacy Docs: JOAC, JOE, JOC, JIC, Etc… CJCSI C JCD&E* J7 - JCCD CBA: Typical analytical basis of JCIDS JCA JCA Posted at J7 JCCD website - JCCD is responsible for developing conceptual solutions to a Combatant Commander or Service Chiefs expected challenges and then evaluate potential solutions to those challenges through joint experimentation. JCCD: Joint Capabilities to Concept Division JCD&E: Joint Concept Development & Experimentation CCJO: Capstone Concept for Joint Operations JIC: Joint Integrating Concept JCA: Joint Capability Area JOC: Joint Operating Concept JOAC: Joint Operational Access Concept JOE: Joint Operating Environment

CBA Framework: Nine JCAs & Six FCBs
JCA Definition: “…currently the preferred method the DoD uses for reviewing and managing capabilities.” “Collections of like DoD capabilities functionally grouped to support capability analysis…” First proposed in 2003 (21), tiered as far as five levels: Updated Structure: JCA # Name FCB Sponsor 1 Force Support Same J-8 2 Battlespace Awareness Same J-2 3 Force Application Same J-8 4 Logistics Same J-4 5 C4 C4/Cyber J-6 6 Cyber C4/Cyber J-6 7 Protection Same J-8 8 Building Partnerships NA J-5 9 Corporate Management NA J-5

Sample JCA & Tiering 2 Battlespace Awareness – The ability to understand dispositions and intentions as well as the characteristics and conditions of the operational environment that bear on national and military decision-making. 2.1 Intelligence, Surveillance and Reconnaissance – The ability to conduct activities to meet the intelligence needs of national and military decision-makers Intelligence, Surveillance and Reconnaissance Planning and Direction – The ability to synchronize and integrate the activities of collection, processing, exploitation, analysis and dissemination resources to meet information requirements of national and military decision-makers Define and Prioritize Intelligence, Surveillance and Reconnaissance Requirements – The ability to translate national through tactical objectives and needs into specific information and operational requirements for ISR. … 2.2 Environment – The ability to characterize and exploit the meteorological, space and oceanographic information from the sub-bottom of the earth’s oceans up to and including space.

1st Recommendation: Non-Materiel Approaches
Doctrine Facilities Leadership & Education Organization Policy Personnel Training DCR DOTmLPF - P Change Recommendation

2nd Recommendation: Materiel Approaches
Development & Fielding of Information Systems Or similar technologies with high obsolescence rates Evolution of existing capabilities Evolution of Existing Systems Provide significant capability improvement Replacing existing system with more capable system Simple recapitalization Transformational Systems Differ significantly in form, function, operation & capabilities Significant improvement over current capability Transforms how we accomplish mission

Sources: CJCSI H, 10 Jan 2012 JCIDS Manual, 19 Jan 2012 Joint Staff, J-8, RMD

Assumptions DOD’s three decision support system communities agree that: Developing IS is fundamentally different from weapon systems DAS & PPBE change their process & documentation expectations accordingly (DODI …) Test & Cert communities can deliver faster – enabling faster delivery of IS capabilities Necessitates incremental/iterative development and testing Push requirements validation authority down to the lowest level Currently within JROC authority IS: Information Systems IT: Information Technology

Rationale for More Change
JCIDS process and documents geared to major hardware weapon systems Rapid pace of IS development not supported by JCIDS & documents Previous JCIDS Manual Enclosure C (IT Box process) was a good starting point to address a more agile and responsive process, but requires adjustment – Modified IT Box Along with acquisition, JCIDS process needs to change New capabilities can be delivered faster – and adapted faster – to cope with changes in the operational environment Desired Outcome: More agile capabilities & requirements process to enable rapid development of IS capabilities

Applicability of the IT Box
IT box applies to: Software development only (w/some adapted HW) Includes integration onto COTS hardware Program costs ≥ $15 million IT box DOES NOT apply to: DBS, programs < $15 million Weapon system IS Expands on JROCM with the “IS ICD” - greater flexibility & alignment with: Sec. 804, NDAA 2010 (Develop new approach for delivering IT capabilities) Sec. 933, NDAA 2011 (Develop strategy for rapid acquisition of tools, applications, and other capabilities for cyber warfare) Planned update to DoDI

Presentation Template
Applications & System Software Development & Acquisition Requirements Organization & Oversight Capabilities Required $ Hardware Refresh & System Enhancements & Integration JROC Approved IS ICD Key Points: Describe the overall bounds of an IS program to reduce return trips to the JROC Provide to FCB/JCB/JROC as part of the approval process for an IS program’s ICD Only applies to programs that do not need to develop hardware systems (leveraging COTS/GOTS hardware) Once ICD is approved, no need to return to the JROC with a CDD or CPD unless… The IS ICD results in an MDAP

Governance Requirements Organization And Oversight: Guidance:
Determines schedule & content of capability releases based upon collaboration between users and the program manager Guidance: Name the flag-level body holding authority over and governance for requirements Identify chair Identify represented organizations, including all stakeholders. Include the acquisition community to provide advice on cost, schedule, & technical feasibility Applications & System Software Development & Acquisition Requirements Organization & Oversight Capabilities Required $ Hardware Refresh & System Enhancements & Integration JROC Approved IS ICD

Validated Capability Requirements And Initial Minimum Levels:
Key Performance Parameters (KPP); Application & System Software Development and Acquisition Applications & System Software Development & Acquisition Requirements Organization & Oversight Capabilities Required $ Hardware Refresh & System Enhancements & Integration JROC Approved IS ICD Validated Capability Requirements And Initial Minimum Levels: The initial minimum performance levels required for the entire IS program. Objective values not required nor briefed. Application and System Software Development and Acquisition: Estimated development and integration costs for the lifetime of the program. Break out costs into annual estimates RDT&E dollars

Hardware Refresh & System Enhancements
Applications & System Software Development & Acquisition Requirements Organization & Oversight Capabilities Required $ Hardware Refresh & System Enhancements & Integration JROC Approved IS ICD Hardware Refresh and System Enhancements & Integration: Estimated sustainment costs over the life cycle of the program. Break out costs into annual estimates O&M dollars.

Information System (IS) ICD
IS ICDs implement the IT Box Model Required when solution reaches R&D, & acquisition of applications cost over $15 Million Not Used for Software Embedded as a Subset of a Capability Solution Developed IAW Other Validated JCIDS Documents IS ICD Applies to: Commercial off the Shelf (COTS)/Government off the Shelf (GOTS) software, and associated hardware without modification Commercial capability solutions with integrated, DoD-specific performance standards Additional production or modification of previously developed U.S and/or Allied or interagency systems or equipment Development, integration, and acquisition of customized application software “IT Box” model calls for fewer iterations of validating documents through the JCIDS process by describing the overall IS program in the IS ICD, and delegating validation of detailed follow-on requirement and solution oversight to a flag-level organization other than the JROC or JCB.

IS ICD (Con’t) CDDs & CPDs are not required as successor documents
Sponsors have mgmt flexibility for alternate documents JCIDS Manual provides examples of potential IS ICD follow-on documents (Actual Names, Content, and Approval TBD by the Delegated Validation Authority): Requirements Definition Package (RDP) – identifies KPPs and non-materiel changes Capability Drop (CD) – lower level document that specifies the characteristics of a “widget” or “app” for partial deployment of the solution Sponsor briefs FCB every 2nd yr after validation May recommend JROC oversight Business IS not normally subject to JROC Review – however, if FCB decides “joint equities” apply, can recommend joint oversight.

Example: Integrated Strategic Planning & Analysis (ISPAN)
Organization & Oversight Flag-level oversight through ISPAN Requirements Governing Council (IRGC) Chair: GS/CD Members: ESC SPM, USSTRATCOM CIO GS COS, J2, J3, J5, J6 HQ J63, J82, J83 Key Performance Parameters KPP #1 - 4: define mission planning capabilities required services and critical user access devices: 0.99 KPP # 5, 7, and 8 – define material availability/quality of service performance KPP #6 Net-Ready requirement “Boundaries” JROC-Approved ISPAN Oversight – ASD(NII) Execute – AF/PEO ESC Hardware Refresh & System Enhancements & Integration Per year (FY04-20) = $22.8M (TY) Lifecycle cost = $387.3M (TY) Per FY = $355.8M average/yr Application and Systems Software Development Per year (FY04-20 = $54.7M (TY) Lifecycle cost = $929.9M (TY)

Lessons Learned/ Working Issues
KPPs in IT program CDDs should be briefed with “Initial Minimums” only vice traditional Thresholds/Objectives. PAUC/APUC don’t apply to IT acquisition; use different metric. For incremental acquisition, ensure IT box describes entire IT program and not just a single increment (if possible). Working Issues: Tie-in IT box (requirements piece) with on-gong DOD IT acquisition reform efforts (directed by FY 2010 NDAA)

IT Box Bottom Line The IT box is the right thing to do for IT programs
Provides required flexibility for IT program success Allows more effective support to the Warfighter High-level guidance and agreement VCJCS, JROC, DOD CIO Supports FY 2010 NDAA: “The Secretary of Defense shall develop and implement a new acquisition process for IT systems …. Based on recommendations for the DSB Task Force on Acquisition of IT.” Must continue close coordination to successfully implement IT box

Capability Development Tracking and Management (CDTM)
IT system that transforms JCIDS capability tracking from document-centric to data-centric process Developed and deployed on NIPRNet and SIPRNet 30 June 2011 (since relaxed) mandated CDTM use for all JCIDS documents (ICD, CDD, CPD, DCR) Capability gap traceability Process metrics Ease of use enhancements Improved search capability Improved document creation Input standardization Ability to data share with other DoD applications

Capability Requirements Analysis Bottom Line
AoA Sound Analysis - Findings & Recommendations: vital for the foundation of a successful acquisition These same results then support which analytical document? Materiel Solution Analysis (MSA) Phase Starts & supports which acquisition phase? Materiel Development Decision (MDD) Supports which decision? Initial Capabilities Document (ICD) Support which document? Results & Recommendations

What an RM Needs to Take Away From This Lesson
Pre-MDD analysis is vital to underpinning the ICD Ensure whatever approach you use effectively scopes the analysis needed CBAs: days, use representative scenarios from the ISC & a realistic timeframe for delivery of the capability Align all capability requirements to prioritized JCAs Use CDTM to develop ICD for correct format and length Recommend appropriate actions to mitigate gaps Accept risk Non-materiel Materiel

Sources for More Pre-MDD Capability Requirements Analysis Information
JCIDS Intellipedia site: CJSCI H, JCIDS, 10 Jan 2012 CJCSI F, JROC Charter, 10 Jan 2012 JCIDS Manual, 19 Jan 2012 (& errata) JCIDS Process Flowchart, 19 Jan 2012 DAU online course CLR 250, Capability-Based Assessments: General CBA overview – more detailed than RQM 310 – access via browse mode DAU Community of Practice (CoP): DTM site

Backups

IT Box Background Why implement an IT box? Moore’s Law: JROCM 008-08
“The number of transistors on an integrated circuit doubles approximately every months.” The US has been able to leverage rapidly-evolving IT for decisive military advantage. However, the JCIDS process does not provide the required flexibility to take full advantage of evolving commercial information technology. JROCM The JROC wants to ensure the IT programs have the flexibility to “plan for and incorporate evolving technology” throughout the program’s lifecycle. CJCSI H Expands on the concepts in JROCM JROCM 00808, 14 Jan 2008, directed changes to the JCIDS process to ensure Information Technology systems have the appropriate flexibility and oversight to plan for and incorporate evolving Technology. The “IT Box” process to implement this JROCM first appeared in the March 2009 JCID Manual. The 19 Jan 2012 JCIDS Manual provides a major update to the IT Box process.

JROCM Detail Define minimum capability levels based upon what is achievable with today’s technology. (IS ICD paragraph 4 and JROC briefing) Describe process for approving capability enhancements. Who will have the authority to manage requirements? (JROC Briefing) Describe the plan for delivering capability (JROC briefing): How often will releases of new or enhanced capability be delivered? What is the plan for assessing the application of new technologies? What is the plan for technology refresh? Identify the level of effort funding which will be used for the software development effort. (IS ICD paragraph 4 and JROC briefing) The bullets are a direct lift from page 2 of the 2 page JROCM.

Requirements Definition Packages (RDPs)
RDPs are not a JCIDS document Created to break down the requirements into deliverable increments Responsive, nimble, focused - SPEED Provides a more detailed definition of one or more capabilities in the ICD Enables detailed design activity Enables detailed costing of the requirements Formal incorporation into JCIDS will link to the acquisition and programming processes Approved by the delegated Requirements Management authority FO/GO-level body that holds authority over, and provides governance for requirements Two document types have been created in the JCIDS Manual. The Requirements Definition Package (RDP) and the Capability Drop (CD). Actual names, content and approval process are to be determined by the delegated validation authority. The RDP is a first level decomposition of one or more capability requirements in the IS ICD, and is co-developed between the operational user (or representative) and the program office. One or more RDPs together would represent the total set of capability solutions developed to satisfy the capability requirements in the IS ICD. The RDP identifies KPPs (including the NR-KPP), Key System Attributes (KSAs), and/or additional performance parameters as necessary to scope and cost a specific solution implementation. The RDP may also identify non-materiel changes that need to be implemented to fully realize the IS capability. The RDP would be supported by an Information Support Plan (ISP), submitted separately to DOD CIO for certification purposes. This would be equivalent to CDD as defined in the typical JCIDS process, and would be approved by the delegated validation authority identified in the IS ICD. A draft RDP could be used before validation to support MS A decisions for IS technology/ prototyping efforts. The RDP would be submitted to the delegated validation authority for validation ahead of a MS B decision. Following validation, the RDP would be posted to the KM/DS system for information purposes and for visibility into the appropriate FCB portfolio. The RDP can be used to initiate an IS program to develop, test, and deliver the full capability defined in the RDP. It can also be used as a basis for defining multiple drops of incremental capabilities such as “apps” or “widgets” which could be documented in something like a CD.

Capability Drops (CDs)
CDs Are Not a JCIDS Document Managing delivery of capabilities through more specifically defined subsets of an RDP The details of how to do this are left to the components and the acquisition process The RDP is Further Broken Down into CDs to Deliver Individual “Widgets” or “Slices” of Capability The Results of the CD Development are Released Incrementally Through Full Deployment Decisions as They Are Ready Approved by the Delegated Requirements Management Authority and the Component PM lead The CD could be a much lower level document to specify the detailed characteristics of a “widget” or “app” necessary for partial deployment of the capability solution. It could be developed through a rapid prototyping effort with the user to ensure it meets their needs. A CD could be developed directly from the definitions in the ICD in the event of a more urgent need for the capability. More commonly, multiple CDs would be derived from an RDP to deliver all of the capabilities defined in the RDP. The CD should include information such as a detailed technical description of the capabilities provided by a “widget” or “app” that can be developed and fielded within a short period of time, along with specific technical performance requirements. If not already covered by the ISP approved for the RDP, the CD is supported by a separately submitted ISP for CIO certification purposes. The approval of CDs would most likely be delegated to a lower level requirements authority as determined by the RDP authority to ensure timely decision making. Deployment decisions are made whenever the product – whether from an RDP or a CD - is ready for deployment to the user.

IS Requirements/Acquisition Process
CD RDP IS ICD JROC Approved Capabilities Based Assessment MS B O&S Engineering Analysis/ Design MDD (NF) Rapid Delivery Fielding Decisions Agile Development Component Specific implementation guidance on document content and approval process to be provided by Component Acquire Decision

Requirements/Acquisition Process (con’t)
Full Deployment Decisions MDD MS A/B Capabilities Based Assessment ICD (NF) Engineering Analysis/ Design RDP CD CD CD CD CD CD CD CD CD Strategic Guidance Joint Concepts O&S Agile Development Rapid Delivery IOC This shows a very streamlined process for truly agile IS development The ICD is developed in a new format tailored to IS capabilities Following the MDD, one or more RDPs are developed to further refine the requirements for the needed capabilities The RDP is further broken down into CDs to deliver individual “widgets” of capability The results of the CD development are released incrementally through Full Deployment Decisions

Execution of the IT Box Process
Execution will vary depending on whether this is a new set of capabilities or whether capabilities are being added to an existing IS capability set A new set of capabilities is initiated through a new IS ICD Adding capabilities to an existing system may enter at any stage along the process In many cases, an update to an existing RDP is all that is required A major expansion of capabilities may require a new IS ICD Modifying or enhancing existing capabilities should only require a mod or a new CD to document what is needed There may be cases where the mod or enhancement has impact on the architectures or data and this will require a mod to the RDP to fully document the change Managed by the requirements management authority

Key Performance Parameter
Net-Ready KPP Example Attribute 1. Support to Military Operations NR-KPP Attribute Key Performance Parameter Threshold Objective Support to military operations Mission: Tracking and locating (Finding, Fixing, Finishing) High- Value Target (HVT) Measure: Timely, actionable dissemination of acquisition data for HVT Conditions: Targeting quality data to the neutralizing/ tracking entity 10 minutes Area denial of HVT activities Near-real-time HVT tracked, neutralized Mission Activities: Find HVT Measure: Location accuracy Conditions: Individual differentiation 100 meter circle Identify armed/ not armed 25 meter circle Identify individual

Net-Ready KPP Example Attribute 2. Enter and Be Managed in the Network NR-KPP Attribute Key Performance Parameter Threshold Objective Enter and be managed in the network Network: SIPRNET Measure: Time to connect to an operational network from power up Conditions: Network connectivity 2 minutes 99.8 1 minute 99.9 Network: NIPRNET

Net-Ready KPP Example Attribute 3. Exchange Information NR-KPP Attribute Key Performance Parameter Threshold Objective Exchange information Information Element: Target Data Measure: Dissemination of HVT biographic and physical data Measure: Receipt of HVT data Measure: Latency of data Measure: Strength of encryption Conditions: Tactical/Geopolitical 10 seconds Line of Sight (LOS) 5 seconds NSA certified type 1 Permissive environment Beyond LOS 2 seconds Non-permissive environment

IT Box Cost Driver Quad Chart
Performance (KPPS & Select KSAs) KPP 1 | | | KPP 2 | | | KPP 3 | | | KSA 4 | | | KSA 5 | | | N IM O Top Cost Drivers A, % of program cost B, % of program cost C, % of program cost D, % of program cost E, % of program cost Y G G G R N = No capability IM = Initial Minimum O = Objective Acquisition Program Baseline (APB) Technology Readiness Assessment Baseline Cost | | | - Life-cycle cost - Current Est | | | (DAES Report) Schedule - IOC or FOC | | | - Next Major Event | | Critical Technologies Critical Assessment Next Milestone Technology A TRL # Technology B Technology C Technology D Technology E Technology F G G +15% +25% G Y +6 mo +1 yr MS B Date: M/Yr MS C Date: M/YR (Note: Aligns with MAIS reporting Tripwires in Ch 144A, FY07 NDAA)

Example JROCM – Consolidated Afloat Networks & Enterprise Services (CANES)
Delegates change authority for non-key performance parameters to the Navy Program oversight for CANES delegated to the Navy led Information Technology Management Council (ITMS) ITMC may approve spiral developments as long a all initial KPPs and funding constraints are not exceeded The CANES program recapitalizes the Navy's afloat network infrastructure (see note below) by consolidation of diverse physical networks into a secure, modular and scalable Common Computing Environment (CCE) and software environments augmented with state of the shelf Cross Domain Solutions (CDS). CANES is the intended hardware and software environment upon and within which applications, services and systems will reside in the Navy tactical domain. CANES provides all security domains from Unclassified through Top Secret/Sensitive Compartmented Information (SCI) for a wide variety of Navy surface combatants, submarines, Maritime Operations Centers and aircraft. CANES enables efficient data visibility and flow within the Ship, Ship-to-Ship and Ship-to-Shore to support operational nodes on the Global Information Grid (GIG) using an open architecture. Category: ACAT IAM Sponsor: Navy Milestone Decision Authority: USD(AT&L

Pre-MDD Military Capability Analyses

Similar presentations

Presentation on theme: "Pre-MDD Military Capability Analyses"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Pre-MDD Military Capability Analyses

Similar presentations

Presentation on theme: "Pre-MDD Military Capability Analyses"— Presentation transcript:

Similar presentations

About project

Feedback