AFA Policy Forum

"Acquisition Report: Delivering Combat Capability at Home and Abroad"
Lieutenant General Richard Scofield (USAF Ret.)
Air & Space Conference 2004—Washington, DC
September 14, 2004

[Click here for printer-friendly version]

Click below to go to the Special Report on Delivering Combat Capability at Home and Abroad
http://www.afa.org/media/reports/Scofield.pdf

General Scofield: Good morning. I think my purpose here this morning is to promote some thought. Specifically, thought about the acquisition system that we live with. A show of hands—who has to live with the acquisition system? [Laughter] Oh, my goodness.

All right. Here's a little bit of background on why I did my Delivering Combat Capability at Home and Abroad study for the Air Force Association and a little bit of background about the results that you'll see.

If you look at the F/A-22 and the F-35 programs today, it's a long time from the start of development contract award until when they expect to have their first operational aircraft. If you look at the F-16 Block 60 and F-15K, which are being sold as part of direct commercial sales to the UAE and to Korea, they're able to deliver airplanes in less than four years from the time of development contract award. So the Secretary of the Air Force over the course of the last year has mentioned this several times in speeches, and has posed the question: Why is it that these foreign countries can get products or capabilities so much quicker than the U.S. Air Force?

The purpose of this briefing is to see if I can identify what the factors were that would allow foreign nations to do this by examining the acquisition processes that are used both in the foreign and domestic programs.

I'm using as an illustration or as a way to compare these, the F-15 and the F-16 programs. The reason I chose them was because here's two programs that were started in the early '70s, are still in production, have foreign and have domestic sales, and have had a number of developmental iterations over the course of time.

Because I've chosen aeronautical systems doesn't mean this applies only to aircraft. This is really a process discussion. This is not a program discussion on the F-15 and F-16. The framework for the study started with the acquisition environment as it existed in the early '70s. I'll talk some more about that later on.

I tried to identify the relevant variables over time, either in terms of organizational relationships and influences or acquisition reform initiatives. Then I tried to compare and contrast the ongoing programs, both foreign and domestic.

Then I put together some observations of the current environment and I'd be more than glad to have some exchanges, even amongst yourselves, on the current environment.

Then I got way out on a limb and said, “I think I'll propose a framework, a management framework that maybe the Air Force and some of the other services could consider as part of a new way to do the business.”

As I put the study framework together, I had an interesting discussion with program managers both in the Air Force and within industry. What I got out of it was there were about six aspects of the acquisition environment which they judged to be relatively important if you're going to have a successful program. These are the six that I jotted down for purposes of evaluating the programs using them as criteria for success.

I'll have some additional observations regarding these aspects. There are some details in terms of additional observations regarding these aspects in the study. And rather than go into those in great detail in the briefing, I would encourage you to read the study.

In July 1971, when Melvin Laird was Secretary of Defense and David Packard was the DepSecDef, they published a brand new 5001. The 5001 came about because of a number of perceived failures in the acquisition system in the 1960s. The C-5, F-14, there were a couple of missile programs—not big missiles, small missile programs. So Packard published a new acquisition process, codified it in DoD-5001. It's a six-page document. What it does is three things. It established a mode of operation, a conduct of the program, and program considerations. But its basic mode of operations had to do with the fact that you need to hire competent people, and establish rational priorities and clear sets of roles and responsibilities for the conduct of the programs. Very big on decentralized responsibility and authority. A single manager with sufficient authority. Minimal layers of authority between the program manager and the decision makers at the component level. He was very big on the services being in charge of their programs. They also talked about the fact that program managers ought to have some tenure in their positions.

I ended up being the B-2 program director for eight years. That's probably the longest or the best that the Air Force has been able to do in terms of tenure for a program manager. I kept thinking I was going to get to leave pretty soon, but they kept holding me accountable for how it was going to get done. [Laughter].

The conduct of the program was really rather enlightening in the 5001, and speaks to the fact that there really are program differences, so program managers ought to be using sound judgment as to how it is they manage their programs, and not following detailed processes within their program management. It also emphasized the need for a strong and usable technology base.

In the 1971 timeframe, programs were initiated by the services. It was a component determination based on their conceptual efforts as to whether there was a need and what the plans and issues and objectives ought to be to satisfy that need. Those are all documented in what was then called the Development Concept Paper (DCP).

