Lesson 2 SE Policies/Current Events

1. Lesson 2 SE Policies/Current Events

2. Learning Objectives(Lesson) Relate how the Defense Acquisition Process, the Requirements Generating Process, and the Budget Process are reflected in the DoD 5000 series documents and how they influence DoD Systems Engineering across the acquisition life cycle. • Identify the role of the major decision support systems (Defense Acquisition System, JCIDS, and PPBE) and their relationship to Systems Engineering (SE). • Given current trend data on DoD acquisition cost, schedule and performance, identify how the current SE policies are attempting to reverse the negative trends. • Identify the characteristics of the acquisition program models as described in the DoDI 5000.02. • Identify the purpose of the SE activities throughout the acquisition lifecycle as described in DAG Chapter 3.

3. Learning Objectives(Homework) Apply the processes for SE Design, Configuration Management, Performance Specifications development, and Statement of Work development in a given DoD acquisition scenario to reduce technical risk. • Describe the characteristics of effective technical communication. • Given an acquisition scenario, use the "design' part of the SE Technical Processes to demonstrate how to flow-down a product requirement through the Requirements Analysis and Architectural Design (Technical Design) (Monday) steps. • Given a Work Breakdown Structure (WBS) exercise, discuss how the WBS can be used to support DoD Risk Management processes. (Tuesday) • Given a manufacturing scenario, explain how DoD Earned Value Management (EVM) techniques of CPI and SPI are used to evaluate program status. (Tuesday) • Given a list of specification requirements, identify which requirements are performance specifications(Wednesday) and which requirements are detailed specifications. • Correct a list of poorly written Statement of Work (SOW) statements (Thursday)

4. Lesson 2 Recommended Reading • Operation of the Defense Acquisition System • DoDI 5000.02 • Systems Engineering (SE) • DAG Chapter 3 • Joint Capabilities Integration and Development System (JCIDS) • CJCSI 5123.01H

5. https://media.dau.mil/media/Defense+Acquisition+System+Overview/0_e1trktnqhttps://media.dau.mil/media/Defense+Acquisition+System+Overview/0_e1trktnq The Defense Acquisition System (DAS) DAS PPBE JCIDS As per the DAG: The management process by which the Department acquires weapon systems, automated information systems, and services.

6. Performance of the Defense Acquisition System 2016 Annual Report https://www.acq.osd.mil/fo/docs/Performance-of-Defense-Acquisition-System-2016.pdf The next few charts were taken from the Performance of the Defense Acquisition System 2016 Annual Report to demonstrate DoD acquisition performance trends as viewed by Congressional/DoD Leadership.

7. Cumulative Growth Over Original MS B MDAP Planned Total RDT&E Funding (CY 1997–2015) Reference: PERFORMANCE OF THE DEFENSE ACQUISITION SYSTEM 2016 ANNUAL REPORT

8. System Beyond Low Rate Initial Production (BLRIP) Operational Test (OT) Ratings DoD-Wide (FY 1984–2016Q1) Reference: PERFORMANCE OF THE DEFENSE ACQUISITION SYSTEM 2016 ANNUAL REPORT

9. Defense Acquisition System Policy • DoD Directive 5000.01, “The Defense Acquisition System” • The overarching management principles and mandatory policies that govern the Defense Acquisition System. • Most recent version: May 2003 (certified current 2007) • DoD Instruction 5000.02, “Operation of the Defense Acquisition System” • Provides detailed procedures that guide the operation of the system through statutory and regulatory requirements that govern defense acquisition programs. • “Significant Changes” in recent versions released (see following slides): • Jan 2015 • Jan 2017 (Change 1) • Feb 2017 (Change 2) • Aug 2017 (Change 3) Current Version

10. 2015 DoDI 5000.02 • The overall tone of the document—moved from compliance to thoughtful planning. • Example Program Models-tailored for the product being acquired and designed to serve as benchmarks for structuring programs. • Re-written and Re-focused acquisition process procedures. • New/Expanded Policy: • Program Management • Program Protection, including Cybersecurity • Intellectual Property • Operational Test and Evaluation (significantly expanded) • Life-Cycle Sustainment • Affordability • Defense Business Systems • Rapid Fielding of Capabilities

