Joint Capabilities Integration and Development System (JCIDS) A Primer

Joint Capabilities Integration and Development System (JCIDS) A Primer
Sources: CJCSI I, 23 Jan 2015 CJCSI G, 15 Jan 2015 JCIDS Manual, 12 Feb 2015 with errata 15 Dec 2015 DoDI , 7 Jan 2015 Joint Staff, J-8 Patrick Wills Dean, Defense Systems Management College Defense Acquisition University work: cell: 22 Feb 2015

Topic Areas JCIDS The Requirements Environment
Three JCIDS Process Lanes Identifying Capability Requirements JCIDS Interaction With the Acquisition Process JCIDS Documents Performance Attributes Document Staffing and Validation Urgent/Emergent Threat Lanes Rapid Acquisition of Urgent Needs Guiding Principles and Challenges JCIDS supports the Chairman of the Joint Chiefs of Staff (CJCS) and the Joint Requirements Oversight Council (JROC) in identifying, assessing, and prioritizing joint military capability needs as specified in Title 10, United States Code. The overriding goal of the JCIDS process is to support the warfighter by identifying and developing capabilities consistent with the National Defense Strategy. This presentation will discuss the sequence of events that turns warfighters’ needs into capability requirements and the subsequent capability requirements into action that provides solutions. This sequence begins with analysis. The analysis is documented in documents like Initial Capabilities Documents (ICDs) and non-materiel change recommendations, called DOTmLPF-P Change Recommendations (DCRs). When the JCIDS process determines that DoD needs to develop new materiel solutions, the JCIDS capability requirements process must interact with the Defense Acquisition System (DAS) and the Planning, Programming, Budgeting, and Execution (PPBE) process to provide effective solutions. JCIDS requirements are “approved” via a validation process. The validation authority depends on the potential Acquisition Category (ACAT), interoperability requirements, and Joint Staff equities. Some capability requirements are urgently needed for ongoing or anticipated contingency operations. These requirements follow urgent needs lanes to deliver solutions to the warfighter.

The Requirements Environment
Finding the balance between: Combatant Command (CCMD) near-term requirements to support Contingency Plans and current missions and Services’ long range vision & investment plans Versatile, joint systems Systems optimized for service missions Growing demands Fiscal & political constraints Geographic specificity Worldwide applicability Ambitious requirements Achievable acquisition strategy Quantity matters High-end capabilities

Joint Capabilities Integration and Development System (JCIDS)
The Goal of JCIDS is to… Provide the Joint Force with the capabilities needed to perform across the full range of military operations and challenges Support the JROC in its Title 10 responsibilities Cost, schedule, performance trades Prioritizing joint military requirements in shaping the force Supported by… Integrated, collaborative review process Leveraged expertise of all government agencies Joint Operations Concepts The JCIDS process exists to support JROC and CJCS responsibilities in identifying, assessing, validating, and prioritizing joint military capability requirements. JCIDS provides a transparent process that allows the JROC to balance joint equities and make informed decisions on validation and prioritization of capability requirements. Services, Combatant Commands, and other DOD Components with delegated validation authority will use variations of the JCIDS process within their organizations to validate capability requirements JCIDS (capability requirements and non-materiel solutions), Defense Acquisition System (DAS) (materiel solutions), and PPBE (resources) are three key processes in DOD which must work in concert to ensure consistent decision making while delivering timely and cost effective capability solutions to the Warfighters. Together, the three processes provide a means to determine, validate, and prioritize capability requirements and associated capability gaps and risks, and then fund, develop, and field non-materiel and materiel capability solutions for the Warfighter in a timely manner. JCIDS along with the Defense Acquisition System and the Planning, Programming, Budgeting and Execution process form the principal DOD decision support processes for developing and acquiring capabilities required by the military forces to support the national defense strategy

JCIDS – The Central Process For Capability Solutions
Requirements development often begins with warfighter feedback. Typical capabilities- based assessment steps are: 1) Set the strategic stage, 2) Set priorities, and 3) Identify needs and solutions. Once CBA identifies needs and potential solutions, the sponsors working within the PPBE and Defense Acquisition System (DAS) provide materiel solutions to augment fielded capabilities. Non-materiel solutions are worked through oversight by the sponsor – and many need funding through the PPBE process. A major goal of the JCIDS capability requirements process is to support the warfighter by moving capabilities through the “Big A” processes (JCIDS, PPBE and DAS). JCIDS also provides for an “urgent operational needs” process to rapidly field capability needed by Combatant Commands for ongoing or anticipated contingency operations.

