Air University Review, January-February 1968

What is an Operational Requirement?

Colonel Geoffrey Cheadle

It has been almost seven years since Secretary of Defense Robert S. McNamara first introduced his "economic" approach to force structure and weapon system planning. This way of doing Defense business no longer inspires the agonized, last-ditch resistance from the military leaders that it used to. The expressions "cost effectiveness," "marginal utility," and "systems analysis" are less often used with disdain or contempt by service staff officers. Some guerrilla warfare still continues, but the more recent confrontations have been concerned with how to implement the McNamara-Hitch-Enthoven-Anthony management concepts rather than with questioning their inherent applicability. Thus, the military services tend now to incorporate, almost automatically, cost-effectiveness studies and systems analyses as backup documents in all new weapon system proposals. Current arguments concern inputs and assumptions. The accommodation that the services have made to the new management doctrine, however, has in one respect been superficial rather than fundamental: "So they want a cost-effectiveness analysis. So give them a cost-effectiveness analysis!" That this is the case can be seen in the attitude of the services toward what are called "operational requirements."

To a military service staff officer, an "operational requirement" represents a new kind of weapon system or equipment needed by ah "operator" (that is, the commander of an operating unit in the field) to do his job adequately. Often with little or no consideration of economic, political, and technical factors, it is alleged that there is an indisputable military "requirement" for the new gear. The claim is usually established as a service "position" and in some military services is still formally documented as a Specific Operational Requirement (SOR).^l There is an implication that upon publication of the Requirement (now spelled with a capital "R") the burden shifts from the operator (and his service headquarters staff advocates) to the program, budget, and technology agencies, whose function is to finance, develop if necessary, and procure the desired end item.

In the early McNamara days, the staff of the Office of the Secretary of Defense (OSD) reacted to the expression "operational requirements" with great annoyance. After all, they reasoned, an operational requirement was clearly nothing more than the responsibility devolving upon a military leader in the field to accomplish a certain task in order to fulfill his mission-an operator might have an operational requirement, for example, to blow up a certain bridge, take a certain hill, or move some cargo from A to B. The decision as to what new weapon system or equipment the operator might profitably be given to fulfill this operational requirement would naturally be subject to scrutiny at all staff levels for such factors as cost effectiveness, alternative approaches, and so forth.

By now, of course, the OSD staff members generally understand what the military person means by his "operational requirement," and the expression is just filtered out of their conversation.

Obviously, communication between OSD and the services which depended in any way on this key expression was sure to break down. And break down it did, particularly on the many occasions when the beleaguered service staff man answered a penetrating question as to the why of a certain system approach by saying, "But this is an operational requirement" or, even more often, "This is what's called for in SOR 123."

The smarter staff officers in the services early came to understand that to have an "operational requirement" is no argument with the civilians in either OSD or the secretarial offices of the departments themselves. There has persisted, nevertheless, a feeling that "operational requirements" are good things to establish and use internally in the services themselves. This explains the fact that organizational entities still exist in each of the services for handling "operational requirements," and the business goes on apace.

In one sense the Air Force is an exception to this statement. Beginning in June 1966, the Air Force adopted a new and radically different approach toward "operational requirements." The rather straightforward instrument of this change is Air Force Regulation 57-1, "Operational Requirements: Policies, Responsibilities, and Procedures for Obtaining New and Improved Operational Capabilities," 17 June 1966. This regulation came about through a working group set up by Major General Jack J. Catton, then Director of Operational Requirements and Development Plans under the Deputy Chief of Staff for Research and Development. General Catton directed his workiI1g group to examine the handling of operational requirements in depth, to work out improved policies and procedures, and to initiate staff actions to implement the new procedures (upon their approval) Air Staff-wide and Air Force-wide. By late 1965 the Air Force had obtained a few years’ experience in doing "requirements" business in the new civilian management environment. The working group was able to draw on considerable expertise in its deliberations, notably on that of Major General Gleen A. Kent, then Deputy Director for R&D Analysis, DSC/R&D, Hq USAF. Almost all consultants confirmed the group’s analysis that a bold departure was essential. The end product was a regulation which tool the bull by the horns—it abolished the venerable SOR as a way of doing business and implemented a management philosophy which is both conceptually sound and eminently pragmatic.

As I have stated, the operational requirements process in the military services has to do with selecting and successfully proposing new weapon systems and equipment for development and/or procurement. Even a superficial glance reveals that many commands, agencies, and offices will be involved in this process. What are the specific responsibilities of each? What are their necessary inputs and desired outputs? Where does one agency’s responsibility end and the next one’s begin? To what extent must the process be formalized, or to what extent can it be left to judgment in individual cases? All these questions must be answered before one is assured that the right people are working the right problems with an acceptably high expectation of success.

