NASA Johnson Space Center Oral History Project
Edited Oral History Transcript

Robert H. Heselmeyer
Interviewed by Sandra Johnson
Houston, Texas – 1 December 2004

Johnson: Today is December 1st, 2004. This interview with Robert Heselmeyer is being conducted for the Johnson Space Center Oral History Project in Houston, Texas. The interviewer is Sandra Johnson, assisted by Rebecca Wright and Jennifer Ross-Nazzal.

I thank you for joining us again.

Heselmeyer: Glad to be here.

Johnson: In our last session, you mentioned that you were somewhat disappointed when you were asked to transfer after Apollo 16 to go work on Skylab. If you would, share with us what area you were transferred to, why you felt that way, and what your first duties were during that transition time.

Heselmeyer: I was disappointed because I wanted to support all the Apollo flights, and 17 was coming up, and it was looking like the last one, and I would like to have completed doing the flight control for the LM [Lunar Module] for Apollo. So it wasn’t a big deal, but it would have been nice. But there was the need for folks to start thinking about Skylab and Skylab support, and I was okay with going over there.

The transfer was to the Space Science and Technology Branch to become a biomed experiments officer, and our function was to be the operational interface with the medical community in support of the medical experiment complement on Skylab. We continued to be employees and responsible to Flight Control. We acted as agents for the medical community in terms of their interests and their operations for their experiments on Skylab.

Our responsibilities were to learn the medical experiments, the complement of those experiments—there were about a dozen of them—and then to support the operations of those experiments on orbit and do the standard kind of flight control things in terms of making sure the operations were correct; if there were problems, working with the crew to get the experiments to operate properly.

And then there was also a planning aspect, because, of course, this was round-the-clock long-duration operations, and the cycle was to do the experiment protocols during the day, then reexamine after the day was over what was accomplished, what may not have been accomplished due to time constraints or problems, confer with the medical advisors, and there was a daily meeting to do that, and then go through a planning phase to plan the next day’s activities. So it was different from Apollo from the standpoint of instead of the whole flight being planned out, there was a twenty-four-hour cycle of execution and then planning for the next day’s activities based on what had gotten accomplished.

Our first job was to learn the experiments and what they were about, the purpose, the equipment, how the equipment operated, and then we put together the standard console tools that we had used during Apollo, the systems handbook, the console handbook, the malfunction procedures, designing the layout of the console for support, that kind of thing. So that’s the experience we brought and used in supporting the experiments. We didn’t have flight rules, of course, things like that, because we weren’t dealing with the vehicle or flight constraints.

Initially, there were four teams. The Control Center operations were the same as Apollo’s front room MOCR [Mission Operations Control Room] person, and then a Staff Support Room divided up amongst the various experiments for that support. There were four teams initially, and then a fifth was added later on, and that, of course, was to provide some relief for the long-term operations, giving people time off. So that’s what we were about in Skylab.

Johnson: Can you talk about those first months, getting everything set up? Were you involved with SMEAT [Skylab Medical Experiments Altitude Test]?

Heselmeyer: Yes. We did not do sims [simulations] like we did in Apollo, but the SMEAT was in summer of [19]’72, I think, maybe. We did support the SMEAT activities. That was the altitude test, fifty-some-odd-day duration. The crew, I believe, was in Huntsville [Alabama] in an altitude chamber, and we supported out of Building 32 at JSC. We set up teams and had a little support area and went through the protocol.

SMEAT was to verify the facilities, the equipment, the food, and we conducted that from our part just like we would a flight. In fact, we were still on the front end of this thing, so it was very helpful to us to get used to that routine, to get into a rhythm about how to schedule experiments, compensate for things that maybe didn’t go quite right, and then do some planning for the next day. It was a useful activity and it was extremely useful to the medical community because they were checking out all their equipment. It worked very well.

There were some minor problems with some of the experiment equipment. I don’t remember there being any significant problems. The biggest thing that I recall was with the food. It was conducted with, of course, a regular crew of astronauts, and the biggest complaint throughout that I remember was getting food. That’s a tough problem. When you’re doing something like that, it’s nice to have things to eat that you like, and that was hard to put together.

Johnson: After that and during the first launch, were you in the Control Room for the first launch of Skylab, when they actually launched and had the problem?

Heselmeyer: No.

Another thought on SMEAT and training. It was a little different in the SMEAT test, because during normal console operations in the Control Center, everything is very professional and very crisp, and it was the same way in SMEAT, but because this was an offline kind of test, there was room for more off-the-cuff kind of conversations. It was interesting to hear some of the both positive and sometimes negative remarks from the crew members where things were going very well and things were not going so well in terms of the kind of things they had to say about it; less formal in some respects.

One of the things that some of us did as part of our training was to accompany the crew up to Shepherd Air Force Base [Wichita Falls, Texas], where they got some briefings and some hands-on practice in terms of long-term medical care, things to look for or to be aware of about how they were doing, how they were feeling, the basics of being able to do a very cursory kind of physical; eyes, ears, nose, heart monitoring, stethoscope. We learned what a heart should sound like when you’re listening to it through a stethoscope, how to set bones if there were any kind of fractures, how to suture wounds, things like that. It was interesting and indicative of the fact that this was going to be some long-time self-reliant activity up there.

Johnson: Was this with the SMEAT crew or with the all the crews?

Heselmeyer: It was a mixed bunch that went up. It was an interesting trip, too, for me personally. I didn’t go up with the rest of the folks, but because my wife’s brother lived in Dallas [Texas], so I drove her up to Dallas and then drove on up to the Air Force base. Then on the way back was the big snowstorm of seventy-whatever. Driving back from Dallas to Houston with it snowing like crazy and the roads covered and icy was an experience you don’t get to have very often down here.

Johnson: Yes. Not here, anyway.

Did you have any interest in moving into this area, or was it something that you were assigned to do, as far as moving into the experimental, scientific part of it, coming from working on console during Apollo?

Heselmeyer: I had given it no thought. I was doing the LM Apollo activities and was approached with this as something that needed to be done, and was asked to go do that. So, no, it wasn’t anything that I had thought about at all. But then once I got over there, it was very interesting. The complement of experiments covered the broad range of food and nutrition, bloodwork, weight gain and loss, stress on the cardiovascular system. There was a lower-body negative-pressure experiment that stressed the heart, and there was a thing called a vector cardiogram, which monitored heart activity, vestibular functions, sleep functions. So it was an array of very interesting kinds of experiments.

The crew did weigh themselves and the samples that they were preserving by—you can’t weigh yourself in zero gravity, but they had an oscillating chair. There’s a relationship between mass and period of an oscillation, so they’d get themselves in this chair and it would oscillate, and they could end up, in effect, weighing themselves. So they had a chair for themselves and then they had a smaller one for weighing samples.

Johnson: When the first Skylab launched and they had the problem with the shield and then there was a concern because it was heating up and with the experiments and that sort of thing, can you talk about that and how that was dealt with as far as from the experimental side?

Heselmeyer: There was a lot of concern, and there wasn’t anything anybody could really do other than get the shield up, but based on the temperatures and the analysis in terms of what would be affected or not, it was determined that things looked like they were going to be all right. We didn’t have any active part in being able to do anything about that, other than look at the data and see. That was mostly the medical folks, because it was the food that they were really worried about.

Johnson: With the first crew, were you involved with them and their first mission?

Heselmeyer: The five teams that were formed, we all supported all three Skylab flights for their durations.

Johnson: This was the first time, of course, NASA had dealt with true long-duration space flight.

Heselmeyer: Yes.

Johnson: And the Control Room and the teams had to be formed for that.

Heselmeyer: Yes.

Johnson: Can you talk about the difference between Apollo and Skylab and how things were set up?

Heselmeyer: The biggest difference was getting ready for a marathon instead of a sprint, is what I’d say. Each Apollo flight was an event that had a specific beginning and an end in a short time period, and you geared up for it and you did it, and then after it was over, you could relax and get ready for the next one.