The “Capability Matrix Lattice” (CML) is an integrating construct to ensure traceability to strategic guidance, missions of the Joint force, and other departmental activities. Strategic Guidance. Guidance from many sources influences military operations, intelligence activities, development and validation of capability requirements, acquisition activities, and DOTmLPF-P associated with organizing, training, and equipping forces. It also influences the budgetary process which provides funding for all of these activities. Missions/ Planning/Operations. Current and planned operations, as well as other roles, missions, and functions which direct an ability to perform certain activities, are the most direct driver of capability requirements, in the context of the strategic guidance and threats/intelligence. Threats/Conditions. Intelligence activities identify and quantify threats which may drive or impact military operations, and the level of effectiveness needed to perform the Universal Joint Tasks, thus inform the setting of performance levels in capability requirements. Capability Requirements (Portfolio Management). Based upon strategic guidance, threats/intelligence, and military operations, the JROC, or an independent validation authority, reviews and validates proposed new capability requirements and performs periodic assessments of the capability requirement portfolios. Capability Solutions (Materiel and Non-Materiel. There is generally a many-to-many mapping between validated capability requirements and capability solutions, requiring both materiel and non-materiel solutions to address a single requirement. A single multifunction system, with its associated DOTmLPF-P enablers, may also address many capability requirements across multiple capability requirement portfolios. Force Elements (Readiness). The force providers – Services, US Special Operations Command (USSOCOM), and Combat Support Agencies (CSAs) – organize, train and equip using the materiel and non-materiel capability solutions available to provide ready forces to the CCMDs via the Global Force Management (GFM) process. Resources/Investment. Execution of the processes or activities in all areas requires appropriate funding. The best justified justification for resources is toby being able to articulate the interactions and traceability between each area of the CML, and how the resources buy down risk in capability, quantity, and/or readiness under specific mission/threat conditions.

Three JCIDS Process “Lanes”
Ongoing Contingency Lane - Urgent Threat Urgent need to prevent loss of life and/or mission failure during current operations Requires little tech development and can be resolved in less than two years CCMD Driven. J-8 Deputy Director for Requirements (DDR) validates Anticipated Contingency Lane - Emergent Threat Accelerated acquisition needed for an anticipated or pending contingency operation CCMD Driven, VCJCS verifies, JCB or JROC validates Normal Lane - Deliberate Planning Service, CCMD or Agency Driven. Traditional route for capabilities that require significant tech development and/or are not urgent or compelling in nature Ongoing Contingency Lane. Urgent Threat Timeline. Planning for ongoing contingency operations may identify urgent operational needs (UONs) which represent potential for critical mission failure or unacceptable loss of life if not satisfied by a rapidly acquired capability solution. These capability requirements may qualify for submission as Joint UONs (JUONs) or DOD Component UONs for expedited validation and rapid acquisition efforts. Anticipated Contingency Lane. Emergent Threat Timeline. Planning for anticipated contingency operations may identify operational needs which represent potential mission failure or unacceptable loss of life once operations commence, if not satisfied by a rapidly acquired capability solution. These capability requirements may qualify for submission as Joint Emergent Operational Needs (JEONs) or DOD Component UONs for expedited validation and rapid acquisition efforts. Normal Lane. Deliberate Planning. The Deliberate Planning process is characterized by the traditional route to identifying capability gaps and proposed solutions – the CBA process, documenting the CBA results in an ICD and/or DCR, and proceeding to a Materiel Development Decision and an Analysis of Alternatives to support a materiel solution decision. This is followed by prototyping, design, development and production.

The Normal Lane Normal Lane - Deliberate Planning
Service, CCMD or Agency Driven. Traditional route for capabilities that require significant tech development and/or are not urgent or compelling in nature The next series of charts deal with the normal lane Normal Lane. The deliberate process is characterized by the traditional route to identifying capability gaps and proposed solutions – the CBA process, documenting the CBA results in an ICD and/or DCR, and proceeding to a Materiel Development Decision and an Analysis of Alternatives to support a materiel solution decision. This is followed by prototyping, design, development and production. The next series of charts discuss the deliberate process.

JCIDS and Acquisition Getting The Front End Right is Key
This chart describes the end-to-end process starting with guidance and concept development, through capability identification and the handoff to the acquisition process where new materiel systems are acquired and fielded. JCIDS provides for a various methods to identify capability requirements. These methods and expected outputs are shown in the upper portion of the large purple box. Some of these methods, such as Joint Capability Technology Demonstrations (JCTDs), Joint Urgent Operational Needs (JUON), Joint Emergent Operational Needs (JEON) are moved rapidly to the right and may bypass some of the acquisition phases of development and move into production. These are mature technology projects and/or commercial-off-the-shelf (COTS), or non-developmental military hardware available without further development. A more traditional process involves a Capabilities-Based Assessment (CBA) or other study to identify capability gaps and potential solutions. Some of the key activities of the acquisition process are listed above each acquisition phase. JROC validation of capability requirements for potential ACAT I and ACAT IA programs is also shown. Other validation authorities for ACAT II and below are the Joint Capabilities Board (JCB) and the Sponsor organizations (departments and agencies). Regardless of the method used to identify capability requirements, the “front end” analysis/assessment is key to ensuring going forward thru the JCIDS, acquisition and PPBE processes, that the identified capability requirements meet the needs of the warfighter in a timely manner and at an affordable cost Getting The Front End Right is Key

Identification of Capability Requirements and Associated Capability Gaps
Goal. To derive and refine capability requirements and associated capability gaps – for which a capability solution must be provided either organically or leveraged through the joint force – to accomplish assigned functions, roles, missions, and operations. Certified Requirements Managers. Sponsors will use certified requirements managers to monitor and evaluate capability requirement identification, including but not limited to the identification of capability gaps due to changes in threats, missions, or aging of legacy weapon systems throughout their life cycle. Relation to Functions, Roles, Missions, and Operations. Before any action can be taken in the JCIDS process related to reviewing and validating capability requirement documents, Sponsors must first identify capability requirements related to their functions, roles, missions, and operations. Fundamental goal. The fundamental goal of any approach outlined in the JCIDS Manual is for a Sponsor to derive and refine capability requirements and associated capability gaps – for which a capability solution must be provided either organically or leveraged through the joint force – to accomplish assigned functions, roles, missions, and operations. Training Mandate. In accordance with Public Law , Section 801, members of the Armed Forces and employees of DOD with authority to generate capability requirements must successfully complete a DOD Component certification training program, including training courses executed by the Defense Acquisition University (DAU) as outlined in the JCIDS Manual, Enclosure A. Functions, Roles, Missions and Operations. While Sponsor activities may examine various aspects of their capability requirements in significant levels of detail, the key for JCIDS is to identify the high level operational capability requirements, establish quantifiable attributes and metrics, and articulate the traceability from those capability requirements to the Sponsor’s functions, roles missions, and operations.

Approaches to Identifying Capability Requirements
Capabilities-Based Assessments (CBAs) & Other Studies Operational Planning Exercises/Warfighting Lessons Learned Joint Capability Technology Demonstrations (JCTDs) and Other Experiments Transition of Rapidly Fielded Capability Solutions Joint Urgent Operational Needs (JUONs), Joint Emergent Operational Needs (JEONs), and DOD Component Urgent Operational Needs (UONs) Joint Improvised Explosive Device Defeat Organization (JIEDDO) Initiatives Business Process Reengineering The CBA is an analytic basis to identify capability requirements and associated capability gaps. Other forms of studies, analyses, or assessments may be used, but may need refinement to ensure sufficient data to properly generate capability requirement documents. Development of OPLANs and CONPLANs is a means to identify capability requirements related to CCMD roles and missions and the assignment or attachment of forces. Warfighting and exercise lessons learned may serve as a basis to establish capability requirements, if the documentation indicates sufficient military utility of a certain capability. Lessons Learned may lead to further analysis and development of JCIDS documents for validation in the deliberate or urgent/emergent staffing processes. JCTDs or other prototypes may serve as a basis to establish capability requirements, if an assessment indicates sufficient military utility of a demonstrated solution. Successful solutions for JUONs, JEONs, and DOD Component UONs may serve as a basis for transitioning capability requirements for sustainment and/or further development if they have a positive assessment of operational utility documented by the requirement Sponsor. A JIEDDO Transition Packet will be used as the source document for developing a Capability Development Document (CDD) or Capability Production Document (CPD) for subsequent review and validation, and transition to a program of record. Business Process Reengineering. Information Systems, other than a national security system, operated by, for, or on behalf of the DOD, such as financial, logistics, and human resource management systems are Defense Business Systems (DBS). DBS are validated by the Investment Review Board (IRB) under the guidance of the DBS Management Committee. DBS employ Problem Statements and Business Case documents in lieu of ICDs and CDDs.

Primary Outputs of Approaches to Identify Capability Requirements
Mission Description & Problem Being Assessed Identification & Assessment of Prior Studies Identification of Tasks Required to Meet Mission Objectives Identification of Capability Requirements Within One or More Joint Capability Areas (JCAs) Assessment of Capability Gaps Between identified requirements and current or programmed joint force capabilities Assessment of Operational Risks Evaluation of Possible Non-Materiel & Materiel Approaches to Close or Mitigate Gaps Evaluation of Current and Potential Future Science & Technology (S&T) Efforts Recommendations The fundamental goal of each approach to identifying capability requirements is to derive and refine the capability requirements – either organically or leveraged through the Joint force – necessary to accomplish their assigned functions, roles, missions, and operations. Primary outputs include those shown on this chart. For each identified capability requirement, Sponsors then compare them to current and programmed future capability solutions, if any, to determine if there are any capability gaps which present an unacceptable level of risk and warrant further development of materiel or non-materiel capability solutions to mitigate or eliminate the capability gaps. Each approach for identifying capability requirements should not presuppose a specific capability solution or end item, but provide data related to forms and functions of potential solutions to support the development of JCIDS documents. The final recommendations should include a focused and concise summary of the justification for the proposed action.

Capabilities-Based Assessment (CBA)
Existing Guidance What we need for the mission NEEDS The problems and the risks GAPS What should we do about it? SOLUTIONS Where does this need rank? How soon do we need it? This chart illustrates the relationship between the three major analyses within a Capabilities-Based Assessment (CBA). The initiation, termination, and study results are required to be posted to the Joint Staff’s Knowledge Management/Decision Support (KM/DS) tool’s study repository for visibility to other stakeholders who may have an interest in the study results. Organizing and executing a successful CBA is a significant challenge. Joint Concepts, developed in accordance with reference g, are specifically designed to drive progress in the DOD, and satisfying the demands of strategic guidance poses significant challenges. Consequently, a CBA, particularly one aimed at a broad mission area should be conducted with a capable Joint team that can bring the necessary spectrum of expertise to bear on the problem. Needs: The mission or military problem considered by the CBA must be relevant to the needs of the defense strategy and other strategic guidance. Gaps: An operational assessment of the current and programmed force is conducted to identify the capability requirements and any associated capability gaps. Gaps are assessed in terms of risk to the mission, risk to the force (potential losses), and other important considerations such as resourcing and affects on allies. Solutions: Solutions include accepting risk and doing noting, identifying non-material approaches to wholly or partially mitigate any of the identified capability gaps, and if needed recommended materiel approaches, or a combination of non-materiel and materiel approaches. Ranking and timing of the needed solution(s) are important for resourcing and planning.

CBA Outputs CBA Documentation:
Initial Capabilities Document (ICD) Joint DOTmLPF-P* Change Recommendation (DCR) CBA Recommendations for Materiel Approaches: Evolution of previously fielded systems with significant capability improvement, to include information systems Replacement or recapitalization of previously fielded system with significant capability improvement Transformational capability solution(s) that differ significantly in form, function, operation, and capabilities from previously fielded systems Managers Must Communicate to Avoid Disconnects Over Seams Between JCIDS, Defense Acquisition System, and PPBE CBA results are documented in an ICD and/or a Joint DCR. The CBA can offer new solutions that transform the battlefield into areas we can dominate. For example, developing nuclear weapons and stealth technology played to our technological strengths and transformed warfare. A CBA can lead to DOTmLPF-P, non-materiel solutions that help existing systems evolve into more effective capabilities. For example, modify or improve information technology systems to be more effective in different threat environments. A CBA may recommend materiel approach(es) to resolving capability gaps, generally in three broad types: (1) Evolution of previously fielded capability solution(s) with significant capability improvement, including development and fielding of improved IS, improved components or subsystems to address high obsolescence rates, or other upgrades and product improvements. (2) Replacement or recapitalization of a previously fielded capability solution(s) with significant capability improvement. The CBA should also consider impact to retirement of previously fielded capability solution(s) as the new capability solution is brought into service, and whether quantities in the joint force should be reduced based on increases in capability. (3) Introduction of a transformational capability solution(s) that differ significantly in form, function, operation, and capabilities from previously fielded capability solution(s). They may address capability gaps associated with a new mission, or describe breakout capabilities that offer significant improvement over current capability solutions or transform the ways of accomplishing a mission. Recommendations for material solution approaches will feed an Analysis of Alternatives (AoA), which compares alternative solutions and provides the acquisition decision maker with data for an informed decision. Seams between the requirements, acquisition, and funding communities must be closely addressed by requirements and acquisition managers to reduce the risk that disconnects result in a failure to meet the warfighter’s needs. *DOTmLPF-P = Doctrine, Organization, Training, materiel, Leadership and Education, Personnel, Facilities & Policy

CBA Output Document – Joint Non-Materiel Solutions
Joint DOTmLPF-P Change Recommendation (Joint DCR) To propose joint non-materiel solutions as an alternative to, or complement of, materiel solutions Non-Materiel Solutions Alternate concepts and CONOPs Organizational and personnel alternatives to resolve gaps/mismatches between force availability and force needs Training changes that improve effectiveness of existing capabilities Alternate uses of previously fielded materiel Leadership and educational alternatives Use existing facilities in new ways; introduce new facilities or locations Policy alternatives – change policies that contribute to gaps in capability Page Limit, Document Body: 30 Pages The purpose of a Joint DCR is to propose non-materiel capability solutions as an alternative to, or complement of, materiel capability solutions. DCRs may also be used to validate capability requirements where service contracting in accordance provides the most appropriate capability solution. A Joint DCR recommends partially or wholly mitigating one or more identified capability requirements and associated capability gaps with non-materiel capability solutions, through changes to one or more of the eight DOTmLPF-P areas. In cases where a DCR is not generated as a successor document to a previously validated ICD, it also specifies the capability requirements and associated capability gaps for review and validation. For non-materiel solutions which impact only the Sponsor organization, DCRs are not required by the JCIDS process, as DOD Components manage Component specific DOTmLPF-P at their discretion. Sponsors may use (or not) a DCR in support of non- materiel capability solutions or as enablers of materiel capability solutions in accordance with policies and processes of that organization. For non-materiel solutions which impact more than just the Sponsor organization, a Joint DCR is used to ensure equities of all effected organizations are addressed during review and validation. For non-materiel solutions which impact only the Sponsor organization, DCRs are not required by JCIDS, as DOD Components manage Component specific DOTmLPF-P at their discretion.

CBA Output Document – Materiel & Non- Materiel Solutions
Initial Capabilities Document (ICD) (Includes the Information Systems (IS) Variant) Documents Capabilities-Based Assessment (CBA) results Specifies one or more capability requirements and associated capability gaps which represent unacceptable operational risk if left unmitigated Identifies relevant operational attributes Identifies notional resources available over anticipated life cycle Recommends partially or wholly mitigating identified capability gap(s) with a non-materiel capability solution, materiel capability solution, or some combination of the two Supports the Materiel Development Decision (MDD) Predecessor for the Capabilities Development Document (CDD) Page Limit, Document Body: 10 Pages The ICD is the most common starting point for new capability requirements. Once validated, the ICD typically leads to a Materiel Development Decision (MDD), then to an Analysis of Alternatives (AoA) to inform a decision for a materiel solution, and subsequently to a Capability Development Document (CDD) for development of a solution, and to a Capability Production Document (CPD) for production and deployment of the solution. An ICD is not always required before creating successor documents – CDDs, CPDs, or Joint DCRs – if alternative studies or documentation sources make the ICD redundant. In cases where the Sponsor proposes to proceed directly to a successor document, the general content of the ICD, including capability requirement and capability gap tables, will be provided in the successor document. In cases where the Sponsor proposes to proceed directly to a CDD or CPD, the Sponsor will request an ICD waiver through the Joint Staff Gatekeeper in accordance with Enclosure E of this manual. The Joint Staff Gatekeeper, in coordination with the MDA and validation authority, may approve an ICD waiver, and the MDA may direct in the MDD that the MSA phase of acquisition be abbreviated or eliminated, and further development of a capability solution start directly at MS A, MS B, or MS C. If the MDA directed at MDD that a program start at MS C, a CDD is not required and a CPD is used to support MS C.

ICD Operational Attributes
An ICD Identifies Capability Requirements with Associated Initial Objective Values Initial objective values satisfy operational needs while serving as starting point for analysis supporting trade-offs above and below the objective value Represent values necessary to achieve mission objectives with moderate operational risk Examples: Outcomes, time, distance, effect, obstacles to be overcome, and supportability Guides the Analysis of Alternatives (AoA) With AoA results, Guides Development of Key Performance Parameters (KPPs) for Inclusion in the Capability Development Document (CDD) The ICD must describe capability requirements in terms of the required operational attributes with appropriate qualitative parameters and metrics, e.g., outcomes, time, distance, effect (including scale), obstacles to be overcome, and supportability. Indicate the minimum value below which the capability will no longer be effective. “TBD” values are not allowed. These operational attributes are “mission” related, not specific to a certain solution. These attributes are used as measures of effectiveness (MOE) during the AoA to compare alternative solutions. Those associated with the preferred solution, or the solution selected by the acquisition milestone decision authority, will evolve into more detailed KPPs for inclusion in the CDD during the Technology Development phase.

ICD Variant for Information Systems (IS-ICD)
IS-ICDs Implement the “Information Technology (IT) Box” Model IS-ICDs must be used when applicable for capability requirements documents with JSDs of JROC and JCB Interest. Specifically appropriate for: Procurement or modification of Commercial off the Shelf (COTS)/Government off the Shelf (GOTS) IS products 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 Approaches where the solution involves research and development and / or acquisition of applications systems software, and the projected life-cycle costs exceed $15 million Associated hardware must be COTS/GOTS The IS-ICD is a variant of the regular ICD, implementing the “IT Box” model. IS-ICDs streamline the requirements process relative to IS efforts by delegating requirements oversight and document formats for subsequent documents as identified in the IS-ICD. This provides IS programs greater flexibility to incorporate evolving technologies and achieve faster responses from requirement validation processes than is typical for other kinds of materiel or non-materiel solutions. The purpose of an IS-ICD is focused on facilitating more efficient and timely software development efforts, and is not appropriate for hardware development efforts or capturing capability requirements which span a broad scope of combined hardware, software, and/or DOTmLPF-P efforts. “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.

When an IS-ICD Is Not Appropriate
IS-ICDs are NOT Appropriate for: Software embedded as a subset of a capability solution developed under other validated capability requirement documents. Software requirements are validated as part of the overall capability solution Software requiring a host platform which does not yet have validated capability requirement documents. Software requirements can be included in the capability requirements of the host platform, or as a separate IS-ICD submitted after validation of the host platform capability requirement documents. Increases in quantities of previously fielded IS without modification, which are not addressed by an IT Box. Increased quantities may be addressed by a DCR. Increases in quantity which remain within the scope of a previously validated IT Box, may be accomplished without revalidation. Requirements for Defense Business System (DBS) capabilities

IT Box Components for IS-ICD
Organization & Oversight Application and System Software Development Cost Controls Capability Requirements & Attributes Hardware Refresh and System Enhancements & Integration Cost Controls Flag-level Chair & Members List operational attributes / initial values (not threshold & objectives) Per year = $xxx Life cycle cost = $xxx Rationale JROC-Approved IS-ICD Oversight Organization Execution Organization Net-Ready KPP Added by JCIDS Manual Feb 2015

Key JCIDS Document Development
Capability Development Document (CDD) Proposes development of a specific materiel solution Draft CDD (Sponsor Approved) supports Milestone A and Technology Maturation and Risk Reduction (TMRR) Phase Validated CDD supports Development RFP Release Decision, Milestone B, and EMD Phase Identifies developmental performance attributes: KPPs, Key System Attributes (KSAs), and Additional Performance Attributes (APAs) Other System Attributes, such as Human Systems Integration (HSI), environmental factors, transportability, etc.. Attributes should be authoritative, measurable and testable Describes DOTmLPF-P considerations associated with the solution May apply to multiple increments of development Page Limit, Document Body: 45 Pages The CDD is the Sponsor’s primary means of proposing refined capability requirements, in the form of KPPs, KSAs, APAs and other system attributes, associated with a specific capability solution intended to wholly or partially satisfy validated capability requirements and close or mitigate associated capability gaps. A draft CDD, not submitted to the Gatekeeper for staffing and validation, is required to inform the Request for Proposal (RFP) for the Technology Maturation and Risk Reduction Phase following the MS A decision. A CDD is not submitted for staffing and validation until the AoA or alternative supporting analysis is completed and reviewed by the validation authority. If an AoA has not been conducted, the sponsor will explain, in the CDD, why an AoA was not justified. The validated CDD is a required for the development RFP release and MS B decision points, and guides the Sponsor in activities during the Engineering and Manufacturing Development (EMD) phase. The validated CDD is a key factor in the MDA decision to initiate an acquisition program at MS B. In cases where the MDA waives MS B but an EMD phase will be conducted, the CDD is validated before RFP release for the EMD phase or the beginning of the EMD phase , whichever comes first. In cases where MS B and MS C are combined, such as for high cost first articles of spacecraft and ships, the CDD is the authoritative document for the first article produced during EMD without the need for a CPD. A CPD is validated to support production of second and subsequent articles. KPPs, KSAs, and APAs are expressed using a threshold/objective format and are included verbatim in the acquisition program baseline. They are expressed in terms of parameters which reflect Measures of Performance (MOP) for the system rather than Measures of Effectiveness (MOE), mission related operational attributes, that were reflected in the ICD. CDD KPPs are inserted verbatim into the APB

CDD Variant for Information Systems (IS-CDD)
Implements IT Box model used in the IS-ICD May be used where a validated ICD contains capability requirements which can be addressed by a combination of IS and non-IS solution and the IT Box is applicable to the IS portion May be used for MDAP and MAIS programs to comply with statutory requirements for a CDD while allowing for the flexibilities of the IT Box May be used in cases where a validated CDD was generated before the IT Box construct was introduced, and the Sponsor wants to revalidate under the IT Box construct. IS-CDDs are appropriate in the same situations where the IS-ICD is appropriate, and are NOT appropriate in the same situations where the IS-ICD is not appropriate. Capability Production Documents (CPDs) are not required as successor documents for an IS-CDD – the delegated authority may prescribe alternate document formats The purpose of an IS-CDD is focused on facilitating more efficient and timely software development efforts, and are not appropriate for hardware development efforts or capturing capability requirements which span a broad scope of combined hardware, software, and/or DOTmLPF-P efforts. The IS-CDD is a variant of the regular CDD, implementing the “IT Box” model outlined in the IS-ICD described earlier. IS-CDDs streamline the requirements process relative to IS efforts by delegating requirements oversight for subsequent documents . This provides IS programs greater flexibility to incorporate evolving technologies and achieve faster responses from requirement validation processes than is typical for other kinds of materiel or non-materiel solutions.

IT Box Components for IS-CDD
Organization & Oversight Flag-level Chair & Members JROC-Approved IS-CDD Oversight Organization Execution Organization Key Performance Parameters Hardware Refresh and System Enhancements & Integration Cost Controls List KPPs Per year = $xxx Life cycle cost = $xxx Rationale Major difference from IS-ICD IT Box. Applications and System Software Development Cost Controls KPPs may be quantified in terms of initial performance values rather than objective / threshold values. Same applies to KSAs and APAs used in the body of the IS-CDD Per year = $xxx Life cycle cost = $xxx Rationale

Key Difference In Usage: IS-ICD & IS-CDD
Key difference in usage of IS-ICDs and IS-CDDs is whether the AoA takes place before or after delegating authorities under the IT Box. For an IS-ICD to be appropriate, it must be very clear from the CBA that an IS solution is the only viable approach to be considered. The AoA conducted in the MSA phase takes place after delegating authorities under the IT Box and will therefore only consider IS alternatives. An IS-CDD is more appropriate when an IS solution is not presumed at the time the ICD is validated and the Materiel Development Decision (MDD) approved, or other materiel and/or non-materiel solution(s) are expected to be necessary along with the IS solution. The IS-CDD is a result of the AoA conducted in the MSA phase and represents an IS solution for part or all of the capability requirements validated in the ICD.

Managing an IS Requirement Using the IT Box Construct
As the IS-ICD and IS-CDD only streamline the applicable requirements processes, the Sponsor must still ensure compliance with acquisition policy and processes in DoDI , and Information Support Plan (ISP) policy and processes in accordance with DoDI Since the standard CDD and CPD are not typically required, an IS-ICD or IS-CDD provides Sponsors the flexibility to manage IS requirements with alternate documents and validation processes as necessary, as long as development efforts remain within the boundaries of the validated IT-Box and any additional guidance provided by the validation authority.

Successor Documents for IS-ICDs and IS-CDDs
CDDs are Not required as successor documents for IS-ICDs; CPDs are Not required as successor documents for IS-CDDs. Sponsors have management flexibility for successor documents JCIDS Manual provides following examples of potential IS ICD/IS-CDD follow-on documents (actual names, content, and approval determined by the delegated validation authority): Requirements Definition Package (RDP) – identifies KPPs, KSAs, and APAs, 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 FCB is briefed Every 2nd Year after validation on progress toward delivering the solution (FCB may recommend elevating to JROC Oversight) Regardless of successor documents used, the Sponsor must satisfy the NR KPP, when applicable, and any acquisition activities dependent upon content from capability requirement documents. Recommend RDPs and CDs be co-developed by the RM and PM Office See notes page for additional information

Requirements Definition Packages (RDPs)
RDP is an example – It Is Not a JCIDS Document; It identifies performance attributes, it does not contain software specs Created to show how requirements can be broken into deliverable increments Components define content and approval process Provides a more detailed definition of capabilities in the IS-ICD Enables detailed design activity Enables detailed costing of the requirements Provides link between the IS-ICD and the acquisition and program budget processes Approved by the delegated requirements management authority FO/GO-level body that holds authority over, and provides governance for requirements In the case of an IS-ICD, one or more RDPs (or equivalents) could be the equivalent of a CDD in terms of providing greater specificity of a capability solution intended to address part or all of the capability requirements identified in the IS-ICD. In the case of an IS-CDD, an RDP (or equivalent) may not be necessary if the required level of specificity for the capability solution is already contained in the IS-CDD. However, RDPs (or equivalents) may still be used if needed to decompose the overall capability requirements of the IS-CDD into more manageable parts to facilitate the development efforts. One or more RDPs (or equivalents) together could represent the total set of capability solutions developed to satisfy the capability requirements in the IS-ICD or IS-CDD. In support of DoDI a draft RDP (or equivalent) must be used before validation to support MS A decisions for IS technology/prototyping efforts. The RDP (or equivalent) is submitted to the delegated oversight authority for validation ahead of a MS B decision. Within 14 days of validation by the delegated oversight authority, the Sponsor must provide the RDP (or equivalent), along with its associated approval memorandum, to the Joint Staff Gatekeeper would be posted to the KM/DS system for information purposes and for visibility into capability requirement portfolios managed in accordance with Enclosure B of the JCIDS Manual. See notes page for additional information

Capability Drops (CDs)
CD is an Example – It Is Not a JCIDS Document; It describes performance characteristics, it does not contain software specs Manages 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 CD development are released incrementally through full deployment decisions as they are ready Approval may delegated to lowest appropriate level (as determined by the oversight authority) to ensure timely decision making The CD (or equivalent) could describe the performance characteristics of a relatively small increment of a capability solution included in a software build necessary for partial deployment of the overall capability solution, typically developed and fielded within a short period of time. It could be developed through a rapid prototyping effort with the user to ensure it meets their needs. A CD (or equivalent) could be developed directly from the definitions in the IS-ICD in the event of a more timely need for the capability solution. More commonly, multiple CDs (or equivalents) would be derived from an RDP (or equivalent) or IS-CDD to deliver all of the overall capabilities capability solution defined in the RDP (or equivalent) or IS- CDD. See notes page for additional information

Example of IS-ICD or IS-CDD Successor Documents
Illustrative - not intended to limit potential flexibilities provided by the IS-ICD or IS-CDD Although this figure shows RDPs and CDs, actual names, content, and approval process are at the discretion of the delegated oversight authority. The RDP (or equivalent) is a first level refinement of one or more capability requirements identified in an IS-ICD or IS-CDD, and is co-developed by the operational user (or representative) and the program office. The RDP (or equivalent) identifies the KPPs (including the NR KPP), KSAs, and APAs necessary to scope and cost a specific solution implementation. The RDP (or equivalent) may also identify non-materiel changes that need to be implemented to fully realize the IS capability. The RDP (or equivalent) is approved by the delegated oversight authority identified in the IS-ICD or IS-CDD. In the case of an IS-ICD, one or more RDPs (or equivalents) could be the equivalent of a CDD in terms of providing greater specificity of a capability solution intended to address part or all of the capability requirements identified in the IS-ICD. In the case of an IS-CDD, an RDP (or equivalent) may not be necessary if the required level of specificity for the capability solution is already contained in the IS-CDD. However, RDPs (or equivalents) may still be used if needed to decompose the overall capability requirements of the IS-CDD into more manageable parts to facilitate the development efforts. See notes page for additional information

Configuration Steering Boards (CSB)
“… the Acquisition Executive of each DoD Component will form and chair a CSB with broad executive membership . . .” DoDI , Jan 2015 CSBs meet at least annually Review all requirements changes and significant technical configuration changes with potential for cost and schedule impacts Only approve changes that increase cost if funds identified and schedule impacts addressed. Requirements fall under CSB cognizance once CDD is validated The PM (with the PEO) identifies descoping options to reduce program cost or to moderate requirements CSB recommends to the requirements validation authority which options should be implemented Final decisions on implementation of descoping options coordinated with capability requirements officials. CSB role kicks in once the CDD is validated. Can meet as needed, but at least annually for ACAT I and IA programs. Requirements discussions and trades (especially affordability trades, or risk-based trades) continue even after the ICD and CDD are validated. The CSB is a forum to tee up requirements issues, trades, and to adjudicate a way forward to resolve emerging requirements (e.g., assigning new requirements to a future increment, or addressing them incrementally with some capability in earlier release/increment, and full capability later).

Key Performance Parameters (KPPs)
Performance Attributes of a system critical or essential to development of an effective military capability KPPs must be measurable, testable, and support efficient and effective T&E Enable feedback from T&E; support decision making Validated by JROC for JROC Interest Documents Change authority generally retained by the validation authority, unless specifically delegated in the validation memorandum. Failure to meet a validated KPP threshold triggers a review by the validation authority and evaluation of operational risk and/or military utility of the system(s). Review may result in validation of an updated KPP threshold value, modification of production increments, or recommendation for program cancellation. KPPs are performance attributes of a system considered critical or essential to the development of an effective military capability. The number of KPPs specified by a Sponsor should be kept to a minimum to maintain program flexibility. Failure of a system to meet a validated KPP threshold value triggers a review by the validation authority and evaluation of operational risk and/or military utility of the associated system(s) if KPP threshold values are not met. The review may result in validation of an updated KPP threshold value, modification of production increments, or recommendation for program cancellation. Post-validation change authority for KPPs is generally retained by the validation authority, unless specifically delegated in the validation memorandum.. The JROC validates KPPs for JROC Interest documents. The JCB validates KPPs for JCB Interest documents. The Sponsor (DOD Component) validates KPPs for Joint Integration and Joint Information documents. The JROC encourages the requirements Sponsor, in coordination with the MDA, to request requirements relief from the validation authority when cost-benefit analyses indicate previously validated KPPs may drive costs out of proportion with the capability delivered to the operational user. KPP relief should be considered especially appropriate in cases where significant cost savings may be achieved with marginal impact to operational capability. I.e. – spending 15 percent of a program’s budget to get the last 3 percent of a KPP threshold, if the operational risk involved with a reduced threshold is minimal.

Key System Attributes (KSAs)
Performance attributes considered essential to achieving a balanced solution Not critical enough to be selected as a KPP Must be measurable, testable, and support efficient and effective T&E Identified by the sponsor; should be kept to a minimum Change authority delegated to Sponsor, unless retained in document validation memorandum The KSAs required to support the Sustainment KPP (KSAs for materiel reliability and Operations and Support Costs) are specified by the JCIDS Manual.

Additional Performance Attributes (APAs)
Performance Attributes of a System Not Important Enough to be a KPP or KSA Must be measurable, testable, and support efficient and effective T&E Identified by the Sponsor; should be kept to a minimum Change authority delegated to Sponsor, unless retained in document validation memorandum

Other System Attributes
Other system attributes not Identified elsewhere in the CDD/CPD, especially those that tend to be design, life cycle cost, or risk drivers. May include, but not limited to: Embedded instrumentation, electronic attack, and wartime reserve mode requirements. Human Systems Integration (HSI) considerations. Natural environmental factors, including climatic design type, terrain, meteorological and oceanographic factors. Physical and operational security, including technology security, foreign disclosure, and anti-tamper Weather and oceanographic data accuracy and forecast needs Transportability and deployability considerations Space, weight, power and cooling margin requirements and open system attributes.

Mandatory Key Performance Parameters (KPPs) & Key System Attributes (KSAs)
Force Protection KPP (all CDDs & CPDs for manned systems) System Survivability KPP (all CDDs & CPDs ) Sustainment KPP (all CDDs & CPDs) Materiel Availability Operational Availability Supporting KSAs Materiel Reliability Operation & Support Costs Net Ready KPP (all IS-ICDs and all CDDs & CPDs addressing IS) Training KPP (all CDDs & CPDs with training requirements which dictate operational performance characteristics of the capability solution) Energy KPP (all CDDs & CPDs where provisions of energy impact operational reach, or protection of energy infrastructure or energy resources is required) In addition to KPPs, KSAs, and APAs essential to the capability solution being developed, Sponsors must address the KPPs show here. Detailed guidance for each is in the JCIDS Manual

Force Protection (FP) KPP
Use of the FP KPP in CDDs and CPDs – Expected for all manned systems, unmanned systems which interface with or operate in the proximity of personnel, and for systems designed to enhance personnel survivability Force Protection attributes include protection from – Kinetic fires Non-kinetic fires CBRN effects Synergy/overlap with System Survivability (SS) KPP – May include same attributes as the SS KPP, but emphasis is on protecting occupants / other personnel rather than protecting the system itself. Exclusion of offensive attributes: Offensive attributes primarily intended to defeat adversary forces before they can engage non-adversary forces are not included as part of the FP KPP. Endorsed by the Chair, Protection FCB Environmental effects Crash events The FP KPP is intended to ensure protection of occupants, users, or other personnel (other than the adversary) who may be adversely affected by the system or threats to the system. Although a FP KPP may include many of the same attributes as those that contribute to the System Survivability KPP, the intent of the FP KPP is to address protection of the system operator or other personnel against kinetic and non-kinetic fires, Chemical, Biological, Radiological, and Nuclear (CBRN), and environmental effects, rather than protection of the system itself and its capabilities.

System Survivability (SS) KPP
Applies to all CDDs and CPDs System Survivability attributes contribute to the survivability of manned or unmanned systems Examples: Speed Maneuverability Armor Electromagnetic Spectrum Control Redundancy of Critical Subsystems Protection from Chemical, Biological and Radiological Effects Endorsed by Chair, Protection FCB The SS KPP is intended to ensure the system maintains its critical capabilities under applicable threat environments. The SS KPP may include reducing a system’s likelihood of being engaged by hostile fire, through attributes such as speed, maneuverability, detectability, and countermeasures; reducing the system’s vulnerability if hit by hostile fire, through attributes such as armor and redundancy of critical components; enabling operation in degraded electromagnetic, space, or cyber environments; and allowing the system to survive and continue to operate in, or after exposure to, a Chemical, Biological, Radiological, and Nuclear (CBRN) environment, if required. In System of System (SoS) approaches, it may also include resiliency attributes pertaining to the ability of the broader architecture to complete the mission despite the loss of individual systems. Exclusion of Offensive Attributes. Offensive attributes of the system, or attributes of other collaborating systems participating in the mission, that are primarily intended to defeat adversary forces before they can engage non-adversary forces are not included as part of the SS KPP.

Sustainment KPP & KSAs Applies to all CDDs and CPDs. Elements:
Availability KPP: Consists of Materiel Availability and Operational Availability Reliability KSA Operations & Support Cost KSA Endorsed by Chair, Logistics FCB in coordination with Joint Staff, J-4 Maintenance Division (J-4/MXD), and the office of the Deputy Assistant Secretary of Defense (Materiel Readiness) Materiel Availability is the measure of the percentage of the total inventory of a system operationally capable, based on materiel condition, of performing an assigned mission. This can be expressed mathematically as the number of operationally available end items/total population. Operational Availability is the measure of the percentage of time that a system or group of systems within a unit are operationally capable of performing an assigned mission and can be expressed as (uptime/(uptime + downtime)). Reliability KSA. Reliability is a measure of the probability that the system will perform without failure over a specific interval, under specified conditions. O&S Cost KSA. O&S Cost metrics provide balance to the sustainment solution by ensuring that the O&S costs associated with availability and reliability are considered in making decisions. All Cost Assessment and Program Evaluation (CAPE) O&S cost elements in support of this KSA. This includes the fully burdened cost of energy.

Net Ready KPP Applies to all Information Systems (IS) and National Security Systems (NSS) Used in the: automated acquisition, Storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of DOD data or information regardless of classification or sensitivity Applies to all IS-ICDs, CDDs and CPDs addressing IS. Applies to JUON, JEON, and DoD Component UON IS solutions unless an exemption to the Information Support Plan (ISP) is approved in accordance with DODI , “Interoperability of Information Technology (IT), Including National Security Systems (NSS)”. Not Applicable to Systems That Do Not Communicate With External Systems Certified by: Chair, C4/Cyber FCB The NR-KPP is used to address: Requirements. Evaluate interoperability and net-centric requirements for the system. Information Exchanges. Verify IS supports operationally effective producer to consumer information exchanges according to the validated capability requirements and applicable reference models and reference architectures. MOEs and MOPs. Provide MOEs and MOPs to evaluate IS’s ability to meet the initial minimum values, for requirements validated under an IS-ICD, or threshold and objective values, for requirements validated under a CDD or IS-CDD, when testing the system for joint interoperability certification. Interoperability Issues. To enable assessment of capabilities and systems, architectures must align with and use the JCSFL. The architecture should also align, if applicable, with the DOD Information Enterprise Architecture (IEA), Joint Information Environment Operational Reference Architecture (JIE ORA), Warfighting Enterprise Architecture (WEA), and existing Joint Mission Threads (JMTs). Compliance. Determine whether IS complies with network operations (NETOPS) for the DODIN direction, DODIN goals and characteristics, and is integrated into system development. Spectrum Requirements. To obtain a NR KPP certification, all IS must comply with spectrum management and Electromagnetic Environmental Effects (E3) direction. J-8 Deputy Director, C4 (Chair, C4/Cyber FCB) conducts interoperability certification of JCIDS Documents. Interoperability test certification is conducted by the Joint Interoperability Text Command.

Net-Ready KPP, continued
Net-Ready KPP consists of three attributes: Supports Military Operations Is Entered and Managed on the Network, and Effectively Exchanges Information Three-Step Development Process Step 1. Mission Analysis – Determines Attribute Details for “Supports Military Operations” Step 2. Information Analysis – Determines Attribute Details for “Entered & Managed on the Network” and “Effectively Exchanges Information” Step 3. Systems Engineering & Architecture – Supports all 3 attributes Support Military Operations. This attribute specifies which military operations (e.g. missions or mission threads), as well as operational tasks, a system supports. Threshold and objective values of MOEs are used to measure mission success and are specific to the conditions under which a mission will be executed. Threshold and objective values of MOPs are used to measure task performance and the conditions under which the tasks are performed. Since the NR-KPP focuses on exchanging information, products, or services with external IS, these tasks should only be net-centric operational tasks. Operational tasks are net- centric if they produce information, products, or services for or consume information, products, or services from external IS (including storing information on external IS). Entered and Be Managed On the Network. This attribute specifies which networks the IS must connect to in order to support its net-centric military operations. The attribute must also specify performance requirements for these connections. Effective Information Exchanges This attribute specifies the information elements produced and consumed by each mission and net-ready operational task . Since the NR- KPP focuses on a system’s interactions with external systems, information elements the IS produces, sends, or makes available to an external system and information elements the IS receives from an external system are identified. For each information element, MOPs are used to measure the information element’s production or consumption effectiveness. The NR-KPP MOPs should also describe the information elements’ continuity, survivability, interoperability, security, and operational effectiveness and how unanticipated users are affected.

Net-Ready KPP IS-ICD Example
NR KPP Attribute Key Performance Parameter Initial Value 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 Mission Activities: Find HVT Measure: Location accuracy Conditions: Individual differentiation 100 meter circle Identify armed/not armed Enter and be managed in the network Network: SIPRNET Measure: Time to connect to an operational network from power up Conditions: Continuous Network Connectivity <2 minutes Network: NIPRNET Conditions: Continuous Network Connectivity Up to 2 minutes Exchange information Information Element: Target Data Measure: Dissemination of HVT biographic and physical data Measure: Latency of data Condition: NSA Type 1 Certified Encryption Condition: Continuous Network Connectivity <10 seconds <5 seconds

Key Performance Parameter
Net-Ready KPP CDD/CPD Example Attribute 1. Supports 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 (<1 sec) HVT tracked, neutralized Mission Activities: Find HVT Measure: Absolute Location accuracy Conditions: Individual differentiation <100 meter circle at 90% confidence Identify armed/ not armed <25 meter circle at 90% confidence Identify individual

Key Performance Parameter
Net-Ready CDD/CPD KPP Example Attribute 2. Enter and Managed on 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: Continuous Network connectivity <2 minutes >99.8% <1 minute >99.9% Network: NIPRNET

Net-Ready KPP CDD/CPD 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: Latency of data Condition: NSA certified type 1 Condition: Continuous Network connectivity <10 seconds <5 seconds >99.8% <2 seconds >99.9%

Training KPP Applies to CDDs and CPDs that Have System Performance Requirements Necessary to Enable Training Associated with the Materiel Capability Solution. Separate Endorsement Not Required. Endorsed as Part of Training Considerations in the DOTmLPF-P Endorsement by Joint Staff J-7, with advice from the Office of the USD (Personnel & Readiness) The Training KPP is intended to ensure that materiel aspects of training capabilities, when applicable, are addressed as part of the development of the capability solution outlined in the CDD or CPD. Nonmateriel aspects of training are to be captured as part of the DOTmLPF-P section of the CDD or CPD. An illustrative example is the long mission durations of submarine operations, which may necessitate that the warfighter use the Training KPP to specify certain training and simulation capabilities be integrated into the weapon system. If not able to properly train during operational missions, warfighter performance may be degraded. The “mission” of some systems is solely the training of personnel who will use a different operational weapon system. For example, use of the T- 38 aircraft as a trainer for more advanced aircraft, or use of a flight simulator to substitute for some aspects of training when training events in the actual aircraft would be too dangerous to perform or when events are more cost effective to execute in the simulator. The KPPs (and KSAs and APAs) of the training system are specified to properly replicate some or all of the performance aspects of a different system in order to conduct the appropriate level of training.

Energy KPP Applies to systems where the provision of energy, including fuel and electric power, impacts operational reach, or requires protection of energy infrastructure or energy resources in the logistics supply chain May be expressed as units of energy used per period of time (e.g. gallons per hour), or as number of refuelings required (e.g. tankings per hour). Endorsed by Chair, Logistics FCB, in coordination with Joint Staff J-4 / Engineering Division (J-4/ED) The Energy KPP is intended to ensure combat capability of the force by balancing the energy performance of systems and the provisioning of energy to sustain systems/forces required by the operational commander in relevant threat environments. The Energy KPP differs from other KPPs in several ways: Fuel delivery logistics (tanker aircraft, oilers, and fuel trucks) have a uniquely large presence in the total force structure and in the battlespace. Fuel, in the large volumes US forces demand it, and, in the timeframe when new systems will come into the force, may become less readily available for procurement in proximity to where it is required for operations. The Energy KPP does not focus directly on energy-related costs, but rather on mission effectiveness within the context of mission and threat. The Energy KPP includes, but is not limited to, considerations for optimizing fuel and electric power demand in capability solutions, in the context of the logistical supply of energy to the warfighter, as it directly affects the demand on the force to provide and protect critical energy supplies. Although the Energy KPP is mandatory, not all programs or systems require full development of an Energy KPP. If a system does not use operational energy, or if energy consumption is not relevant to sustained performance over scenario timelines, the Sponsor may request a waiver of the Energy KPP, and include justification in the CDD or CPD as to why the Energy KPP is not applicable.

Key JCIDS Document Production
Capability Production Document (CPD) Proposes production of an increment of a specific materiel solution Supports Milestone C Identifies production performance attributes: KPPs, Key System Attributes (KSAs), and Additional Performance Attributes (APAs) Other System Attributes, such as Human Systems Integration (HSI), environmental factors, transportability, etc. Attributes should be authoritative, measurable and testable Identifies DOTmLPF-P impacts of the solution Does not introduce new requirements Page Limit, Document Body: 40 Pages The CPD is submitted to the JCIDS process for staffing and validation prior to a MS C decision. Prior to validation, the draft CPD provides the validation authority and other stakeholders the opportunity to assess how the capability solution, its associated production KPPs, KSAs, and APAs, and other supporting data, address the validated capability requirements. During staffing, the validation authority and other stakeholders have the opportunity to recommend modifications to the document, including the production KPPs, KSAs, and APAs and associated threshold/objective values, to best address the needs of the joint force and to manage and prioritize the capability requirement portfolios. Because a CPD is finalized after critical design review (CDR) and after the majority of capability development, it is normally not appropriate to introduce new capability requirements at this point. New capability requirements should be included in the next increment or in a future modification or upgrade if no additional increments are planned. In cases where MS B and MS C are combined, such as for high cost first articles of spacecraft and ships, the CPD is the authoritative document for production of the second and subsequent articles, and must be validated prior to the production decision for those articles. CPD KPPs are inserted verbatim into the APB

Differences Between the CDD and the CPD
Focus on Design & Development Focus on Production All Increments A Specific Increment Production Representative Articles measured against KPPs/KSAs/APAs Low-Rate Initial Production articles measured against refined KPPs/KSAs/APAs The most significant difference between the CDD and the CPD is the refinement of threshold and objective values for KPPs, KSAs, and APAs previously identified in the CDD or other source document. The CDD drives design and development of a new system; the CPD focus is on an increment of production. The KPPs/KSAs/APAs in the draft CDD at Milestone A drove an evaluation of alternative designs and acquisition strategies. The validated CDD required at the Development RFP Release decision and at Milestone B reflects any KPP/KSA/APA changes from the draft, and is used to complete development of the selected design, and prepare for production. During EMD, production representative articles will be tested to confirm performance consistent with the KPPs/KSAs/APAs. The CPD reflects the results of the EMD phase activities with appropriate adjustments to KPPs/KSAs and APAs. The validated CPD is a requirement for Milestone C.

Thresholds, Objectives, and Trade Space
Performance attributes in the CDD and CPD are expressed in threshold / objective Format. Thresholds. Threshold values should be based upon the minimum performance required to achieve the required operational effect, while being achievable through the current state of technology at an affordable life cycle cost of the system. Objectives. Objective values should be defined where an increased level of performance delivers significant increased operational effect, or decreased operational risk, if it can be delivered at an affordable life cycle cost of the system. Not every KPP, KSA, or APA must have an objective value which differs from the threshold value. Trade Space. The difference between threshold and objective values sets trade space for balancing multiple KPPs, KSAs, and APAs while remaining above the threshold values. Threshold and objective values of an KPP, KSA, or APA may change between the CDD and the CPD. During the Engineering and Manufacturing Development (EMD) phase, tradeoffs are made between the threshold and objective values to optimize performance, given the available technology for the increment and the competing demands introduced by combining subsystems into the overall system. A deeper analysis of cost-capability trade-offs at and around threshold and objective values may be beneficial to decision makers, by exploring incremental return on investment where particular KPPs, KSAs, and APAs might be insensitive to small deviation at great advantage in life cycle cost, performance, schedule, and quantity reviews. After the Critical Design Review (CDR) during EMD, these tradeoff decisions are essentially completed and a more precise determination of acceptable performance can be stated in the CPD.

DOD Architecture Framework (DODAF) Data Flow, CBA – ICD – CDD/CPD
DODAF views and associated data provide a structured means to document data associated with the CBA and more easily leverage and update data when developing capability requirement documents as shown here. The DODAF Operational Views (OVs) and Capability Views (CVs) illustrated here should be generated during the CBA, as leveraging these DODAF views and associated data can significantly improve efficiency, saving time and resources later in the JCIDS and DAS processes. The DODAF Systems Views (SVs) should NOT be generated during the CBA and are shown for context only. They require system level details that will not be available until an AoA is conducted, but are derived from the OVs and CVs generated during the CBA. In addition to specific views outlined in later sections of the CBA guidance, the Sponsor should be maintaining/updating the following views throughout the CBA activities for their own benefit, even though they are not mandatory submissions to go along with an ICD. DODAF All View-1 (AV-1) – Overview and Summary Information. This overview/summary data from the CBA can be re-used when authoring the CBA results and the ICD executive summary DODAF All View-2 (AV-2) – Integrated Dictionary. The definitions identified during the CBA can be re-used when authoring the CBA results and as a starting point for authoring the ICD . For more details on DODAF views, see the DODAF Architecture Primer in Appendix C of Enclosure C of the JCIDS Manual. This chart illustrates the flow of operational context and capability requirement and gap data gathered during a CBA to the ICD/CDD/CPD. See the JCIDS Manual for the full range of required DODAF data for JCIDS documents

JCIDS Document Staffing and Validation

JCIDS Gatekeeper J-8, Deputy Director for Requirements (DDR) is the Gatekeeper The Gatekeeper: Performs an initial review of all JCIDS proposals Gatekeeper determines: Joint Staffing Designator (JSD) JROC Interest JCB Interest Joint Integration Joint Information Lead and supporting Functional Capability Boards (FCBs) Formal staffing begins after gatekeeper decisions Gatekeeper Makes Joint Staffing Designator (JSD) Decision After Sponsor Posts Document to the Knowledge Management/ Decision Support (KM/DS) Tool The Gatekeeper manages the overall flow of documents into and out of the JCIDS process for staffing and validation, in addition to other activities in support of the JCIDS process. Regardless of potential ACAT or validation authority, Sponsors submit all ICDs, CDDs, CPDs, and Joint DCRs to the Joint Staff for evaluation of joint equity and determination of the appropriate staffing process and validation authority. The Gatekeeper: Confirms that the document is complete and ready for staffing; if not returns to Sponsors for further development Confirms that CBAs, studies, and other supporting material have been uploaded into the KM/DS studies repository Identifies lead and supporting Functional Capability Boards (FCBs) Assigns one of four Joint Staffing Designations based on actual/potential ACAT and Joint Staff equities. The JSD sets the staffing path and timeline for the documents and identifies the validation authority Determines what Joint Staff certifications or endorsements may be necessary Initiates staffing by sending the document to the lead FCB Generates metrics related to the JCIDS Process and posts to KM/DS for visibility Monitors progress toward fielding of solutions to urgent operational needs Sponsor organizations have a Sponsor gatekeeper function providing a single point of entry into the JCIDS process. Common gatekeeping functions are maintained with the intelligence community for Intelligence Community Capability Requirements, and with the Deputy Chief Management Officer of DOD for Defense Business Systems. (see enclosure E, JCIDS Manual)

JCIDS Document Staffing Tracks
JSD FCB review JROC Interest JCB Review JROC KM/DS staffing & comment ACAT I/IA programs & Joint DCRs FCB review JCB Interest JCB KM/DS staffing & comment ACAT II & below with significant impact to the joint force Sponsor FCB review Joint Integration KM/DS staffing & comment ACAT II & below that require endorsements & certifications The FCB (often assisted by other supporting FCBs), will conduct their review concurrent with the review of the document by all other stakeholders via KM/DS. The Sponsor will adjudicate comments from those stakeholders, and when necessary ask the FCB for assistance. Comments submitted to KM/DS in response to document staffing are expected to be signed out at the GO/FO, or civilian equivalent, level. For documents with JSDs below JCB or JROC Interest, the JROC delegates validation authority to the Sponsor organization, and Sponsors may use their own internal staffing processes for review and validation. Sponsor processes must accommodate the time required to obtain Joint Staff endorsements and/or certifications where applicable. Endorsements and certifications include: Threat Validation and Intelligence Certification (J-2); Weapon Safety Endorsement (Chair, Protection FCB); Force Protection and System Survivability KPPs (Chair, Protection FCB); Net-Ready KPP certification (Chair, C4/Cyber FCB); Sustainment KPP (Chair, Logistics FCB); Energy KPP (Chair, Logistics FCB with J-4 and ASD(Operational Energy Plans and Programs); Training KPP (J-7 with USD(Personnel and Readiness); and DOTMLPF Endorsement (J-7 with DOTMLPF stakeholder organizations). FCB review Joint Information Validation Authority KM/DS staffing & comment ACAT II & below that do not require endorsements & certifications

Deliberate Staffing Gatekeeper determines JSD and assigns to lead and supporting FCBs FCB staffing runs concurrently with stakeholder review and comment Sponsor adjudicates comments FCB Chair recommends validation/no validation to JCB/JROC Validated documents are posted to KM/DS ICD, CDD, CPD to appropriate Acquisition Executive for action Joint DCR to lead organization designated in validation memo The Gatekeeper has 4 calendar days to perform initial review of the document and assign the new document to a Lead and supporting FCBs. Document Review and Commenting Stage: 21 Days. Staffing conducted with documents available to Services, CCMDs, and other DOD Components, as well as certifying/endorsing organizations and other stakeholders, for review and commenting. Substantive or Critical comments in response to staffing are expected to be signed out at the GO/FO or SES, level. Administrative comments may be signed out at the O-6 or GS-15 level. Comment Adjudication Stage: 30 days. The Sponsor adjudicates comments. Comments against documents with JSDs of JROC interest or JCB Interest must be adjudicated to the satisfaction of the FCB Chair and the Joint Staff certifying or endorsing organizations. Comments against documents with JSDs of Joint Integration must be adjudicated to the satisfaction of the DOD Component validation authority and the Joint Staff certifying or endorsing organizations. Comments against documents with JSDs of Joint Information must be adjudicated to the satisfaction of the DOD Component validation authority. FCB WG and FCB Review Stage: 14 Days. Following Sponsor comment adjudication, the FCB reviews the revised document, ensures certifying or endorsing organizations concur with Sponsor adjudication of comments, and assists the FCB Chair in reaching a recommendation for the JCB or JROC. The FCB Chair is ultimately responsible for providing a positive or negative validation recommendation to the validation authority. Validation Stage: 14 Days for JCB Interest. 28 Days for JROC Interest. The validation stage begins when the FCB Chair provides a positive validation recommendation. Post-Validation Documentation. Validation decisions by the JROC or JCB are documented via JROC Memorandum and are signed by the JROC Chairman or designee. Validation decisions by Sponsors and final versions of all validated requirement documents are uploaded to the KM/DS system for information purposes and visibility in the capability requirement portfolios.

JROC Decision Chain VCJCS JROC JCB FCB FCB WG JROC Membership
Chair: VCJCS Council Members: Vice Chief of Staff, Army Vice Chief of Naval Operations Vice Chief of Staff, Air Force Assistant Commandant of the Marine Corps Combatant Commands* (Commander or Deputy Commander) *Unless otherwise directed to participate by the JROC Chairman, CCMD representatives are highly encouraged to participate as voting members when matters related to the area of responsibility or functions of that command will be under consideration by the JROC. USD(AT&L), Dir, CAPE, USD(Comptroller), DOT&E, and USD(Policy) attend as JROC advisors Owns JCIDS; Validates JROC Interest Documents; Final Authority Validates JCB Interest Documents; Assists JROC Reviews Documents Prior to JCB Review Reviews Documents; Makes Validation Recommendation to JCB / JROC JROC Chairman; Advises the CJCS JCB JROC VCJCS FCB WG FCB JROC Decision Chain JROC: Joint Requirements Oversight Council JCB: Joint Capability Board FCB: Functional Capability Board FCB WG: Functional Capability Board Working Group

Joint Capabilities Board (JCB)
Provides review and endorsement of documents and adjudication of lower level issues prior to JROC validation Validates JCIDS documents with a Joint Staffing Designation (JSD) of “JCB Interest” JCB Chair: Director, J-8 JCB Membership: General/Flag Officers, or civilian equivalent, from the military services and combatant commands The JCB is a board below the JROC and provides review and endorsement of documents and adjudication of lower level issues prior to validation by the JROC. The JCB has delegated validation authority for documents with a Joint Staffing Designator of JCB Interest. USSOCOM has delegated validation authority for Special Operation peculiar JCIDS documents at the level of JCB Interest and below. JCB Chairman: Supports the JROC Chairman and the JROC in executing JROC responsibilities. Coordinates oversight of the JCIDS process and coordinates other issues requiring JROC review. Conducts JROC pre-briefs to ensure format, content, and presentation are appropriate. Assists the JROC Chairman in maintaining liaison with the Services, Combatant Commands, and other DOD components. USSOCOM has delegated validation authority for Special Operation Peculiar JCIDS documents at the level of JCB Interest and below.

Functional Capabilities Boards (FCBs)
Provides capability requirement portfolio management, including review and assessment of documents and adjudication of lower level issues within their portfolio prior to JCB review Aligned with Joint Capability Areas (JCAs) FCB Chair: General/Flag Officer, or Civilian Equivalent FCB Lead: Military Officer, 0-6, or Civilian Equivalent FCB Membership: Representatives in military grade of 0-6, or civilian equivalent, from Joint Staff, Services, CCMDs, and other organizations with equity in the FCB’s portfolio The FCBs are one level below the JCB and advise the JCB and JROC on issues within the capability requirement portfolio(s), and perform other activities at the direction of the JCB or the JROC. FCBs are aligned with eight of the nine joint capability areas (JCAs) , which define portfolios of functionally similar capabilities within which each of the FCBs can focus their efforts.

Functional Capabilities Boards (FCBs)
Force Support JS J-8 JCA 1 & 8 Force Support and Building Partnerships Battlespace Awareness JS J-2 JCA 2 Battlespace Awareness Force Application JS J-8 JCA 3 Force Application Logistics JS J-4 JCA 4 C4/Cyber JS J-6 JCAs 5 & 6 Command & Control and Net-Centric Protection JS J-8 JCA 7 FCBs receive their authorization from the activating JROC Memoranda (JROCM), and are empowered to task subject matter experts (SMEs) from the Joint Staff, and request information and support from SMEs in the Services, Combatant Commands, and other DOD components. The approved FCBs as of the date of this presentation, and their designated sponsors are shown on this chart. JCA 9, Corporate Management, does not have a FCB. Corporate Management issues related to Defense Business Systems are managed by the Deputy Chief Management Officer, along with common gatekeeping processes with JCIDS via the Joint Staff Gatekeeper. Other Corporate Management issues will be handled through one of the listed FCBs with appropriate participation from other organizations.

Functional Capabilities Board Working Groups (WGs)
Provide initial review and assessment of documents prior to review by the FCB Established by the FCB Chair FCB WG Lead: Military Officer, 0-6, or Civilian Equivalent FCB WG Membership: Military, civilian, or contractor support Subject Matter Experts from Joint Staff, Services, Combatant Commands, and other organizations with equity in the FCB’s portfolio. FCB WGs are one level below the FCBs. The FCB WGs provide initial review and assessment of documents and issues within their designated portfolios prior to review by the FCB, and perform other activities at the direction of the FCB Chair. Establishment of the FCB WGs is at the discretion of the FCB Chair to most effectively carry out the responsibilities of the FCB.

Other Related Organizations
In addition to the Gatekeeper, there are several organizations that participate directly with the four levels of boards (JROC, JCB, FCB and FCB WG): Independent Assessment Organizations Within J-8 J-8 / Joint Requirements Assessment Division J-8 / Capabilities and Acquisition Division J-8 / Program and Budget Analysis Division FCB General Officer / Flag Officer (GO/FO) Integration Group FCB 06 Integration Group Joint Weapon Safety Technical Advisory Panel Document Sponsor Milestone Decision Authority

Summary of the Deliberate JCIDS Process
Materiel Solutions Initial Capabilities Document (ICD) Capability Development Document (CDD) Capability Production Document (CPD) Non-Materiel Solutions – Joint DOTmLPF-P Change Recommendation (DCR) Operational requirements development is a team effort; all stakeholders should be involved; involve the user in technical requirements development Remember, there are three JCIDS documents that support materiel solutions. The ICD supports the Materiel Development Decision and the Materiel Solution Analysis (MSA) phase, and specifically drives the AoA. The CDD follows the ICD and provides capability requirements details needed to design, develop, and sustain a system solution. The CDD supports the Development RFP Release Decision, Milestone B and the EMD phase. The CPD follows the CDD, supports a Milestone C decision, and provides the capability requirements to produce the system.

Urgent Needs

Urgent Need Situations
Urgent and compelling needs during crisis and conflict, or anticipated or pending contingency operation Each Service has policies and procedures, but … Service-unique approaches do not address theater-wide Joint Urgent and Emergent Operational Needs Requirements Managers need to stay engaged in the process The deliberate JCIDS process acquire weapons systems using a traditional process, usually taking a few years even when the system uses maximum streamlining. Sometimes, the warfighters need a new capability as soon as possible. Each Service uses various methods to shorten the acquisition timelines to meet urgent and compelling needs during crisis and conflict, but service policies and procedures do not provide address theater-wide multi-Service combatant commander joint urgent operational needs. Here we deal with the joint urgent operational needs processes, as described in the JCIDS Manual, and the rapid acquisition/fielding process described in DODI The Warfighter Senior Integration Group (SIG) is the Oversight Body for DoD Urgent Needs See DoDD , 24 Aug 2012

Urgent & Emergent Threat Lanes
The Ongoing Contingency Lane is the Joint Urgent Operational Needs (JUON) Lane The Anticipated Contingency Lane is the Joint Emergent Operational Needs (JEON) Lane When warfighters report situations that put life at risk or risk mission failure, every service has its own urgent needs procedure. When the situation is a joint problem, the joint urgent operational needs (UON) process applies. The JCIDS Manual provides guidance for the joint UON process. JUONs apply to ongoing combat operations; JEONs apply to anticipated contingency operations. The validation process is almost the same, except that the Gatekeeper will first confirm the contingency referred to in the JEON with the VCJCS, who will then assign either the JCB or the JROC as the JEON validation authority.

Definitions Urgent Operational Need (UON):
Capability requirements identified by a DOD Component as impacting an ongoing or anticipated contingency operation. If left unfulfilled, UONs result in capability gaps potentially resulting in loss of life or critical mission failure. DoD Components, in their own terminology, may use a different name for a UON. Joint Urgent Operational Need (JUON): UONs that are identified by a Combatant Command as inherently joint and impacting an ongoing contingency operation. Joint Emergent Operational Need (JEON): UONs that are identified by a Combatant Command as inherently joint and impacting an anticipated or pending contingency operation. JUONs, JEONs, and DOD Component UONs are used ONLY when the deliberate requirement validation and deliberate acquisition processes, or other means such as the Global Force Management (GFM) process, Joint Manpower Validation Process (JMVP), etc., are not practical for satisfying the capability requirement in the operational timelines. Capability requirements associated with ongoing or anticipated contingency operations and intended to prevent loss of life or critical mission failure that do not require out-of- cycle funding to initiate program execution, should not use a JUON, JEON, or DOD Component UON, but rather generate an ICD, CDD, or CPD for review and validation in the deliberate staffing process. In these cases, the Sponsor may request expedited timeliness from the validation authority and/or the MDA through tailoring of the deliberate processes. Capability solutions for JUONs, JEONs, and DOD Component UONs do not require associated ICDs, CDDs, or CPDs for initial fielding, but may require appropriate CDDs or CPDs to support validation of enduring capability requirements and transition for sustainment and/or further development of capability solutions for enduring use.

Who Initiates a JUON or JEON?
JUONS or JEONS are submitted by a CCMDs or the CJCS/VCJCS While JUONs and JEONs are primarily submitted by the CCMDs, the CJCS/VCJCS may generate a JUON or JEON directly in support of CJCS or VCJCS responsibilities, or to facilitate timely validation of urgent or emergent needs identified by multiple CCMDs or DOD Components. CCMD JUONs or JEONs must be endorsed by the CCMD Commander, Deputy Commander, or Chief of Staff. Administrative modifications to previously validated JUONs or JEONs may be endorsed by the CCMD J8.

JUON and JEON Staffing, Validation and Resourcing
Goal for staffing and validation of JUONs is 15 days; JEONS is 31 days JUON or JEON validation and resourcing Involves Collaborative review by the Lead FCB and the Joint Rapid Acquisition Cell (JRAC) The Gatekeeper (J8 Deputy Director for Requirements (DDR)) Validates JUONs JCB or JROC validates JEONs as determined by VCJCS Solution Sponsor (normally a military department) designated by the JRAC will fund the solution

The Sponsor Component (Service or Agency) recommended by the Gatekeeper and named by the JRAC The Sponsor develops an initial course of action for JRAC review Implementation Recommendation Funding Strategy Recommendation The Sponsor manages the approved JUON / JEON effort Components will use all available authorities to fund, develop, assess, produce, deploy, operate, and sustain urgent operational need (UON) capabilities expeditiously (DoDD )

JUON and JEON Staffing Staffing begins when Gatekeeper receives the document Gatekeeper has 1 day to review and assign to Lead FCB JEONs confirmed by Gatekeeper with VCJCS; VCJCS assigns JCB or JROC as validation authority Lead FCB & Joint Rapid Acquisition Cell (JRAC) assess validity of JUON/JEON and identify potential solutions (if possible – ultimate solution will be determined post-validation) FCB Chair & JRAC make recommendation for or against validation Validation is communicated to JRAC, who designates a solution sponsor to rapidly fund, develop, acquire, field and sustain a solution If not validated, validation authority notifies JUON/JEON sponsor JUON and JEON staffing begins when the Gatekeeper receives the document from the Sponsor. The Gatekeeper has one day to perform initial review. Following confirmation that the JUON meets the appropriate entry criteria, JUONs are assigned directly to a Lead FCB and the JRAC for collaborative review. JEONs are first confirmed by the VCJCS, via the Gatekeeper and DJ-8. The VCJCS will identify the validation authority as the JCB or JROC. Once the VCJCS provides confirmation that the JEON may use the emergent process, JEONs are assigned to a Lead FCB and JRAC for collaborative review. The Lead FCB, in collaboration with the JRAC, assesses the validity of the JUON or JEON and identifies potential solution approaches which could satisfy the capability requirement in the requested timeframe. At the end of their assessment, the Chair of the lead FCB, with a JRAC representative makes a recommendation to the validation authority either for or against validation. Identification of a potential solution approach is a desired outcome to assist in cost and schedule estimations but is not a required outcome, as the ultimate approach to fulfilling the JUON or JEON will be determined following the requirement validation process. Staffing a JUON or JEON will not be unnecessarily delayed to assess potential solutions. The validation authority will make one of the following decisions: 1) Validate and proceed to a solution sponsor. 2)Validate part of the JUON or JEON – proceed through a mix of urgent and deliberate processes. 3)Reject – recommend accept risk, adopt a non-materiel approach, or pursue through deliberate process.

