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.

A: The intent of the Directive is that the SWP can be used for every system type in the DoD, and any combat, combat support, or business system program. Programs on the SWP are delivering a range of capabilities: command and control, decision support, cyber, business, and weapon systems. Weapon systems also include application and cloud native system types such as C2, Intel, Decision Support, and Cyber.

In general, this Directive applies to all system types, given the SWP has specific sub-paths for applications, embedded systems, and business systems. As such, the Directive and the SWP have applicability to all warfighting and system domains. Hybrid acquisitions combining the use of SWP with other pathways can be used to de-couple hardware and software acquisition, as applicable and appropriate.

Particularly for DBS systems, SWP should not be limited to purely custom development but also building new workflows, configuration, robotic process automation, low-code/no-code, etc. This includes modifications of a type customarily or not customarily available in the commercial marketplace to meet DoD requirements.

The Directive recognizes that the DoD must reframe acquisition and the force to be software-centric in an era of software-defined warfare. Software acquisition and development for business and weapons systems, and discussed above, will be conducted using the SWP.

A: Commander’s intent is to “think, act, and do differently.” The intent of the Directive is that the Software Acquisition Pathway can be used for every system type in the DoD, and any combat, combat support or business system program.

Programs in planning (prior to signed Acquisition Strategy(AS)) should transition to SWP or adopt hybrid pathway approaches. Programs currently executing (post signed AS) and delivering capabilities to the Warfighter should continue executing. However, those programs should identify a plan to transition the software development components to the SWP, in accordance with the Directive*.

*Component Acquisition Executives and their delegated Decision Authorities should require justification for programs not using or transitioning to the SWP.

A: Programs that intend to transition, in whole or in part, from another AAF pathway to the SWP should update their acquisition strategy and have a Decision Authority (DA) approved transition plan before the transition is executed via a signed Acquisition Decision Memorandum (ADM) signed by their DA authorizing use of the SWP.

The intent for SW programs currently in development that transition to the SWP is to continue delivering software capabilities. The intent is NOT to pause the program to redo and staff many program documents for approval. Programs should reuse existing artifacts as much as is reasonable and allow programs to continue delivering software capabilities during the transition.  Programs should reuse existing artifacts as much as is reasonable and allow programs to continue delivering software capabilities during the transition.

Program Managers, in partnership with their DA and key stakeholders, should lay out a transition plan which may include developing and/or updating key documents within a set timeframe. The purpose of the transition plan is to ensure a program is set-up to successfully deliver software capabilities leveraging modern software development processes and SWP acquisition best practices. Transition plans should reflect the program’s consideration of the extent to which its strategies, processes, and artifacts will be updated to reflect SWP requirements and a pivot to modern software practices, e.g. Agile, DevSecOps, and Lean.

The DA should ensure that programs being considered for transition to the SWP from another AAF pathway, in whole or in part, are prepared and that this preparation is reflected in their artifacts. The DA may decide to have the program enter the SWP Planning Phase to update strategies, designs, and more. The DA may approve the program to enter the SWP via the Execution Phase if it has the required information (or equivalent documents), with expectations on updating strategies, designs, and processes while continuing to develop and deliver software.

Per DODI 5000.87, Section 3.2.b: “Programs using the software acquisition pathway will be identified in component and DoD program lists and databases within 60 calendar days of initiating the planning phase in accordance with DoD’s implementation of Section 913 of Public Law 115-91 on acquisition data analysis.”

A: Programs currently executing and delivering capability are not required to immediately switch to the SWP or change contracts. However, programs should pursue immediate opportunities to improve software delivery processes and leverage commercial developers/solutions through CSO processes and OT awards and transition to the SWP at the next logical point, in accordance with the Directive and as addressed by the Applicability questions.

A: The SWP is designed to facilitate rapid and iterative delivery of software capability to the user.  It is based on commercial product delivery and purpose-built for rapid innovation cycles that give our Warfighters competitive advantage on the battlefield.  The SWP model includes leveraging flexible contracting strategies that create opportunities for non-traditional contractors to contribute innovative capabilities to larger program objectives.

Acquiring software development solutions requires flexibility in business arrangements in structure to reduce barriers to entry for viable commercial providers. Leveraging CSOs and OTs lowers barriers and enables faster more flexible solicitation processes and awards.

