NASA Johnson Space Center Oral History Project
Edited Oral History Transcript

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

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

Aldrich: Your interest today is about program management and how you prepare for it and what attributes are strong attributes or things you ought to have. One of the things I will mention a couple times, and I believe in a lot, is that in the programs that we do in NASA and particularly at the Johnson Space Center [Houston, Texas] really require a pretty in-depth understanding technically of the program and the systems that are involved in the program. In order to arrive at the point I was at when I went into program management, I had quite an extensive background of spacecraft systems in the Mercury, Gemini, and Apollo and Apollo-Soyuz [Test Project, ASTP] Programs, the Skylab Program. I did move into program management midway in the Skylab Program. Then on with the CSMs [Command Service Modules] for Apollo-Soyuz. But prior to that, the first third of my 35 years at NASA I worked in the flight operations organization and in the development of the Mission Control Center and the remote sites and the flight procedures.

All of that gave me a pretty strong background in the details of those programs, and I evolved into becoming one of the senior spacecraft systems console operators for Mercury. Then for Gemini and Apollo I was the leader of the organization that trained and used and applied the spacecraft system monitors for the Gemini spacecraft and for the Command Service Module on Apollo. Through all of that, learning the operations and the management and then the spacecraft systems in quite a bit of detail, provided a breadth of background that I thought was a very strong asset when I first moved into program management. I knew the program so well, and I knew in-depth the technical aspects of it.

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 of Apollo 15, I transitioned out of Mission Control and spacecraft systems management, and I went to work for Kenny [Kenneth S.] Kleinknecht as a deputy program manager in Skylab. Then not long after that, we were using the Apollo Command Service Modules also to go to Skylab and to do the Apollo-Soyuz with the Russians, and I went to the Apollo Spacecraft Program Office, and I was deputy program manager to Glynn [S.] Lunney for the Command Service Modules. I was back in the same programs I'd been doing mission control for in the early phases of program management.

During that time period of the Skylab and the Apollo-Soyuz, the Space Shuttle Program started up and actually became very real, and hardware became developed, and it was a strong program underway. When Apollo-Soyuz ended, that was the end of the Mercury-Gemini-Apollo sequence for all of Johnson and NASA. It was at that time that they were beginning to see some need for a Program Assessment Office. Some people called it the “devil's advocate” office, to assess what the program was doing in the Space Shuttle and identify issues that if you looked at it independently of the program perhaps ought to be addressed. I know Bob Thompson was very interested in that, and I'm certain he felt he was doing his best to run the program the best way it could be, but it was an opportunity to look at things. And I was asked to run this office.

Most of the rest of the Apollo people that had finally finished doing ASTP went into a new office that dealt with payloads for Space Shuttle. It was called SPIDPO [Shuttle Payload Integration and Development Program Office], and it was the procedures and what they'd be and how you'd handle them and how you'd deal with the people that brought payloads. I was pulled off because of my background in spacecraft systems to lead this separate assessment with people who hadn't been tied into the Shuttle Program at that time and look at what was there.

I carefully went through the Center and selected a group of about half a dozen people to work for me and had to go negotiate getting them assigned to me with whoever their manager was at the Center. I remember a couple of them that I asked for were pretty strong in the Engineering Directorate, and I had to go talk to Max [Dr. Maxime A.] Faget. Max thought the Program Assessment Office was great, but—“Not taking my people to do it.” In the end I got a pretty good team, and we looked at the mechanical aspects of the Shuttle and the avionics and the missions and the whole suite of what the Shuttle Program was planning to do and provided a series of reports on what we thought. It was interesting. Because of my background partly, because I'm an electrical engineer, but partly also because I think it was one of the needs—we were particularly critical of how the avionics and the software was developing. There were some questions about the adequacy of the size of the computers and the actual architecture of the avionics multiredundant computer system that's on the Shuttle. We criticized that pretty strongly. I'll come back to that in a minute.

Another thing we were pretty concerned about was the fact that the solid rocket boosters were single point failures, and once you lit them they had to burn for the first two minutes. There was no way to get off. There was no escape. They would take you two minutes downstream in the direction they wanted to go. Our group had been used to the prior three programs where we always had a launch escape system on board. We presented that to the Shuttle Program and to the Center management, and they felt the rationale for doing that had been looked at a number of times and that didn't result in any change, even though it's something we played back to them.

The avionics thing—what really happened there was that they said, “Well, Arnie, you're so smart, I think you ought to come to the Orbiter and be the head of the Orbiter Avionics Systems Office,” which is doing the avionics and the software for the Space Shuttle, even though it's called Orbiter. All of the avionics that controls the total vehicle and most of the flight and the mission is all in the Orbiter. It was in the Orbiter Project Office under Aaron Cohen, but closely tied to Bob Thompson's Shuttle. They didn't have an avionics office in the Shuttle Program.

