OSD ATL class on Agile Acquisition

11

IT Policy Update (IT Efficiencies, IT Acquisition Reform & Other)

Don Johnson

Office of the Secretary of Defense USD(AT&L) – DASD(C3 & Cyber)

Where To Start – Senior Official for ITInspiring New DoD CIO Role

• DoD CIO Vision

• Agile and secure information capabilities to enhance combat power and decision-making

• Main DoD CIO Thrust Areas

• Lead the DoD Information Enterprise• Improve Enterprise Architecture Effectiveness via

Consolidate Infrastructure & Networks; StandardizeIT Platforms; and Deliver DoD Enterprise Cloud

• Direct and Oversee DoD IT Investments• Streamline Processes - Includes Enable Agile IT;

Strengthen IT Governance; Leverage Strategic Sourcing for IT Commodities; and Strengthen the IT Workforce

• Strengthen Cyber Security across DoD Enterprise• Create & maintain strong boundary defenses and

monitoring on DoD networks

New OSD Landscape, Jan 11, 2012

• Refashioned DoD CIO

• New DASD Within AT&L

• DoD CIO will retain• Primary authority for policy and oversight

of IT, network defense and network operations

• Statutory responsibilities relating to acquisition matters (aka Clinger Cohen Act related duties)

• Principal Staff Assistant (PSA) for nuclear, C3 and spectrum

• Information Assurance and related Cyber oversight duties

Innovating in DoD’s IT LandscapeEach System is Often Part of a Larger “System”

Requirements Validation/Execution

DoD Adaptive Planning Environment

Plan Assessment

Force Flow

Force Management

TRANSCOMTRANSCOM

DISADISAOUSD(P)OUSD(P)

STRATCOMSTRATCOM

OUSD(P&R)OUSD(P&R)

ISPANISPAN

JCRMJCRM

JOPES DBJOPES DB

JFASTJFAST

DRRSDRRS

IGSIGS

JET/RQTJET/RQT

ALPSALPS

RTBRTB

TSCMISTSCMISJoint Staff J3Joint Staff J3

Wargaming

Logistics

4

DLADLA

ICISICIS

Most IT Systems Have Their Own Requirements (Islands Upon Themselves)Each System Brings Its Own Infrastructure & Technology Stack

No Single Office to Provide Guidance, Direction & Funding

Need to Govern DifferentlyCSIS Study on Acquisition of Net Centric System-of-Systems

Problem: Stove-piped, program-centric and Component-centric systems have led to ad hoc activity, lack of flexibility and resilience in face of “surprise”

CSIS Study Team: Mr Ken Krieg, Mr Frank Kendall, Harvard, etc.,

Points/Recommendations:• Need for enterprise-wide governance for delivering warfighting and business capabilities is not

recognized across DoD (applies equally to MDAP and MAIS)

• Governance is key to successful delivery

› No organizational construct exists to assess and guide “enterprise” performance (like a Board of Directors with authority to make trades)

› Successful delivery of capabilities require that interests at the system/ component level be re-balanced around the capability-centric view

• Absence of enterprise risk assessment , risk management strategies and enterprise metrics/goals (First enterprise milestone in acquisition is “IOC”)

• Iterative involvement of warfighter in all stages of delivery is critical but rarely occurs because it is rarely mandated

Shift Governance From “Program-Centric” to “Capability-Centric”

Visible and Hidden IT Costs

6

Jan 2012 Defense Business BoardEnterprise Consolidation Savings: 25-50% in Total Annual Expenditures

Bigger Picture: Enhancing Enterprise Efficiencies (Others Federal Agencies Having Impact)

2012 Excellence.gov Awards Ceremony, March 13, 2012

• Overcoming Cultural Barriers• FAA Federal Notice to Airman System

• Enterprise capability replaces 50-year old system providing pilots safety of flight (in 15 minutes) to an IT system that takes less than 5 seconds

• Overcoming Complexity of Worldwide Mission• Department of State’s Enterprise IT Innovation

• Transformed a paper-based environment across 245 embassies• DHS consolidated 32 globally environments into one

• Overcoming Silo-Mindset• U.S. Treasury developed IT solution to build its annual budget now used by 6 Cabinet agencies and 13 total agencies to build their budgets• Coast Guard Business Intelligence

