15 10 510 https://oralhistory.uah.edu/files/original/1439acc4423ad780f2be458091d5279e.jpg 4598197eb9b09fa4ae86fb6882190ee7 https://oralhistory.uah.edu/files/original/edb08d4a75b12b8ddca1a63d0f9cd53f.mp4 12b4b938f605251636d51177f0f20564 Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Title A name given to the resource Saturn V Collection Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Identifier An unambiguous reference to the resource within a given context ohc_stnv_000029_A Title A name given to the resource Neubert, Erich W. Description An account of the resource General Saturn development and programs, benefits of earlier programs, contractor and vendor relations. Date A point or period of time associated with an event in the lifecycle of the resource 1971-08-23 Format The file format, physical medium, or dimensions of the resource .MP4 Type The nature or genre of the resource Interviews Audio Source A related resource from which the described resource is derived University of Alabama in Huntsville Archives and Special Collections, Huntsville, Alabama Language A language of the resource en Rights Information about rights held in and over the resource This material may be protected under U. S. Copyright Law (Title 17, U.S. Code) which governs the making of photocopies or reproductions of copyrighted materials. You may use the digitized material for private study, scholarship, or research. Though the University of Alabama in Huntsville Archives and Special Collections has physical ownership of the material in its collections, in some cases we may not own the copyright to the material. It is the patron's obligation to determine and satisfy copyright restrictions when publishing or otherwise distributing materials found in our collections. https://oralhistory.uah.edu/files/original/0d46327185983f8a7899419594d6f9de.pdf ac968afa5bbcd39af80ac3223a1ef1db Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Title A name given to the resource Saturn V Collection Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Identifier An unambiguous reference to the resource within a given context ohc_stnv_000028_T Title A name given to the resource Mrazek, William A. (Transcript) Date A point or period of time associated with an event in the lifecycle of the resource 1971-08-30 Format The file format, physical medium, or dimensions of the resource .pdf Type The nature or genre of the resource Interviews Text Source A related resource from which the described resource is derived University of Alabama in Huntsville Archives and Special Collections, Huntsville, Alabama Language A language of the resource en Rights Information about rights held in and over the resource This material may be protected under U. S. Copyright Law (Title 17, U.S. Code) which governs the making of photocopies or reproductions of copyrighted materials. You may use the digitized material for private study, scholarship, or research. Though the University of Alabama in Huntsville Archives and Special Collections has physical ownership of the material in its collections, in some cases we may not own the copyright to the material. It is the patron's obligation to determine and satisfy copyright restrictions when publishing or otherwise distributing materials found in our collections. https://oralhistory.uah.edu/files/original/6c8e3923cafcaf6e88e987647b7b6ade.jpg 4598197eb9b09fa4ae86fb6882190ee7 https://oralhistory.uah.edu/files/original/0713ce620ec317e87bee5c5755b2380f.mp4 e5df4e126c629e9f39f048effe50b16f Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Title A name given to the resource Saturn V Collection Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Identifier An unambiguous reference to the resource within a given context ohc_stnv_000028_A Title A name given to the resource Mrazek, William A. Description An account of the resource General Saturn development and problems, contractor relations. Date A point or period of time associated with an event in the lifecycle of the resource 1971-08-30 Format The file format, physical medium, or dimensions of the resource .MP4 Type The nature or genre of the resource Interviews Audio Source A related resource from which the described resource is derived University of Alabama in Huntsville Archives and Special Collections, Huntsville, Alabama Language A language of the resource en Rights Information about rights held in and over the resource This material may be protected under U. S. Copyright Law (Title 17, U.S. Code) which governs the making of photocopies or reproductions of copyrighted materials. You may use the digitized material for private study, scholarship, or research. Though the University of Alabama in Huntsville Archives and Special Collections has physical ownership of the material in its collections, in some cases we may not own the copyright to the material. It is the patron's obligation to determine and satisfy copyright restrictions when publishing or otherwise distributing materials found in our collections. https://oralhistory.uah.edu/files/original/9e4260a0e0fbaa94b36da9e53a1bb682.pdf fe12d5421f7cb52a3a651a94cb048bb3 Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Title A name given to the resource Saturn V Collection Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Identifier An unambiguous reference to the resource within a given context ohc_stnv_000027_T Title A name given to the resource Morata, Lorenzo (Transcript) Format The file format, physical medium, or dimensions of the resource .pdf Type The nature or genre of the resource Interviews Text Source A related resource from which the described resource is derived University of Alabama in Huntsville Archives and Special Collections, Huntsville, Alabama Language A language of the resource en Rights Information about rights held in and over the resource This material may be protected under U. S. Copyright Law (Title 17, U.S. Code) which governs the making of photocopies or reproductions of copyrighted materials. You may use the digitized material for private study, scholarship, or research. Though the University of Alabama in Huntsville Archives and Special Collections has physical ownership of the material in its collections, in some cases we may not own the copyright to the material. It is the patron's obligation to determine and satisfy copyright restrictions when publishing or otherwise distributing materials found in our collections. https://oralhistory.uah.edu/files/original/432ed16143074011e756a13c595a7730.jpg 4598197eb9b09fa4ae86fb6882190ee7 https://oralhistory.uah.edu/files/original/f1c575a49f9f6cd61bbcf8404e28a9bc.mp4 afd2a4051c83ee98092b1a259a4941a3 Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Title A name given to the resource Saturn V Collection Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Identifier An unambiguous reference to the resource within a given context ohc_stnv_000027_A Title A name given to the resource Morata, Lorenzo (Part 2) Format The file format, physical medium, or dimensions of the resource .MP4 Type The nature or genre of the resource Interviews Audio Source A related resource from which the described resource is derived University of Alabama in Huntsville Archives and Special Collections, Huntsville, Alabama Language A language of the resource en Rights Information about rights held in and over the resource This material may be protected under U. S. Copyright Law (Title 17, U.S. Code) which governs the making of photocopies or reproductions of copyrighted materials. You may use the digitized material for private study, scholarship, or research. Though the University of Alabama in Huntsville Archives and Special Collections has physical ownership of the material in its collections, in some cases we may not own the copyright to the material. It is the patron's obligation to determine and satisfy copyright restrictions when publishing or otherwise distributing materials found in our collections. https://oralhistory.uah.edu/files/original/44264f1722945731e1d5a9cf52090426.jpg 4598197eb9b09fa4ae86fb6882190ee7 https://oralhistory.uah.edu/files/original/5ec6261f9cb85928a74f5849c5646399.mp4 51db09bd2de50e1211d750fcb9e1d267 Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Title A name given to the resource Saturn V Collection Oral History A resource containing historical information obtained in interviews with persons having firsthand knowledge. Interviewee The person(s) being interviewed Morata, Lorenzo Interviewer The person(s) performing the interview Bilstein, Roger E. Duration Length of time involved (seconds, minutes, hours, days, class periods, etc.) 0:15:49 Transcription Any written text transcribed from a sound Morata Part 1 [00:00:00] Roger Bilstein: Okay, maybe you could just…If you would start by telling a little bit how you got on the Saturn program and what you did when you first started and what you've been doing since. [00:00:13] Lorenzo Morata: Fine, fine. I graduated from the University of Oklahoma in 1960—June of 1960—and I came to work at the McDonnell Douglas, which at that time was the Douglas Aircraft Company-Missiles and Space Division. I went to work for…About the first four months that I was with the company, I worked on the Delta program, which was located at Santa Monica, and they were in the development of electronic black boxes. My first love at that time was I was an electronics design engineer supposedly when I got out of college, and I wanted to do a lot of initial design with transistors and this kind of circuit design kind of aspect. I requested to be transferred to the Saturn program. I went over on the Saturn program around November of 1960, which was pretty close to the initial design phase of the Saturn program. I believe the company had gotten a contract right about that summertime, and at that time I went to work in what they call the electronic design section. I worked on part of our propellant utilization system, which was developed for the S-IV program. The propellant utilization system at that time was a closed-loop type of system that maximized or minimized the residuals between the LOX and the hydrogen tank on IVB. What it did was regulate both the LOX flow in relationship to the hydrogen flow to make all both masses deplete at the same time and end up with minimal residuals. Therefore you could optimize payload kind of considerations. [00:02:04] RB: Is this where this propellant utilization capacitor comes in? [00:02:07] LM: Yes, yes. And the propellant utilization capacitor, as we know it, are continuous probes. In the LOX tank, it's one continuous probe, which is about twenty-some feet. In the hydrogen tank, we have one continuous probe, which is about forty feet. It's made up of two sections. What this does is give you a continuous monitoring reading device, which you're able to tell at any time what the mass in the tank or what level in the tank it is. As one depletes, it actually triggers the other one. We have a LOX valve going to the main engine. What happens is, as a function of what's happening in the hydrogen tank, there's an error between that probe and the LOX probe. The LH2 probe and the LOX probe compare itself and give you an error signal, which then is closed-loop transformed to open up the LOX valve or close it as a function of what mass is going through the hydrogen side of the engine. If it's going fast or slower, it always optimizes a certain mixture ratio. In our case, it's 5:1. What I did on that particular system—it was an analog computer device—and what I did for that system, the analog computer requires different voltages, both AC and DC voltages. My responsibility at that time was to design what we call—it was really a power supply—it's called an inverter/converter. What that means is that you take twenty-eight volts from a battery, and it converts it to AC voltages, which at that time we required something like 115 volts and 400 cycles to drive our servo motors, and one was on the LOX circuit. We had a valve on the LOX side of the engine, which was driven by a motor for opening and closing as a function of what was happening in the hydrogen tank. [00:04:18] RB: This is on the side of the engine. [00:04:19] LM: Right, it's up on the turbos. It's not on the side of the engine. It's coming down the line. It's on the pump on the engine. It's near the engine. It's sort of like a valve right in coming down from the tank to the engine. What you do is bypass some of the LOX and control it—either open it or shut it—to let more LOX or less LOX flow through. By regulating the LOX flow as a function of what's happening to the hydrogen side, you always make sure that the mixture ratio between LOX and hydrogen is 5:1. By doing that, by setting the mixture ratio to a constant number like that, what you're able to do is then deplete both masses at the same time. You load for hydrogen, and you load for LOX, and what you like to do is, at the end of mission, just be at zero, so you don't have to carry a lot of extra weight as far as LOX or hydrogen, and you can use all that for payload. If you can accurately predict how much mass you have to have to meet your mission and then make sure you use every drop of it, that's going to optimize how much payload you can put on because you don't have any extra mass weight around at the end of the mission. [00:05:41] LM: Now, the inverter also, at that time, put out 115 volts, 400 cycles, plus it changed a lot of voltages DC-wise. You needed some different ranges of DC voltages like fifteen volts, twenty-five volts, five volts, and that's where you call it an inverter/converter. In one case, you usually end up changing DC to AC and DC to different levels of DC. Start out with a twenty-eight volt battery, and you can end up with 115 volts, 400 cycles for driving motors or lights or those kinds of things. You end up with different DC voltages like they want to shave, you know, you got a twelve volt battery, a five volt battery, a six volt battery. I designed that, designed/developed. I was the system engineer as well as the design engineer for that portion of the inverter/converter. It was a black box by itself. I did all the design on it circuit-wise. Then I was involved when we were laying it out mechanically from an RFI standpoint, radio interference standpoint, the packaging involved with it, plus the development of it, how we were building it in the shop, how we were qualifying it. I brought it through the whole gamut of checkout when we put it on the bird, and we married it to the propellant utilization electronics. When it went into checkout, I was instrumental in following that one through. At that time, it gave you a pretty good feel. At that time, I was the design guy, the systems engineer kind of guy that carried that design all the way through. I was involved in the initial design concept as well as the development and qualification of both the inverter and the PU systems for that matter. [00:07:36] RB: One of the things that we're interested in is the evolution of technology in this aerospace, especially the Apollo thing. Was there any kind of similar system in development in the Centaur as the only other real liquid hydrogen vehicle? [00:07:52] LM: No. At that particular time, I think, and that was done just before I had gotten here, there had been a canvassing made of the industry as far as propellant utilization systems were concerned. I think our concept was the first one where we continuously monitored a closed-loop system. Before I think the Centaur, and I can't speak with a lot of…I don't know what the Centaur system was at that particular time, but I know that they probably used level sensors. I don't know if the Atlas uses level sensors where there are discrete points, not a continuous probe. [00:08:37] RB: Yeah, and boy, this is really out of my mind here, but how is this continuous probe…How do you get the feel out of it? [00:08:47] LM: Well, what happens is electrically, when you build it, when you manufacture it, they can give you a calibration. Just like any other tool that you can calibrate it in the lab, and you know what it is actually in the lab. When we buy it—our particular manufacturer of the probes is Minneapolis Honeywell—and when they design it, they can design it so that you know it's so much capacitance change. Sort of like a thermometer kind of concept is, you know if it goes up—the mercury goes up so far—it's at a certain point. The vendor can build it so he knows what its capacitance is from the tip bottom to the top of the probe. That's really what we're interested in is a change of capacitance. He can tell you when he builds it, and he calibrates it, he'll tell you, “Okay, this point at the bottom, which we consider our empty point, is this capacitance, and as you fill it, you'll get a change of capacitance.” He can calibrate it for you. He'll check it out in his lab before he sends it to us. When we put it inside our tank, we know what it is at the bottom, which is our empty point. What we get…Capacitance is really electrical signal. We receive a very minute electrical signal from the probe, and that's what excites our electronics. As we fill from the bottom of the probe up, this mass changes the dielectric of the probe, and we get a change of capacitance. That change of capacitance stimulates the electronics. We know as we get this much change, we've got that much up above the empty point. Then we also know where the top of the probe is, and we know the tank geometry. Okay? Then we can correlate as the mass goes up the probe, the capacitance changes. We correlate that till we know how far that point or any point is above the bottom of the probe. Then we know what the tank geometry is, and we know how much can go in there, so we know that there's enough mass up here. [00:11:03] RB: That comes to you as an automatic readout. [00:11:05] LM: Yes, we get an automatic readout. This signal goes into our propellant utilization electronics, and those send a signal back to the ground to a computer that says, “Okay, you've got so much mass inside the tank at this point.” Okay? We've got ways to electronically look at it so we know where we are inside the tank. As you fill that up, you'll get a reading back in the block house, and you'll know exactly where you're at. The same thing, as we deplete down, both in flight and when we go through a static firing or when we go through a countdown demonstration test at the Cape, when we deplete, we see the same thing happening in reverse. We get a change back, and we can tell where we are until we're down at the bottom. It's a continuous reading, and I think that was one of the key factors that I think our design or our system helped evolve was that you could tell at any point in time. Up until that time, you had what they call, you could have level sensors, which are really discrete points. You can have a small capacitor at the bottom of the tank, one ten feet above that, one twenty feet above that, thirty feet above that. As your mass goes across that capacitor, you have a change of state, which also comes out as a function of voltage or some electrical signal. As the mass changes, your dielectric changes, your capacitance changes that gives you a different electrical stimulus to the ground so you know, hey, it was dry before, now it's wet. You know you've got that much mass. Then you keep on loading, and you won't know where you are until the next one picks up. Now, you could end up putting as many of these discrete points as you wanted to. You could put one every foot. [00:12:58] RB: That's going to ask you about that, okay. [00:12:59] LM: You could put one every foot or every ten feet or every twenty feet. But then you'd have to have different electronics for every one of them, so your system would be more complicated. You'd have to have wiring inside the tanks for every one of those things. You'd have to have connector feed-throughs. Your system could get more complicated. Just a number of equipment in this kind of thing. [00:13:25] RB: It's beginning to come through now, the particular advantage of this single unit capacitor you're talking about now. [00:13:31] LM: Yeah, you could always know at any point in time where you are mass-wise inside both tanks. I think it was a real…We felt real good about the system at that particular time. We still do. [00:13:49] RB: Is this ultimately tied into the instrument unit up there? [00:13:53] LM: No, no. The instrument unit provides all the guidance for all the stages below us. The instrument unit sits on top of the S-IVB and guides the S-IVB, S-II, and the S-IC. Now the only correlation that you have between the propellant utilization system is that the IU system will generate cutoff for the main engine—it'll just stop the main engine. It's not as a direct function that we're feeding them information, okay? We'll feed all our information to the ground. Now the ground has…They can issue commands from the ground—program commands—that they can shut off the engine through the IU. and/or the IU can be programmed for what we call velocity cutoff. At a certain point in the flight program, the IU could send a command based on time and shut us off. The PU itself is not closed loop with the IU. The propellant utilization system is only closed loop inside the S-IVB stage. That's the way the concept started out on the S-IV program. [00:15:14] RB: Was this a…Now can you tell me again what the Thor was in terms of propelling utilization? Did you have any kind of similar…? [00:15:21] LM: No, the Thor doesn't have a continuous probe. [00:15:24] RB: Didn't have it at all, no. [00:15:26] LM: The S-IVB I believe was the first time we used the, the S-IV program was the first usage of the continuous probe. Now there are some programs that have used what they call a short probe where concept-wise you've used either mass sensors… [tape ends] Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Identifier An unambiguous reference to the resource within a given context ohc_stnv_000026_A Title A name given to the resource Morata, Lorenzo (Part 1) Format The file format, physical medium, or dimensions of the resource .MP4 Type The nature or genre of the resource Interviews Audio Source A related resource from which the described resource is derived University of Alabama in Huntsville Archives and Special Collections, Huntsville, Alabama Language A language of the resource en Rights Information about rights held in and over the resource This material may be protected under U. S. Copyright Law (Title 17, U.S. Code) which governs the making of photocopies or reproductions of copyrighted materials. You may use the digitized material for private study, scholarship, or research. Though the University of Alabama in Huntsville Archives and Special Collections has physical ownership of the material in its collections, in some cases we may not own the copyright to the material. It is the patron's obligation to determine and satisfy copyright restrictions when publishing or otherwise distributing materials found in our collections. https://oralhistory.uah.edu/files/original/12ce1e61d7b8be6fb5a292e02b6ccad9.pdf 1286807ce83b92026cef8b2609f89e21 Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Title A name given to the resource Saturn V Collection Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Identifier An unambiguous reference to the resource within a given context ohc_stnv_000025_T Title A name given to the resource McCulloch, James C. (Transcript) Format The file format, physical medium, or dimensions of the resource .pdf Type The nature or genre of the resource Interviews Text Source A related resource from which the described resource is derived University of Alabama in Huntsville Archives and Special Collections, Huntsville, Alabama Language A language of the resource en Rights Information about rights held in and over the resource This material may be protected under U. S. Copyright Law (Title 17, U.S. Code) which governs the making of photocopies or reproductions of copyrighted materials. You may use the digitized material for private study, scholarship, or research. Though the University of Alabama in Huntsville Archives and Special Collections has physical ownership of the material in its collections, in some cases we may not own the copyright to the material. It is the patron's obligation to determine and satisfy copyright restrictions when publishing or otherwise distributing materials found in our collections. https://oralhistory.uah.edu/files/original/5962f683dfa1f2d82addab0ee7343edd.jpg 4598197eb9b09fa4ae86fb6882190ee7 https://oralhistory.uah.edu/files/original/39db8b9427de08e5940409c11a022817.mp4 ce7a18c83515205ff5607cf77d41f05b Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Title A name given to the resource Saturn V Collection Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Identifier An unambiguous reference to the resource within a given context ohc_stnv_000025_A Title A name given to the resource McCulloch, James C. Description An account of the resource S-IVB, Saturn IB Manager Date A point or period of time associated with an event in the lifecycle of the resource 1971-08-23 Format The file format, physical medium, or dimensions of the resource .MP4 Type The nature or genre of the resource Interviews Audio Source A related resource from which the described resource is derived University of Alabama in Huntsville Archives and Special Collections, Huntsville, Alabama Language A language of the resource en Rights Information about rights held in and over the resource This material may be protected under U. S. Copyright Law (Title 17, U.S. Code) which governs the making of photocopies or reproductions of copyrighted materials. You may use the digitized material for private study, scholarship, or research. Though the University of Alabama in Huntsville Archives and Special Collections has physical ownership of the material in its collections, in some cases we may not own the copyright to the material. It is the patron's obligation to determine and satisfy copyright restrictions when publishing or otherwise distributing materials found in our collections. https://oralhistory.uah.edu/files/original/899d706b93786a69e9730244b0226408.jpg cc0c4f909af1a8ef79e706ad5968148a https://oralhistory.uah.edu/files/original/5bdaf3ff55f52c68189839ab6793291a.mp4 27f5f841e1562af83c8e8833df175d73 Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Title A name given to the resource Christensen, David Collection Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Identifier An unambiguous reference to the resource within a given context ohc_crst_000017_A Title A name given to the resource Kaschig, Erich Description An account of the resource Early days of rocket development in Germany. V-2 development at Peenenuende. Date A point or period of time associated with an event in the lifecycle of the resource 1971 Format The file format, physical medium, or dimensions of the resource .MP4 Type The nature or genre of the resource Interviews Audio Source A related resource from which the described resource is derived University of Alabama in Huntsville Archives and Special Collections, Huntsville, Alabama Language A language of the resource en Rights Information about rights held in and over the resource This material may be protected under U. S. Copyright Law (Title 17, U.S. Code) which governs the making of photocopies or reproductions of copyrighted materials. You may use the digitized material for private study, scholarship, or research. Though the University of Alabama in Huntsville Archives and Special Collections has physical ownership of the material in its collections, in some cases we may not own the copyright to the material. It is the patron's obligation to determine and satisfy copyright restrictions when publishing or otherwise distributing materials found in our collections. https://oralhistory.uah.edu/files/original/0cca248fc659b3beb25fed924885c424.jpg 4598197eb9b09fa4ae86fb6882190ee7 https://oralhistory.uah.edu/files/original/ea8526c65068559d2576bb40ae374acf.mp4 4353c2efd7ff5eb17c297dc220b49895 Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Title A name given to the resource Saturn V Collection Oral History A resource containing historical information obtained in interviews with persons having firsthand knowledge. Interviewee The person(s) being interviewed Johnston, Sid Interviewer The person(s) performing the interview Bilstein, Roger E. Duration Length of time involved (seconds, minutes, hours, days, class periods, etc.) 0:45:49 Transcription Any written text transcribed from a sound Johnston [00:00:00] Roger Bilstein: Interview with Sid Johnston. Summary of your career, I know you did other things before you got into the Saturn V program office, and I wonder if you could just give a brief background of how you got started in management or whatever, then we'll bring it [up from that?]. [00:00:20] Sid Johnston: You mean outside of NASA? [00:00:22] RB: Yeah. [00:00:23] SJ: Well, I guess I could start off by saying, Roger, that I had finished undergraduate role at Georgia Tech, I believe in ‘53, in Industrial Management and Industrial Engineering. The first job I took was in private industry with the Chemstrand Corporation in Decatur, Alabama—now the Monsanto Chemical Company. Originally started off a little work in the construction end of them and then in the program control, and I got transferred back from Pensacola, Florida to Decatur research and development end of the thing where I got involved in management. I stayed with them about ten years in the management end and then came to work for NASA here in Huntsville down in the manufacturing and engineering laboratory, it was called at that time. Really a program control type job. I stayed there about a year, and then I transferred. [00:01:27] RB: When was that again? [00:01:31] SJ: When I was in the manufacturing and engineering lab? I was about 19-and-61. That timeframe. I only stayed down there relatively short time, as I recall, about a year. Then I came to work in the Saturn program office under Bill Sneed, which is essentially this office I'm in now. Bill Sneed had this job. I've been involved really in management of the Saturn program for about the last ten, eleven, or twelve years now. [00:02:05] RB: When did Bill Sneed leave? When did you [take his job?]? [00:02:11] SJ: Bill Sneed left this job about four years ago, I believe now, somewhere in that timeframe. I really have to check to be sure. Of course, at the time he left, I was back in graduate school at Tech. I went back and got a Masters in Industrial Management. Bill Sneed left during that time, so that was about the ‘69 timeframe. Then they had a fellow here by the name of Horton Webb, who was here a relatively short time. Then a fellow by the name of Curt Hughes, who now works in the HEAL program, was here for about—I don't know—a year and a half or something like that in this slot that I'm in now. Actually I took over the job when Curt Hughes left to go to the HEAL program. [00:03:03] RB: I wanted to ask you about Curt Hughes because I've gotten some transcripts of the presentations he made to L. Bell and [inaudible] and some of those things. I wasn't sure who he was. That's one of the questions I wanted to ask. [both laugh] [00:03:16] SJ: Okay, Curt is sort of a…I think sort of a deputy manager to Dr. Speer. Curt has responsibilities, sort of a deputy management position plus a program control manager of that program similar to this job here. [00:03:31] RB: In HEAL? [00:03:32] SJ: In HEAL, that is correct. Now I want to make one other note that I'm not sure how pertinent it is, but anyway, prior to my going back to Tech for a year, back about in the ‘64-'65 time, I went back to Athens College at night and got a degree in Mathematics. I'm not sure how that ties into management except really I just wanted to see if I was sharp enough to get a degree in math, I think. [laughs] I don't really use it. [00:04:02] RB: You made it. [00:04:03] SJ: Yeah, I made it. [laughs] [00:04:06] RB: Okay, one of the things that gets me about studying this thing is that I've heard it said that Saturn V program management is unique. What I'm not really sure…What…Why is it unique in comparison to your experience with other management things even outside of NASA for example? What do you think really makes a difference in many other kinds of management programs? [00:04:31] SJ: The outstanding thing, Roger, that stands out to my way of thinking about that is that management of the Saturn program developed in a manner that was extremely visible to people associated with the program. In other words, it was a way—I'm not sure if force and function is a word—of getting people to put their plans down on a piece of paper or on a board in the control center where they were 100 percent visible to all of management. Then these plans were followed up on a regular recurring type basis—weekly and daily—where we had a problem. I personally feel that the fact that these guys were forced to take a pen in hand and lay out this plan and think it through logically and study it themselves and review it before they even presented to management really made them do a better job than if, you know, the management just said, “Joe, I want you to do this,” and he says, “Okay,” and went out and thought about it, said, “Well, I believe I'll do it like this and such,” and sort of kept it in his mind and to himself really. In other words, if his plan did not come to fruition or if it was delayed, the schedule was impacted, if he had a cost overrun, there was a big board in the control center that had his plan there, everything he intended to do to execute that plan—times and his name is up there in a big black letters in the right hand corner—to be shown to everybody in the world with a bunch of red marks here to indicate either that he performed well or that he did not perform well. I know just from human nature in my job in here that I would actually say that when we were in the height of that kind of a discipline, I feel that I personally did a better job because now I say, “I'm too rushed. I don't have time to do this. How about Mack? You're going looking at that and Howard this.” I don't really force them to put it down, and I don't follow up as closely. I feel sure that it was that kind of a forcing function that just created an environment that made the manager of each individual system or stage or subsystem or whatever do a little better job in that he sat down and logically thought through everything he had to do to complete that assignment, and then he followed up on it because he knew somebody else was going to be tracking each detail. [00:07:07] RB: So there's the program element plans were very important? [00:07:11] SJ: Very important. I remember, Roger, most of our managers seem to say, “You guys”—talking about the program control people and the Saturn manager—”are getting too much in my britches”—you know?—”I'm responsible for this so let me do it. If I need your help, I'll let you know or if I have a problem, I'll tell you about it.” By and large we found out when these guys had problems they would not tell the managers about their problems in time to get his help to resolve it. They would keep thinking, “I can do it. I can do it.” As time went by, “I can do it.” Bingo the delivery date was there. They were six weeks late. “Gee, chief, I thought I could do it.” They were just reluctant to say, “Hey, I'm slipping. I've got a problem.” [00:07:58] SJ: These systems we had forced these things out. The first indication of a slip was slipped upstairs or at least in the program control office for us to look at and decide whether it was worthy of forcing up to managers attention or not. Doing program reviews—I give you an example—when we had PERT on scheduling, Sam Yarkin was the manager of the S-II program office. We had a very elaborate PERT system going, and I'd stand in there and tell Dr. Rudolph that Sam Yarkin is going to be late delivering the S-II stages by sixteen weeks or whatever the time was. Yarkin would stand up and beat the table, and he'd say, “That's a lie! I'm not going to be late. I'm going to get it there on time,” you know? I would say, “Well, Colonel, how do you explain this slip and this behind delivery and this…What are you doing about it? I don't see it.” He’d say, “Dadgummit, that's not your problem! That's my responsibility,” you know? I would say, “Fine, but I say you're going to be late,” and ninety-nine percent of the instances the shots we called were correct. The guy was late. I'm not saying that because we were that better of a person individually or that more intelligent. I think it was the system, Roger, that we had that… [00:09:11] RB: Where did you get your information? Was it through PERT by way of the resident manager's office or how did you know that Yarkin was going to be late? [00:09:18] SJ: Okay. In that particular example, we established a system whereby the North American people—who were doing the machining, who were doing the fabrication, who were making the mods, and who were doing the checks of the subsystems, and all—would fill out cards: “Yeah, this component is due today. I'm going to get it. It's going to take me so many weeks to fabricate it.” You put that card in. The next guy would say, “It's going to take me so many weeks to install it.” And the next guy. These were low level guys—these were working men at that level—not middle level supervisors. They fill in all these cards, and it would run them through the system, and we'd get the computer printout [that the PERT would prepare?]. The PERT system in this case, just for schedules now—I'm not talking dollars at the moment—and those cards would come in, and the time would add up to be sixteen weeks greater than what the schedule called for. We felt that those people knew their job better than anybody else, and they were giving us good information, and that's the way it turned out. Now it…I probably shouldn't use names in this thing but really… [00:10:33] RB: No, we can finesse that as necessary. Go ahead. [00:10:36] SJ: I wouldn't want this to get in public print anything…But finally, it turned out that we were calling the shots to a much more precise and exact degree than the contractor’s management was. In cases, it came to be that the contractor’s management when we kept saying, “You're going to be late. You're not going to meet this delivery,” and they’d say, “Oh baloney! We have management [prerogative?]. We'll put more overtime on that. We'll expand more resources. We will meet it.” Then the fact was that they didn't meet it. It got to the point where they would instead of giving us the raw data from the PERT printout, they would have a midnight run for the contractor management to review. They would go back in then and direct the people down the line to gimmick the time cards and change them and make another run that they would send to the government. [00:11:25] RB: How did you find that out? [00:11:28] SJ: Because they got to be where the system was coming back in saying we're going to meet this date everything stacks up, and then they just didn't meet it. They missed it, see? So we went back, went in for a detailed audit, and we found out that the contractors had started gimmicking in the system. [00:11:49] RB: Well, I didn’t really realize how PERT [accepted?] an overall critical path method and so on, how it really works on the very basic level of the shop floor, and that those guys working with a valve or whatever had to do that. [00:12:03] SJ: That's right. That's where their time estimates came from. [00:12:10] RB: Did the resident manager have much of an input at that point? That was really flowing directly to your program. [00:12:16] SJ: That was directly to us. Resident management, of course, he was there on the site, but he didn't see the printouts until we did. He had the same visibility we did. He might have had a little better feel or opinion. I think most of the time his opinion would bear out what our system did: “Yeah, I just been walking around on the floor, and I just don't see them making that on time.” You know, just like your house when they contracted finish it in ninety days, and the time is two weeks away, and you walk in, and sheet rock’s not up on the walls inside, the floors aren't finished. You know all this slow, slow stuff. You know good and well they aren't going to make it, but the contractor will say, “Oh, we’re probably going to be pretty close. You know we're going to get there. Don’t sweat it.” It was real interesting. [00:13:00] RB: The S-II became the lead or pacing item about ‘64, ‘65. [00:12:52] SJ: Yes, it did. That's right, and that's why I use it as an example. At the time it was the pacing item on the program. It was the tent pole as we called it for a long time. The umbrella, everything else was under it. [00:13:18] RB: Why were they having so much [sic] problem with that? [00:13:23] SJ: I think it was really an advancement in the state of the art. It was the hydrogen technology plus the thirty-three foot diameter bulkheads. It was just a little tougher problem, and the engineers, you know, thought they could handle it, saying, “Well, we've done it on a IVB stage, we can do it on an S-II.” The IVB stage is, you know, like twenty-two feet in diameter and the S-II is thirty-three. It was just I think an advancement in the state of the art that they just had a lot of problems they had to work out. [00:13:54] RB: That’s what strikes me so often in the Saturn program, you know, you start out with the technology sort of in hand you say, “Well, we'll just make it bigger.” The F-1 is just a bigger H-1 engine for example. But that operating creates magnitudes of problems on a scale…Just a different set of problems. They just need [to have the time?]. [00:14:12] SJ: That’s right. There is an interesting thing too that I wish you would ask Edna to see if she can locate for you. In some of these management reviews even unknown to Dr. Rudolph, I presented really a cartoon characterization on the status of the program at times, which was a surprise to the manager as well as the stage people there. I used this as a technique to sort of highlight things if you will and really get the attention out. We had one, at least one where I can remember where we portrayed Dr. Rudolph laying on an operating table in the middle of a huge racetrack. The racetrack portrayed each one of our stages—S-IC, S-II, IU, S-IVB, LVGSE—as a racehorse, and whether he was on schedule or not or behind schedule was indicated by the position of the horse during the race. The horse was marked on the side of his saddlebag S-II, and he was galloping along way late. Bill Sneed was prodding him with a pitchfork and running along with a bucket of water, which was designated with a dollar sign, trying to beef up the horse and pour all his resources in and prod him. The S-IC stage at that time was ahead of schedule, so we portrayed them way out in front. At the same time the whole program was slipping, so here was the Washington people—General Phillips I believe at the time—down moving the finish line almost, you know, downstream. Then Dr. Rudolph was laying on the table flat on his back because of the S-II. We were trying to get assistance from the S&E labs, but there were other programs that they were diverting their resources to instead of helping Rudolph solve the S-II technical problem. The S&E was portrayed as a bottle of glucose or something coming in, but yet somebody had tied the thing off down there and diverted it over to another program who was portrayed on another operating table. You know, they were doing [good?] before Rudolph was told to stick it up [inaudible]. I wish you could find that and look at it, okay? [00:16:31] RB: Yeah, that brings up an interesting problem in terms of the relationship between IO and the R&DO operation. IO apparently didn't really have that much muscle when they needed it sometimes. I guess that’s [inaudible]. [00:16:44] SJ: That's correct. The organization really looked good, but to tell you the truth about it, the labs were Von Braun's baby. He liked the research and development end, and they just sort of went off on their own. In other words, they did not have to directly respond to the Industrial Operations. [00:17:03] RB: Technically they were supposed to do that. [00:17:05] SJ: Technically they were supposed to do that. [00:17:07] RB: I got the impression technically IO kind of had, you know, the muscle over them. [00:17:11] SJ: Supposed to have been that way, but in effect it really didn't work. Their muscle was limited, I think, to the amount of influence that they were able to exert. They really didn't have that much strong organizational authority behind them for reaching the S&E and for resources when they needed it. [00:17:32] RB: So even for the matrix management concept, this is one point where it didn't really come through in the way that you hoped it would. [00:17:40] SJ: Well, it didn't, and it did. It didn't from an overall standpoint, from higher center management. But it did from a detail level where you had a guy down in the lab identified on the matrix as the responsibility for a particular black box in a subsystem sort of thing. You could call that guy who was working with one of our guys at the contractor, and that guy seemed to feel enough responsibility and had enough interest in getting to the moon, so to be in it. He put forth a good effort. [00:18:16] RB: The problem was he lacked the support that he really required to do the job. [00:18:19] SJ: That's right. The guy I'm talking about, in S&E now. [00:18:22] RB: Yeah, okay. Down in the RS…yeah. [00:18:24] SJ: But he sort of went ahead and did everything humanly possible on his own. It happened more from the individual involvement and standpoint than it did really from the management organizational thing really working. [00:18:41] RB: Well, how did you bring the S2 problem around then? [00:18:48] SJ: Roger, I have to look back and refresh my memory. I think it was more of a standpoint of just the program slipping. It just slipped out of the launch dates and all to the point that S-II finally fell in line. [00:19:04] RB: Somewhere, I have a comment by Rudolph, and he just took money out of the big pot and put it into the S-II program. Do you know how did he do that? What were his ways of accomplishing that? [00:19:17] SJ: Well, there was also a lot of that because we in program control had the flexibility. In other words, we were given dollars for the Apollo or the Saturn launch vehicle program. [00:19:32] RB: A big pot. [00:19:34] SJ: A big pot. Now we prorated those dollars out between the stages—S-IC, II, IVB, S-IVB, IU, LVGSE—as we saw fit. Therefore, to go back to the cartoon I mentioned a while ago, at that point in time when the S-II [sic] was so far ahead, we de-obligated [sic] funds. We took money back from that pot, from that contractor, and dumped it into S-II to pay for overtime, for additional technical help, and other things to try to pull them along. So we had that flexibility. [00:20:04] RB: So obviously it would hurt, to say, maybe the S-IVB schedule, but they were ahead anyhow. It didn't hurt them if they maybe slipped a little bit because they didn't have the money to do the program. You wanted to get the S-II [inaudible]. [00:20:13] SJ: That's correct. We were responsible for conducting a continuous series of trade-offs between schedule and resources along those lines to try to bring the tail man up. If the other guys, one guy was running ahead to throttle him back and take resources away and put it in where we saw it was needed. [00:20:34] RB: Now did you have anything to do with getting Bob Greer in at S&ID out at North American? Was that their decision to bring him in? He became sort of the S-II czar in at least his ideas. [00:20:48] SJ: Yeah, I agree with your view on the thing, but I don't really know. I don't think it's a Rudolph level. Well, maybe I shouldn't say…I don't really know how much we here had to do with getting Bob Greer in. [00:21:Well, the S-II problem involved headquarters. Miller was involved in it. Brainerd Holmes was at that time. No, he was out by that time. [00:21:11] SJ: Brainerd Holmes was out, and Miller was there. [00:21:14] RB: But Miller and Phillips… were involved in it. [00:21:17] SJ: Sam Phillips. I think it was essentially at that level. They just decided…You know, it looked for a while there like pretty black like North American could shuttle the whole darn program almost. So they just took those kind of steps. [00:21:33] RB: I came across a comment once that—and I think it was Freitag who made it—that Marshall's capability here created maybe something of a problem in that where North American, for example, had contracts with both Houston and with Marshall that they might be inclined to put their best people in the Houston stand. Because if there were problems, maybe they could count on Marshall's laboratory capability to help them out. [00:22:07] SJ: I think that's a valid statement. [00:22:11] RB: This is kind of tangential…Time and time again though the Marshall laboratory capability comes up as a very significant aspect of the Saturn program and Marshall's management capability. [00:22:22] SJ: I think there was a technical depth there that bailed this program out many times. For instance, they would take a Tiger Team or some kind of a team out and solve certain problems that the contractors planned. [00:22:36] RB: Okay, now that's one thing I wanted to ask you about, these Tiger Teams. Could you elaborate on that a little bit? [00:22:42] SJ: Well, I... [00:22:43] RB: It's just kind of informal…It never appears in any of the formal documentation, [I think?]. [00:22:50] SJ: No, it's just...It was just a fact that there was a problem, there was a job to be done, and it didn't seem at the time like the contractor was resolving the problem or didn't have the capability or something. Marshall just had an in-depth technical capability in the labs that was fantastic. [00:23:13] RB: There was an MTF, they lost the S-IIS stage, then they lost the S-IIT stage down there. They finally brought in the S-II-1 stage for the static and qualification testing. As I recall, Marshall sent a bunch of people down there to make sure that the system's safety was okay and [range?] safety was okay. Now that probably would have been a Tiger Team? [00:23:34] SJ: Yes, that's the kind of a team we're talking about. [00:23:37] RB: And they had another group then that went out… [00:23:39] SJ: To the contractor's plants at times. [00:23:42] RB: Another Tiger Team? [00:23:42] SJ: Yeah, different teams made up of different skills depending on what the problem was. [00:23:47] RB: Were the Tiger Teams mostly in relationship to the S-II then or were there other cases where that kind of loose arrangement was applied? [00:23:54] SJ: No, we had other cases, it was in…I believe we had a case in the S-IVB. There were several instances where this technique was applied. [00:24:02] RB: This comes over the overall rubric too of penetration of the contractor then? [00:24:08] SJ: That's right. [00:24:10] RB: That's another thing that really came through to me. It's kind of from the government viewpoint, I suppose, it's kind of a beautiful approach, but as Rees pointed out, the contractors often got a little restive about this thing. [00:24:22] SJ: Yes, they did. [both laugh] But I'm firmly convinced that it, you know, got the job done on time really. I'm not saying we wouldn't have gotten it done without those things, but it certainly all seemed to help it fall in place. [00:24:39] RB: Well, you had a Tiger team down at MTF working on the problem, you would have had a similar group here—a working group? [00:24:45] SJ: Yes. [00:24:46] RB: Cooperating, working on internal events. So that's the difference between the two. [00:24:50] SJ: That's correct. [00:24:54] RB: Anything more you want to say about that? [00:24:58] SJ: I don't really [inaudible]... [00:25:00] RB: As you were talking, one of the things that Rudolph seemed to bring out is that the staff people, like yourself and others, were really on a managerial par with the project managers. This was a different arrangement to a normal management relationship. [00:25:14] SJ: Yes, that's right. If I can illustrate the point, Roger, if you would just look at the vehicle like it's stacked up—look at the S-IC stage, the S-II stage, the IVB, and the IU—each stage manager was given what we would call a horizontal responsibility this way for his particular stage, his particular slice of the thing. But the staff guy in the quality and reliability and test area—Howard Burns at the time—and systems engineering—Lucian Bell—these kind of guys had a more of, I guess you'd say, a vertical responsibility that extended from the IU down right through the engines. This combination seems to work extremely well, for instance, as far as saving resources. There's really no point to—unless there was a technical reason for it—to test in one component in the S-IC stage to a greater depth than you would up in the IU somewhere, to take one of their structures, you know, knowing the characteristics of the vehicle, and the problems they had with pogo and things like this. This was a little, I guess, different or new technique to me, and it seemed to work real well. [00:26:35] RB: Now this was different in terms of what you would find in management outside? [00:26:40] SJ: Yes, I think so. [00:26:43] RB: Can you see any other striking differences between the Marshall kind of concept and outside management, for example? This being one of them, the staff and lines managed to have equal responsibility. [00:27:01] SJ: Oh, not that really, I guess in the intervening years I really sort of become more unfamiliar with how private industry is working now. [00:27:13] RB: Let me ask something else, too, the thing that fascinates me about the staff and people here: the mirror image relationship with the same boxes in Miller's office in Washington. [00:27:24] SJ: That's right. [00:27:26] RB: Now—the so-called G.E.M. boxes—did Miller institute this thing in the 1963 reorganization? How did these G.E.M. boxes really come out? Is that Rudolph's thing or how did that cook out? [00:27:38] SJ: Oh, I think that really was probably the higher level inductor. I don't really think that came about as a combination effort from headquarters and the center, really. I'm not sure it was unique to either one. I think it was just a “Hey, this looks like a good way to work it. Let's try it and see what happens” sort of a thing. I'm not sure I could say there was any one individual responsible for that, but there may have been somebody like that. I'm just not aware of that. [00:28:07] RB: The phrase that keeps coming across me was a G.E.M boxes thing, wondering was that…Just a natural relationship to see as a headquarters in the fact that there was this... [tape cuts out] [00:28:23] RB: Okay. [00:28:25] SJ: One of the good features about that mirror image concept was the fact that here in this program control office as far as the funding and schedules went, contractual applications, and these sort of things, is that we could deal directly with our counterpart office in Washington. In other words, I was free to get on the telephone and call the Apollo program control chief in Washington and work problems with him without going through Dr. Rudolph and whoever was chief of industrial organizations at that time like O'Connor or Lee James and then going through Rees, center management and those sort of things. See, we could work the problems directly at a fairly low level and say, “Hey, this is a solution.” Now, of course, there were certain major type things that had to come up through those channels and certain changes in direction, program directives and things, but essentially you could work the guts of the problem at this detail. [00:29:24] RB: Okay, we kind of discussed the relationship you had from your level down. Now, what kind of problems do you work out between yourself and headquarters, for example, going on? [00:29:35] SJ: Oh, I guess it would be hard for us to say. Most of those problems were…Well, really, I guess…I don't think launch vehicles, Roger, was ever the pacing problem in the Apollo program itself. It was always a spacecraft or something else. I'm really hard pressed to think of a pretty high level type problem that we here resolved with headquarters. There were certain scheduled deliveries and reallocation of resources things, but these were more on a day-to-day program. As I remember most of the time, launch vehicle-wise, we were doing our program for less than the amount of resources that had been planned, and essentially we ended up bailing other organizations out like Houston, the spacecraft and all, by taking dollars or offering up dollars out of the launch vehicle program to be applied to their problems. [00:30:44] RB: Rudolph, once said the figure, they were turning, I think this is maybe overall Senate, but they were turning back $30 to $40 million a year. Does that mean that Marshall's management was better because of the laboratories? Or how do you…? That seems to be a pretty remarkable thing to have occurred. Just good management? [00:31:02] SJ: Roger, I would have to say that certainly a large portion of that was good management because even up until this past year, FY73, we gave about 8.8…No, this is in FY74…We see that we can give about 8.8 million bucks back, which headquarters has used to help the Skylab payload problem. Now, you know, anybody can use all of their resources. Anybody can overrun. I can overrun a program. You can. That's no management at all to me. I think anybody can overrun a program. They're just adding people and time and this, that, and the other. But it takes a pretty good manager to constantly underrun a program. It takes some good management techniques to go along with it in my opinion. I think it's more than a [“See you at the pitches”?] manager. I think, you know, this team approach, Dr. Rudolph had a lot of good people working for him, a lot of good dedicated people that really all put their shoulder to the wheel were able to accomplish this thing. You know, one thing strikes out in my mind, having worked in private industry for over ten years and working here at the government in the height of the Apollo program, I would have to say that I saw more dedicated people here in the government working on the Apollo program, trying to get a man on the moon, who worked overtime without pay, and who worked twenty-four hours solving problems, and who worked weekends making presentations to higher management to tell them where the problems were and making recommendations what to do about it than I ever saw in the private industry. I make that remark because you hear so many people say the government's just a bunch of goof-off people, you know? [00:32:47] RB: Do you think that situation is the same today or is it kind of peaked off now that the program is kind of peaking down a little bit? [00:32:54] SJ: I personally feel it's peaked off a little bit since the program is. I can't speak to the shuttle people over there, of course, I’m not in that organization, but I know in our program it's peaked out a little bit. [00:33:06] RB: Is that, too, just kind of the inevitable reaction of a maturity of a center or something like that, a maturity of a program? [00:33:14] SJ: Well, yeah, and I think it's just when you have these kinds of people on the job, and once you're over the hill, these people tend to start looking for new challenges, you know, new jobs to be done. It's going to really tax them. They don't really want to coast down home free. We find it somewhat hard to get good people like Mack and Bob Shepard and others to stay on the program. I think they'd rather get on a new program that's got problems where everything's hustling and bustling and all that. At the same time, we've got to have good people to close out the program. You can't just walk off and leave, you know, we've still got to support the remaining two Skylab launches and an ASTP launch. You've got to keep a nucleus or a cadre of people around to do that job. [00:34:04] RB: That raises an interesting…[Really not pertinent I suppose?], but one of the things that struck me talking to somebody in Washington said sometimes they didn't always figure enough money for a program. It's partly this thing that once you get the hardware, you've got to keep it in good shape, and you've got to keep the people around to make sure it stays in good shape. They hadn't really…It's obvious maybe now, but they hadn't really figured on it. You know, they think, “Okay, we’ve got the hardware ready to go.” That’s it. But there are these recurring and sustaining costs that over a long period of time that keep them going up. [00:34:34] SJ: That's right. The people are a big thing. We found, I know in the—if I can give you an example—in the F-1 engines, they have a procedure of welding these cooling tubes in the [bail?] portion of the chamber. [00:34:46] RB: Right, regenerative [inaudible]. [00:34:48] Right and they went to great lengths when they finished that to document the welding technique. They made movies of the best welder they had on the job very thoroughly. He did it exactly this way, that way. They wrote up procedures that told precisely how that guy did that job. They finished welding the last one. They laid the guy off. He went home. I don't know, eighteen months later, they had need to build another chamber, you know? So they took a guy who wasn't a new welder now. He was a certified welder, and they asked him to do this job. The guy went through the procedures. He reviewed the films. He practiced, but he couldn't do the job. He ended up having to call people back in to do that job. There are just some techniques that come through doing this job over time that seemingly you can't document. [00:35:43] RB: Okay, I heard this…Engineers thinking about something: “Will it work or will it won't work?” There's a gut feeling. It's either going to go or it’s not going to go. It's the same thing. [00:35:54] SJ: That's right. That's right. It was amazing. There they had movies, written procedures, documented, checked, checked, and rechecked. You call a new guy in and even though he's a certified welder, he just can't start and do the job. [laughs] There's just a certain technique there that…Oh, you don't know what it is. [00:36:11] RB: Okay, let me ask something about managerial techniques, especially in terms of Rudolph. Now, in some place, I think it was set up that…Well, let me ask you this. Did Rudolph have daily staff meetings or only…? [00:36:28] SJ: Rudolph had frequent staff meetings. I don't believe he had daily staff meetings. [00:36:33] RB: Somewhere in the PEP, there was something about daily meetings, but I had the impression that they weren't necessary. [00:36:42] SJ: Rudolph had weekly review type meetings and in depth, very thorough monthly reviews. I know I have stood in the control center and on my feet and presented all day just on schedules and problems. When Lee James came aboard, he asked me to set up a weekly staff meeting. We did this in a little matrix format that said the first fifteen minutes we'll cover this item, the next five minutes we'll cover these kinds of things. Then once a week, we would have a fifteen minute presentation by each stage manager or staff guy on a rotating basis. We just went around and then started all over. Whatever his most significant problem was, no matter how minor he thought it was, he had to present that to management: what the problem was, what the alternatives were, what the projection was. Some of these turned out to be quite significant. In the guy's opinion, he should never have presented to management. But once again, the system that we had established made him bring up that problem. Maybe somebody else had a tie in that they saw how relevant this was, and it could have been a program stopper, you know, or at least a delay. The thing there again was identified early enough for corrective action to be taken to resolve it so that it did not become a real problem. It was a potential problem. If you had left it up to the manager on his own—the stage manager now—most likely he would not have brought that out of his own accord until it was too late. It would have caused a schedule... [00:38:18] RB: [But was none of this kind of?] directed to make sure that it was brought out? [00:38:23] SJ: That's right. [00:38:25] RB: It puts a lot of pressure then on the individual. [00:38:27] SJ: It does. It puts a lot of pressure. [00:38:30] RB: They seemed to have responded to it. [00:38:31] SJ: They responded. They felt responsible, and they responded. [00:38:37] RB: Management has to be careful in this situation in that it's taken in the general atmosphere of “We're all in this together,” and it's not like whipping the poor guy because he [inaudible]. [00:38:46] SJ: Now that's right. Now we did have a manager or two that felt he had been whipped like that. He felt that he was being made an example of or embarrassed before other managers. That was a personal feeling and not, you know, the intent. It was more the guy's personality that became involved with the thing, and he resented it to a degree. [00:39:03] RB: That's one of the difficulties of writing this kind of a thing. You know, there are all kinds of personality aspects of this thing that’s hard to bring out. Rudolph must have been a good manager then? [00:39:15] SJ: I'd say Rudolph was a good manager. He was a dedicated manager and certainly one of the hardest working managers I've ever seen. [00:39:22] RB: The fact that he was in headquarters for something like a couple of years in the OMSF office, do you think that this was helpful to him when he came back down here and that he knew how headquarters was operating and how he managed? [00:39:36] SJ: Are you talking about Rudolph or Lee James? [00:39:38] RB: Rudolph. I was under the impression with the way he worked in the OMSF for a while from about ‘61 to ‘63. [00:39:45] SJ: You know, he could have, but that was the time when I was over in the ME lab, and I really wasn’t associated. I'm really not aware of the fact that Rudolph was at headquarters for that period. [00:39:56] RB: I'll have to check on that. [00:39:58] SJ: It could be that I'm just not aware. You could be exactly right. I'd say you should check on it though because I've never heard that. Now Lee James was at headquarters. [00:40:07] RB: Yeah. One of the things too that strikes me again as we've been talking, talking about visibility, so the program’s control centers really stands out as a real vehicle for this visibility you're talking about, provided the arena for this… [00:40:22] SJ: Yeah, it's very different. That's right. This is where it all came together, and all the problems, we made it up to see whether it could be worked in parallel or series or what, you know, popped a balloon out over here. I think it was a tremendous management too. [00:40:40] RB: But after a while, as I recall, you got to the point where you found that Curt wasn't so useful. [00:40:47] SJ: That's right. [00:40:49] RB: By that time the stages even maybe the S-II had caught up in the manufacturing. [00:40:52] SJ: In the research and development, the early phases of the program, that was tremendous too. Later on as the program gained a degree of maturity and we left the development and started into the manufacturing phase where we were cranking them out the tube that became less significant as the management too, and eventually we dropped it because we just didn't see a need for it. That was another factor in itself, Roger, is the flexibility of the system to change and update itself and adapt to the change in environment and the change in degree and maturity of the program. It wasn't that we, “Oh, you develop PERT, and now you're going to keep it until you die, until you wrap up the program.” I think the system itself helped point out to us that, “Hey, you know, this has been a good tool, but you really don't need it now, so drop it and get something else or do something differently or at least revise it.” We've had change in techniques, you know, all the way through this thing. [00:41:56] RB: Did headquarters ever interfere or was there a period when headquarters interfered too much in terms of technical things? Or were the program offices pretty much left to their own? [00:42:07] SJ: I think there was a time when headquarters tried to interfere too much, and I think they wised up quick enough to back off so that they really didn't interfere. You know what I mean? [00:42:18] RB: Was that during the Holmes and [inaudible] and Joe Shea? [00:42:20] SJ: Yeah, I'd say that was back in the early days of the program. [00:42:27] RB: And the 1963 reorganization kind of changed the community the [inaudible] cycle. Would you think that that was…Well, Holmes left then, but it was naturally a change in personality. [00:42:38] SJ: Yeah, it was a change in personality, you know, new management. [00:42:41] RB: But is it correct to assume then that Miller was aware of this problem and maybe eased off on the technical interference from the headquarters level? [00:42:48] SJ: Miller eased off but real slowly because he was an in-depth technical guy himself, and he enjoyed probing into those things, see? I think he did ease up a little, but I'd say it really wasn't until after his administration that headquarters really said, “Hey, let's get out of that and let's leave that up to the guys that know what they're doing now.” Everybody seems to have a tendency to want to be an engineer. [00:43:13] RB: They'd like to get their hands dirty. [00:43:15] SJ: Yeah, and solve a problem. But as far as the program control center and the system we had here, headquarters adapted the Marshall system in effect. [00:43:24] RB: Is that right? [00:43:26] SJ: Oh, yeah. They did not have an original control center. They did not use all the procedures and techniques. They came down and viewed ours in the Sam Phillips era and then went back and established one of their own. Now, Sam had been used to Air Force control centers and techniques somewhat of a similar nature, and he knew how they worked. [00:43:45] RB: Well, how is your control center different, for example, from the Air Force concept and technique? [00:43:53] SJ: I'm not sure because I don't know that much about it. I know we looked at a lot of the Air Force techniques and things and revised or adapted some of them to suit ourselves. We didn't reinvent the wheel in each case. [00:44:02] RB: I have the feeling that the control center here was much more, I hesitate to use the word elaborate, but it was much more comprehensive maybe in terms of the data presented, in terms of pinpointing individuals, and in terms of the matrix management that was part of that control center. [00:44:28] SJ: It was much more comprehensive than anything used hithertofore [sic], I'll say that. [00:44:33] RB: Would you say that this is the model for the control centers that developed at the Cape, for example? [00:44:38] SJ: Definitely. [00:44:39] RB: And at Houston? [00:44:40] SJ: Definitely. [00:44:43] RB: But the control center at MTF came in at about the same time? [00:44:48] SJ: Yeah, they came up with an adaption originally of what they called a think tank concept down there that sort of developed along about the same time as I recall. [00:45:05] RB: In ‘65 when they finally got started here, isn’t that right? [00:45:08] SJ: Yeah, about ‘65 really. But we had done a lot of work on it for a couple of years before in writing these procedures, but we just didn't get them implemented formally, Roger. I really think this control center right here on the third floor set the precedent for NASA. I think as early as the days of Mr. Webb the first administrator. If you look up some of his early comments, he made a review down here, and he used to send people down here to review this center and what we’re doing here. He had very complimentary comments about the control center and its operations in fact early in his days. [tape ends] Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Identifier An unambiguous reference to the resource within a given context ohc_stnv_000024_A Title A name given to the resource Johnston, Sid Format The file format, physical medium, or dimensions of the resource .MP4 Type The nature or genre of the resource Interviews Audio Source A related resource from which the described resource is derived University of Alabama in Huntsville Archives and Special Collections, Huntsville, Alabama Language A language of the resource en Rights Information about rights held in and over the resource This material may be protected under U. S. Copyright Law (Title 17, U.S. Code) which governs the making of photocopies or reproductions of copyrighted materials. You may use the digitized material for private study, scholarship, or research. Though the University of Alabama in Huntsville Archives and Special Collections has physical ownership of the material in its collections, in some cases we may not own the copyright to the material. It is the patron's obligation to determine and satisfy copyright restrictions when publishing or otherwise distributing materials found in our collections.