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

Ronald D. Rigney
Interviewed by Rebecca Wright
Stennis Space Center, Mississippi – 3 June 2008

Wright: Today is June 3rd, 2008. We are in Mississippi to talk with Ronald Rigney, the Deputy Director of Stennis Space Center’s Project Directorate, as part of the JSC Tacit Knowledge Capture Project for the Space Shuttle Program. Interviewer is Rebecca Wright, assisted by Jennifer Ross-Nazzal. Thanks for squeezing us in your schedule. We understand you’re really busy. Thanks for letting us come in.

Rigney: You’re welcome.

Wright: We’d like for you to start by telling us how you first became involved with the Space Shuttle Program.

Rigney: I went to college at Mississippi State University to become a mechanical engineer. I had originally intended on going into the oil industry. When I graduated, however, the oil industry had crashed in this area, and there weren’t any jobs. I was going into interviews with people with 20-plus years’ experience and having to compete with them, and it just wasn’t working out too well for me. NASA had a hiring freeze on. This was after [Space Shuttle] Challenger [STS 51-L accident], and it was in 1986.

So to make a long story short, I worked my way into an interview here at Stennis Space Center, and in that interview I got an opportunity to go around to all of the different contractors and NASA entities on site and interview with them. However, everybody had a hiring freeze on. After about 15 different interviews, I met an individual who was in charge of the roads and grounds contract here on site, and talked him into giving me a temporary position as a laborer working out in the test complex. So I did everything from mop floors to shovel sand out from under the test stand, sandblasting material out from under the stands—really you name it, I did it. Welder’s helper, cleaning up behind the welders.

I did that for a month before it was recognized that I had an engineering degree, and things were starting to really get going again on the SSME [Space Shuttle Main Engine] Program, and I got a job offer with Pan Am World Services to work as an engineer. In that job I worked as a facilities design and field engineer. So I did everything from design cryogenic systems, pneumatic systems for the SSME test stands at Stennis, to running crews to go in and make the modifications to the facilities and things like that.

During that job, I developed an expertise in running shutdown jobs where we might—you’ve probably had stories of explosions of engines during test and failures of engines during test. This would create a unique problem for the facilities in that anywhere from about a 25-foot radius would be damaged. Charred, damaged, removed, burned, melted, and all those things. So I would go in, and in some cases where it was a test stand anomaly, go in and analyze a situation and redesign the facility to prevent the problem. And then build the teams to go in and rebuild all of the facilities. I did that for about five years.

Then I received an offer from [NASA] Marshall Space Flight Center [Huntsville, Alabama] to go to work with the Space Shuttle Main Engine Project Office, and I worked as a project engineer there for a few years. Kept gravitating towards the technical side of things, because that was where I wanted to apply myself. Ended up going to work in what used to be called S&E, Science and Engineering, in the Marshall Space Flight Center. Here at Stennis—all of this work was here at Stennis in the testing program. I worked with S&E and became a senior engineering representative here at Stennis from Marshall. We had a small resident office here with Marshall Space Flight Center at Stennis Space Center. I did that up until about the 2001 timeframe. Then I came to work for Stennis Space Center as a NASA Marshall-badged person doing a Stennis job as a deputy project manager for the SSME test program here. That’s really how I got in the program. I’ve been in the Shuttle Program all along until I took this directorate-level job, which I’m responsible for all the testing programs here.

Wright: As you went along through all these different positions, even your first one, you had a number of challenges that you had to overcome to move to the next one. Could you share with us some of the lessons that you’ve learned along the way that helped you even in your current job now?

Rigney: You learn things when you start at the bottom and work your way to the top. Most people tend to forget some of these lessons as they move into management. But the one thing that I cherish dear to my activity as a manager is that the people at the ground floor are really the only ones that matter in the end. Managers provide opportunity for them, but the real work is done by those at the ground floor. Everything we do has to be centered around providing opportunity for them to succeed. Anything else is insignificant in its end product. So that’s a life lesson for me that I carry with me in the way that I operate here.

