NASA Johnson Space Center Oral History Project
Tacit Knowledge Capture Project
Edited Oral History Transcript

Loren J. Shriver
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?

Shriver: 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 be done.

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 period.

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 aircraft 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 done differently.

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 or whatever?

Ross-Nazzal: If you want to talk about some of the other assignments that you worked on in the Shuttle program, you can.

Shriver: 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 Shuttle operations.

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 so forth.

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 they are.

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.

Ross-Nazzal: I think it's hard to give a very brief introduction to your work in the Space Shuttle Program.

Shriver: I know it's longer than you probably wanted.

Ross-Nazzal: 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?

Shriver: 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.

Ross-Nazzal: 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?

Shriver: 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 like that.

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.

Ross-Nazzal: Can you share with us some lessons you've learned in regards to improving management performance?

Shriver: 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 branch out.

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 days.

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.

Ross-Nazzal: Could you share with us some of the lessons learned in relation to planning, program efficiency, and risk assessment?

Shriver: 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.

Ross-Nazzal: Any lessons learned from planning or program efficiency?

Shriver: 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 on.

Ross-Nazzal: How do you apply these lessons learned, that you've learned over the years, to your current position?

Shriver: 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.

Ross-Nazzal: Could you share with us an example of a successful risk mitigation activity or management activity that impacted the Shuttle Program?

Shriver: 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 before.

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.

Ross-Nazzal: What improvements and planning or implementation of risk mitigation would you recommend, given past lessons learned?

Shriver: 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 about before.

Ross-Nazzal: 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?

Shriver: Gosh. Don't know whether I can think of anything new or not that I haven't talked about.

Ross-Nazzal: OK, I think that you've addressed those. How do you think you would best teach these processes or lessons learned to future employees?

Shriver: 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.

Ross-Nazzal: 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?

Shriver: 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.

Ross-Nazzal: Looking back over your 30-year career, what do you think was the hardest challenge that you had to face?

Shriver: 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 the biggest.

Ross-Nazzal: What advice would you give someone going into a similar program?

Shriver: 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.

Ross-Nazzal: Is there anything that you wanted to discuss that we haven't had a chance to talk about today? Anything in your notes?

Shriver: 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?

Ross-Nazzal: Not in this phase, no. Probably on the next.

Shriver: 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 the down-slope.

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.

Wright: 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.

Shriver: 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?

Wright: 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 it?

Shriver: 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.

Wright: 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?

Shriver: 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.

Ross-Nazzal: Well, thank you.

Wright: Thank you for your time today. We certainly appreciate it, and we very much enjoyed it.

[End of interview]