DoD Software Policy

Changes and Impact on Cost

Estimating

Darrell Hamilton

Professor Business Cost Estimating

JCIDS Manual12 Feb

JCIDS Manual18 Dec

CJCSI 3170.01I23 Jan

BBP 3.0 ImplementationApr 9

Actions to Improve DoD CompetitionAug 21

Use of LPTA Source Selection & Contract TypeMar 4

PPBE “Reset” (change to sequential review)

Dec 11

DoDI 5000.02Jan 7

Changes to Acquisition, Capability Requirements, & Program/Budget Processes2014 – 2020

For acronyms see notes page

DAG Major Restructure & Revision, All ChaptersFeb 2

Defense Innovation Unit (DUIx)Jul 2

DoDI 5000.74Jan 5

DoDI 5000.75Feb 2

JCIDS ManualAug 31

CJCSI 5123.01HAug 31

Middle Tier of Acquisition Interim AuthorityApr 16

DoDI 5000.02, Ch 2Feb 2

DoDI 5000.02, Ch 1Jan 26

Pricing Responsibilities & Warfighter LethalityJul 26

Defense Exportability FeaturesApr 9

Designation of MDA Dec 18

Source Selection ProcessApr 1 DBS Investment

Mgmt GuidanceJun 26

Other Transactions GuideJan 17

Guidebook for Acquiring Commercial Items, Parts A & B

JanRisk, Issue & Opportunity Guide for Acquisition PgmsApr 9

DOT&E TEMP GuidebookJan 19

RAM-C Report OutlineFeb 28

Improving Exportability Planning

Sep 13Program/Budget

Review- Return to PDMs & PBDs vice RMDs

Feb 26

DoDI 5000.02, Ch 3Aug 10

28 Jan 2020

Program/BudgetReview- Return to Integrated Review

Jun 14

2014 2015 2016 2017 2018 2019

DoDI 5000.02, Ch 4 Aug 31

DoD PrototypingGuidebookDec 6

DoDI 5010.44 Intellectual Property Acq & LicensingOct 16

Sustainment Factors in Weapon System Design

Jan 31

2020

OSD Policy Memo/Guide

Defense Acquisition

Guidebook (DAG)

Acquisition Policy/Revision

Change, Program Budget Process

Capability Requirements Policy/

Revision

DoDI 5000.81 Dec 31

DoDI 5000.02, Ch 5 Oct 21

DoD Manual 5000.78Rapid Acq AuthorityMar 20

Operational & LFT&E EvalGuidelines for MTAOct 24

Middle Tier of Acquisition Interim Governance 2Mar 20

DoDI 5000.80 Dec 30

Independent Tech Risk AssessmentsDec 31

Interim Guidance for TEMP Pilot ProgramApr 8

Establishment of USD(R&E) & USD(A&S)Jul 13

Middle Tier of Acquisition Interim GovernanceOct 9

JROCM, ExportabilityApr 15

DoDI 5000.02T, Ch 6 Jan 7

DoDI 5000.74 Jan 10

Software Acquisition Pathway Interim Policy Jan 3

DoDI 5000.02 Jan 23

DAG Update, Chapter 1, PM & Chapter 2, Intel SupportAug

Digital Modernization StrategyJul

Transforming Acquisition Policies

DODD 5000.01: The Defense Acquisition System

Updated to outline the overarching policies and responsibilities of key executives.

DODI 5000.02: Operation of the Adaptive Acquisition Framework

Outlines the six pathway of the Adaptive Acquisition Framework.

DODIs for Each Functional Area

T&EEngineering Cybersecurity AoAs Cost Est

ProgramProtectionIP HSI

AcquisitionIntelligence IT

3Owned by various OSD functional organizations

Middle Tier of Acquisition

Acquisition of Services (5000.74)

DODIs for Each Acquisition PathwayUrgent Capability

AcquisitionMajor Capability

Acquisition

SoftwareAcquisition*

Defense Business Systems (5000.75)

* Interim

5000.02T • Published in conjunction

with 5000.02• Covers functional policies

that have not been released yet

• Enclosures will cancel as functional policies are released

Adaptive Acquisition FrameworkEnable Execution at the Speed of Relevance

Tenets of the Defense Acquisition System1. Simplify Acquisition Policy2. Tailor Acquisition Approaches3. Empower Program Managers

4. Conduct Data Driven Analysis5. Actively Manage Risk6. Emphasize Sustainment

January 2020

Legend:ATP: Authority to ProceedDD: Disposition DecisionFOC: Full Operational CapabilityI: IterationIOC: Initial Operational CapabilityMDD: Materiel Development DecisionMS: MilestoneMVCR: Minimum Viable Capability ReleaseMVP: Minimum Viable ProductOD: Outcome DeterminationR: Release

xxC

ybe

rsec

uri

ty

PathSelection

Defense Business Systems

Middle Tierof Acquisition

Acquisition of Services

Major Capability

Acquisition

UrgentCapability

Acquisition

OP

ERA

TIO

NS

AN

D S

UST

AIN

MEN

T

Business Capability Acquisition Cycle

< 2 years

SoftwareAcquisition

RapidPrototyping