• SWP Contracting

A: We are aligning our acquisition strategies to ensure rapid delivery is not achieved at the expense of security or interoperability.

Contractors will be required to adhere to applicable DoD cybersecurity frameworks and undergo testing to confirm compliance with DoD standards.  The SWP policy has an intense focus on cybersecurity.

• SWP Cybersecurity

The DoD Software Cadre within A&S championed the API Strategy for DoD that will be required for SWP programs. PMs will plan how they expose their data and services to ensure data exchange and rapid integrations of software and analytics.

• SWP API Strategy
• SWP Enterprise Services and DevSecOps

A: Effective and successful SWP programs are driven by the skill and expertise of program teams executing modern software development practices and SWP processes combined with flexible contractual agreements. Leveraging modular contracting strategies resulting in OT awards enables programs to award to multiple contractors and provides flexibility to pivot to another solution provider if a contractor is not delivering capability agreed to by both parties. This flexibility ultimately reduces long-term costs and inefficiencies and mitigates program risk by not reducing reliance on a single contractor.

• SWP Contracting

The SWP model is based on commercial product delivery best practices and modern software development. Some of these elements include:

Government management of Program Roadmaps and Backlogs along with continuous collaboration with contractor development teams to execute DevSecOps and Agile software development practices provides insight into the progress of development teams to deliver working capability desired by users

• SWP Execution
• Agile 101 Primer

Programs will develop and track program management metrics to provide leadership, the Product Owner, team members, and other key stakeholders information and insights into the development effort to guide technical/programmatic decision-making, continuous improvement efforts, and remediation of blockers/impediments.  The program will continue to update its cost estimates and software data reporting from the planning phase throughout the execution phase.

• SWP Metrics and Reporting

Value Assessments measure the program’s progress toward meeting user needs and enable the program to determine if the cost of the software development effort is commensurate with the value it provides.

• Value Assessment

A: Not necessarily. Over the last several years, the Department has made extensive investments in the infrastructure needed to implement DevSecOps and related modern software practices, including Software Factories and trusted container repositories.

Acquisition programs can get access to technical solutions that provide tailored resources for key warfighting domains and make those solutions available to their contractors. In addition, an expanding commercial ecosystem offers access to services for contractors directly to develop their software.

• Enterprise Services and DevSecOps

A: This Directive is designed to foster competition and provide opportunities for non-traditional contractors. By using processes like Commercial Solutions Openings (CSO) and issuing Other Transaction (OT) awards, the Department is making it easier for non-traditional contractors, including small businesses, to bring their solutions to the Department without the need to navigate burdensome bureaucracy. Using software acquisition models that use commercial practices reflects how commercial companies prefer to develop products – and adopting CSOs and OTs offer a faster, more flexible way for non-traditional contractors to bring their solutions to the Department.

A: In general:

• Congress elevated the SWP HW to guidance into 10 U.S.C. §3603 and emphasized that HW buys on the SWP are to be expected:

 “(1) Applications. -The applications pathway shall provide for the use of rapid development and implementation of applications and other software or software improvements operated by the Department of Defense, which may include applications and associated procurement of covered hardware (including modifications of a type not customarily available in the commercial marketplace to meet Department requirements), commercially available cloud computing platforms, and other non-developmental items.”

• SWP does not preclude contracting for hardware.  There is no threshold for procurement of hardware items in direct support of development, testing, training, and fielding activities.
• The Software Acquisition Pathway supports the integration and deployment of software components into both applications and embedded systems.

Given the above, programs (e.g., autonomous systems) using pre-built hardware can be fully acquired on the SWP.  Programs that require the use of pre-built hardware may manage both software and hardware components under the Software Pathway, especially when integration is critical for functionality.

In terms of hybrid acquisition, this is warranted in certain situations.  (Note: the DoD Software Cadre is releasing its Weapons Ignite toolkit with detailed guidance on this approach; we will update this FAQ and our website when it is released.)

Programs deploying Commercial Off the Shelf (COTS) hardware non-developmental items (NDI) hardware, or Government Off the Shelf (GOTS) hardware should transition to the SWP at the next milestone review (e.g., MS-C, LRIP, Full Rate Production or Sustainment) in accordance with the Directive.