• Integrated 40 existing data sources to report readiness & capabilities• NASA created a single enterprise-level IT cloud across its 10 Centers• Minnesota became first U.S. state to enter into enterprise-wide cloud

• Thinking Differently• Enterprise solution links interpreters to court in 9th Circuit Court in Florida

8

Need to Innovate & Think DifferentlyWhat Did Former DoD Leaders Say -

• Adaptive Ecosystem• Processes responsive to dynamic operational

and technology environment• Responsive Solutions

• User-centered domain expertise • Leverage the latest solutions available commercially and

products not hard-wired at predetermined needs unable to evolve• Speed

• He who learns fastest ends up making progress and wins• Speed the process… … Gen Petraeus

“The [defense] budget has basically doubled in the last decade. And my own experience here is that in doubling, we’ve lost our ability to prioritize, to make hard decisions, to do tough analysis, to make trades.”

“It is time to think hard about how to institutionalize the procurementof capabilities to get them fielded quickly – the issue becomes how

we can build innovative thinking and flexibility into the rigidprocurement system”

Thinking Differently in IT AcquisitionInside the Pentagon, March 2012

Deputy Chief Management Officer Beth McGrath said the revision to the 5000.02 instruction that would overhaul the DoD procurement process awaits the signature of acting USD (AT&L) Frank Kendall to start coordination.

DoD calls for an agile application process that deploys capabilities every 12 to 18 months to a number of business and non-business systems, said McGrath and DoD CIO Teri Takai in separate interviews.

Congressional sources said that DoD has deviated from several steps laid out in the section 804 report's implementation schedule and Congress is still waiting to see the details of how DoD will achieve the plan.

9

- 1965 Brooks Act: Provided GSA exclusive IT acquisition authority across the Government

- 1988 Warner Amendment: DoD to procure IT provided it was an integral part of a weapon

-1996 Clinger Cohen Act: DoD given acquisition authority to independently procure IT

-2006 Section 806: Notify Congress of MAIS cancelation or significant change

-2007 Section 811: Time certain development for MAIS

-2007 Section 816: Codify MAIS, SAR-like and NM-like reporting

-2010 Section 804: New IT acquisition process

-2009 Section 817: MAIS and MDAP mutually exclusive

-2008 Section 812: Pre-MAIS reporting, funds first obligated

-2009 WARSA: ICE for certain MAIS when AT&L is MDA

-2008 10 USC 2222: Obligation of funds restrictions annual IRB

-2009 Section 841: Replace IOC with FDD

IT Legislative Landscape

-2010 Section 933: New Cyber process & tools

2010 National Defense Authorization Act

IMPLEMENTATION OF NEW ACQUISITION PROCESS FOR INFORMATION

TECHNOLOGY SYSTEMS

• NEW ACQUISITION PROCESS REQUIRED —The Secretary of Defense shall develop and implement a new acquisition process for information technology systems• “… Be based on the recommendations in

Chapter 6 of the March 2009 report of the DSB Task Force on DoD and Procedures for the Acquisition of Information Technology

• New designed to include—

(A) early and continual involvement of the user;

(B) multiple, rapidly executed increments or releases of capability;

(C) early, successive prototyping to support an evolutionary approach; (D) a modular, open-systems approach

Achieving the Vision of theMarch 2009 Defense Science Board

Today (Static/Time Unconstrained) Future (Dynamic/Time Boxed)

91 months 18-36 months

“The primary conclusion of the task force is that the conventional DOD acquisition process is too long and too cumbersome to fit the needs of the many IT systems that require continuous changes and upgrades. Thus the task force believes that there is a needfor a unique acquisition system for information technology.”

March 2009 Defense Science Board Task Force Report

DSB Report on Policies and Procedures for Acquisition of IT

Acquisition ModelChapter 6 of March 2009 DSB Report

13

Milestone Build Decision

• Impact to Core DoD Processes– Requirements: From: fix set of requirements; To: evolving requirements & user role throughout– Delivery: From: static waterfall model; To: Agile model with user feedback driving priorities– Governance: From: Driven by Milestones & breaches ; To: More frequent review- delivery focused – Functional Areas: From: rigor tied to documentation for single milestone; To: rigor tied to demonstrated risk and delivery of capabilities

Acquisition Model: Continuous Technology/Requirements Development & Maturation

Integrated DT / OT

Prototypes Iteration1 Iteration 2 Iteration “N”

