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!