The Information Technology (IT) Box A Primer

Transcription

1 The Information Technology (IT) Box A Primer Sources: CJCSI H, 31 Aug 2018 JCIDS Manual, 31 Aug 2018 Patrick Wills Dean, Defense Systems Management College Defense Acquisition University work: cell: Jan 2019

2 IT Box Topics IT Box Background Assumptions Applicability Information Systems Initial Capabilities Document (IS-ICD) Information Systems Capability Development Document (IS-CDD) Governance & Requirements Management Successor Documents and the Acquisition Process Examples 2

3 3 IT Box Background Why implement an IT box? Moore s Law: The number of transistors on an integrated circuit doubles approximately every months. The US has been able to leverage rapidly-evolving IT for decisive military advantage. However, the traditional JCIDS process does not provide the required flexibility to take full advantage of evolving commercial information technology. JROCM The JROC wanted to ensure that IT programs had the flexibility to plan for and incorporate evolving technology throughout the program s lifecycle. CJCSI and the JCIDS Manual Expand on the concepts in JROCM

4 Assumptions The Requirements, Acquisition and Financial communities agree that development of Information Systems (IS) is different from weapon systems Modification of processes and documentation are appropriate The Test communities (DT/OT) can deliver on more responsive testing to enable more rapid delivery of capabilities Necessitates incremental/iterative development and testing Validation Authority for managing IS requirements can be pushed down to the lowest level to allow for rapid changes/decisions 4

5 5 Reasons for IS Variants of JCIDS Documents Traditional JCIDS documents are not supportive of the rapid pace of development necessary with IS systems/capabilities In conjunction with the acquisition process*, the JCIDS process needs to meet the needs of the operational user so that new capabilities can be delivered rapidly, and adapted to changes in the operational environment Desired Outcome - Provide an agile and responsive capability requirements process for rapid development of IS capabilities *DODI provides software intensive program models

6 Information Systems (IS) Development Streamlining the Requirements Processes Sponsors should consider the IS Initial Capabilities Document (IS-ICD) or IS Capability Development Document (IS-CDD) for capability requirements likely to be addressed by IS solutions, software development, and off-the-shelf hardware. IS-ICDs and IS-CDDs are variants of regular ICDs and CDDs, implementing the IT Box construct. Both streamline the requirements process by delegating oversight and formats for subsequent documents. Provides IS programs greater flexibility to incorporate evolving technologies and achieve faster acquisition. - No return to the JROC unless new core capabilities added to the IS-ICD/IS- CDD 6

7 The IT Box IS-ICD Capability Requirements & Initial Minimum Values List & Describe Capability Requirements = initial minimum values IS-CDD Key Performance Parameters & Initial Minimum Values List & Describe KPPs = initial minimum values Requirements Organization & Oversight Flag-level oversight [describe oversight body] Chair Members (list) JROC Approved IS-ICD or IS-CDD Application & System Software Development Cost Controls Per year = $XXX Lifecycle cost = $XXX Rationale Hardware Refresh, System Enhancements & Integration Cost Controls Per year = $XXX Lifecycle cost = $XXX Rationale Further definition of capabilities through Requirements Definition Packages(RDPs)/Capability Drops (CDs) See notes page for additional information 7

8 Applicability of the IT Box IT Box Applies to: - Information Systems (IS) with software development only - Includes integration onto commercial off-the-shelf hardware - Program costs that exceed $15 million IT Box DOES NOT Apply to: - IS with a developmental cost less than $15 million - Defense Business Systems (DBS) (see DoDI ) - Hardware development efforts or capturing capability requirements which span a broad scope of combined hardware, software, and/or DOTmLPF-P efforts. 8

9 IS-ICDs are Specifically Appropriate for: Information System ICD (IS-ICD) - Capability requirements when a Capabilities-Based Assessment (CBA) or other study results clearly state that an IS solution is the only viable approach to be considered. - Procurement or modification of Commercial off the Shelf (COTS)/Government off the Shelf (GOTS) IS products is from domestic or international sources, or the development of dualuse technologies. - Additional production or modification of developed DoD, allied, partner-nation, or other U.S. Government agency IS products. - Development, integration, and acquisition of customized application software - Development of both offensive and defensive cyber capability that meet the remaining criteria for an IS-ICD and require the flexibility that the IT process provides. - 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 Capability Development Documents (CDDs) are not required as successor documents for an IS-ICD the delegated authority may prescribe alternate document formats See notes page for additional information 9

10 10 IS-ICDs are NOT Appropriate for: When an IS-ICD Is Not Appropriate Software embedded in 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, such as a manned or unmanned vehicle, 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 Requirements for Defense Business System (DBS) capabilities

11 Initial Minimum Values The IT Box model uses initial minimum values in place of initial objective values so that the baseline capability is clearly specified, and the delegated oversight body has flexibility to further develop capabilities without revalidation of the capability requirements document. Initial minimum values represent the achievable level of required capability needed to incorporate current technology to meet the baseline capability. 11