• Procuring HW on the SWP

Programs with custom hardware solutions should move to a hybrid acquisition pathway approach with the hardware and full system integration executed under the MCA/MTA pathway and software under the SWP using the Embedded Software sub-path IAW with the Directive.

• SWP (General Procedures toggle)

A: Congress elevated the SWP HW to guidance into 10 U.S.C. §3603 and emphasized that HW buys on the SWP are to be expected:  “(1) Applications.-The applications pathway shall provide for the use of rapid development and implementation of applications and other software or software improvements operated by the Department of Defense, which may include applications and associated procurement of covered hardware (including modifications of a type not customarily available in the commercial marketplace to meet Department requirements), commercially available cloud computing platforms, and other nondevelopmental items.”

SWP does not preclude contracting for hardware. Programs (e.g., acquiring autonomous systems) that require the use of non-developmental, COTS, or GOTS hardware may manage both the software and hardware components under the Software Pathway when integration is critical for functionality. 10 U.S.C. §3603 addresses covered hardware as part of software acquisition pathways. Covered hardware is defined as:

• Hardware that is a commercial product (as defined in 41 U.S.C. §103) or a nondevelopment item; and
• Hardware in which software acquired under section 3603 is embedded.

Congress was encouraged by the Directive that directs all DOD components to use the SWP as the “preferred pathway for all software development” to include weapon systems programs. The Directive notes, “DOD has struggled to reframe its acquisition process from a hardware-centric approach to a software-centric approach” and as a result, “it is the warfighter who pays the price.”  They want to see the memo and SWP applied to accelerate software acquisition – particularly within autonomous systems.

The SWP includes guidance for appropriate use of the pathway for hardware.

• Procuring HW on the SWP

A: The 10 U.S.C. §3458 CSO process is implemented in DFARS 212.70 and thereby introduces FAR requirements (e.g., Competition in Contracting Act (CICA) compliance) and limits resultant Prototype OT awards to fixed-price and fixed-price incentive arrangements. OTs are ultimately the preferred approach – as amplified in Executive Order 14265 Modernizing Defense Acquisitions and Spurring Innovation in the Defense Industrial Base, which includes “a first preference for commercial solutions and a general preference for Other Transactions Authority…”.

DIU’s CSO process (different from the 10 U.S.C. §3458 CSO process implemented in the DFARS) was developed specifically to award 10 U.S.C. §4022 Prototype OTs and is defined in the DoD OT Guidebook. DIU’s CSO process satisfies the maximum extent practicable competition requirement for 10 U.S.C. §4022 Prototype OTs (CICA is N/A) while providing maximum flexibility in award selections, to include fixed-price or expenditure-based arrangements.

• DoD OT Guidebook
• DIU

At its core, the DIU CSO is a competitive solicitation process with three phases focused on being “fast, flexible, and collaborative for innovative prototyping projects. DIU’s CSO three-phase competitive process includes: prepare a solution brief, pitch, and complete written proposal.

• Phase 1 Solution Briefs: Solution briefs are either a paper no more than 5 pages or a presentation no longer than 15 slides. The solution brief should detail the technology concept and provide information on the company.
• Phase 2 Pitch Session: The pitch is the second phase of the CSO process. This step mirrors how a start-up would pitch a venture capital firm for funding, or a vendor would attempt to secure a contract from another commercial firm. Companies invited to Phase 2 pitch additional details on project rough order of magnitude cost, schedule, as well as discuss data rights.
• Phase 3 Request for Prototype Proposal (RPP): This phase applies to the companies DIU determined had potentially meritorious proposed solutions. Companies invited to Phase 3 will submit proposals to be reviewed and negotiated by the Government.

Other similarly innovative OT processes can be used to accelerate solicitation and award.

A: A CSO is a solicitation process designed to streamline the acquisition of innovative commercial products, services, and technologies. It allows government agencies to engage with industry partners and issue Prototype OT awards without the rigid requirements of traditional acquisition methods.

Other Transaction (OT) agreements and FAR-based contracts are awards, of which both are possible under the 10 U.S.C. §3458 CSO process. OTs are ultimately the preferred approach – as amplified in the Executive Order 14265 Modernizing Defense Acquisitions and Spurring Innovation in the Defense Industrial Base which includes “a first preference for commercial solutions and a general preference for Other Transactions Authority…”.