Wright: If we could be a little more specific about some of the other lessons that you’ve learned in regard to possibly improving management performance? You’ve been again in different roles, and have seen a lot. Can you share with us some of those?

Rigney: Actual examples of what we’ve done over the years?

Wright: Things that you know that have worked, and then maybe some things that you saw that didn’t work so well.

Rigney: The Shuttle Program—we’ve been testing for over 30 years, so we’ve accumulated a lot of data. We’ve tried a lot of different models for how you learn about a rocket engine. We’ve tried a lot of different ways of doing that, and attempts and approaches. One of the things that I learned through 22 years of working in that program is that really getting focused on what your end goal is or requirement in any attempt to learn something is extremely important. Controlling the requirements creep that might exist in almost any developmental process or even manufacturing process is important to us.

In the rocket engine test world, you have two tremendous “unknown unknowns” they call it. You can start into a process of trying to learn a specific task. An example would be trying to determine why a vibration exists in a turbopump. You would design a test to go and determine what this cause is for the vibration. In your assessment of what’s important in doing that, you create a new condition for the test that provides you an opportunity to learn a new lesson that you had not anticipated. For instance, you may—because of the power level that you ran at, at a specific pressure in one location in the system—you may create a crack that did not exist before in the program in a piece of material. Or you may create an opportunity that provides a specific flow condition for a liquid that you never really discovered before in the past because you were trying to learn something about a specific condition.

As a part of that, you learn things that you didn’t set out to learn. As a result, you have a whole new problem to solve. Really thinking hard about what your control parameter is in a test, what your objectives are, and how you’re going to control all of the influences on that learning process so that you minimize influences outside of what you’re trying to discover. We’ve experienced this over and over again. I’m trying to think of just an example, but there are so many. I think every test we actually discover something new, unanticipated. It may be benign in its nature to the program, but it is still yet new information we never had experienced before.

An example may be—we’ll put a strain gauge on one of the ducts on the engine to learn what the vibration conditions are there. As a result, we find out that actually today it’s vibrating at a frequency and amplitude that’s different than what we had experienced in the past. Well, now we’re off trying to discover why has that changed, and we end up instrumenting engines sometimes to the tune of 100 strain gauges all over the engine, and in that look to try to figure out where this vibration anomaly is coming from we discover a whole new set of vibration anomalies, and our knowledge begins to unfold exponentially just because of this one finding.

We find ourselves having to apply tremendous amounts of resources and analysis teams to go and work out what do we do next with the information we’ve gained, and what do we ignore at this time, what do we consider to be benign, and what things do we just accept as information we can’t deal with, and what level of risk are we willing to take to continue with that knowledge that something’s going on.

Thinking really hard about what you instrument and why you instrumented that before you do it is extremely important. Another thing is the phasing of what you start. When you start a project to go perform some discovery in the rocket engine test world, you have to consider whether or not the unknowns you might develop out of this can be addressed in a timely enough manner to allow you to continue to fly the vehicle. We use moratoriums on testing prior to a flight to try to control some of this.

Over the years, it’s changed from different lengths of time. There’s been a time when it was seven days. You couldn’t test seven days before a flight because you didn’t have the resources to go and address issues that might come out of that test that would probably be unrelated to the flight. However, you can’t fly until you’ve addressed them and proved that they’re unrelated. So we’ve had to deal with those phasing issues in the test program.

We’ve operated for many years under a 24-hour moratorium where we could test it up to 24 hours before a flight. As the program reduced its resources available for analytical purposes and for testing analysis, we had to change how we dealt with that in order to be able to fly. But really considering all those things of what you don’t know as well as what you think you know, along with what you do know, to be able to develop a test plan that supports the flight program that you’re in. That’s been something that’s really unique about the Shuttle Program, because I don’t know of a time when we were truly a flight production program.