The result of my work in the Program Assessment Office led to me being put in charge of the avionics for Shuttle for the Orbiter, but also for the whole Shuttle vehicle. That was a very interesting part of my career, and I worked it for the next three and a half or four years. Quite proud of what was accomplished there. We made some of the changes that were the direct result of the areas we were worried about in the Program Assessment Office. For a number of those years I ran the Orbiter Software Avionics Control Board every week with eight or ten hours of change and adjustment traffic with IBM, who was building the software, and Rockwell International [Corporation] building the avionics. That was my introduction into serious program management. I was the deputy in the two prior programs and contributed, but this was one where I was in charge of a major element of a program, and it was the Space Shuttle Orbiter.

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 is needing to understand in detail the systems that you're the program manager for. I had done that as a matter of course during my time in flight operations. So it was natural to be pretty detail-involved in the engineering and the technical aspects of the programs. In each of these programs during this time and for the rest of my time in program management in NASA I ran a significant change board, had to deal with very detailed technical people, both at Johnson and the contractors involved. I was comfortable with that and I liked it. If I was going to recommend an attribute that is important in program management the way it's done at Johnson, and what the programs at Johnson demand, I think that's a necessary aspect and trait that program managers need to develop.

At Lockheed Martin [Corporation] I could see some different things as we talked about program management. I was in the corporate office in Bethesda [Maryland], and on any given day at Lockheed Martin there are about 3,200 programs, and they're all in some phase of executing. They need to use adequate procedures and have adequate training and be prepared for the things they're going to deal with. They're working on programs, some of which are quite like the ones we did at Johnson, but some are quite a bit different. They're managing people services, they're managing information technology. There's a broader suite of programs than just what Johnson does. My experience was almost all with Johnson.

At Lockheed, one of the things we talked about a lot was whether you had to be an engineer and a technical person to be a program manager. Philosophically, I agree with the general consensus that you don't have to be. Someone who comes from a business background or someone comes from some other scientific discipline could well be a program manager, if they have the right exposure and training and they're brought in the right way and then they have the adequate set of processes and procedures to follow. I agree with that philosophically, but at Johnson when you're flying these very technical human spacecraft, it would be hard to picture a program manager that doesn't have a strong—and maybe not an engineering degree—but a strong technical focus on what they're doing. Because otherwise you don't get quite deep enough to understand the decisions you're making.

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 every job I had, I worked for some of the people that were already doing the job, that were as capable and talented and knew how to execute programs as I've ever known. When I worked for Kenny Kleinknecht in Skylab, he had a tremendously effective well-balanced program going. I learned how to do it by just joining the program and doing it with him and doing some of it myself. It was true with Glynn Lunney. Then I worked for Aaron Cohen, it was true with Aaron Cohen. Then I worked for Bob Thompson. Every one of them, when I got there, already had a program that was balanced, was well-planned, was executing efficiently and effectively. So I learned how to do those things just because I started doing them.

Now, you go to Lockheed where you have all these programs, 3,200 programs. It means that every day some program manager's leaving that program or leaving the company. New ones are coming in, and how do they plug in? So you talk about, “How do we assure these people are trained and what do they need to know and how do they get it?” I still think that on-the-job training is by far the most necessary and most beneficial part of learning program management. But, many times I don't think people have the opportunity to work for people like the program managers I've mentioned, and Chris [Christopher C.] Kraft [Jr.]. These people were strong and competent and were already doing the things that I think are the best in executing programs. I learned by doing it with them.

The kind of program you need, though, if you have to start and you don't have that opportunity—you still need some on-the-job training because being a program manager takes experience and understanding of dealing with people, but you also need some classroom training. It's probably classroom and beyond the classroom in terms of exposure to program management processes, program management aspects that people in this era and in prior eras thought were the best practices to be used. You've got to know that. You don't have to be an expert in all of them, but you have to be exposed to all of them. You also need mentors. You need people that you can go to when you seem stumped and you say, “Well, am I doing it right? What am I missing here?” or “Can you help me?” That's also an important characteristic.

I guess I had mentors all the time, because they were right there, but my program management training was on-the-job training to an extent that I think is unique. If you're providing new program managers for new programs and new timeframes, you've got to be sure these other things are part of what they learn and what they do. Right now I'm on an advisory council that supports an initiative that Mike [Michael L.] Coats started last year on developing program managers at Johnson. There's some colleagues of mine on that advisory council that I think a lot of, and we've met regularly during the last year to first plan this program and then help put it together and then help the phases of execution through the first—there's a class of about 30 program managers at Johnson now that are halfway through an 18-month program management training.

We built the concept of, “You've got to have on-the-job training, and if you want these people to evolve, you've got to today put them in some job where they'll start to get the experience they're going to need.” Then you also have to have the training and exposure so that you understand the breadth of program management and all the little areas that you're going to have somebody else do for you. But you better know enough about it to be sure it's being done the way it ought to be done, and maybe if it's not, what the right additional steps are. And mentors so that you can talk about it standing back a little further, not on-the-job training, but somebody who's been there and has other views or other timeframes.

