Downloaded from https://www.everyspec.com MIL-HDBK-502: A MIL-HDBK-502: A CQUISITION CQUISITION L OGISTICS OGISTICS 4.2.1 Type of Acquisition “Type of acquisition” generally relates to the amount of design activity required to complete a total system. There are four basic types of acquisitions. The types of acquisition are, in order of preference: (1) modification of an existing system; (2) commercial item, (3) nondevelopmental item (NDI), and; (4) development. There are sub- categories within each type; for example, a product improvement program may be for upgrade of an existing DoD item or for an item developed by a foreign military organization.
Figure 4-2 shows the steps in making a type of acquisition decision. The acquisition type names generally relate to the state of design of the primary mission element of the system being acquired, be it hardware or software. Thus a modification program to an existing combat system may include a full development effort for new operational software and only minor change in hardware and support. Conversely, a full development effort for a training system’s hardware may require little or no software or support development if commercial software and support designs are used. It is DoD policy to acquire total systems which meet operational needs at the most affordable life cycle cost.
The options are many. But the goal is always to get the best balance between total system design opportunities, operational needs, and program constraints. To achieve this goal, each aspect of a total system must be considered, the alternatives identified and evaluated, and the tradeoff decisions made and implemented. Deciding the type of acquisition program to be implemented is the first major step in determining what systems engineering activities to include in a program’s acquisition strategy. The supportability analysis portion of the systems engineering process begins with the identification of an operational need.
The initial operational requirements and concepts are evaluated to identify support implications and alternatives. Here are two examples: 1) A requirement for a small quantity of a new highly reliable system suggests greater affordability under a commercial repair support concept than under an organic concept. This opportunity should be investigated further. 2) An interoperability requirement suggests a standardization opportunity that might reduce the support burden of the system. The standardization candidate should be evaluated for its performance and design suitability, and the support risks and benefits of the candidate should be explored.
Modification programs are most often conceived of as such from the outset, perhaps because of the significant investment represented by materiel assets to be modified or the limited scope of the modification. In these instances the support evaluations are usually bounded by the scope of the needed change and are conducted in the context of the existing support 4-4