I’ll bet many of you in this room think DCP stands for Decision Coordinating Paper, which it does today, but in the early 1970s it was a service document and it was for the purposes of documenting the need and how we were going to solve the need.

The SecDef still made the decision on whether to go into development and production, but it was when the service brought the program forward for his review. Then it was a matter of just making sure it was consistent with DoD strategy and that the risk had been adequately addressed within the program prior to getting into production.

In the study, I tried to normalize all three programs—F-15, A-10, and F-16—which were the three programs that were started in the 1970, '71, '72 timeframe, all under the guidelines of 5001 as written by Secretary Packard.

There's some pretty short timeframes here. The longest one was the F-15 from the start of development contract to the first operational airplane which I think was 59 months. They were the only program that didn't have a prototype system. They actually had contract award prior to the publication of 5001. It's interesting that all three of them came in under five years from the time of development contract award.

Note, the relationship between low rate initial production milestones and full production go-ahead relative to the DT&E programs in all three of those programs.

The F-15 had low rate production three months after first flight of the first airplane; full production go-ahead six months after first flight of the first airplane.

The F-16 had long lead one month after first flight and full production ten months later.

The A-10 is really interesting. They had long lead production funding before they had first flight of the development airplane and full production funding five months after that.

I would point out the work that they had done on the A-10 program with regard to the early DT&E and OT&E was done not with developmental airplanes but using prototype airplanes. And not just using the YA-10, but using the YA-9, even though it had lost in the competition. I was at Edwards Air Force Base at the time and I remember the pilots talking about the flying similarities in being able to conduct the mission on those two airplanes. Therefore, why don't we go get useful OT&E data using both airplanes and make an operational assessment without worrying about what the particular airframe was?

The full rate production of the A-10 was approved by OSD and supported by Congress in the funding, in spite of the fact that they had a major fatigue failure three months before the decision. They had a solution when they went to the DSARC, but they had not yet tested the solution.

I think what this says is that if you have an environment where you're willing to delegate responsibility and authority, you're willing to buy into some risk on how you're going to manage the programs with the idea that you're going to get something into the field, going to let the operators use it for a while and then you'll come back with your follow-on, incremental improvements and get it to where you want it to be. I think today we call that “spiral development,” but here's the proof of the pudding that spiral development can be made to work. And it can be made to work even better if you put it into the right environment relative to acquisition risk and decision making.

The F-15 spiral development program had a lot of overlap between the USAF and the international programs over time; and of course we have A's, B's, C's, D's, E's, a bunch of other nomenclatures for the foreign countries that bought F-15s.

The F-16 had a similar heritage evolution starting out with the very early Block 10, Block 15s, moving on all the way up through the Block 60s. But both of these programs were built on a solid airframe foundation. Both programs were able to incorporate new capabilities over time because of the work that had been done on the front end.

Regarding the acquisition command structure as it existed at the time that these three programs were being managed, we had the Secretary and the Chief, and, of course, at that time, the Commander of Air Force Systems Command. We had the four product centers. I've illustrated where the F-15, F-16, and A-10 were. Also, the AWACS was being developed at that time, but AWACS was developed at Hanscom Air Force Base. It wasn't an airplane program. It was an electronics program in the back of an airplane, but still very similar in terms of how you can evolve a configuration and make improvements.

What I think is relatively important to the success of these programs and which we don't have in the environment we live in today what’s behind this program management chain, an infrastructure which included development planning, Wright Aeronautical Laboratories, manufacturing technologies, all of the things that would help the SPOs be able to develop their products more quickly.

One of the reasons the Air Force was able to bring these three airplanes to the table so quickly was an enormous amount of work that was done by the development planners in very close collaboration with industry in the late '60s, so that when the requirement came out of the FX, the AX and the lightweight fighter, there were candidate solutions. These candidate solutions had been studied, industry and the folks at Wright Field had agreed on the attributes those systems could have and the capabilities it would have. And they had done enough work to build constituencies within the Pentagon so that when they took the programs forward they already had the support of OSD and other people within the Pentagon and within Washington to be able to get those programs up and running so quickly.

Unfortunately, due to the downsizing and resources that we deal with today, you don't find that infrastructure existing at any of the product centers as it did in the late '60s or early '70s. I think that's something that really needs to be addressed by the system in the future. It's an investment that can be made that I believe has high payoff.