Skylab wasn’t as intense while we were supporting, but adapting to the different shifts took some doing. Some folks did it better than others. And then the execution and planning cycle was a whole different thing. While the crew was up and working and doing their experiments, it was similar in that you’re watching what they’re doing and making sure things are going okay and answering questions and what have you. But after the crew’s gone to bed, then the next day needs to be planned, and that was different, entirely different, from Apollo. The Apollo flights were planned from beginning to end, and this, every day was a variation of the previous day.

And it wasn’t always easy, because there was competition for the limited amount of crew time available. The other experiment areas were looking for what they needed to get done. The medical folks and the biomed experiments, of course, had their protocols. We probably were a little more critical in terms of getting the protocols done because of the frequency and time of day, even, for example, of gathering this medical kind of data, which can vary. There was an enormous amount of pre-flight work done by the medical community to establish baselines on the crew members, and then tracking how that changed over a flight required that various kinds of information be gathered often enough to create a valid trend. So it was very important to us to get as much done as we could or needed to every day.

There was a daily planning meeting with the medical community after they had reviewed the day’s activities and decided what they wanted us to try to get accomplished the next day for them. Then we’d take that back to the Control Center and work with the timeline folks to get it scheduled. And sometimes it was important to do it in the morning instead of the afternoon, for example. So it was a different environment.

NASA got sensitive to that, too, in terms of the long-duration and the shift-changing, which can be very hard on families. It wasn’t so bad for—well, everybody has to adapt to it, and my wife had to adapt, too, but that was before we had kids, so it was a little easier on us, I think.

They did do a couple of things, which were very nice gestures. During one of the Skylab flights—I think it was the last one—we had a potluck dinner in the Control Center and set up tables in the front of the MOCR and invited families to come in, and we had an evening with our families in the Control Center. Very unusual, and a wonderful experience for the families to be able to come over there and spend some time and at least be where a lot of us were spending an awful lot of our time.

Then [Jones W.] Joe Roach, who was the Deputy Director, Deputy Division [Deputy Chief/Technical Assistant to the Director of Flight Operations]—I’m not sure what Joe’s position was, but he wrote a very nice letter to the wives that expressed appreciation for what they’re doing in supporting those of us who were spending all our time over there.

Johnson: How long were your typical shifts?

Heselmeyer: They were three eight-hour shifts, but they overlapped on each side, so it was usually a ten- or eleven-hour kind of day for handovers, and we rotated. I don’t remember the exact sequence, but we would go for a while on the daytime shift, although it didn’t matter the time of day, it was really the crew rotations. But we would end up over a period of time just rotating around the clock. We’d have some regular-hour shifts and then some evening shifts and then some night shifts, which, for me personally, worked out just fine. I didn’t have a lot of trouble adapting to that, other than trying to sleep during the day when there’s a lot of noise.

Johnson: During the first flight, maybe you could just tell us some of the issues, or if you have any memories of things that you had to deal with in your position.

Heselmeyer: The primary thing we had to do—over the course of the Skylab missions, I don’t recall us having any serious equipment problems. There were lots of little problems, lots of little adjustments, but nothing that brought any of the experiments to a halt. Mostly what it was, the most exciting part of it, if you could really call it that, was having the challenge of getting the experiments scheduled. Scheduling was a big thing and the competition for time and the competition for time slots. Overall, that was our routine.

There was one interesting incident that came up, and again, I don’t remember which flight it was, but the medical community started becoming concerned about crew fatigue. It could measure a lot of other things having to do with the crew and how they were functioning, but fatigue was hard to judge. So they were trying to figure out how to get a handle on if the crew was doing okay from a “being tired” standpoint.

One of the things at one of these daily meetings that they suggested, and it happened to be I was on the shift where I was attending those, was they suggested that we start logging crew mistakes as an indication of the crew getting tired. If you start getting tired, you start making mistakes. So they suggested to us that we start watching for and keeping a log of mistakes that the crews were making. That sounded like a terrible idea to me. I didn’t like that at all because I wouldn’t do that to the crew and it just didn’t seem like a good idea to be looking over their shoulder, watching out for when they’re going to do something a little wrong or whatever. They can’t operate in that kind of environment.

I was concerned about it, so I went and talked to [Eugene F.] Kranz about this request and said it sure didn’t seem like a good idea. In the process of talking to Gene about that, I must have used some kind of terminology about how they were wanting us to make notes of when the crew would screw up, and Gene agreed that that was not a good idea and we ought not to do it.

So I was prepared to go back to the meeting the next day and tell them that we weren’t going to do that for them. When I got there, the doctor who was running the meeting was furious, and he wanted to know who it was that had been talking to people about starting a crew screw-up log or something like that. Apparently, the word had gotten back to him before I got over there, but he was not happy. I told him, well, maybe that was some unfortunate terminology that got used, but we weren’t going to do that.

Johnson: Talk a minute, if you will, about the relationship between someone in your position and the medical people and how that worked.

Heselmeyer: We were the operations agents for the medical community and the medical experiment principal investigators. They are not operations oriented, they are medically oriented and they are experimenters, and the protocols of the Control Center and the monitoring skills and troubleshooting skills are not part of what they do. That was the value that we brought to it. We did not have any responsibility for the purely medical care of the crew. We were simply the experiments. They had the experiments, the purposes, the protocols, the requests to get the data, and then it was our responsibility in the context of Control Center operations to get those things into the timeline to monitor the operation and to deal with any real-time difficulties with either procedures or equipment and to work that out. So that’s what we were about.

Johnson: You say you didn’t deal with the actual medical care of the crew, but they did have some health issues as far as space sickness. In the last flight, they got behind on a lot of their experiments and everything because of that illness and because of other issues. Do you want to talk about that for a moment? Do you have any specific memories about dealing with that or how you worked—I know you said every night you would replan for the next day—and how that was handled and how that was accomplished?

Heselmeyer: I think I’ve already covered that, in that the medical aspects of what was going on with the crew was separate, and we only were affected by that in terms of what the crew could or could not do each day and what that meant in terms of what experiments needed to be scheduled and how the following day.

Johnson: As far as what was learned from Skylab and what you dealt with specifically, is there anything specific you feel was a significant accomplishment with what you dealt with, the experiments?

Heselmeyer: All of that data was a brand-new learning experience for the PIs [Principle Investigators]. They seemed to be extremely happy with the kind of data they were getting in the samples that came back. It taught them all kinds of new things about bone loss and vestibular function and how the body reacts to zero-G. I’m not a medical experimenter, so I didn’t have as much of an appreciation for all that as they did, but we did our job in terms of getting them that data, and they were just very happy with what they got. It established a database that I think has become very important in terms of long-duration space flight. Of course, the equipment’s gotten better and there’s a lot more technology involved, but this was a great start for them.

Johnson: Do you have any other thoughts or memories about Skylab that you’d like to share?

Heselmeyer: I don’t think so. It was a long, long time of a lot of Control Center operations, but I think back on it as being a pleasant experience from a standpoint of being able to do Control Center operations and being able to get that done. I enjoyed that.

Johnson: At what point did you transition to Shuttle?

Heselmeyer: Skylab was over in [19]’74, and I didn’t get to Shuttle until [19]’81, so I was seven more years in Operations. After Skylab, I went to Mission Operations Branch and got involved in the development of the Control Center requirements for the Shuttle Program. Shuttle planning was gearing up, and at that time it was thought that the Shuttle Program would provide as many as sixty flights a year. This is a whole different deal. It’s the same thing, but it’s rapid turnaround and a lot of flights.

So the Control Center needed to be redone to support that frequent an activity, and I ended up leading an effort from the Operations side to determine what the Control Center requirements needed to be for the Shuttle Program. We worked with the Ground Data Systems Division, which was the organization responsible for the Control Center. That was a long-term activity. That was several years of working through what the Control Center needed to do.

We started off with basic assumptions in terms of broad capability and then developed more detailed requirements as time went on. What we ended up deciding initially was that the Control Center needed to be able to support three activities simultaneously. This is all new. The Control Center needed to be able to support flights, real-time flight activity, simulations, and the processing of vehicles at [NASA] KSC [Kennedy Space Center, Florida], tests down there. I think the worst case was two flights and then either a sim or a KSC test and then based on that capability, that leads to three FCRs [Flight Control Rooms], and the amount of computing power the Control Center needed to be able to have in place.