For the military services the responsibility for something like an operational requirements process stems from public law. Under Title 10, U.S. Code, the services are required by law to "organize, train, and equip" forces—aerospace, naval, or land forces, depending on the service. Those forces are to be used by the unified and specified commands. The military service headquarters in the Pentagon are not in the chain of command; they do not operate the forces they are required to organize, train, and equip. The service headquarters must rely on their subordinate combat commands (which are the components of the unified and specified commands) for information and recommendations as to what force and equipment resources are needed, now and in the future. By smart management and effective staff action the service headquarters obtain approval from their departmental secretarial staffs and from OSD for the resources necessary. It is the obtaining of the necessary new kinds of systems and equipment for the "equip" function that gives rise to the operational requirements process. This process must be responsive to the real needs (not necessarily all the requests) of the operators on the one hand and effective in negotiations with the approval authorities for the new resources on the other. Let us see how this has been working in the past.

Until recently the three military services went about the operational requirements business in remarkably similar manners. If I may reduce the official procedures to their essentials and generalize quite a bit, the process was supposed to go like this: An operator would forward a formal requirements document, usually called a Qualitative Operational Requirement or QOR, to his higher headquarters. The QOR would describe a needed new system or item of equipment, going into considerable detail on its required or desired characteristics, intended use ("operational concept"), plus more or less of collateral justification in terms of the threat, relationships with other forces, time period of interest, etc. The service headquarters would be expected to evaluate the QOR and approve or disapprove (very few disapprovals!). The headquarters would then be expected to make the necessary consultation with its R&D support agencies, get the necessary funding, and direct the implementing action. Only first, before implementation could begin, the requirement received from the field had to be blessed as a true military service Requirement (capital "R") by the headquarters. This meant that the weapon system and the corresponding forces had to be factored into the appropriate long-range and mid-range plans (if they affected force structure), and a formal service position had to be taken and published, usually in the form of a Specific Operational Requirement or SOR. Then, by some completely undefined continuation of the process, the service headquarters was supposed to convert the SOR into reality.

It must be apparent to the perceptive reader that certain aspects of that official procedure were either at variance with the real Pentagon world or at best contributed only accidentally to the fulfillment of the services' legal responsibility to "equip" the forces. Any part-time student of management would predict that the individuals on the operational requirements staffs of the operating commands would tend to concern themselves excessively with the documents involved—both their creation and their proper routing and coordinating. That there was much such business occupying Pentagon staff officers is beyond dispute. As to whether it was excessive or not depends on the point of view.

The realities of the situation as perceived by General Catton and his working group were sad. Their conclusions: Not only did people spend much time creating and amending formal documents after the fact to conform with what is going on "where the action is," but—and this is worse—the documents, once created, fooled the writers into thinking they had achieved the goal. The staff officers most knowledgeable about a certain need in the field would sit back and rest on their SOR just when the really productive work of getting approval and funding of the implementing project should have begun. In the meanwhile a more enterprising and less inhibited group of staff officers was getting things done by "wiring around" the official process, using a great variety of nonstandard but effective procedures.

There were fundamental flaws in the whole traditional approach, flaws which even the most conscientious and energetic staff could not surmount. The traditional process failed because it was sequential, formal, and defensive.

A sequential approach is generally ineffective because of the nature of research and development and the way new programs are considered and approved in OSD and the departmental secretarial staffs. There are always "happenings" going on in R&D—the atmosphere is consistently one of quick change, often radical change. Getting good new systems and equipment from R&D calls for a willingness to change system specifications, even basic system approaches, right up to the time of proposal to OSD—and even after, if important enough. Also, as Secretary McNamara has made very explicit, the decision-making on high is not limited to a mere approval or disapproval of a single proposed approach. There must be a consideration of alternatives, even alternatives not envisioned by the original proposing agency in the field or in the service headquarters. The sequential approach, beginning with the QOR and proceeding in a step-by-step well-defined fashion, fails because the QOR pre-empts too many decisions on system characteristics, even overall system type, at too early a time and at too low an organizational level. The QOR becomes a command "position" by its very formality, resisting future change with a certain amount of bureaucratic inertia of its Own. All this is not to say that the operators should be excluded from the operational requirements process. In general they have an expertise and a firsthand knowledge of the needs of their CINC's which cannot be duplicated. They must be brought into the process at all stages, not just at the kickoff.

 The same should be said at this point concerning those agencies which do the R&D for the services. The sequential approach, if followed rigidly (and it is often followed rigidly), keeps the R&D experts in their laboratory cubbyholes during key periods, isolated from the operators, to the detriment of the final product. Strange as it must sound, the most effective operational requirement process is not sequential but can best be described as tentative, a guided sort of muddling through, involving much backing, filling, and evolving. The operational requirements business is a kind of problem-solving, working on detailed versions of the problem: What are the best new weapon systems and equipment items for the future? This point of view makes the following observation most appropriate: "In an important sense a rational problem solver wants what he can get and does not try to get what he wants except after identifying what he wants by examining what he can get."²