Johnson’s put together a program like that over the last year, and frankly I think it is excellent. We had a review of it just about a month ago where they gave a summary of the success so far, and it's a very excellent program. In fact, I mentioned to them that you were going to be doing these interviews and that the things people like me tell you could be good inputs to their program, too. Because they're looking certainly to finish this class and be very successful, which they feel they have been so far, but then there's going to be more classes and their program will evolve. So best practices in program management are the ones I've talked about here, and they're all very important. A program manager needs to know some amount of each of those things will make the blend of background that's really important.

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 maybe in some program they're not quite assigned to yet, but any program would be of interest to them. I pointed out they've got to be interested in the technical aspects of it as well as the “I'm going to manage the schedule and the budget and assign things to people.” There's some people that are part of these groups I've worked with, particularly at Lockheed because it was a bigger operation, that view this as what we need to do: find the perfect set of procedures to execute program management. And if we have a perfect set it's like a cookbook recipe for doing program management, and if we do a good enough job putting that together, anybody can be a program manager.

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

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—it's to have your technical basis and be interested in it. It's an important part. One of the things I learned going along, but was even more reinforced when I became the Shuttle Program Manager at Johnson, after the Orbiter avionics timeframe. I became the Deputy Program Manager in Space Shuttle under Bob Thompson briefly, but then I was asked to become the Manager of the Orbiter following Aaron Cohen. That was a great job. But it was also a program that was up and running and humming, and I just had to step in and be sure I kept all the knobs turned the right way and get deeply involved in it. One of the things I started to learn there, and I really learned when I took over as Program Manager after Bob Thompson in the Space Shuttle, is the importance of rigorous configuration management control.

The Space Shuttle Program at Johnson had, and I think probably still has, the best configuration control process I've seen anywhere. It is very meticulous. It's very well-documented. It's very well-communicated. At that time, when I became the Program Manager for Space Shuttle, I also became the Chairman of the PRCB, Program Requirements Change Board. I got to see this process that Bob Thompson put in place. I don't know where he came upon this. Maybe he'd done it before. It was really a strong process, and it controlled everything in the Shuttle Program in terms of rigorous definition of configurations and of changes and rigorous documentation. The overall spec [specification] for the Space Shuttle Program is NSTS [National Space Transportation System] 07700. It's a very extensive set of documentation that defines everything about the Shuttle, both in the big picture and in the details, and everything in there was controlled rigorously by this office.

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

Another thing I would say is—bouncing back to the prior time when I was doing the Software Change Board for the avionics software for the Shuttle—that was an era in aerospace evolution where the processes for developing software weren't as rigorous and widespread across different organizations as they are now. Now they're quite rigorous. It's understood formal processes of developing software. They're commonly used by lots of people that do that. But back then that all hadn't become such a well-integrated understood way. Software was still pretty new, and the Shuttle had some complicated software.

I think one of the strengths that caused the avionics and the software to come out so well is that we insisted on writing the requirements for the software, the detailed requirements, specifically, exactly, what's going to happen in every little technical area. Writing it in English so that you and I could understand exactly what was going to happen. Then someone would go away and code the software to do exactly that, and someone else would write the test procedures that would test that software to see if it matched. In that era many different areas that were developing software would write requirements in general. Broad requirements—“What it's supposed to do: supposed to do this, supposed to do that.” But then, when they got down to the details, they'd write it in software machine language so that the engineers and you and I hoped they got it, and we're going to test it to see if we like what it does, but there was no communication.

There was an office in the Mission Planning and Analysis Division that was responsible for the contract with IBM to develop the software. When I got there the plan was to do it in English, and these are big books. Flight software requirements, these are big books, too. Once they're baselined, we control every little word in English in there that controls every little set of coding in the software. I think that was an awesome strength. By the way, the Space Shuttle avionics and software has performed admirably for many years, and it is one of the evolving technologies that made the Space Shuttle possible. So I think it was very important.

Another thing I learned about program management—and this again came out of this mission control time phase—in running these change boards and dealing with all these technical subjects, you had to listen carefully to people who would present. “We need to do this because we're going to change this or that or add to this or something, we need money for it.” But it wasn't just, “They need money for it and what's the schedule?” it was also, “Is it really the right thing to do?”

I tried to develop the habit, and I did develop the habit, of listening in-depth to everything they presented to the level of detail they presented it. The purpose of that is to fully understand why they want to make these changes and what they are. If they couldn't explain it to me so I could understand it, I had a strong suspicion they didn't understand it either—so that's another ground rule of mine. If people can't explain it to you in a way that's simple enough you can understand it—in technical depth—but, sometimes these are in areas you haven't spent much time in. You’ve got to understand it.