You take that system and you start with 5001 in 1971, and I think David Packard left the Pentagon in '72, if I'm recalling correctly. Shortly after that, there began to be a series of publications that whittled away at what David Packard had written to 5001. I use an example, and only one example.

Earlier, I had said that the DCP stood for Development Concept Paper, a service document to identify the need and identify the plan as to how to satisfy that need.

5002 came out. They kept the terminology DCP, but it was now Decision Coordinating Paper and it became an OSD document. What it described was the process of how you coordinate a decision within the DSARC environment. I think they have something like seven pages worth of instructions on how you process the DCP when 5001 was written in six pages. It's not a big deal, bit it's a first step. It's part of the insidious evolution of reforms that whittled away at the process that we had established or that Packard had established in 1971.

Then you get down into the 1986 timeframe, after help came from other interested agencies within the acquisition process, and then David Packard comes back again to look at the acquisition system in 1986. What does he say? He says we need to go back to where we have competent people, decentralized, up-front planning, and streamlined management.

Then in 1989 we have the Defense Management Review, and the reason we have the Defense Management Review in '89 is because people didn't think people had reacted properly to the Packard Commission.

So here we are, our third strike at how it is that we can make the process work better, and we're still headed down the path of more reforms, if you will, and the list goes on to where I think 5001 and 5002 have been rewritten twice and have been revised twice since the early 1970 timeframe.

The reason I point this out is because if I look at this simplified command structure, which I had discussed earlier with regard to U.S. Air Force programs, all of those reforms directly impacted the workload on the SPOs.

In the meantime, we've got these folks over in what was then AFLC which are now part of AFMC in the foreign sales community, and they're still pretty much doing things the way the U.S. Air Force did it in the early '70s. They're defining the requirements up front, they're establishing baselines with their foreign customers, they're establishing funding streams and schedules to match those funding streams, and then they go execute and they do all that somewhat impacted by those reforms because of the impact they have on the basic program, but these folks are over here working the process the way the process was created.

They get their deliveries within four or five years after development contract award because they've done the necessary development planning, they've got them decentralized, and they even have some flexibility that our program managers don't have. Country managers who manage the portfolio of programs for a country are able to trade dollars within those portfolios for the benefit of the country, the customer country, which is kind of what we'd like to be able to have our PEOs do for portfolios within the Air Force for the benefit of the using customers within the Air Force.

So I found it interesting in the course of the study that here we had this environment in the early '70s, pushing out products. It wasn't the ultimate solution in any of the cases. They were good airplanes and they were the foundation for better airplanes over time. We had a series of reforms, we have a group of people who are working outside of those reforms, nothing's changed here. But by the F/A-22 and F-35, we'd say a lot has changed.

In my study, I overlay the two direct commercial sale programs with the earlier U.S. Air Force programs, and I'm somewhat struck by how remarkable the schedules look and the fact that there is concurrency in the F-16 Block 60 and the F-15K. But those programs were structured in such a way that the program managers at both Lockheed Martin and at Boeing had the flexibility between development, production and support to be able to manage the total program within the budget that they have and to be able to make the trades as necessary with the approval of the customer, but to keep the programs on track. It's a different environment than what we have in the U.S. Air Force programs today.

So here are some comparative observations. All five of these programs I think are the result of a pretty thorough pre-development concept and planning activity. The development plan was consistent with maturing technology. That was one of the premises that Packard wrote into the first. Take advantage of a solid technology base.

I think all of these programs are not necessarily pushing technology. The F-15 pushed technology in some way in that they were the first widespread use of titanium. And there's no doubt the F-15 program had some start-up problems, had power plant start-up problems, had some EW startup problems, but it wasn't something that couldn't get worked out with the airplanes matriculating to the operating base at the same time.

There were clear requirements baselined with the customers. Some of my friends who were junior officers or mid-grade officers at TAC headquarters at the time weren't totally happy with the way General Bellis was running the F-15 program. They weren't able to get all their new requirements in. The SPO kept saying, “we've got a baseline, we've got a set of requirements, we're getting a good jet on an air-to-air mission.” And the SPO even had a motto that said "not one pound for air-to-ground" during the whole time the F-15A and B were being developed. “Bring it back when we get the A developed and in the field, and we'll work it in the C's and D's and we'll take it on into the E models.”

