ISA 201 Intermediate Information System Acquisition

Slides:



Advertisements
Similar presentations
Clinger Cohen Act (CCA): Integrating CCA (U. S. C
Advertisements

BENEFITS OF SUCCESSFUL IT MODERNIZATION
Lesson Objectives Review Capabilities Development documents and processes for Information Technology and Information Systems IT Box – (current JCIDS manual)
KDP-1: Integrate supply chain knowledge into secure solutions concepts Evaluate supply chain threats with respect to the set of possible solutions under.
1 May 2009 ver. 5.5 Materiel Development Decision (MDD) MDA: Approves AoA Study Guidance Determines acquisition phase of entry Identifies initial review.
Presented By: Thelma Ameyaw Security Management TEL2813 4/18/2008Thelma Ameyaw TEL2813.
NLRB: Information Security & FISMA Daniel Wood, Chief IT Security February 19, 2004.
DITSCAP Phase 2 - Verification Pramod Jampala Christopher Swenson.
Enterprise Architecture
Complying With The Federal Information Security Act (FISMA)
A Security Training Program through Transformational Leadership and Practical Approaches Tanetta N. Isler Federal Information Systems Security Educators’
DoD Acquisition Domain (Sourcing) (DADS) Analysis of Alternatives (AoA) E-Business/SPS Joint Users’ Conference November 15-19, 2004 Houston, TX.
NIST Special Publication Revision 1
Why is BCL Needed? BCL addresses long-standing challenges that have impacted the delivery of business capabilities The DepSecDef directed increasing the.
The Challenge of IT-Business Alignment
Important acronyms AO = authorizing official ISO = information system owner CA = certification agent.
Certification and Accreditation CS Phase-1: Definition Atif Sultanuddin Raja Chawat Raja Chawat.
UNCLASSIFIED DITSCAP Primer. UNCLASSIFIED 1/18/01DITSCAP Primer.PPT 2 DITSCAP* Authority ASD/C3I Memo, 19 Aug 92 –Develop Standardized C&A Process DODI.
IRM304 CDR Course Manager: Denny Involved Competency Leads: 26 (Cybersecurity)-Denman, 19 (Measurement)-Denny, 7 (DBS)-Corcoran [Capability Planning],
Disaster Recover Planning & Federal Information Systems Management Act Requirements December 2007 Central Maryland ISACA Chapter.
1 © Material United States Department of the Interior Federal Information Security Management Act (FISMA) April 2008 Larry Ruffin & Joe Seger.
Power to the Edge A Net-Centric DoD NII/DoD CIO Performance and Results-based Management of IT and NSS Investments Measures of Effectiveness (MOEs) and.
Life Cycle Logistics.
Evaluate Phase Pertemuan Matakuliah: A0774/Information Technology Capital Budgeting Tahun: 2009.
Defense Business Systems (CLE077) Sprint November 9, 2015 DRAFT1 Sprint Working Group Toni Freeland Kevin Hamilton Lee Hewitt Tom Hickok Len Nale Bob Ramsey.
12-CRS-0106 REVISED 8 FEB 2013 APO (Align, Plan and Organise)
CCA LSS Support Slides1 Draft The Defense Acquisition Management Framework. Post Implementation Review (PIR) Capability Needs Satisfaction & Benefits.
| 1 Weapon System Acquisition Reform- Product Support Assessment DAU SYMPOSIUM 13 April 2010 Presented by: Basil Gray Where Innovation.
Materiel Development Decision (MDD) Information Requirements
Important acronyms AO = authorizing official ISO = information system owner CA = certification agent.
Environment, Safety, and Occupational Health Opportunities in DoD Business Transformation May 4, 2006.
SUNY Maritime Internal Control Program. New York State Internal Control Act of 1987 Establish and maintain guidelines for a system of internal controls.
ISA 201 Intermediate Information System Acquisition
Business, Cost Estimating & Financial Management Considerations
Michael J. Novak ASQ Section 0511 Meeting, February 8, 2017
MORS Special Meeting: Risk, Trade Space, & Analytics for Acquisition
ISA 201 Intermediate Information Systems Acquisition
DoD Template for Application of TLCSM and PBL
Life Cycle Logistics.
MDD to Milestone A Requirements Management Activities
ISA 201 Intermediate Information Systems Acquisition
ISA 201 Intermediate Information Systems Acquisition
Eric Jefferies Professor, Requirements Management
Milestone A to Milestone B Requirements Management Activities
JTAMS MILESTONE A ANALYSIS
ISA 201 Intermediate Information Systems Acquisition
TechStambha PMP Certification Training
ISA 201 Intermediate Information Systems Acquisition
Improving Mission Effectiveness By Exploiting the Command’s Implementation Of the DoD Enterprise Services Management Framework - DESMF in the [name the.
Introduction to the Federal Defense Acquisition Regulation
ISA 201 Intermediate Information Systems Acquisition
JTAMS PRE-MILESTONE B ANALYSIS
Purpose Provide an update on recent major changes to law, policy, and guidance that affect the way we conduct IA&E activities National Defense Authorization.
JTAMS PRE-MILESTONE B ANALYSIS
MDD to Milestone A Requirements Management Activities
Materiel Development Decision (MDD) to Milestone A (MS A)
9/16/2018 The ACT Government’s commitment to Performance and Accountability – the role of Evaluation Presentation to the Canberra Evaluation Forum Thursday,
The Open Group Architecture Framework (TOGAF)
Defense Business Systems (CLE077) Sprint
Information Required for Milestone and Decision Reviews
Matthew Christian Dave Maddox Tim Toennies
Phase 1 Tollgate Review Discussion Template
Continuity Guidance Circular Webinar
Project Management Process Groups
Cybersecurity ATD technical
8 Tech Processes Drive Acquisition
The Department of Defense Acquisition Process
JTAMS PRE-MILESTONE B ANALYSIS
JTAMS PRE-MILESTONE B ANALYSIS
Purpose Provide an update on recent major changes to law, policy, and guidance that affect the way we conduct IA&E activities National Defense Authorization.
Presentation transcript:

ISA 201 Intermediate Information System Acquisition

Lesson 4 Program Planning

Today we will learn to: Discuss the impact of Title 40/CCA on acquisition of Information Technology (IT). Apply the eleven (11) compliancy requirements of Title 40/CCA to a given DoD IT System. Document the requirements for project/program reporting listed in OMB Circular A–11 Section 55. Given the acquisition lifecycle, identify at least one major activity related to the BCA that should occur at relevant acquisition milestones. Determine what should be assessed in IT areas when developing a PS BCA. Identify relevant considerations that influence the acquisition lifecycle of a software-reliant system. Apply the Program Protection Plan to an IT Acquisition Scenario. Describe rules, regulations, guidelines and Best Practices for Portfolio Management. Program Planning

Planning Considerations Lesson Plan Planning Considerations Product-Tailored Acquisition Models Business Case Analysis Focus on Performance Following the Law Security Planning Program Planning

Thoughts on Planning "In preparing for battle I have always found that plans are useless, but planning is indispensable." —Gen D. D. Eisenhower "To be prepared is half the victory." —Cervantes "It pays to plan ahead. It wasn't raining when Noah built the ark." —Unknown "Prior proper planning prevents painfully poor performance." Program Planning

Why the Focus on Upfront Planning? Program Planning

Product-Tailored Acquisition Models Lesson Plan Status Planning Considerations Product-Tailored Acquisition Models Business Case Analysis Focus on Performance Following the Law Security Planning Program Planning

Product-Tailored Acquisition Models (DoDI 5000.02) Four basic models are tailored to the dominant characteristics of the acquisition The hybrids are described because many products will require combining 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 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. Program Planning

Defense Unique Software Intensive System (Model 2) The number and type of builds will depend on system type. Program Planning

Incrementally Deployed Software Intensive System (Model 3) Program Planning

Hybrid Program A (HW Dominant) Model 5 Program Planning

Hybrid Program B (SW Dominant) Model 6 Program Planning

Planning and DoDI 5000.02 Program Planning

Exercise: Planning a Software Acquisition Scenario 1: An Enterprise Resource Planning (ERP) application to manage financial planning functions for the Air Force Materiel Command. The system recently received an ADM at MS A for entering the TMRR phase . Estimated Total Life Cycle Cost of the System is $525M Scenario 2: A C4I System providing targeting info to the Army’s Advanced Missile System. The system recently received permission to release a Development RFP for work in the EMD phase . Estimated RDT&E cost of the System is $200M Scenario 3: A major upgrade to the weapons management system, containing both hardware and software upgrades, to handle new threats on a fielded tactical fighter aircraft. The system recently received an ADM at MS A for entering the TMRR phase . Estimated Life Cycle Cost of the System is $530M Scenario 4: A web-based data management system for CENTCOM to manage incoming intelligence data. The system has been classified by the DoD as a major, highly sensitive classified program. The system recently received an ADM at MS B for entering EMD . Estimated Life Cycle Cost of the System is $120M Scenario 5: An advanced UAV system for collecting intelligence data via link 16 as needed by the force commander. The system recently received an ADM at MS C for eventual fielding . Estimated Life Cycle Cost of the System is $590M Program Planning

Exercise: Planning a Software Acquisition Use the current DoDI 5000.02 to research and prepare a brief for the class on the following: Acquisition Model best fitting the scenario (pages 8–15) Appropriate ACAT/MAIS level (Enclosure 1, Table 1) The next major lifecycle event? (Enclosure 1, Table 2) The documentation requirements for the next major lifecycle event (indicate whether it is new or and update) (Enclosure 1, Table 2) Program Planning

Defense Business Systems (DBS) What is a Defense Business System? A Payroll System? ERP System? Time & Material System? Command and Control System? Defense Commissary System? An information system operated by, for, or on behalf of the Department of Defense, including financial systems, mixed systems, financial data feeder systems, and information technology and information assurance infrastructure, used to support business activities, such as acquisition, financial management, logistics, strategic planning and budgeting, installations and environment, and human resource management. US Code Title 10, Subtitle A, Part 4, Ch 131, par. 2222 Program Planning

Defense Business System No JCIDS procedures or documentation Problem Statement developed by Functional Sponsor. Assesses business need, DOTMLPF-P impacts; high-level outcomes and metrics Business Case is required. The Business Case is a brief, high-level document that describes the program and associated planning Program Charter is required. Establishes the roles and responsibilities of those involved in planning and executing the DBS Program Planning

Business Case Analysis Lesson Plan Status Planning Considerations Product-Tailored Acquisition Models Business Case Analysis Focus on Performance Following the Law Security Planning Program Planning

Business Case Analysis (BCA) A formal, structured process A tool to assess business improvement alternatives Emphasis of the enterprise wide perspective of stakeholders and decision makers and assessment of the holistic effects impacted by the decision Program Planning

When are BCA’s Conducted? Product Support BCAs are accomplished throughout the life cycle. Program Planning

BCA Major Elements BCA Purpose BCA Process Components Problem Statement, Objectives, Desired Outcomes, Requirements, Measurements BCA Process Components Desired Outcomes and Requirements Alternatives Mission & Business Impacts Risk Analysis & Mitigation Plans Sensitivity Analysis Recommendations BCA Quality Foundation Governance, Research, Data Management, Due Diligence Program Planning

Product Support BCA Process Tailoring of the process must occur to meet the needs of the stakeholders and sponsor. Program Planning

Software Engineer Role in BCA Ensures understanding of the software development environment for cost estimation purposes. The software architecture meets the requirements of Open Systems Architecture (OSA) standards for ease of support.  The IP Strategy is used to identify appropriate software data rights for every software application in the solution architecture. The data rights should be examined for best value agreements (OSA requirement). The software support tools required during the product support phase (after Initial Operational Capability (IOC) or Full Deployment (FD)) are identified. Ref: DoD Product Support BCA Guidebook–April 2011 Program Planning

Software Engineer Role in BCA The Data Management Strategy is understood; What are the program’s data element rules (governance) for how data is described, cataloged, metadata tagged, adjudicated (when two data elements collide) and managed for software application availability (inputs into the KPP on Availability and KSA on Reliability)? The software code is developed using secure coding practices. That security is built into software architecture from the start.  Ref: DoD Product Support BCA Guidebook–April 2011 Program Planning

BCA Guidance "Conduct a Product Support BCA every five years or prior to a change to the strategy." FY2010 NDAA Sec. 805, Life Cycle Management and Product Support "A BCA should be prepared for all sustainment and product support decisions where DoD funds are expended." DoD BCA Guidebook "All major decisions regarding product support strategy development and PSI selection need to be based on unbiased BCAs that account for all applicable costs and Warfighter requirements." PSM Guidebook "The programs should use accepted decision making tools and processes, such as Business Case Analysis." Defense Acquisition Guidebook (DAG) Program Planning

Focus on Performance Lesson Plan Status Planning Considerations Product-Tailored Acquisition Models Business Case Analysis Focus on Performance Following the Law Security Planning Program Planning

Legislative and Policy Drivers The Chief Financial Officers Act of 1990 Government Performance and Results Act of 1993 The Paperwork Reduction Act of 1995 Federal Financial Management Improvement Act of 1996 The Clinger-Cohen Act of 1996 The President’s Management Agenda of 2002 OMB Circular A–11 OMB Circular A–130 Program Planning

Federal Focus on Performance http://www.osec.doc.gov/cio Program Planning

IT Investment Planning Must ensure IT investments are aligned with and support the DoD strategic plan 2 Parts—Agency Portfolio and Major IT Investment Business Cases Reporting to OMB Exhibit 53A is the Agency IT Portfolio Summary Exhibit 53C is the Agency Cloud Spending Summary Agency IT Infrastructure Spending Summary Exhibit 300A is the Major IT Business Case Exhibit 300B is the Major IT Business Case Detail Exhibit 53 ref: OMB Circular No. 11, Section 55 & OMB Circular No. 11, Section 25.1 Exhibit 300 ref: OMB Circular No. 11, Section 55 & OMB Circular A–130 Program Planning

Why Report? Required by OMB to review, evaluate and compare agency's IT spending. Supports Clinger—Cohen Act Requirement Gives an understanding and allows comparison of spending on new capabilities, modernization, and maintenance Captures IT security costs for all IT investments as required by the FISMA Program Planning

Agency IT Portfolio (Exhibit 53) Part 1—IT Investments for Mission Delivery Area and Management Support Area Part 2—IT Investments for Infrastructure, IT Security, Office Automation, and Telecom Part 3—IT Investments for Enterprise Architecture (EA), Capital Planning, and CIO Functions Part 4—IT Investments for Grants Management Systems Part 5—National Security Systems IT Investments Part 6—Grants to State and Local IT Investments Program Planning

Agency IT Portfolio (Exhibit 53) All major, non-major, migration related, and funding of IT investments All Exhibit 300 Investments Reported Annually Program Planning

Major IT Business Case (Exhibit 300) Justification, planning, and implementation of individual capital assets included in the Agency IT Portfolio Summary (Exhibit 53) The Major IT Business Case is comprised of two components: The Major Business Case itself which provides key high-level investment information to inform budget decisions, including general information and planning for resources such as staffing and personnel. The regular, timely, updates to the Business Case, to include information such as projects and activities, risks, and operational performance of the investment. Reported Annually Program Planning

Exhibit 300 Contents Usually created and maintained yearly by the Program Office Risk management plan Investment charter, including IPT Investment-level alternative analysis and benefit-cost analysis Operational analyses (for operational or mixed life cycle systems) Post implementation review results (investment level or project-specific) Documentation of investment re-baseline management approval(s) Program Planning

Following the Law Lesson Plan Status Planning Considerations Product-Tailored Acquisition Models Business Case Analysis Focus on Performance Following the Law Security Planning Program Planning

What is the Clinger Cohen Act? Information Technology Management Reform Act (ITMRA) and Federal Acquisition Reform Act (FARA)—combined Attempt to resolve the following perceived issues: Money spent on IT was spent with no Business Process Improvement in mind Little improvement in mission performance from $$ spent on IT Implementation of ineffective information systems resulted in waste, fraud, and abuse Outdated approaches to buying IT did not adequately take into account the competitive and fast paced nature of the IT industry and the continuing evolution of IT equipment and SW Program Planning

Purpose of CCA/Title 40 "To ensure Information Technology (IT) investments provide measurable improvements in mission performance" Title 40/CCA poses three questions: Are the functions consistent with mission? Could the functions be performed more economically by private sector (or another government agency)? Have the functions been redesigned and reengineered before applying new technology? Program Planning

CCA Compliance in DoD 5000.02 For all programs that acquire IT, including NSS, at any acquisition category (ACAT) level, the Milestone Decision Authority (MDA) will not: initiate a program nor an increment of a program, or approve entry into any phase of the acquisition process that requires formal acquisition milestone approval. The DoD Component will not award a contract for the applicable acquisition phase until: The sponsoring DoD Component or program manager has satisfied the applicable requirements of the CCA as shown in Table 9 in Enclosure 1 of this instruction; and The DoD Component Chief information Officer (CIO), or their designee, confirms compliance with the CCA. Program Planning

Program Documentation CCA Compliance Actions Required Program Documentation 1 ***Make determination that the acquisition supports core priority functions of the Department ICD approval 2 *** Establish outcome-based performance measures linked to strategic goals. ICD, CDD, CPD and APB approval 3 *** Redesign the processes to reduce costs, improve effectiveness and maximize the use of COTS technology. Approval of the ICD, Concept of Operations, AoA, CDD, and CPD 4 * No private sector or government source can better support the function. Acquisition Strategy page XX, para XX; AoA page XX 5 * An Analyses of Alternatives has been conducted. AOA 6 * An economic analysis has been conducted that includes a calculation of the return on investment; or for non-AIS programs, an LCCE has been conducted. Program LCCE; Program Economic Analysis for MAIS * For weapons systems and command and control systems, these requirements apply to the extent practicable (40 U.S.C. §1451) ** The system documents/information cited are examples of the most likely but not the only references for the required information. If other references are more appropriate, they may be used in addition to or instead of those cited. *** These requirements are presumed to be satisfied for Weapons Systems with embedded IT and for Command and Control Systems that are not themselves IT systems. Program Planning

Program Documentation CCA Compliance Actions Required Program Documentation 7 There are clearly established measures and accountability for program progress Acquisition Strategy page XX, para XX; APB 8 The acquisition is consistent with the DoDIN (DoD Information Network) policies and architecture, to include relevant standards APB (Interoperability KPP); C4ISP (IER’s) 9 The program has an information assurance strategy that is consistent with DoD policies, standards, and architectures, to include relevant standards Cybersecurity 10 To the maximum extent practicable, (1) modular contracting has been used, and (2) the program is being implemented in phased, successive blocks, each of which meets part of the mission need and delivers a measurable benefit, independent of future blocks Acquisition Strategy page XX, para XX 11 The system being acquired is registered. DoD IT Portfolio Repository—DON (DITPR-DON) Program Planning

Title 40/CCA Impacts DoD Chief Information Officer (CIO) MAIS certification of compliance Registration of Mission Critical or Mission Essential IT systems Required for all IT systems including weapon systems Institutionalized in the DoDI 5000.02 Program Planning

Security Planning Lesson Plan Status Planning Considerations Product-Tailored Acquisition Models Business Case Analysis Focus on Performance Following the Law Security Planning Program Planning

Program Protection Planning (PPP) The integrating process for managing risks to DoD warfighting capability from foreign intelligence collection; from hardware, software, and cyber vulnerability or supply chain exploitation; and from battlefield loss throughout the system life cycle. Program Protection Plan (PPP) Program managers will employ system security engineering practices and prepare a PPP to guide their efforts and the actions of others to manage the risks to critical program information and mission-critical functions and components associated with the program. The PPP will be submitted for MDA approval at each Milestone review, beginning with Milestone A. Program managers will describe in their PPP the program’s Critical Program Information and mission-critical functions and components; the threats to and vulnerabilities of these items; the plan to apply countermeasures to mitigate associated risks; and planning for exportability and potential foreign involvement. The Cybersecurity Strategy is required per statute as an appendix to the PPP Program Planning

Program Protection Plan Contents Plan to align PPP and Prime Contractor Program Protection Implementation Plan(s) Critical Program Information (CPI) and Critical Functions and Components Protection Identification Methodology, Inherited CPI and Critical Components, and Organic CPI and Critical Components Assurance that critical defense technologies, to include CPI, associated with more than one Research, Development, and Acquisition (RDA) program, are protected to the same degree by all involved DoD activities Identified threats and vulnerabilities to CPI and critical functions/components PPP Outline & Guidance v 1.0 July 2011 Program Planning

Program Protection Plan Contents Other System Security-Related Plans & Documents (SEP, TEMP) How Program Protection risks will be integrated with overall Program risk management Foreign Involvement, Defense Exportability Features Processes for Management and Implementation of PPP Processes for Monitoring and Reporting Compromises Summarize the plan/procedure for responding to a CPI compromise or a supply chain exploit Program Protection Costs Program Planning

Program Protection Plan Appendices Security Classification Guide (SCG) The SCG may be referenced or pointed to rather than included in the document. Counterintelligence Support Plan (CISP) The CISP may be referenced or pointed to rather than included in the document. Criticality Analysis The results of the most recent Criticality analysis must be included and should be updated regularly Anti-Tamper Plan Not all programs will require an Anti-Tamper plan. If an Anti-Tamper Plan is required, use the template developed by the Executive Agent for Anti-Tamper. Acquisition Cybersecurity Strategy See next slide for content Program Planning

Cybersecurity Strategy Outline Program and System Description Cybersecurity Requirements Cybersecurity Approach (high level) Acquisition of Cybersecurity Capabilities and Support System Certification and Accreditation (Assessment and Authorization (A&A)) Cybersecurity Testing Cybersecurity Shortfalls Policy and Guidance Point of Contact Program Planning

Today we learned to: Discuss the impact of Title 40/CCA on acquisition of Information Technology (IT). Apply the eleven (11) compliancy requirements of Title 40/CCA to a given DoD IT System. Document the requirements for project/program reporting listed in OMB Circular A–1 Section 55. Given the acquisition lifecycle, identify at least one major activity related to the BCA that should occur at relevant acquisition milestones. Determine what should be assessed in IT areas when developing a PS BCA. Identify relevant considerations that influence the acquisition lifecycle of a software–reliant system. Apply the Program Protection Plan to an IT Acquisition Scenario. Describe rules, regulations, guidelines and Best Practices for Portfolio Management. Program Planning