See previous question for additional information re: CSOs.

A: No special authority is required to leverage CSO processes.

A: The CSO solicitation process is designed to streamline the acquisition of innovative commercial products, services, and technologies and award Prototype OTs under 10 U.S.C. §4022. Successfully completed Prototype OT projects can follow-on to non-competitive production OTs or FAR contracts pursuant to 10 U.S.C. §4022(f).

• Prototype Other Transactions
• DoD OT Guidebook

A: The Directive establishes the CSO and OT process as the default solicitation and award approaches for acquiring software capabilities using the SWP.

A: The use of CSOs and OTs lowers the barriers to entry for companies that don’t traditionally work with the DoD.  The DoD must leverage the entire American innovation ecosystem to provide the most innovative capabilities possible to our Warfighters.  We are in an era of software-defined warfare.  The innovation ecosystem is particularly strong for software-based capabilities including cyber, autonomy, and AI-enabled systems.

CSO processes can be leveraged to award Prototype OT agreements. The competitive nature of CSO processes satisfies the “competition to maximum extent practicable” requirement for Prototype OTs and enables non-competitive follow-on production agreements or contracts for successfully completed prototypes pursuant to 10 U.S.C. §4022(f).

• DoD OT Guidebook
• Prototype Other Transactions

A: No. CSO is a competitive solicitation process that is not restricted to non-traditional contractors. However, there are criteria to award Prototype OTs (10 U.S.C. §4022) to traditional contractors that include non-traditional contractor or small business participation or cost-sharing arrangements.

• Prototype OT
• DoD OT Guidebook

A: CSO is a solicitation process, not a contractual vehicle. The CSO process can be leveraged to award Prototype OTs which scale to follow-on Production OTs or FAR contracts pursuant to 10 U.S.C. §4022(f).

• Prototype Other Transactions
• DoD OT Guidebook

A: The Prototype OT authority (10 U.S.C. §4022) allows agencies to acquire solutions separate from FAR/DFARS evaluation and source selection procedures to streamline award timelines and negotiate terms and conditions that more closely align with the commercial marketplace to deliver capabilities to warfighters more efficiently. Successfully completed Prototype OT projects can follow-on to subsequent non-competitive production OT awards or FAR contracts pursuant to 10 U.S.C. §4022(f).

The use of OTs lowers the barriers to entry to companies that don’t traditionally work with the DoD.  The DoD must leverage the entire American innovation ecosystem to provide the most innovative capabilities possible to our Warfighters.  We are in an era of software-defined warfare.  The innovation ecosystem is particularly strong for software-based capabilities including cyber, autonomy, and AI-enabled systems.  The use of OTs supports our goal to streamline the acquisition of innovative commercial products, services, and technologies.

• Prototype Other Transactions
• DoD OT Guidebook

A: Programs are not precluded from leveraging existing OT Consortia to award Prototype OT agreements. Awarding OTs on a project by project basis provides a competitive environment where all companies can compete. OT Consortia competitions are limited to members of the selected consortium.

• SWP Contracting
• Prototype Other Transactions
• DoD OT Guidebook
• Existing OT Consortia

A: The SWP calls for a modular contracting strategy that enables a SWP program to establish contracts with different objectives to best meet the requirements and objectives throughout a program’s lifecycle. Modular contracting is an approach that divides an acquisition into smaller increments with the intended outcomes of reducing program risk, continuously acquiring rapidly changing technology, and enabling flexibility for programs to scale, as well as creating opportunities for non-traditional contractors to contribute innovative capabilities to larger program objectives.

• SWP Contracting

The DoD should identify Government core intellectual property (IP) use cases early and negotiate detailed terms and conditions focused on the specific intellectual property and data rights specific to the program and mission needs. In a collaborative contracting environment like the CSO process, it is especially critical that the Government independently understands its IP needs and employs the best practices identified in the IP Guidebook.

• Intellectual Property Guidebook for DoD Acquisition

A: Data rights and IP rights can and should be specifically negotiated under OTs. SWP OT agreements should include IP arrangements that allow companies to retain ownership where appropriate, while ensuring that the DoD can maintain and operate critical capabilities over time. There are no standard license rights granted in OTs. Each OT agreement should have its own specific rights framework negotiated between the parties. It is recommended to NOT templatize rights assertion, especially where software services and licenses are combined.