Then we worked from that broad requirement down to the very detailed requirements. In fact, we developed three different levels. There was Level A, Level B, and Level C requirements. So I spent a lot of time fleshing all that out and ended up with a baseline set of requirements for the Control Center. Of course, there was a lot of give-and-take in terms of what the operations folks wanted to do and what the ground systems folks thought was possible to do, budgetary restraints, schedule constraints, what have you, but it was a whole body of work that laid the foundation for Control Center operations.

Then I got involved in approach and landing tests and OFT [Orbital Flight Test] test requirements, and toward the end of that period of time ended up in a small staff office working for John [W.] O’Neill. There were three of us in there: [Seymour] Sy Liebergot was one of them, and a fellow by the name of [R.] Scott Millican, and myself. We were an interface group with the Program Office on various aspects of Shuttle activities and relating between the Operations and the Program Office.

My particular role, I was a representative on the—I think it was called the Flight Test Program Panel. It was a panel that [Alfred A.] Al Bishop ran for the program. There were representatives on that panel from all the disciplines associated with Shuttle support, and I was the Operations rep. We were working through requirements for the approach and landing test and the original Orbiter flight testing and what needed to be done in what sequence. Various folks would have ideas, and then I’d carry those thoughts back and forth between the Operations folks, and work out what our position would be, and then go back to Program with it. That was, in fact, my first real exposure to working with the program. I had always very much been an operations kind of guy. So in broad summary, that kind of covered that period of time.

Then when I worked in MOD [Mission Operations Directorate], [David C.] Dave Schultz was the Branch Chief. Dave had subsequently left and gone to work with Glynn [S.] Lunney, who was doing a lot of traveling between [NASA] Headquarters and JSC, and Dave was working with him. Then he ended up in the Program Office and was setting up a new office, Flight Production Office. He called one day and said how would I like to come to work in the program, in this new Flight Production Office. It was another one of these deals, you know. I didn’t think about Skylab. I wasn’t thinking about going to work in the program, but I said, “What are you doing?”

He said, well, all the details had not been worked out in terms of the charter, but what it was about was setting up an office that would start dealing with implementation of high flight-rate Shuttle flights and how you do that, and how you make sure that all of the coordination with respect to getting stuff to the Cape [Canaveral, Florida, Kennedy Space Center] that you need to process vehicles and getting manifests worked out, was what this office was going to be addressing.

I wasn’t sure if I thought that was a good idea or not. So I thought about that for at least a week. I told Dave, “Let me think about that.” And I worked that over and kind of agonized about it, and finally decided that that was probably a move I ought to make, because it was time to get a broader outlook. So I called and said, yes, I’d be willing to come over and work in the program. So I let Dave know that, and I let the HR [Human Resources] folks in Flight Operations know that.

It wasn’t long after that, and then people knew I was going to move, and somebody said to me, “Have you heard from Kranz yet?”

I said, “No.”

And a few days later, sure enough, I got a call saying that Gene wanted to see me. So I went up to his office. Bottom line was that—well, I went in there, and he said, “What in the world are you doing? What has possessed you to leave Operations and go anywhere else, much less a Program Office? I always thought you were smarter than that. What are you thinking?” And it was very much a “Is this really something you want to do?” and, “Why would anybody want to do that?”

Of course, Gene was an operations guy his entire career. He’d had all kinds of opportunities to go do other things, but operations was what it was about. So I got wire-brushed a little bit in terms of why I thought I would want to be somewhere else.

So I said, “Well, to broaden my horizons, and I think that’s something I really want to do.”

So he let me go. He had to approve that, too. A transfer like that needed to be approved. So he let me go, but it was interesting to get the exit interview. I suspect that might have been kind of standard for folks who were leaving, and it was kind of traumatic, because having spent that much time in Flight Operations, you come to believe that that’s where the action is, and to get away from that to go do Program Office kinds of activities, managerial, bureaucratic kind of stuff, is a major step. So it was not an easy decision, but I knew I didn’t want to go back and do any more console work, and when I thought about it, I had been doing bureaucratic kinds of things. I wasn’t hands-on on the console anymore, and the Control Center, of course, is a pretty interesting thing. But then the test requirements kind of—I guess it steered me that way, so I was ready to go try it.

Johnson: And that was in [19]’81, you said?

Heselmeyer: That was in ’81. I think that was right before the first Shuttle flight.

So then Flight Production Office, brand-new office, there were half a dozen of us in there. My initial role was to get involved and head up a working group, an inter-Center working group, with Kennedy and [NASA] Marshall [Space Flight Center, Huntsville, Alabama] to start analyzing how high flight rates could be maintained from a standpoint of getting all of the equipment and parts of the Shuttle stack to Kennedy and processed on a regular basis, getting solid rocket motors from Utah, getting boosters put together, getting external tanks barged over from Michoud [Space Systems Assembly Facility, Louisiana] getting Orbiter vehicles turned around, stacked, checked out. So all the players pertinent to that were part of this working group. We started talking to each other and laying out timelines and logistics kind of factors to see how to make that work.

It was an interesting period, because the agency was still selling very high flight rates. We were still up in the high fifties, sixties, flights a year, and we were putting together scenarios to see how to support that. It was all based on assumptions, and we didn’t knowingly make any bad assumptions, but we obviously made a lot of very optimistic assumptions in terms of how this whole set of activities could come together.

It was a pretty snappy operation in terms of being able to support it, but we didn’t at that time in our lives come up with any showstoppers that said it couldn’t be done. It was based on what turned out to be, as I said, overly optimistic assumptions, mostly to do with processing all of the test and checkout that needed to be done. But, back then, we were doing work for very high fly rates.

We continued to do that, and then we also started getting into integrated scheduling and came up with the concept of a flight integrated schedule, which consisted of—it wasn’t just the processing, it was everything that needed to get done to enable a flight from the very beginning. So it also included the manifesting aspects, working with the PIs for the experiments and the NASA folks who put together the manifests. So we developed this very detailed schedule with critical paths and worked with all of the different organizations to develop these schedules and to come up with a tool that could be used to track whether or not these flights were on schedule, on track.

There were early cargo integration reviews, and we would go and be on the agenda and show up with a tentative schedule, and then work with that whole group to put together an agreement on what could be done when to get all of those activities done. It was relatively inefficient from the standpoint of the tools that we used at that time, and it was very intensive in terms of the amount of detail that needed to be tracked, but it set the stage for a much more sophisticated kind of scheduling later on.

Eventually, of course, during that period of time—and this was from [19]’81 till ’86—reality began to set in in terms of what kind of flight rates could actually be sustained. Toward the end of that period, after we had done the early work on very high flight rates and the ability to process them and started work on all these flight schedules, it was becoming obvious, as the program got more experience as well, that that was not going to be achievable.

Toward the end of that period, a couple of other people and I did a kind of feasibility study on what kind of flight rate would be realistic, intentionally tried to come up with more based on experience and more realistic assumptions what sort of flight rate would be achievable in a Shuttle Program. Based on that activity, we concluded that the best the program would ever be able to do would be about twenty-four. So we were still high, but we were coming to grips with reality. We went and pitched that, wrote some memos about that and pitched that to various organizations.

My overall recollection of that was it was news that was before its time. People were polite and people took it under advisement, but nothing concrete happened because of that. But it was the point in time where everybody was beginning to realize it. I don’t remember what the official agency position was then, but we had it down to twenty-four in our estimates. I think over the course of the Shuttle Program, I think we got twelve in one calendar-year period. If you take twelve months and you lay it along the flight schedule, we got twelve once and came close a couple other times.

Johnson: In those early flights, did you get a chance to see any of the launches?

Heselmeyer: No, I did not go to any of the launches. For the early flights, we were doing this analytical kind of work. We weren’t really in the mainstream of getting launches put together. In fact, over my career, I was actually down there for one launch. I didn’t go to launches, tended not to go.

Johnson: When you were working on the ALT [Approach and Landing Test] program, did you see any of that?

