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
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
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
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
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
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
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
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
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
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: 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.
Return to AFA Air & Space Conference