NASA Johnson Space Center
Oral History Project
Edited Oral History Transcript
Interviewed by Rebecca Wright
Springfield, Virginia – 28 April 2008
Wright: Today is April 28th, 2008. We are in Springfield, Virginia
to speak with Arnold Aldrich, who retired after 35 years with NASA
and after 13 years with Lockheed Martin where he served as a vice
president and director of program management for the corporation.
The interview is being conducted for the JSC Tacit Knowledge Capture
Project for the Space Shuttle Program. Interviewer is Rebecca Wright,
assisted by Sandra Johnson. Thanks again for coming in to see us this
morning. You first joined NASA in 1959 when the space program was
first beginning. Your firsthand experiences range through the programs
that led to Shuttle, where you first served as the manager of the
Program Assessment Office that Bob [Robert F.] Thompson asked you
to begin. Tell us how you transitioned into this position from Apollo
and about those duties, and then just lead us into where you'd like
for us to know about the Shuttle Program.
Your interest today is about program management and how you prepare
for it and what attributes are strong attributes or things you ought
to have. One of the things I will mention a couple times, and I believe
in a lot, is that in the programs that we do in NASA and particularly
at the Johnson Space Center [Houston, Texas] really require a pretty
in-depth understanding technically of the program and the systems
that are involved in the program. In order to arrive at the point
I was at when I went into program management, I had quite an extensive
background of spacecraft systems in the Mercury, Gemini, and Apollo
and Apollo-Soyuz [Test Project, ASTP] Programs, the Skylab Program.
I did move into program management midway in the Skylab Program. Then
on with the CSMs [Command Service Modules] for Apollo-Soyuz. But prior
to that, the first third of my 35 years at NASA I worked in the flight
operations organization and in the development of the Mission Control
Center and the remote sites and the flight procedures.
All of that gave me a pretty strong background in the details of those
programs, and I evolved into becoming one of the senior spacecraft
systems console operators for Mercury. Then for Gemini and Apollo
I was the leader of the organization that trained and used and applied
the spacecraft system monitors for the Gemini spacecraft and for the
Command Service Module on Apollo. Through all of that, learning the
operations and the management and then the spacecraft systems in quite
a bit of detail, provided a breadth of background that I thought was
a very strong asset when I first moved into program management. I
knew the program so well, and I knew in-depth the technical aspects
The Shuttle, of course, was a brand-new spacecraft. When I was reading
back through a transcript that you had done with us before, for instance,
and you mentioned that Bob Thompson asked you to start this Program
Assessment Office, which was a new office, and you had a chance to
look at issues. Tell us how important that was at the beginning of
this new time period for NASA as it moved into a new spacecraft era.
During the time of Apollo 15, I transitioned out of Mission Control
and spacecraft systems management, and I went to work for Kenny [Kenneth
S.] Kleinknecht as a deputy program manager in Skylab. Then not long
after that, we were using the Apollo Command Service Modules also
to go to Skylab and to do the Apollo-Soyuz with the Russians, and
I went to the Apollo Spacecraft Program Office, and I was deputy program
manager to Glynn [S.] Lunney for the Command Service Modules. I was
back in the same programs I'd been doing mission control for in the
early phases of program management.
During that time period of the Skylab and the Apollo-Soyuz, the Space
Shuttle Program started up and actually became very real, and hardware
became developed, and it was a strong program underway. When Apollo-Soyuz
ended, that was the end of the Mercury-Gemini-Apollo sequence for
all of Johnson and NASA. It was at that time that they were beginning
to see some need for a Program Assessment Office. Some people called
it the “devil's advocate” office, to assess what the program
was doing in the Space Shuttle and identify issues that if you looked
at it independently of the program perhaps ought to be addressed.
I know Bob Thompson was very interested in that, and I'm certain he
felt he was doing his best to run the program the best way it could
be, but it was an opportunity to look at things. And I was asked to
run this office.
Most of the rest of the Apollo people that had finally finished doing
ASTP went into a new office that dealt with payloads for Space Shuttle.
It was called SPIDPO [Shuttle Payload Integration and Development
Program Office], and it was the procedures and what they'd be and
how you'd handle them and how you'd deal with the people that brought
payloads. I was pulled off because of my background in spacecraft
systems to lead this separate assessment with people who hadn't been
tied into the Shuttle Program at that time and look at what was there.
I carefully went through the Center and selected a group of about
half a dozen people to work for me and had to go negotiate getting
them assigned to me with whoever their manager was at the Center.
I remember a couple of them that I asked for were pretty strong in
the Engineering Directorate, and I had to go talk to Max [Dr. Maxime
A.] Faget. Max thought the Program Assessment Office was great, but—“Not
taking my people to do it.” In the end I got a pretty good team,
and we looked at the mechanical aspects of the Shuttle and the avionics
and the missions and the whole suite of what the Shuttle Program was
planning to do and provided a series of reports on what we thought.
It was interesting. Because of my background partly, because I'm an
electrical engineer, but partly also because I think it was one of
the needs—we were particularly critical of how the avionics
and the software was developing. There were some questions about the
adequacy of the size of the computers and the actual architecture
of the avionics multiredundant computer system that's on the Shuttle.
We criticized that pretty strongly. I'll come back to that in a minute.
Another thing we were pretty concerned about was the fact that the
solid rocket boosters were single point failures, and once you lit
them they had to burn for the first two minutes. There was no way
to get off. There was no escape. They would take you two minutes downstream
in the direction they wanted to go. Our group had been used to the
prior three programs where we always had a launch escape system on
board. We presented that to the Shuttle Program and to the Center
management, and they felt the rationale for doing that had been looked
at a number of times and that didn't result in any change, even though
it's something we played back to them.
The avionics thing—what really happened there was that they
said, “Well, Arnie, you're so smart, I think you ought to come
to the Orbiter and be the head of the Orbiter Avionics Systems Office,”
which is doing the avionics and the software for the Space Shuttle,
even though it's called Orbiter. All of the avionics that controls
the total vehicle and most of the flight and the mission is all in
the Orbiter. It was in the Orbiter Project Office under Aaron Cohen,
but closely tied to Bob Thompson's Shuttle. They didn't have an avionics
office in the Shuttle Program.
The result of my work in the Program Assessment Office led to me being
put in charge of the avionics for Shuttle for the Orbiter, but also
for the whole Shuttle vehicle. That was a very interesting part of
my career, and I worked it for the next three and a half or four years.
Quite proud of what was accomplished there. We made some of the changes
that were the direct result of the areas we were worried about in
the Program Assessment Office. For a number of those years I ran the
Orbiter Software Avionics Control Board every week with eight or ten
hours of change and adjustment traffic with IBM, who was building
the software, and Rockwell International [Corporation] building the
avionics. That was my introduction into serious program management.
I was the deputy in the two prior programs and contributed, but this
was one where I was in charge of a major element of a program, and
it was the Space Shuttle Orbiter.
Each of the positions you described had its own level of responsibilities
and details of discovery. Share with us some of the most memorable
lessons during that time period, working with those challenges that
you encountered during those different transitions of positions up
in the Shuttle. Did it become easier as you moved up the line of management?
One of the lessons is needing to understand in detail the systems
that you're the program manager for. I had done that as a matter of
course during my time in flight operations. So it was natural to be
pretty detail-involved in the engineering and the technical aspects
of the programs. In each of these programs during this time and for
the rest of my time in program management in NASA I ran a significant
change board, had to deal with very detailed technical people, both
at Johnson and the contractors involved. I was comfortable with that
and I liked it. If I was going to recommend an attribute that is important
in program management the way it's done at Johnson, and what the programs
at Johnson demand, I think that's a necessary aspect and trait that
program managers need to develop.
At Lockheed Martin [Corporation] I could see some different things
as we talked about program management. I was in the corporate office
in Bethesda [Maryland], and on any given day at Lockheed Martin there
are about 3,200 programs, and they're all in some phase of executing.
They need to use adequate procedures and have adequate training and
be prepared for the things they're going to deal with. They're working
on programs, some of which are quite like the ones we did at Johnson,
but some are quite a bit different. They're managing people services,
they're managing information technology. There's a broader suite of
programs than just what Johnson does. My experience was almost all
At Lockheed, one of the things we talked about a lot was whether you
had to be an engineer and a technical person to be a program manager.
Philosophically, I agree with the general consensus that you don't
have to be. Someone who comes from a business background or someone
comes from some other scientific discipline could well be a program
manager, if they have the right exposure and training and they're
brought in the right way and then they have the adequate set of processes
and procedures to follow. I agree with that philosophically, but at
Johnson when you're flying these very technical human spacecraft,
it would be hard to picture a program manager that doesn't have a
strong—and maybe not an engineering degree—but a strong
technical focus on what they're doing. Because otherwise you don't
get quite deep enough to understand the decisions you're making.
You talked about the details of the technical side for overall program
management. What about program efficiency? What are some of the attributes
or the lessons that you learned in how to run programs as efficiently
as they need to be?
In some sense I think I was spoiled in how I was brought up at the
Johnson Space Center. I was brought up where every job I had, I worked
for some of the people that were already doing the job, that were
as capable and talented and knew how to execute programs as I've ever
known. When I worked for Kenny Kleinknecht in Skylab, he had a tremendously
effective well-balanced program going. I learned how to do it by just
joining the program and doing it with him and doing some of it myself.
It was true with Glynn Lunney. Then I worked for Aaron Cohen, it was
true with Aaron Cohen. Then I worked for Bob Thompson. Every one of
them, when I got there, already had a program that was balanced, was
well-planned, was executing efficiently and effectively. So I learned
how to do those things just because I started doing them.
Now, you go to Lockheed where you have all these programs, 3,200 programs.
It means that every day some program manager's leaving that program
or leaving the company. New ones are coming in, and how do they plug
in? So you talk about, “How do we assure these people are trained
and what do they need to know and how do they get it?” I still
think that on-the-job training is by far the most necessary and most
beneficial part of learning program management. But, many times I
don't think people have the opportunity to work for people like the
program managers I've mentioned, and Chris [Christopher C.] Kraft
[Jr.]. These people were strong and competent and were already doing
the things that I think are the best in executing programs. I learned
by doing it with them.
The kind of program you need, though, if you have to start and you
don't have that opportunity—you still need some on-the-job training
because being a program manager takes experience and understanding
of dealing with people, but you also need some classroom training.
It's probably classroom and beyond the classroom in terms of exposure
to program management processes, program management aspects that people
in this era and in prior eras thought were the best practices to be
used. You've got to know that. You don't have to be an expert in all
of them, but you have to be exposed to all of them. You also need
mentors. You need people that you can go to when you seem stumped
and you say, “Well, am I doing it right? What am I missing here?”
or “Can you help me?” That's also an important characteristic.
I guess I had mentors all the time, because they were right there,
but my program management training was on-the-job training to an extent
that I think is unique. If you're providing new program managers for
new programs and new timeframes, you've got to be sure these other
things are part of what they learn and what they do. Right now I'm
on an advisory council that supports an initiative that Mike [Michael
L.] Coats started last year on developing program managers at Johnson.
There's some colleagues of mine on that advisory council that I think
a lot of, and we've met regularly during the last year to first plan
this program and then help put it together and then help the phases
of execution through the first—there's a class of about 30 program
managers at Johnson now that are halfway through an 18-month program
We built the concept of, “You've got to have on-the-job training,
and if you want these people to evolve, you've got to today put them
in some job where they'll start to get the experience they're going
to need.” Then you also have to have the training and exposure
so that you understand the breadth of program management and all the
little areas that you're going to have somebody else do for you. But
you better know enough about it to be sure it's being done the way
it ought to be done, and maybe if it's not, what the right additional
steps are. And mentors so that you can talk about it standing back
a little further, not on-the-job training, but somebody who's been
there and has other views or other timeframes.
Johnson’s put together a program like that over the last year,
and frankly I think it is excellent. We had a review of it just about
a month ago where they gave a summary of the success so far, and it's
a very excellent program. In fact, I mentioned to them that you were
going to be doing these interviews and that the things people like
me tell you could be good inputs to their program, too. Because they're
looking certainly to finish this class and be very successful, which
they feel they have been so far, but then there's going to be more
classes and their program will evolve. So best practices in program
management are the ones I've talked about here, and they're all very
important. A program manager needs to know some amount of each of
those things will make the blend of background that's really important.
If you were putting together a class of the new generation of leaders
for NASA, what would you be looking for, and what are the attributes
that you'd like to identify in these up-and-coming managers? What
do they need to have in order to take that next step or take NASA
to the next step? What are you looking for in people that will be
developed as part of that program management plan?
They need to be energetic and interested in things, not just maybe
in some program they're not quite assigned to yet, but any program
would be of interest to them. I pointed out they've got to be interested
in the technical aspects of it as well as the “I'm going to
manage the schedule and the budget and assign things to people.”
There's some people that are part of these groups I've worked with,
particularly at Lockheed because it was a bigger operation, that view
this as what we need to do: find the perfect set of procedures to
execute program management. And if we have a perfect set it's like
a cookbook recipe for doing program management, and if we do a good
enough job putting that together, anybody can be a program manager.
It's very important to work towards a goal like that. But that in
itself is not enough. There's unique and different things that come
up daily in program management. There's no recipe that's going to
take you through it. You've got to have intuition and insight and
understanding and ability to communicate with people, to understand
people, understand how much trust to give them or confidence to put
in what they tell you, how many times you ask a breadth of people.
It's pretty complicated. Your question was, “What do new fresh
younger people need to move into that and what do you look for?”
You look for strength and interest and intelligence, hardworking,
but the drive to want to do it. If they want to do it and they have
some of these attributes. It's always a learning experience. Whatever
degree of program management you've done up to now, if you do more
you'll learn more and your experience base will expand.
What do you think the hardest lesson you learned through all those
years that you've worked in the space-related industry? What's the
best lesson you learned?
The best lesson—it's to have your technical basis and be interested
in it. It's an important part. One of the things I learned going along,
but was even more reinforced when I became the Shuttle Program Manager
at Johnson, after the Orbiter avionics timeframe. I became the Deputy
Program Manager in Space Shuttle under Bob Thompson briefly, but then
I was asked to become the Manager of the Orbiter following Aaron Cohen.
That was a great job. But it was also a program that was up and running
and humming, and I just had to step in and be sure I kept all the
knobs turned the right way and get deeply involved in it. One of the
things I started to learn there, and I really learned when I took
over as Program Manager after Bob Thompson in the Space Shuttle, is
the importance of rigorous configuration management control.
The Space Shuttle Program at Johnson had, and I think probably still
has, the best configuration control process I've seen anywhere. It
is very meticulous. It's very well-documented. It's very well-communicated.
At that time, when I became the Program Manager for Space Shuttle,
I also became the Chairman of the PRCB, Program Requirements Change
Board. I got to see this process that Bob Thompson put in place. I
don't know where he came upon this. Maybe he'd done it before. It
was really a strong process, and it controlled everything in the Shuttle
Program in terms of rigorous definition of configurations and of changes
and rigorous documentation. The overall spec [specification] for the
Space Shuttle Program is NSTS [National Space Transportation System]
07700. It's a very extensive set of documentation that defines everything
about the Shuttle, both in the big picture and in the details, and
everything in there was controlled rigorously by this office.
There was a fellow that worked for Bob that had a lot to do with setting
that up named Bert [James B.] Jackson [Jr.]. After I became the chairman,
Bert ran that for me, and I felt that, more than anything else, gave
me the feeling that I had control and ultimate knowledge of what was
going on in the program. I had everybody connected. Nobody's off doing
some other kind of stuff that they thought was what they were supposed
to do that the program wasn't connected with. I'd say that's a very
important lesson. I appreciate it a lot, and if I was to ever be a
program manager again, rigorous configuration control is a very strong
part of it. A lot of people don't like that much configuration rigor
and documentation and formality. But to me it's worth the effort it
takes. It makes for a lot of long days in meetings and reviewing things,
but it makes it work.
Another thing I would say is—bouncing back to the prior time
when I was doing the Software Change Board for the avionics software
for the Shuttle—that was an era in aerospace evolution where
the processes for developing software weren't as rigorous and widespread
across different organizations as they are now. Now they're quite
rigorous. It's understood formal processes of developing software.
They're commonly used by lots of people that do that. But back then
that all hadn't become such a well-integrated understood way. Software
was still pretty new, and the Shuttle had some complicated software.
I think one of the strengths that caused the avionics and the software
to come out so well is that we insisted on writing the requirements
for the software, the detailed requirements, specifically, exactly,
what's going to happen in every little technical area. Writing it
in English so that you and I could understand exactly what was going
to happen. Then someone would go away and code the software to do
exactly that, and someone else would write the test procedures that
would test that software to see if it matched. In that era many different
areas that were developing software would write requirements in general.
Broad requirements—“What it's supposed to do: supposed
to do this, supposed to do that.” But then, when they got down
to the details, they'd write it in software machine language so that
the engineers and you and I hoped they got it, and we're going to
test it to see if we like what it does, but there was no communication.
There was an office in the Mission Planning and Analysis Division
that was responsible for the contract with IBM to develop the software.
When I got there the plan was to do it in English, and these are big
books. Flight software requirements, these are big books, too. Once
they're baselined, we control every little word in English in there
that controls every little set of coding in the software. I think
that was an awesome strength. By the way, the Space Shuttle avionics
and software has performed admirably for many years, and it is one
of the evolving technologies that made the Space Shuttle possible.
So I think it was very important.
Another thing I learned about program management—and this again
came out of this mission control time phase—in running these
change boards and dealing with all these technical subjects, you had
to listen carefully to people who would present. “We need to
do this because we're going to change this or that or add to this
or something, we need money for it.” But it wasn't just, “They
need money for it and what's the schedule?” it was also, “Is
it really the right thing to do?”
I tried to develop the habit, and I did develop the habit, of listening
in-depth to everything they presented to the level of detail they
presented it. The purpose of that is to fully understand why they
want to make these changes and what they are. If they couldn't explain
it to me so I could understand it, I had a strong suspicion they didn't
understand it either—so that's another ground rule of mine.
If people can't explain it to you in a way that's simple enough you
can understand it—in technical depth—but, sometimes these
are in areas you haven't spent much time in. You’ve got to understand
There's another thing I wanted to comment on in this discussion—the
management style of the people you worked for—every program
manager works for somebody that's higher up. Over the years, in all
three of my areas—the flight control, mission control, flight
operations—then in all these program management jobs at Johnson,
and then in the jobs I worked in in Lockheed, I always had a more
senior guy who I worked for. So I got to see a lot of management styles.
Some people would be very much engaged with you and into what you
were doing. Even though you were the program manager, you're responsible,
you're accountable, they'd be in there with you. Some people—unless
you fall flat on your face and have some terrible problem—wouldn't
talk to you.
The reason I brought this up is that one of the most important parts
of my development during these years is working for Chris Kraft. In
all of the years I had in aerospace, 48 years, the best management
style for a senior person I worked for is the one that Chris has.
He would clearly assign you a job because he had confidence you would
do it. Then he'd leave you to do it and be accountable, and he wouldn't
come down and muck with day-to-day. But what he would do is once a
week, faithfully, you'd have an hour with him. It'd be your meeting.
You'd go in and you'd talk to him about what you thought was most
important, what you were having trouble with, what things maybe we
should be doing we weren't. He was always up to speed on anything
that was going on, so he would be prepared to talk about any of that.
If someone had some problem they brought to him that they were concerned
about, during that he'd ask you about it.
Bet that could be an interesting conversation, couldn't it?
Yes, but it was wonderful. You never felt like he was stepping in
and directing you this way or that way. He was paying close attention,
but he wasn't on top of you every day. Yet he was letting you go away
and solve your problem. It's a very excellent way also to bring people
up and improve. Whatever they can do now with that kind of treatment,
they can grow.
It seemed to incorporate a lot of the aspects that you talked about.
He served as a mentor at the same time he was a teacher and a confidant
and an encourager, but still taskmaster. He knew what you were doing.
And he's watching you. But he's not meddling. It was very, very fine.
Great way to learn.
Through all of that, if I come back to where we started, still the
most important part of becoming a good program manager is on-the-job
training. If you don't bring people up through an on-the-job process
to some degree, it's going to be hard to get them to where you need
them to start a program.
When I was listening to you going through these different areas, there
was a lot of planning involved in how things were done. Share with
me why that's so important, and if you saw anything through your career
that proved that good planning really is worth the time that it takes
for a good result.
These programs are incredibly complicated, complex interactions of
different systems elements and different companies, different people
involved in the government side. There's no way you can have a successful
evolution of development and of the business aspects of a program,
the schedules and the finances, and then in Shuttle after you get
to fly, these manifests and the sequencings of vehicles and the capabilities
of the facilities you're going to use. It is so complicated that planning
is a huge aspect of the program management job. You have to be watching
what's going on and taking care of problems, but you also have to
be focusing on all of the things that are going on simultaneously:
how they converge and how they keep you moving towards the goals you
want to achieve. Planning is just one of the biggest parts of program
Underlying everything that you've done these last almost 50 years
there's been a level of risk that has been attached to all the decisions
and planning, scheduling. If we could spend some time talking about
risk and risk mitigation activities and assessments—talk to
us about those aspects and how you plan. What’re the lessons
and the knowledge that we need to make sure that we are adhering to
the right level of risk?
You asked about risk management, and I'm glad, because right now the
subject of risk management is a very topical subject in the program
management community. It’s like people are looking for a solution
that can solve problems that we weren't dealing with before. I have
a little different perspective on risk management than some of the
very extensive activity that goes into finding ways “to do”
risk management. In my opinion now, but also in my opinion in the
past, program management is risk management. It's always been risk
management, and years ago there was no doubt in the way I operated
day to day, every day, on a risk management perspective of the program.
“What are the risks in my critical systems that are going on
right now? What are the risks in my schedule? What are the risks in
my budget? What are the risks that my people are adequate or not adequate,
or maybe about to change and I have to do something about that?”
What did we say a minute ago? Program management is planning. Well,
program management is planning, but program management is also risk
management. I think years ago before it was such a common talked-about
aspect of program management, it was nevertheless, at least at Johnson,
alive and well, and that's what we were doing, and we knew we were
Now that said, the new emphasis on program management and the new
tools and processes that people talk about for risk management are
very good. They're great additions to the fact that the program manager
needs to be conscious of risk management at all times, for a couple
of reasons. One is that these new processes and some of the capabilities
that are now software tools and capabilities to organize it in computers
or in documentation in an effective way—they're very useful
because part of the aspect of that is that it really gets everyone
in the program, and maybe even beyond the program, involved in participating
in risk management and thinking about it. So it provides a flow of
information to the program manager that is very useful, and it sensitizes
aspects of the program that might not be thinking about risk management
to know always that that is, in fact, important. I think it's very
important. I don't think it's new that people are starting to do risk
management. But it's made better by these things.
If you do have a risk management process for your program, the program
manager himself or herself needs to be the one that runs it. You can't
delegate somebody to go away and run my risk management for me and
then look at it every other month. People that would do that are sidestepping
the issue of risk management, and they're filling the square by having
a staff that's off doing something. I've seen all these tendencies
I've talked about. I think that risk management is good. I think the
processes are good. There's many choices now of software and books
about ways to do it in the program. As long as the program manager
does it, it adds to the benefit of something he or she should have
been doing all along.
You were there during [Space Shuttle] Challenger [STS 51-L accident],
and of course you were closely related during [Space Shuttle] Columbia
[STS-107 accident]. What improvements do you feel like need to be
done in some of the management processes that are associated with
risk, other than the one that you just mentioned? If the program manager
is the person that's responsible for risk management, what processes
can that person put in place that they're doing that job well, as
well as doing all the rest of the aspects of program management well?
How do they do it all?
Well, that's the art of program management. I don't know as much about
Columbia, because I've only read about how those things transpired.
But in the Challenger that I was heavily involved with, I think the
risk management processes were there. In fact, one of the things I
ask myself regularly about the Challenger is, “What could we
have done to prevent what happened?” The facts of what happened
have been well developed by the Rogers Commission and documented,
and I think they're complete. I don't think there's any hidden thing
that isn't lined out. We know what happened. But then you say, “How
did the management of that launch allow it to happen? Why did it happen?”
We had the right series of reviews, we had the right series of people,
we had the right trust, I think, between the people involved.
But, over a period of time, too many things converged right at that
time that the right processes let something get through. Because none
of us, if we could take everything we knew after the fact and looked
at it again, none of us would have allowed it to happen. When I ask
myself what might I have done that could have made a difference—the
big issue with the Challenger accident was of course the temperature
and some residual weaknesses in the solid rocket motor segment joints
that hadn't really received a lot of attention, and maybe we could
have found a way to know more about that. But it was really the temperature.
After we did not launch on the day before Challenger for a wind-related
problem, for return-to-launch-site aborts, we had a management review
at the Kennedy Space Center [Florida]. It was called an L-1 day review,
and we had all of the senior management related to the program, Center
directors and all of the project and program managers and all of the
technical support to talk about if we'd be able to launch the following
day. The issue was the fact that it was going to be so cold that night.
The weatherman brought in the fact that it was going to be 22 degrees
[Fahrenheit] overnight. None of us had experienced anything like that
before, but we didn't know. We knew that the launch mission rule was
31 degrees, and we talked about that on prior missions, and it was
pretty widely understood that was what it was. It was projected that
even though it'd be in the 20s overnight, that it would be above 31
degrees at launch time. There wasn't an immediate feeling that that
was going to be unacceptable.
The action of the L-1 meeting was to have each project go away and
look at all aspects of their technical project—the Space Shuttle
main engines, the Orbiter, the solid rocket motors, and of course
the launch facilities—and come back and tell us if you have
constraints, if you have risks, if you have threats. I think the question
was well-asked and understood, and we reconvened a few hours later
and they came back. Each of the projects felt that their part of the
system would be okay if we were above the 31 degrees for launch again.
There was a minor issue on the solid rocket motors. Nothing to do
with the joints, something down in the systems in the aft skirt. But
they felt it was not going to be a critical problem. There was one
instrumentation thing in the Orbiter that would be below its limits.
But they didn't feel that that would be a problem either. It wasn't
a critical problem. The whole team felt like it was all right to tank
and all right to plan to launch the next day.
Overnight things changed, and things changed that were not addressed
frankly. As you know from the details that are well known about the
Challenger, the solid rocket motor technical community in Utah became
wildly concerned when they heard about it, because they were concerned
about the joints, where there had been some problems in the past.
So the [NASA] Marshall [Spaceflight] Center [Huntsville, Alabama]
had a long series of meetings overnight to deal with that, and in
the end decided it was going to be acceptable. Even though the technical
community never agreed, the management decided it would be acceptable.
At the same time, there was water all over the launchpad for spraying
things down. Of course there's water for the launch time that goes
under, but water runs all up and down the gantry. The concern with
the Kennedy people was that the pipes would freeze and break and you'd
have just water spew out. So the Kennedy team dealt with that problem
by turning the faucets on slightly to trickle the water all over the
launchpad. Both of those things happened after our L-1 day when everybody
said there really aren't big issues and we're ready to go. The next
day when we convened, everybody went to their position in the Control
Center because we're now three, four, five hours before the count
is going to start, and everybody has a place to be and a job to do.
The senior management sits in a little place in the firing room and
everybody felt still ready to go.
These two big issues had been dealt with at a lower level overnight,
and they were not raised in the firing room or to the management team
or injected into the launch countdown process. The water was worked
by Kennedy, but it was worked at the Kennedy support level. Both of
those turned out to be bigger problems than we realized after the
fact. The trickle water caused a lot of ice on the launch pad—we
did have a review. I called a separate review and we reviewed the
ice on the gantry and whether it would have an effect on the launch,
particularly whether any falling ice would hit the Orbiter, which
would be terrible. We had buyoff from the technical community.
But it wasn't the senior management, it was the engineering at the
Mission Evaluation Room in Houston, and it was the Kennedy project
management at the Kennedy Space Center. In fact, Rockwell raised a
concern and said they felt we were adding some amount of risk. But
they also didn't call for a no-go. We thought this ice is more than
we realized was going to happen, but we accepted it. So that was done.
But we never talked about the concern that Thiokol [Morton Thiokol
Incorporated] had with the boosters. It was not known. It's really
hard to believe that, but it was not known.
We did, as we marched to launch, we called at least two delays to
let the day get warmer and warmer. We were originally going to launch
around 9:00 [a.m.], and we slipped it up almost to noontime, and things
were warmer and melting and so we launched. And of course we had the
accident. When I think about that and what could I have done, I sat
there in the firing room with Bill [William R.] Lucas, who's the head
of the Marshall Space Flight Center, and Stan [Stanley R.] Reinartz,
who's the head of the Shuttle Program at Marshall, and Jess [Jesse
W.] Moore, who was the Associate Administrator, beside me. We sat
there through the whole count and never once talked about the solid
rocket boosters being a concern. Everybody was still “to go.”
These are all people I'd worked with for years and had huge confidence
in. I felt like we were a well-integrated, understanding team working
together. These issues were not worked as maybe they should be. I
don't think we had enough information the day before at the L-1 day
meeting to not tank and count. I think we were right saying, “Well
okay, we ought to proceed.” I now wish that we had called a
management meeting in the next morning. It would have been disruptive
because everybody has a place that they go to and job to do, and the
countdown goes fairly quickly even though it's quite a few hours.
But we should have called that whole team together and talked about
the solid rocket motor, talked about if everybody was still “go.”
I think the discussion of the solid rocket motor would have come out,
and I think the discussion of the ice would come out, and people would
have seen it actually was a bigger problem.
I think the Kennedy guys found a way to think it would be okay to
go. It was okay. But the Rogers Commission assessment of that was
that it was more unknown and risk than we should have accepted. That
feeling really didn't permeate. If we'd had such a meeting—and
it would have required the Center directors and the Associate Administrator
and the various other very senior people to come. I wish I had made
such a meeting happen. But I didn't. It was not standard. You don't
do that during a countdown. But that time it certainly was necessary
if we were going to proceed.
The other thing I would do about the ice—I actually made the
decision to go with the Kennedy people on the ice, because I felt
it had been analyzed and it was going to be acceptable—which
it was, no ice hit the Orbiter. But there are other issues with the
crew access—to get in the vehicle, which sounded like that would
be all right, then also over to the escape buckets that would get
them away in the event of an emergency, and that side of the gantry
was quite covered with ice. That's something that was never brought
out. What I think about all of that is that since that was a known
problem that I was working, I should have insisted that I go out and
see it for myself if I was going to make a decision on it. That would
have been disruptive and nonstandard. But I could have done that,
and I wish I had.
You've had a lot of years to think about what you could have done.
Unfortunately, in program management life, schedules and budgets and
structures of how things are only permit you a small amount of time
to make those decisions. Like you mentioned, you rely on people. Which
leads me to my other question: you worked so closely when you were
at NASA with those teams of people, and then after three and a half
decades you moved to the contractor side. Could you share with us
the differences of working for the success of a space agency, but
where on one side you were the NASA person and on another side you
were a contractor? Share with us those differences and what different
lessons you learned from being on the contractor side than when you
were working on the NASA side.
Let me finish one more thing about the Challenger, because you correctly
said I had a lot of time to think about that, a lot of years. It's
still hard for me to believe that the people we knew and trusted that
were part of our team from Marshall didn't talk about it. They could
have said, “We've reviewed it, there were concerns, here's what
they were, we think it's all right.” They didn't say a word.
I think if any of us from Johnson had heard that we'd have said there's
In the contractor, I never did the program management. One of my lessons
about contractors that I would talk about still from the NASA experience
is that one of the other things you need to do as a program manager
is to team with your contractor: don't treat your contractor like
an employee or someone you've hired to do something for you. Treat
your contractor like a partner. Work with them, communicate with them.
Because they actually want to succeed just as much as you do, and
they want to contribute everything they can. It's a very important
aspect of good program management. I've seen programs where there's
a huge tension and distance between the contractor and the program
manager, and it's very hard to have a successful outcome, at least
in the schedule and timeframe you're hoping to achieve it. Maybe in
the end you finally hammer something out. I was lucky here again to
work with—I worked with Rockwell, I worked with McDonnell Douglas,
I worked with IBM. It was all just marvelous. They were just as much
a part of the team as anybody on the NASA side and worked at least
When we were talking earlier about all the different projects that
Lockheed had, the 3,200, and you were mentioning that people within
those projects and programs changed or they left the company. I know
that a lot of your colleagues that you started with were with you
a long time before they all moved on. What would you tell someone
that is trying to build a team with good program managers? How do
you improve issues or aspects that will improve management performance
where these people that are coming up as young and upcoming managers
will stay and spend long tenures with the space agency?
The kind of work we did and still do is very motivating to people.
I don't know many people who have been heavily involved in the programs
at Johnson on space vehicles and space missions that haven't been
so involved and so in love with what they do that they just want to
stay. They may want to work in a little different aspect of it, or
they want to find some way to learn some more. But they certainly
don't want to just drift off and go somewhere else. The people that
I knew that left mostly left because they'd done a pretty long career,
and they felt now it was time to step aside.
What do you tell the people that want to move into the space exploration
business? Why would you encourage them to do that?
There's a lot of different aspects of space exploration. What I've
been talking about are manned programs, but you can work in space
exploration, and you don't have to be a manned enthusiast. We do so
much with robotic missions now that are so good for science and so
good for technology that if you're an engineer and you want to work
on something meaningful and something that's at the forefront, it's
just one of the best places I can think of to work on it. I think
there's still many engineers that want to do that and will do that.
The pipeline people talk about maybe not being as strong as it was,
but I think it's full of excellent people. They're motivated just
like the ones that I've talked about here that I worked with in the
I know that you brought some papers with you. I was going to ask if
we wanted to look through some things or some other comments and aspects
that we haven't talked about yet.
Mostly I was making notes on what you asked me. The first question
was, “What are the best practices and processes as I see in
program management?” I think I ticked those off. One is needing
and wanting to be engaged in detail in the technical aspects of the
program. Doing rigorous configuration control. Doing the software
requirements in English so the broader community can understand in
detail what's going to be put together. Listen carefully to presenters
and make sure they're telling you a story that you can buy into. I
talked about Chris Kraft's management style, because I think from
my experience it's pretty unique. I'm sure he's not the only person
in the world that ever did that, but it was well done. In the end
you have to do all these things on the job if you're going to get
good at it. You can learn them in the classroom or talking to people,
but you have to go do it before you're going to be ready to really
One of your questions is about memorable days. We talked about the
launch of Challenger, and that was one of my most memorable days.
But there was another very memorable day for me, and that was the
launch of the next flight two and a half years later in Discovery.
That mission was STS-26. During the time that we went from all the
things that we felt so terrible about with Challenger to the time
we launched Discovery—during the Challenger launch I had been
the Program Manager for Shuttle at the Johnson Space Center and Jess
Moore was the Associate Administrator in Washington, that was the
overall Shuttle person.
After the Challenger I was asked to come to Washington [NASA Headquarters,
Washington D.C.] and be the Director of the Program, which was a job
that didn't exist during the Challenger. Moved some of the things
that were centered at one of the Centers, at Johnson, to Headquarters,
so it would have more comprehensive authority over all of the NASA
Centers involved. I was the Director of the Space Shuttle Program.
Really I was the Director of the National Space Transportation System,
which is the name that the Shuttle was called in those days.
After we finally got through the failure analysis and sorting out
what really happened with Challenger and where we had to take care
of those problems, I realized that was not, maybe, the only weak system
in the Space Shuttle. I set up a series of formal reviews looking
at all aspects of the Space Shuttle for risk management, for weaknesses.
In fact, for a lot of known weaknesses that we'd agreed to live with
up to that time.
There were a number of things that people knew ought to be improved
prior to the first flight of the Shuttle on Columbia, but because
the first flight was important to get off, the program had reviewed
various things and said, “Well, we're going to have to fix this
downstream, but we can go, the first flight, and we'll get it later.”
Almost every subsystem area in the Space Shuttle had little things
tucked away that they knew ought to be improved. But once the first
flight went, then the second one, then the third one, and there was
never a time or the budget to step up and say, “Well, we got
to go back and stop and fix all these things that actually we ought
to do to make the Shuttle completely right.”
So after the Challenger I set up this series of reviews out of the
PRCB meeting that I ran to look at everything and bring those things
in and talk about them and prioritize them. That wasn't just my idea
alone. That is exactly what I witnessed George [M.] Low doing after
the Apollo fire. George Low did exactly the same thing with the total
Command Service Module and Lunar Module during the time we were recovering
from the fire and made extensive changes to those two vehicles that
made them better. Didn't have anything to do with the fire in particular,
but it had to do with risks and weaknesses.
We did that on the Space Shuttle after the Challenger, and we made
over 250 changes to the different elements of the Space Shuttle, including
software. Some of them were software changes. Some of them were different
changes for emergency landings, but most of them were different hardware
things that the subsystem managers already had in their little notebooks
that really ought to get worked on. We approved those changes, and
most of them were for first flight after, for STS-26, but some of
them were too big for that. We approved them but gave them license
to come in later downstream, like the new turbopumps on the Space
Shuttle main engines that came into play [six] years ago. They were
Pratt & Whitney turbopumps for the Rocketdyne engine that were
more robust. They were approved by this process after Challenger,
but it took a number of years of development and testing to get them
ready. This is the timeframe they were set in place. Of all those
changes, only about five of them dealt with the solid rocket motors.
They were big changes, but the cause of the Challenger that we had
to fix—only about five of them.
There are a couple of other things that were memorable. During the
time I was the Orbiter Project Manager, we completed the fabrication
of Discovery and of Atlantis. I had the opportunity go out and give
the acceptance speech at the rollout for NASA. It was quite a thrill,
particularly for Atlantis, because at that time Atlantis was thought
to be the last Orbiter and the workforce there finished their job.
It was good. In fact, I'm told that the speech I gave that day was
used in the Rockwell program training and inspirational material that
they used for their employees downstream for some number of years
after that, because it said so many right things about what they did.
Palmdale [California] continued as a repair and refurb site for the
Orbiter, but at the time of that speech it was thought to be the last
construction. Then Endeavor was approved and it came along later.
Two other memorable days early on. The first flight, STS-1, had been
delayed several years by the time we got to it, for a variety of problems.
Mostly the TPS [Thermal Protection System] on the Orbiter. But we
got to the countdown finally, and it counted down, and that timeframe
I was still in charge of the avionics and the software. We got to
T-20 minutes, which is the point where the backup flight system that
supports the primary avionics comes online, and it didn't come online.
It didn't initialize. It's a system that was made by Rockwell and
the primary system, with its four redundant strings of computers,
is all by IBM, and so everyone was saying, “Well, these Rockwell
people, backup software is not good.” It turned out that actually
the initialization of that came from the primary system, and it was
an IBM problem. It was fixed overnight and we launched, but it was
quite a thing to get to that point.
One of the early flights we had—with the four computers on board,
there's two-fault redundancy: you can have one fault and continue
the mission, you have another fault and it's fail-safe—you've
got what you need to come home. But we had two computers fail in the
middle of that flight. It's the only time it ever happened on the
Space Shuttle, that I know of. That was some amount of concern because
they weren't too far apart. They were a little different scenarios,
but there again we got to bring one back on and things went on and
it was good. There's a lot of memories that you could talk about that
probably aren't written very extensively anywhere anymore, just some
people remember them.
Those are good ones.
Coming in that same first flight, STS-1, the big thing for me with
the avionics was—in those days I hadn't done much with the ascent.
The software that controls the main engines was a Marshall product,
and it was part of the engines, and I hadn't spent a lot of time being
engaged in ascent. We'd spent a lot on reentry, because when the Shuttle
comes in, it starts in after it deorbits, and there's no air yet,
and so its attitude to keep it going right is controlled by the little
thrusters. Then it starts to pick up atmosphere and the thrusters
don't have as much control because the atmospheric pressures are quite
strong, and you start using the aerodynamics.
But there's a point there where the two have to be blended, and there
was no way to test that except fly it. It had been analyzed to death
and tested in models and things, but I had never been quite confident.
We knew how much margin we had and how risky that was. We did the
very best that could be done without flying it, but now we were flying
it, and we had John [W.] Young and Bob [Robert L.] Crippen on board.
So another memorable time was when I was sitting there in the Control
Center, in my avionics little job, and that came out of blackout.
It turns out that the margin was there. There was good margin. It
had been well-analyzed, but we couldn't prove it to ourselves very
well until we flew it.
That was another good day.
Another good day. The other two things about program management I
meant to mention: One—the program manager needs to know that
he or she is in charge and they are accountable and responsible for
the program. Program is not a democracy. There's some feeling that
you get everybody together and vote, and that's not the way it is.
In the end, the program manager needs to hear everybody, give everybody
their say, weigh all of the things with the people that they respect,
but then in the end they have to make the decision. It's not a democracy.
We've been through a period, some within NASA, but to a great extent
in the Department of Defense [DoD], about managing programs with integrated
management teams. What you really do is you break the program down
into all these little product centers that each manage an aspect of
the program, and they have their own schedule and budget. That's a
pretty good concept. The thing I always thought about it when it came
online is that that's what we always did at the Johnson Center. We
always had people that were in the program, but we had the technical
disciplines, we had the flight disciplines, we had the budget people
all together. I think we did it.
When they changed the Space Station Program from Freedom to the International
Space Station, they had an independent panel review [on] Freedom and
why its schedule and its budget had the issues it had. They criticized
Freedom quite strongly because we didn't use integrated program management
teams in the way our processes were set up. That was a time when that
was coming on to be a big way of doing business in DoD. It was the
new thinking in how to do programs. We just didn't call them that—that
is the way we did program management. But to their language and what
they could tease out of what people told them, they didn't sense we
had—integrated product team is what they called them—they
didn't sense that we had it. It was a big criticism, and then they
started it. There's a couple of risks if you use that management style.
It's a good style. DoD has used it a lot. I think it's not used as
broadly now maybe as it was at one point in time, but it's still extensively
You've got to be careful on those integrated product teams, also,
that someone is in charge of that team and is accountable and responsible.
If you make it just a collection of people who all have inputs and
you try to run those as democracies, it sounds like what you were
trying to do, everybody gets a voice, but in the end somebody has
to be in charge. You do that across the integrated product team structure
so that each one really has a responsible accountable person, and
it's a good way to operate. But then you also need to have one integrated
product team at the top of that. Someone needs to be in charge of
that. Because otherwise they won't fit together and dovetail. That's
an aspect of program management that gets a lot of attention, and
I don't know that everybody would think about what I just talked about,
but I think it's important.
Two other things about doing program management: I talked about being
in charge and being accountable. But, also, the program manager can't
do everything. You have to have good people that you trust and have
confidence in run the key aspects of the program for you. You have
to stay in close contact with them and know what they're doing. You
have to have people you can count on. Let them do their job, just
like I was talking about Chris Kraft with the program manager. That's
important. Again, that's something that was rich in the programs I
did. I always had good people working for me that I could count on,
and they did great things.
One final thing—it's a little like the mentoring. The other
thing you ought to do is regularly seek the advice of people outside
the program that you have respect for and you think could give you
help. There are senior people in your organization. There are other
people that have like responsibilities and jobs. You ought to contact
them and be in touch with them and use what they tell you.
Good idea. A lot of good information.
You asked, also, about other people you should talk to. Two of the
best that I ever worked with, you can't talk to anymore. George Low
and Sy [Seymour] Rubenstein with Rockwell were two of the very best.
Also Bill [Howard W.] Tindall [Jr.]. Bill probably isn't categorized
as a program manager, but he was one. Then the other people—you
must have a list that probably is most of this or better, but you
must talk to Chris Kraft about this. He was in charge of most of the
things at the Center that came to be and were successful. Aaron Cohen
is not well, but he's a very knowledgeable person in this, and he
would tell you things about doing it that are important. Bob Thompson
A fellow I worked with a lot: Dick [Richard H.] Kohrs. From that same
organization and era: Owen [G.] Morris. In this software area: John
[W.] Aaron. Ron Dittemore. You also ought to talk to Bob Crippen.
There're a lot of astronauts who've done a lot of great things. When
I think about program management though, Bob is the one I think most
broadly has a real handle on what it takes, what's important. There're
a lot of people at Marshall, and I could give you a list of names,
but I couldn't prioritize them for you well. But one I think would
be good to talk to is Bob [Robert] Lindstrom. And J. R. [James R.]
Thompson [Jr.], who now is with Orbital Sciences. Lives in Huntsville,
but he works for Orbital up here in the DC area. That's the list I
had. I'm sure there's more.
Thank you for all your information, and I'm sure we'll be talking
in the future.
You asked about notes and things, and I'm not sure what you're looking
for there exactly.
We do have a JSC History Collection, and that is used quite often,
especially the last couple of years as Constellation has been up and
going. One of the goals of the Chief Knowledge Officer is to try to
make sure lots of papers, documents—whatever information that
might have been important to someone along the way of programs—makes
it into that archive. Sometimes people left their files at the Center,
and they made it where they needed to go. A lot of that's, of course,
at the National Archives. But she's wanting to see if there are people
that might have personal papers. There are some that have taken their
papers. Mr. Bond, Aleck [C.] Bond, has given his, and Carl [R.] Huss's
papers are there.
I don't know that my papers are that organized. I don't have a diary
kind of thing on the programs I managed, which almost sounds like
that might be what it would be.
It could be. The archivist that's there is Shelly Henley Kelly, and
she's gotten boxes—I don't know if you remember a gentleman
named Mr. [Louis] Leopold.
We've talked to him. Last time we were there, we put about seven or
eight boxes in the back of the vehicle and brought them down to the
archives for him. They're just papers that have been put in a box,
and they may not get to right away, but at some point Shelly will
go through them and organize them and label them and be able to put
stuff into the database of what's there. But in the meantime they're
kept someplace. Bobby [Robert A.R.] Parker—when he left JPL
[Jet Propulsion Laboratory, Pasadena, California], he sent his stuff
down to the history archive here in Houston. Same thing. Took her
a while to go through all those papers. She's trying to at least collect
them so that they can be there, and people can at least go through
and start making use of them.
I might look through my boxes, because like I say, it's not very well-organized,
and some of it's not connected very well. I did come up with one thing,
though, I thought of right away. The Challenger was not the only launch
in January of 1986. The STS-61C launched earlier in January, and some
of the problems we had with the launch attempts that ended up so badly
with Challenger, we had in spades with STS-61C. You don't probably
read much about these things anymore. The thing you'll read is that
we scrubbed six times before we launched on the seventh attempt. I
wrote a memo after that happened, and this was to the Shuttle team
about the characteristics of all of those scrubs and how avoidable
they would have been if we'd just had things synched better some way.
So I brought that.
Great. Thank you.
Because if I was a program manager and going to be into that kind
of thing, that might be a series of thought-provoking things.
Is it all right if we scan this in and attach it to your transcript
as part of this?
Sure. You can have it too. You can keep it.
You started off asking about Columbia and Challenger. This is something
I just collected around 2003. This is a little article by a man that
was working on the O-ring analysis at Thiokol back then. It talks
about a common cause of the Challenger and the Columbia accidents.
It's not talking about flaws in management style as a common cause,
which has been pretty well talked about. This is talking about Max
Q [Mazimum Dynamic Pressure] and upper-level winds and how they also
played into both of these, or potentially did. It's interesting reading,
and I haven't seen anybody reference it. But that was in the AIAA
[American Institute of Aeronautics and Astronautics] magazine, Aerospace
America, and I think it was in 2003, which is not long after the Columbia.
Well good. This'll be great information to add as well.
I don't know if you want my resume. This is the detailed one. It's
so I can keep track of it. No one would read it, but it's complete,
which is nice.
I'd love to have it. Thank you. Because the one I have, as you know,
stopped a few years ago.
I had to have one that was about that long for Lockheed, because no
one would do anything with something like that.
It gives us a lot of good background information, so I thank you for
bringing all of these things and for spending the morning with us
with such great information.
Two more. There's a lot of books that were written about Challenger,
and many of them were written pretty early. There was still a tremendous
amount of emotion flowing around and facts not well sorted. I think
some of them are just off track, but there's a couple that I think
if you were a program manager and you wanted to read about some of
that. There's a book written by a guy in Scandinavia. The title is
No Downlink. Do you know about that book?
No Downlink is the title. It was written by Claus Jensen in 1993.
It was translated by Barbara Haveland in 1996. His accounts in there
are very factual. He doesn't draw a lot of conclusions, but occasionally
he does. I won't say all of his conclusions are exactly what I conclude,
but it's pretty accurate. It's probably more readable than the Rogers
Commission stack of books.
Then the other one that has seen a lot of popularity is Challenger
Launch Decision [The Challenger Launch Decision: Risky Technology,
Culture, and Deviance at NASA ] by Diane Vaughan. It deals extensively
with the psychological aspects of management and Challenger. Again,
I don't know that her conclusions throughout would synch with what
I conclude, but it's a very thought-provoking analysis and a good
book to maybe spend some time with.
All right. Thank you so much for coming in.
It was my pleasure.