FAQs
AAF > Software Acquisition > FAQs
Phases
Planning Phase
Execution Phase
Activities
Define Capability Needs
Develop Strategies
Cost Estimation
Engage Users, Assess Value
MVP, MVCR, Deployment
Architecture, Interoperability
Cybersecurity
Ent Services, DevSecOps
Metrics and Reporting
DBS in SWP
Additional Resources
*AAF Pathway Resources*
SWP Quick Start Primer
SWP Artifact Templates
SWP Programs
SW In NDAAs
Glossary
FAQs
FAQs
How To Use This Site
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.
Using the SWP
Q: What is required for new programs to use the SWP?
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.
Q: What is required for an existing program to transition to the SWP?
A: A signed Acquisition Decision Memorandum (ADM) signed by their Decision Authority authorizing use of the SWP. Per DODI 5000.87 Section 3.1.d: “Existing acquisition programs may elect to update their acquisition strategy to transition to the software acquisition pathway or use it in addition to their current acquisition pathway. The PM and applicable stakeholders will identify, and the DA will approve, a transition approach to tailor processes, reviews, and documentation to effectively deliver software capabilities.”
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. However, a transition period is a good point to reflect on the program’s strategies and processes and pivot to enable modern software practices of Agile, DevSecOps, and Lean. Program Managers, in partnership with their decision authority and key stakeholders, should layout a transition plan which may include developing and/or updating key documents within a set timeframe.
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.”
Q: Can an MDAP or ACAT II weapon system use the SWP for its software development?
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).
Q: Is there a dollar threshold for using the Software Acquisition Pathway?
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.
Q: What are the enterprise challenges and barriers to Agile and DevSecOps adoption in DoD?
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.
Q: When can I use the Acquisition of Services Pathway for SW Development?
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.
Q: What is the proper acronym for the Software Acquisition Pathway?
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?
Applicability of Statutes and Laws to SWP
Q: Are SWP programs exempt from JCIDS?
A: FY20 NDAA Section 800 includes: “Programs executing the software acquisition pathway are not subject to the Joint Capabilities Integration and Development System (JCIDS), and will be handled as specifically provided for by the Vice Chairman of the Joint Chiefs of Staff, in consultation with Under Secretary of Defense for Acquisition and Sustainment (USD(A&S)) and each service acquisition executive.”
In 2021, USD(A&S), VCJCS, and the Services collaborated on a new approach to software requirements and captured a streamlined, tailored approach in the JCIDS Manual. It includes a hybrid overarching document merging the SWP CNS and JCIDS IS-ICD into a new SW-ICD with streamlined validation processes if there are Joint equities. The details of this update will be captured on the Define Capability Needs page and in a future update to DODI 5000.87.
Q: Are SWP programs exempt from MDAP laws?
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.
Q: Do ACAT Levels apply to the SWP?
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.
Q: Are Acquisition Program Baselines (APBs) Required for the SWP?
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.
Q: Is EVMS required for a SWP Program?
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.
Q: Does the Clinger Cohen Act apply to SWP Programs?
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.
Q: Where can I find the statutes/laws related to the SWP and DoD software?
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.
SWP Requirements
Q: If my program has an approved JCIDS document (IS-ICD, IS-CDD), do I need a new CNS?
A: Current acquisition programs with approved JCIDS 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 on JCIDS vs CNS decisions.
Q: Does the Net-Ready KPP apply to SWP programs?
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.
Q: How does a SWP program manage “requirements” after the initial document is approved?
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.
SWP Artifacts
Q: Where can I find a list of all the required documents for the SWP?
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.
Q: How is a Value Assessment different from traditional Cost, Schedule, and Performance baseline?
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.
SWP Execution
Q: What delivery timelines are required within the SWP?
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.
Q: What if a SWP program is unable to meet the one-year MVCR requirement?
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.
Q: What metrics are required to report to USD(A&S) staff?
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.
Q: When does a SWP transition to Sustainment?
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.
Q: Would a program be sent back to the Planning Phase for any reason?
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.
Contracting
Q: Are SWP programs required to use a certain contract strategy/type?
A: No. 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. SWP may leverage the full range of FAR and Non-FAR contract strategies to acquire and deliver the software capabilities. See the SWP Contract Strategies page for more information.
Q: What Agile language should I put in my SOO/SOW/Contract?
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.
Roles and Responsibilities
Q: Is USD(A&S) the Decision Authority for SWP Programs?
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.
Q: Who is envisioned to be a Sponsor for a SWP program?
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.
Q: What is the Product Owner role in the SWP and who should be assigned this role?
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.
Defense Business Systems (DBS) and SWP
Q: Can a Defense Business System use the SWP?
A: Yes. Understanding that defense business systems are software intensive with or without the use of commercial off the shelf (COTS) software, the Software Acquisition Pathway (SWP) can be incredibly beneficial. Similar to other acquisition programs, DBS programs may elect to update their acquisition strategy to transition to the SWP or tailor their current pathway to fully embrace modern software development approaches supported in the SWP.
Q: What are the risks to a defense business system using the SWP?
The only major constraint is if the program cannot realistically deliver a release annually due to external constraints that challenge a high deployment frequency. A DBS program should also recognize that tailoring the SWP and associated BCAC processes is not an excuse to take Business Process Reengineering (BPR) shortcuts. The SWP provides all the flexibility a program needs to properly address complexity, interdependencies and acceleration of capability.
Q: What can defense business system do without transitioning to the SWP?
Defense business systems can take adopt modern software development practices, incorporate SWP acquisition approaches and use the different SWP artifacts without entering the Software Pathway.
Q: What can defense business system NOT do without transitioning to the SWP?
Defense business systems will not be able to eliminate the burden of formal ATPs and gain a high level of requirements flexibility without transitioning to the SWP.