JUON and JEON Follow-On Activities
Quarterly Review. The Joint Staff Gatekeeper, together with the JRAC, reviews validated JUONs and JEONs quarterly to assess progress toward fielding capability solutions in a timely manner Assessment of Operational Utility The original requirement Sponsor will generate an assessment of the capability solution no later than six months after initial delivery to facilitate transition, sustainment, or alternate approaches. Biannual Review. Unless withdrawn earlier by the validation authority or requirement Sponsor, the validation authority reviews validated JUONs and JEONs two years after the validation date Quarterly Review: Similar reviews of validated DOD Component UONs, if used, are at the discretion of the DOD Component validation authority. Assessment of Operational Utility: Does not limit the ability of the solution Sponsor to provide more in-depth operational testing and assessment as part of acquisition efforts, and does not relieve the PM from conducting acquisition assessments in accordance with DODI If the assessment of operational utility is not practical due to capabilities not being fielded to the user, or insufficient quantities being delivered in the first six months, the validation authority may waive the assessment or specify alternative measures for capturing the intent of the assessment. An example of assessment content is in the JCIDS Manual. Biannual Review: The Joint Staff Gatekeeper will communicate with the CCMD and the solution Sponsor to see if the capability requirement has changed or if either a capability solution is working or development is expected to produce a suitable capability solution. In cases where a JUON or JEON was validated and tech development took longer than two years, the FCB and JRAC will assess whether continued development of the capability solution would be more effectively accomplished by validation of enduring capability requirements and transition to the deliberate acquisition process. This review also serves as a driver to determine if validation of enduring capability requirements and transition of a successfully fielded capability solution to an enduring POR is appropriate, if not already initiated by the Sponsor