They had clear program authorities and responsibility. General Bellis as the F-15 program director was the first to use what was then called the blue line management system, where he reported to the commander of AFSC and then on into the Chief and Secretary. Supposedly the staffs were not to get involved, and I've got some vignettes in the study that will give you a feel for that.

General Bellis, being the smart guy he was, didn't ignore the staffs, but the staffs all knew they were there to help. They weren't there to throw roadblocks in General Bellis' way. I think the same was true on the A-10 and on the F-16 programs.

Small management teams. The report will give you a feel for the size of the SPOs at the time. Thirty, 40, 50 people managing the programs. They managed concurrency. Not wild concurrency, but manageable concurrency and they took risk and the system bought into those risks as part of the program plans, as evidenced by the long lead production approvals and the production program approvals. Then the necessary resources were committed and they were in fact maintained with the SPOs. Congress basically supported the funding for the development programs in the early '70s. It wasn't until the late '70s when we went through that inflation period that changes began to be made in the programs and they were generally made in the production side.

In the dominant management environment similarities, I think I've already talked about delegation of authority and responsibility with top cover, which I think was very important to the program managers at the time. There were cooperative constituencies within the Pentagon.

When I started in this business in '73 with AWACS we had PEM offices that looked like IPT. They had people from studies and analysis, they had people from the budget shops, they had people from logistics shops, all co-located within the same offices in the Pentagon. You went to the PEM shop for any knowledge that you wanted to have on the program. The PEMs spoke for the program managers pretty much at that time. And there was a willingness to accept risks and tolerate work-arounds. The F-15 clearly had to use a number of work-arounds when they began fielding the airplanes in the 1970-'74 timeframe.

So I think there are lessons we could learn from looking at those five programs.

There is a chart in my study that I lifted out of a Defense Acquisition University briefing last May. This briefing was put together to brief the acquisition workforce following the last rewrite of 5001 and 5002. I was first struck by how small the acquisition portion was, but I'm equally struck by this thing called oversight which has integrated decision meetings, ongoing process from day one until day infinity, where requirements can creep into the program, or at least it infers that requirements can creep into the program at any time.

Now I'm sure there will be people that say, “well this chart was really just to be an illustration of what the system could be and it's really not technically accurate.” I would contend we ought to make it technically accurate so that we can at least have a baseline on which the acquisition community and the using commands can understand how the process could work or ought to work.

What I also found interesting is it's not the acquisition process. It's the requirements and acquisition process. I'm setting you up for an answer here.

Here's another chart out of the DAU briefing that shows a different aspect of the acquisition management framework, and it shows that you can in fact insert user needs and technology opportunities into the program at three defined locations, but one of them is Milestone C. Now, if my recollection is right, you're supposed to go to OT&E with a production representative article, and you're supposed to produce that representative article, but yet we're telling the system you can put new requirements in in Milestone C. I would submit that that may be part of the reason we can't get basic capability into the field more quickly today.

I've not seen a system go into the field in 20-plus years of doing this where we didn't improve the system once we got it into the field in any case.

So I would suggest that maybe the system needs to think more about taking advantage of user needs and technology opportunities up to Milestone B, and the Milestone B would only be if it's a high priority, high payoff using somewhat mature technology. But establish a baseline at Milestone B. That's the baseline you take into development. That's the baseline you test and that's the baseline you produce. You can always come back on the next spiral and put in new requirements and establish a new development baseline. The fact that we have this two-year budget cycle may very well give us the opportunity to put some discipline into the system to work within that two year budget cycle.

So I devised my own acquisition system, recognizing this is not the way I would have done it if I had total control. This is the way I would do it given the fact that we've got these 20-plus years worth of acquisition reforms. You've already got OSD and Congress with their fingers all over most of our programs. It would be very difficult to take those people entirely out of the process as it was in the 1970-71 timeframe.

But what could we do today to take advantage of the skill sets that these people at the higher levels can bring? I would submit that maybe we ought to have a pre-systems acquisition phase, and we take those folks within the JROC and OSD, the operating commands, the headquarter DRs, the DCSs within the Pentagon, SAF/AQ, and AFRL in particular and AFMC, and let them worry the requirements generation, the new JSIDS process that we have, the concept requirement and technology development, the activity around Milestone A in a somewhat iterative process. These are the folks that ought to be dealing with strategy and policy, and they ought to be laying out a course where the services can then devise the program needs in order to support the policy and the strategy. They work that within the planning years leading up to the preparation of the President's budget. Don't take Milestone B as being that it has to be program specific. It could be a President's budget for technology development or for laboratory programs. But at least it's hung against a strategy so that when you submit a President's budget you can justify it clearly and logically on the basis of need and set it up for implementation. In the case of a program, set it up for system development.