11. 2015 DoDI 5000.02 (cont’d) New Systems Engineering (SE) content in the following areas: • Development Planning • Systems Engineering Trade-Off Analysis • Technical Performance Measures and Metrics • Manufacturing and Producibility • Software • Program Protection • Reliability and Maintainability (R&M) • Open Systems Architectures • Insensitive Munitions • Design Reviews • Program Support Assessments (PSAs) • Documentation: • Test and Evaluation Master Plan (TEMP) now required at Milestone A vice Milestone B; Test and Evaluation Strategy (TES) formerly due at Milestone A is no longer required. • Acquisition Strategy now due at Milestone A vice Milestone B; Technology Development Strategy formerly due at Milestone A no longer required.

12. 2017 DoDI 5000.02 (Changes 1, 2, and 3) • Retains same “tailorable” program models from 2015 version • Modifies and clarifies roles & responsibilities for Milestone Decision Authority (MDA) approval • Multiple changes to Milestone & Phase Information Requirements including: • MDA approves Systems Engineering Plan (SEP) • Validated On-line Life-cycle Threat (VOLT) report replaces System Threat Assessment Report (STAR) • More detail on Program Management assignment and responsibilities • Expands SECDEF authority to waive acquisition law/regulation • Removes “Defense Business Systems” enclosure (incorporated into DoDI5000.75) • Urgent Capability versus Rapid Fielding • Expands “Cybersecurity” into its own separate enclosure

13. Product-Tailored Acquisition Models in the DoDI 5000.02 • Provides four basic models and two hybrid models • Model 1: Hardware Intensive Program • Model 2: Defense Unique Software Intensive Program • Model 3: Incrementally Deployed Software Intensive Program • Model 4: Accelerated Acquisition Program • Hybrid Acquisition Programs: • Model 5: Hybrid Program A (Hardware Dominant) • Model 6: Hybrid Program B (Software Dominant) • “The models provide baseline approaches. A specific program should be tailored to the unique character of the product being acquired” (as per DoDI 5000.02 Change 3 of August 10, 2017).

14. DoDI5000.02 Acquisition Program Structure • DoDI5000.02 Change 3 of Aug 10, 2017 retains a similar acquisition program phase structure to the legacy DoDI 5000.02 (2008) with some exceptions; • Technology Development Phase now called the “Technology Maturation and Risk Reduction (TMRR) Phase” (except in Incrementally Fielded Software Intensive and Accelerated Acquisition Programs). • “CDD Validation” and “Development Request for Proposal Release Decision” Points added in TMRR phase (except in Accelerated Acquisition Program model). • “Sloped lines” transitioning from one phase to another indicate some functions from previous phase may still be ongoing. • Character of product being acquired dictates acquisition program model utilized and associated tailoring. DoDI 5000.02 (2008) Acquisition Program Structure DoDI 5000.02 Change 3 of Aug 10, 2017 Acquisition Program Structure (Model 5: Hybrid Program A (Hardware Dominant) shown)

15. Model 1: Hardware Intensive Program Source: Figure 3, DoDI5000.02 Change 3 of Aug 10, 2017 • Model of a hardware intensive development program such as a major weapons platform; “Classic” model that has existed in some form in all previous editions of this instruction. • Starting point for most military weapon systems; however, these products almost always contain software development resulting in some form of Hybrid Model A.

16. Model 2: Defense Unique Software Intensive Program Source: Figure 4, DoDI5000.02 Change 3 of Aug 10, 2017 • Dominated by the need to develop a complex, usually defense unique, software program that will not be fully deployed until several software builds (number of builds dependent on specific system needs) have been completed. • Leverages planned software builds – a series of testable, integrated subsets of the overall capability – which together with clearly defined decision criteria, ensure adequate progress is being made before fully committing to subsequent builds; Examples include military unique command and control systems and significant upgrades to the combat systems found on major weapons systems such as surface combatants and tactical aircraft.

17. Model 3: Incrementally Deployed Software Intensive Program Source: Figure 5, DoDI5000.02 Change 3 of Aug 10, 2017 • Distinguished from the previous model by the rapid delivery of capability through multiple acquisition increments, each of which provides part of the overall required program capability; Each deployment results from a specific build, and provides the user with mature and tested sub-elements of the overall incremental capability. • Applies in cases where commercial off-the-shelf software, such as commercial business systems with multiple modular capabilities, are acquired and adapted for DoD applications.