From my tenure here since ’86, we’ve always been developing the engines in some way or another, dealing with a new type design or with a new scenario of operation that we wanted to address. So this program has flown vehicles in a timeframe where it was also developing the vehicle throughout its entire flight. It makes it extremely difficult to deal with in a test world, because you create problems that are not beneficial to the flight program necessarily.

Wright: Listening to all you’ve explained, my next question would be then how do you apply lessons you’ve learned for program efficiency? How are you able to plan for those types of phasing issues?

Rigney: One thing that we did do here is we tried to maintain a core of people with knowledge base that’s been carried throughout the whole—actually we’ve carried a knowledge base all the way from the Apollo Program here at Stennis. This organization has performed testing with a continuance of personnel ever since the Apollo Program. For instance, when I came on board as an engineer with a contractor here on site, I was trained under mentors who worked in the Apollo Program and the beginnings of the Shuttle Program. So I had the benefit of capturing their knowledge by on-the-job training and question-and-answer sessions and mentor-protege type arrangements.

Later on, as they became older and retired and went on to other things, they left behind them younger people that carried some of that knowledge. There’s no way to capture all of it. But some of that knowledge. That knowledge was received while practicing the use of it. It’s one thing to capture knowledge and pass it to someone through a book or training and other means. It’s another to be able to do that on the job from mentors.

Here at Stennis, we’ve been able to do that. We’ve used that and capitalized on it by taking that expertise that we’ve maintained over these years and provide test knowledge assessments of program needs. For instance, the Space Shuttle Main Engine Project Office would like to improve a part on an engine. So they propose a design change. They would engage us openly often to find out how that would be tested and how we would propose testing it. In that, our knowledge of past history of repetitively running these tests would allow us to evaluate their design not from a conceptual view or an analytical view or a design view, but from a test operations view. Where we’ve experienced things that may not have ever been documented, that may have been a side thought in a process that we were executing here.

So we’ve been able to add to the design process and to the hardware development process by having upfront dialogue with the design office from a test perspective, and giving them a good check and balance against how things were going to work once they started trying to use it. We’ve been able to support their design offices by sending our people to the location where they might be developing new software or developing a new piece of hardware, and giving them insight into experiences that we had had here that they may want to consider as they design or develop that new piece of hardware.

Wright: Everything that you do here has an element of risk that you factor in. Share with us some ideas or recommendations for improving risk management or risk assessment, risk mitigation, the whole area, and those lessons that you’ve learned that you certainly want to apply when you’re looking at that area.

Rigney: From this position that I’m at now, I’ll say that a well-defined tier structuring of what risk means for each element. From each location that you’re viewing a risk from, there’ll be different assessments for how that area is affected by the risk. You see arguments over red, yellow, and green all the time. If you go and pull risk documentation, each element of a process will define risk at a different level—red, yellow, or green—based on some criteria that they establish. It would be extremely beneficial to future programs if they understood each element’s risk definition, and when they make a risk mitigation decision or anything of that nature—in today’s computer world we ought to be able to already know what the criteria is at each level.

When you look at a risk from your perspective, you ought to be able to see the risk from all the other people’s perspective in your organization, so that you know that down the end, for instance, you may see a risk as a red because you only have $100,000 to manage it with, whereas the top-level manager has $6 billion to manage that risk with. He’ll see it as a green. I’ll see it as a red. Understanding how that’s viewed across the whole spectrum is something that I think would benefit other programs—if we had communicative dialogue or instant ability to understand how risk is viewed, of the same risk from different perspectives when they address them. Because there may be a decision to perform a lot of work or worry or concern over something that at the end customer’s end is something that they wouldn’t even consider a risk itself, it’d be a green. So that’s one thing I think that a new program might consider, is new methods to see risk from across the spectrum as opposed to from their own knothole or their own level.

