Software Acquisition

Each page in this pathway presents a wealth of curated knowledge from acquisition policies, guides, templates, training, reports, websites, case studies, and other resources. It also provides a framework for functional experts and practitioners across DoD to contribute to the collective knowledge base. This site aggregates official DoD policies, guides, references, and more.

DoD and Service policy is indicated by a BLUE vertical line.

Directly quoted material is preceeded with a link to the Reference Source.

Reference Source: USD(A&S) Guidance

Templates for SWP Artifacts (Acquisition Strategy, Capability Needs Statement, Test Strategy, User Agreement, Value Assessment)

Reference Source: USD(A&S) Guidance

While the Clinger-Cohen Act is statutory for all IT programs (in the broadest use of that term), there may be creative ways to achieve compliance using alternative SWP artifacts.  Consult with your CCA Approver early so you can understand the options you have to tailor compliance in this area.

Reference Source: USD(A&S) Guidance

BLUF: Programs using the Software Acquisition Pathway (SWP) should not baseline cost, schedule, and performance.  An Acquisition Program Baseline (APB) is not required and in fact is highly discouraged.

• This includes programs transitioning from other AAF pathways or legacy 5000.02 models. When requesting Decision Authority approval to enter the Software Pathway, programs transitioning should also request closeout of current APBs.
• Traditional baselines are associated with (and required for) hardware intensive systems using the Major Capability Acquisition pathway. Congress established the SWP with explicit exemption from MDAP processes in order to drive more dynamic, modern software development.
  • Generally APBs can drive behaviors which run counter to modern digital product delivery. This includes over definition of upfront requirements and associated long range cost estimates that do not allow for discovery and are not informed by small batch, iterative deliveries. In addition to running counter to these desired approaches, APBs cannot keep pace with dynamic changes to needs — and therefore the corresponding financial resources and delivery timelines – that will be increasingly expected in a volatile, uncertain and complex tech and threat environment.
  • Understanding cost efficient and timely deliveries remains important, but there are more modern management approaches and controls suited for dynamic executions at the speed of relevance and SWP.
• Instead of establishing a baseline, SWP programs should apply modern software development practices (Agile, DevSecOps, Lean, and Human Centered Design) which promotes delivery of iterative and frequent software upgrades to satisfy user’s current highest priorities.

OLD WAY

• Conduct extensive analysis of alternatives and technology maturity
• Define program requirements upfront and lock them down in perpetuity
• Develop lifecycle cost estimates based on long-term program requirements
• Develop and coordinate extensive acquisition, contracting, systems engineering, test and evaluation, product support and related plans that are rarely, if ever, updated.
• Baseline costs, schedule, and performance in an APB before any insights from development
• Measure a program’s performance against APB baselines and declare breaches if exceeded
• Track contractor performance via Earned Value Management against rigid plans and schedules.
• Programs punished when poor predictions lead to changes and cost and schedule impacts

NEW WAY

• Scope, requirements, budgets, cost estimates, and designs expected to change based on changing operational needs, threat changes, and cybersecurity upgrades.
• Programs deliver capability on a regular cadence maintaining a focus on addressing highest priority user requirements first.
• Progress is measured by user perception of the value delivered (conveyed in value assessments) and specific performance metrics (determined by the DA) in lieu of milestone progress. Metrics can be used to measure
  • Speed of delivery
  • Frequency of releases
  • Quality of software
  • Responsiveness to cyber threats
• Acquirers and developers actively engage user community throughout development to understand environment, priorities, performance and feedback on earlier releases/demos.
• Program sponsor (with user input) provides written value assessment at least annually.
• Continuously evolve program scope, budgets, designs, strategies, and functionality.

DODI 5000.87 does not require SWP programs to develop/manage to an APB.

• Acquisition executives and decision authorities should not impose constraints and risks on programs by mandating an APB and managing via legacy major hardware-centric programs.