Defense Acquisition Program Models
DoDI 5000.02 describes four basic models that serve as examples of defense program structures tailored to the type of product being acquired or to the need for accelerated acquisition. Two additional hybrid models combine the features of multiple basic models. Each basic model is tailored to the dominant characteristics of the product being acquired (e.g., hardware intensive products such as most weapons systems). The hybrids are described because many products will require combining models, such as a weapons systems development that includes significant software development. The models provide baseline approaches. Acquisition programs should use these models as a starting point in tailoring a program to the unique character of the specific product being acquired.
All of the models contain requirements and product definition analysis, risk reduction, development, testing, production, deployment, and sustainment phases punctuated by major investment decisions at logical programmatic and contractual decision points. Progress through the defense acquisition system depends on obtaining sufficient knowledge about the capability to be provided and risks and costs remaining in the program to support a sound business decision to proceed to the next phase.
Model 1: Hardware Intensive Program. Figure 3 is a model of a hardware intensive development program such as a major weapons platform. This is the classic model that has existed in some form in all previous editions of this instruction. It is the starting point for most military weapon systems; however, these products almost always contain software development resulting in some form of Hybrid Model A (paragraph 5c(3)(f)1 describes Hybrid Model A). Model 2: Defense Unique Software Intensive Program A system in which software represents the largest segment in one or more of the following criteria: system development cost, system development risk, system functionality, or development time. . Figure 4 is a model of a program that is dominated by the need to develop a complex, usually defense unique, software program that will not be fully deployed Fielding a weapon system by placing it into operational use with units in the field/fleet. until several software builds have been completed. The central feature of this model is the planned software builds – a series of testable, integrated subsets of the overall capability – which together with clearly defined decision criteria, ensure adequate progress is being made before fully committing to subsequent builds.
1. Examples of this type of product include military unique command and control systems and significant upgrades to the combat systems found on major weapons systems such as surface combatants and tactical aircraft.
2. Several software builds are typically necessary to achieve a deployable capability. Each build has allocated requirements, resources, and scheduled testing to align dependencies with subsequent builds and to produce testable functionality to ensure that progress is being achieved. The build sequencing should be logically structured to flow the workforce from effort to effort smoothly and efficiently, while reducing overall cost and schedule risk for the program. Model 3: Incrementally Deployed Software Intensive Program A system in which software represents the largest segment in one or more of the following criteria: system development cost, system development risk, system functionality, or development time. . Figure 5 is a model that has been adopted for many Defense Business Systems An information system, other than a national security system, operated by, for, or on behalf of DoD, including financial systems, management information systems, financial data feeder systems, and the information technology and cybersecurity infrastructure used to support business activities, such as contracting, pay and personnel management systems, some logistics systems, financial planning and budgeting, installations management, and human resource management. . It also applies to upgrades to some command and control systems or weapons systems software where deployment Fielding a weapon system by placing it into operational use with units in the field/fleet. of the full capability will occur in multiple increments In the context of Joint Capabilities Integration and Development System, a militarily useful and supportable operational capability that can be effectively developed, produced, acquired, deployed and sustained. Each increment of capability will have its own set of threshold and objective values set by the user. as new capability is developed and delivered, nominally in 1- to 2-year cycles. The period of each increment should not be arbitrarily constrained. The length of each increment and the number of deployable increments should be tailored and based on the logical progression of development and deployment for use in the field for the specific product being acquired. 1. This model is distinguished from the previous model by the rapid delivery of capability through multiple acquisition increments, each of which provides part of the overall required program capability. Each increment may have several limited deployments; each deployment will result from a specific build and provide the user with a mature and tested sub-element of the overall incremental capability. Several builds and deployments will typically be necessary to satisfy approved requirements for an increment of capability. The identification and development of technical solutions necessary for follow-on capability increments have some degree of concurrency, allowing subsequent increments to be initiated and executed more rapidly.
2. This model will apply in cases where commercial off-the-shelf software, such as commercial business systems with multiple modular capabilities, are acquired and adapted for DoD applications. An important caution in using this model is that it can be structured so that the program is overwhelmed with frequent milestone The point at which a recommendation is made and approval sought regarding starting or continuing an acquisition program, i.e., proceeding to the next phase. Milestones established by DoDI 5000.02 are: Milestone A that approves entry into the Technology Maturation and Risk Reduction phase; Milestone B that approves entry into the Engineering and Manufacturing Development phase; and Milestone C that approves entry into the Production and Deployment phase. or deployment decision points and associated approval reviews. To avoid this, multiple activities or build phases may be approved at any given milestone or decision point, subject to adequate planning, well-defined exit criteria Program-specific accomplishments that must be satisfactorily demonstrated before a program can progress further in the current acquisition phase or transition to the next acquisition phase. Exit criteria normally are selected to track progress in important technical, schedule, or management risk areas. They serve as gates that, when successfully passed or exited, demonstrate that the program is on track to achieve its final program goals and should be allowed to continue additional activities within an acquisition phase or be considered for continuation into the next acquisition phase. Exit criteria are some level of demonstrated performance outcome, the accomplishment of some process at some level of efficiency, or successful accomplishment of some event, or some other criterion that indicates that aspect of the program is progressing satisfactorily. Exit criteria are documented in the ADM. , and demonstrated progress. An early decision to select the content for each follow-on increment (2 through N) will permit initiation of activity associated with those increments. Several increments will typically be necessary to achieve the required capability.
Model 4: Accelerated Acquisition Program. Figure 6 is a model that applies when schedule 1. Series of things to be done in a specific sequence within a given period of time. 2. A timetable. 3. A listing of activities and events organized by time. considerations dominate over cost and technical risk considerations. This model compresses or eliminates phases of the process and accepts the potential for inefficiencies in order to achieve a deployed capability on a compressed schedule. The model shows one example of tailoring The manner in which certain core issues (program definition, program structure, program design, program assessments, and periodic reporting) are addressed in a particular program. The Milestone Decision Authority seeks to minimize the time it takes to satisfy an identified need consistent with common sense, sound business management practice, applicable laws and regulations, and the time-sensitive nature of the requirement itself. Tailoring may be applied to various aspects of the acquisition process, including program documentation, acquisition phases, the time and scope of decision reviews, supportability analysis, and decision levels consistent with all applicable statutory requirements. for accelerated acquisition and many others are possible. This type of structure is used when technological surprise by a potential adversary necessitates a higher-risk acquisition program. Procedures applicable to urgent needs that can be fulfilled in less than 2 years are a subset of this model and are discussed in Enclosure 13. Hybrid Acquisition Programs
1. Figure 7 is a model depicting how a major weapon system Items that can be used directly by the Armed Forces to carry out combat missions. combines hardware development as the basic structure with a software intensive A system in which software represents the largest segment in one or more of the following criteria: system development cost, system development risk, system functionality, or development time. development that is occurring simultaneously with the hardware development program. In a hardware intensive development, the design, fabrication, and testing of physical prototypes may determine overall schedule, decision points, and milestones The point at which a recommendation is made and approval sought regarding starting or continuing an acquisition program, i.e., proceeding to the next phase. Milestones established by DoDI 5000.02 are: Milestone A that approves entry into the Technology Maturation and Risk Reduction phase; Milestone B that approves entry into the Engineering and Manufacturing Development phase; and Milestone C that approves entry into the Production and Deployment phase., but software development will often dictate the pace of program execution and must be tightly integrated and coordinated with hardware development decision points. 2. In the hybrid “A” model, software development should be organized into a series of testable software builds, as depicted in Figure 7. These builds should lead up to the full capability needed to satisfy program requirements and Initial Operational Capability (IOC) In general, attained when selected units and/or organizations in the force structure scheduled to receive a new system have received it and have the ability to employ and maintain it. The specifics for any particular system IOC are defined in that system’s Capability Development Document and Capability Production Document. . Software builds should be structured so that the timing of content delivery is synchronized with the need for integration, developmental and operational testing in hardware prototypes. The Milestone B decision to enter EMD The third phase of the Defense Acquisition System, usually beginning after MS B, as defined and established by DoDI 5000.02. The purpose of the EMD Phase is to develop, build, and test a product to verify that all operational and derived requirements have been met and to support production or deployment decisions. EMD completes all needed hardware and software detailed design; systemically retires any open risks; builds and tests prototypes or first articles to verify compliance with capability requirements; and prepares for production or deployment. It includes the establishment of the initial product baseline for all configuration items. and the Milestone C decision to enter Production and Deployment (P&D) should include software functional capability development maturity criteria as well as demonstrated technical performance exit criteria.
Model 6: Hybrid Model B (Software Dominant), depicts how a software intensive product development can include a mix of incrementally deployed software products or releases that include intermediate software builds. All of the comments about incremental software fielding associated with Model 3 in paragraph 5c(3)(d) apply to this model as well. This is a complex model to plan and execute successfully, but depending on the product it may be the most logical way to structure the acquisition program.
Source: DODI 5000.02