18. Model 4: Accelerated Acquisition Program Source: Figure 6, DoDI5000.02 Change 3 of Aug 10, 2017 • Amodel that applies when schedule considerations dominate over cost and technical risk considerations; compresses or eliminates phases of the process and accepts the potential for inefficiencies in order to achieve a deployed capability on a compressed schedule. • For products that must be developed and acquired as quickly as possible, usually motivated by a potential adversary achieving technological surprise, and featuring a greater acceptance of program risk (Joint Urgent Operational Needs (JUONS) for example are included in this model).

19. Model 5: Hybrid Program A (Hardware Dominant) Source: Figure 7, DoDI5000.02 Change 3 of Aug 10, 2017 • A model depicting how a major weapons system combines hardware development as the basic structure with a software intensive development that is occurring simultaneously with the hardware development program. • NOTE: For the purposes of this course, Model 5 Hybrid Program A (Hardware Dominant) will be used as the baseline model for graphical depictions and discussion of topics related to SE and the acquisition processes contained within most areas of the Student Book; Real world programs will of course use the model most appropriate for the product being acquired.

20. Model 6: Hybrid Program B (Software Dominant) Source: Figure 8, DoDI5000.02 Change 3 of Aug 10, 2017 • Depicts how a software intensive product development can include a mix of incrementally fielded software products or releases that include intermediate software builds. • For both hybrid A and B models, highly integrated complex software and hardware development poses special risks to program cost and schedule performance.

21. General Overview of the Planning, Programming, Budgeting, and Execution (PPBE) Process PPBE DAS JCIDS As per the DAG: The Department’s strategic planning, program development, and resource determination process.

22. Planning, Programming, Budgeting, and Execution (PPBE) • Planning, Programming, Budgeting, and Execution (PPBE) is the primary vehicle for identifying mission requirements and translating them into the budget and personnel resources required to accomplish a mission. • Through the evaluation of alternatives, PPBE ensures that the highest priority requirements are funded.

23. PPBE Phases • Planning • Assess capabilities / review threat • Develop guidance • Programming • Turn guidance into affordable packages • 5-year program (Future Years Defense Program, FYDP) • Budgeting • Prepare defensible budget • Scrub budget years • Test for efficient funds execution • Execution • Develop performance metrics • Assess actual output vs. planned performance • Adjust resources to achieve desired performance goals

24. Program Objective Memorandum(POM) • Programming begins with the development of a POM by each DoD Component. The goal is to construct a balanced set of programs responding to priorities of the Joint Programming Guidance within fiscal constraints. • When completed, the POM provides a fairly detailed, comprehensive description of proposed programs, including a time-phased allocation of resources (forces, funding, and manpower) by program, projected five years into the future. • The DoD Component may also describe important programs not fully funded (or not funded at all) in the POM, and may assess the risks associated with the shortfalls. • Thorough phase-by-phase process reviews ensure that major issues (mission-readiness, quality-of-life for military personnel, modernization, administration priorities, and legislative initiatives) have been addressed within the constraints of total DoD resources.

25. General Overview of the Joint Capabilities Integration Development System (JCIDS) JCIDS DAS PPBE As per the DAG: The systematic method to support the Joint Requirements Oversight Council (JROC) and Chairman of the Joint Chiefs of Staff (CJCS) responsibilities in identifying, assessing, validating, and prioritizing Joint military capability requirements.

26. Where Do Requirements Come From?

27. Summary of JCIDS August 2018 Major Changes • CJCSI 5123.01H: “CHARTER OF THE JOINT REQUIREMENTS OVERSIGHT COUNCIL (JROC) AND IMPLEMENTATION OF THE JOINT CAPABILITIES INTEGRATION AND DEVELOPMENT SYSTEM (JCIDS)”, released Aug 31, 2018. • Cancels prior CJSCI 3170.01 series and absorbs content. • Updated Joint Requirements Oversight Council (JROC) functions. • Describes multiple entry points into JCIDS; urgent/emergent needs, deliberate planning needs, and insertion of a Science and Technology (S&T) prototype or other innovative approaches. • JCIDS MANUAL: released Aug 31, 2018. • Reduces number of mandatory Key Performance Parameters (KPPs) from six to four. • Eliminates Capability Production Document (CPD) at Milestone C. • Modifies Initial Capabilities Document (ICD) and Capability Development Document (CDD) formats.

