NASA Johnson Space Center
Oral History Project
Tacit Knowledge Capture Project
Edited Oral History Transcript
Interviewed by Jennifer Ross-Nazzal
Houston, Texas – 23 April 2008
Ross-Nazzal: Today is April 23, 2008. We are in Houston, Texas, to
speak with Loren Shriver, who is currently Vice President for Engineering
and Integration and the Chief Technology Officer for the United Space
Alliance. This interview is being conducted for the Johnson Space
Center Tacit Knowledge Capture Project for the Space Shuttle Program.
The interviewer is Jennifer Ross-Nazzal, assisted by Rebecca Wright.
How did you first come to work with the Space Shuttle Program, and
could you tell us how your duties have evolved over time?
Sure. My association with the Shuttle Program goes way back to 1978,
when I was stationed at Edwards Air Force Base [California] as an
Air Force test pilot. I was working on the F-15 test project at that
time. Actually, in 1977 was when NASA put out its call for applications
for astronauts and mission specialists for Space Shuttle Program.
Of course Edwards was all abuzz because the people who had been the
flight test engineers had gone through test pilot school, as had most
of the pilots out there, so that looked to be part of the qualifications
that NASA was looking for. So [I] and about 500 of my close friends
out there all rushed to put in applications for that class that was
due to start then in 1978. In the latter part of 1977, we went through
the interview process and screening processes, both the Air Force
and the NASA's process.
Things must have turned out right, because I got a call in January
of '78 wanting to know if I was still interested, and I said yes.
July was the reporting date. So, July of '78 was the beginning of
my association with the Shuttle Program and all the Shuttle operations.
That was from the point of view, of course, coming into the astronaut
office brand new, class of 35 people. There were several astronauts
already in the office that had come off of the Apollo Program, and
through the Apollo-Soyuz Program, and the Skylab Program. They were
there. They turned out to be part of our mentor structure, and our
other instruction, systems experts within the astronaut office. We
learned an awful lot from those folks who were already there.
But the first year that we were here was mostly, gosh, classes and
systems lectures, and some training in geology and space physics and
all those things that most of us in our piloting careers -- I had
not studied any of those things. That was really an interesting year,
the astronaut candidate year. When that was done, then we became eligible
for assignment to a crew, and also eligible to do other things within
the astronaut office, and my first responsibility was -- we call them
a “Cape Crusader.” It's a person who spends a lot of time
at KSC [Kennedy Space Center, Florida] from the astronaut office,
helping them to develop a good set of procedures and processes for
when the crews come down and are ready to fly a mission: all the procedures,
the switch list, the configuration of the crew module cockpit, and
all that sort of thing.
I spent a couple of years prior to STS-1 working that kind of stuff
at KSC with the KSC workforce and the KSC components of the Shuttle
Program. Lots of meetings on countdown timelines, endless meetings.
We just went over and over, which is a good thing. It was absolutely
required. Very meticulous laying out of the timelines and the sequencing
of events, and when the crews needed to be there and what needed to
In that role then, I also was assigned as the first Space Shuttle
Astronaut Support Pilot, we called it in those days ASP. There was
an astronaut member of the closeout crew, there still is today. I
know they use a lot of the same procedures that we developed. We helped
strap in the crew, configure the cockpit switches to the necessary
configuration, and in general the responsibility was to get things
ready for the crew coming up in the crew [module]. The closeout crew
was already all there and received the crew, got them strapped in,
got the hatch closed and checked, and the pressure checks done on
the crew module. I had what I think was a very neat assignment, to
be able to do that the first time and work through all those procedures.
I know they've changed some since then, but some of it's still the
same even today. That was a two-year assignment where the main thing
that I did was coordinate with KSC.
STS-1 launched, and I promptly flew to White Sands [Test Facility,
New Mexico] to be available at White Sands in case there was a need
to land there as, again, an Astronaut Support person. As John [W.]
Young and Bob [Robert L.] Crippen flew that flight, it became apparent
that things were going OK and they were going to be landing at Edwards,
so George [W.S.] Abbey [Director of Flight Operations] called me up
and said, "Hey, go on out to Edwards now." So I left White
Sands, went to Edwards the morning of landing, and when they landed
then, I was available. Since I had this really good familiarity with
the inside of the cockpit, I was one that went in and helped get things
in the proper configuration for the post-landing part. That was a
lot of vehicle orientation, a lot of Shuttle-specific things that
I did in those first couple of years after the astronaut candidate
Then after STS-1, I was assigned as a Chase Pilot on STS-2, had a
couple of other assignments within the astronaut office. I was also
assigned to monitor the building of [Space Shuttle] Challenger. The
next vehicle coming off the line was being built, being assembled,
in Palmdale [Rockwell’s Plant, California], and so, I think
because of my familiarity with the systems and the vehicle at KSC,
the office assigned me to kind of monitor what was going on out at
Palmdale and make any required inputs. Also, if there was the need
for a crew interface or a crew to come and help perform a test or
something that they were doing out there, I would arrange for that
sort of thing to happen as well.
Of course I wasn't spending all the time down in Florida. When I was
back here you would catch some training sessions in the simulator
from time to time, [and] the single systems trainer. All that early
training stuff that you could do before you were assigned to a crew,
we were trying to fit all that in as well and the Shuttle training
Then after STS-2, I was assigned to the night landing development
project, that's where we developed the landing aids for the night
landings. We went through several different test configurations there
on what we thought would work. STS-8 was the first night landing,
Dick [Richard H.] Truly's flight. We kept inviting him and Dan [Daniel
C.] Brandenstein, [who] was his pilot, to check the configurations
we were coming up with and get their opinion, not just them, but a
lot of pilot astronauts in the office. That was kind of an interesting
and neat project, spent a lot of time out at Edwards Air Force Base
doing that, because the first night landing --folks wanted it to be
on the lake bed, so that's what we were doing. Although we used the
runway out there, too.
Of course, still more training going on. Finally, I was assigned to
the crew of what was going to be STS-10, and as we started training
for that there were some issues with parts of the equipment that [was]
going to be used, so we kind of got delayed, to put it mildly. Matter
of fact, the mission really kind of came off the manifest for about
a year and a half, two years, and then resurfaced. By that time, we
had adopted the Shuttle mission nomenclature that is difficult to
figure out. It became STS 51-C, and we ended up training for that
then, and that finally flew in 1985. Again, the progression of some
jobs in the astronaut office are all associated with developing certain
capabilities for Shuttle operations, and then eventually training
took over pretty much your whole time available when you were training
for the mission-specific stuff. We flew STS-51C in '85, that was a
DOD [Department of Defense] mission, so can't say much about it.
But we came back from that -- again some assignments internal to the
astronaut office, systems development stuff mainly, new capability
things. Started training, got assigned fairly quickly to a second
mission which probably would have been '86, '87 some time, but of
course then Challenger happened in '86. So when Challenger happened,
basically, the schedule got set aside and lots of fixes, of course,
started, through the fairly long process of basically retooling the
SRB [Solid Rocket Booster] field joint, the one that caused the problem
with the O-ring. That got completely redesigned and tested before
we could go fly again.
We did a lot of things. I worked on the [spaceflight safety panel]
that I chaired for a while, an overall Shuttle Program safety team.
It even had Agency participation in it. Worked a lot with the [Ellison
S.] Onizuka’s family during the aftermath of Challenger, helping
them get through that process and all the things that came to happen
after that. In the meantime, trying to help out with the recovery
efforts. Again, a lot of the processes got re-looked at, reinvented,
improvements made all across the board. It wasn't just the fixing
of that booster field joint. There were a lot of things that were
Then again, when operations picked back up after Challenger, got back
into pretty much training flow right away, was assigned to STS-31
as the Commander. I was the pilot on the first flight. On STS-31,
I was Commander. STS-31 was the Hubble Space Telescope deployment
flight. So we got started training for that. Then, after we flew the
Hubble flight, I got reassigned pretty much right away to STS-46,
which was Eureka. It was a European Space Agency payload, a free flying
payload with lots of experiments mounted on it, and then it also had
the tethered satellite on it for the first time. We had all kinds
of interesting training on trying to figure out what the tethered
satellite was all about and how it was going to act and behave, so
a lot of process stuff in there. Do you want me to keep going on assignments
If you want to talk about some of the other assignments that you worked
on in the Shuttle program, you can.
Sure. After I flew the third flight, that was in 1992 when I came
back from that --quite honestly, the training routine for each mission
was fairly long, a year or more length. So you start thinking about,
“Well, am I going to keep doing this or what? Is there life
after being an astronaut?” I was assigned as the Deputy Chief
of the Astronaut Office after the third flight, but I began to look
around to see what other opportunities might be available. Brewster
[H.] Shaw had left the Astronaut Office a while before and had gone
to KSC as kind of a Deputy Program Manager, [for the] Space Shuttle
Program Manager down there, working for Bob Crippen. It ended up that
they were getting ready to do a rotation, and Brewster was going to
come back to Houston and become the Space Shuttle Program Manager.
So he was starting to look for a replacement for himself down in Florida,
and he talked to me about it, and I said, "Yes, I would like
to do that."
That's a great transition. It was a Space Shuttle Program position,
so I was still directly involved. Again, I describe it as kind of
a Deputy Program Manager position, which it was, but we gave it a
new name. We called it Manager of Launch Integration. But it's a Space
Shuttle Program position in Florida. I moved to Florida and became
involved in that job, and that was quite a different aspect on Space
It's one thing to be in the astronaut office and be involved in all
of that operational stuff from the flying point of view, but there's
a lot of stuff that goes on “behind the scenes” that the
people in the astronaut office I don't think are even aware of, in
terms of the huge amount of preparation that goes into each flight.
You learn a lot about what goes on, but there's still many, many operations
-- these are the program and project things that have to happen in
order to make a program like the Space Shuttle Program work, because
it involves thousands of people around the country.
Going into that job, of course that was like taking this new fire
hose and drinking out of the fire hose, trying to learn all of the
things there were to learn about in terms of how all of this stuff
came together. Each one is a precisely controlled piece of equipment
by its own set of engineering specs [specifications] and its processing,
and how it got ready, and what all got done to it. Each piece is that
way, and then at KSC, this Manager of Launch Integration job was involved
with making sure all of those individual components then come together,
get assembled properly. You set out a timeline for each mission, and
there's a sequence of events that needs to occur, and there's a sequence
of major reviews on exactly what's been done and what the outlying
things are for each flight that comes along. Very, very much a different
focus than the astronaut office part of it was. You really get into
the nitty-gritty detail of what it takes to run a program.
So I was there for -- I was in that job for about four years, I guess,
altogether. We flew I think about 32 flights while I was in that job.
That was from mid '93 to mid '97, August of '97. We flew a high number
of flights, we had a lot of good things that happened. We were not
flying the rendezvous flights to the Mir [Russian Space Station] yet,
or the [International] Space Station. None of that stuff had gelled
together yet, so it was mostly the science missions and all the things
that were going on during that period of time. I learned a lot from
that tour, and I learned a lot of things I just was not aware of,
even being in the astronaut office and flying the machine. There's
just a lot of detail that in the back of your mind, you know it probably
goes on, but you just were not familiar with it until [getting] into
that job. A lot of coordination involved with the other human spaceflight
Centers and the other parts of NASA, and then all the contractors
around the country that build the equipment and get it tested and
Then in '97, Roy [D.] Bridges [Jr.] had become the Center Director
at Kennedy, and he asked me if I wanted to basically be a Deputy Center
Director for the technical aspect of things that are done at KSC.
Basically, it was a Deputy Director for Launch and Payload Processing,
which just meant for the technical things that go on in KSC; I was
the Deputy Center Director for that. It included, by the way, the
expendable launch vehicles that they operate for NASA. They procure
and get them launched, and so that was yet another interesting and
new thing that added to the experience base while I was down there.
Again, a different focus than the Shuttle Program job, but certainly
still very active in both human spaceflight and in the unmanned spaceflight
part of what NASA does as well, and a new exposure, a lot of the same
kind of things. In addition to that, we were trying to set up a technology
center at KSC for spaceport technology and to help KSC find its niche
in a certain area of technology where they had a need to develop technologies
in spaceport processing and spaceport operations, because that's what
Then in 2000, early 2000, I rotated out of NASA. While I was at KSC,
I was a NASA civil servant. During the astronaut years, I was on active
duty in the Air Force assigned to NASA, so kind of a dual status there.
When I went to KSC, I retired from the Air Force and became a civil
servant, SES [Senior Executive Service], and then in 2000, I left
civil service and became a part of United Space Alliance, and went
right back into Shuttle operations as a Deputy Program Manager for
the Space Shuttle part of USA [United Space Alliance]. My responsibilities
were largely the same as in that NASA Shuttle program job at KSC,
doing almost the same kind of stuff, except from USA's point of view
on what it needed for Space Shuttle operations. But [I was] directly
involved in day-to-day decisions that USA has to make in processing
the vehicles, all the various work that we do and we have a considerable
amount of work, of course, that we do for the Shuttle program. [I
did] that for the first five years or so, up until about a year and
a half ago, and then we kind of reorganized internally in USA, and
that's when I became the Vice President of Engineering and Integration
and the Chief Technology Officer, which still is very intimately involved
in human spaceflight operations. That's primarily what we are, is
a space ops [operations] company. It's engineering and integration
aspects of people working to do human spaceflight.
I now can say that I have a 30-year career, from '78 to 2008. I have
a 30-year career in basically human spaceflight operations, and the
program during that whole time has been the Space Shuttle Program,
with Space Station starting up and now Constellation [Program] coming
along, and people trying to work the transition of whatever processes
and concepts and lessons learned from the Shuttle Program that directly
transfer --those are the kinds of things that we're trying to help
identify as well. That's at least a high-level overview of the career
progress through that 30-year period.
I think it's hard to give a very brief introduction to your work in
the Space Shuttle Program.
I know it's longer than you probably wanted.
No, it's fantastic actually. We like those sort of details. You've
talked about some of the management positions that you've been in,
and reflecting on those experiences, could you share with us what
you think are the best practices or sound processes that benefited
you during your tenure in the Shuttle Program?
Sure. Well, I think the best practice overall is the fact that there
is so much process detail. We typically refer to it as the COFR process,
the Certification of Flight Readiness. COFR is the short acronym.
What that does is put just a huge amount of rigor into every activity
that takes place, all the way from buying the raw materials, to the
production of a component, to the integration into the system, and
the system into the whole vehicle. That whole process is conducted
under the guidance or under the specifications of this COFR process,
and so it's very detailed. It has specifications involved. There's
processes involved that are proven, and they produce a good product.
It's a very strict adherence -- signatures on the signing line from
people who have been involved, saying, "This was done this way,
and it's done properly, and we're certifying that this thing is going
to work the way you wanted it to work." I think that's been the
strong point throughout the program.
I think I would have to point to that as the number one thing that
causes success, is just the minute attention to detail and attention
to the data that comes in, both from the operation during an actual
mission, what's going on, and then the data that comes in from the
assembly process, the build process. All that stuff is looked at and
carefully scrutinized for abnormalities. Things that look different
than they did before, trending, that kind of thing. That's a huge
part of it.
The other part is that -- it became apparent very early, both as an
astronaut in the astronaut office and then as basically a Deputy Program
Manager, or the Manager of Launch Integration in Florida, we're hugely
dependent on other people. There's so many people involved. This thing
about trust, you've got to have trust that people are doing their
jobs correctly and following the procedures, following the specifications.
If you have a problem with any of that, you're probably not going
to last very long in the human spaceflight operations business, because
it is all about people, and the way people operate, and the way people
build trust with one another. If you didn't have that, it just wouldn’t
work, I don't think. I guess call it a best practice, or whatever,
but the COFR process, this system of trust and integrity that goes
into the building of everything.
There are other practices or other things, of course, that make it
all work. The simulation and modeling that are done are pretty dog-gone
important. Mentoring, mentoring is always important. Mentoring or
OJT, on-the-job training, are a big part. People just don't come in
from the outside, or come in from being a college graduate -- they
don't step in the door with this wide range of knowledge. It takes
years to develop that, so the idea of having the mentors around, those
people who already know quite a bit, who have been around the block
and learned the lessons, maybe the hard way. There's a lot of that
that goes on in all those positions, the ones that I had especially.
That, and whether it's a best practice or not -- just people who have
good, sound technical knowledge of what they're doing. People who
take pride in maybe being a little geek-ish, if you want. It still
takes that kind of person to, I think, be effective in an industry
or in a calling that requires so much attention to detail, and so
much intimate knowledge of what's normal and what's not. That technical
expertise I think is just really, really important, and for my 30
years in this program it's always been stressed, and it's always been
a big deal. I think those are the highlights.
So many times at work we face challenges. What are some of the more
memorable challenges that you faced, and what were the lessons that
you learned from those stumbling blocks?
It's a challenge a day, or more, sometimes. Obviously, a couple of
the biggest challenges we've had in the Shuttle Program have been
Challenger and [the Space Shuttle] Columbia [STS-107 accident]. Those
were huge challenges. Folks obviously thought they were doing a good
job, obviously thought they were doing the right things before those
accidents happened, but as the teams investigated those accidents,
it became quite apparent that there were some things that just weren't
being done as robustly as they could. People were ignoring data, things
So right away, you've got to go back to the basics that says, "Hey.
First of all, look at the design. Is the design healthy? Is it not?"
In the case of that SRB joint, it probably wasn't all that good a
design, so they redesigned it and they really put a lot of attention
into it. Then they paid attention to the test data that came out of
the redesign, and it said, "Yes, it looks like we've done the
right thing here." It's a huge challenge coming off these major
accidents like that, because basically you're reinventing a lot. You're
taking everybody's comfort zone on what they were doing and saying,
"That apparently wasn't good enough. We need to step up a little
bit, a little bit more. We need to be more vigilant, we need to be
better communicators with each other."
By the way, I think that is a large part of both accidents, the slipping
of communication, the tendency to want to do your own thing and look
at it and say, "Yes, it looks OK. It's doing all right."
Even though some of the data might be beginning to creep in and say,
"Well, this is a little bit abnormal here." So I think constant
communication, interplay with other folks, it's always a challenge
to do a good job of that. It continues to be a challenge today, and
it always will be. I think it's kind of human nature. But very, very
important in our business to be totally open and communicate freely.
Every little detail, sometimes gory detail. But I think right now
people are in the mode of being very open and trying to overdo it
rather than not do enough of it.
Can you share with us some lessons you've learned in regards to improving
Yes. The communication thing I was just talking about is one of those.
When you take technical people who take great pride in their technical
knowledge and what they do, sometimes they get a little introverted
or whatever you want to call it, and say, "Well, I know what
I'm doing. I know what's going on. I don't need a lot of help from
the outside to do my job." It's almost a sense of pride to be
able to do things in an individual manner. Well, that's probably not
the best thing to do in this environment, so you've got to learn to
Especially after Columbia, there was a huge amount of effort devoted
to training people in management positions to be more open and more
inclusive of other opinions, other ideas, even totally dissenting
opinions from what the majority of the community might have on a subject.
Welcoming those points of view that were a little bit tangent to everybody
else's. Because, quite frankly, maybe there was too much groupthink
in the first place that led you into the trap of overlooking some
of the data. There was a lot of emphasis put on team training, communications,
decision making, that sort of thing. That, I think, was a very good
thing to do.
It was a course of action specifically designed for the management
echelon to do a better job of being inclusive of other data and other
opinions, and drawing on the entire community for inputs to and options
that you might follow in order to solve a problem. There's almost
always more than one way, always more than one solution. So technically,
getting a lot of people involved is a way to hopefully arrive at a
best solution, one that you know will work for the long-term. There
was a tremendous amount of effort put into that. Same thing took place
after Challenger, although I was still in the astronaut office then,
so I probably wasn't exposed to as much of it as I was in the post-Columbia
Let's see. There's a number of things as a manager that you just kind
of learn as you go along. One was when I stepped into that job at
KSC. You get used to working with your crews, your assigned crews,
and your training teams, which are fairly close-knit groups of people.
When I got into that job, the whole world exploded, “You mean
I have to talk to all these people?”
“Yes, you do, they're all part of the program.” So relearning
some of the basics of program and project management, there's always
new ideas, new ways of doing things, and NASA's always been pretty
strong on proper program and project management in the way things
get done. Again, it's part of the whole process. There's always been
continuing emphasis on that, and I think it helps managers.
Just because you're a good technical person, a good engineer -- you
can be the most whiz-bang engineer around and really know a lot of
technical detail. Doesn't necessarily mean you're going to be a good
manager or a good program manager, or a good manager of people. There
are some other qualities involved there other than just looking at
technical things and solving formulas and getting to solutions. Every
person is different, and so you've got to relate to people. I didn't
have too many classes on that, not here. The class foundation for
that actually happened way earlier in my career, in the Air Force
as a matter of fact. That kind of thing is very important as well,
and it sometimes happens, and sometimes happens by accident. After
Columbia, there was a concerted effort to do a lot more of that.
Could you share with us some of the lessons learned in relation to
planning, program efficiency, and risk assessment?
Certainly in the area of general risk assessment, obviously again,
the two key events that come to my mind are again Challenger and Columbia.
When things like that happen, it becomes pretty apparent that maybe
your risk assessment and your risk management foundations weren't
so great after all, and you've got to retool and rethink what you're
doing. Again, in both cases, there was a huge amount of rework that
went into failure modes and effects analysis, and hazard reports,
and all that kind of thing. A huge amount of information and time
went into reevaluating, rewriting, re-baselining those things so that
the program management would end up with a lot better assessment,
a lot better idea of what the true hazards and the true risk areas
were. Again, after Columbia there was just a huge amount of that that
went on, and all those documents got re-baselined.
I think the end result of that was that senior management does have
a lot better idea. You can take a look at everything that has a high
risk and you can decide, "Well, yes, that's the most serious
thing there is that I'm worried about today, and so if I've got any
money or any things that I can do to mitigate that risk and lower
the risk from that effect, then that's where the money will go. Maybe
this [is] not so mandatory, or nice to have, but not a mandatory thing,
I'll just have to put [it] off and go tackle the really big things.”
That happened after Challenger.
When the plans for supporting Space Station were being built, of course
we started off, I think, with a Space Station that was at a lower
inclination. Then as we came to the point where the Russians, it looked
like we were going to get into cooperation with the Russians on Space
Station, and then the International Space Station of course, was the
final outcome of all of that. The orbit changed to a higher inclination.
It became obvious that we were going to have to improve the performance
of the Space Shuttle system in order to boost the elements and then
the logistics into that high of an inclination.
One of the main things that was happening, just after I went to Florida
and Brewster Shaw transferred back here as the Program Manager, was
a big effort on what was called Performance Enhancement, PE. It involved
pretty much all the elements, all of the projects that the Space Shuttle
Program had to evaluate what they needed to do. Evaluate whether there
[were] changes in the flying environment, and what those changes might
mean to them. [That effort was] a good example of what we had to do,
to take a look at risk and being able to make the vehicle perform
so as to be able to even pull off that part of the mission. That was
one thing that wasn't connected to either one of the major accidents,
but it was a major thing that we had to go through and build into
the capability of the program. Because we had to increase the performance
by several thousand pounds, and that's where the super-lightweight
tank came along and main engine performance increased. There's a number
of things that happened when we did that.
Any lessons learned from planning or program efficiency?
I guess the biggest lesson learned is just because you're thinking
about a change in one element doesn't mean that there won't be other
elements that are affected by it. We wanted an increase in performance.
We had to have all elements look at [that]. You couldn't just say,
"Main engine, why don't you see if you can beef up your performance
and provide more thrust." If you do that, then you're going to
change the whole -- the environment outside is maybe the same, but
you're going through it faster at each stage of the game, so you've
got to evaluate that whole thing, and each project then has to get
involved and do that.
What seems like maybe an innocent change that would just apply to
one project, as a Program Manager, I think you've got to say, "Hey,
this could effect everybody, and so everybody needs to take a look
at it." I think it's really apparent that you've got to have
a good understanding of the way decisions are made in the program
and the effects then of those decisions on everybody else. It's not
just a program thing or it's not just an SSME [Space Shuttle Main
Engine] or a tank thing, it might affect everybody, so you've got
to make sure everybody gets involved in it and knows what's going
How do you apply these lessons learned, that you've learned over the
years, to your current position?
I think it's a matter of as you go through each experience, it just
builds, and luckily you remember most of that, hopefully, and each
time something like that happens, you say, "Oh, OK, that's a
good thing that we did it that way, because if we hadn't, then you
would have had to recycle and spend more money on it, or redo it."
Which is not very efficient. I think the thing that's obvious is that,
in the 30 years that I've been involved in this program, there has
been no such thing as a static program. In other words, we go along
and we say, "By gosh, this is the way we did it on the first
flight. It's going to stay that way for the rest of the program."
No such thing. If there's one thing that's been constant throughout
the Shuttle Program, it's been change.
You've got to have a mindset, and you've got to help your people develop
the mindset that says, "We are in a changed environment. It changes
all the time." Get ready for it, be able to deal with it, and
keep the people that they bring in ready for it, too. Don't try to
get comfortable, because as soon as you try to get comfortable, somebody's
got a new idea or somebody's going to want to change something, and
so you've got to be able to deal with it. Your processes have to be
robust enough, then, to accommodate that change as you go along, because
it's always happening. Always.
Could you share with us an example of a successful risk mitigation
activity or management activity that impacted the Shuttle Program?
Sure. I've actually been talking about risk mitigation for a lot of
this. All of the activities after Challenger and Columbia have a certain
amount of relation to risk mitigation. But specifically, take the
External Tank we had. The first external tanks built were fairly heavy
and bulky. We went to a lightweight tank to increase performance,
that's a mitigation -- maybe not necessarily mitigating risk, but
it's performance enhancement, and anything you can do to enhance performance,
I think, translates to a safer operation. Then when we needed even
more performance, the project at Marshall [Space Flight Center, Huntsville,
Alabama] developed the super-lightweight tank, which was the aluminum/lithium
material that we use today. Each one of those steps is a huge, it's
a major deal for the project, to develop each of those stages. Each
of those changes would come with a considerable amount of risk on
affecting the safety of operation unless they were doing all those
things that go along with it to make sure that they are addressing
any of the changes that could increase the risk, especially. Then
the overall effect of that, then, is when you get done, you actually
have a product that's safer in the long run than what you were doing
There were several things done to the main engines, throughout the
history of the early program especially, but they've actually been
continuing all along. We developed -- again, this is the Project that
did this -- but they developed new turbo-pumps, both an oxidizer turbo-pump
and a fuel turbo-pump to put on the engine that were more robust,
they had a lot more safety features, and so they were a direct enhancement
to increase safety of operation during the ascent phase, for example.
They provided a very significant increase in the safety of the launch
phase. Then they had some other things. All along, they worked sensors,
they worked seals, they had a large-throat, main combustion chamber
that they developed. That was another single big thing that they did
that increased safety. Each time they do that, then they go through
a complete test program. For a main engine, that means firing the
engines a given number of times down at Stennis Space Center [Mississippi],
putting it through the paces and flying to profile. Each time they
did that, then it was accompanied by a big test program, and overall,
when you got done, you had a better engine, a more reliable engine.
Let's see. I think another good example of that would be after Columbia
we took a look at debris, potential debris sources on the Shuttle
stack in a total new light. I mean, just with a fine tooth comb, went
over everything we knew about and could postulate, and went through
a physics-based analysis on it, and really, the folks who did that
work became very finely attuned to the mechanisms that were causing
foam to pop off and other pieces of debris to be liberated throughout
the phases of ascent of concern. Systematically, the systems engineering
and the tank people addressed each one of those mechanisms and debris
sources, and came up with solutions that decrease -- each one of them
-- decreased the risk of having a major debris event. We never get
rid of all the potential debris risk that there is in flying a vehicle
like this, with the Shuttle mounted on the side, but we've done a
lot to mitigate the risk from debris in the post-Columbia time period.
That's been another huge effort in doing that. Then other things that
we've already talked about.
What improvements and planning or implementation of risk mitigation
would you recommend, given past lessons learned?
Oh boy. Well, I mentioned planning for change. You need to be of a
mindset that says you're always going to run into something that needs
to be done differently or should be done differently, and as you do
that, then you need to plan on trying to make it safer as you come
out the other side of your effort. Another lesson learned would be
if you know that change is a part of the program -- and it is and
it always will be -- then you need to very jealously guard a program
reserve, a budget reserve, to accommodate new work in a certain area.
You can't use up all your budget just to operate the program. You've
got to have some reserve budget to be able to address problem areas
as they come up. If you don't have that budget, then you're just discovering
risk and if you're not doing anything about it, then risk is going
to start piling up again. So you've got to protect that reserve and
build it into the program-planning part to be able to address issues
that come up from month to month to month.
Let's see. I think I stressed the importance of professional program
project management training and class activity. I think NASA needs
to do -- and we all need to do -- a certain amount of that. Make sure
that we have folks trained in how to do this stuff, because it's very,
very important that we have conscientious, technical yet “business-savvy”
people, so to speak, if you want to use that term, that know that
all your problems aren't necessarily technical in nature. You could
be facing other things as well in terms of not having enough funds
or not having enough support, political support dropping off. There's
not too much you can do about the political part of it other than
stress it to the senior people, and they can try to deal with it.
But everybody ought to be cognizant of the fact that you're not operating
in a vacuum. There's a lot of factors that can affect what you do,
and it's all part of that mentoring, on-the-job training that I talked
I think you've already addressed this question, but are there any
other additional suggestions or improvements, you think, that could
be made in management processes?
Gosh. Don't know whether I can think of anything new or not that I
haven't talked about.
OK, I think that you've addressed those. How do you think you would
best teach these processes or lessons learned to future employees?
I think what [you] are doing is probably one way of making sure that
you do take the time to mentor young folks as they come along, as
people step into these management positions that have not been involved
before, or have been involved in a different way. You know? Help them.
Offer assistance, offer advice, whatever seems appropriate at the
time. My advice always is try to get to know the job, technically,
and then in the non-technical aspects as well because as I just said,
that's very important. Somebody told me that as you come into this
job, you're going to meet a lot of people. Some of those people's
advice is more important than others’, let's just put it that
way. Everybody's advice is probably important, but there's some folks
who [are the “go-to” people for advice].
You want to learn as fast as you can, who are the “go to”
people, or who are the people who have a good, solid set of knowledge,
and their knowledge is based usually on experience, and they have
developed a reputation of knowing those good things to do. In other
words, it is something they have cultivated in their lifetime, and
so it's probably a good thing to pass on to the next generation or
two. Getting to know those people who can help you most is a very,
very important aspect of just jumping into program management. Some
of them are technical experts, but some of them are not technical
experts, and you need some of both.
I think you've got to know the customers, you've got to know who your
stakeholders are. Your stakeholders are sometimes different than customers,
and so you've got to be familiar with both. “Who are we doing
this for? Why are we doing this?” That's pretty important stuff.
Then of course know your people, the people who are working for you
and with you, because they're going to be looking to you for guidance
and assistance as well. Back in the very beginning, I talked about
trust. I think it's hugely important in a program. Our human spaceflight
programs by nature are very diverse programs. They have lots of components
and projects, different sections to them. Program and project management
has to have the mindset that this is the whole. You've got to recognize
what's part of the whole thing and deal with all of it, not just single
out one or two areas. It's everything, each area is dynamic, and you've
got to coordinate and come to know all of them. Probably the best
piece of advice is know where to go to get help, and don't be afraid
to ask for it. You've got to look to everybody.
This is kind of a similar question to the last one. What would you
recommend to use to best train and equip the future NASA employees
and contractors coming on board?
I think both NASA and the contractors, they do stress program project
management training. As I say, it's not easy to do, and so everybody
likes to have certain formal requirements. So there's formal requirements,
there's the mentoring that I talked about, or on-the-job training.
You're not going to get by [just on] that. You can have all the formal
training you want, and you still need to have some help when you get
into it. I would recommend some of the things that are being used
today in terms of -- I don't know what the right terminology is --
the non-technical things like team, how to operate in teams.
How to get the most effective work out of teams. How to lead teams.
Communications courses, or communication theory, ability. Learn how
to communicate with people, interface with them. Decision-making courses.
“How do you take this huge amount of technical data and put
it all together and come up with a cost-effective, value-added, risk-reducing
solution to whatever it is you're dealing with?” Because you
will have options, there will be options on things you can do. That's
where this knowing who can help you and going to ask for help comes
in. Training in the softer side of program management is very important,
as well as the technical side.
Looking back over your 30-year career, what do you think was the hardest
challenge that you had to face?
Gosh, I think the aftermath of Challenger probably was the hardest
situation. Even though I was in the astronaut office and wasn't in
a program-responsible position, there were a lot of things going on
that affected whether you personally, whether other astronauts, whether
the rest of the world thought you were doing enough to be safe to
come out and start flying again. As I said, there was almost every
major aspect of the program after Challenger that had some kind of
reinvention. Whenever you do that, you take experienced engineers
especially, and you shake them up a little bit and say, "Come
on! You're lost in your paradigm. You've got to expand your field
of view, you've got to branch out." Engineers get entrenched
probably as much as or more than other folks, so it's hard to do that,
because anytime you're dealing with significant change, you're going
to have a huge challenge. Those times of hugely significant change,
I think the biggest times for those were after the two accidents.
There were other periods of change in between, but I think those were
What advice would you give someone going into a similar program?
Well, that's interesting. (Laughter) I kind of touched on a lot of
it as we went through, but again, first of all, try to get the scope
of the job. It's all these projects out there. If you're in program
management especially, there's a number of projects out there. Try
to learn as quickly as you can the technical aspects of what you've
got to deal with. Then, of course, you've got to figure out who your
customers are and what they're looking for. Who your stakeholders
are, and what makes them happy or tickles their fancy or whatever
that will allow you to continue to operate relatively -- it's a gauge
of how much communication you need with them as well as the other
direction, toward your program people.
Let's see. It's a good idea to get to know the key people, all people,
but the key people especially. Become very familiar with the decision-making
processes that are there, that are part of the formal system. Then,
of course, informal, there's even typically a lot more processes that
you begin to become aware of. But the official, formal decision-making
processes are important to know about. This whole COFR process that
I mentioned before, you've got to be very familiar with that. Again,
knowing your job, the technical aspects of your job, and then the
other things that go along with it, and know where to find help. You've
got to, you can't get by that. That would be the advice I'd give people.
Learn as much as you can about the job, learn as much as you can about
everybody else's job. When you thought you've learned enough, keep
looking, because it's probably only started. And be ready for change.
Is there anything that you wanted to discuss that we haven't had a
chance to talk about today? Anything in your notes?
It's been pretty familiar. In your last area there you talked about
recommendations on who else you might talk to, and I think you mentioned
that you're starting off with 20 folks in this phase, and I don't
know who they are. Again, in this same thought process of each project
has a job to do and is part of the overall whole, the project managers
would have very specific instances of the risk mitigation activity
that they got involved in. Because I know I just barely scratched
the surface on that. Each one of them was involved throughout every
year doing something that was an improvement. Previous project managers,
hit all of them. There's some at KSC, there's some at Marshall, and
some at JSC. Then the guys over at Stennis may have an input on testing
that might be appropriate.
Chris [Christopher C.] Kraft wasn't really a Shuttle guy so much,
but certainly there's a lot of corporate knowledge on the management
of all that went on. Bob [Robert F.] Thompson was an early Program
Manager. If you go in Building 1 onsite, there's a picture of all
the program managers that the Shuttle Program has had throughout its
history, and I would think each one of them would be a possible candidate
if you go into other phases. Guys like John Young and Crippen and
Dick Truly. T.K. [Thomas K.] Mattingly had a huge technical knowledge—I
flew with him on the first flight. I mentioned Brewster had this Florida
position, Manager of Launch Integration. Are you going to talk to
him, by the way? Is he on the list?
Not in this phase, no. Probably on the next.
I think he'd be a good one to talk to, because he was a Program Manager
also, with myself, Don [Donald R.] McMonagle, Jim [James D.] Halsell
[Jr.]. [N.] Wayne Hale [Jr.] did it for a while. Wayne was also a
Program Manager. LeRoy [E.] Cain is doing it right now. Just some
ideas for you. You're probably not short of people to go talk to.
There's always a battle going on. There's some politics and everything,
outside interests. You never quite know for sure whether the public
is behind you or not. In my role as an astronaut, when we used to
go talk to people, and even today I get a chance every now and then,
people in general seem to be very interested in our human spaceflight
programs, and it's very intriguing to them. But there's so much competition
for their attention these days as compared to 50 years ago. The kids
growing up today, if they're not directly exposed to human spaceflight
like some of the Generation Y people and younger around here, then
there's just a general lack of knowledge of what's going on, and I
see that as a threat to robust programs. That, and the fact that our
United States production of engineers and scientists seems to be on
It really concerns me, that we're not going to have enough critical
mass in our science and engineering ranks in the future to maintain
world leadership. I think world leadership is something that we ought
to continue to strive for in human spaceflight, and I'm just wondering
if we're going to be able to do it, if we can continue to interest
enough young people. Everything has to be instant these days. Instant
fame on the reality TV shows, and going from nothing to making records.
Or dancing your way to something. You guys have seen them all.
Well, that's fine, that's good entertainment, but it doesn't keep
us number one in the world stage of human spaceflight, and if we look
back on it, that's what has made life so good today, is the fact that
we put so much effort into things like going to the moon. It was a
huge technology injection into our economy and into our thought processes.
We are a highly technical nation today, but we're technical in a different
sort of way today. I'm not sure it all applies to things that really
matter in the rest of the world. But we'll see, I guess.
I wanted to ask you, since you've sat on both sides of the table –
[you’ve] been a government official in a management position,
and you've been one in the contractor field. Share with us, if you
would, about the differences and the similarities of the challenges
that you face in those two roles.
Yes. I probably should have said something about that as we were talking,
but there is a significant difference between the two. Now obviously,
NASA is always in charge. The NASA folks are in charge of their critical
decision processes. It's not to say they're operating in a vacuum
or not operating without input from their contractors or anything
-- but when it comes down to the final decisions and making those
decisions, it is up to NASA to do that. That's their role in the program
the way it's laid out. As I mentioned, when I came to USA, I was doing
a lot of the same things that I did as a NASA person, except then,
when you get to the endpoint, you're not the decision authority anymore.
The NASA folks are. It took a little getting used to that, quite frankly.
It was like, "Hmm, OK. I maybe have more experience than this
person, and yet it's not up to me to make that decision. It's up to
me to come up with a good solution for him, a good set of options
for him,” and I believe we do that on a regular basis. All the
private contractors, I think, do a good job of that. But there is
that difference, that in the programs, the way that NASA is set up
today, it is the NASA civil servant that has basically the final judgment.
The final, major "this is the way we're going to go" kind
of decision, but it has to be that way, I think. I think everybody
is aware of that. I would caution people not to get into the syndrome
of, “Well, the NASA folks are there and everybody else is a
second-class citizen,” so to speak. I think you've got to avoid
that point of view, and it's unfortunate that I heard statements throughout
my tenure as a civil servant and then as a contractor. Not everybody
has the correct attitude. There's some of that, you know?
Did you find the processes of getting to a decision the same or different
on how the government achieves that and as the contractor achieves
I think they're pretty similar. I think there's a lot of similarities
in the way USA is set up to do our job in support of the Shuttle Program.
Our elements are aligned with the NASA Project Offices to a very high
extent, very closely coordinated in that. The USA flight operations
group pretty much totally supports MOD [Missions Operations Directorate]
over on the NASA side. They work very closely together, and so as
you would expect, that being the case, the way our flight ops [operations]
people bring along the data and make their solution or make their
decisions and propose their solutions and propose options, is very
similar to the process that MOD uses, because in the end our folks
realize they're really supporting the NASA decision-making process.
It will be the NASA folks who make that final decision. Each one of
our USA elements is structured like that, so our flight software group
supports the NASA flight software project office. Our systems and
engineering and integration does the same thing for NASA SE&I
[Systems Engineering and Integration]. We have an Orbiter project,
they directly support the NASA Orbiter project, and they develop solutions.
If you were to go into a meeting, there would be NASA people, there'd
be Boeing people, there'd be USA people, and if you didn't look at
the badge, it would be hard to tell who's who. That's a good thing.
That's a very good thing. It should be that way. When I was in the
astronaut office, I was pretty much totally unaware of who was NASA
and who was a contractor in the training teams because first of all,
that wasn't the important part, the important part was the quality
of the training. There were people I just assumed were NASA, but come
to find out, they were a contractor, either a Boeing or a Lockheed.
We didn't have USA when I was in training, but other contractors,
and far more of them than there were NASA people.
The better working relationship you have, of course, the smoother
that all goes, and I think we've developed very good relationships
with each one of the projects that we support on the NASA side. But
there is that, there is always that distinction that says the way
the programs are structured, the NASA hierarchy is the one that has
the final decision-making. You'd have to have it that way. Somebody's
got to be in charge, and the way it's set up, NASA's in charge. We
are in a support mode, and I think everybody realizes that. But at
the same time, I don’t think it stifles anybody's thought processes
or ability to want to come up with an eventual solution. Because we
have decisions to make, along the way to our information, bubbling
up as well. It's the same process in the end.
Do you think it's been a benefit to the program overall to have many
individuals like yourself that have worked so long on the government
side cross over to the contractor side?
Yes. I think it's definitely beneficial. I'm all for diversity and
crossover, intermingling of capability, collaboration, wherever we
can do it. Anytime you can get a solution that's based on the joint
input of as many people as you can. There is such a thing as getting
too big a group, and going dead in the water because there's just
so many different opinions. But, I think the way we operate and the
need for solution drives you to the point that diversity of opinion
coming into it is good, and then eventually you need to know, you
know that you have to come to a decision. I think that has a way of
bubbling the best options up for final consideration. Because I don't
think we've made too many really bad decisions in terms of how to
go operate on something. We've got a huge set of flight rules [on]
how to operate, and those things got formulated in the calm of the
day with people sitting around with data and technical opinions, and
they were saying, "This is how we need to operate." Then
they documented the rules from that, and then they followed the rules.
So that's it.
Well, thank you.
Thank you for your time today. We certainly appreciate it, and we
very much enjoyed it.