There's another thing I wanted to comment on in this discussion—the management style of the people you worked for—every program manager works for somebody that's higher up. Over the years, in all three of my areas—the flight control, mission control, flight operations—then in all these program management jobs at Johnson, and then in the jobs I worked in in Lockheed, I always had a more senior guy who I worked for. So I got to see a lot of management styles. Some people would be very much engaged with you and into what you were doing. Even though you were the program manager, you're responsible, you're accountable, they'd be in there with you. Some people—unless you fall flat on your face and have some terrible problem—wouldn't talk to you.

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

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. Yet he was letting you go away and solve your problem. It's a very excellent way also to bring people up and improve. Whatever they can do now with that kind of treatment, they can grow.

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 start 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, complex interactions of different systems elements and different companies, different people involved in the government side. There's no way you can have a successful evolution of development and of the business aspects of a program, the schedules and the finances, and then in Shuttle after you get to fly, these manifests and the sequencings of vehicles and the capabilities of the facilities you're going to use. It is so complicated that planning is a huge aspect of the program management job. You have to be watching what's going on and taking care of problems, but you also have to be focusing on all of the things that are going on simultaneously: how they converge and how they keep you moving towards the goals you want to achieve. Planning is just one of the biggest parts of program 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: You asked about risk management, and I'm glad, because right now the subject of risk management is a very topical subject in the program management community. It’s like people are looking for a solution that can solve problems that we weren't dealing with before. I have a little different perspective on risk management than some of the very extensive activity that goes into finding ways “to do” risk management. In my opinion now, but also in my opinion in the past, program management is risk management. It's always been risk management, and years ago there was no doubt in the way I operated day to day, every day, on a risk management perspective of the program. “What are the risks in my critical systems that are going on right now? What are the risks in my schedule? What are the risks in my budget? What are the risks that my people are adequate or not adequate, or maybe about to change and I have to do something about that?” What did we say a minute ago? Program management is planning. Well, program management is planning, but program management is also risk management. I think years ago before it was such a common talked-about aspect of program management, it was nevertheless, at least at Johnson, alive and well, and that's what we were doing, and we knew we were doing it.

Now that said, the new emphasis on program management and the new tools and processes that people talk about for risk management are very good. They're great additions to the fact that the program manager needs to be conscious of risk management at all times, for a couple of reasons. One is that these new processes and some of the capabilities that are now software tools and capabilities to organize it in computers or in documentation in an effective way—they're very useful because part of the aspect of that is that it really gets everyone in the program, and maybe even beyond the program, involved in participating in risk management and thinking about it. So it provides a flow of information to the program manager that is very useful, and it sensitizes aspects of the program that might not be thinking about risk management to know always that that is, in fact, important. I think it's very important. I don't think it's new that people are starting to do risk management. But it's made better by these things.

If you do have a risk management process for your program, the program manager himself or herself needs to be the one that runs it. You can't delegate somebody to go away and run my risk management for me and then look at it every other month. People that would do that are sidestepping the issue of risk management, and they're filling the square by having a staff that's off doing something. I've seen all these tendencies I've talked about. I think that risk management is good. I think the processes are good. There's many choices now of software and books about ways to do it in the program. As long as the program manager does it, it adds to the benefit of something he or she should have been doing all along.

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

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 things transpired. But in the Challenger that I was heavily involved with, I think the risk management processes were there. In fact, one of the things I ask myself regularly about the Challenger is, “What could we have done to prevent what happened?” The facts of what happened have been well developed by the Rogers Commission and documented, and I think they're complete. I don't think there's any hidden thing that isn't lined out. We know what happened. But then you say, “How did the management of that launch allow it to happen? Why did it happen?” We had the right series of reviews, we had the right series of people, we had the right trust, I think, between the people involved.

But, over a period of time, too many things converged right at that time that the right processes let something get through. Because none of us, if we could take everything we knew after the fact and looked at it again, none of us would have allowed it to happen. When I ask myself what might I have done that could have made a difference—the big issue with the Challenger accident was of course the temperature and some residual weaknesses in the solid rocket motor segment joints that hadn't really received a lot of attention, and maybe we could have found a way to know more about that. But it was really the temperature.

After we did not launch on the day before Challenger for a wind-related problem, for return-to-launch-site aborts, we had a management review at the Kennedy Space Center [Florida]. It was called an L-1 day review, and we had all of the senior management related to the program, Center directors and all of the project and program managers and all of the technical support to talk about if we'd be able to launch the following day. The issue was the fact that it was going to be so cold that night. The weatherman brought in the fact that it was going to be 22 degrees [Fahrenheit] overnight. None of us had experienced anything like that before, but we didn't know. We knew that the launch mission rule was 31 degrees, and we talked about that on prior missions, and it was pretty widely understood that was what it was. It was projected that even though it'd be in the 20s overnight, that it would be above 31 degrees at launch time. There wasn't an immediate feeling that that was going to be unacceptable.