Programs should develop unique and tailored IP agreements for rights in technical data (TD), computer software (CS), and any other necessary data. As non-FAR based contracts, the standard DFARS data rights categories and rules do not apply to OTs. Instead, it is the Government’s responsibility to plan for and craft TD, CS, and license rights necessary to meet its short and long-term mission goals and objectives.

Additionally, Government funding of technology under an OT does NOT count as Government investment for purposes of applying the funding rule for DFARS data rights in future FAR-based contracts. This makes it more critical for DoD to be a good steward of taxpayer dollars by ensuring that the Government acquires the TD, CS, and rights embodying any Government funded technology development to meet DoD needs.

• SWP IP Strategy
• SWP Contracting
• Intellectual Property Guidebook for DoD Acquisition
• DoD IP Cadre

A: DoD has developed an implementation plan for the SW Lethality Directive that is led by the DoD Software Cadre and includes acquisition workforce training in collaboration with the Defense Innovation Unit, Defense Acquisition University, and other applicable organizations. The Software Cadre will provide support to programs seeking to adopt or transition to the SWP.

Request support from the DoD SW Cadre Director and team:

• Email the Director [email protected] and SWP team [email protected]
• Request a SWP Roadshow: https://aaf.dau.edu/aaf/software/roadshowrequest/

Additional training resources:

• DIU
• DAU Software Acquisition Training

The SWP website also provides extensive resources and guidance for SWP adoption and best practices.

• Software Acquisition Pathway

The SWP includes a “getting started” page to help the acquisition workforce navigate the resources that are available.

• SWP Quick Start Primer 

A: A new software acquisition program using the SWP should have an Acquisition Decision Memorandum (ADM) signed by their Decision Authority authorizing use of the SWP and a draft Capability Needs Statement (CNS), Software-ICD, or equivalent draft requirements document. Each Service/ Agency will have unique policies on what constitutes a “draft” requirements document. Per DODI 5000.87, Section 3.2.b: “Programs using the software acquisition pathway will be identified in component and DoD program lists and databases within 60 calendar days of initiating the planning phase in accordance with DoD’s implementation of Section 913 of Public Law 115-91 on acquisition data analysis.”

Upon approval to use the SWP, programs are requested to notify the USD(A&S) Acquisition Enablers office by completing the registration form (CAC required) with basic program information for OSD and Congressional insight into pathway usage and sending to mailto:[email protected]. This will be an interim measure until formal reporting systems are updated to account for the SWP.

A: Programs that intend to transition, in whole or in part, from another AAF pathway to the SWP should update their acquisition strategy and have a Decision Authority (DA) approved transition plan before the transition is executed via a signed Acquisition Decision Memorandum (ADM) signed by their DA authorizing use of the SWP.

The intent for SW programs currently in development that transition to the SWP is to continue delivering software capabilities. The intent is NOT to pause the program to redo and staff many program documents for approval. Programs should reuse existing artifacts as much as is reasonable and allow programs to continue delivering software capabilities during the transition.  Programs should reuse existing artifacts as much as is reasonable and allow programs to continue delivering software capabilities during the transition.

Program Managers, in partnership with their DA and key stakeholders, should lay out a transition plan which may include developing and/or updating key documents within a set timeframe. The purpose of the transition plan is to ensure a program is set-up to successfully deliver software capabilities leveraging modern software development processes and SWP acquisition best practices. Transition plans should reflect the program’s consideration of the extent to which its strategies, processes, and artifacts will be updated to reflect SWP requirements and a pivot to modern software practices, e.g. Agile, DevSecOps, and Lean.

The DA should ensure that programs being considered for transition to the SWP from another AAF pathway, in whole or in part, are prepared and that this preparation is reflected in their artifacts. The DA may decide to have the program enter the SWP Planning Phase to update strategies, designs, and more. The DA may approve the program to enter the SWP via the Execution Phase if it has the required information (or equivalent documents), with expectations on updating strategies, designs, and processes while continuing to develop and deliver software.