12 12 IT Box Components for IS-ICD Organization & Oversight Flag-level oversight through (describe/list) Chair & Members Capability Requirements & Initial Minimum Values Capability Requirement 1 [Describe] = Initial minimum value Capability Requirement 2 [Describe] = Initial minimum value Capability Requirement N [Describe] = Initial minimum value (include Net Ready Performance Attribute if applicable for joint interoperability) Boundaries JROC-Approved IS-ICD [Topic Name] Oversight Organization [name] Execution Organization [name] Application & System Software Development Cost Controls Per year = $xxx Life cycle cost = $xxx Rationale Hardware Refresh, System Enhancements, & Integration Cost Controls Per year = $xxx Life cycle cost = $xxx Rationale

13 IS-CDD Information Systems CDD (IS-CDD) Implements IT Box model; but is not a follow-on to an IS-ICD Performance attributes (KPPs, KSAs and APAs) may be quantified in terms of initial minimum values rather than threshold/objective values. IS-CDDs streamline the requirements process by delegating oversight and formats for subsequent documents as identified in the IS-CDD. 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. In cases where the potential for use of the IT Box construct is unclear or in dispute, the Joint Staff Gatekeeper, in consultation with the validation authority as needed, will determine whether an CDD or IS-CDD will be used The validation authority may prescribe appropriate successor documents See notes page for additional information 13

14 Organization & Oversight Flag-level oversight through (describe/list) Chair & Members IT Box Components for IS-CDD Key Performance Parameters & Initial Minimum Values List/Describe KPPs = Initial Minimum Values (include Net Ready Performance Attribute if applicable for joint interoperability) Boundaries JROC-Approved IS-CDD [Topic Name] Oversight Organization [name] Execution Organization [name] Application & System Software Development Cost Controls Per year = $xxx Life cycle cost = $xxx Rationale Hardware Refresh, System Enhancements, & Integration Cost Controls Per year = $xxx Life cycle cost = $xxx Rationale Mandatory KPPs. Only two of the four mandatory KPPs apply to an IS-CDD: The System Survivability (SS) KPP and Sustainment KPP. See notes page for additional information 14

15 15 Key Difference In Usage: IS-ICD & IS-CDD Key difference in usage of IS-ICDs and IS-CDDs is whether the Analysis of Alternatives (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 or other study that an IS solution is the only viable approach to be considered. - The AoA conducted in the Materiel Solutions Analysis (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.

16 Successor Documents for IS-ICDs and IS-CDDs JCIDS Manual provides the 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) 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 identifies KPPs, KSAs, and APAs, and non-materiel changes Capability Drop (CD) (or equivalent) describes 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. Could be developed through a rapid prototyping effort with the user to ensure it meets their needs. Commonly, multiple CDs would be derived from a RDP, or IS-CDD See notes page for additional information 16

17 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 See notes page for additional information 17

18 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 See notes page for additional information 18

19 IS-ICD & IS-CDD Successor Documents Process Flow 19 This example of RDPs and CDs for managing followon efforts is illustrative and is not intended to limit potential flexibility provided by the IS-ICD and IS-CDD. Actual names, content, approval process and implementation guidance are at the discretion of the delegated oversight authority. Adapted from Figure A-5, JCIDS Manual, 31 August 2018

20 20 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 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.

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

22 22 Capabilities Required Capability Requirements/KPPs and Initial Minimum Values: The initial minimum performance levels required for the entire IS program. Objective values not used. It is understood and expected that performance will improve as technology capability improves. Capabilities Required Requirements Organization & Oversight JROC Approved IS-ICD or IS-CDD $ Applications & System Software Development Cost Controls $ Hardware Refresh, System Enhancements & Integration Cost Controls

23 Estimated Development and Sustainment Costs Capabilities Required Requirements Organization & Oversight JROC Approved IS-ICD or IS-CDD Application and System Software Development: Estimated costs per year & life-cycle $ Applications & System Software Development Cost Controls $ Hardware Refresh, System Enhancements & Integration Cost Controls Hardware Refresh, System Enhancements & Integration: Estimated costs per year and life-cycle Cost estimates Seek help for initial and updated cost estimates from program office/ acquisition command Cite applicable life cycle cost analysis, cost models, and business cases A table reflecting programmed funding by year is required for IS-ICD and IS-CDD Ensure cost estimates have been reviewed by Component Cost Agency 23

24 Annual/Biennial Functional Capabilities Board (FCB) Review IS-ICD. Sponsor must provide the Lead FCB an update a year following the validation and then biennially after. IS-CDD. Sponsor must provide the Lead FCB an update every second year following the validation. The Lead FCB will determine if the JROC or JCB should review the following items and will make appropriate recommendations for action. Progress in delivering capability solutions within the required timeframe and available funding. Compliance with applicable EA and data standards. Other items as identified by the IS-ICD/IS-CDD validation memo 24

25 Examples 25

26 26 Example JROC IS-ICD Approval Memo JROC approval. JSD of JCD Interest assigned Oversight delegated to the Navy Capabilities Board Required to return to JCB if funding levels exceed or capabilities not achieved.

27 Example Quad Chart for Briefing JROC 27