From down the end in dealing with test programs, we have a perspective that all things carry a risk. There’s low risk, there’s medium risk, there’s high risk, there’s moderate risk, but there’s never a no-risk situation. You always have something that can go wrong. So when people from outside the test world view us, they have difficulty understanding that environment. For people outside of the test world it would be greatly beneficial for them if they could understand one thing: that all things are risky in the test world, but the test that they perform provides value that weighs against that risk. And that value is we develop equations for things that analytical and engineers and scientists do not have equations for yet.

A lot of times we are just validating a known theory for an engineer somewhere when we perform a test. But there are many times where we’re performing tests that actually build the equation that they’ll use for understanding how a rocket engine works. In those cases, people complain about burning a rocket engine up. If you’re doing it for a reason, and you develop an equation that didn’t exist before, generations behind you will benefit from that, and that cost of that risk is insignificant over the long haul.

So it would be great if people outside of the test world could understand what we’re really here for sometimes, that we’re here to develop equations that don’t exist today, as well as verify those that do already exist—or discredit them as well. Some theories actually don’t work. Risk in the test world is the norm for us. Benefit is what we need to be thinking about when we weigh it against that. We shouldn’t see risk as something that you should avoid. It’s always dealt with by mitigation in test or equalizing value in its chance for success.

Wright: Are there other areas that you see that you would recommend to increase benefit? I like that word that you used, that you have to look at the benefit.

Rigney: Right. I don’t think I’ve actually ever seen a time when a project manager, after performing a test, felt like he had wasted his money. Everyone I’ve ever talked to—they’ve always felt like after they performed the test they were glad that they did, because they learned something from it. If rocket engines were as easily understood as some analytical people would have you believe, then that wouldn’t be the case. But the truth is you always learn something from a test performed. Whether it was worth the value of what it cost you to perform it is another story, and people have to be very smart about how they do that, how to get the most bang for the buck out of every test they perform.

But you should never have a project manager or program manager complain about the significance of a test up front. Because there’s going to be some value, whether known or unknown at that time, that comes out of it. The real issue is whether or not you can afford it in the first place. If you have money for testing, there’s going to be value that comes out of it. If you do not have money, you’re not going to get the value out of it, and you are missing something. You don’t spend that money at a cost in this world, but that’s something that project managers should consider. But they shouldn’t think of testing as something that is not of value to them. I’ve never met a project manager or program manager that looks back on any test they performed that they weren’t glad that they did it. There may be some out there. I’ve never met them.

Wright: You had an interesting evolution, as you mentioned coming up, literally, from the ground up. There’s going to be a whole new group of folks coming in or leaders being trained. How would you best equip them to be the leaders that the space agency needs in the future?

Rigney: I’m not one of those that things there’s a single answer for that. You need all kinds and all types of all people in something like this. There’s no one person that fully understands SSME. There’s no one person that fully understands the Space Shuttle. There are groups of people from around the country that each one has a part of it, and communication between them is what builds the ability to do this kind of task. When people start saying that you need to do this or you need to punch this card or that card to be able to do this type of job, I think they lose something in what value comes from the nature of individuals in our world.

Everybody’s a little bit different. They bring different things to the table. I think the art is taking what comes from that diversity and making the most use of it. There are things that do align well with certain tasks. For instance, being in project management—there’s a tremendous amount of training that ought to be provided within NASA. I’ve been the beneficiary of some of that in the near past. I’ve spent most of my career without any training on budgeting and scheduling. All my training was technical, which is the norm for NASA individuals.

There’s completely different fields throughout NASA. Hands-on type environments like they have here at Stennis, where we’re more the executing side of the spectrum. The things that are good for us are not necessarily good for someone in the design field. But there is an element of what a person learns coming up through the ranks in the test world that adds to a design field. So I think it’s diversity that we ought to be thinking about and not necessarily some canned set of specific requirements for certain types of jobs. I’d rather see any organization or any function even have a diversity in it as opposed to a lot of people that have the same credentials. They’re really going to have a lot of blind spots if we do those kinds of things in NASA.