The action of the L-1 meeting was to have each project go away and look at all aspects of their technical project—the Space Shuttle main engines, the Orbiter, the solid rocket motors, and of course the launch facilities—and come back and tell us if you have constraints, if you have risks, if you have threats. I think the question was well-asked and understood, and we reconvened a few hours later and they came back. Each of the projects felt that their part of the system would be okay if we were above the 31 degrees for launch again. There was a minor issue on the solid rocket motors. Nothing to do with the joints, something down in the systems in the aft skirt. But they felt it was not going to be a critical problem. There was one instrumentation thing in the Orbiter that would be below its limits. But they didn't feel that that would be a problem either. It wasn't a critical problem. The whole team felt like it was all right to tank and all right to plan to launch the next day.

Overnight things changed, and things changed that were not addressed frankly. As you know from the details that are well known about the Challenger, the solid rocket motor technical community in Utah became wildly concerned when they heard about it, because they were concerned about the joints, where there had been some problems in the past. So the [NASA] Marshall [Spaceflight] Center [Huntsville, Alabama] had a long series of meetings overnight to deal with that, and in the end decided it was going to be acceptable. Even though the technical community never agreed, the management decided it would be acceptable.

At the same time, there was water all over the launchpad for spraying things down. Of course there's water for the launch time that goes under, but water runs all up and down the gantry. The concern with the Kennedy people was that the pipes would freeze and break and you'd have just water spew out. So the Kennedy team dealt with that problem by turning the faucets on slightly to trickle the water all over the launchpad. Both of those things happened after our L-1 day when everybody said there really aren't big issues and we're ready to go. The next day when we convened, everybody went to their position in the Control Center because we're now three, four, five hours before the count is going to start, and everybody has a place to be and a job to do. The senior management sits in a little place in the firing room and everybody felt still ready to go.

These two big issues had been dealt with at a lower level overnight, and they were not raised in the firing room or to the management team or injected into the launch countdown process. The water was worked by Kennedy, but it was worked at the Kennedy support level. Both of those turned out to be bigger problems than we realized after the fact. The trickle water caused a lot of ice on the launch pad—we did have a review. I called a separate review and we reviewed the ice on the gantry and whether it would have an effect on the launch, particularly whether any falling ice would hit the Orbiter, which would be terrible. We had buyoff from the technical community.

But it wasn't the senior management, it was the engineering at the Mission Evaluation Room in Houston, and it was the Kennedy project management at the Kennedy Space Center. In fact, Rockwell raised a concern and said they felt we were adding some amount of risk. But they also didn't call for a no-go. We thought this ice is more than we realized was going to happen, but we accepted it. So that was done. But we never talked about the concern that Thiokol [Morton Thiokol Incorporated] had with the boosters. It was not known. It's really hard to believe that, but it was not known.

We did, as we marched to launch, we called at least two delays to let the day get warmer and warmer. We were originally going to launch around 9:00 [a.m.], and we slipped it up almost to noontime, and things were warmer and melting and so we launched. And of course we had the accident. When I think about that and what could I have done, I sat there in the firing room with Bill [William R.] Lucas, who's the head of the Marshall Space Flight Center, and Stan [Stanley R.] Reinartz, who's the head of the Shuttle Program at Marshall, and Jess [Jesse W.] Moore, who was the Associate Administrator, beside me. We sat there through the whole count and never once talked about the solid rocket boosters being a concern. Everybody was still “to go.”

These are all people I'd worked with for years and had huge confidence in. I felt like we were a well-integrated, understanding team working together. These issues were not worked as maybe they should be. I don't think we had enough information the day before at the L-1 day meeting to not tank and count. I think we were right saying, “Well okay, we ought to proceed.” I now wish that we had called a management meeting in the next morning. It would have been disruptive because everybody has a place that they go to and job to do, and the countdown goes fairly quickly even though it's quite a few hours. But we should have called that whole team together and talked about the solid rocket motor, talked about if everybody was still “go.” I think the discussion of the solid rocket motor would have come out, and I think the discussion of the ice would come out, and people would have seen it actually was a bigger problem.

I think the Kennedy guys found a way to think it would be okay to go. It was okay. But the Rogers Commission assessment of that was that it was more unknown and risk than we should have accepted. That feeling really didn't permeate. If we'd had such a meeting—and it would have required the Center directors and the Associate Administrator and the various other very senior people to come. I wish I had made such a meeting happen. But I didn't. It was not standard. You don't do that during a countdown. But that time it certainly was necessary if we were going to proceed.

