Ed. Note: General Miley retired from the U.S. Army this past February. His last assignment was that of Commanding General of the Army Materiel Command, in which capacity he had served for more than four years. Given his recent position, General Miley is uniquely suited to comment on the weapons systems acquisition process.
The subject of this paper will be of obvious interest to those readers directly involved with military acquisitions, as well as government projects in general. Additionally, the article sheds an interesting perspective on project management as a whole, thus providing worthwhile reading for the remainder of the readers as well.
With materiel acquisition very much in the news these days, we find ourselves intensively and extensively challenged. Disillusionment following the Vietnam Conflict, a recessionary economy, competition for Federal funds (weapons systems are very costly) and a wholesome search for better ways combine to make all of us involved in this business more cautious, more contemplative, more introspective and even defensive.
On the whole this is good, for many of us have been hidebound, complacent, and not frugal enough. In order to adjust to the changed environment, over the past few years we have turned to new methods and techniques. My purpose here is to discuss several of the innovations which are assisting us in meeting the post-war challenges.
Cost/schedule control systems criteria (C/SCSC or CS squared), is an area that we have been working with in the Army Materiel Command (AMC) for some time. We have made significant advances. We now have nearly 60 acceptable applications, including 9 inhouse.
In the early days contractors resisted being validated under the provisions of C/SCSC. But the longer we work with this, the more the contractors themselves tell me that CS squared has turned out to be a wonderful management tool for corporations that do business with us.
During the quarterly reviews for project managers (RECAPS), I've dutifully watched to see if contractors have been validated, and if so, if project managers are utilizing the latest CS squared data. I've concentrated on the CS squared report that shows the cost and schedule variance trends and the utilization of contractor management reserves. I watch these areas very closely and get uncomfortable when either the cost/schedule variance trends or management reserve turn unfavorable. I am adamant with project managers with regard to taking quick and decisive action to reverse unfavorable trends as soon as they are detected.
Once, in a recap, a project manager said, “Sir, we're in financial trouble as opposed to cost trouble.” I asked him how this could be. As it turned out, the problem was that the contractor was ahead of schedule but using money faster than planned.
I hadn't been watching the chart that measures the consumption of dollars closely enough; in other words, the one that compares the contractor's commitments and expenditures versus the financial plan included in the contract. In the case cited, the contractor had come to the project manager and said, “Your plan doesn't follow the financial consumption plan that I'm following.” The contractor contended that his costs versus budget costs and his cost to complete were totally under control and reflected on the CS squared. So don't be smug just because the contractor's actual costs versus his budgeted costs seem to be in good relationship; he may be consuming money faster than he had planned or you are able to feed it to him.
I attribute this problem with CS squared to a lack of sophistication on the part of some of our project managers and their procurement support in AMC. As you know, in AMC, the project manager looks to the commodity command for his contracting and procurement support. However, in the case of the XM1 tank, we have, on a test basis, given him his own contracting officer and pricing support to see if that is a better solution.
In a couple of other cases where the cost of work performed has started to approach or exceed the budgeted cost of work performed, the PM's have reported this in their quarterly recaps. On such occasions I have asked: What are you going to do about this? What is the company going to do about this? The point is, “You've got to have get-well plans.”
It occurred to me, as an old contracting officer, that the thing which would concern me most is the breakdown of the delta of actual cost over planned costs. In many cases I've found it to be overhead. Often the increased overhead has developed because the contractor had forecasted a larger future Army or DOD business and it hadn't materialized. In other words, he missed a contract or two and now he's got to absorb his overhead on existing work.
In such cases, I've suggested that the project manager and I go to the contractor and say, “You and I have a problem and it's mostly yours. You have to find some way of doing your work at less cost. And we think your ‘less cost’ is to reduce your overhead.”
Design to unit cost. Everybody who is going to buy weapons systems that will be produced in the future will be required to meet or be below a design to unit cost in production. We have design to unit cost incorporated into our five big weapons systems and about fifty other systems and subsystems. In other cases we inserted it later in the development contract because the concept came along after award of the initial contract. I might say that inserting it after the fact is more painful. It's in about fifty other contracts. I am high in the design to unit cost concept. Even the late Chief of Staff, General Abrams. who was not a procurement expert, thought that design to unit cost would exert discipline on both contractor and the Army. He thought that the discipline would be useful even though we may be over-optimistic about actually meeting it several years from now, when we finally procure the median item and have come down the learning curve.
Experience shows that design to unit cost means many things to many people. When we were getting started we would arrive at the design to unit cost and furnish the specs to the contractor, expecting him to meet the ceiling at the sacrifice of only a modicum of capability. In other words, we expected to get the best vehicle or helicopter for the design to unit cost. The user wasn't too happy with design to unit cost; he suspected the developer would sacrifice capability, take it down below the minimum. We didn't mean that at all.
The ceiling on the UTTAS, for example, is $600,000. We don't want the two developers to work like hell to give us the best for $600,000. We would prefer something that costs less but which still meets a reasonable range of required capabilities and does a good job. Lest our contractors catch the earlier philosophy, we are trying to reeducate them. Our approach is to say that a prime selection factor — in the case of competitive prototype — will be the design to unit cost which we think they can achieve. If the performance of the less expensive helicopter appears to be reasonably effective at the end of our evaluation of competitive prototypes, waiving all other factors, it should be selected over the higher priced helicopter.
People outside AMC are concerned that we've applied design to unit cost like a catchword, that we're really doing the same old things. I've talked to contractors and I've talked to project managers who have design to unit cost ceilings in their programs, and I really think the philosophies of trade-off have been captured not only by the government people and VIP's in the contractor's chain but also by the design engineers. I've visited all of the Big Five contractors and talked to people at the drawing board level, and I think they know what we're talking about. It's a good discipline that we've instituted, so long as we and our contractors understand it thoroughly.
Improved Requests for Proposal (RFP): For a long time now I've been hearing from all directions that the Army's RFP's are big, unwieldy, hard to understand, ask for too much data, impose a great burden on the contractor, cost a lot of money to respond to, and are generally pretty lousy. I suppose maybe we're guilty of some of that, but we have instituted several things to correct this. We've done a lot of indoctrination, teaching, lecturing, and philosophizing across the board in the Army Materiel Command. We've had seminars to talk about the fact that we've had bad examples and good examples, and we've done all that kind of spade work. We have conducted a course at the Army Logistics Management Center at Ft. Lee, which trained 175 key procurement officials from the Commodity Commands. This course instructed them in the fine art of developing and producing RFPs. Subsequently, we have issued an RFP preparation guide. This guide features the idea that the purpose of the RFP is to translate faithfully to the contractor the contract that we have with OSD in the DCP (Development Concept Paper), and within the Approved ROC (Required Operational Capability) in language as simple as we can make it; and in as few pages as possible with the minimum essential boiler plate. This education has been followed by a quality assurance program which consists of a senior procurement review board reviewing all the principle RFPs at the Commodity Command level. Their work is sampled by the Commanding General and the Deputy for procurement of each Commodity Command. Then my senior procurement review board reviews a sample of their sample and, finally, General Vaughan and I will sample one or two a year to make sure it's all put together. The Pentagon will also provide some help by doing more sampling, too.
I can cite chapter and verse on the reduction in the size of RFP's that has actually taken place. A great stimulus to our effort is that the Air Force jumped out on the AX aircraft procurement two and a half years ago with a 25-page RFP.
The trouble with our RFP's to date is that we've never had one like the AX where we could solicit proposals on building a couple of airplanes. Perhaps its because we're oversophisticated, but we always solicit proposals for programs intended to keep competition alive. We say, “Give us a price on building five prototypes, on engineering development, and on competitive testing.” We write a single RFP to cover four or five years of development, with the idea that, at the end of that time, we'll select a production contractor. Obviously, if we write an RFP to cover four or five years of work in a variety of functions, it's going to be larger than one that says, only, “build me five airplanes that look something like this.”
Our RFP's will improve. I'm sure, though, that five years from now — when RFP's should be down to about ten pages — my successor will be reporting that some industrial tycoon tells him they're too big, too complicated, and not understandable.
Life Cycle Cost. This is a favorite subject of mine. Like design to unit cost, life cycle cost means many things to many people. For example, the Army, in developing new systems for its troops in the field, should concern itself with reduced life cycle cost. To do this we must invent, design, develop, and produce vehicles, guns, and tanks that have a longer time between failures, a reduced mean time to repair, and durability features that exceed those of the old systems. Then you combine these features in a single system and demonstrate through tests during development and early production that the new item does in fact have a longer mean time between failures and does have a reduced mean time to repair and does have better durability. By definition, improving the effects of inflation on the cost of repair parts and the cost of labor, you have in fact produced an item with a lower life cycle cost. Because, with the 10-year operating cost of the item in the field rising so fast, the initial end item cost is almost unimportant. If you read the contracts we have placed for new systems, you will see we have incorporated improved reliability and maintainability features in every case. We have also financed, through the contractor, plans to increase reliability and improve maintainability and we will test for this improvement not only at the end item level but also at the component level. These check-off points will determine whether or not the contractor is coming up the reliability growth curve.
Unfortunately, people often get carried away with a new concept. And the one that gives me heartburn is the idea that we are going to select competitively the contractor whose design promises a lower life cycle cost. This means that at the time that you sit down to write a contract which will call for some competitive prototypes followed by engineering development and then by low rate production, you're going to have the life cycle cost data in hand. But can you say that Brand A will have a lower life cycle cost than Brand B? Estimating errors or the cost of repair parts and cost of maintenance for a yet to be designed system makes this a hazardous venture. Just the data you have from the real world are so spotty and so inaccurate that you have to round off to the nearest ten percent. It would be most difficult to make a competitive selection between two contractors based on the Army's estimate of the life cycle cost of items that you haven't even cut the first piece of metal on.
I don't know what we can do about this, but I have the feeling the American public and the Congress are beginning to believe that we have this clairvoyance.
Doing business with the Army. Another thing I hear from various reports is that the US Army (at least in its weapon system acquisition) is hard to do business with. We ran a small opinion survey a couple of years ago. We had a major weapon systems competitive procurement; we had five offers, and we selected two. We made it a point within one week after the award of the contracts to visit with the presidents of all five companies and I asked, “How did the procurement go? Was the RFP well structured? Were the negotiations conducted in an orderly and reasonable fashion? Were you satisfied with your treatment by the Army? Were you able to raise questions about the RFP and get some satisfactory answers?” I realize that five is a small sample, but the results were that three of them were horrified. The RFP was long, wordy, complicated, and over-specified. Negotiations were abbreviated. It was hard to get answers to questions. The other two said, “I've never seen a more professional job.”
Now, the principal interface with the contractors that make noises (because they're the big ones) are the project managers. And so in the course of seeing my project managers every quarter (some of them I see more often than that), I ask if they feel that the contractor believes that they're hard to deal with. Of course, the answer is no. Occasionally, I get one who's having a cost overrun. His answer is more guarded.
I'm very serious about getting to the bottom of this. I don't think I'm hard to do business with. People call me on the phone and say they'd like to come in and see me. Normally, we get together.
A while back at a banquet I happened to sit beside a representative of a fairly large corporation. I asked him, “How do you feel about this? What is your reaction to this: ‘The Army is hard to do business with?’ He said, “I hate to say this, but you are tough to do business with.”
“Give me some specifics, because I never could get any details. Why don't you come in and see me?”
“I'll be in within a month. I want to bring along one guy and I want to talk just to you, because we have to continue to do business with you people.”
The man and his companion showed up and gave me chapter and verse. A most useful and illuminating exercise. We intend to do something about it.
A time for regrouping. Our product improvement program on weapon system acquisition probably had its starting point in mid-1969 when Secretary Packard, in a famous letter, said, “We have been moving forward on a broad front with a variety of innovations to improve our acquisition techniques and we have added to our methodology.” Since then we have been doing such things as: competitive prototyping; CS squared; “should cost”; operations testing (a formalized program of operational testing to parallel development testing); design to unit cost; greater emphasis on cost analysis, cost data bands and cost estimating; placing a lot of new people under the comptroller to get them away from the procurement man; reliability growth; and better RFP's.
One of my apprehensions today is that we've been going so fast since Dave Packard wrote DOD Directive 5000.1 that the time may now have come, without taking a negative or defensive attitude, to consolidate our gains. Before we unleash any more bold, innovative techniques in the acquisition system, I think we ought to carefully examine the ones we have developed and instituted to date. I think we have to learn to use CS squared better than we're using it now. I think we have to clarify what design to unit cost really means. I think the “should cost” technique is very, very useful, but I think it needs some polishing. The follow-up techniques must employ the talents of DCAS (Defense Contract Administrative Services) to see if the things that we tell the contractor he should improve on after the “Should Cost” is over are in fact followed up on.
I think competitive prototyping and the other term that we attach to that — technology transfer — need a good hard look. Take the first selection of a competitively prototyped item, for example, the raw theory is that, even though we select the winning design, there may be elements of other designs that we'd like to incorporate in the winning design. I don't think we have thought this all the way through because as soon as you start changing the winning guy's design the losing guy says, “You could change my design — how about me?”
We may be going faster than the body politic can absorb. I am fearful of this on the part of not only Army people but industry people as well. As I talk to industry people, and even when I talk to the vice president in charge of merchandising or the vice president in charge of defense business in the esoteric language of CS squared and design to unit cost, I get the feeling that maybe he and I are communicating only 50 percent of the time. I'm not sure that down in the bowels of the corporation this stuff is making a lot of sense; and if it doesn't then it's not going to work very well.
Maybe I'm being somewhat proud of the service, but we really have a discipline in the chain of command. For the purpose of translating new doctrines and new techniques, the chain of command is more responsive, I believe, than in an industrial situation. We do gather people up and give them a seminar for two or three days on design to unit cost. We do send people to school. We do get out in the field and take a look at what's being done. We do set up sampling reviews as we're doing in the RFP's.
But I think even there, with the discipline that I claim we have in the organization and the chain of command, we really have saturated the system. And I'm fearful that the contractor structure, on which we have to depend, may not be as well saturated. So I'm saying, “Let's take a breather. Let's refine our techniques. Let's take another look at every one of them and see if there is some improvement we should make before branching out into something new.” I remember (back in the early 60's) when someone invented the multiple incentive contract. We raced headlong into that — and then spent two years getting out as fast as we could. We hadn't thought it all out.
Project Managers. We have 41 project managers, seven are general officers and two of them are wearing two stars. As far as we can determine, this structure, insofar as rank is concerned, is as good as or better than that of any other outfit in the world.
A GAO report contended that the project manager doesn't have enough authority. So we turned the Army Management Engineering Training Agency (AMETA, an agency out in Rock Island that does independent management engineering surveys) loose and they went around the countryside talking to all the PM's and to many of the contractors that these PM's dealt with. They also talked to the staffs that dealt with the project managers. The findings were very interesting: approximately 95 percent of the project managers thought they had plenty of authority; industry they dealt with thought their authority was fully adequate for performing their jobs; and the staffs, by and large, thought they had too much authority. When you put that all together you conclude that the authority is just about right.
How about the complaint that Project Managers are harassed? Sometimes they are. When a project manager comes in for his quarterly review and sheepishly announces that his latest cost reports indicate that his cost to complete is going to overrun an earlier estimate by $30 million, that the prototypes that were due for testing are going to be six months late, or that his latest test missile broke up after three feet of flight, he should realize that he has introduced into the whole structure, starting with me, a violent transient. After delivering that little collection of bombshells, I don't think he can expect to go back to where he came from and go about his business quietly.
And if, in fact, he needs another $20 million between now and the 30th of June, this is something far beyond the reprogramming authority of anybody in the structure; we have to go over to Congress. So if, in the course of resolving this he is required to give half a dozen briefings and analyses to people in the Pentagon and on the Hill, I don't think the guy should feel that he is being put upon. He should feel he is getting great attention.
A perspective. In 1969 we took a look at the past and it was kind of grim — for a lot of reasons. We had Congressional investigations, we made the newspapers, the Army had its Cheyenne, its MBT-70, its M-16 rifle, and its Sheridan. My counterparts used to mumble, when we'd get together, about the C-5A, the Mark-48 torpedo, and some others. I suppose, during Monday morning quarterbacking sessions, there were things we wish we had done differently. But we do have to get on with our business; so I suggest that maybe the time has come to stop talking about all the bad things that we have done in the past and start talking about things we started to do as long ago as when Dave Packard wrote his memo. Let's put them in place and measure the results of the new techniques in dollars and cents, in schedules, and in hardware performance.
Now, why should we do this? I think that, if we're going to capitalize on our new approach, our new techniques, our new training, our new attention to project managers, and our new and improved interface with industry, we ought to start acting like guys who are on a winning team. Because, unless we do, I just don't think we're going to get any place. It's kind of an emotional, philosophical thing, but I really think we've talked about the bad old past long enough.