Using military standards in acquisition programs.

If one were to ask members of the Department of Defense acquisition workforce whether or not military standards may be used in their programs, the responses might be surprising. Rather than receiving a consistent, unambiguous statement, one commonly hears: "We can't use military standards in contracts"; or "We can use standards only if we obtain a waiver"; or "Sometimes we can use them"; or "I didn't think military standards even existed anymore." There are many more variations, but when one regularly asks the question, it is apparent that there is no consistent working level understanding of DoD policy regarding the application of military standards. Thus the basic issue is what exact policy is to be followed.

How We Got Here

Rather than launching into current policy, it may be useful to discuss exactly how we arrived at the current situation. Starting with the one-page requirement issued to Orville and Wilbur Wright for the first military heavier-than-air flying machine, the acquisition system arrived at a point in the 1980s when military contracts were no longer measured by the page but by the linear foot, maybe even by the pound as some skeptics suggested.

One of the major contributors to the increased bulk was identified as the overuse of military standards and specifications, and the solution was to "tailor" requirements to eliminate unneeded requirements and thereby decrease procurement costs. While that approach did diminish the mass of requirements, the final steps occurred in June 1994 and then March 1996 with directives from then Secretary of Defense Dr. William Perry emphasizing commercial practices and products while simultaneously departing from the traditional military specification system. Apparently in the intervening years, some of that initial clarity was lost, leaving us with many current views of the milspec system.

As with any good research, the only acceptable data should be collected from primary sources, not word-of-mouth, your buddy, or somebody's opinion. In the case of military standards, the primary source is found in DoD 4120.24-M, the Defense Standardization Program (DSP) Policies and Procedures. And despite the varied usage views presented in the introduction, there are only two classes of standards and specifications to be considered: those that may be used with no restrictions and those documents requiring waiver. The remainder of this article will discuss the two classes, giving examples of their application.

[ILLUSTRATION OMITTED]

Defense Standardization Program Policies and Procedures Paragraph C3.8.2. of DoD 4120.24-M lists nine types of documents that may be used in development contracts. Of particular interest are three military document types: standard practices, interface standards, and defense standards.

In the first category, standard practices, one finds: MIL-STD-961E, Defense and Program-Unique Specifications Format and Content; and MIL-STD-882D, System Safety. Each title sheet clearly includes the term "standard practice," and that identifier is consistent on all military standards that may be used without restriction.

In the second category, are: MIL-STD-1553B, Digital Time Division Command/Response Multiplex Data Bus; and MIL-STD-1760D, Aircraft/Store Electrical Interconnection System. Both are titled as "interface standards" and are approved for use without restrictions.

Finally, DOD-STD-1399, Shipboard Systems, offers an example of a DoD standard--in this case an interface standard as well.

Getting ASSISTance

Each of these three categories requires use of documents listed in the ASSIST database at <http://assist.daps.dla.mil/online/start/>. The ASSIST database is the official source of all documents listed in the DoD Index of Specifications and Standards and all Data Item Descriptions, and it contains both current and outdated document versions. Establishing an ASSIST account is quite simple, provides significant capability, and controls the approved DoD standards and interfaces.

C3.8.2 also defines several types of nonmilitary standards that may be used in development contracts. These include nongovernmental standards, commercial item descriptions, and international standardization agreements. As can be imagined, these three categories are both expansive and comprehensive, but the field user has easy access to them in separately listed areas in the ASSIST database. In fact, in the nongovernmental standards area alone, the listing currently contains 9,122 standards from numerous organizations such as the American National Standards Institute, American Society for Testing and Materials, Society of Automotive Engineers, Underwriters Laboratory among other well-known entities.

Handbooks listed in the ASSIST database may be used but may not be cited as contractual requirements. This inclusion is especially important when one considers such powerful tools as MIL-HDBK-881, Work Breakdown Structure; and MIL-HDBK-245D, Handbook for Preparation of Statement of Work, both of which are critical to the proper preparation of any solicitation. Acquisition professionals will note that MIL-HDBK-245D also contains an excellent discussion of and requirements for use of the statements of objectives solicitation method as well.

As can be seen from the preceding discussion, DoD professionals have several different types of standards and specifications that may appropriately be used in development contracts, and among these types are often-forgotten military standards and handbooks. Many of these documents are essential to well-developed technical programs and their associated procurements.

When is a Waiver is Required?

One final commonly heard comment remains: "I thought I had to get a waiver to use a military standard." Having established within published DoD policy the approved use of identified standards and documents, it is clear that other standards and specifications will require a waiver before use in development contracts. DoD 4120.24-M lists the circumstances under which a waiver would be required, and many of those circumstances are quite well-known: detail defense specifications or standards; program-unique detail specification and standards defining an exact design solution; or any specifications or standards that describe management or manufacturing processes in a major defense acquisition program, as are defense test method standards, design criteria standards, and manufacturing process standards.

In most of these waiver circumstances, the issue is clearly one of detail specification rather than the DoD preference for performance-based specifications. And while the sometimes subtle differences between detail and performance specifications can be a subject of lively discussion, the prime source and approved definitions can be found in MIL-STD-961E, Defense and Program-Unique Specifications Format and Content. In general, by the MIL-STD-961E definition, a detail specification states such requirements as type of material, how the requirement is to be achieved, or how an item is to be fabricated or constructed. When required, the waiver is processed in accordance with each Service's implementing instructions.

Waiver Exemption Process

The waiver process also has a companion exemption process. It is presented in paragraph C3.8.4, which defines situations that are not at all uncommon: reprocurements not requiring major modifications or upgrade; specifications or standards proposed by an offeror in a proposal; non-DoD customer requirements; and situations where another agency or country is leading the program. More uncommon--and quite understandable--the requirements for nuclear components are also exempt.

While many people have differing understandings of the policy basis of acquisition decisions, the DoD policy is actually quite clear and understandable, and it provides unambiguous guidance to the concerned professional in the field.

Eiband is professor of systems engineering with DAU. He earned his bachelor's degree at the United States Air Force Academy and his master's at the University of Texas at Austin.

The author welcomes comments and questions and can be contacted at [e-mail].