Heselmeyer: No, I sure didn’t.

Johnson: Anything else on those early flights pre-Challenger [accident] you’d like to talk about, or anything else you did?

Heselmeyer: I don’t think so.

Johnson: Do you want to talk about Challenger and how that affected what you were doing? Of course, obviously it stopped the flights for a while.

Heselmeyer: Yes, it sure did. Challenger happened about the same time that the Flight Production Office was shutting down, and I ended up moving along with Dave Schultz. He was now in the Management Integration Office, so I moved over there and became a configuration management guy. That took several days to decide if that’s something I wanted to do, but I’d had some exposure to it, and I was familiar with it, and it sounded like something that I would probably be interested in. I was a little worried it might be boring. It turned out not to be the case at all. So that’s how I got over to Management Integration.

In that same period of time, the Challenger accident happened, which, for me, since I was not involved in direct flight support, it wasn’t traumatic from that standpoint, but it was incredibly sad, not only for the program, of course, but from a personal standpoint, because my oldest daughter and Ellison [S.] Onizuka’s youngest daughter were classmates. They both played on the high school soccer team and the club soccer team, so we had become pretty good friends with the Onizukas through all this soccer activity. And for her to lose her dad in that way, in that tragic and public way, that was very hard. That was tough on that family, and it was tough on those of us who were their friends. So that was just a sad time.

The results or the response to the Challenger accident and the presidential commission and the findings, of course, shut the program down for what, a year and a half. That investigation was much more focused than the later Columbia accident. It homed in on the problem with the O-rings, and then it did have some recommendations with respect to the organization and how the organization ought to get changed to get away from minimized Center-centric thinking, a strong central program management.

How it affected me in my job is that now being a configuration management person, one of the things that happened was that the program went through a whole redo of the system design, and there were a series of system design reviews and critical item list reviews that went on forever; long, long meetings. Fortunately, I wasn’t doing the board at the time. All this happened in the PRCB [Program Requirements Control Board]. I wasn’t doing all those boards. I did a few, but the process of re-looking at all that information and re-examining the design and the analyses and everything to do with flying that vehicle to try to make sure there wasn’t anything else out there, it was grinding to go through all that.

Another significant change in the way the program operated was that there was a Program—I think it was a Program Director, was the title, and the management of the program was moved to Headquarters. [Robert L.] Bob Crippen became the Program—I believe it was Program Director.

Along with that came ultimate Control Board authority. Up until that time, the Program Requirements Control Board was at JSC at the program level. With the creation of a Headquarters Program organization, there was a Headquarters Program Requirements Control Board established. So that changed in a significant way the way that the program handled changes and controlled its baseline.

Crippen gave me the opportunity to go up to Headquarters and do that function for him, but my kids were in school and I wasn’t going to move, so I ended up not doing that. But it turned out to be an interesting phenomenon, because there were a set of decisions that were defined to be Headquarters-level decisions, and so anything that the program did that met any of the conditions that made it a Headquarters decision would go from the program level, PRCB. What we would do is have to write a change request to Headquarters and then elevate this extra step up to Headquarters. Then Headquarters would conduct the Level One PRCB, make their decision, then transmit back to us what their decision was, and then we would implement it in the program. I guess that board lasted for maybe a couple of years.

Over time, it became apparent that the vast majority of the decision making was being done by the same people. There wasn’t this influx of outside expertise or extra expertise operating at Headquarters that was adding any more information to the decision-making process, but it was requiring this extra step. So after a while, everybody in the program agreed that Headquarters, in their ability to influence decision making or make inputs in the process, could do it as well at the program level at JSC. So that whole thing reversed itself in the matter of a couple of years.

So you have a period in time after Challenger where there was the Level One board and decisions made at Headquarters level. That went away, and we went back to doing it at JSC at the program level. But for those of us who were involved in the CM [Configuration Management] operations, the control board was a significant shift, and it was a resource impact, that kind of thing.

I guess that’s the primary effects on what I was doing from Challenger.

Johnson: If you want to talk about your position after return to flight and what you were doing during that time period.

Heselmeyer: When I went to work in the Management Integration Office, I went over there as what’s called a Technical Manager, which is a nice title. It was not a supervisory position, but my area of responsibility was configuration management. And then over the years—in fact, from [19]’86 until I retired, that’s the office where I worked, and over those years, I went from a Technical Manager to an Office Manager when the office expanded and reorganized.

There were two offices within the Management Integration Office. One of them had to do with CM, and I was the Office Manager for that. The office also had responsibility for information technology support, computers maintenance and upgrades, and that kind of thing. So there was a separate office for that.

Then a while later, another reorganization, the offices went away, and I became the Deputy Manager. Then eventually, when Dave retired, I became the Manager of the office, in [19]’87, I think.

Now I forgot the original question.

Johnson: What you were doing during that time period in your day-to-day activities.

Heselmeyer: I was the CM guy. Dave still did the PRCB. I ended up being the Noon Board person. Maybe I need to explain a little bit about the PRCB-CM process. The purpose of configuration management is to establish the program management technical hardware and software configuration baselines and then to control changes to those baselines and be able to report on them and verify them, the broad categories of what CM is all about.

The changes to the program baseline, whether it’s a document, whether it’s a configuration of the hardware, is done by control boards. The Program Requirements Control Board is the board in which all of that change authority is vested. The PRCB, in turn, delegates authorities and responsibilities to other control boards such that everything doesn’t have to go through this single board. So it parses out, based on category of change in most cases, to delegated boards, who then can make authorized changes.

One of those was called the daily PRCB. Its sphere of authority was processing at KSC. Anything that affected change processing at KSC went to the daily PRCB. It met daily because if it was time critical as vehicles were being processed and if there were changes to the operations and maintenance checkout requirements, those are program requirements. If you wanted to change or waive any of those, you needed to get permission from the program, and you went to the daily PRCB.

There were other delegated boards. Integration Control Board was delegated authority for integration kind of subjects. There was a Mission Integration Control Board for payload and manifesting kinds of activities. There was a control board at KSC for the configuration of their equipment. So, a whole array of those things.

Interestingly enough, one of the things that happened over the years—it varied. When I got there, the PRCB had retained the authority for changes for an awful lot of things. Then along came TQM, Total Quality Management, which the program embraced. The principle of TQM is to delegate to the lowest possible level the authority to make changes. That applied directly to control boards, so that in implementing Total Quality Management into the program, it meant more delegation of authority to lower-level boards, which is a double-edged sword. On the one hand, it certainly places it in the right place, closest to those most knowledgeable and with the authority to make changes, but on the other hand, it complicates the whole decision-making process, because now you have all these islands of authority and every time—not every time, but much of what’s delegated has caveats or conditions associated with it. If you violate one of those conditions, it’s got to go to the PRCB. So all the people who are running these boards need to understand what their authority is and what the limits of their authority are.

For people on the outside, some guy in Engineering who wants to get a change approved, it’s a bewildering array of boards, and which one does he have to go to and why? So it became confusing for the users of that system.

Just for the record, I was always a little lukewarm about TQM. I saw the benefits in it. Certainly there is something to be said for getting some things delegated. There’s no reason why a lot of decisions need to be made by the Program Manager at the program level, but it can be outweighed or compromised to some extent by the complications. To this day, if you look at the program configuration management requirements, there’s page after page of conditions, explanations of what is delegated and to what extent to all these different boards. As time goes on, it’s gotten better as people have gotten used to it and understand which board to go to. It’s worked out okay, but I was kind of lukewarm on that to begin with.

So, back to the Noon Board. That was my primary task, other than—well, from the board support standpoint. So I acted as the secretary to the Noon Board. The Noon Board process is different from the regular board process in that it’s a quick turnaround kind of a thing. It meets daily, and when a change comes to it, it doesn’t have to go through all the rigmarole that another change has to go through because time is of the essence. Basically, if a change comes, it gets a one-day review, and then it goes to the board. So my responsibility was to monitor what went to the board and to properly disposition what the board ruled on on any given change and to make sure that that got transmitted to the program.