Per DODI 5000.87, Section 3.2.b: “Programs using the software acquisition pathway will be identified in component and DoD program lists and databases within 60 calendar days of initiating the planning phase in accordance with DoD’s implementation of Section 913 of Public Law 115-91 on acquisition data analysis.”

A: Absolutely. One of the two paths within the SWP is the embedded software path which provides for the rapid development, deployment, and insertion of upgrades and improvements to software embedded in weapon systems and other military-unique hardware systems.  The system in which the software is embedded could be acquired via other acquisition pathways (e.g., major capability acquisition). Major programs such as AIAMD and Kessel Run are using the SWP. This is per FY20 NDAA Section 800 (P.L. 116-92).

A: No, the SWP is used by programs ranging from small software acquisitions to software embedded in large billion-dollar programs. In general, modern software development practices like Agile and DevSecOps are most effective for smaller programs. Large programs should consider adopting a portfolio approach with multiple smaller software programs to enable greater speed and agility.

A: While Industry has used Agile and DevSecOps for 20 years, the DoD and Federal Gov’t have only started to adopt them over the last few years. These practices run counter to many DoD processes and culture. Culture is one of the biggest challenges to move from predefining the program upfront to being empowering teams to be responsive to changes. DoD’s processes have long timelines and costly changes yet must be redesigned for speed and agility with software. Users are actively involved throughout SW development in the new paradigm. Programs historically were structured with a fixed scope and measured against an APB and EVM. The new model has small iterative releases, tailored processes, with regular value assessments. Agile and DevSecOps requires modern training and experience beyond the development team to include the program office, key stakeholder orgs, and oversight.

A: The AoS pathway, governed by DODI 5000.74 and FAR Part 37, is regularly used to acquire commercial services. While AoS is technically an acquisition pathway, it is primarily a 7-step contracting process that was never intended to provide the necessary structure to execute a formal acquisition program. An AoS acquisition strategy doesn’t address the programmatic elements required of a formal acquisition program. Services Category (S-CAT) decision authorities are also not authorized to serve as the Milestone Decision Authority or Decision Authority for a defense acquisition program.

DODI 5000.74 section 1.1.b(8) notes the AoS pathway does NOT apply to: “Services that are managed and reviewed as part of acquisition programs under other pathways of the Adaptive Acquisition Framework.” Therefore, leveraging services contracts does not mean a program is “on the AoS pathway.” IT services contracts in support of SWP programs may be awarded using AoS procedures while fully operating under SWP policy and processes. Said another way, a software program cannot adopt the AoS pathway as an acquisition strategy, but it can use the AoS procedures to award IT services contracts as components of a modular contracting strategy in support of SWP program execution. See the Contracting Strategies page for more information.

A: SWP is the preferred acronym for the Software Acquisition Pathway. As DoD loves acronyms, SAP was already taken for Special Access Program – classified programs. The Defense Innovation Board used SWAP for their Software Acquisition Practices (SWAP) study. Weapon system designs include SWAP for Size Weight and Power. So, you could have a SAP that leverages the SWP to deliver software per the SWAP direction without having to worry about SWAP. Got it?

A: Yes, per FY20 NDAA Section 800, “Software acquired or developed using the authority under this section shall not be treated as a major defense acquisition program for purposes of section 2430 of title 10, United States Code, or Department of Defense Directive 5000.01 without the specific direction of the Under Secretary of Defense for Acquisition and Sustainment or a Senior Acquisition Executive.” Some DoD policies may require additional documents or reviews for larger SWP programs.

A: No, ACATs only apply to the Major Capability Acquisition pathway. However, for convenience, some DoD policies use ACAT I and II-dollar thresholds for certain requirements that large programs (including SWP) must do, yet these are limited. In general, it is better to keep software acquisition programs smaller to enable small, frequent releases.

A: No. 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 because modern software development embraces changes to requirements and designs throughout development, which drives changes to cost and schedule. 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. 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. See the Modern Software Management Approaches to Baselines and Progress section of the Develop Strategies page.

A: EVM runs counter to modern software development practices and should be avoided for SWP contracts. Per DoD implementation of DFARS, EVM is required for cost or incentive contracts and subcontracts greater than $20 million. As part of their contract strategy, SWP programs could explore fixed-price or T&M contracts and constrain contracts to <$20 million. The Defense Innovation Board and Section 809 Panel recommended eliminating EVM from software acquisitions.