Rapid Acquisition of Urgent Needs DoDI 5000.02, Encl. 13
Pre-Development: Assess and select a course or courses of action Development Milestone: MDA determines if can be fielded within 2 years; does not require substantial development effort; approves release of RFP Development: MDA, in consultation with the user, determines what deficiencies must be resolved and what risks can be accepted Production Milestone: MDA decides whether to produce and deploy the system Production and Deployment: Capability is provided to the warfighter Operations and Support: Urgent need is sustained over its anticipated life cycle Disposition: 1. Terminate 2. Sustain for Current Contingency 3. Transition to Program of Record See DODI for detailed descriptions of each decision point, and major activities.

JUON and JEON Assessment Conclusion
JUON or JEON Assessment of Operational Utility Conclusion Categories Failure / Limited Success. The solution does not provide operational utility satisfying the capability requirements in the JUON or JEON. Success / Limited Duration Requirement. The solution satisfies the urgent/emergent capability requirement for the limited duration purposes identified in the JUON or JEON Success / Enduring Requirement. The solution satisfies the urgent/emergent capability requirement for the limited duration purposes identified in the JUON or JEON, but also provides enduring capabilities that should remain in the joint force

Disposition Analysis (DoDI 5000.02)
No later than 1 year after the program enters O&S (or earlier if directed by the DoD Component), the DoD Component will appoint an official to conduct a Disposition Analysis The disposition official will recommend one of the following options: Termination: Demilitarization or Disposal Sustainment for Current Contingency Transition to Program of Record DoD Component head and the CAE will review the recommendation and a transition decision will be recorded in a Component Head Disposition Determination Termination: Demilitarization or Disposal. The system will be demilitarized and disposed of in accordance with all legal and regulatory requirements and policy related to safety (including explosive safety) and the environment. The recommendation will be coordinated with the DoD Component or, for JUONS and JEONS, the Combatant Commands. Sustainment for Current Contingency. The system will continue operation and sustainment as an urgent need for the current contingency. Multiple sustainment decisions may be made should the capability require operations and support longer than 2 years; however, such sustainment decisions will be made and re-documented at least every 2 years. The sustained urgent need solution will continue to receive the same priority of action as the original urgent need solution. This recommendation will be coordinated with the DoD Component validation authority. Transition to Program of Record. If the program provides a needed, enduring capability, it may be transitioned to a program of record. The disposition official will recommend to the CAE the acquisition point of entry into the defense acquisition system, and whether the MDA should retain program authority or whether it should transition elsewhere. The DoD Component validation authority will specify the capability requirements documents required to support transition to a new or existing program of record.