Maybe I ought to talk a little bit about being any board secretary and what that means. The Management Integration Office, by the way, today it provides the secretariat function for a whole bunch of different boards. The people in that office act as secretary for the boards. What that is, is the tip of an iceberg in terms of being involved in how a change gets to a board and then what happens to it after the board makes a ruling on it, dispositions it.

In the PRCB, for example, any change that wants to get dispositioned to the PRCB level comes to the Management Integration Office, to the board secretary. The first step is to make a decision about whether or not that change needs to go to the board, actually get presented at a board, or whether or not it is routine enough or noncontroversial enough or whatever that it can go outside the board.

So the up-front decision is, here comes a change. It doesn’t need to go to a board, so we’ll go get a directive written and then take it to the Program Manager and have him sign it—he still has to sign it all—based on rationale that says—of course, he has to agree with that. If he doesn’t like that decision, then it goes back to the board, but by and large, we got pretty good at being able to decide that.

If it goes to a board, then you have to decide who the OPR [office of primary responsibility] is for the change, the organization that’s going to shepherd it through the change process and be responsible for pulling together all the comments to it and making the presentation to the board, and then also which organizations ought to evaluate it, and request those evaluations from those organizations. So that has to be determined, and then it gets scheduled to a board.

There’s a whole set of folks who then keep track of where these changes are in the process, are they being evaluated, are they scheduled to the board, and then if something needs to get deferred, there are meeting coordinators who work in the office who will get it rescheduled. There’s a whole array of meeting support kinds of activities, setting up telecoms—not just setting up telecoms, that’s routine, but making sure that all the right people are on the telecom, participate in the meetings, that kind of thing.

Once a decision is made at a board, then there’s another set of folks, and most of these are contractors, who will generate the directive. Then the directive gets concurred on by various people as necessary and gets signed. What the board secretary does is manage that whole set of activities and approve most of those functions, decides how it’s going to get processed, reviews all the directives.

For a time we did minutes. Minutes are one of my least favorite things. There were people who took minutes at PRCBs, and various other boards have different kinds of minutes. A lot of them just have “Here’s the subject, here’s two sentences of the discussion, here’s the decision.” The PRCB minutes historically had been description of conversations. “So-and-so talked about this for a while, and somebody else responded with this for a while.”

So there’d be this board, the board would last all day, and then a week later, the minute writers would have this set of minutes written up. And they’re very good. That’s a talent that not everybody can do. But they’d have these minutes written up, and then what we would have to do—and I’ve skipped ahead to when I was a PRCB secretary—we’d have to review them and mark them up and make sure they were accurate with respect to what the board did. And it was drudgery. It was just awful. Dave was still doing it at that time, too. We got to talking about “There’s got to be a better way to do this.” So we started looking around to decide whether or not minutes were even—what purpose did they serve other than they were a record of the meeting. That’s important. You’ve got to preserve the record of the meeting, and minutes were pretty good, because we made sure they were accurate in terms of what went on, but they didn’t come out for a week or two afterwards at the best.

So we started looking at who used them. They were kind of a reference that people would want to look at every so often. In terms of when there are investigations or problems, they become very important, but by and large, the ongoing thing with minutes didn’t appear to be the valuable—so we finally got smart enough to figure out that what we could do is record the meeting and do away with all of the resources and time and unpleasantness that some of us felt reviewing minutes, got rid of all that and simply recorded the meetings, and we’ve been doing that for a long time now, and save the tape. If somebody needed to know what happened during some discussion, then we implement the capability to cue up the tape for them, and they could listen to it for themselves and get the best possible reproduction of what happened in the meeting. They could hear the people talking. So that was a vast improvement. Of course, you couldn’t always tell who was talking, but it has worked out well with the tapes.

So where was I? That’s all the things that go along with being a board secretary.

Johnson: As you mentioned, you stayed in that Management Integration Office up until your retirement. Any of the positions in there, are there any instances or specifics that you’d like to talk about, or if you just want to kind of walk through those years?

Heselmeyer: Let me tell you about the CM area support. When I got there, in fact, when Dave got there, configuration management in Shuttle Program was an established discipline. The people who originally put that together back in the seventies deserve an awful lot of credit for having established a body of requirements, the documents, the 07700 documents and then all of the reference documents out of that, that documented requirements for how this program was going to operate, both management and technical, that have withstood the test of time. Included in that was this change control process through these control boards, with membership that’s appropriate across all the organizations, the accounting functions that need to take place when a baseline is defined. But it’s dynamic, it’s changing all the time, and there are more than one kind of baseline. There’s a launch baseline, a baseline of what the configuration is before launch. You baseline that configuration when you’re designing something, and then you’re going to handle the contract. There’s all variations on that theme. But to have this set of stuff in place that has worked with minimal changes over the years is a testament to how well they put this thing together, the whole verification function, having people at the Cape.

The board will approve a change, lots of changes. The vehicle configuration is very dynamic, to put things on vehicles, take things off vehicles, modify vehicles in different ways. But when the board says that, you have to make sure it happens, and there’s a verification function that is supported all the way down to the Cape. And how that works and how reliable it is was put together in a solid way. So part of what we had to do while I was there was not reinvent anything. It was working very well, and it’s a very large network. It goes from coast to coast, from the manufacturers on the West Coast to the launch site on the East Coast in terms of what gets built, what gets approved to be put on the vehicle, what ends up being put on the vehicle, and the verification that it’s on there and it’s on there right and it’s the right thing. That has always worked well. What I did as I worked in CM was to make sure that the discipline stayed in place while trying to make configuration management as user-friendly as possible.

Johnson: You mentioned TQM coming in and the changes that brought. Were there other changes over the fifteen, seventeen years you were in that area that you can think of?

Heselmeyer: They were tweaks on the basic system. Maybe this is an example. One of the first things I did when I went to work in the Management Integration Office was to attempt a rewrite of Volume Four; O7700, Volume Four, is the Program Configuration Management Requirements. It’s a book that is that thick [demonstrates]. It had been tweaked over the years to include different sorts of requirements, to address issues as they had come along, to modify some different kind of changes, and it ended up being kind of hard to read. So one of the things I was asked to do was to rewrite it, but that wasn’t a rewrite in terms of changing any of the requirements, other than maybe some things that were no longer necessary, but to try to make it an easier book to read. So that was one of the first things I did, and we went through there and didn’t do a very wonderful job, in my opinion. We improved it some, but it was still a hard book to read.

Over the years I was in that office, the requirements continued to get refined in certain ways, and one of the last things I did was initiate a rewrite, except this time I had a lot more experience. I had years of experience doing that, and so we reorganized a lot of things, didn’t change significantly any requirements. Of course, the whole thing had to be approved by the PRCB. We couldn’t change any requirement without getting the approval of the program, but we reorganized it and put things together and did eliminate a few things here and there, but now it’s a much more readable book, user-friendly.

[When I joined the Management Integration Office (MIO) the standard time from Change Request (CR) submittal to PRCB presentation was seven weeks. That time was taken up primarily by the PRCB member organizations generating evaluations and then the Office of Primary Responsibility (OPR) organization coordinating those inputs, working any issues, and preparing the PRCB presentation. In 1990 or 1991, I believe, we were challenged by the Program Manager, Leonard Nicholson, to reduce that length of time. So I headed up a working group consisting of representatives of every PRCB organization, which spent over six months examining the individual organization processes as well as the program process. After a lot of debate and fine-tuning of procedures and schedules, we shortened the overall time to three to four weeks, depending on the day of the week the CR is submitted. That was a significant efficiency. It took the cooperation of the entire Space Shuttle Program community, and it is still the standard processing schedule today.]

Most of what we did was accommodate changes in board structures. There was a significant change after Challenger—which is when I first got there—on the verification function. That was done as part of the CM process. Lockheed [Aircraft Corporation] worked down there, and [North American] Rockwell [Corporation] worked down there, and they would verify that things got done right. There was an emphasis on verification after Challenger, and as a result of that, the SIAP was generated. The SIAP is O7700, Volume Eleven, System Integrity Assurance Plan, and it covered verification of lots of different areas, not just the vehicle configuration, but safety and trending. It looked at trending and imposed requirements on the program, on doing a better job of looking at trends to try to forecast problems. As a result of that, the verification function responsibility moved primarily from management integration to the systems integration folks, because while the CM function did the verification in terms of making sure all of the records were in order, the systems integration people did a final kind of engineering evaluation on whether or not the whole big picture fit together. They are the ones that signed the certification of flight readiness, that the configuration is what is should be. So that migrated to the systems integration organization, whereas originally it had been in management integration.

