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

Arnold D. Aldrich
Interviewed by Rebecca Wright
Springfield, Virginia – 28 April 2008

The questions in this transcript were asked during an oral history session with Arnold D. Aldrich. Mr. Aldrich has amended the answers for clarification purposes. As a result, this transcript does not exactly match the audio recording.

Wright: Today is April 28th, 2008. We are in Springfield, Virginia to speak with Arnold Aldrich, who retired after 35 years with NASA and after 13 years with Lockheed Martin where he served as a vice president and director of program management for the corporation. The interview is being conducted for the JSC Tacit Knowledge Capture Project for the Space Shuttle Program. Interviewer is Rebecca Wright, assisted by Sandra Johnson. Thanks again for coming in to see us this morning. You joined NASA in 1959 when the space program was first beginning. Your firsthand experiences range through the programs that led to Shuttle, where you first served as the manager of the Program Assessment Office that Bob [Robert F.] Thompson asked you to begin. Tell us how you transitioned into this position from Apollo and about those duties, and then just lead us into where you'd like for us to know about the Shuttle Program.

Aldrich: Your interest today is about program management, how you prepare for it and what strong attributes a program manager ought to have. One of the things I will mention several times, and I believe in a lot, is that managers for the programs that we do in NASA and particularly at the Johnson Space Center [Houston, Texas] really require a pretty in-depth understanding technically of the program and the systems that are involved in the program. In order to arrive at the point I was at when I started in program management, I had had quite an extensive background in spacecraft systems in the Mercury, Gemini, Apollo, Apollo-Soyuz [Test Project, ASTP] and Skylab Programs. I first moved into program management midway in the Skylab Program and then with the Apollo CSMs [Command Service Modules] for Skylab and Apollo-Soyuz. But prior to that, during the first third of my 35 years at NASA, I worked in the Flight Operations Directorate in the development and operations of the Mission Control Center and the Manned Space Flight Network remote sites. My on-console responsibilities and the responsibilities of those that worked for me were all related to in flight support of spacecraft systems in the programs that preceded the Space Shuttle.

All of that gave me a pretty strong background in the details of those programs. I evolved into becoming one of the senior spacecraft systems console operators for Project Mercury in the Mission Control Center. Then, for Gemini and Apollo, I was the leader of the organization that trained and provided the spacecraft system monitors for the Gemini spacecraft and for the Command Service Modules in Apollo. Through all of that, learning the program operations and the spacecraft systems in quite a bit of detail provided a breadth of background that was a very strong asset when I first moved into program management. I knew the programs well, including the in-depth technical characteristics of them.

Wright: The Shuttle, of course, was a brand-new spacecraft. When I was reading back through a transcript that you had done with us before, for instance, and you mentioned that Bob Thompson asked you to start this Program Assessment Office, which was a new office, and you had a chance to look at issues. Tell us how important that was at the beginning of this new time period for NASA as it moved into a new spacecraft era.

Aldrich: During the time leading up to Apollo 15, I transitioned out of Mission Control and spacecraft systems management, and went to work for Kenny [Kenneth S.] Kleinknecht as his deputy program manager in the Skylab Program. Not long after that, we began using the Apollo Command Service Modules for Skylab and for Apollo-Soyuz with the USSR, and I transitioned to the Apollo Spacecraft Program Office. I was deputy program manager to Glynn [S.] Lunney for the Command Service Modules. Thus, in my early phases of program management I was back in the same programs I'd been supporting in the flight operations organization.

During the time period of Skylab and Apollo-Soyuz flights, the Space Shuttle Program started and became very real with hardware being developed and a large, multi-center program underway. When Apollo-Soyuz ended, that was the end of the Mercury-Gemini-Apollo program era for all of Johnson and NASA. And, it was at that time that the Space Shuttle Program was beginning to see a need for a “Program Assessment Office”. Some people called it the “devil's advocate” office, to assess how the program was coming along and identify issues that ought to be addressed. I know Bob Thompson was very interested in that. I'm certain he believed that he was doing his best to run the program as effectively as possible, but it was an opportunity to have an independent, off line, organization look at the program, as well. And I was asked to set up and run this office.

Most of the rest of the Apollo Program Office people that had finished doing ASTP went into a new office that dealt with payloads for the Space Shuttle. It was called SPIDPO [Shuttle Payload Integration and Development Program Office], and it was created to develop the processes and procedures for acquiring and handling Space Shuttle payloads as well as how the Shuttle Program would deal with the organizations that provided the payloads. I believe I was pulled off to run the Program Assessment Office because of my background in spacecraft systems, with the charge to lead these independent assessments with people who hadn't been associated with the Shuttle Program up to that time.