What I have seen NASA do well is there are people from Stennis all over NASA. They’re everywhere. They’ve run Shuttle programs. People from Stennis Space Center with expertise that’s developed here. We rely heavily on growing our NASA people through the contractor workforce here at Stennis. I notice that other Centers do the same. A lot of people are moving back and forth through the different Centers within NASA, which is extremely helpful.

But on the same token, there are people that might spend their entire career at one Center that are extremely valuable to NASA because of that knowledge strength that they have. They don’t necessarily have the understanding of the broad spectrum of NASA, but they do provide to those people that do have that broad spectrum of understanding specific, detailed knowledge that stands the test of time in one location. That adds to that person who has that broad spectrum of training across all of NASA. That’s just an example. You hear people talking about, “It’s important to move from place to place,” and I would agree with that wholeheartedly. Except that it’s also important to be the guru of something specific.

My answer to that is always going to be very broad and hard to nail down because there’s value in everything that we do in NASA. You’re going to find value in some one [thing] because we are doing things here. You might sum all that up in saying if you’re doing something, you’re doing something good for NASA’s long-term training benefit, because that’s how people learn. Whether it’s through training or traveling or learning from other people or watching other people work, you’re doing something, and that results in good things for people in NASA.

Wright: What kind of advice would you share with someone who’s interested in moving into the space agency and making it their career?

Rigney: Know what you want out of it. When I came, I was looking for the oil industry. I actually watched the Challenger incident from a hallway in McCain Engineering at Mississippi State University. When the Shuttle launched we always rolled a TV out in the hallway, and all the engineers would gather around and watch it with awe and pride in our country and what we were able to accomplish there. When I saw that it really affected me, just as it did everybody in the country. I never really dreamed of an opportunity to work with NASA. I really didn’t even know that Stennis Space Center existed in Mississippi. I grew up in Mississippi and did not know it existed. That’s one of the problems that we’ve had within the rural areas of the country. There’s not an education of what’s out there.

When I was a graduating senior is when I learned what was here, just 50 miles from where my parents had moved to. So I happened upon the space industry only because—I would have loved to have done it, but I wouldn’t allow myself the thought of even being in the program, because I was raised in an area where it was more agricultural and you didn’t have opportunities for things like that. The oil industry was one of the fields that I knew about, and that’s what I was drawn to.

Once you set your mind to go into the space industry, it is broad. You can be from any background or knowledge base and apply it to this industry. I would say set your goals and have long-term goals for what you want to do and stick to them. Don’t let money or prestige—what traps a lot of people are things like that.

I’ve found that when you go home being satisfied that you did something that was pleasing to you and you’re proud of is enough. You probably won’t starve to death if you do that. I’ve never gone hungry, and I won’t be rich, and I’m worried about my gas prices. But when I get home I’ll be proud of what I did here, because I love the hands-on aspect of what we do at Stennis. So for me that’s where I need to be. Other people need to decide what makes them happy and let their happiness be a part of what they do for NASA.

Wright: What do you think has been the hardest lesson or maybe the best lesson that you’ve ever learned while you’ve worked for the space agency?

Rigney: Every little thing you do matters to the astronaut in the end. Even in attitude. When you walk in in the beginning of a day, if you bring a bad attitude with you, it might infect someone else who is performing an inspection later on that day, which is a final inspection for a part before it goes down to the Cape [Canaveral, Kennedy Space Center, Florida] to fly. We take that very seriously here. But I don’t think anyone can ever take it seriously enough. Just saying the wrong thing to the wrong individual on the wrong day when they’re already having a bad day might create something that could be detrimental in the endgame. Here at Stennis, we’re very attuned to the fact that everything we do affects the astronauts. That shows in our record. SSME is considered to be the highest-risk element of the ascent in the Shuttle Program, but we’ve never really had anything that’s caused an issue—that created a life issue for the crew. That’s not something we brag about, but it’s something that we’re proud of internally.