The other thing I would do about the ice—I actually made the decision to go with the Kennedy people on the ice, because I felt it had been analyzed and it was going to be acceptable—which it was, no ice hit the Orbiter. But there are other issues with the crew access—to get in the vehicle, which sounded like that would be all right, then also over to the escape buckets that would get them away in the event of an emergency, and that side of the gantry was quite covered with ice. That's something that was never brought out. What I think about all of that is that since that was a known problem that I was working, I should have insisted that I go out and see it for myself if I was going to make a decision on it. That would have been disruptive and nonstandard. But I could have done that, and I wish I had.

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 had a lot of time to think about that, a lot of years. It's still hard for me to believe that the people we knew and trusted that were part of our team from Marshall didn't talk about it. They could have said, “We've reviewed it, there were concerns, here's what they were, we think it's all right.” They didn't say a word. I think if any of us from Johnson had heard that we'd have said there's no way.

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

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 still do is very motivating to people. I don't know many people who have been heavily involved in the programs at Johnson on space vehicles and space missions that haven't been so involved and so in love with what they do that they just want to stay. They may want to work in a little different aspect of it, or they want to find some way to learn some more. But they certainly don't want to just drift off and go somewhere else. The people that I knew that left mostly left because they'd done a pretty long career, and they felt now it was time to step aside.

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's a lot of different aspects of space exploration. What I've been talking about are manned programs, but you can work in space exploration, and you don't have to be a manned enthusiast. We do so much with robotic missions now that are so good for science and so good for technology that if you're an engineer and you want to work on something meaningful and something that's at the forefront, it's just one of the best places I can think of to work on it. I think there's still many engineers that want to do that and will do that. The pipeline people talk about maybe not being as strong as it was, but I think it's full of excellent people. They're motivated just like the ones that I've talked about here that I worked with in the 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 as I see in program management?” I think I ticked those off. One is needing and wanting to be engaged in detail in the technical aspects of the program. Doing rigorous configuration control. Doing the software requirements in English so the broader community can understand in detail what's going to be put together. Listen carefully to presenters and make sure they're telling you a story that you can buy into. I talked about Chris Kraft's management style, because I think from my experience it's pretty unique. I'm sure he's not the only person in the world that ever did that, but it was well done. In the end you have to do all these things on the job if you're going to get good at it. You can learn them in the classroom or talking to people, but you have to go do it before you're going to be ready to really do it.

One of your questions is about memorable days. We talked about the launch of Challenger, and that was one of my most memorable days. But there was another very memorable day for me, and that was the launch of the next flight two and a half years later in Discovery. That mission was STS-26. During the time that we went from all the things that we felt so terrible about with Challenger to the time we launched Discovery—during the Challenger launch I had been the Program Manager for Shuttle at the Johnson Space Center and Jess Moore was the Associate Administrator in Washington, that was the overall Shuttle person.

After the Challenger I was asked to come to Washington [NASA Headquarters, Washington D.C.] and be the Director of the Program, which was a job that didn't exist during the Challenger. Moved some of the things that were centered at one of the Centers, at Johnson, to Headquarters, so it would have more comprehensive authority over all of the NASA Centers involved. I was the Director of the Space Shuttle Program. Really I was the Director of the National Space Transportation System, which is the name that the Shuttle was called in those days.

After we finally got through the failure analysis and sorting out what really happened with Challenger and where we had to take care of those problems, I realized that was not, maybe, the only weak system in the Space Shuttle. I set up a series of formal reviews looking at all aspects of the Space Shuttle for risk management, for weaknesses. In fact, for a lot of known weaknesses that we'd agreed to live with up to that time.

There were a number of things that people knew ought to be improved prior to the first flight of the Shuttle on Columbia, but because the first flight was important to get off, the program had reviewed various things and said, “Well, we're going to have to fix this downstream, but we can go, the first flight, and we'll get it later.” Almost every subsystem area in the Space Shuttle had little things tucked away that they knew ought to be improved. But once the first flight went, then the second one, then the third one, and there was never a time or the budget to step up and say, “Well, we got to go back and stop and fix all these things that actually we ought to do to make the Shuttle completely right.”

So after the Challenger I set up this series of reviews out of the PRCB meeting that I ran to look at everything and bring those things in and talk about them and prioritize them. That wasn't just my idea alone. That is exactly what I witnessed George [M.] Low doing after the Apollo fire. George Low did exactly the same thing with the total Command Service Module and Lunar Module during the time we were recovering from the fire and made extensive changes to those two vehicles that made them better. Didn't have anything to do with the fire in particular, but it had to do with risks and weaknesses.

We did that on the Space Shuttle after the Challenger, and we made over 250 changes to the different elements of the Space Shuttle, including software. Some of them were software changes. Some of them were different changes for emergency landings, but most of them were different hardware things that the subsystem managers already had in their little notebooks that really ought to get worked on. We approved those changes, and most of them were for first flight after, for STS-26, but some of them were too big for that. We approved them but gave them license to come in later downstream, like the new turbopumps on the Space Shuttle main engines that came into play [six] years ago. They were Pratt & Whitney turbopumps for the Rocketdyne engine that were more robust. They were approved by this process after Challenger, but it took a number of years of development and testing to get them ready. This is the timeframe they were set in place. Of all those changes, only about five of them dealt with the solid rocket motors. They were big changes, but the cause of the Challenger that we had to fix—only about five of them.