Architectural Development and Risk ReductionBusiness Case Analysis

and Development Development & Demonstration

Fielding

RELEASE 1

PrototypesIteration 1 Iteration 2 Iteration 3

Development & Demonstration

FieldingRELEASE 2

Decision Point

6 to 18 monthsUp to 2 yearsCoordinated DOD stakeholder involvement

ICD

CDD

CDD Capabilities Development Document

ICD Initial Capability Document

PrototypesIteration 1 Iteration 2 Iteration 3

Development & Demonstration

FieldingRELEASE “N”

1 Year Study – Dr Kaminski, Noel Longuemare, John Stenbit, Pricilla Guthrie, Industry, Academia, Former DARPA Director

Process Owner

Improve Operational

Process

DSB Recommended Scope of Change

IT Use by DODIT Use by DOD

Intent

New NSS Legacy NSS

Cyber NSS

Middle/ware

Data Process

Common Networks

CommSatellites

“Classic” NSS

Customer

Realization Process

DOD Milestone Process

DOD Milestone Process

Force Provider

Improve Weapon System

Infrastructure Provider

Provide Shared, Trustworthy, Ubiquitous, High Performance, Low Cost IT Infrastructure

IT to Support a National Security System

IT to Support an Operational Process

IT to Provide a Shared Infrastructure

New IT Acquisition ProcessNew IT Acquisition Process

War Fighting Process

Business Process

The Call For ChangeMarch DSB Consistently Supported By Others

Acquisition• Long acquisition cycle-times

• Successive layers … built over years • Limited flexibility and agility

Requirements• Understanding and prioritizing requirements

• Ineffective role and comm in acquisitions

Test/Evaluation• Testing is integrated too late and serially

• Lack of automated testing

Funding & Governance• Program-centric, not capability-centric

• Overlapping decision layers (e.g., multiple review processes)• Lack of customer-driven metrics

• Funding inflexibility & negative incentives

DoD Should Implement Agile -- Prioritization of Capabilities Throughout and Time-box Iterations Within Each Capability Increment

16

2 Year Study – Lt Gen Campbell, Dawn Meyerriecks, Microsoft, Google, Carnegie Mellon, Cohen Group

4 to 8 Week Iterations

Integrated T&E / Voice of the End User

Requirements Analysis, Re-prioritization & Planning

Architecture Refinement

Test Cases

Implementation

Integration

Testing

Verification & Validation

Design

Requirements Analysis, Re-prioritization & Planning

Architecture Refinement

Test Cases

Implementation

Integration

Testing

Verification & Validation

Design

Requirements Analysis, Re-prioritization & Planning

National Academies StudyAchieving Effective Acquisition of IT in the DoD, Dec 2009

Mission Apps

Mission Infrastructure

IT Infrastructure

Step Development with Mission Infrastructure

As The Base

Demonstrated Operational Value Constantly Increases with each Iteration

Op

era

tion

al V

alu

e

Iteration 0

Iteration 1

Iteration 2

Iteration n

Robust Operational Value

Initial DemonstratedOperational Value

What is an Agile Model

17

Mission Apps Mission Apps

Mission Infrastructure Mission Infrastructure

IT Infrastructure IT Infrastructure

Database / Integration

Business Logic / Services

Presentation / User Interface

2-Oct 30-Oct 30 Nov 30-Dec 91 MonthsLaterIteration Iteration Iteration

Data generated and used to calibrate the plan

Presentation / User Interface

Business Logic / Services

Database / Integration

1

Incremental& Iterative Delivery

2-Oct

2 3

Integration & “Big Bang”

Delivery

Significantly Changes Workforce Dynamics

DevelopmentTeam

Agile (AAM*) Waterfall (5000.2)

Inte

grat

ion

Inte

grat

ion

Inte

grat

ion

Comparison DSB Model to DoD 5000Why continued modifications will not work

DevelopmentTeam

User

* AAM = Acquisition Assurance Method, an ICH process standard

Analysis & Design Modelling Prototype Development

CT&E

• Establish a single entity accountable for rapid Test/Evaluation• Focus Capability T&E on the prioritized requirements of each

iteration (vs. release)• Significant amount (100% is the goal) of test automation• Treat Capability T&E as a shared resource

– Accomplish DT/OT/Iop/Security objectives– One team, one time, one set of conditions, one report