Johnson: Why don’t we stop for a minute and we’ll change the tape out. Then we’ll come back and maybe talk about Columbia.

[pause]

Johnson: If we can, let’s move on to the Columbia accident and what you were doing at that time and how that affected what you were doing after that.

Heselmeyer: I was managing the Management Integration Office and had been for some time. I got up on Saturday morning, was getting ready to go jog. I happened to turn on the radio and heard the report that the Orbiter vehicle hadn’t gotten to the Cape, and when I heard that—but it was still—they didn’t know what was going on. There was a lot of—just wondered what was going on. I thought to myself, “There’s no way the Orbiter vehicle can’t be at the Cape on time.” So this was obviously serious.

So I went to the other room to turn on the television, and in the space of walking from one room to the other thinking about what was going on, it became obvious that if people in Florida didn’t know where the vehicle was, that this was serious. I was trying to figure out how it could not be catastrophic.

Then it became obvious that it was, and it was overwhelmingly sad. I just stood there and felt empty. Not only was it a tragedy for the Shuttle Program, which had been emphasizing safety, and the program was very much aware of the fact that even minor anomalies or accidents would have serious consequences, the program was doing everything that it knew how to do to stay within this very fine line of perfect operations, and to go from that to having that bad an accident was, of course, devastating for the program. And then the human element was beyond description. They were doing what they wanted to do, but still, it shouldn’t cost anybody their life to do that.

So there it was, and I just turned around and told my wife that it was going to be bad and I was going into work. So I got dressed and went into work. Other people were drifting in. I went to my office. Other people were drifting in, and we were following the news accounts, starting to think about who all we needed to start mustering in terms of an investigation, support, what our responsibility would be, because we are the custodian of the program’s records, and spent that Saturday getting in touch with contractors, doing what we could think of to get ready to support an investigation, which already the MRT [Mishap Response Team] had been formed and had met and, I guess, [Harold W.] Gehman [Jr.] had been named. All that happened very quickly on that Saturday.

Sunday morning, turn around, went back into work, and then got a call, which my secretary took and said that [Ronald] Dittemore wanted to see me over in the Action Center, and [Michael E.] Mike Corbin. Mike Corbin worked in the office, and he was the configuration management lead person. He wanted to see Mike and me over in the Action Center. So we walked over to the Action Center. Ron said, “There has been a data and records handling working group chartered by the Mishap Response Team, and you’re the chair. Your responsibility is to identify and preserve all of the accident-related data.”

I stood there and looked at him, and I said, “You mean all of the Program Office data in Houston, right?” I think those were about my exact words.

And he said, “No, all of the accident data everywhere.” My jaw must have dropped, and I just started absorbing that. He just sat there and grinned. And I was to have the first working group report to the MRT that afternoon. This was about nine or ten in the morning.

Mike and I walked back to the office, and I was trying to absorb the magnitude of that responsibility. All of the accident-related data is everywhere. It’s at all of the manned space flight centers and [NASA] Goddard [Space Flight Center, Greenbelt, Maryland] and Headquarters. It’s at contractor facilities all over the country and other parts of the world. For the experiments, it’s at schools and laboratories. It’s at Air Force bases, tracking stations. This stuff is all over, and it’s all kinds of different data. It’s paper and audiotapes and videotapes and computer disks and laptops and films and anything you can imagine. And the scope of this thing in the broadest sense is all of the accident-related data, which I immediately interpreted as STS-107, that flight data, start to finish.

So an immediate problem is, it’s got to be impounded, and I’m wondering how do I start getting my arms around this thing and in a hurry. It’s got to happen right now. So I had some ideas about trying to start making some phone calls, and all of a sudden it’s that afternoon. I go back to the MRT and sat down, and my report was meaningless. It was, you know, “Hi. I’m the chair of this working group, and I’m going to need your help in pulling all this stuff together.”

I remember Dittemore broke in and said, “I’ve got nothing else to say, but that’s the guy you need to talk to with respect to your data.” And it turns out that that’s what opened the floodgates. Me having to get in touch with people was the least of my problems. There were people everywhere who had questions about the data and what to do with it. The initial response of the people who had any data that involved that flight impounded it. There were contingency action plans in place for all of the NASA and contractor organizations, and it spread to the experimenters as well. The impound part of the problem, which was the immediate “Make sure it’s protected,” happened. Everybody did it. In fact, they did it, in some cases, to extremes, which became part of the problem later on. Some folks walked out of buildings and locked the door and wouldn’t let anybody in the entire building.

The other part of what was going on was that people had questions. There were people wanting access to the data, requests for data from Headquarters, from the press, early inquiries from the Accident Investigation Board members, and people didn’t know how they should honor those requests. So what happened immediately after that MRT meeting was that the phones started ringing and e-mails started pouring in. They now had names, because I had told everybody that Mike was, in effect, the co-chair, and people started calling and writing with questions about what to do with their data, who could they release it to, how should they protect it.

There were databases being put together. There was a debris database that was starting to be built. A lot of folks wanted access to the debris database. Who’s supposed to decide who has access to that database along with other databases? It turned out that the answer apparently was Mike and me, because they had a name and they had a data working group. So all of those kinds of requests came rolling in.

The first week, everything we did we had to do with the background of these constant phone calls and e-mails from people about what to do with their data, how to protect it, who to give it to. The working group itself—and we did a lot of that apart from the working group. Database access was, “So-and-so from somewhere wants to get access to the data in this database. Should we let them?” And Mike and I just started making decisions. If it sounded reasonable to us or we knew who it was or we knew what the source was, we’d okay it. If we didn’t, we’d ask for more information, but this whole back-and-forth in terms of allowing people mission data landed on us. We handled all that separate from the working group. That was going on constantly. The formation of the working group came together very rapidly because people called in with who their representative was, and if we didn’t hear from somebody, then I had already kind of figured out who ought to be represented, and we’d call. People were showing up. There was no problem at all in terms of getting support. People wanted to do whatever they could.

So the first working group meeting actually happened on Tuesday afternoon. Based on the rolling questions that we were dealing with, it became obvious we needed to come up with a policy that addressed what is accident-related data. How do you need to protect it? If you haven’t already, you need to, but by and large, everybody had locked down their data. How do you need to protect it? What do you need to do to maintain it? Then who do you release it to and on what authority? As questions came in, we would answer them on the fly, based on the immediate need, even through the working group, but we started working on a policy. It was a data-impound policy and a data-release policy and a data-handling kind of policy.

The working group served as a very good forum to work through that process while answering questions and while developing those policies. We had a draft that—well, we had more than a draft. We had what we thought was a good report on the eighth. And on the eighth at the MRT, I presented the data and record-handling working group impound and release policy document. It was seven or eight pages long.

The reaction that I got was that, “Yeah, it’s a lot of good data. There’s too much of it. It’s too big. People need something shorter, more summary. They don’t need some of that information that you’re documenting in this thing.”

The MRT chair, who was Linda Hamm at the time, said that she was going to take it and cut it back. So we had this working paper. She was going to mark up the parts that she didn’t think were necessary. So we operated with that as our working set of information until we were going to get something back that we could use as official.

That turned out not to be a very crisp exchange, because we didn’t get it back for a while, and when we did, it ended up two pages long. One was impound and one was release. There were some sections that got deleted we didn’t have any problem with. We had dealt early on with how sensitive is what kind of data and did we need to provide guidance to the various organizations about how to handle it or how to transmit it if they needed to send it somewhere. That came back cut, and we decided that’s probably okay.

This stuff doesn’t get classified all of a sudden, and to try to protect it from the press—and the press was everywhere—was something that we decided we didn’t need to try to go to any extra effort to do. If people are e-mailing or mailing or faxing or whatever, then we’re just going to do that.