Transition to Program of Record (PoR)
Who decides if a solution to an Urgent Operational Need must enter the formal acquisition process? ACAT I – Defense Acquisition Executive (DAE) makes the PoR decision ACAT II or below – Component Acquisition Executive (CAE) / Service Acquisition Executive (SAE) makes the PoR decision May need Materiel Development Decision (MDD) depending on: Status of procurement If the fielded solution needs additional development Funding for additional quantities and sustainment is Service responsibility

Challenge of Rapid Acquisition
Future Focused Very Structured Process Evolved Requirements Analysis of Alternatives Lengthy Development High Visibility on Program Large Investment A Deliberate immediate Now-focused More ad hoc process Broad requirement Quick assessment of alternatives Limited development High visibility on results Limited investment Very Limited Feedback Transition to PoR a

Urgent Operational Need Summary
An urgent / emergent situation that may result in Loss of life and/or Critical mission failure Each service has its own approach to urgent needs that are not joint JUONs / JEONs document joint urgent needs Requirements Managers need to be involved with follow- on activities Planning for ongoing contingency operations may identify urgent operational needs (UONs) which represent potential for critical mission failure or unacceptable loss of life if not satisfied by a rapidly acquired capability solution. These capability requirements may qualify for submission as Joint UONs (JUONs) or DOD Component UONs for expedited validation and rapid acquisition efforts. Planning for anticipated contingency operations may identify operational needs which represent potential mission failure or unacceptable loss of life once operations commence, if not satisfied by a rapidly acquired capability solution. These capability requirements may qualify for submission as Joint Emergent Operational Needs (JEONs) or DOD Component UONs for expedited validation and rapid acquisition efforts.