The military services have also hurt their operational requirements processes by formalizing them or at least by formalizing them in the wrong places. In a game where flexibility is essential the formality of the QOR and SOR restricts one's freedom of movement. A service "position" may not count for much with the decision-makers in OSD, but it certainly is a sacred cow in the service itself. It takes a very wise (and brave) junior staff officer to negotiate with OSD a piece of a program that is at variance with an existing "position." No anarchy is suggested here—it is well known that many "positions" existing on paper (particularly in documents such as SOR’s) are not the best interests of the service as time goes on and situations change. Further, nothing is to be gained by excessive formality. True, some directives for getting action accomplished must be issued in such format as to command the necessary respect and adherence, but traditionally SOR'S have not been directives in that sense. Since the services are probably the worst bureaucracies in the government for overformalizing activities, a certain deliberate restraint is always in order.

Many service staff officers see requirements documentation as necessary defensive hedges against an unfavorable future for the proposed system or equipment. If, they think, because of politics, niggardliness, or whatever other ignoble reason motivates the decision-maker he will decide against the requirement at least the service has publicly stated its needs, and therefore the blame is on the decision-maker for not following through. In this reasoning, SOR'S have been viewed as a sort of collective "Pearl Harbor File" which could be used to show the general public that it is not the service's fault that the country cannot be defended with adequate weapon systems and equipment. This defensive attitude would be bad enough in principle, but it would be indefensible in practice because it would divert so much staff energy and expertise from the real business to be done.

What is, then, the real business of operational requirements? How should it be approached? As I have suggested, the operational requirements process must serve to identify qualitative materiel needs (or operational deficiencies) of the operators and to achieve the approval and funding of the appropriate programs or projects to fulfill the need (or eliminate the deficiency). However or by whomever the needs are identified, the service responsibility to equip the forces calls for the approval and funding of programs or projects. As we shall see, some of the projects call for development, some for modification, some for procurement. Once approved and funded, the projects proceed in accordance with fairly well-defined directives and processes in the R&D, modification, or procurement area. It is the achievement of this crucial approval and funding of the right kind of program or project which should be the goal of the operational requirements process. Procedures, documents, and formalities are only useful, even tolerable, insofar as they contribute to achieving this goal. The way to the goal in any particular instance varies with the system, the status of R&D, the urgency of the need, the time of year, the availability of kinds of funding—with a whole host of factors. The effective staff officer keeps the goal in sight and pursues whatever intermediary activities appear to hold the most promise of contributing. The effective official requirements process is one which permits, even encourages, latitude of specific approach by the staffs at all levels, while making crystal clear what the staff responsibilities are in general.

The very organization of the service headquarters staffs tends to fragment or compartmentalize proceedings. If an operational requirements matter is given to an R&D man to handle, for example, one can expect an R&D answer, even though a modification or an off-the-shelf procurement might really be more appropriate. There is a fundamental problem here, which suggests that we look closely at the alternatives available to a man trying to satisfy an operational requirement. Basically, as stated often by General Catton, there are three avenues of effort for the elimination of an operational deficiency: tactics, modification, or new equipment.

The use of new tactics with existing equipment is an obvious first step available to the operational commander. Witness the air tactics used by our jet fighters in Southeast Asia to avoid the SAM's. Tactics can be changed quickly and locally, but ultimately tactics are constrained by the limiting characteristics of the weapon systems and equipment (or personnel) involved. Because of their local operational nature, tactics are not considered as solutions to operational requirements as we are discussing them here. 

The modification of existing (or already in-production) systems, on the other hand, is a valid and often very rewarding course of action to satisfy an operational need. This is the quickest, and usually the cheapest, way to achieve a truly new equipment capability. There is almost no kind of operational requirement for which some modification could not be reasonably proposed as a solution. Naturally, there are limitations; no one can make a silk purse out of a sow's ear, although what the Air Force has done with the stately old C-47 airplane comes close. One does not make a quantum jump with a mere modification, but the value of modifications in general can be seen by the very many different models of weapon systems now in use: F-4B, F-4C, F-4D, F-4E, just to give one example. The time comes, of course, when a completely new system is called for.