There are a couple of other things that were memorable. During the time I was the Orbiter Project Manager, we completed the fabrication of Discovery and of Atlantis. I had the opportunity go out and give the acceptance speech at the rollout for NASA. It was quite a thrill, particularly for Atlantis, because at that time Atlantis was thought to be the last Orbiter and the workforce there finished their job. It was good. In fact, I'm told that the speech I gave that day was used in the Rockwell program training and inspirational material that they used for their employees downstream for some number of years after that, because it said so many right things about what they did. Palmdale [California] continued as a repair and refurb site for the Orbiter, but at the time of that speech it was thought to be the last construction. Then Endeavor was approved and it came along later.

Two other memorable days early on. The first flight, STS-1, had been delayed several years by the time we got to it, for a variety of problems. Mostly the TPS [Thermal Protection System] on the Orbiter. But we got to the countdown finally, and it counted down, and that timeframe I was still in charge of the avionics and the software. We got to T-20 minutes, which is the point where the backup flight system that supports the primary avionics comes online, and it didn't come online. It didn't initialize. It's a system that was made by Rockwell and the primary system, with its four redundant strings of computers, is all by IBM, and so everyone was saying, “Well, these Rockwell people, backup software is not good.” It turned out that actually the initialization of that came from the primary system, and it was an IBM problem. It was fixed overnight and we launched, but it was quite a thing to get to that point.

One of the early flights we had—with the four computers on board, there's two-fault redundancy: you can have one fault and continue the mission, you have another fault and it's fail-safe—you've got what you need to come home. But we had two computers fail in the middle of that flight. It's the only time it ever happened on the Space Shuttle, that I know of. That was some amount of concern because they weren't too far apart. They were a little different scenarios, but there again we got to bring one back on and things went on and it was good. There's a lot of memories that you could talk about that probably aren't written very extensively anywhere anymore, just some people remember them.

Wright: Those are good ones.

Aldrich: Coming in that same first flight, STS-1, the big thing for me with the avionics was—in those days I hadn't done much with the ascent. The software that controls the main engines was a Marshall product, and it was part of the engines, and I hadn't spent a lot of time being engaged in ascent. We'd spent a lot on reentry, because when the Shuttle comes in, it starts in after it deorbits, and there's no air yet, and so its attitude to keep it going right is controlled by the little thrusters. Then it starts to pick up atmosphere and the thrusters don't have as much control because the atmospheric pressures are quite strong, and you start using the aerodynamics.

But there's a point there where the two have to be blended, and there was no way to test that except fly it. It had been analyzed to death and tested in models and things, but I had never been quite confident. We knew how much margin we had and how risky that was. We did the very best that could be done without flying it, but now we were flying it, and we had John [W.] Young and Bob [Robert L.] Crippen on board. So another memorable time was when I was sitting there in the Control Center, in my avionics little job, and that came out of blackout. It turns out that the margin was there. There was good margin. It had been well-analyzed, but we couldn't prove it to ourselves very well until we flew it.

Wright: That was another good day.

Aldrich: Another good day. The other two things about program management I meant to mention: One—the program manager needs to know that he or she is in charge and they are accountable and responsible for the program. Program is not a democracy. There's some feeling that you get everybody together and vote, and that's not the way it is. In the end, the program manager needs to hear everybody, give everybody their say, weigh all of the things with the people that they respect, but then in the end they have to make the decision. It's not a democracy.

We've been through a period, some within NASA, but to a great extent in the Department of Defense [DoD], about managing programs with integrated management teams. What you really do is you break the program down into all these little product centers that each manage an aspect of the program, and they have their own schedule and budget. That's a pretty good concept. The thing I always thought about it when it came online is that that's what we always did at the Johnson Center. We always had people that were in the program, but we had the technical disciplines, we had the flight disciplines, we had the budget people all together. I think we did it.

When they changed the Space Station Program from Freedom to the International Space Station, they had an independent panel review [on] Freedom and why its schedule and its budget had the issues it had. They criticized Freedom quite strongly because we didn't use integrated program management teams in the way our processes were set up. That was a time when that was coming on to be a big way of doing business in DoD. It was the new thinking in how to do programs. We just didn't call them that—that is the way we did program management. But to their language and what they could tease out of what people told them, they didn't sense we had—integrated product team is what they called them—they didn't sense that we had it. It was a big criticism, and then they started it. There's a couple of risks if you use that management style. It's a good style. DoD has used it a lot. I think it's not used as broadly now maybe as it was at one point in time, but it's still extensively used.