A: Yes. While the Clinger-Cohen Act is statutory for all IT programs (in the broadest use of that term), the constrained set of SWP artifacts meet the requirements. See the Clinger Cohen Act Compliance Consideration section of the Develop Strategies page. Consult with your CCA Approver early to ensure a common understanding of the program artifacts you intend to develop meet CCA compliance.

A: See the new Software in NDAAs page for both the legislative language now in public law along with the Conference Report that conveys the intent, motivation, or direction from Congress.

A: Current acquisition programs with approved requirements documents that transition to the SWP may continue to use them as the basis of requirements or develop a CNS to capture current, software-unique needs. The sponsor, in consultation with the decision authority and program manager, will decide. The sponsor will periodically update the CNS throughout development as required to reflect the current high-level operational needs for the software solution.
See CNS Guidance for additional details.

A: If a SWP is developing a new SW-ICD, per the new JCIDS Manual: “The NR-KPP table should focus only on the performance attributes within the scope of the software capabilities defined in this document. It should reference other systems or documents that capture the broader network or weapon system Net-Ready performance attributes.” Programs that Joint Staff determines don’t have Joint equities may use a Capability Needs Statement which does not have Net-Ready KPPs.

A: The product owner, and program office will develop and maintain a product roadmap to plan regular and iterative deliveries of software capabilities. The product owner and program office will also develop and maintain program backlogs that identify detailed user needs in prioritized lists. The backlogs allow for dynamic reallocation of current and planned software releases. Issues, errors, threats, and defects identified during development and operations, including software updates from third parties or suppliers, should be captured in the program’s backlogs to address in future iterations and releases. Regular stakeholder feedback and inputs will shape the product roadmap and program backlogs. See Define Capability Needs page for additional information.

A: The Information Required for Software Acquisition Pathway Programs toggle on the Develop Strategies page has tables of all the statutory and regulatory information required. SWP programs, per their DA approval, are strongly encouraged to tailor and streamline the information into a few program documents. The intent is to balance speed with rigor to capture sufficient information to inform decisions and stakeholders. Program processes and strategies will continuously improve throughout development.

Templates for Acquisition Strategy, Capability Needs Statement, Test Strategy, User Agreement, and Value Assessment are also available.

A: Traditionally, acquisition programs have assessed cost, schedule, and performance measures at the endpoints of (very lengthy) development efforts, requiring long-term projections of envisioned operational performance needs, anticipated costs, and durations of associated efforts. In contrast, a SWP program uses a Value Assessment at least annually to assess whether the program is meeting user needs or whether the program should pivot or cease. This Value Assessment approach is more representative of modern software practice for rapid, efficient, and successful software efforts. A Value Assessment typically includes a range of measures (spanning cost, schedule, and performance), guided by an overarching program roadmap and dynamic user priorities, to ensure that program resources (including teams and funding) are focused and efficiently applied to achieve the most-needed capabilities. See the Value Assessment page for more information.

A: Programs using the software acquisition pathway will demonstrate the viability and effectiveness of capabilities for operational use not later than 1 year after the date on which funds are first obligated to develop the new software capability. New capabilities will be delivered to operations at least annually to iteratively meet requirements, but more frequent updates and deliveries are encouraged where practical. For programs using the embedded software path, this annual update applies after initial operational acceptance of the system in which the software is embedded and should be aligned with the associated system’s schedule. Before the operational acceptance of the system in which the software is embedded, software deliveries will be delivered to an operationally representative environment at least annually.

Congress further stressed in the FY21 NDAA Section 835 Joint Explanatory Statement: Provide for delivery of capability to end-users not later than 1 year after funds are obligated noting that other Government-wide policy and best practices call for updates no less frequently than once every 6 months.