New technological advances are usually best exploited in new equipment rather than in modification of older gear. Sometimes such new equipment comes already developed (by a different service, by commercial in-house R&D, etc.), in which case the matching operational requirement can be validly satisfied by direct procurement (and usually testing and evaluation) of the equipment, repackaged as necessary. This often happens with small equipment items that have civilian counterparts (survival equipment, communication sets, etc.). For the big weapon systems and support systems, like aircraft, missiles, and ships, development programs are called for. Even in R&D there is much range of choice that must be considered. A study under exploratory development may be appropriate to produce design characteristics for the "next generation" system. An advanced development will serve to lessen the technical risk for a later engineering development by providing operationally sized and shaped equipment for test and evaluation. An engineering development or an operational system development (the latter if follow-on production for inventory has already been approved) serves to put the technological idea into final military configuration using the latest available technology, for possible quantity production and operational use. It is sometimes quite clear into which development category a project will suitably fall, but often considerable judgment and negotiation are necessary. In some fields, such as advanced aircraft, there are contributory activities going on in many development areas at once.

There is a need for the military service requirements staff officer to have full freedom and encouragement to consider all these approaches, in modifications and new equipment, to do his job properly. The situation is akin to the job of repairing a piece of furniture—it will get fixed the best if the repairman is permitted to use any tool available (to borrow a figure of speech from Major General Otto J. Glasser, Assistant DCS/R&D, Hq USAF).

The current Air Force approach, embodied in AFR 57-1, recognizes the limitations of previous Air Force procedures and encourages a change of modus operandi in Air Force headquarters and pertinent field agencies. The word "encourages" is used advisedly rather than "requires" or "directs" because of the nature of the problem. It is one thing to lift the burden of stultifying documentation off the staff officers' backs; it is another to change their old habits and rationalize an old mythology held dear by many. Some will never change, but those who would like to change will at least find the law on their side.

What, specifically, does the new Air Force Regulation 57-1 change? First, it abolishes all SOR's and similar types of document as a way of doing business. Second, it states philosophy concerning service responsibilities, objectives, alternative approaches, and flexibility in much the same terms as I have described. Third, it prescribes a new, very flexible document called a "Required Operational Capability" (ROC), to be used by service field commands as inputs. Fourth, it prescribes a new type of document to be issued as necessary by Headquarters USAF to direct action to be taken by the field on any operational requirement matter. Called a "Requirements Action Directive" (RAD), this document serves to emphasize certain important directives that would otherwise be issued in ordinary letter form. The RAD avoids the undesirable features of the SOR by being a temporary action item of purposely restricted scope; it does not therefore become an albatross of "position" around the staff's neck. Fifth, AFR 57-1 provides for a number of special cases calling for nonroutine procedures (operational requirements in support of Southeast Asia, for example). All in all, the Air Force has put into a single regulation its entire new framework for handling operational requirements.

Admittedly, one regulation, like one swallow, does not make a summer. The big question is, Does it work? It is really too early to tell. This is the sort of thing that people will never agree on, even after the smoke clears. It takes a year to two years for everyone around the circuit to get the new message. Nevertheless, it is possible to see some encouraging signs. At least the one swallow is there! A few straws in the wind:

· More bounce to the manpower ounce noted in the Air Staff Operational Requirements Directorate.

· A new wave of end-objective-mindedness sweeping over the Development Plans organization in Headquarters Air Force Systems Command, which is responsible for operational requirements business in that command. A recent document issued by General Kent as DCS/Development Plans, entitled "The AFSC Planning Process: policies, Procedures, and Terminology," bodes well to do for the Systems Command what AFR 57-1 does for the Air Force as a whole.

· Considerable evidence of increased mutual cooperation between the Air Force Systems Command and its "customers," the operating commands.

Only so much can be done by changing the official procedures. The smart manager transcends the regulations themselves. In my judgment, however, an official mechanism has been created which will remove all unnecessary obstacles to the smart manager and still give the most productive guidance possible to the less favorably endowed. If the twin benefits can be attained of more efficient use of staff energies on the one hand and more effective fulfillment of the "equip" responsibility on the other, then the change will not be in vain. The new Air Force approach appears to score well on both these counts. Let us hope that time serves to confirm this favorable estimate. 

Hq Air Force Systems Command

Notes

1. There are variations in nomenclature for some types of operational requirements in some services. Generally, however, they are all handled as described here.

2. Albert O. Kirschman and Charles E. Lindblom, "Economic Development, Research and Development, Policy Making: Some Convergent Views," RAND Paper P-1982 (Santa Monica: The RAND Corporation, 4 May 1960), p. 16.