You've got to be careful on those integrated product teams, also, that someone is in charge of that team and is accountable and responsible. If you make it just a collection of people who all have inputs and you try to run those as democracies, it sounds like what you were trying to do, everybody gets a voice, but in the end somebody has to be in charge. You do that across the integrated product team structure so that each one really has a responsible accountable person, and it's a good way to operate. But then you also need to have one integrated product team at the top of that. Someone needs to be in charge of that. Because otherwise they won't fit together and dovetail. That's an aspect of program management that gets a lot of attention, and I don't know that everybody would think about what I just talked about, but I think it's important.

Two other things about doing program management: I talked about being in charge and being accountable. But, also, the program manager can't do everything. You have to have good people that you trust and have confidence in run the key aspects of the program for you. You have to stay in close contact with them and know what they're doing. You have to have people you can count on. Let them do their job, just like I was talking about Chris Kraft with the program manager. That's important. Again, that's something that was rich in the programs I did. I always had good people working for me that I could count on, and they did great things.

One final thing—it's a little like the mentoring. The other thing you ought to do is regularly seek the advice of people outside the program that you have respect for and you think could give you help. There are senior people in your organization. There are other people that have like responsibilities and jobs. You ought to contact them and be in touch with them and use what they tell you.

Wright: Good idea. A lot of good information.

Aldrich: You asked, also, about other people you should talk to. Two of the best that I ever worked with, you can't talk to anymore. George Low and Sy [Seymour] Rubenstein with Rockwell were two of the very best. Also Bill [Howard W.] Tindall [Jr.]. Bill probably isn't categorized as a program manager, but he was one. Then the other people—you must have a list that probably is most of this or better, but you must talk to Chris Kraft about this. He was in charge of most of the things at the Center that came to be and were successful. Aaron Cohen is not well, but he's a very knowledgeable person in this, and he would tell you things about doing it that are important. Bob Thompson also.

A fellow I worked with a lot: Dick [Richard H.] Kohrs. From that same organization and era: Owen [G.] Morris. In this software area: John [W.] Aaron. Ron Dittemore. You also ought to talk to Bob Crippen. There're a lot of astronauts who've done a lot of great things. When I think about program management though, Bob is the one I think most broadly has a real handle on what it takes, what's important. There're a lot of people at Marshall, and I could give you a list of names, but I couldn't prioritize them for you well. But one I think would be good to talk to is Bob [Robert] Lindstrom. And J. R. [James R.] Thompson [Jr.], who now is with Orbital Sciences. Lives in Huntsville, but he works for Orbital up here in the DC area. That's the list I had. I'm sure there's more.

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 kind of thing on the programs I managed, which almost sounds like that might be what it would be.

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 like I say, it's not very well-organized, and some of it's not connected very well. I did come up with one thing, though, I thought of right away. The Challenger was not the only launch in January of 1986. The STS-61C launched earlier in January, and some of the problems we had with the launch attempts that ended up so badly with Challenger, we had in spades with STS-61C. You don't probably read much about these things anymore. The thing you'll read is that we scrubbed six times before we launched on the seventh attempt. I wrote a memo after that happened, and this was to the Shuttle team about the characteristics of all of those scrubs and how avoidable they would have been if we'd just had things synched better some way. So I brought that.

Wright: Great. Thank you.

Aldrich: Because if I was a program manager and going to be into that kind of thing, that might be a series of thought-provoking things.

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

Aldrich: Sure. You can have it too. You can keep it.

Wright: Okay, good.

Aldrich: You started off asking about Columbia and Challenger. This is something I just collected around 2003. This is a little article by a man that was working on the O-ring analysis at Thiokol back then. It talks about a common cause of the Challenger and the Columbia accidents. It's not talking about flaws in management style as a common cause, which has been pretty well talked about. This is talking about Max Q [Mazimum Dynamic Pressure] and upper-level winds and how they also played into both of these, or potentially did. It's interesting reading, and I haven't seen anybody reference it. But that was in the AIAA [American Institute of Aeronautics and Astronautics] magazine, Aerospace America, and I think it was in 2003, which is not long after the Columbia.

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

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

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 about that long for Lockheed, because no one would do anything with something like that.

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. There's a lot of books that were written about Challenger, and many of them were written pretty early. There was still a tremendous amount of emotion flowing around and facts not well sorted. I think some of them are just off track, but there's a couple that I think if you were a program manager and you wanted to read about some of that. There's a book written by a guy in Scandinavia. The title is No Downlink. Do you know about that book?

Wright: No.

Aldrich: No Downlink is the title. It was written by Claus Jensen in 1993. It was translated by Barbara Haveland in 1996. His accounts in there are very factual. He doesn't draw a lot of conclusions, but occasionally he does. I won't say all of his conclusions are exactly what I conclude, but it's pretty accurate. It's probably more readable than the Rogers Commission stack of books.

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

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

Aldrich: It was my pleasure.

[End of interview]