Techniques of Systems Analysis revisits some important topics in its concluding chapter:
Research? Development? Procurement? Operation?
The first question to ask is: what kind of recommendation is one trying to make; why are we doing the study? Occasionally a study is done solely for self-education. One simply wanted to know more about the subject. It is probably not right to think of such studies as Systems Analysis, though they can be very valuable. (In our lexicon Systems Analysis means System Design. People who are interested only in analysis will have to find their own word.) Usually though, a study should be sharply affected by whether the question being treated is associated with Research, Development, Procurement or Operation.
Popular and semi-popular opinions to the contrary, the ability to do basic or semi-basic research in this country is not (in an absolute sense) in short supply. In addition, if we compare the cost of most kinds of basic or semi-basic research to other costs of the total defense system, we see that on the whole it is extraordinarily cheap. Ordinarily one can legitimately recommend doing it on very flimsy evidence. That is, one shouldn’t have to show that the research being recommended is likely to be useful, but only that there is a chance that it may be useful. Generally this kind of research should have only the loosest sort of guidance, except for monitoring to see that the people involved are professionally competent and that there are no glaring holes in the overall program.
Development is somewhat more expensive. But once again, one should not have to justify a development program by proving that the item being developed should be procured. One simply tries to carry through, but in more detail, the kind of study that is done before recommending a basic research program. Here one might justify the program on the grounds that there are reasonable (in the case of expensive programs — not improbable) conditions under which this development could be useful. When the issue is crucial, we should only have to indicate that the nature of the problem is such that it is hard to show that the development won’t be useful. In particular, we should do a great deal of development simply to cut down lead time and provide insurance against uncertainty. One wants to be in a position so that if certain events (technical, political, or military) occur, we will be able either to guard against or exploit them. We should be willing to do this, even if the events are rather improbably, if they are important or if the cost of hedging is, relatively speaking, small. Much of the cost of development programs should be put down to giving this kind of flexibility.
To quote a remark made earlier, “It may or may not be a mistake to develop something which is not procured, but it is always a mistake to procure something which is not developed.”
Or referring again to the Time magazine article, it was only because the Navaho cruise missile was being pushed that we had the rocket engines for the ICBM. Actually, many people would have been willing to have a development program for big rocket engines which was not necessarily tied to any system at all. It just seemed very clear that large rocket engines are one of the commodities in which military systems of the future are likely to be interested.
In general, “state-of-the-art” development programs are good things. It turns out to be amazingly easy, ordinarily, to modify and we already developed components. A naive individual might think that if there were two independent programs which had not heard of each other and if at a later date one wanted to combine them into a single overall program, it might be impossible to do this. Sometimes it is, but more often it is not. The important thing is that if one insists on doing only complete system development programs, he will find himself having a much smaller number of marriages of convenience to arrange. Historically, exactly this type of amalgamation oftens turns out to be important. Even if on knows that he wants a complete system he should be cautious in freezing the component design too early. There are a lot of errors made in predicting performance of components and one often achieves his goal faster by first doing bread-board work to answer state-of-the-art questions than by trying to do final design immediately.
The procurement problem is, of course, quite different. Procurement is expensive but has the virtue of involving much shorter time scales. When on has come to the step of being ready to procure something, the environment and context are relatively firm. There may be a lot of uncertainty left, but hopefully both the alternatives and the contingencies are reasonably limited. One should then be able to make just about the kind of study we have indicated in the example. Presumably the analysis should probably be pretty numerical all the way through, i.e., contain practically no qualitative arguments and conjectures except those that involve the kinds of fundamental questions that we necessarily relegate to the sphere of policy and intuitive judgment.
An operational study, of course, is almost completely concerned with detail, but there one has the saving grace of being restricted to current or immediately procurable hardware. For this reason, even though the amount of detail has gone up enormously, the number of alternatives has been correspondingly decreased. However, it is a typical weakness of current operational studies that they do not consider enough alternatives.