CapabilityNeed

Identification

SolutionAnalysis

FunctionalRequirements and

Acquisition Planning

Acquisition,Testing, and Deployment

CapabilitySupport

Pla

nn

ing

Ph

ase I1 I2…

MVP MVCR Rn

OD Rapid Fielding

10

MaterielSolutionsAnalysis

TechnologyMaturation and Risk Reduction

Engineering and ManufacturingDevelopment

Production and

Deployment

MDD MS A MS B MS C IOC FOC

ATP ATP ATP ATP

In In InExecution Phase

OD

≤ 5 years

< 1 year

DD

≤ 5 years

PLAN DEVELOP EXECUTE

1Form the

Team

2ReviewCurrentStrategy

3Perform Market

Research

4Define

Require-ments

5Develop

AcquisitionStrategy

6Execute Strategy

7Manage

Performance

DoDD 5000.01: The Defense Acquisition SystemDoDI 5000.02: Operation of the Adaptive Acquisition Framework

DoDI 5000.81

DoDI 5000.80

DoDI 5000.UG

Interim Policy

DoDI 5000.74

DoDI 5000.75

• Program managers may select and tailor one or more acquisition pathways to acquire and deliver capabilities

• Part of acquisition strategy for decision authority approval

• Programs may transition to other pathways as needed

• Tailor acquisition processes, documents, and reviews to enable speed, agility, and innovation

• Statutory (law) requirements must be met, whereas DoD and Service level policies may be tailored upon approval

Defense Business Systems

5

To acquire information systems that support

DoD business operations.

• Assesses the business environment, identify existing commercial or government solutions

• Review and revise DoD business processes to align more closely with IT best practices

• Minimal customization of a selected IT solution

No change since put in place in 2018

Why a New Software Acquisition Pathway?

DoDI 5000.02 milestones, models and documentation did not provide the proper structure for managing SW development

6

OLD WAY

NEW WAYSprints

S1 S2 ….. Sn Sn Sn

(MVP)Minimum

ViableProduct

(MVCR)Minimum

ViableCapability

Release

(Rn)Release(s)

Pla

nn

ing

Ph

ase

Execution Phase0 1

months

“…we need to catch up with the private sector and make sure we are using contemporary SW development processes,” -The Honorable Ellen Lord, USD, A&S

Software Acquisition

7

To facilitate rapid and iterative delivery of software capability

(e.g., software-intensive systems and/or software-

intensive components or sub-systems) to the user.

• Integrates modern software development practices such as Agile, DevSecOps, and Lean

• Active user engagement and leveraging enterprise services

• Working software is rapidly, iteratively delivered to meet the highest priority user needs.

• Leverage automated tools for development, integration, testing, and certification

• Based on Capability Needs Statement

– Not subject to JCIDS (the formal requirements process for hardware)

• Minimum Viable Product (MVP) due in “months”

• Minimum Viable Capability Requirement (MVCR) within a year *

– Minimum Marketable Product (MMP) is the commercial equivalent

• Subsequent major deliveries at least annually

• Requires iterative SW development practices such as: Agile, DevSecOps, Lean

• Automate testing & build DT & OT tests early

• Active user engagement with the SW teams

• Bake-in cybersecurity

Custom Software

*• NDAA: demonstrate

viability/effectiveness of

capabilities for

operational use not

later than after the date

on which funds are first

obligated for SW

• Currently unclear if that

can happen at MVP

• What is Agile and how does it differ from past practice?

• When in the process does software go into a maintenance phase?

• How does Agile save the government money?

• What is the primary challenge of Agile on government cost estimating?

Policy and Cost Implications

10

Paradigm comparisons

Agile allows us to refine ideas over time

and deliver in small chunks.

Development may stop at “good

enough”.

Iterative or Evolutionary goes from

rough to polished, allowing us to refine

ideas over time.

Incremental assumes we know what

we want and builds in pieces.

Waterfall assumes we know what we

want and builds all-at-once.

“Woman with Umbrella” - Monet

Build 1

Build 2

Build 3

Patch 2.1

Build 4

Patch 3.1

Patch 3.2

Build 5

Patch 4.1

Build 6

Patch 4.2

Patch 4.3

Patch 4.4

Patch 4.5

Patch 5.1

Patch 5.2

Patch 5.3

Merge into

Development Maintenance

• A new (for DoD) recognition that software is never finished

• Current Sustainment definitions are inadequate (expect more changes)

• Currently experimenting with a “software” color of money to go along with this

Software is eternal

How Agile benefits DoD

What makes this difficult to estimate

• DoD only starting to appreciate complexities

– Has to rely on FP and SLOC methods

– Improving data

• “Typical” creep in the 30-100% range

• Requirements Discovery knows no bounds

– 200%? 1000%?

• Ideas being floated/tried

– Variations on “level of effort”

AAF website

• https://www.dau.edu/aaf/

• New 5000 meant to be accessed via DAU

hosted website

• OSD owns the content with DAU SMEs identified to

help build content– Will provide policy and guidance for each pathway

– Taking advantage of existing tools/videos/powerful examples/etc

WHAT is required and HOW do I do it

Questions?

Thanks!