For additional details, see Deployment Frequency guidance section of the MVP/MVCR/Deployment page.

 A: Failing to meet the one-year release requirement does not immediately result in a program being removed from the SWP.  A program that recognizes they will not meet the 1-year requirement needs to identify a corrective action plan that is reviewed and concurred with by the Decision Authority.  This plan should provide a short summary of what process or development environment improvements the program will incorporate to accelerate deployment frequency.  If there are external challenges, such as supply chain issues, prolonged Authority to Operate approvals or operational test events, driving the inability to field within a year, the program should detail the steps that have been taken to address the delays and highlight any support needed from leadership.  If a program is consistently unable to meet the 1-year requirement and does not have a viable corrective action plan, the Decision Authority should consider the use of a different pathway.

 Another case for shifting releases outside of current program cadence is when a key capability is a sprint or two outside of the current planned release baseline. The focus is delivery of value to the warfighter, if the program has not matured enough to be able to deliver small rapid releases or continual delivery, do not release just to meet arbitrary timelines. Waiting for a sprint to complete that delivers key mission needs that has been coordinated with the user and DA is more important than meeting arbitrary release dates. These should be exceptions since maintaining the development and release cadence to maintain a strong DevSecOps culture.

A: Programs using the software acquisition pathway will report a set of data to the Office of the USD(A&S) on a semi-annual basis. Data reported under this pathway will be used to monitor the effectiveness of the pathway, drive improvements to make the PM’s execution easier, and will not be used for program oversight.

Programs using the SWP will complete the Semi-Annual Reporting form (CAC required) and email to [email protected] in April and October. This will be an interim measure until formal reporting systems are updated to account for the Software Pathway.

A: As the Defense Innovation Board’s Software Acquisition Practices report is titled: Software Is Never Done, most DoD software programs will have continual development, even if at a low level. This may include addressing deficiencies, cyber vulnerabilities, upgrades to underlying platforms and services, integration, in addition to increased functionality. Programs will decide the optimal product support strategy leveraging organic and/or contracted developers managed by a traditional acquisition program office, a software depot, and/or operational command.

A: No, the planning phase is intended to be a short-term phase where programs compile their initial requirements, strategies, architecture and funding.  Once in the execution phase, issues may arise but they will be managed in the execution phase.

A: Commercial Solutions Opening and Other Transactions are the default solicitation and award approaches for acquring capabilities under the SWP.  Modular contracting is the preferred approach for acquiring major software IT systems in accordance with 41 U.S.C. §2308 and FAR Part 39.103.  See the SWP Contract Strategies page for more information.

A: The SWP Contracting Strategy page addresses contracting for two distinct areas applicable to software development as part of a modular contracting strategy: DevSecOps environment and Agile software development. Language for Agile software development will be driven by program specific needs, requirements, selected Agile development methodology, government hosted, or contractor hosted development environment, etc. Examples of work statement language are offered but should be tailored and customized for each individual program.

A: No, in most cases the Program Executive Officer (PEO) is the Decision Authority (DA) for SWP programs. Most Services and Agencies proactively delegated DA to the PEOs for programs below the MDAP thresholds. Service Acquisition Executives will typically serve as MDA for SWP programs that exceed MDAP dollar thresholds (note: SWP is exempt from MDAP, but DoD still uses the dollar thresholds to identify for “large” programs). Per DODI 5000.87, Section 2.1.a., “USD(A&S) serves as the decision authority (DA) for special interest programs in the software acquisition pathway on a by-exception basis when the size, cost, complexity, performance, joint, or congressional interest warrants additional oversight.” This is envisioned to be a rare case.

In SWP programs, the Sponsor is a senior official from the operational community who has the gravitas, knowledge, skills, and abilities to:

• Champion both the program goals and the program’s agility.
• Develop and approve the Capability Need Statement (CNS) or Software ICD.
• Progress the CNS or SW-ICD through the Service requirement boards per the established approval process.
• Work with the Decision Authority, Program Manager, and Product Manager to develop the User Agreement (UA) to support engagement with customers/end-users.
• Ensure there are sufficient end users to engage the development teams to provide insights and feedback.
• Oversee a product owner who would be responsible for day-to-day management of requirements and user-engagements.
• Address organization-level bottlenecks and impediments that the team is unable to resolve on their own.

The product owner actively engages the user community, development team, and key stakeholders to understand the needs, priorities, and mission objectives. They actively groom the requirements in product backlogs by clarifying details and adjusting priorities. The product owner works closely with the program manager on shaping the product roadmap. The product owner is typically a government employee from the operational community. Ideally they are a peer to the program manager who has an understanding of the operational environment, envisioned program, can effectively engage a wide group of stakeholders, and manage competing priorities.