But at the same time, it instills a lot of concern and fear inside you when you work here. That was a difficult thing to grab hold of as you come out of a world where—especially in today’s society, as kids are raised without the same level of accountability that they were in days past, we see less and less accountability being applied to children in the way they’re raised today. When you start a job in NASA, it’s a real shock for people, nor do they actually grasp the full concept. It takes years to really grasp the full concept of what your obligation is to an astronaut in a flying program. That was the most difficult thing.

I think I learn new things even today. I just came back from a launch. I’ve only seen two launches in my career of 22 years. I’ve seen a lot of scrubs, but I haven’t seen a lot of launches. We watch a lot of test firings here, but there’s not a man or woman riding on that rocket when we test it. We have our people cleared back. Everything’s remote-controlled. So here the focus is on doing the job right and keeping people safe in our operations, which are hazardous. However, it’s not the same as the end result of an astronaut riding the Shuttle. The combined complexity is great there.

Standing at the Cape and watching the Shuttle launch STS-124, what I just got to watch, it really shakes you up. I’m tearing up now. When you watch that, it brings home to you what the reality of what you’ve been doing every day. We do a good job of carrying that with us here. But I don’t think anybody could ever really pay enough attention to that aspect of it, because it is a dangerous business. It’s a miracle what happens when it goes well.

Wright: When we first started, you mentioned that those on the ground floor that do the work—they’re so important, and the management’s role is to provide the opportunities for them to succeed. Do you have any other sound practices and best processes that you like to use when you do those?

Rigney: I’m a simpleton. I operate out of a core set of things as much as I can. One of them is you do what you say you’re going to do. If you tell someone you’re going to do something, then do it. Most things aren’t impossible. If you just believe enough that you can do it, you probably will get it done. If you’re having trouble, you get help. Whatever that is, you do what you say you’re going to do.

When you fail, you try to find a way to make it right and complete what you said you were going to do under some new set of terms. Say it again. If you’re going to fail, you tell people, "I’m not going to be able to do exactly what I said when I said I was going to do it for how much I said I was going to do it for. However, I believe I can do it for this," and you go ahead and you confess and move forward with a new opportunity. Never hide anything. Do what you say you’re going to do. Say you’re going to do something that’s believable, don’t overstate your case. And when you find you’ve done that, confess and find a new path forward to success. That’s an important thing.

Another thing is to never get ahead at anybody else’s expense. That goes with personal issues, but also with your work issues. This is part of this taking care of the astronauts, getting your specific tasks done at the expense of another task is not a good practice. Best practice is to consider all those things around you and make sure that your task doesn’t interfere with things. So do what you say you’re going to do, but not at the expense of others in doing that.

Every dollar is important. When I first came here, NASA was huge. Stennis is still small. It was small then, but it was bigger than it is today. There was a lot more buying power with the dollar back in that day. However, I don’t think we really did that much more then than we do now with the buying power that we have. It’s been reduced, but we’re that much better at what we do. When I first came here, I came from more of an agricultural background, where they thought about things a little differently than they did inside the government realm. Inefficiency was something that was easy to see when I first came into NASA. I’ve watched that through the reduced buying power, people learning from the way they were operating that day and trying to do it better.

It wasn’t because people were—the assumption that the outside world has that we’re lazy or those things. It’s that we were learning about these things that are unknown. Rocket engine testing is unknown and still an unknown today. Taking every dollar you get and squeezing the most out of it for the taxpayer is an extremely important thing to adhere to. I’ve watched that take place here in a way that is respectable.

There’s always things you can point out that are wrong and you need to fix. But that’s not so much a judgment on the people that were doing it wrong as it is the whole of the organization. As long as they’re recognizing that and moving forward, that’s a good thing in the world, making the most out of that dollar that the taxpayers provide to us. Because somewhere there’s a guy sitting at a table with not a whole lot of food on it because he’s living within his means. There’s a farmer somewhere that’s paying his taxes and getting by on less than someone else is, but still paying his taxes. We’re using his dollar just like we are the guy that has plenty. So we ought to treat them all the same and get the most out of them for the program, because that’s what we were sent here to do is make the program successful.