It was interesting, because I’d be sitting at my desk and the phone would be ringing, and all of a sudden it’s somebody from CNN [Cable News Network] wanting to know something about something, and no clue how they even got my number. But we’d just kind of refer them to go talk to PAO [NASA Public Affairs Office] and get on with what we needed to do. But the crush of the press was truly amazing.

In those early days, with all of this activity going on, things worked out pretty well. Mike and I, in granting access, got that under control, and it helped when the initial rush was over. We did a few things that we had to redo. A couple of things come to mind. One of them is, in addition to the data, there were facilities that were shut down, Control Center being one of them—not shut down, but frozen. The configuration was frozen, which is important for reconstructing data. And [International Space] Station is still flying, and things are getting dicey in the Control Center in terms of they need to have some of those computers up and running for support.

I had gotten a request from MOD to release the Control Center, to unfreeze it. It came from Jack Knight [Jr.], who was Division Chief over there. I knew Jack from Apollo, and, in fact, Jack ended up being one of the Skylab biomed officers, and Jack was not going to do anything that wasn’t okay. He had sent me a detailed e-mail about how they had made tapes and preserved the configuration and could reconstruct it as necessary and all that kind of thing. I said, okay, so I authorized releasing the Control Center for operations.

It turned out later that that was a function that the MRT wanted to retain for itself. The level of authority making was not at all clear in terms of what authority I had as chairman of this working group and what the MRT wanted to retain. As it settled out, the MRT would authorize facilities releases and debris releases, those kinds of things, and I would handle the data, the pure data. But I released the Control Center, and it turned out that wasn’t a problem.

The other thing that we had done initially is, amongst our ground rules for preserving and protecting the data is that there would be no original material released. For computer systems, tapes would need to be made, and if any data was requested, they would be off of a tape. What came back from the MRT—in fact, Dittemore, in one of our offline discussions, said that didn’t sound like enough. You know, if you messed up the tape—he was more comfortable with two tapes. So that got incorporated into the final set of policy, and it took two tapes.

I had already told everybody one tape in the working groups, which the working group met daily, every afternoon, for months, where we would trade information and like that. So we had to go back and fix that. In fixing that, some smaller computer systems, fine, no big deal. There’s mainframes and storage devices out there. That’s a lot of tapes. So we worked a deal in some cases where, if it was a huge number of tapes, we would stay with the one set, and then if they did get a request for more information, what they would do is make a second tape for that portion and then run copies off of that. It was kind of a double failure deal. So we worked through all those kinds of things.

It wasn’t until four, five, six days after the MRT presentation of the original set of policies that we got back the shorter version and worked out a few details on it, but then had basically what remained, the impound policy and the data release policy. Then the question became, who was going to sign them? It’s policies, but here, they’re just pieces of paper, and I wanted somebody to sign it, and decided that I ought to give the MRT the opportunity to sign off on it. I sent it back to them with the question, and never got a response. It ended up—and it never was signed. To this day, those policies are not signed.

So as I was waiting and the working group was meeting and we were dealing with how all of these different organizations all over the country were going to handle their data and release it and what have you, these policies were well known but not signed. I wasn’t signing them because I was waiting for the MRT to sign it. It evolved to where it became a non-issue. I decided that, until told differently, I was going to use these policies as official and tell everybody they’re official and that’s what they needed to abide by. It worked for everybody, all the organizations, except for the Air Force. Later on, when the Air Force was going to release some data to NASA, they wanted fingerprints on that in terms of who’s authorizing it. So they called, and I said, “The working group has said this is the way we’re going to do it,” but they wanted specific permission. So we handled that with a letter, which I signed, to the Air Force command who was responsible for the data. Other than that, it was policy that was adopted without signature.

As we worked through providing guidance to everyone on getting their buildings unlocked but keeping the data, we did things like delegate the authority for all the payload-related data, which we were preserving, lots of questions about payload data on what it would have to do with the accident, delegated that to the office that deals with the payload investigators to let them handle the release of that, but we did not allow release of any of that data on our own. A lot of unhappy principal investigators. It wasn’t flight data; it was their baseline data that they had on the computer or things they were doing during the flight but had to do with 107, and we weren’t letting them mess with it. They were getting very antsy to get their data. Release of those kinds of things, like a laptop or some lab equipment, sample kinds of things, ended up being done by the MRT.

We talked to people about inventorying what it is, and lots of questions about release. Although the policy talked about never releasing originals, by what authority it can be released to what different entities, the CAIB [Columbia Accident Investigation Board], for example, the instructions were not to release any data to the CAIB unless it went through the MRT, and that’s because the investigation board was hiring all—you know, they were getting lots of help, and these people were wanting all kinds of data, the stuff we had impounded, and they were calling.

It was becoming obvious that there was no way to track who had what. So the MRT suggested, and the CAIB agreed, that their request would come through the MRT just so that they would know what they had and could share it instead of asking for the same thing five times. So that was established. Other ground rules with respect to Headquarters, release for Headquarters, or the press, which were referred to other people.

Eventually, once that settled down, we started phasing into the preservation of the data. We chose to use the Challenger model, which was to establish a repository. So the question became, where should that repository be and what should go in it? After casting around for opinions and talking it over with the Historian, the records people at JSC and NARA, National Archives [and Records Administration] folks, we decided that the repository could be in the same building at JSC that holds the Challenger repository, which is an outbuilding out back, because it’s qualified to ninety-five-mile-an-hour winds. It’s still not real high, but it’s about as good as it’s going to get without putting it in with the Moon rocks or whatever. So we worked with the records people to establish space in that building for what would become a repository.

We started working with all the different organizations to get inventories of what their data is that they had, and that’s notebooks of stuff. They did a wonderful job of, to a detailed level, inventorying all this data that had been impounded. That was enormous work on their part and took a lot of people, but they provided good inventories of the data.

What of all that data would be appropriate to come to a central repository? Lots of questions about that. For example, the Orbiter build records. One of the initial questions was, are the build records all the way from day one part of the accident investigation? Because the vehicle, as it was configured, was a product of changes, an ongoing change process, ever since it was built. So basically, yes, because they all influenced the way that vehicle was put together, and that was very important during the investigation. Those were accident-related records. But they also, where they are, are protected, and it would be overdoing it and unnecessary to copy all of that and put it in a central place in Houston. So those records are in place.

The program records, the records that I had custody of in Building 1 at JSC of the program records, we decided don’t need to go into a repository, although some work was started on that. But there they are protected and access is very limited. There’s no point in having copies of all those, because those records will be around as long as the repository. So we decided not to include those.

One of the biggest questions had to do with computer data. Paper and film and that kind of thing is easy. There it is. But there’s all kinds of different computer formats, programs that have generated data that two years from now are going to be obsolete. That was a huge problem in terms of getting that data to JSC in a repository and then being able to access and make sense of it within a few years. It happened on Challenger, but the Challenger records were in the custody of the Management Integration Office for a number of years until we turned responsibility over to JSC. So we had familiarity with those Challenger records and some of the problems with them, in terms of having tapes over there, old mag [magnetic] tapes off of some computer somewhere. No clue what was on there, and even if there was, no machine exists to be able to read it.

So that part of that repository was not preserved as well, or consideration given to how to deal with that. So I was very much aware of the fact that we needed to be careful with all the computer kind of data, computer-based data. What we ended up doing over time was we got together with the National Archives and records people, and we have made an agreement with them that after that data gets gathered up, we would transfer it to them because they are better equipped to either have access to the equipment that would be able to read that data or to convert it. They do that. That’s what they do, and they have initiatives going to establish things in common formats.

We did not do that with the Challenger records. We still have custody of the Challenger repository. JSC has custody, and to release any of that data has got to have the concurrence of the program, and it’s still not in NARA records. We took a different tack with the Columbia data simply because we didn’t want all of that to get obsolete and useless. So that which is coming to the repository that has formatting kinds of things we’re going to get to NARA.