I've tried to illustrate the fact that you can always come back in follow-on spirals within the budget cycle. And then I got rid of this integrated decision meeting process. I don't necessarily know how to do integrated decisions. I know how to get integrated inputs and then make a decision, but I'm not necessarily sure how you do integrated decision making. Let the guys worry about that pre-systems acquisition. But once you get into it, then you rely on the Capabilities Review and Risk Assessment process (CRRA) to identify the deficiencies so that the lab and other people can start to work those deficiencies as well as work new technologies. And if you have feedback on those deficiencies, you can put that back into the pre-system acquisition mix so the decision makers can make trades between new capability or improving capability that we currently have.

In the book, you'll see there are some shaded areas behind these in the book to reflect the fact that it's really two separate activities. I go back to my earlier point. The process is already described as the requirements and acquisition process, so maybe we ought to separate them. Maybe we just ought to say, “okay, we're going to have two processes. One for figuring out what we want and when we want it; and the other, decentralized, service-run, go execute to fill the need that we give you for Milestone B.”

Again, don't take milestone B as being the only departure point, but you could, and I tried to identify those offices and agencies which could be a part of the pre-system acquisition phase, those activities to the right of the Milestone B line, the decentralized execution of those activities within AFMC and within the PEO structure.

By way of summary, I think effective combat capability can be developed more quickly than we're doing it today. It's probably going to require us to go back to the future, or at least move back toward the future. I would assert that it requires a change in the defense acquisition to the point where you want to have a separate pre-development activity. And I haven't said enough yet about technology push, but if I look back at the programs in the late '60s or early '70s, there was a lot of technology push. It was rung out so that when they went to development it was fairly mature. I think the most, at least the classic example of technology push that I'm familiar with is the F-117. The Air Force had no requirement, had no ConOps when DARPA wanted to have the Have Blue program. They did the Have Blue program and we did the F-117 program on the basis of a technology leap, if you will, in terms of technology push. The only thing we pushed in the development program was the plan form. The F-117 uses F-15 landing gear, it uses an F-18 cockpit, and F-18 engines. It was not an F-16 flight control system. So what we pushed was the shape of the airplane to get the low radar cross section.

So you can manage these technology pushes in a way that you reduce the risk of the development program.

Post Milestone B execution ought to be a service responsibility. We ought to have the JROC and OSD and maybe even Congress participate in the establishment of policy, strategy, defining for the services that strategy so the services can develop the way in which they want to meet the requirement, and then manage the program to meet the requirement. Then integrate the spiral development within the PBES system as part of fulfilling the overall strategy. This would require a change in the management environment. We'd have to make a bigger investment in technology and in the development planning. And I'm aware that there's work already ongoing within AFMC with regards to reestablishing the development planning aspects, renamed as capabilities integration. There's good work ongoing in that area.

But there has to be a willingness to delegate authority, and I mean really delegate authority to the program managers. When I think back to the Air Force lightning bolts that we first saw in the 1995 timeframe—if I remember the wording in the cover memo it was that these lightning bolts in the IPTs—the overarching IPT and integrating IPT were being established to remove roadblocks and impediments for the program manager. If any of you have been a program manager in the last ten years, you know that what those folks really did was put on additional requirements for programs to be able to fulfill before they could even get to go to the DSARC process.

Then we need to discipline the system to work within the process. The F-15 did a great job of that. Guys didn't like it at the time, but they got a good airplane and they got it early and they got to improve it as time went on. We need to gain control of how requirements work their way into particular programs. And somehow we need to reestablish this cooperative environment and reestablish confidence. We need to build constituencies where everyone is pushing and pulling in the same direction for the support of a program instead of the somewhat adversarial relationships we have even within the Pentagon today and, of course, across the river.

With that, I'd be glad to take questions or comments or discussion.

Q&A Session:

Q: For us who developed the F-15/F-16, there wasn't a technology leap because we were just improving our airframes. But for the foreign countries, it was a technology leap because they had nothing. So when we invested in the F-117 technology with the design of that aircraft, it moved us forward. So we moved forward based on that technology.

The smart UAVS that are flying today represent a technology leap for us, so we're pushing the technology quickly, and maybe that's why when we move forward to bringing something to fruition, we're using this process for the warfighter, because of that technology leap as opposed to something that we're just moving off the shelf. We deliver those Foreign Military Sales to those foreign countries because these technologies pay for that.

General Scofield: I think I'd take a little bit of issue with regard to the amount of technology leap that the foreign countries are really getting into.

If you look in the book, and I think I've got a chart that would show it. For example, the F-15 configuration changes. Two aspects of this. Some people will say, “well they got it in four years because they were using a proven airframe.” If you have program management experience and you look at the changes that they're making to the F-15 to get the K model, this is not a simple task. This requires some good systems integration, systems management. It's still going to be a challenge to do, but the point is the program manager has the flexibility between development and production. He knows he's going to get to sell so many airplanes to get through the development program. He can make trades. If he runs into a problem in development he can make trades between the production program and development to keep it on schedule to get the capability. He might even make trades in the specifics of the subsystems as long as he gets system level performance.

So I'm not sure there's a big technology leap—it's a manageable technology task and I think that's part of the contract negotiations that go on within the foreign sales where they know what they can deliver and that's what they commit to deliver. If the customer wants more, well, then maybe we need a bigger development program or we get you this and then we come back and look at it when the other technology is more mature.

Now in the case of the UAV, I think the fact that we're using Predator and Global Hawk as prototypes in actual operational experience is a way for us to figure out what we really want UAV systems to be able to do. So there's a way that you can manage technology by not going into high rate production programs until you basically understand how you're going to use it and what you want the attributes of the system to be.

Q: You talked about going back to sort of pick up some of the things that were done earlier in development. We might have rushed some of the F-15’s difficult types of capabilities. Even in a four year stretch, what about the sustainment piece? Do you think it was the right thing to do when the commands merged? And are we thinking through some of those things that we're rushing into development?

General Scofield: There are two schools of thought. David Packard when he wrote 5001 also wanted to write into there that there would be no investment in manpower and resources in the "ilities"—maintainability, reliability—until they got into the development program. The prototype program was to be free of that because he felt that only slowed down the process.

The staff talked him out of it. I'm not sure whether it was the OSD staff or the service staffs, but they talked him out of putting that in.

In the maintainability or supportability area, there are so many options that we have today that we didn't have at the time that these airplanes were being built. You've got overnight express and FedEx changes the whole mix of how you buy spares and where you put them. So I think that's something that we ought to worry about as part of the development activity with the idea that we know that there are support options available to us with early operational development. It may not be exactly the way we end up doing it in the end, but at least we get capability out there, we get to use it, and then we find out what are the real breakers and what are the things that we're going to have to manage more carefully.

I think you can give up on some of that.

Q: You mentioned independent process of operational testing. We're very interested in reestablishing things that we saw in the earlier conduct of development and operational testing. I think we know now the test community can be very much involved, real joint venture partners, pre Milestone A—to establish the best strategy, to look for ways to include the things that are most critical and build it quicker, and we want to do that again because we see a major erosion of that influence over the past few years.

General Scofield: Yeah. That's a good point. I probably should have talked more about it when I was in the acquisition reform listing here.

The creation of AT&L really codified the fact that OSD was going to own the decision making process on the programs, for the services. It also established about that same time that OT&E would be an independent agency. So that independence in my judgment over the last 10 or 15 years has caused a big gap between the guys who do DT&E in the development of the program and the guys who have to test it and have to maintain this independence in order to satisfy it.

What the AS program did with the A-10 and the A-9, that's the model we ought to be working for. I don't think the YF-23 was that much different than the YF-22, that you couldn't have taken all four prototypes and used them for some period of time and gained some real honest operational assessments. Not operational testing, but at least operational assessments.

And I've sometimes wondered what would have happened if Tom Morganfeld hadn't had that PIO and that we didn't put the 22 in the barn. For how many years could we have used the 22 prototypes and gotten more data? On the A-10, they had 2,000 hours of flight test data before they got the first development airplane. And the A-10 production article was not that much different than the prototype airframe. That's the reason they were able to get their production decision so quickly, along with the support.

