Defense Acquisition Changes & Systems Engineering Vik Chauhan, Indu Singh
April 23, 2012
Agenda Defense Acquisition Changes Business Capability Lifecycle Systems Engineering role in Acquisition Support Case Studies • JIEDDO • iEHR
Acquisition 101
3
Integrated Defense Acquisition, Technology, and Logistics Life Cycle Management System
Current Acquisition Documentation IT Related Documentation for DOD 5000 Acquisitions Material Solution Analysis MDD • AoA Study Guidance • AoA Study Plan • Initial Capabilities Document*
Technology Development
Production & Deployment
Engineering & Manufacturing Development
A
B B
• Acq Decision Memorandum* • Act Info Assurance Strategy* • AoA* • Benefit Analysis & Determination* # • Certification of Spectrum DD1494* • Clinger Cohen Act Compliance* • Consideration of Technology Issues* # • Cooperative Opportunities* # • Data Mgmt Strategy* # • DoD CIO Confirmation of CCA Compliance* • DoD Component Cost Estimate* • Economic Analysis* • Exit Criteria* • ICE* • Info Support Plan* • IUID Implementation Plan* • Life Cycle Signature Support Plan* • Market Research* • MDA Program Certification* • Net Centric Data Strategy* • Nunn McCurdy Assessment & Certification* • Program Protection Plan* • System Engineering Plan* • System Threat Assessment Report* • Technology Development Strategy • T&E Strategy
• Acq Program Baseline* • Acq Strategy* • Affordability Assessment* • Alternate LFT&E Plan$ • Capabilities Development Document • Competition Analysis* # • Core Logistics Analysis, Source of Repair Analysis* # • Corrosion Control Plan* • Cost Analysis Requirements Document* • Independent Technology Readiness Assessment (ACAT 1D)* • Industrial Base Capabilities Considerations* # • LFT&E Waiver from Full-Up System Level Testing% • Life Cycle Support Plan*# • LRIP Quantities • Manpower Estimate* • Operational Test Agency Report of Operational T&E Results* • PESHE* • Post-CDR Report • Post-PDR Report • Replaced System Sustainment Plan • Spectrum Supportability Determination* • System Threat Assessment* • Technology Readiness Assessment* • TEMP*
C C • Capabilities Production Document • Military Equipment Valuation* # • Operational Test Plan
Operations & Support
FRP • Beyond LRIP Report! • IT and NSS Joint Interoperability Test Certification • IOT&E completed • LFT&E Report% • Post Implementation Review
Other Documentation • Assessment & Certification of a Critical Change to Defense Committees • CCDR • Defense Acq Executive Summary • DBSMC certification • MAIS Annual Report to Congress • MAIS Quarterly Report • Notice of MAIS Cancellation or Significant Reduction in Scope • Notification of Significant Change to the Defense Committees • Program Deviation Report • Selected Acq Report • SRDR • Unit Cost Report • * Document is created in this phase and updated periodically throughout the life cycle • # Part of TDS or Acquisition Strategy • Red: Statutory requirement • Black: Regulatory requirement • Green: Statutory requirement for MAIS programs • Blue: Statutory and Regulatory requirement • % OSD LFT&E oversight programs only • ! OSD OT&E oversight programs only • $ OSD LFT&E oversight programs with waiver from full-up, system-level testing only
Why Reform IT Acquisition? Using current acquisition processes and governance…..the result: • Does Not Meet User Needs • Takes Too Long To Deliver Capabilities • Costs Too Much to Acquire • Allows Duplicative Acquisition “On average, it takes the DoD 81 months from when an IT program is first funded to when it becomes operational…By comparison, the iPhone was developed in 24 months. That is less time that it would take us to prepare and defend a budget and receive Congressional approval for it. Steve Jobs gets an iPhone. We get a budget. It’s not an acceptable trade. “ Bill Lynn, DEPSECDEF (May 2010)
For Official Use Only
6
“We can't solve problems by using the same kind of thinking we used when we created them.” Albert Einstein
7
DoD Response GOAL
Congressionally Mandated 804 IT Acquisition Process Improvements
Dramatic improvement to the pace and quality of IT deliveries..and reduction in costs
IT Acquisition Reform (Section 804) Response Objectives: IT Acquisition Reform Guiding Principles (Section 804) – – – – –
Deliver Early and Often – Be responsive to the users needs Incremental and Iterative Development and Testing Rationalized Requirements – Balance user needs with constraints Flexible/Tailored Processes – Customize to IT category Knowledgeable and Experience IT Workforce – Understands IT uniqueness
Provide a simplified, tailorable approach for delivering IT capability that: – Favors mature technology (OTS), emphasizes the Enterprise and discards redundancy 8
IT Acquisition Tenets Deliver meaningful increment of capability in 18 months or less. Larger capabilities will be delivered in a series in increments, each of which provides useful capability. Planning and execution will occur within a level of effort funding top line. Use outcome and performance based metrics. Metrics define improvements to the capability and provide clear and coherent way to measure both process and system improvements. Leverage enterprise services and assets (Emphasize open standards and common platforms) Emphasize the use of open standards and common platforms by use of enterprise systems, processes, infrastructure, and services (e.g., Common systems engineering, RACE, Forge.mil, NCES) to required extent practicable Conduct testing and certification/accreditation “in stride”. Integrated testing and certification will occur throughout the implementation phase. 9
IT Acquisition Tenets (cont’d) Assure agility by allowing trade-offs within dollar and time limits. Accommodate requirements trades (features, performance) reflecting user priorities, feedback, and technology advances/limitations during planning and execution. Allow tailorable processes. Project execution should be tailored for the particular risks, acquisition life cycle, and oversight needs of different types of IT acquisition efforts. Comply with enterprise and segment architectures. Assure designs are consistent with promulgated architecture policies and standards to facilitate system interoperability and integration.
10
DoD 5000 & Business Capability Lifecycle (BCL) Defense Acquisition Management Framework – Traditional A
Concept Refinement
B
Engineering & Manufacturing Development
Technology Development
Concept Decision
Pre-Systems Acquisition Acquisition Decision Points
Capability Definition
FOC
Production & Deployment FDDR
Operations & Support
Systems Acquisition
Sustainment
Business Capability Lifecycle
MDD
Business
IOC
C
A
B
Investment Management
Prototyping
Up to 12 Months
12 Months*
Close Out Review
FDD
C
Engineering Development
Limited Deployment
Full Deployment
IOT&E IOC
Operations and Support
18 Months* MS B to IOC FDD
ATP
B
Milestone Review MDA Decision Point IRB/DBSMC Chair Decision Point MDA Decision Point MDD = Materiel Development Decision FDD = Full Deployment Decision ATP = Authorization to Proceed
Prototyping
(ERAM for MAIS and MDAP)
*
From Contract/Option award
Engineering Developm't
Limited Deployment
Full Deployment
Operations and Support
IOT&E IOC
Increment 2
12 Months*
Increment N
18 Months* MS B to IOC
FDD
ATP
B
IRB Close Out Independent Risk Assessment
C
Prototyping
C Engineering Developm't
Limited Deployment IOT&E IOC
12 Months*
18 Months* MS B to IOC
Full Deployment
Operations and Support
Notional Incremental Model for Capability Delivery with IT Decision to Enter Acq Process
Capability Definition
Course of Action
Solution Analysis
Program/Project Lifecycle Decision to Invest
Decision to Acquire
Risk Reduction & Solution Refinement
Increment 1 Deploy Decision(s)
Implement & Deploy
Invest
Operate & Sustain
Acquire
Increment 2 Deploy
Risk Reduction & Solution Refinement
Implement & Deploy
Invest
Operate & Sustain
Acquire
Increment n Deploy
Risk Reduction & Solution Refinement
12
Implement & Deploy
Operate & Sustain
SE’s Role in Acquisition Support Fall 2002: OSD establishes SE organization to: • Drive SE back into programs & instill credibility in the acquisition process Program Support Reviews: Element of DoD SE revitalization effort • Help Program Managers identify & mitigate risks • Shape technical planning and management • Provide insight to OSD stakeholders • Identify systemic issues requiring resolution above program 3.9.6. Program Support Review (PSR). PSRs are a means to inform the MDA, OIPT, and Program Office of the status of technical planning and management processes by identifying cost, schedule, and performance risk and recommendations to mitigate those risks. PSRs shall be conducted by cross-functional and cross-organizational teams appropriate to the program and situation. PSRs for ACAT ID and IAMs shall be planned by the Director, Systems Engineering to support pending OIPT program reviews, at other times as directed by the USD(AT&L), and in response to requests from PMs.
Tactical Support
Program Assessments & Monitoring • Support acquisition decisions & requests • Address technical issues • Support PMs in maintaining execution discipline
Strategic Support
Systemic Root Cause Analysis • Data driven • Recommendations in policy, education, guidance, leading practices, etc • -Metrics to assess program performance
•
Providing Tactical and Strategic Acquisition Support
Systems Engineering Acquisition Process Engagement SE has a role in many major acquisition program milestone decisions and oversees and executes critical acquisition risk management processes to reduce program cost, acquisition time and risk. Continuous Engagement
ICD
A
MDD Enabling S&T
Pre-acquisition Concepts, Experimentation and Prototyping
Materiel Solution Analysis
CDD
CPD
B
C
CDR
PDR
AOA
Production and Deployment
Engineering and Manufacturing Development
Technology Development
Developmental Testing
FRP
OT&E
Developmental Testing
Continuous Engagement (Mentoring, Workforce, Assessment) by Systems Engineering and Developmental Test Continuous Technical Emphasis on Reliability and Producibility Development Planning SEP – Systems Engineering Plan TES – Test and Evaluation Strategy TEMP – Test and Evaluation Master Plan TDS – Technology Development Strategy PPP – Program Protection Plan AOA – Analysis of Alternatives PDR – Preliminary Design Review CDR – Critical Design Review ICD – Initial Capabilities Document CDD – Capability Development Document CPD – Capabilities Production Document MDD – Material Development Decision FRP – Full Rate Production Decision
SEP
SEP
SEP
TEMP
TEMP
TES
PPP
PPP
TDS
TRA
PPP
Post-PDR Assessment for 2366b Certification
Cross-Cutting Efforts: Acquisition Workforce Management, Engineering Policy and Guidance, Advocacy for Service Competencies and Initiatives, STEM Initiatives
System Engineering and the BCL Outcome Process
Joint Improvised Explosive Device (IED) Defeat Organization (JIEDDO)
16
Joint Improvised Explosive Device (IED) Defeat Organization (JIEDDO)
Mission: To rapidly provide counterIED (C-IED) capabilities to warfighters. JIEDDO has provided significant support along three lines of effort — Attack the Network, Defeat the Device, and Train the Force. (FY) 2010 Highlights include: •
•
•
Source: 2010 JIEDDO Annual Report (Unclassified)
Supporting increased Operation Enduring Freedom (OEF) C-IED requirements via rapid acquisition, reprogramming of funds, and repurposing of previous investments on the magnitude of $1.2 billion from an overall $2.7 billion effort Providing fused information tools for warfighters in the field to enable and enhance their capabilities to attack enemy IED networks Streamlining organizational processes to speed acquisition efforts
Mapping the JIEDDO Acquisition Methodology to DoD 5000 JIEDDO Acquisition Methodology Capability Requirement Validation Domain
MDD DCR / ICD
Material Solution Analysis Phase
DoD 5000 Methodology
Develop Phase
MS-B
MS-A Solution Analysis
DP-1
Technology Development
Integrated System Design
DP-1D
PostCDR A
Development Phase
Demo Phase
System and Manufacturing Process Demonstration
DP-2
MS-C
Procure Phase
Low-Rate Initial Production
T3C Working Group Integration
DP-0
Integration Domain
Operational Assessment
Prioritize Phase
Pre-Solution Refinement
Validate Phase
Capabilities Based Assessment
Identify Phase
Solution Domain
FRP DR
Sustain/ Transfer / Transition Phase
DP-3
Full Rate Production
Production and Deployment Phase
FOC
Integrated Electronic Healthcare Record (iEHR)
19
The DoD iEHR is an Enterprise-wide Medical and Dental Information Management System WHO WE SERVE
• • • • • • •
Service Members Retirees Their Families Other Beneficiaries Operational Commanders Military Health System Community Other Stakeholders
WHAT WE DO
• • • •
Right Information Right Community Right Time Right Place
WHY WE DO IT
• • • • •
Enhanced Access to Quality of Care Enhanced Patient Safety Enhanced Health Outcomes Better Health Resource Management Health Community Satisfaction
20
iEHR Bottom Line As quickly as we can, within an acceptable expectation of risk, we want to deploy an EHR capability to improve the delivery of healthcare. At Milestone (A)/B (or upon approval of the Acquisition Strategy), the Planning Office will be able to put out an RFP. – EHR Deployed – Funding – September 2011 – Procurement – Milestone B – Requirements – AoA – Today
21
Fundamentals of the iEHR SE Process The primary goal of the iEHR SE Process is to align the iEHR acquisition/development approach with user processes by using an iterative cycle of definition, refinement, and implementation. The iEHR SE process is not a development approach based on a simple one-to-one mapping of capability to requirement.
• Capabilities developed by iEHR will fulfill formal requirements but do so within the context of a user process. • This new SE process should re-orient design and development from a broad domain area to a well-specified mission process. • Multi-process SE issues still need to be resolved at the “top” level, but design and implementation occurs at the narrowly focused mission process definition level
VHA-DoD HA Transition consideration Key to success rapid definition of user business (or mission) process AND translation into initial user capability
22
Key SE Process Themes Agile, response SE Process Trading off traditional SE processes to gain speed of delivery while maintaining sufficient technical control • • •
Implemented evolving Baselines Leverage spiral development at the CDP - CM level Enable individual CMs to proceed at best speed to fielding
Closely coupled with User requirements Guided by Architecture Products • • •
MHS Architecture Framework Increment specific architecture Domain specific designs
CM development commences prior to Requirements & Functional Baseline completion Maintaining CM development, Integration & Test, and Certification rigor and thoroughness User involvement 23
Systems Engineering: Critical to Program Success