Wright: Those are good things. Are there some other areas that you’d like to talk about as far as lessons learned? You’ve talked about risk and program efficiency. Is there anything else about management performance or bringing new leaders into the agency?

Rigney: There’s one other thing, is having accountability for what you do. There’s a tendency inside of a development world to get the job done. Documentation isn’t necessarily as important as it is, say, in a flight program or handling flight hardware. However, it is just as important. Because if you can’t be accountable for what you did and account for it and even share that knowledge later on, it really didn’t happen. It happened in that moment, but the long-term effect of it doesn’t exist, because it’s been lost. Brilliant ideas have been lost over and over and over and over again inside NASA by technicians and welders who had an idea about a better way to weld. But they didn’t document the process; they were just satisfied with being better at it than others.

That kind of thing has been extremely costly to NASA, to the government, because again it’s at that ground floor where the work really happens, but it’s also at that ground floor where the least amount of documentation of the skill and the process occurs from that perspective. The documentation usually is forced down to them as opposed to developed by them. To me, that’s a huge loss that we’ve had over the years, especially in the development cycle of rocket engine development. Many many many many best practices get lost and rediscovered and lost and rediscovered and lost and rediscovered and lost again by that mentality. Documenting great ideas, collecting the gems out of what you do every day and passing them on, are extremely important.

Wright: That’s a good one. I’m glad you thought about that. I think one of the other things that we would like to know is if you have some other people that you feel would be able to contribute some expertise to this project, some that you would think that you know along the way.

Rigney: Yes. There are many people that are retired. I don’t know if you all have access to retirees or can compensate them for their time and that kind of thing. There’s an individual that retired here recently that has a historical knowledge from actually 42 years’ experience. He just retired. It’s Pat [F.] Mooney. He’s the guy I replaced as the SSME Project Manager here whenever I took that position. He has knowledge about not only the Shuttle Program but programs prior to. The Apollo Program and the processing of the stages through Stennis and the actual facilities here, as well, from inception on. He would probably be of value to talk to.

I’m getting to be one of the older guys, I’m embarrassed to say. We do have some Pratt & Whitney Rocketdyne [Inc.] individuals here. I can’t think of his name, Whitey is his nickname. You could inquire with Pratt & Whitney Rocketdyne folks about Whitey. They’ll know his real name. I can’t think of it right now. He’s also about 43 years here, and he’s from the instrumentation world and data acquisition world. So he can give you a hands-on perspective of the operations here. I’ll probably think of a million things. There’s 22 years of stuff up here.

Wright: Well, good. We’ll be back in contact with you so maybe we can fill in some of those blanks. Any other thoughts you’d like to share before we close?

Rigney: Just something in general is that failures—people define certain events as failures. Failure of a rocket engine when it explodes—that’s not what that is. That’s opportunities is the way we look at it. Because of the things that we can learn from that. Any program that’s developing the ability to fly humans in space should embrace those things that are seen as failures by others because there’s value there that transcends time for that program, and maybe for future programs as well. You can see that throughout the Shuttle Program, the things that we’ve learned about what the bad ideas were, but also what the good ones were. It’s obvious what the bad ideas were. The good ones are not so obvious to people when they come on board.

They need to look at the failures as opportunities, not as negative things that they should discard. The Shuttle Program might have had something right, with the exception of maybe one thing that caused that failure. That creates an opportunity to correct that one thing and have something that’s perfect. People tend to look at it from a different viewpoint, that if there is a failure associated with one system of a certain type or an issue, then they try something completely new as opposed to taking all of this investment that NASA has developed and taking something that was almost there to being there. That’d be advice I would give to people. Look at the testing program. Look at the history. Look at the failures in specific—and not from what not to do, but what is that one more thing that needed to be done to take us to a new level.

Wright: That’s a good place to end. Thank you very much.

[End of interview]