As the months went on, the whole activity settled out. There was a lot of work that needed to be done in inventorying and coordinating for repository and ongoing monitoring of requests for access, what to do with the data. Over at Marshall, in the course of them dealing with their impounded data, they found some Challenger data they didn’t know they had stuck off in a building somewhere.

But even simple questions, like we required that we know what it was and where, in what location. There were cases where they wanted to move it, and was it okay to move it? So we’d have to talk about what is it and how complicated and why do you need to move it, because anytime stuff comes out of impound, then you’ve got to make sure you keep track of it all, and if it’s going across town, I’m not so sure you want to do that. Those kinds of things.

Eventually we got all the inventories, and by the time I left, we had told folks to start sending their data. I checked recently with Mike, and he said the data’s still dribbling into the repository, but it’s working.

It was an enormously trying time from the standpoint of having to get all that together in a short period of time with a lot of stuff going on, and without the help of the people whose data it was and their having impounded it and their having been willing to cooperate in every way possible, it wouldn’t have come together. The working group turned out to simply be a forum where people could come talk to each other and learn from each other and get some badly needed guidance and to provide a common basis for working with it. But everybody stepped up and did great work.

Johnson: What led to your decision to retire this past year?

Heselmeyer: I was doing the same job that I had been doing for a long time. The CAIB had a whole twenty-nine recommendations, a lot of them technical, a lot of them organizational, and a lot of the organizational ones were being thrashed around. The agency committed up front to implementing every one of them. A lot of new people, a new Program Manager, new Office Managers of various kinds. Ron [Dittemore], of course, was gone. So there was a new management style addressing a new set of problems, trying to deal with some fundamental issues in terms of how the program was going to operate.

I started working in that environment, and it became obvious to me that—a couple of things. One, I was tired. I didn’t realize how tired I was after that year until after I retired. There was a weariness about what I was doing that I had never felt before, and I recognized it as being different and probably a sign that maybe I ought to let somebody else do this for a while. That, combined with the new management, new approaches, fresh thinking.

There was never anything ever said or intimated to me that I wasn’t welcome to keep on keeping on, but you start getting the feeling that you’re the old school and here’s the new school. It’s very intangible, but you start thinking about that. It made me think about some of the things that were going on in terms of proposed changes or the way the new folks are thinking about things, that I would say to myself, “That’s not the way we used to do it. Why do you want to do that?” It was really old-school thinking.

So after having done that for a while and being—and I had thought about retiring. I’d actually given it some thought a year or two before that and really kind of decided I wasn’t ready to do that, but it just seemed to me like the time had come and the program needed this fresh start with the new people to get on with getting back to flight. I thought it was a nice break point, and I retired.

Johnson: In the first interview you talked about some of the Flight Directors that you worked for and their different styles, after Apollo and Skylab, and you’ve worked for different managers, and then you, yourself, have been a manager. How would you describe your management style, and do you think anyone in particular may have influenced your style of management, or where that came from?

Heselmeyer: You mean my management style? I think I came to it naturally, and it’s very hands-on. I wouldn’t ask the folks who supported me in my office to do something unless I had given it enough thought or talked with them about how to make it happen to know that it was a reasonable request and it was a doable request. I did not come up with big ideas and dictate to people. I liked working closer with the people who work with me and getting their ideas and trading information in terms of Can you do this?” That includes the contractors. The Management Integration Office was, for most of the later years, nine civil servants and then hundreds of contractors, and the contractors are the ones who got the real work done. So, being in close communication and open communication with the contractors, they are the ones who supported this whole change control process with meeting coordinators and logistics people and directive writers, and all those functions. It’s a very procedurally intensive process, and I tried to partner with them as closely as I could to be amenable to things they wanted to do that would make it better or to offer them ideas. It was rare, although it happened sometimes; normally, I would not just dictate how to do something. I’d work with you. So I was a hands-on kind of guy.

The Management Integration Office also was, as I mentioned earlier, responsible for the information technology support for the program. That’s kind of an interesting situation for management style, because I am not an information technology kind of guy, but I had people who were, who worked for me, and they were very good. I guess it speaks to my management style, because what I did with respect to that whole area of support was give them the responsibility to go make it happen and work right and then stay in touch, and if they needed things or needed any advice or management help, I was happy to do that, but I left that to the people who knew how to do that. I was not techie-inclined.

Johnson: In dealing with contractors, did you ever have to deal with the DoD [Department of Defense] as far as payload integration?

Heselmeyer: Yes, indeed. Early on, not long after I got to the Management Integration Office, there were classified payloads being flown, and so we had to process classified data. So one of the things that I did was implement a classified support room over in Building 37, I think it was. There was a building over there that had been a locker room/shower, no longer used. We got with [NASA JSC] Security and converted that facility to a secure data processing room, tempest-certified and everything. In fact, I saw some of the pictures of it. It used to be a locker room, and now it’s an office with computers in it. And then we had classified PRCBs for a period of time. We did it in [Building 1, Room] 602; 602 would be swept. You had to have clearances to get in, very closely monitored. There would be classified information discussed, and we had to process the changes to get it to the board, then we had to issue the direction out of the board, all classified. That’s what we did in the facility.

Minutes; we had minutes back at that time. The minutes would be classified, so we had to store classified material, write the directives. We had classified directives. It took a lot of extra going on.

With respect to the DoD, we did have interface with the DoD on all of those activities, and they were a good working partner. We didn’t have any real problems with them, not in my area. There were some discussions that went on in terms of need-to-know kinds of things that I know they had some uneasiness about, because we were a civilian agency, and they probably wondered if we knew how to keep secrets and all that. They were used to it, and so they were, I guess, understandably nervous, but those things got worked out, never affected anything I did.

Johnson: Looking back over your entire career, I know the last time we talked about your most challenging period of time during Apollo. Would there be anything that stands out in your mind as being the most challenging time during your entire career?

Heselmeyer: I would say two things. One of them was Apollo 13 and the whole activity associated with that flight recovery, and the other thing would be the Columbia accident aftermath and the data and record handling working group responsibility getting that on one day and having to have all those policies and people working in some kind of concert. That was a challenge. After having done that intense work for several months and then less intense but ongoing for more months, is part of what, I figured out later on, helped to create that sense of weariness. But that was an enormous challenge, that one. So I think those two things are what stand out.

Johnson: If you don’t mind, I’m going to see if Rebecca and Jennifer have any questions.

Heselmeyer: Sure.

Wright: I have one, and it’s about Columbia. I guess it’s a two-part. Did you have any input from the Legal office here at the Center or from NASA Headquarters that told you or to help you guide on what to do with the data that you were collecting? And, was there a lot of data coming in from the field, from the recovery efforts, that you were having to deal with as well?

Heselmeyer: Last question first. The debris data from the Mishap Response Team out in the field, that was not part of the working group. That, by and large, went directly to KSC, and that was under the control of another group of folks. So I did not do debris. And with respect to the Legal Office, yes, indeed. The Legal Office was one of the offices that I consulted with in terms of the data, government obligations with respect to that data, the repository, function and obligations with respect to that. So, yes, Legal was involved.

Johnson: Is there anything else that we haven’t talked about that maybe you want to mention before we go?

Heselmeyer: Just a couple of observations, I guess. In working in the program, I worked with a whole set of Program Managers. In thinking back on that, the space program has been blessed with a series of people who manage that program who were bright and insightful and dedicated to what they do. Every one of those people, in my opinion, did an outstanding job of managing a very complex program.

In the broader view, the whole time at NASA, it was a pleasure and a privilege to work in an environment and with people who, in the vast majority of cases, are there because they’re doing what they want to do, what they like to do. They’re not just doing it for a paycheck and can’t wait to get home on weekends; they believe in what’s going on. They think it’s important. They want to do their part. And being able to work in that environment with those kind of folks is just wonderful, and I count myself lucky to have been able to be part of that community for a long time. It’s an important part of working at NASA, at least at JSC, my little piece of what it was, with all those people that I was associated with and their dedication to what they’re doing.

Johnson: We appreciate your coming again today and speaking with us.

Heselmeyer: Like I said, it’s my pleasure. I enjoy talking about it.

Johnson: Thank you so much.

[End of interview]