• Field deployable capability…start small; scale rapidly

Combined DT/OT/Interop/Security

Development and Demonstration

Iteration 1 Iteration 2 Iteration 3

RELEASE 1

CT&ECT&E CT&E

Test and Evaluation Paradigm Shift From Sequential to Agile Test/Evaluation

New Requirements ProcessJCIDS “IT Box” and Increased Combatant Command/User Role

• Scenario Based Requirements• User Story (include Req’ts and

Features) and Story Stack An active, living scope of work that

stakeholders use to drive the project• Annual Capability Roadmaps• Annual Expectation Management

Agreements• Domain understanding via

enhanced use of prototyping & modeling (activity diagrams, process models, spike solutions, etc)

• Delegation of JROC responsibilities

• Increased Combatant/User role throughout

• Creation of “Functional Manager” • Charged with requirements accountability

• Secretariat to delegated-JROC board• Responsible for maturing & prioritizing Req’ts• Serves as the regular, high-frequency,

interaction with acquisition

Early Adopters: Organization-Wide ChangesWithin The Intelligence Community

Problem: The Intelligence Community faces nimble adversaries who can take full advantage of the speed of IT innovation from commercial industry where the “end state” is not known and thus requires continual modernization consistent with the pace of technology

Solution: Based upon these guiding principles, an IC Agency implemented the following acquisition process:

• Major modernizations projects are broken into increments• Increments typically have 18-30 month duration• Increments are subdivided into “spins” lasting typically 90-120 days or shorter• Initial Operational Capability (IOC) achieved within each increment• Customers prioritizes capabilities within each increment• Use of gates, metrics and processes to create, test and deliver valued capability• Robust risk management and governance process based upon quarterly reviews

Program Initiation to MS B: 18 months (DoD: 41 months)MS B to initial delivery: 9 months (DoD: 47 months)

Integrated Strategic Planning and Analysis Network (ISPAN) Increment 2

Purpose: Authorizes tailoring of the Increment 2 program to achieve principles of Section 804 (of the 2010 NDAA)

while adhering to DoDD 5000.01

Guidance:• No Milestone A• Replaces a "Build Decision" with traditional Milestone B decision • Approves program to forgo a Milestone C• Tailors the Configuration Steering Board• Replaces OIPT with a co-chaired PEO/OIPT quarterly review forum• Implements annual Expectation Management Agreement to include the spend plan, schedule, and

capabilities to be delivered in the next l2-month period • Implements annual Capability Roadmap to define time-phased set of capabilities• Requires milestone doc to be signed within 45 days; if not, report to MDA required• Designates ISPAN Increment 2 a “Capital Program”

23

March 29, 2010 Acquisition Decision Memorandum Signed by Dr Carter

91 Months

Planning Phase

Analysis of Alternatives

EconomicAnalysis

Milestone B

MS C

40

48

5Test

43

Build Phase

Development

Initial Operating Capability

Numbers represent time in months

Generic MAIS Timeline*

33

Build Decision

12

Initial Operating Capability

ISPAN Timeline

Initial Delivery

13 9

MaterialDevelopment

Decision

Comparison of Projected Deliveries

* DSB Report,2009, Average of 32 MAIS

This Road Seems Awfully Familiar

Previous attempts at program level• Agile emphasized on NCTC Railhead Proposal

• Top IT program to fight terrorism

• Significant Gov & FFRDC team

• RFP Required Agile experience/Scrum expertise

• 2010 “Railhead’s $500M Colossal Failure”

- “Collapse of the Railhead result of poor technical planning and design, potential contractor mismanagement and inadequate government oversight” 25

Previous attempts to reform IT lacking• Brooks Act…..1972

• Centralized IT acquisition & management

• CCA - Clinger Cohen Act….1996• Computer Chaos “Billions Wasted Buying Federal IT”

• “Process of acquiring IT takes significantly longer than tech..”• Decentralized IT acquisition & management

• DoD Rapid Improvement Team…..2005• Capability Portfolio Management ……2008

DoD Directive 7045

DCMO-led Task Force(s) …. (2+ yrs later)

26

Portfolio & Governance

Portfolio & Governance Funding & ResourcingFunding & Resourcing

Acquisition ProcessAcquisition Process

ContractingContracting

ArchitectureArchitecture

Test, Evaluation, and Certification

Test, Evaluation, and Certification