You'll see in the report, General Bill Evans who was RD at that time took on Congress on the issue of how fast were we were going on the A-10. He took it on on the basis of prototype and our ability to understand based on the prototype performance.

Q: Regarding the role of investor preparedness in pre-Milestone B, can you describe more specifically what the government and what industry needs to be doing to ensure that we are ready to produce at the time that the capability is really needed?

General Scofield: I think discussed briefly the infrastructure that existed in the late '60s and '70s at places like ASC. I think it also existed at ESC with the developmental planning, the laboratory, product line laboratory and manufacturing technology.

I'll use the example that I'm most familiar with, which was the B-2. We had a little bit of a luxury in the B-2 in the 1981-'83 timeframe. We were able to manage our program and our budget without a whole lot of oversight. So we were able to do things working with the laboratory and putting specific manufacturing technology programs on line at Boeing and at a [BOT] and somewhat at Northrop Grumman that significantly reduced the risk of manufacturing the B-2. Composite wing, for example. [Aft deck] material fabrication. I would think we probably spent a couple of hundred million dollars on manufacturing technologies on B-2 in order to be able to reduce the risk to get that airplane into development.

The fact of the matter was we carried two wings. We carried an aluminum wing and a composite wing for almost three years. The airplane never would have made it on an aluminum wing so we had to have composite.

At that time, the Air Force manufacturing technology budget ran around $120 million. It was managed by the manufacturing technology folks in the Wright Lab. Today the budget's around $30 to $40 million, and out of that comes overhead for the people that are involved. We don't have the industrial preparedness capability today that we had at that point in time. I think that's as much an oversight as the lack of development planning.

We ought to be in the business. We have technology readiness levels and there are folks working hard to establish manufacturing readiness levels. And there's a relationship between these technology readiness levels and manufacturing readiness levels which would help you get to a Milestone B decision to where you really understand what you’re dealing with.

I think that may be the key to being able to restore confidence in the system. We can establish a program baseline at Milestone B with a cost and schedule estimate, that the team has a 90 to 100% chance of completing. Do that a couple of times, and then I bet the system begins to think a little bit differently. I'm not sure we can wait that long, but maybe we need a couple of prototype programs that could go do that for us.

Going back to your question, even within industry, I read how the IRAD that gets addressed by the government has changed over the last ten years to where it's not all that much of an advantage for industry to be able to make those manufacturing investments. So I think that's an area where we could really be doing a lot better and probably have a better chance of successful program implementation because of it.

Q: Having worked on the F-117 for a number of years, I can say that because of the classified nature of that platform/program we had a lot of emphasis and flexibility in SPD to do the program quicker, faster, better, cheaper, simply because we didn't have to do all of the reporting. Unfortunately, the F-22 and C-17 don't fall under those kinds of umbrellas and requirements for reporting. Today, everybody has their finger in the pie. That in my opinion really affects a lot of these timelines as well as requirements for sustainment and development changes. The F-117 did not have all of these kinds of requirements in the very beginning.

General Scofield: It had a lot of CLS, but the folks at Tonopah did a lot of organic work early on, at least at the organizational level.

Two thoughts on that ... You'll see in the study I've referenced the fact that people think that the F-117 and the B-2 threw out all the regulations and went fast. They didn't do that. What we did is we took them and used them as guidelines. Now we didn't have the reporting requirements, you're right about that. And that's a big workload off the SPO when you don't have the reporting requirements. I think Packard said it specifically—small team, minimum reporting requirements. If you're going to have a small team and minimum reporting requirements and you're going to push decision making down to the lowest level (what really gives you the speed is making decisions at the lowest level without fear of having to go back and review them at some point in time), you need a set of regulations or guidelines so that the team can operate with a common set of expectations. That's what we did on the 117 and the B-2. We didn't throw them out. The 375 series from the '70s was a great set of documents on how you implement and execute a program, and those of us who lived with that for a short time and used it in the black world in the '80s, there was a way in which we all could anticipate how people in manufacturing or people over in engineering were working to resolve issues. You've got to have that kind of an infrastructure to keep everybody within your organization on a common decision making process.

So don't let people tell you they threw the regulations out and therefore they were able to go faster. We had a lot less requirements, no doubt about that, but the processes that have been established over the years were good processes and we elected not to throw them out.

Thank you very much.