Waivers Waivers can be used for:
Request to submit a CDD without an ICD (ICD waiver is not required to submit a Joint DCR without a preceding ICD) Request to submit a CPD without a preceding ICD and/or CDD ICD and/or CDDs may be waived in cases where it is best to proceed directly to MS B or C (GOTS/COTS solutions, transitioning UONS/JUONS, successful JCTDs, etc.. Tripwire relief – when a sponsor does not believe a tripwire review is necessary. J-8/DDR is the approval authority for: ICD, CDD and tripwire waiver requests Deviations from processes described in the JCIDS Manual The waiver request will be submitted in memo form into the KM/DS system as the document type that is being waived (e.g., ICD waiver request will be submitted as an ICD document type), and must be endorsed by the Service, CCMD, or other DOD Component J8 equivalent or higher. The waiver request must include the rationale/justification for why an ICD and/or CDD is not required, the source(s) of equivalent information, and the proposed path forward. In cases where an AoA recommends processing directly to a CPD and MS-C decision, the post AoA review by the FCB satisfies the intent of the waiver request. The Joint Staff Gatekeeper assigns the waiver request to the appropriate FCBs and a J- 8/Capabilities and Acquisition Division (CAD)for evaluation within 4 calendar days of receiving the waiver request. The lead FCB, in coordination with the J-8/CAD AO, will develop a recommendation for approval/disapproval of the waiver within 13 calendar days. After receiving the recommendation from the Lead FCB, the Joint Staff Gatekeeper will approve or disapprove the request within 4 calendar days. Not every deviation requires a waiver request. An ICD waiver request is not required for Joint DCRs without associated ICDs. In cases where an AoA recommends processing directly to a CPD and MS-C decision, the post AoA review by the FCB satisfies the intent of the waiver request.

Guiding Principles Know the requirements– the requirements/acquisition community should not only clearly understand the requirements, but should be actively engaged with the user in establishing realistic and achievable requirements within budget constraints. Question the requirements – if a requirement doesn’t make sense, question it – the answer may be surprising. Are the requirements realistic – is it physically possible to meet the requirement? Can it be tested? Is an 80% solution adequate and field the remaining 20% when technology is mature enough? Beware of derived requirements – an engineer’s “derived” technical requirement can take on a life of it’s own; keep focused on the user’s operational requirements. Tech Reviews – JCIDS sponsor/user should attend PDR and CDR to answer questions on operational requirements. Configuration Steering Boards (CSBs) – PM has the authority to recommend descoping options and to object to new requirements after MS B, unless approved by the CSB. Must be coordinated with the requirements professionals Know your requirements and question the requirements: That applies to both acquisition and requirements stakeholders. The requirements manager should lead an IPT with all stakeholders (PMO, testers (DT and OT), etc..) to ensure the KPPs and KSAs provide the capabilities required by the ICD, are supported by the AoA, and are affordable and testable. Is each requirement realistic: Can it be achieved within the timeframe required? Is it testable? Is it affordable? Is mature technology available – if not, should one or more requirements (KPPs) be delayed to future increments? Can KPPs be modified / eliminated? If KPPs are modified or eliminated will it necessitate a change in CONOPs, quantity, or is the solution no longer viable? Derived requirements: Do the engineers understand the operational requirements; the operational concept? If not, they need to get together with the requirements manager before they develop the technical requirements. (Perhaps the RM could attend the Engineering kickoff meeting to ensure they go down the right track?) Tech Reviews: Technical design attributes should support that requirement and not go out of scope (and off budget) to make some hard charging engineer happy. Requirements managers should be invited to tech reviews, particularly PDR and CDR and encouraged to ask questions to ensure they understand how the design will mitigate or resolve the gaps in capability. CSBs: First required in Now required by and public law. Should be helpful in controlling requirements creep

Requirements Challenges
Gaming the System by Specifying the Solution too Early Incomplete or Rushed Analysis Vague/Poorly Written Requirements Good Briefings Based on Poor Documents Confusing Requirements with Specifications Not Following Up on Results of DAS Reviews and T&E results Requirements Creep (Operational & Technical) Misusing the Urgent/Emergent Requirements Determination Processes Cost and Schedule Estimates Based on Incomplete or Poorly Written Requirements (Operational and Technical) Does the ICD identify the materiel solution? Only “recommended approaches” are in the ICD. The acquisition community decides, along with the requirements manager, what approach(es) to take, and the AoA looks at alternatives, not JCIDS. Analysis: Sometimes the underlying analysis is either not apparent, not current or was not conducted. There are approved ICDs lacking any analysis. JCIDS process requires supporting analysis to be posted to KM/DS. Briefings: Powerpoint charts are not “requirements”. Do homework first, then do the briefing. Ensure briefing is based on documented evidence. JCB and JROC do not see documents —just briefings and briefings can get modified to the point that they no longer resemble the document. Requirements vs. Specs. Operational requirements are in CDD/CPD; specs are in contracts. Don’t confuse them when communicating – particularly to Congress. Results of decision reviews and program reviews – keep in mind what the ADM or other minutes expects; share test results with all stakeholders – requirements community and contractor. Requirements creep: Don’t blame the RM if engineers derive requirements beyond scope of needed capabilities. Most RMs are operators and they will gladly accept more capability. If engineers derive additional requirements, and the RM thinks they are great, reference the ICD/CDD to see if they are requirements or desirements Urgent Needs: JUONS are only to avoid loss of life or mission failure; don’t fudge. Cost and schedule: Share the operational and tech specs with your cost estimators. Make sure the program schedule is in sync with all required events – staff with all stakeholders.

Joint Capabilities Integration and Development System (JCIDS) A Primer

Similar presentations

Presentation on theme: "Joint Capabilities Integration and Development System (JCIDS) A Primer"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Joint Capabilities Integration and Development System (JCIDS) A Primer

Similar presentations

Presentation on theme: "Joint Capabilities Integration and Development System (JCIDS) A Primer"— Presentation transcript:

Similar presentations

About project

Feedback