28. Key JCIDS Documents • Initial Capabilities Document (ICD): Describes capability requirements in terms of operational attributes with appropriate qualitative parameters. • Supports Materiel Development Decision (MDD) prior to MSA phase • Capability Development Document (CDD): Defines authoritative, measurable, testable parameters across one or more increments of a materiel solution. Defines Key Performance Parameters (KPPs), Key System Attributes (KSAs), and Other System Attributes (OSAs) (see following slides for JCIDS Manual definitions). • Draft (Component endorsed) due at Milestone A • Validated and released prior to Development RFP Release Decision Point • Updated as needed for Milestone C

29. JCIDS Definitions • Key Performance Parameter (KPP) - Performance attributes of a system considered critical or essential to the development of an effective military capability. • Key System Attribute (KSA) - Performance attributes of a system considered important to achieving a balanced solution/approach to a system, but not critical enough to be designated a KPP. • Additional Performance Attribute (APA) - Performance attributes of a system not important enough to be considered KPPs or KSAs, but still appropriate to include in the CDD. Source: JCIDS Manual, Aug 2018

30. JCIDS Definitions (cont’d) • Threshold- Performance below the threshold value is not operationally effective or suitable or may not provide an improvement over current capabilities. • Objective - The objective values are applicable when a higher level of performance represents significant increase in operational utility. If applicable, desired operational goal achievable but at higher risk cost, schedule, and technology. Performance above objective does not justify additional expense. • Tradespace - The difference between threshold and objective values sets trade space for balancing multiple performance attributes while remaining above the threshold values. Source: JCIDS Manual, Aug 2018

31. Mandatory JCIDS Key Performance Parameters (KPPs) Mandatory JCIDS KPPs (4): • Force Protection – Ensure protection of occupants, users, or other personnel who may be adversely affected by the system or threats to the system. • System Survivability – Promote the development of critical warfighter capabilities that can survive kinetic and non-kinetic threats across domains and applicable environments including space: • Kinetic: Traditional, Non-traditional, and Chemical, Biological, Radiological, and Nuclear (CBRN) (including Electromagnetic Pulse) • Non-Kinetic: Cyber and Electromagnetic Spectrum. • Sustainment– Ensure an adequate quantity of the capability solution will be ready for tasking to support operational missions. • Energy- 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 under applicable threat environments. • Note: As per the Aug 2018 JCIDS changes, Net-Ready and Training are no longer mandatory KPPs. Net-Ready is still required but can be addressed as a KPP, KSA, or APA depending on the system. Source: JCIDS Manual, Aug 2018

32. Navy Mandatory Cost/Schedule Parameters and KPPs • Key Cost Parameter: Identify the appropriate procurement cost per unit (e.g. Average Procurement Unit Cost- APUC) to become threshold value. Objective value will be at least 5% below threshold value. • Key Schedule Parameter: Threshold value shall be Initial Operational Capability (IOC) date. Objective value will be at least 6 months earlier. • Space, Weight, Power, and Cooling (SWaP-C) Margins KPP: Defined as a KPP for platforms which will carry payloads. The amount of margin available in a platform will be defined in terms such as cubic or square feet, center of gravity, tons, megawatts, and British Thermal Units. Reference: CNO Memo Ser. N00/100050 dated 11 August 2014

33. Statutory/Regulatory Definitions • Statutory Requirement: Statutory refers to laws passed by the federal government. • Regulatory Requirement: Regulatory refers to a rules issued by a government agency to manage their workforce. • DoDI 5000.02, Enclosure 1 lists the Statutory and Regulatory requirements in Table 2. Milestone and Phase Information Requirements. • DAU Milestone Document Identification (MDID) Tool available at https://www.dau.mil/mdid/Pages/Default.aspx

34. Lesson Artifacts • Student Book: Student homework allows for a shorter Friday class day. • Homework Areas: • Technical Design Processes • WBS/EVM • System Performance Specifications • Statement of Work • Exercise & Artifact Book: Technical Review Summary extract from DAG