I carefully reviewed the Center manpower at the time and selected a group of about half a dozen people who I would like to have work for me. I had to go negotiate getting them assigned to me with whoever their manager was at the Center. I remember that a couple of them that I asked for were pretty strong in the Engineering Directorate, and I had to go talk to Max [Dr. Maxime A.] Faget. Max thought the Program Assessment Office was a great idea, but—“not taking my people to do it.” However, I ended up with a very strong team. We looked at the mechanical aspects of the Shuttle and the avionics and the missions - essentially the whole suite of what the Shuttle Program was planning to do and provided a series of reports on what we found. Partly because of my background, I suppose (I'm an electrical engineer), but primarily because I think it was an area with some significant deficiencies at the time, we were particularly critical of how the avionics and the software were evolving. There were some questions about the adequacy of the size of the computers and the overall architecture of the avionics multi-redundant computer system that was planned for the Shuttle. We criticized these areas pretty strongly and I'll come back to that in a minute.

Another thing we were quite concerned about was the fact that the solid rocket boosters (SRB’s) were single point failures, and once you lit them off they had to burn for the first two minutes of launch. There was no way to get off. There was no escape. They would take you two minutes up hill or in any other direction they wanted to go. Our group had been used to the prior three manned space vehicle configurations where we always had a crew launch escape system for ascent. We presented this as a concern to the Shuttle Program and to the Center management, but they felt the rationale for this configuration had been assessed a number of times and was acceptable. In an ironic twist, the realities of this SRB failure potential came back to affect me directly ten years later during the Challenger flight of STS-51L, which I will comment on a little later.

With respect to the avionics issues the Program Assessment Office raised—what really happened there was that management said, “Well, Arnie, you're so keen on these issues, we’d like you to come over to the Orbiter Project and lead the Orbiter Avionics Systems Office”. This office was developing the avionics and software that controls the entire Space Shuttle vehicle, flight and mission, even though this equipment was primarily located in the Orbiter. Organizationally, this work was in the Orbiter Project Office under Aaron Cohen, but it also supported Bob Thompson's Space Shuttle Program Office and there was not a separate avionics/software organization in the Shuttle Program Office.

Thus, my work in the Program Assessment Office led to me being put in charge of the avionics for the whole Shuttle vehicle. This was a very interesting part of my career, and I worked on it for the next three and a half or four years. I am quite proud of what was accomplished there. We led the evolution of a number of changes that were a direct result of the areas we had been worried about in the Program Assessment Office. For a number of those years I ran the Orbiter Software Avionics Control Board [OASCB]. It met every week dealing with eight to ten hours of change traffic with IBM, who was building the primary flight software, and Rockwell International Corporation which provided the avionics and the Backup Flight Software [BFS]. This was my introduction into serious program management. I had been the deputy in Skylab and Apollo and had contributed, but now I was in charge of a major element of a program, the Space Shuttle Orbiter Avionics and flight software.

Wright: Each of the positions you described had its own level of responsibilities and details of discovery. Share with us some of the most memorable lessons during that time period, working with those challenges that you encountered during those different transitions of positions up in the Shuttle. Did it become easier as you moved up the line of management?

Aldrich: One of the lessons, which I’ve already mentioned, is to understand in detail the systems that you're the program manager for. I had done that as a primary requirement during my time in flight operations. So it was natural for me to be involved in the engineering and the technical aspects of the programs as a program manager. During most of my time in program management in NASA, I ran a significant program change board and dealt with very detailed technical people, both at Johnson and with the contractors involved. I was comfortable with that and I liked it. If I was going to recommend an attribute that is important in program management, at least with respect to what the programs at Johnson require, I think technical focus and understanding is a very necessary aspect and a skill that program managers need to develop.

At Lockheed Martin [Corporation] I could see some different things as we talked about program management. I was working at LM corporate headquarters in Bethesda [Maryland] on the effectiveness of program management and on any given day across the entire Lockheed Martin Corporation there were approximately 3,200 programs in some phase of execution. All of the associated program managers needed to have adequate training, use effective processes and procedures and be prepared for the things they were going to have to deal with. At Lockheed, they were working on many types of programs, some of which are similar to the ones such as I’ve referred to here at Johnson, but many that are quite a bit different. For example, there are contracts for support services, facility maintenance, information technology capabilities, etc. This is a much broader suite of program types than just those that are like what Johnson does.

At Lockheed, one of the things we talked about a lot was whether you had to be an engineer or, at least, a strong technical person to be a program manager. Philosophically, I agree with the general consensus that you don't have to be. Someone who comes from a business background or some other discipline could well be a program manager, if they have the right desire, exposure and training, they are brought in carefully and they have an appropriate set of processes and procedures to follow. Although I agree with this philosophically, at Johnson, when you're developing and flying very technical human spacecraft, it would be hard to picture a program manager that doesn't have a strong technical focus on what he/she is doing. Otherwise, I don’t believe they would get quite deep enough to understand the implications of the decisions they required to make.

Wright: You talked about the details of the technical side for overall program management. What about program efficiency? What are some of the attributes or the lessons that you learned in how to run programs as efficiently as they need to be?

Aldrich: In some sense I think, I was spoiled in how I was brought up at the Johnson Space Center. I was brought up where, in every job I had, I worked for people that were already doing the job. They were always capable and talented and knew how to execute programs as well as anyone I've ever known. When I worked for Kenny Kleinknecht in Skylab, he had a tremendously effective, well-balanced program going. I learned how to perform just by joining the program and doing it along with him and doing some of it myself. This was also true working with Glynn Lunney. Then I worked for Aaron Cohen and subsequently for Bob Thompson. When I was assigned to these jobs, every one of these leaders already had a program that was balanced, well-planned and executing efficiently and effectively. So I learned how to do the things I needed just by doing them.

Now, you go to Lockheed where they have these 3,200 programs, more or less, and one of the things that entails is that every day some program managers are leaving programs or even leaving the company. New ones are coming onboard and the corporation needs to have processes bring them up to speed and plug them in. So one of the things we worked on was, “How do we assure these people are trained, what do they need to know as program managers and how do they get it?” I still think that on-the-job training is by far the most necessary and most beneficial part of learning program management. But, many times I don't think people have the opportunity to work for people like the program managers I've mentioned, particularly under the overall leadership of someone like Chris [Christopher C.] Kraft [Jr.] These people were strong and competent and were already doing the things that I think were the best in executing programs. I learned by doing it with them.

Assuming one doesn't have the kind of opportunities I had, they still must receive some on-the-job training because being a program manager takes experience and understanding of dealing with people. But, additionally, they also need some formal classroom training in terms of exposure to program management processes, procedures and, in general, the program management aspects that people in the current era and prior eras felt were the best practices to be used. They've got to be familiar with all aspects of program management. They don't have to be an expert in all of them, but they have to be exposed to them. Mentoring is also an important element. Program managers need people that they can go to when they feel stumped and say, “Well, am I doing it right?”, “What am I missing here?”, “Can you help me?”

I guess I had mentors all the time, because they were right there, and my program management training was on-the-job training to an extent that I think may be unique. If you're providing new program managers for new programs and new timeframes, you've got to be sure they are equipped to handle all aspects of the job. Right now I'm on an advisory council that supports an initiative that Mike [Michael L.] Coats started last year to develop program managers at JSC and other NASA centers for the new programs that will be starting in the next few years. Some of my colleagues that I think a lot of are also on this advisory council and we've met regularly during the last year to first help plan this program and then assist in putting it together. We have also participated in developing the various instruction modules which make up the total program. Currently, the first class of about 30 program managers at Johnson is more than halfway through the first 18-month program management training class and the second class is about to begin.

This formal training is intended to provide a depth of understanding of the breadth of program management responsibilities and processes. Students also need to have training and exposure in areas that they will have senior managers working for them so as to know enough about these areas to be sure things are being done the way they ought to be, and if not, what the right additional steps might be. Much of the formal training in this program is provided by Georgia Institute of Technology.

Our advisory council emphasized that the students must also have on-the-job training in addition to the classes and encouraged NASA to provide immediate job assignments, in parallel with the formal training, where the students will accumulate valuable experience they are going to need.

Finally, mentors are also a vital part of this program, enabling the students to talk about things while standing back a little with someone who's been there and may have other views or experiences from other timeframes.

Johnson put this program together over the last year. We had a review recently where they gave a summary of the success thus far and it's turned into a very excellent program. In fact, I mentioned to them that you were going to be doing these interviews and that the things people like me tell you might be good inputs to their program, as well. Johnson is looking to complete this class and be very successful, which they feel they have been so far, but then there are going to be more classes and their program is expected to continue to evolve.

Wright: If you were putting together a class of the new generation of leaders for NASA, what would you be looking for, and what are the attributes that you'd like to identify in these up-and-coming managers? What do they need to have in order to take that next step or take NASA to the next step? What are you looking for in people that will be developed as part of that program management plan?

Aldrich: They need to be energetic and interested in things, not just in some program they're hoping to be assigned to, but any program should be of interest to them. As I pointed out earlier, they've got to be interested in being engaged in the technical and the program accomplishment aspects of a program as well as in managing schedule and budget and assigning things to people. There are some people that are in groups that I've worked with, particularly at Lockheed because it was a bigger and more diverse organization, that view what is needed to manage a program is to find a perfect set of processes and procedures to execute program management. The theory is that if you have a perfect set it's like a cookbook recipe for doing program management, and if we do a good enough job putting that together, then any competent person can be the program manager.

It's very important to work towards a goal like that. But a perfect recipe is, in itself, not enough. There are unique and different things that come up daily in program management and there is no recipe that's going to take you through all of it. You've got to develop the ability to work with people. You must select, delegate, understand and communicate with people on a regular basis. You have to understand how much trust to give them or confidence to put in what they tell you, how many times and how many ways to ask a question. It's pretty complicated. Your question was, “What do new fresh younger people need to move into that and what do you look for?” You look for strength of character, interest, intelligence, ability to work hard and the drive to want to do it. If they want to do it and they have some of these attributes it’s still always a learning experience. Whatever degree of program management you've done up to now, if you do more you'll learn more and your experience base will expand.

Wright: What do you think the hardest lesson you learned through all those years that you've worked in the space-related industry? What's the best lesson you learned?

Aldrich: The best lesson is to have your technical background and be involved in the technical aspects of your program. One of the things I learned in that regard was even more reinforced when I became the Shuttle Program Manager at Johnson. That is the importance of program configuration management. To elaborate, I served as the Deputy Program Manager in Space Shuttle under Bob Thompson briefly, but then I was asked to serve as the Orbiter Project Manager following Aaron Cohen. That was a great job. But it was also a program that was up and running and humming along. I just had to step in and be sure I kept all the knobs turned the right way and get deeply involved. One of the things I started to learn there, and I really learned subsequently when I took over as Space Shuttle Program Manager is the importance of rigorous configuration management.

The Space Shuttle Program at Johnson had, and I think probably still has, the best configuration control process I've seen anywhere. It is very meticulous, well communicated and well documented. When I became the Program Manager for Space Shuttle, I became the Chairman of the Space Shuttle Program Requirements Change Board [PRCB] and got to experience first hand this process that Bob Thompson had put in place. I don't know how he knew to evolve something this rigorous, although I heard it rumored that he did so as a result of difficulties he had experienced while he was the Gemini Program Manager. In any event, it was a really strong process, and it controlled everything in the Shuttle Program with rigorous delineation of configurations, changes and associated rigorous documentation. The overall specification for the Space Shuttle Program is NSTS [National Space Transportation System] 07700. It's a very extensive set of documentation that defines everything about the Shuttle, both in the big picture and in the details, and everything in there was strictly controlled by the program office via the PRCB.

There was a fellow that worked for Bob named Bert [James B.] Jackson [Jr.] who had a lot to do with setting up and running this process. After I became PRCB chairman, Bert ran the process for me and I felt that this process, more than anything else, gave me the feeling of control and ultimate knowledge of what was going on in the program. It had everybody connected. No one anywhere in the program was off doing some other kind of stuff that they thought was what they were supposed to do and that the program wasn't connected with. I'd say that was a very important lesson. I appreciated it a lot, and if I was to ever be a program manager again, rigorous configuration control would be a very strong part of it. A lot of people in the program and in organizations supporting program didn’t like that much configuration rigor, documentation and formality and often complained about it. But to me it is worth the effort that it takes. It makes for a lot of long days in meetings and in reviewing things, but it makes the program work.

I’d like to revert for a moment back to the prior period when I was running the Orbiter Avionics Software Control Board. That was an era in aerospace evolution where the processes for developing software weren't as rigorous and common across different organizations as they are today. Now, these are quite rigorous and there are industry accepted formal processes for software development and they are commonly used by lots of people that do this kind of work. But back when the Shuttle was being developed all that hadn't come together. Software was still pretty new, and the Shuttle had a lot of complicated software.

I think one of the strengths that caused the avionics and the software to come out so well is that we insisted on writing down the detailed requirements for the software—specifically, exactly, what's supposed to happen—in every little technical area and writing it in English so that you and I could understand precisely what the performance was expected to be. Then someone could go away and code the software to do exactly that, and someone else could write the test procedures that would be used test that software to see if it was correct. In that era, many different entities that were developing software would write down the broad top level requirements in English. But when they got down to the detailed requirements they'd write these in software machine language. Thus the engineers (and you and I) hoped they got it right but we never could be quite sure until the software was built and fully tested. This could lead to communication gaps as well as delays to fix problems after the software had already been coded.

The JSC Flight Software Division was responsible for the contract with IBM to develop the primary Orbiter flight software. When I arrived on the scene, the plan was to write all requirements in English in books called Flight Software System Requirements [FSSRs]. These are big books! Once they are baselined, they control every single word in English that defines the specific coding in the software. I believe that was a tremendous strength in the evolution of the Space Shuttle flight software. By the way, the Space Shuttle avionics and software have performed admirably for many years, and it was one of the evolving technologies that made the Space Shuttle possible.

Another thing I learned about program management in running these change control boards and dealing with all these technical subjects is that you should you listen very carefully to people who would present things to you. You would frequently hear “we need to do this because we're going to change this or that or add this or something else and we need money to do it.” But it wasn't just that they needed money for it and schedule availability. Most important was to determine whether it was really necessary and the right thing to do.

I always tried to develop the habit of listening in-depth to everything someone presented to the level of detail they presented it. The purpose of that is to fully understand what the changes are and why they recommended making them. If the presenter could not explain it to me so I could understand it, I had a strong suspicion he/she didn't understand it either, so that's another ground rule of mine. If people can't explain it to you in a way that's clear enough that you can understand it well enough to make a decision they simply have more work to do. You’ve got to understand it no matter how time critical the situation may seem.

There's another thing I wanted to comment on in this discussion and that’s the management style of the people you worked for. Every program manager works for someone higher up. Over the years, in NASA flight operations, NASA program management and then in the jobs I worked in Lockheed, I always had a more senior person who I reported to. So I got to see a lot of management styles. Some people would be very much engaged with you and into what you were doing. Even though you were the program manager, you were responsible and accountable, they'd be right in there with you. Other people, unless you fall flat on your face and have some terrible problem, would hardly talk to you.

The reason I bring this up is that one of the most important parts of my development during these years was working for Chris Kraft. In the 48 years I worked in aerospace, the best management style for a senior person I worked for is the one that Chris utilized. He would clearly assign you a job because he had confidence you could do it. Then he'd leave you to do it and be accountable, and he wouldn't come down and muck with you day-to-day. But what he would do is once a week, faithfully, give you an hour with him. It would be your meeting. You'd go in and you'd talk to him about what you thought was most important, what you were having trouble with, what things maybe we should be doing that we weren't. He was always up to speed on everything that was going on, so he would be prepared to talk about any of that. If someone had brought some problem to him in your area that they were concerned about, during that time he'd ask you about it.

Wright: Bet that could be an interesting conversation, couldn't it?

Aldrich: Yes, but it was wonderful. You never felt like he was stepping in and directing you this way or that way. He was paying close attention, but he wasn't on top of you every day and he was letting you go away and solve your problem. It's a very excellent way also to bring people up and help them improve. I think it also gets the very best out of them.

Wright: It seemed to incorporate a lot of the aspects that you talked about. He served as a mentor at the same time he was a teacher and a confidant and an encourager, but still taskmaster. He knew what you were doing.

Aldrich: And he's watching you. But he's not meddling. It was very, very fine.

Wright: Great way to learn.

Aldrich: Through all of that, if I come back to where we started, still the most important part of becoming a good program manager is on-the-job training. If you don't bring people up through an on-the-job process to some degree, it's going to be hard to get them to where you need them to be to run a program.

Wright: When I was listening to you going through these different areas, there was a lot of planning involved in how things were done. Share with me why that's so important, and if you saw anything through your career that proved that good planning really is worth the time that it takes for a good result.

Aldrich: These programs are incredibly complicated with complex interactions of different system elements, different industry partners and different organizations and people involved on the government side. Without significant, careful planning there's no way you can have a successful evolution of technical development together with the business aspects of a program; the schedules and the finances. And then with Shuttle, after you start to fly you must deal with the flight manifests, the sequencing of vehicles and the capabilities of the support facilities you are required to use. It is so complicated that planning is a huge aspect of the program management job. You have to be watching what's going on and taking care of problems, but you also have to be focusing on all of the things that are going on simultaneously: how they converge and how to keep moving toward the program goals you want to achieve. Planning is one of the biggest aspects of program management.

Wright: Underlying everything that you've done these last almost 50 years there's been a level of risk that has been attached to all the decisions and planning, scheduling. If we could spend some time talking about risk and risk mitigation activities and assessments—talk to us about those aspects and how you plan. What’re the lessons and the knowledge that we need to make sure that we are adhering to the right level of risk?

Aldrich: I'm glad you asked about risk management, because right now the subject of risk management is a very hot subject in the industry-wide program management community. It seems as though everyone is looking for some magic solution or set of tools that can solve problems that we previously weren't dealing with effectively and keep themselves out of trouble. I have a little different perspective on risk management than some of the very extensive activity that goes into finding new mechanisms “to do” risk management. In my opinion, program management is risk management. It's always been risk management and years ago I operated day to day, every day, from a risk management perspective on the program. “What are the risks in my critical systems that I am depending on right now? What are the risks in my schedule? What are the risks in my budget? What are the risks that the people supporting me are adequate or maybe about to change and will I have to do something about that?”

What did we say a minute ago? Program management is planning. Well, program management is planning, but program management is also risk management. I think years ago before it was such a commonly discussed aspect of program management, it was nevertheless, at least at Johnson, alive and well, and that's what we were doing, and we knew we were doing it.

Now that said, the new emphasis on risk management and the new tools and processes that people are using for risk management are excellent. They are great augmentations to the fact that the program manager needs to be conscious of risk management at all times. These new processes and some of the capabilities that are now software tools and capabilities to organize risk management in computers or in documentation in an effective way are very useful. Used correctly, they can get everyone in the program, and maybe even beyond the program, involved in participating in risk management and thinking about it. So it provides a flow of information to the program manager that is very useful and it sensitizes areas of the program that might not be focusing on risk management to know that is important. I don't think it's a new thing that people are starting to do risk management. But these new initiatives are making risk management more effective.

If you do have a risk management process for your program, the program manager needs to be the one who runs it. The program manager must not delegate someone to go off and run the risk management for him and then look at it every other month. Managers that do that are sidestepping the issue of risk management, and they are filling the square by having a staff that's off doing something in that area. I've seen all these tendencies I've talked about. I think that risk management is good. I think the new processes are good. There are many choices now of risk management software as well as books dealing with ways to do risk management in a program. As long as the program manager leads the effort, these new techniques enhance the benefit of something he or she should have been doing all along.

Wright: You were there during [Space Shuttle] Challenger [STS-51L accident], and of course you were closely related during [Space Shuttle] Columbia [STS-107 accident]. What improvements do you feel like need to be done in some of the management processes that are associated with risk, other than the one that you just mentioned? If the program manager is the person that's responsible for risk management, what processes can that person put in place that they're doing that job well, as well as doing all the rest of the aspects of program management well? How do they do it all?

Aldrich: Well, that's the art of program management. I don't know as much about Columbia, because I've only read about how those events transpired. But with Challenger I was heavily involved and I think the risk management processes were there. In fact, one of the things I ask myself regularly about the Challenger is, “What could we have done to prevent what happened?” The facts of what happened have been well developed and documented by the Rogers Commission and I think they are complete. I don't believe there are any hidden factors that haven’t been brought out. We know what happened. But then you say, “How did the management for that launch allow it to happen? Why did it happen?” We had the full series of formal reviews, we had the right assemblage of people and we had the right trust, I think, between the people involved.

In reality, too many negative things converged at the same time and our regular processes let some things get through. None of the people involved, if they’d known what we now know after the fact, none of us would have allowed it to happen. The big issue with the Challenger accident was of, course, the cold ambient temperatures coupled with some design weaknesses in the solid rocket motor field and nozzle joints that hadn't really received appropriate program-wide attention.

After the Challenger did not launch on Saturday, January 27 [1986] as a result of unacceptable crosswinds for a potential return-to-launch-site abort, the program held a Mission Management Team [MMT] meeting in the Launch Control Center. The meeting included most of the senior management related to the program including two center directors, all of the project and program managers and the required technical support people to discuss whether we would be able to launch the following day. The principal issue was the fact that it was going to be so cold that night. The weatherman stated that it was going to be approximately 23 degrees [Fahrenheit] overnight and the program had not previously experienced anything like that. The launch mission rule was that we could not launch if the ambient temperature was lower than 31 degrees. We had discussed this on several prior missions and it was pretty widely understood that was what it was. The temperature projection was that even though it would be in the 20s overnight, that it would be above 31 degrees by launch time and there was a general feeling within the MMT that this might be acceptable.

The action of the MMT meeting was to have each project go away and evaluate all aspects of their technical projects—the Space Shuttle main engines, the Orbiter, the Solid Rocket Boosters, the External Tank and, of course, the launch facilities—and come back and report on whether they found any constraints or concerns with proceeding to launch. I believe the question was well-asked and understood, and the team reconvened a few hours later. Each of the projects reported that their part of the system would be okay if temperatures returned above 31 degrees by the time of launch. There was a minor temperature issue reported by the Solid Rocket Booster Project—nothing to do with the field or nozzle joints, but, rather, a system component in the aft skirt—and they felt it was not going to be a significant problem. There was also some instrumentation in the Orbiter that would be below its limits but the Orbiter Project didn't feel that that would be a problem either and could be managed. Thus, the MMT concluded that it was all right to proceed with tanking and to plan to launch the next day.

Overnight things changed. However, the Mission Management Team never reconvened to fully address these issues. As subsequently became well known and reported with respect to the Challenger accident, the Thiokol Solid Rocket Booster technical community in Utah became highly concerned when they learned of the projected temperature profile. They were concerned about temperature effects on the SRB nozzle and case joints, and associated seals, where they had experienced some flight problems in the past. In response, the [NASA] Marshall Spaceflight Center [Huntsville, Alabama] held a lengthy series of telecom meetings that evening between KSC, MSFC and Thiokol to review the concerns and in the end it was concluded that it was acceptable to launch the following day. Even though the Thiokol technical community never agreed, their management made the decision to proceed.

Another issue was related to the water systems which were located all over the launch complex for spraying things down. These are in addition to the water deluge systems that turn on at ignition to provide sound suppression for the Shuttle’s large engines. The concern the Kennedy people had was that the water pipes that run all up and down the launch complex would freeze and break and water would spew out and form ice. The Kennedy team dealt with that problem by turning the faucets on slightly to trickle the water from these systems located on the launch complex during the evening hours to prevent water line rupture. However, the trickling water also formed ice on the LCC [Launch Control Center] which became the real crux of this issue. Both the MSFC [Marshall Space Flight Center]-Thiokol meetings and the formation of ice from the water drains happened after the final MMT where everyone had concluded there weren’t any big issues and that we were in good shape to proceed to launch. Early the following day, MMT members reported to their respective positions in the Launch Control Center three, four or five hours before liftoff. Each person had a place to be and a job to do. The senior management gathered in an area in the firing room and everyone still felt ready to go.

The SRB issues had been dealt with at the MSFC Project and Center level overnight, but they were not raised in the firing room or to the management team or injected into the launch countdown process. The water issue and related freezing had been worked primarily by Kennedy using procedures which had been previously developed for such a situation. The trickling water had caused a lot of ice and icicles on the launch complex. As a result, I was asked to lead an offline review of the ice on the LCC and MLP. The principal focus of this review was whether the ice conditions could have an effect on the launch, particularly whether any falling ice would hit the Orbiter, which could cause damage to the Orbiter thermal protection system.

Project management at the Kennedy Space Center, Orbiter project management and the engineering support team at the Mission Evaluation Room in Houston all expressed that they felt the ice situation was acceptable and recommended that we proceed to launch. Rockwell, however, raised a concern stating that they felt we were adding some additional amount of risk, but they didn't call for a no-go. Thus, though this ice accumulation was more than we had expected, we accepted it. But there was never a discussion of the concern that Thiokol [Morton Thiokol Incorporated] had had regarding the boosters. It was not known to the senior program management team assembled in the firing room. It's really hard to believe, but it was not known.

As the countdown proceeded, we called at least two delays to let the day get warmer and for additional ice inspections. The original launch time was scheduled for approximately 9:00 a.m. and we slipped it forward almost to noon. By that time, ambient temperatures were well above 31 degrees, all ice had been removed from the sound suppression troughs and the Mobile Launch Platform and ice was melting on the Flight Service Structure. And so we launched. 73 seconds later the right hand SRB separated from the External Tank and STS-51L disintegrated with the loss of Challenger and the crew.

I had sat all morning in the firing room with Bill [William R.] Lucas, the head of the Marshall Space Flight Center, Stan [Stanley R.] Reinartz, the head of the Space Shuttle Program at Marshall, and Jess [Jesse W.] Moore, the NASA Associate Administrator for Space Flight beside me. We sat there through the whole count and never once did MSFC talk about or even mention the solid rocket boosters being a possible concern. Everybody was still “go.”

These are people I'd worked with for years and had confidence in. I felt as though we were a well-integrated team working together, however, these issues were not worked as they should have been. I don't believe the team had enough information the day before at the MMT meeting to not proceed with tanking and the countdown. I think we were right saying we ought to continue, at that point. However, I’ve thought many times since that we should have called a Mission Management Team meeting for launch morning. It would have been disruptive because everybody has a place to go to and job to do on launch morning and the countdown goes fairly quickly, even though it's quite a few hours. But we should have called the whole team together and talked about whether everybody was still “go.” I think the discussions of the solid rocket booster joints and seals the prior evening would have come out, cooler heads would have prevailed and we would not have launched on that day.

A morning MMT meeting would also have further reviewed the ice situation. I think that Kennedy believed that it was acceptable to proceed with the launch as did the Orbiter Project and the Houston MER [Mission Evaluation Room] team. But even though no falling ice impacted the Orbiter during launch, the Rogers Commission assessment was that the situation was more of an unknown and risk than the program should have accepted.

A morning MMT would have required the center directors, the Associate Administrator and the various other senior program and project managers to attend. I wish I had made such a meeting happen. It was not standard and it’s not normally done during a countdown, but in hindsight it certainly was necessary in the STS-51L case, particularly if we were going to proceed toward launch.

Following my morning review of the ice situation, I made the decision to recommend going with the KSC, Orbiter and MER recommendations on the ice because I felt the situation had been well analyzed and was going to be acceptable—which it was, no ice hit the Orbiter during launch. However, there were other issues with the ice that were never brought up. Among these was the crew access to the Orbiter, which, since it was not brought up, was probably acceptable, but also the pathway over to the escape buckets that could get the crew away in the event of an emergency. That north side of the LCC was quite covered with ice. What I think about all of that is that since the ice was a known problem that I was working, I should have insisted that I go out and see it for myself if I was going to make a decision about it. That would have been disruptive and nonstandard. But I could have made it happen, and I wish I had.

Wright: You've had a lot of years to think about what you could have done. Unfortunately, in program management life, schedules and budgets and structures of how things are only permit you a small amount of time to make those decisions. Like you mentioned, you rely on people. Which leads me to my other question: you worked so closely when you were at NASA with those teams of people, and then after three and a half decades you moved to the contractor side. Could you share with us the differences of working for the success of a space agency, but where on one side you were the NASA person and on another side you were a contractor? Share with us those differences and what different lessons you learned from being on the contractor side than when you were working on the NASA side.

Aldrich: Let me finish one more thing about the Challenger, because you correctly said I’ve had a lot of time to think about that, a lot of years. It's still hard for me to believe that the people we knew and trusted that were part of our team from Marshall didn't talk about the SRBs on launch morning. They could have said, “We've reviewed it, there were concerns, here's what they were, we think it's all right.” They didn't say a word. I think if anyone from Johnson had heard of these deliberations they’d have said there's no way we are going to launch until this is better resolved.

In Lockheed, I never did program management. One of my lessons about contractors that I would talk about, still from my NASA experience, is that as a program manager you need to team with your contractor—don't treat your contractor like an employee or someone you've hired to do something for you. Treat your contractor as a partner. Work with them, communicate with them, because they actually want to succeed just as much as you do, and they want to contribute everything they can. It's a very important aspect of good program management. I've seen programs where there's huge tension and distance between the contractor and the government program manager, and it's very hard to have a successful outcome, at least within the schedule timeframe and financial parameters you're hoping to achieve. Maybe in the end you can eventually hammer something out. Here again, I was lucky to primarily work with Rockwell, McDonnell Douglas and IBM over various programs and timeframes. It was all very satisfying. They were just as much a part of the team as anybody on the NASA side and they worked at least as hard in driving our mutual successes.

Wright: When we were talking earlier about all the different projects that Lockheed had, the 3,200, and you were mentioning that people within those projects and programs changed or they left the company. I know that a lot of your colleagues that you started with were with you a long time before they all moved on. What would you tell someone that is trying to build a team with good program managers? How do you improve issues or aspects that will improve management performance where these people that are coming up as young and upcoming managers will stay and spend long tenures with the space agency?

Aldrich: The kind of work we did and most of the aerospace industry still does today is very motivating to people. I don't know many people who have been heavily involved in the programs at Johnson on space vehicles and space missions that haven't been so involved and so in love with what they do that they just want to stay. They may want to work in a little different aspect of it, or they want to find some way to learn more, but they certainly don't want to just drift off and go somewhere else. The people that I knew that left, mostly left because they'd had a pretty long career, and they felt now it was time to move on.

Wright: What do you tell the people that want to move into the space exploration business? Why would you encourage them to do that?

Aldrich: There are a lot of different aspects of space exploration. What I've been talking about, mostly, are manned programs, but you can work extensively in space exploration with out having to be a manned space enthusiast. We do so much with robotic missions now that are so great for science and so great for technology development that if you're an engineer and you want to work on something meaningful and something that's at the forefront, it's just one of the best places I can think of to be. I believe there are still many engineers that want to and will do these things. The pipeline people talk about maybe not being as strong as it once was, but it has many excellent people and they are motivated just like the ones that I've talked about that I worked with in the past.

Wright: I know that you brought some papers with you. I was going to ask if we wanted to look through some things or some other comments and aspects that we haven't talked about yet.

Aldrich: Mostly I was making notes on what you asked me. The first question was, “What are the best practices and processes I see in program management?” I think I mostly have already ticked those off. One is a desire to be engaged in detail in the technical aspects of the program. A second is assuring a program employs rigorous configuration control. I mentioned specifying software requirements in English so the broader community can understand in detail what's going to be developed. One should listen carefully to presenters and make sure they're telling you a story that you (and they) can understand before you take any action. I also discussed the importance of risk management and of teaming with your contractor. I talked about Chris Kraft's management style because I think, from my experience, it's pretty unique. I'm sure he's not the only person that’s ever done it that way, but it was well done. In the end, you have to experience all these things on the job. You can gain appreciation for them in the classroom or by talking to people, but you have to go do them yourself before you're going to be really good at it.

One of your questions is about memorable days. We talked about the launch of Challenger (STS-51L), and that was one of the most memorable days of my career. But there was another very memorable day for me, as well—the launch of the next flight, two and a half years later, with Discovery (STS-26) on September 29, 1988. During the period leading up to the Challenger launch I had been the Program Manager for Space Shuttle (NSTS) at the Johnson Space Center and Jess Moore was the Associate Administrator for Space Flight in Washington. However, I reported to the JSC Center Director as part of the “lead center” NASA program management concept.

After Challenger I was asked to come to NASA Headquarters in Washington D.C. and become the Director of the NSTS Program, a job that hadn’t existed for a number of years prior to Challenger. This resituated some of the programmatic responsibilities that I had as program manager at Johnson and provided more comprehensive authority over the Space Shuttle projects and related budgets at all of the NASA Centers involved in the program.

As the program worked through the failure analysis and redesign of the Solid Rocket Boosters following Challenger, I set up a series of formal reviews looking at all aspects of the Space Shuttle systems for weaknesses and risks. There were, in fact, a lot of accepted weaknesses that we'd agreed to live with up to that time.

Specifically, there were a number of things that engineers knew ought to be improved prior to the first flight of the Shuttle on Columbia. However, the first flight had been critically important to get off and the program had reviewed a number of these things and determined that they would be acceptable for first flight and could be improved later in the program. Beyond that, almost every subsystem area in the Space Shuttle had things tucked away that were known that ought to be improved. But once the first flight went, then the second, then the third and so on, there was never a time or the budget to step up and say, “Well, we’ve got to stop and fix all these things to make the Shuttle completely right.”

So after the Challenger accident I set up a series of reviews within the PRCB structure to look at the Shuttle across the board and review system risks, talk about them and prioritize them. This wasn't just my original idea. It is exactly what I witnessed George [M.] Low do following the Apollo fire. George Low reviewed the total Command Service Module and Lunar Module during the time the Apollo program was recovering from the fire and made extensive changes to those vehicles that made them significantly better. These changes weren’t particularly related to the fire, but dealt with other system risks and weaknesses.

So, we also did that on the Space Shuttle after Challenger and incorporated over 400 changes to the different elements of the Space Shuttle vehicle. Some these were software changes such as improvements to capabilities for emergency landings, but most were for various hardware improvements that subsystem managers already had in their little notebooks that really ought to get worked on. As we approved these changes, most had priority for the first flight after Challenger but some of them were too major for that. These, such as the new turbo pumps for the Space Shuttle main engines, were approved with license to come in with later program effectivity. These were new Pratt & Whitney turbo pumps for the Rocketdyne engines that were to be more robust the original Rocketdyne ones. They were approved by this process following Challenger, but it took a number of years of development, testing and additional funding to get them ready. Of the changes 400 changes we made, only about half a dozen dealt with the solid rocket motors. The others were improvements to other systems in the Space Shuttle which were not directly related to the Challenger accident and I believe the Shuttle was a significantly better vehicle when it returned to flight.

There are a couple of other things in my Shuttle career that come to mind as particularly memorable. During the time I was the Orbiter Project Manager, we completed the fabrication of Discovery and of Atlantis. I had the opportunity go to Palmdale [California] and give an acceptance speech for NASA at each of their rollouts. It was quite a thrill, particularly for Atlantis, because at that time Atlantis was thought to be the last Orbiter and the workforce at Palmdale had finished their work of producing new orbiters. I was later told that the speech I gave that day had been used in Rockwell training and inspirational material for their employees for some number of years after that, because it highlighted so many things about their performance. Palmdale continued as a repair and refurbishment site for the Orbiter, but at the time of that speech it was thought to be the last construction. Then Endeavor was approved and it came along later as yet another new Orbiter to be assembled.

I’d like to mention two other memorable days that occurred early in the Shuttle flight program. The first Space Shuttle flight, STS-1, had been delayed several years by the time we got to it, for a variety of problems including TPS [Thermal Protection System] issues with the Orbiter. When we finally got to the countdown, I was still in charge of the avionics and flight software. At T-20 minutes the backup flight system [BFS] that supports the primary avionics was supposed to come online, however, it did not initialize correctly. The BFS is a system that is manufactured by Rockwell while the primary avionics flight software, with its four redundant computer strings, is all provided by IBM, and had been operating well throughout the countdown. Thus, everyone initially blamed this problem, associated hold and one day delay on Rockwell. It turned out that actually the initialization of the BFS came as a transfer from the primary system, and it was an IBM problem. The problem was fixed overnight and we launched the following day, but this was a good lesson in integrated system performance.

The Orbiter has four primary computers providing two-fault redundancy (fail operational/fail safe): you can have one computer failure and continue the mission, after failure of a second computer the system is still fail-safe but you've got to plan to terminate and come home. On one of the early Shuttle flights, we had two computers fail in the middle of the flight. It's the only time that I know of that it ever happened on the Space Shuttle. There was some fair amount of concern because even though they were different failure scenarios they didn’t occur too far apart and we weren’t sure what had caused them. However, we were able to bring one computer back online and continue with a successful mission. There are a lot of memories like this that you could talk about that probably aren't written down very extensively but some people still remember quite vividly.

Wright: Those are good ones.

Aldrich: Going back to the first flight, STS-1, the big thing for me with the avionics was Orbiter control during entry. In those days I hadn't done much with ascent. The software that controls the main engines was part of the MSFC main engine project. Thus, I hadn't spent a lot of time being engaged in ascent, however, I'd spent a lot of time on system performance during reentry. After the Shuttle does its deorbit burn there's no atmosphere yet and its attitude is controlled by its small maneuvering thrusters. Then, as it starts to pick up atmosphere the thrusters don't have as much control because the atmospheric pressures are becoming quite strong, and the vehicle starts using its aerodynamic surfaces in combination with the thrusters.

At the point where the thruster and aerodynamic forces have to be blended there was no way to fully test those conditions except fly the vehicle. It had been analyzed thoroughly and tested in math models and flight simulations, but I had never been quite confident in the degree of control margin which the vehicle had in this flight region. We had done the very best that could be done without flying it and now we were flying it with John [W.] Young and Bob [Robert L.] Crippen on board. So another memorable time was when I was sitting there in the Control Center, with my avionics hat on waiting for Columbia to come out of blackout. It turns out that the margin was there and there was good margin. It had been well-analyzed, but we couldn't prove it to ourselves very well until we flew it.

Wright: That was another good day.

Aldrich: Another good day.

There are two other things about program management that I meant to mention: One—A program is not a democracy. The program manager needs to know that he or she is in charge and that they are accountable and responsible for program performance and success. There are some people in the industry today who believe that you should get everybody together and basically vote on various courses of programmatic action, and that's not the way it is. In the end, the program manager needs to give everybody their say, weigh things with the people that they respect, but in the end they have to make the decision. It's not a democracy.

Secondly, I’d like to briefly discuss Integrated Product Development [IPD]. The industry has been experiencing a period, to a degree within NASA, but to a much larger extent in the Department of Defense [DoD], where managing programs using integrated product teams (IPTs) has been in vogue. What this really entails is breaking a program down into specific small product centers that each manage an element of the program. Each team has its own schedule and budget and members of all project organizations are engaged on the team (cost, schedule, technical disciplines, manufacturing, test, etc.) From many perspectives, this can be an effective structure for managing a program. While IPD became popular in the early 1990s as a new, innovative approach to program/project management, I felt that it reflected what we had always done at the Johnson Space Center and much of NASA. JSC always has had program committees and panels where program representatives, technical disciplines, flight organizations, program control people, etc. were brought together to manage integrated aspects of programs.

When NASA went through the investigation which eventually led to changing the Space Station Program from Freedom to the International Space Station, an independent, multi-disciplinary panel, led by MIT President Charles M. Vest, conducted a review of Freedom and, in particular, its schedule and budget issues. This group criticized Freedom quite strongly because we didn't use integrated product development as the core of the overall program management structure. That was a time when IPD was evolving to become a principal approach to running programs within DOD and it was touted as a new way of thinking on how to do programs. As I previously stated, I felt that NASA had always been sensitive to inter-organizational integration in the way it did program management, we just didn't use all the new IPD buzz-word terminology. But in the context of the review panel’s language and in what they could understand from what people they interviewed told them, they didn't sense NASA had embraced such concepts on Freedom. Thus, they concluded Freedom was behind the times and this had led, at least in some degree, to the problems which the panel had been assembled to review. Accordingly, based upon their recommendations, major changes were made in the structure of the NASA Space Station program.

The IPD management style is basically an effective approach to program management and DoD has used it extensively. However, as with all management approaches, there is the potential for pitfalls which can lead to trouble. For one, you've got to be careful that on the integrated product teams someone is in charge of each team and is accountable and responsible for the outcome. If the teams are just a collection of people who all have inputs and they try to run them as democracies they can be ineffective or counter-productive. The “democracy” approach sounds like what you were trying to do—everybody gets a voice and an input—but in the end someone has to be in charge. This approach must be followed across the whole integrated product team program structure so that each team really has a responsible, accountable person and then this becomes good way to operate. Equally important, the program must have an overarching “integration” integrated product team at the top of the IPT structure where each of the other IPTs is represented. Otherwise the work of each of the IPTs won't fit together and dovetail into a functional program.

Two other thoughts about doing program management: I talked about being in charge and being accountable. But, the program manager can't do everything. You have to have good people that you trust and have confidence in who run the key aspects of the program for you. You have to stay in close contact with them, know what they're doing and help them if they get in trouble. You have to have people you can count on. Let them do their job, just like I was talking about with Chris Kraft’s style of management. Having strong subordinates certainly benefitted me in the programs I ran. I always had good people working for me that I could count on, and they did great things leading to program success.

One final area I’d like to comment on is mentoring. Program managers should regularly seek the advice of people outside the program that they have respect for and they think could give them alternative perspectives and ideas. There are always senior people in one’s organization and other people that have or have had similar responsibilities and jobs. A good program manager should give consideration to contacting such people, staying in touch with them and giving consideration to what they tell you.

Wright: Good idea. A lot of good information.

Aldrich: You also asked about other people you should talk to. Some of the best that I ever worked with in this business are no longer with us. George Low and Sy [Seymour] Rubenstein, with Rockwell, were two of the very best and also Bill [Howard W.] Tindall [Jr.] Bill probably isn't categorized as a program manager, but he was one.

You must already have a list that probably contains most of those who I would suggest. In any event, you must talk to Chris Kraft. He was in charge of many of the highly successful things at the Center. **Aaron Cohen also is a very knowledgeable person in this regard and he would tell you things about program management that are important. You should also consider talking with Bob Thompson, Owen [G.] Morris, Glynn [S.] Lunney, Dick [Richard H.] Kohrs, Tommy [Thomas W.] Holloway, Bob Crippen, Brewster [H.] Shaw, Ron [Ronald D.] Dittemore and Bill [William H.] Gerstenmaier. For software management, I’d talk with John [W.] Aaron.

There also are quite a few people you might consider at Marshall. One I definitely think would be good to talk to is Bob [Robert] Lindstrom and also J. R. [James R.] Thompson [Jr.], who now is with Orbital Sciences. You might also consider Jim [James B.] Odom, George [B.] Hardy, Joe [Joseph A.] Lombardo and Gerald [W.] Smith.

Wright: Thank you for all your information, and I'm sure we'll be talking in the future.

Aldrich: You asked about notes and things, and I'm not sure what you're looking for there, exactly.

Wright: We do have a JSC History Collection, and that is used quite often, especially the last couple of years as Constellation has been up and going. One of the goals of the Chief Knowledge Officer is to try to make sure lots of papers, documents—whatever information that might have been important to someone along the way of programs—makes it into that archive. Sometimes people left their files at the Center, and they made it where they needed to go. A lot of that's, of course, at the National Archives. But she's wanting to see if there are people that might have personal papers. There are some that have taken their papers. Mr. Bond, Aleck [C.] Bond, has given his, and Carl [R.] Huss's papers are there.

Aldrich: I don't know that my papers are that organized. I don't have a diary or that sort of thing on the programs I managed, which almost sounds like that might be what would be most useful.

Wright: It could be. The archivist that's there is Shelly Henley Kelly, and she's gotten boxes—I don't know if you remember a gentleman named Mr. [Louis] Leopold.

Aldrich: Yes, Lou.

Wright: We've talked to him. Last time we were there, we put about seven or eight boxes in the back of the vehicle and brought them down to the archives for him. They're just papers that have been put in a box, and they may not get to right away, but at some point Shelly will go through them and organize them and label them and be able to put stuff into the database of what's there. But in the meantime they're kept someplace. Bobby [Robert A.R.] Parker—when he left JPL [Jet Propulsion Laboratory, Pasadena, California], he sent his stuff down to the history archive here in Houston. Same thing. Took her a while to go through all those papers. She's trying to at least collect them so that they can be there, and people can at least go through and start making use of them.

Aldrich: I might look through my boxes, because as I say, they are not very well organized and some of them are not connected very well. I did come up with one thing, though, I thought of right away. The Challenger was not the only launch in January of 1986. Columbia launched earlier in January on STS-61C, and some of the types of problems we had with the launch attempts that ended up so badly with Challenger, we had in spades with STS-61C. You probably don't read much about these things anymore. The thing you will read is that we scrubbed six times before we launched on the seventh attempt. After all that happened, I wrote a memo, with assigned actions, to the Shuttle team addressing all of those scrubs and how avoidable they would have been if we'd just been more on top of things. So here is a copy because it might provide a series of thought-provoking things for a program manager.

Wright: Great. Thank you.

Wright: Is it all right if we scan this in and attach it to your transcript as part of this?

Aldrich: Sure. You can keep it.

Wright: Okay, good.

Aldrich: You started off asking about Columbia and Challenger. Here is an article I found around 2003. It was written by a man that was working on the O-ring analysis at Thiokol at the time of the Challenger accident. It discusses a theory of a common cause of the Challenger and the Columbia accidents. It's not talking about flaws in management style as a common cause, which has been pretty widely discussed and debated. This is talking about Max Q [Maximum Dynamic Pressure] and upper-level winds and how they potentially were a contributing cause in both of these accidents. It is interesting reading, and I haven't seen any other reference it. But this was in the AIAA [American Institute of Aeronautics and Astronautics] magazine, Aerospace America, and I think it was in 2003, not long after the Columbia accident.

Wright: Well good. This'll be great information to add as well.

Aldrich: I don't know if you want my resume. This is my detailed one. I have it so I can keep track of all these details. No one else would want read all of it, but it's complete, which is nice.

Wright: I'd love to have it. Thank you. Because the one I have, as you know, stopped a few years ago.

Aldrich: I had to have one that was much more brief for Lockheed when I worked there, because no one could do anything with something like this.

Wright: It gives us a lot of good background information, so I thank you for bringing all of these things and for spending the morning with us with such great information.

Aldrich: Two more items of potential interest. There are a lot of books that were written about the Challenger, and many of them were written pretty early on following the accident. At that time there was still a tremendous amount of emotion flowing and related facts were not all uncovered or well sorted. I think some of these authors got off track, but there are a couple of books that I believe are pretty good if a program manager, or anyone else for that matter, wanted to read about some of what transpired. There's a book written by a fellow in Scandinavia. The title is No Downlink. Do you know about that book?

Wright: No.

Aldrich: No Downlink is the title. It was written by Claus Jensen in 1993 and was translated in English by Barbara Haveland in 1996. Claus’s accounts come across to me as quite factual based upon what I remember. He doesn't draw a lot of conclusions, but occasionally he does. I won't say all of his conclusions are exactly what I conclude, but it's pretty accurate. For details of what happened it's probably more readable than the Rogers Commission stack of volumes.

The other one that has seen a lot of popularity is Challenger Launch Decision [The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA] by Diane Vaughan. It deals extensively with the psychological aspects of management and Challenger. Again, I don't know that her conclusions throughout would synch with what I would conclude, but it's a very thought-provoking analysis and a good book to maybe spend some time with.

Wright: All right. Thank you so much for coming in.

Aldrich: It was my pleasure.

[End of interview]

At the request of the current Space Shuttle Program Manager, and as part of the JSC TacitKnowledge Capture Project, Mr. Aldrich wrote a paper detailing some of his experiences, best practices, and lessons learned as a former Space Shuttle Program Manager.

Read more about his memories of the Challenger accident (STS 51-L) and NASA's return to flight with the launch of Discovery (STS-26) 33 months later.