RequirementsRequirements

UNCLEAR THERE IS ANY REPORT, RESULTS OR CONCLUSIONEffort Appears to Quietly Disappear!

Where Are We Today ?New DoD 5000 With Multiple IT Appendices/Templates

27

30 Pages of Detailed Process

No significant change to architecture, requirements,

funding, portfolio mgt, governance, contracting and

test/evaluation(DCMO-Task Force areas)

No Apparent Use ofExperience

From Early Adopters FDD

FY11 NDAA Section 933

Develop a strategy for the rapid acquisition of tools, apps, and other Develop a strategy for the rapid acquisition of tools, apps, and other capabilities for cyber warfare for USCYBERCOM and other cyber operations capabilities for cyber warfare for USCYBERCOM and other cyber operations components of militarycomponents of military

28

Orderly process for determining, approving operational Orderly process for determining, approving operational requirementsrequirementsWell-defined, repeatable, transparent, and disciplined process for developing Well-defined, repeatable, transparent, and disciplined process for developing capabilities IAW IT capabilities IAW IT AcquisitionAcquisition process processAllocation of facilities and other resources to thoroughly Allocation of facilities and other resources to thoroughly testtest capabilities in capabilities in development, before deployment and use to validate performance and take into development, before deployment and use to validate performance and take into account collateral damageaccount collateral damage

Orderly process for determining, approving operational Orderly process for determining, approving operational requirementsrequirementsWell-defined, repeatable, transparent, and disciplined process for developing Well-defined, repeatable, transparent, and disciplined process for developing capabilities IAW IT capabilities IAW IT AcquisitionAcquisition process processAllocation of facilities and other resources to thoroughly Allocation of facilities and other resources to thoroughly testtest capabilities in capabilities in development, before deployment and use to validate performance and take into development, before deployment and use to validate performance and take into account collateral damageaccount collateral damage

Submit report on Cyber Submit report on Cyber Acquisition Strategy to Acquisition Strategy to CongressCongress

Our plan is to first determine the best rapid Our plan is to first determine the best rapid acquisition solution for the Department, then vet acquisition solution for the Department, then vet through the Department leading to the final report for through the Department leading to the final report for congresscongress

Our plan is to first determine the best rapid Our plan is to first determine the best rapid acquisition solution for the Department, then vet acquisition solution for the Department, then vet through the Department leading to the final report for through the Department leading to the final report for congresscongress

Bottom Line Up Front (BLUF)

• Proposed Streamlined Requirements Process and Oversight Level• Leverage overarching ICDs for GIG Net Ops, Cyber Defense and Cyber Offense• Implement a “IT Box Concept” to support streamlined cyber requirements process

• Acquisition Process Tailored to Product (“What”) and Timelines (“When”)• Process A: <30 days – Standard Catalog – COTS/GOTS, IT Services• Process B: 1-9 Months – Simple Catalog Mods – Modified COTS/GOTS, SW Dev

• Testing • Perform testing as an integrated activity across development – DT/ OT, Interoperability, IA• Scale T&E – C&A scope & rigor based on acceptable risk to support acquisition timelines • Establish enterprise-level architectures for cyber test infrastructure and resources

• Cyber Governance• Establish a Senior Mgt Board to align technical, acquisition, and investment strategies• Oversee Development and Implementation of policies to acquire cyber via quarterly reviews• Collaborate with cyber governance bodies of requirements, acquisition, and test

• Funding• Dedicated funding for cyber required; exploring options

UNCLASSIFIED // FOUO 29

Rapid Cyber Acquisition Roadmap

DAG

DoDi on

Cyber

AcquisitionAcquisition DTM

T&E Policy(As needed)

JCIDS Updates

Develop & Validate Use CasesStakeholder Engagement

Working Group Activities

Report to CongressSubmitted

(Provided Overview)

Pilots

-Define Metrics

-Lessons Learned

-Refinement

Implementation PlanDevelopment

Refinement

Inform / UpdateInform / Update

Charter & Policy

SME/ Stakeholder Input

““Change is the law of life. And, those who look only to the Change is the law of life. And, those who look only to the past or present are certain to miss the future.”past or present are certain to miss the future.”

In IT DomainDoing Nothing is Not an Option

Contact Information

Mr Don JohnsonUSD(AT&L) DASD (C3 & Cyber)

(703) [email protected]