Interviewee: General Sam Phillips

Interviewer: Martin Collins

Date: September 28, 1989

Location: National Air and Space Museum

TAPE 1, SIDE 1

MR. COLLINS: Last time we discussed Minuteman at great length and just initiated our discussion of NASA [National Aeronautics and Space Administration], but I understand you want to make one additional comment about Minuteman before we proceed with that.

GENERAL PHILLIPS: Yes. One thing that I didn't mention that I think was very significant in the history of Minuteman, and for that matter of the whole intercontinental ballistic missile [ICBM] program, was the introduction of site activation task forces. My recollection is that, some time in 1961, the magnitude of the job of creating the field sites for all three of the ballistic missiles, the Atlas, Titan, and Minuteman, but particularly Minuteman, was recognized, and we did talk some last time about the magnitude of that job. And that concern over the tremendous scope of the site activation job was I think a significant factor in a reorganization of the Ballistic Missile Division [BMD] to divide the missile organization from the space organization. My recollection is, that occurred in 1961, although it could have been over into '62. It was some time in that period. And at that point, AFBMD was divided into the Ballistic Systems Division, which was then given to General Tom Gerrity to command, and the Space Systems Division, which was given to Ozzie Ritland, who up to that point had been the commander of the combined Air Force Ballistic Missile Division.

    Early in that period, Tom Gerrity, who had come more from the logistics materiel side of the Air Force, decided to move the Ballistic Systems Division from Inglewood out to Norden Air Force Base at San Bernardino. At least from my perspective, he was the one who came up with the concept of establishing site activation task forces, to be located at each of the many sites which were to be built for all three of the missile systems, and he was given high priority for picking and assigning people, and he picked a group of very senior colonels, and as I recall, they were all initially senior colonels, to be site activation task force commanders at each of those locations. And they all in an organizational sense reported to Tom Gerrity.

    I remember particularly the site activation task force commander at Malmstrom Air Force Base, which was the site of the first Minuteman wing, who was Harry Goldsworthy, who in later years became a lieutenant general and retired as a deputy chief of staff of the Air Force in the Pentagon. But during the Minuteman site activation years, he was the on-site commander of all the activities, and, I as program director, working of course with my own organization and with our contractors, worked in conjunction with Harry Goldsworthy. Harry had a small but very good staff of people who kept very close track of the activities of all the contractors, to plan and eventually to execute the tremendously large job of construction and installation of the equipment and the ultimate activation of those sites and turning them over to SAC [Strategic Air Command]. So that concept, I think, worked exceedingly well, and it's certainly a significant step in the whole process of managing the acquisition of those major intercontinental ballistic missile systems, and as I said, particularly the Minuteman, because of the tremendous scope of the Minuteman program, which ultimately involved the creation of a thousand silos and associated launch control centers and support facilities.

COLLINS: Does this imply that when the Minuteman program was initially conceived, that the complexity and scale of the site activation task was not fully appreciated?

PHILLIPS: Well, I don't know that it implies it wasn't fully appreciated. I suppose in a sense that's true. Because you know, the closer you get to a job of that kind, as you plan it in detail, the full scope of it becomes more apparent. I think it was a very logical step to take in the evolution of an organization to manage such a tremendous undertaking.

COLLINS: But the key point is that a specific organizational mechanism was established to handle this particular large job.

PHILLIPS: Yes. Yes, that's true, and as I said, I think it worked extremely well. Tom Gerrity, who in those years was a major general but who later was a four-star general, was commander of Air Force Logistics Command [AFLC], and he was as a matter of fact commander of AFLC when he died of a heart attack many years ago. He gets a lot of credit, I think, for the top- level management of the overall organization that created those ballistic missiles.

COLLINS: Okay. Now, the site activation task forces did not report or work through you. Your organization and the site task forces were complementing each other? Both reported to Gerrity?

PHILLIPS: They both reported to Gerrity, so in an official line sense they were parallel organizationally. In other words, Harry Goldsworthy reported to Gerrity as did I. In an actual working sense, things work in a way where the program organization, which I headed, worked with and through Harry Goldsworthy and his organization. When things worked smoothly, as they usually did, his organization was almost transparent. I guess it's a little bit hard to describe. I suppose there are elements of what industry and for that matter the government tends to call a "matrix organization," where program offices and program managers are organizationally placed in parallel with functional organizations and laboratories who have jobs to do for the program, so in a sense they both report to the same boss, but program managers for all practical purposes in the "functional organizations," which you can make some parallels of the site activation task force, work essentially for the program organization. Although there's always that independent channel to the same boss in case there's a dispute that needs mediating, which, as I said, occurs only rarely.

COLLINS: Right. Was it initially thought that the site activation activity would fall under the program manager's domain?

PHILLIPS: Yes, and as a matter of fact, from day one in the Minuteman Program Office, I had a branch of my program office which was responsible for the site activation job.

COLLINS: So in a sense then, it was determined by you and others that this task was really just too big to fit under your umbrella and needed some kind of separate status?

PHILLIPS: Well, I'm sure that those in upper echelons of command would have agreed with that statement. Admitting some parochialism, I guess, on my own part, I think probably a better perspective is to recognize that it was recognized that the scope of the job on the site, Malmstrom for example, was so large that it required an on-site presence, meaning an organization with fairly senior and competent people who had access to high places for decisions or action. In other words, it was a recognition that a significant on-site presence was required, and as I said, but again admitting some parochialism, I really worked with Harry Goldsworthy in a way in which I always looked at him as working for me but having that independent channel if he needed it to our mutual boss. And that's essentially the way it worked.

COLLINS: Okay. I was just trying to get at what the significance of it was to you, of establishing these site activation task forces. I guess the key point is that you needed to apply a certain amount of talent in a particular location to get a job done.

PHILLIPS: Yes. And that would probably have occurred whether the site activation task force commander reported to me fully organizationally or to our mutual boss. In other words, I think, just looking back on it, that the need for an on-site organization of that type was sufficiently evident that I would have created it had not Tom Gerrity taken the initiative to create it, setting it up in a command structure which looked like it was parallel to the program offices.

COLLINS: Do you want to move back to NASA then?

PHILLIPS: Sure.

COLLINS: Last time, we just talked about the circumstances which brought you to NASA in your position as first deputy director and then director of the Apollo program. What were your initial responsibilities when you came there? What things were you asked to tackle? Perhaps another way to put it is, what did you find when you came there?

PHILLIPS: Well, my concept of my assignment, from the beginning, was to serve as the director of the program in the same perspective that I had served as the director of the Minuteman program. As we have already discussed, my initial assignment, which I think was officially on the 1st of January of 1964, was as the deputy program director, and in that period, George Mueller, who officially was the associate administrator for Manned Space Flight, had his name in the box as program director, "acting," if you will. His discussions with me were that--I've forgotten exactly how those discussions went, but my understanding was that as soon as things were evidently working well, that it was his intent to remove his name and to make me the program director, which did actually occur some time in the late summer or early fall of '64. So with that understanding between me and George Mueller, the way I tackled the job from day one was as though I were the program director. So therefore, you know, my first need was to learn enough about the program as it was constituted to that point, to gain knowledge, in other words, of the job to be done, the system which to that point had been conceived to perform the mission, and the organization that existed at that point to carry it out. So one of my first priorities obviously then was to learn a lot, and to get to know a lot of people. It was apparent very, very quickly that creating the organization, in a total sense, was one of the high priorities.

    The basic outlines of it had already been established by George Mueller. He had already introduced to NASA the concept of the program structure, with program offices reporting to him, and at that point there was one for Gemini, one for Apollo, and one for advanced developments, and of the program offices in NASA Headquarters then working with what I tended to call the project offices at each of the centers, who in turn had the contracts. So if you will, it was a program structure involving Headquarters and centers and contractors, built into or overlaid on the line structure of Headquarters and centers.

    So he'd introduced that concept, but the, if you will, final design of the organization and the obtaining of a significant number of people to flesh it out was the top priority. That, as I said, I recognized as one of the early requirements, and it's what led me very early, as we discussed last time, to go back to the Air Force and tell them I needed help, which resulted in the assignment of a significant number of Air Force people with system management experience. One of my early priorities in connection with creating that organization, or building it, was to get people, get good people, starting with the top jobs. So I went to industry as well as to the Air Force, and one of my early acquisitions to head my program planning and control organization, was a man named Jerry Kubat, who came from Boeing and brought with him a young man named Jim Skaggs. As I said, Jerry, I put in charge of the program planning and control organization.

COLLINS: Let me ask, for both the Air Force people and industry people that you brought in, where did you put them? Where were the greatest needs in the NASA organization for people with experience in program management?

PHILLIPS: First, in my own organization here in Washington, to fill out the key positions in the program office here. That was what I felt was the first priority. The second priority need was at Marshall. [Wernher] von Braun, under the earlier actions of George Mueller to direct the creation of this program organization superimposed on the center, had led von Braun to restructure Marshall into basically two entities. One was what he called industrial operations, and that was the program offices of Marshall, and the other was what he called, I think, technical operations, and that was headed by one of his associates.

    The most urgent need was to find somebody for von Braun to head the industrial operations organization, and that wound up being one of the Air Force officers that I obtained, Ed O'Connor, who as I recall at that point was either a senior colonel or a brigadier general, and who in later years retired from the Air Force as a three-star general. So Ed O'Connor headed the so-called industrial operations, reporting to Wernher, and under Ed were the Marshall program offices for the major engines, which was headed by the civilian Lee Beaulieu, who had been at Marshall for some time. The Saturn I-B program office, which was headed by Lee James, who had originally been an Army officer but who had come into Marshall as it was moved out of the Army, and Lee stayed with Marshall. Arthur Rudolph, who headed the Saturn V program office, was one of Wernher's long-time associates. So that was basically the industrial operations organization.

    Wernher had highly competent technical people running his programs, like Rudolph, like Lee James, and Lee Beaulieu. All of them had had experience in managing highly technical programs, so they were quite competent. They needed in their organizations some people with experience in program planning and control. These were the most urgent needs. I don't remember names particularly but there were several of the Air Force people who were assigned then to the project offices there at Marshall, with program planning and control being one of the priority needs.

    I think probably the third priority, the way I think back on it, was down at Cape Kennedy. Rocco Petrone headed that activity initially back in the early sixties. I think his title was project manager for Apollo. In my program organization diagrams or charts, he appeared as heading the launch systems project office in Apollo. There too, he needed people to fill out his organization, and priority needs were in program planning and control. Incidentally, I should add that priority needs in all the centers as well as in Washington were in program planning and control, and in an element of system engineering which back in those years was still fairly new, which typically was called configuration management. So the priority assignment of people were in program planning and control and in configuration management kinds of assignments.

COLLINS: Just to be clear, why don't you give me a kind of a definition and sense of what falls under program planning control and configuration control.

PHILLIPS: Okay. Thinking about the job that a program director or program manager of a large complex program has, I, today as well as in prior years, have thought that I needed to have three significant elements of help. And you can think of it conceptually as having, if you will, three deputies or three directors reporting to me in the program offices. One was for program planning and control, the second was for system engineering, which I'll elaborate on in a minute, and a third would be for operations. Incidentally, those three deputies, if you want to think of them that way, have to work extensively together, because all aspects of all their jobs require a great deal of integration with other elements, and a great deal of iteration. And so those three deputies and the people that serve them need to work extensively together, as well as with the program director himself, who of course in many areas has to serve as the initiator and director and coordinator and so on.

    Well, program planning and control, then, is responsible for creating the documents, if you want to think of it that way, that define the plan to execute the program, to get it done. So it's a complete plan of action, and of course that has to start with a clear definition of the job to be done or the objective of the whole thing, which, in an organizational sense, I think, I tend to look at the system engineering organization as being responsible for preparing, which starts with the performance and design requirements. And of course in a program like Apollo, even the operations people should become involved early, because ultimately the conduct of an operation, a mission, is the execution of the program in the end. So even at the very beginning there's an iteration. I think a way to think about it is, the system engineering organization is responsible for creating initially, and then over time iterating and perfecting, the technical requirements and the performance and design requirements of the operations people responsible for laying out in progressively greater detail the plan of operation, both of which have to become the leading parts of a program plan. This is what needs to be done; now here's how we're going to do it. And in the program plan for Apollo, an appropriate portion of it has to be the organization that is going to carry it out and how that's going to work, and so a part of that of course is, I'll call it, the clear statement of, assignment of, responsibilities, and at the appropriate place the delegation or assignment or definition of authorities, at what levels what authorities exist. So an overall program plan, which has many elements--as I recall, there were something like seventeen or so different significant chapters that had to be prepared in the Apollo program plan, which dealt with things all the way down through the plan for logistics. Another major element of a program planning and control organization's job is to create the structure and the procedures and the processes by which there will be tracking or control of the progress and so on, which can be looked on in a broad title as reporting and review, that whole process which needs to be sufficiently structured and defined. Of course a significant part of the whole program plan has to be the whole financial plan, and that in turn typically leads to having to have sufficient staff to prepare budgets and Congressional statements, and the many things that have to be done to work that whole process of budgeting and financial reporting. There has to be created and defined just how the multitudinous scheduling is going to get done, interrelated and integrated and reported, so there has to be a scheduling system tied in to all this.

    That's a kind of a broad outline. There are other elements in the program planning and control organization. Now in the system engineering, the way I tend to think about it, I've mentioned already the requirements definition piece of the job, and that in itself is pretty substantial. Another significant piece of it is to prescribe the system by which technical specifications and design requirements are going to get handled in the program. And let me say, parenthetically, that when I came into Apollo, we didn't really have a specification system. There obviously were technical specifications of various types that had been created and used in setting up the contracts, but in terms of integrated, interrelated specification tree and set of requirements for how specs were to be prepared and used, and ultimately, as always is required in development, modified, we had to create that. So there was a spec program, and the specification program really becomes the leading part of an overall configuration management system. Configuration management, as a broad title, is one of the major pieces of system engineering, or ways in which system engineering is accomplished. It starts with the creation of your technical control system, which fundamentally is specifications and standards and related.

    And then another piece of it is the identification of interfaces in an organizational sense, and of the assignment of responsibility for the documentation and control of those interfaces. And those interfaces involve, first of all, technical matters, but they also involve procedural matters. As I say, a system engineering organization is responsible for identifying the interfaces and being sure that the responsibility is assigned, and then ultimately for tracking to insure that they are adequately accomplished. Parenthetically I might add that that interface documentation and control function in Apollo was a fairly sizeable job, and it led to the creation of a group of panels that had members, each had a chairman, and the assignment of chairmanship varied around the organization depending on who the lead for that interface was. Some of them were assigned to people in one or another of the centers, and a small number of them were assigned to be chaired by people in my program office. And that panel structure, the membership of the panels involved, they were essentially technical. They included people from centers, each center involved in a particular interface, and members from the contractors who were involved in those particular interfaces. Now, as I say, the panels were the mechanism for carrying out the interface definition and control job, and had over the top of this group of panels, I've forgotten the number, but there must have been twenty or more panels. We established a panel review board which I chaired. So that was all part of the implementation, if you will, of the interface identification and control process.

    Another major function in system engineering is to establish the process of carrying out the design and on into production and operation. It's to prescribe the series of major checkpoints that are going to occur. In the Apollo years, what we established was the requirement for a requirements review, a preliminary design review [PDR], a critical design review [CDR] which was a final design review, an acceptance review--meaning when the hardware or software was finished, accepted by the government--and then a flight readiness review, which was the final action to approve a flight.

COLLINS: What level of hardware are we talking about here? Are we talking about subsystems, groups of subsystems, a completed piece of hardware?

PHILLIPS: All of those. The directive that my organization created specified what reviews were to be conducted and what level. So the way the Apollo program started to work even in '64 but then all the way through the program, and for that matter the practice is still followed generally by NASA, is to formally schedule the PDR, CDR, etc. as the major milestones of a program, and they are shown then for significant components, certainly for the important subsystems, like engines, guidance systems, etc., and for the vehicles themselves, and ultimately for the total launch system.

TAPE 1, SIDE 2

PHILLIPS: I'm still responding to your question of giving some definition to program planning and control and system engineering, talking about system engineering. Another major piece of system engineering is to prescribe, if you will, the rules that govern testing, and at the top of the program I think we tended to think of it as the master test program requirements. And it really spells out the rules, what's to be accomplished in the way of qualification, starting in most cases with piece part components, how they're to be qualified, and then progressively up the tier of assembly. And the ground rules, if you will, for test programs, to define scope and intent, and that leads pretty rapidly to defining the number of articles that are going to be used at various stages of testing. So just to think of it as a major piece of system engineering is to govern the whole test program, which in a program like Apollo is a big piece of the program.

COLLINS: Right. When you're trying to define a test program in areas where the end products are relatively new in a developmental sense, you're experimenting with new technologies, how difficult is it to prescribe a test program for something that you're really still in the process of defining?

PHILLIPS: Well, I don't think of it as difficult. It's a progressive process, starting with a set of rules, if you will, and rules can be as simple as the fact that every piece part component--this is an exaggeration--is going to be subjected to qualification tests that demonstrate sufficient margin, and that each subassembly, like engine or guidance and control system, will be demonstrated to some level of margins. And that each major system, if you want to think of it, spacecraft or launch vehicle stage subjected to--and then progressively, it becomes defined as units of hardware that have to be built and then put into test programs. And it then progressively spells out that certain test facilities have to be created, and some of them turn out to be quite major. Of course some of those are defined very early in a pretty broad conceptual sense.

    For example, in Apollo, the Marshall people defined very early the need for a major facility to test each of the stages in a complete sense, and of course because of the size of the SaturnV, that whole requirement to plan for facilities to do testing was a pretty major thing, and it involved logistics. For example, how are you going to move these very large structures and objects from wherever they're built to where they're going to be tested and where they're going to be used? Now the Saturn V first stage, as I remember, was something like thirty-three feet in diameter and what, one hundred feet long. It was tremendous and very heavy. So barge transportation was the mode of transportation that was decided, and that led to very early planning for where it was going to be built, which turned out to be in a plant on the water in New Orleans, the Michoud plant. Where it was going to be tested is a major stage, which was in a facility that was created as a test facility, in Mississippi, which we originally called the Mississippi Test Facility, which still exists today. It has a different name now. And so transportation--they were located on water. They could be transported by barge from Michoud plant in New Orleans to Mississippi and then in turn from Mississippi around to Cape Kennedy, and of course that meant we had to create barge facilities at all those locations. We're getting off of testing, but--so very early the plans for these extraordinary test facilities we had identified had led to Mississippi.

    In the case of the spacecraft, it led to the creation of a test facility and organization out at White Sands, New Mexico, for testing the engines of the spacecraft in a vacuum mode. It led to early identification of a requirement that was laid on the Air Force for capabilities to be used at Tullahoma, Tennessee, where very large propulsion testing facilities in vacuum existed, and we did a lot of testing at Tullahoma in Apollo. The early needs become also identified as contractor facilities. So quite a number of test facilities were created at industrial sites. I remember out at North American, at Downey, a major facility was created to drop test the command module, to do testing both to get data for development and then ultimately for qualification of the landing system of Apollo. In other words, its ability to withstand the impact of landing on either water or in an emergency mode on land, and to meet the requirements.

    Without trying to elaborate in all detail, I just would say that the need for substantial facilities for testing is an early need, because, in the case of Apollo, there were major facilities to be created at a number of industrial plants, at a number of government locations, and ultimately of course major test facilities to be created at Cape Kennedy for the ultimate test and checkout. And in turn then those had to be defined in detail and planned and budgeted and contracted and created. So the management of the test program is a substantial piece of system engineering. The way I tend to think of it at least, that's a major function of system engineering. At some point I want to talk about how we in some ways had a kind of a hybrid organization to manage all this, but let me stop and ask whether I've done enough to define program planning and system engineering.

COLLINS: You have. Right. Let me just say, the point of this is just to give us a base of discussion for (1) assessing the evolution of the NASA organization, and for the nature of the interactions between NASA and industry. You indicated that when George Mueller came in and later when you came in, a program management concept as understood by the Air Force and by contractors who'd worked with the Air Force, was not in place. Was it the case that there was some alternate approach to R&D and program work in NASA? Or was it just simply, the new organization hadn't had time to develop an approach yet?

PHILLIPS: Well, when I came into the organization, January of '64, the basic requirements and skeleton of the organizational structure had already been directed and the basics of it put in place under George Mueller's direction. George Mueller came into the organization in the spring of '63, and when he came into the organization, into NASA, a program organization really did not exist, and George could tell you in appropriate detail exactly what existed when he came in and what he did about it. So as I said, when I came into the organization, the basic concept and skeletal structure already existed. So my job was to complete the design and to fill it out and make it work.

And I might add, Martin, that the basic concept and structure which George Mueller had put in place was totally consistent with my experience in managing the Minuteman program. So it was totally in accord, what he had directed and put in place skeletally, was totally consistent with my own experience and concepts of how it should be structured and managed.

COLLINS: You indicated previously, when we talked last time, that when you first came to NASA, there was some antagonism because of your Air Force background. Your discussion here about the program management concept prompts me to ask, was this a function of, that you were in some sense representative of another organization? Or was there some resistance to the idea of the approaches that were being implemented by you and George Mueller in handling the program?

PHILLIPS: You used the word "resistance" in asking the question. I don't recall sensing any substantial resistance, really. There had to be, at least in the back of the minds of many people, some resentment of outsiders coming into their program.

That did not result in any resentment or obstacle placing that was a problem for me. There clearly was a certain amount of a wait-and-see kind of attitude. You know, is this all really going to work? Thinking about top people. And so of course that placed a demand on me, in particular, and on the people that I brought in to demonstrate some--well, to demonstrate what? You know, to perform, and if you will, earn a place in the scheme of things, and therefore to be regarded in a way that important people in other parts of the organization were willing and comfortable to work with. That's not uncommon to any organization.

I know that, after a year or so, I can remember one of the Management Council Meetings in which I remember Joe Shea, who was project manager for the spacecraft projects at Houston, asking me in effect, when is all this going to end? In other words, when are you going to stop coming up with things we have to do? The procedures and so on. This was several months after I came into the program, by which time I had introduced requirements for a number of things and had issued documents and directives calling for many things to be done along the lines we've been discussing. And so you know, that was I guess a manifestation of some impatience, with "when are you guys going to quit laying more and more requirements on us?" But I don't think back on it as an impeding-type statement or even a problem, really.

COLLINS: What I'm getting at is whether there was a sense within the people who had been at NASA for some time that the systems that they had in place were somehow all right?

PHILLIPS: No. No. No, I don't think that at all. As a matter of fact, I would tend to think back on it as more or less the opposite. That essentially all of the responsible people in NASA wanted help in structuring the management system totally to fill in what they knew were voids in their organizational capabilities. In the main these voids were in these process management areas that I've tended to discuss. The NASA organization, I thought then and still do, thinking back to that time period, was a tremendously capable, competent, scientific and technical organization, and there clearly would have been resentment and resistance to me coming in or bringing in people or efforts to interfere or intercede significantly in their scientific and technical designs. So there would have been resentment and resistance in those areas. I want to put a caveat even on that statement, because progressively, all the way through a program like Apollo, there has to be a continuum of decisions and inputs and directions on technical matters, many of which are highly technical. But that, in a well working organization, can work very well, and it did, at least from my perspective in Apollo, as an evolving development matter in management of technical activities.

    But in the program planning and control, and in the system engineering configuration management areas, there was really not resistance or resentment. More, there was an open minded desire for "help." We tended to run into more in the way of resistance in the operations area. That was I guess largely because the only world's experience in manned spaceflight operations had been created through Mercury and the early parts of Gemini, and so there was more in the way of resistance and reluctance and even maybe elements of resentment to intruders coming in from outside, like the Air Force, to bring to bear requirements and so on in the operations field.

COLLINS: I don't know whether you still want to stick by this characterization, but last time you did mention the word antagonism, when you came in as an Air Force person. It occurred to me, though, that many of the people from NASA came from NACA, which had a lot of experience with the military, and the other significant fraction of people who came over from the Army in von Braun's group had significant experience, although obviously there would be interservice rivalry questions there possibly. It would seem that the question of antagonism might not enter in to such a degree given that kind of background of the people that were there.

PHILLIPS: Well, that's a true statement and I would have difficulty I guess today using the word antagonism in any major sense. I would more tend to think of it as we've been discussing for the last twenty or thirty minutes, the general attitudes. If there was antagonism, and that is a bit of a strong word that I would not tend to use, I'd think of it more as reluctance, resistance, maybe even elements of resentment in the operations area, that I was just talking about a minute ago. Organizationally that would have focussed mostly at Houston, because as you have already said, Marshall, which had its origins in the military--Army. Kennedy had its origins coming out of Marshall in the main and of course the third major center being Houston, which had fundamentally come out of NACA, out of Langley, its origins. So Houston tended to be polarized on many, many matters with the other centers, and it led to a lot of difficulties over time in structuring the interrelations with Marshall, and more apparently really with Kennedy, over how spacecraft were going to be brought into Kennedy, and who was going to be responsible for their test and checkout and assembly and ultimate launch.

    Those organizational interfaces were fairly difficult when I first came into the program. The organizational interfaces on day one when I came into the program between Washington and the centers, and among the centers, as I said, were fairly difficult. I tended to characterize NASA as a group of feudal baronies, after I'd been there a few days to kind of see what was going on. Those attitudes existed for a lot of reasons, some of which were associated with the origins and evolution of each of the organizational elements. Some of them, I guess, some of the attitudes were sponsored by, who was really in control, and who was responsible for what, and who got how much of the total pie, thinking of money and resources, to create things and do things. And I suppose some of the attitude was a manifestation of some resistance to outsiders coming in and having key positions, outsiders like George Mueller first and me later.

    I said earlier this morning that one of my first priorities was to perfect the organization and make it work. Well, within that, one of the first areas in a broad sense that I identified as needing a lot of my attention and effort was team building, to work toward creating across the program a real team to include the NASA elements and for that matter other elements of the government organizations that were involved, like for example, military, and in turn industry. My own view is that progressively, starting from early in '64, the creation of a real team of government and industry was accomplished, and progressively as time went on that team got stronger and better and worked better and better together. So by the time we got into our actual flying program, starting with unmanned flights, we really did I think have a very strong, well-working team of government and industry. So team building was one of my very early efforts, and I devoted a significant amount of time to that broad subject over my whole time at NASA.

COLLINS: Let's look a little bit then at the nature of the tensions between Headquarters and the two principal centers that you dealt with, Houston and Marshall. What was the nature of the tension between those centers and Headquarters?

PHILLIPS: Well, one of the fundamentals involved in that relationship was what scientific and technical capability was required, and to do what, in Washington. That was very fundamental in the whole thing. Joe Shea, who by early '64 had already gone to Houston and was project manager for the spacecraft in Houston, was himself a highly experienced system engineer. He'd come from experience in Bell Labs and TRW for that matter, what was then STL in system engineering, so Joe was as good a system engineer in a technical sense as anybody would ever want to find. And Joe's attitude was that Washington should not create a significant system engineering organization and bring in any significant number of people to do top-level system engineering, but that Washington should operate in a way that used the centers essentially to perform system engineering. Well, other people at Houston felt the same way. Gilruth, certainly [Max] Faget, as well as Shea, those being the principal ones--aside from operations, which [Chris] Kraft headed, and crew matters, which [Deke] Slayton headed--were very much of the same mind. Essentially they were saying, "Look, we don't need Washington's help to tell us how to build a spacecraft."

    And coming from a different point of view, the attitudes at Marshall were somewhat similar. In other words, we don't need people in Washington to tell us how to build a launch vehicle orultimately a Saturn V. Kennedy had much the same attitudes as Marshall.

    Well, to a degree I agreed with that kind of concept. In other words, it's not the job of the people in Washington, me or the people who work for me, to design or in any detail direct the design of these various modules and the total system. So in broad concept I agreed with that. The need for system engineering management and direction from the top of the program in Washington was in several process and how-are-we-going-to-do-it areas that I've already elaborated on, and there wasn't a whole lot of disagreement about that. There wasn't much of any disagreement. That's generally the area in which the centers welcomed help. There was need for overview or oversight in intercenter matters, whether the centers wanted it or not. That was just a fundamental need. The element of system engineering that I mentioned that carried out its work generally through the panels, the panel review board that I mentioned, was the mechanism by which I and my people in Washington really carried out my perspective of the overview or oversight, and therefore review and direction in these interface and therefore technical areas.

    I said earlier, I wanted to discuss some of how we wound up with something of a hybrid organization in Washington, which was not as pure as I was describing a while ago, with the three deputies: program planning control, system engineering, and operations. This is probably a good time to talk some more about that. [interruption] I've forgotten now what we called them, but I was the program director and the people who reported to me were system engineering director--I can't remember now. But the head of system engineering in my program office was a BellComm person, and his name, specifically in the early years and for much of the program, was Tommy Thompson. BellComm was a company which had been created at Jim Webb's request in the early sixties, I suppose in '62, by Bell Laboratories, responding to what Webb described as an urgent national need for a scientific technical organization to accomplish system engineering on Apollo. Bell Labs created a subsidiary they called BellComm.

    When I came in early in '64, the BellComm president was John--I'll remember the name later--who'd come from Bell Labs and was replaced midway in the Apollo program by Ian Ross, who even today I think is the head of Bell Labs, or he was until recently anyway. In other words, they were putting top-level people in there. John Hornbeck was his name. John Hornbeck. The way he had organized, he set up essentially a program organization headed by Tommy Thompson and a scientific and technical organization as well as administrative, and so I assigned Tommy Thompson as my director of system engineering, and of course that then gave me, the Apollo program, the full complement of BellComm to perform.

    BellComm was not really fully capable of carrying out the system engineering, management function in the perspective that I've described earlier and that I felt was needed in the program. So I hybridized to an extent, by putting responsibility for configuration management in program planning and control. Now that's a bastardizing of the fundamental concept but it worked quite well. And so therefore the job of BellComm progressively got defined with a lot of scientific content and environmental requirements content. BellComm did a lot of the basic work in defining the whole environment in which Apollo had to live, that being in space at the various stages, involving micrometeorites, radiation, solar flares, and midway in the program and later, a lot of knowledge about the surface of the moon and the environment of landing and carrying out the jobs and so on.

They did a lot of very good and very basic work in those environment areas. They were across the board members of the panels, and in turn of course the panel review board, so in that respect then they had people who were on each of these many panels and therefore in a position to input, influence, and so on that whole process. And there was a lot of learning that went on in that process, and BellComm served an important function in that respect. But the people that I used to define the whole system engineering management process of specs, configuration management and control, and so on, were physically under program planning control and were headed initially by a person I brought in from the Air Force named Jack Colopy. He was an Air Force lieutenant colonel, at that time, and had come out of the ballistic missile and Minuteman configuration management arena.

TAPE 2, SIDE 1

COLLINS: We were talking about the organization of your Headquarters operation, and you had described BellComm's role, and I'd like you to elaborate on the degree to which they participated in the configuration and technical management activity, as well as doing scientific studies.

PHILLIPS: Okay. Well, I mentioned that BellComm had assigned individuals to serve on each of the panels, and also then on the panel review board. So that role of BellComm was very much in the loop of configuration management, because the panels were fundamentally structured to manage all those interfaces, and to a degree, that used the panels in perfecting performance and design requirements in many cases. An example of the latter being, there was a panel whose broad charter was safety. That's not an interface. And that panel, which is one that I spent a certain amount of time personally involved with, had a lot to do with setting standards to achieve safety, and a number of design requirements came out of that panel, having to do with redundancies.

    I remember one of the special tasks that we attacked in that panel, which clearly was an interface issue, was the issue of giving the flight crew ability to manually fly the launch vehicle. To try to be brief, you know, the basic design of the launch vehicle was under control of its own internal guidance and control system, which was programmed in advance to fly a certain trajectory and to carry out all the many things that had to be accomplished in that trajectory, and the flight crew in the basic design couldn't intercede in or interfere with that whole program. They could, of course, exercise options to abort under certain criteria and things of that kind. Well, the flight crew early on identified a desire and a need and, I suppose officially, a requirement to be able, under certain conditions, to manually fly the launch vehicle like you'd fly an airplane.

    So that panel took that task on, and in the final analysis we did, through that panel, come up with the basics that then led the contractors to design and the organization then to perfect and approve a way in which the flight crew could fly the launch vehicle. I'm digressing from the basic need or the basic thing here of discussing the BellComm role, but the perspective I'm trying to establish is that BellComm engineers assigned to each panel were very much involved in the design and design review, design requirements of system engineering, configuration management process. And so that, in a sense then, gave them the procedure by which they could carry out that piece of the system engineering responsibility.

COLLINS: Was this the primary way in which they related to their counterparts in the centers and in industry, or were there other mechanisms?

PHILLIPS: There were other mechanisms. Each of the BellComm engineers allied themselves with "counterparts" in centers and contractors. In other words, you know, the people working on the subjects that were in their sphere of responsibility were known, and BellComm then, individuals tended to work with those individuals as they worked their various designs and problems. So that was another mechanism. Another mechanism was BellComm's participation in the formal series of reviews that I mentioned earlier, the preliminary design requirements, etc. So those were ways in which BellComm did carry out the full perspective of system engineering.

COLLINS: To get a better sense, it sounds like one of their roles was kind of troubleshooting and problem solving. They were getting in there and working with groups of engineers who had specific problems to worry about. Were they also worrying about overall system concepts as well?

PHILLIPS: Yes. Yes, and some of that was done even before my time. By the time I came into the program, the mode decision had already been made. That's the one that identified the lunar orbit rendezvous mode as the way to carry it out. And that in turn had led them to laying out the basic flight trajectory, and BellComm did play a role in the progressive definition of that whole sequence that was the flight profile. And that was, as you put it, the broad perspective of system engineering. A role in that.

COLLINS: In this scheme of things, who had overall responsibility for the systems engineering, the systems integration for the total spacecraft, the launch vehicle and the spacecraft?

PHILLIPS: I did.

COLLINS: And how did you organize yourself to carry out that responsibility? How did that relate to what you've told me so far?

PHILLIPS: The prescription of process involving this whole series of design reviews leading up to a flight readiness review, in which I and the people directly working for me were involved, and in the final flight readiness review. I chaired all of those. I chaired the panel review board which was the ultimate decider of interface issues. I've already described how that whole structure worked.

So my answer to your question, who was responsible for the total system engineering and integration, my answer was, I was. And those are a couple of the ways I carried it out.

COLLINS: I guess the mechanism was the panels and the various review boards which were the mechanisms for handling this work.

PHILLIPS: Yes. I should add that another of my activities which related to that was my own personal attendance and participation in a significant number of center-led activities, in the way of their own program reviews with their contractors. In other words, Joe Shea's organization, which later was headed by George Low, was continually conducting reviews with their contractors, like North American, like Grumman, and in certain cases I attended those and participated in them and interacted as was appropriate. In many cases, people who worked for me participated and interacted, either BellComm or the civil service people on my staff.

    Incidentally, I haven't finished describing all the bastardization of this organization. Another piece of that hybridization was to establish a director of test who reported to me. He was Roy Day, who was in the program office when I took it over. His origins had been through the NACA channel, and he was a good person in technical management areas. And in order to give appropriate visibility and attention to the subject of testing, which I elaborated on earlier as being such a major piece of the Apollo program, I set up this test organization headed by Roy Day, and he had several quite competent technical people who worked for him. One, for example, who was a pro in rocket engines. I can see his face, and I'll remember his name in a minute. Very fine person. And as I say, that's a hybridization in that, in my pure concept, testing is a major role of system engineering, to define the whole testing requirement and program. But here again, BellComm's experience certainly did not put it in a position of the kind of know-how that I felt was necessary to carry out that function. So Roy Day and his people took that on, and BellComm people were very much involved. There was a lot of working back and forth together between Roy Day's people and BellComm people as well as program control people.

COLLINS: Now, Roy Day's responsibility, to refer back to our earlier discussion, primarily would have been to design this test program that you mentioned.

PHILLIPS: Yes. And then to control it, if you will, the definition of control being, you know, tracking its progress against your plan and acting as appropriate. First of all, laying out the requirements. That was Roy Day's job. And then progressively building on those to spell out appropriately more and more detail, and then to keep track of the progress of testing and progress of qualification. Let me just build on that to point out a couple of things I haven't pointed out yet. This panel structure and panel review board which fundamentally was in configuration management and particularly interface control, required a lot of detail work and administrative kind of work and record keeping and documentation control. That job was big enough that we hired a support contractor, General Electric Company, to provide that support, and GE then was essentially the administrative arm. That's an oversimplified way to think of their role in the panel activities. And they then set up and operated a center which was physically located at Huntsville in the Marshall facilities, which was the repository of all the interface control documentation.

COLLINS: For the entire Apollo system?

PHILLIPS: Yes. So there was a support contractor role that really played a part in my pure concept of system engineering. Another one I want to mention was a decision that I made, after the fire, by which point it was to me clear that we needed a greater depth of involvement in this whole testing qualification and flight readiness process. I've tended to think of what I'm about to describe as being the hard, dog work part of system engineering, the requiring of, for a big program like Apollo, a fairly significant number of well-seasoned engineers. And for a number of reasons and through a process that I won't try to describe right at the moment, we selected the Boeing Company to perform that role, and the title of their contract was "Technical Integration and Evaluation." It was called the TIE contract.

COLLINS: This was after the fire, though.

PHILLIPS: That's after the fire, as I said. And Boeing then rapidly put together a fairly large--I don't remember the number-and very capable organization of engineers. By that time, I had located my program office over in L'Enfant Plaza, and I gave Boeing one floor of that building to house their organization. I structured the TIE contract in a way that elements of the TIE Boeing organization were physically located in each center, so there was a group of TIE engineers, Boeing engineers, at Houston, Huntsville, and the Cape, and the top group here in Washington, co-located with me. Their broad job was involvement in depth in, I'd say, all of the testing activities. "All" has to be somewhat in quotes because they were so extensive and pervasive, but certainly in the more major ones, and so they did a lot of things. They observed and participated in test programs, especially at the higher levels of testing, reviewed test results in some depth, and ensured that anomalies and problems were tracked to proper solutions.

    So that was one broad category of their job, and another broad category of it was problem solving. Not unexpectedly, we ran into some fairly major problems in the course of the program. Just to mention one or two, one was POGO in the Saturn V, and that appeared on, I guess 501, which was the first unmanned flight of the Saturn V. POGO is a latitudinal oscillation that develops in a launch vehicle, which amounts to a positive feedback system in which the structural dynamics interacting with the propulsion introduce propulsion stabilities [instabilities] which feed each other, and you wind up with very large and ultimately destructive oscillations or major vibrations. So I assigned to Boeing the job of helping me insure the proper solution to that problem. The ultimate solution of it has to occur in the centers and their contractors, obviously, and I don't want to try to, you know, give more credit on one side or the other, but in the heat of need to identify problems and see that they get fixed, major problems were the kind that I felt I needed to get some help, to go help work, and see they got fixed as rapidly as possible, which in itself usually, and always I guess did involve significant additional testing.

    So that was done, and I can remember in that particular case participating in several or at least a few teleconferences. By that point in the program, we had set up over at L'Enfant Plaza a large conference room which had teleconference facilities with each of the centers and some of the contractors. So we were able to call a meeting with some hours or a day's notice, and to include all the centers, my office, and one or more contractors, each according to some pre-planned agenda to discuss or brief a particular problem or subject and state of action. So this POGO problem, for example, got some of its reviews and ultimate solution through that teleconferencing process. Just briefly to say how that worked, it was speaker telephone connections with each participant, plus a fax machine, which we used to transmit visual material, viewgraphs, and they'd be transmitted both in advance and during a meeting and put up on the screen so all participants could see them. So it was a very effective means, and it allowed us to bring to bear a number of people and organizations rapidly without having to travel people all over the country to do it. It was used quite extensively during the last four or so years of Apollo, up through '69.

    Another major problem that I told Boeing to tackle in this same sense was the set of failures that we had on the second unmanned Saturn V, 502, and that was the second and planned final unmanned flight of the Saturn V. In that flight we had, I guess, two engines fail on the second stage. I think we had a failure to restart on the third stage S-4-B engine. We had a structural failure in the spacecraft LEM adaptor. So in a sense it was kind of a major set of failures, and I suppose you could look on it as almost a disaster. But on the other hand, we did accomplish most of the flight objectives, and the flight was carried out to satisfactory completion. But there were sure some major problems that had to be solved. Like finding out why two of the engines in the second stage failed, and so on. Well, here again, in the end the contractor has to fix problems, and I think Boeing did a super effort of, for me, leading the charge to do all the detective work and design work and testing, to identify and fix all those problems.

    There were others. But the broad concept, as I said, was system integration and evaluation, therefore in-depth involvement in testing, across the whole program, in-depth involvement in the final design reviews and flight readiness reviews, the documentation of anomalies and problems and failures, and the tracking of those to satisfactory completion. We had by then developed rules in Apollo that there would be no unexplained anomalies. In other words, they had to be tracked to some decision, and actually documented, starting with even an anomaly as opposed to a failure of significance. An anomaly in a test program--something doesn't look right or isn't working quite like it's supposed to. It gets identified and then tracked through to some responsible decision, that either something is changed or that there is an adequate explanation of why that occurred.

COLLINS: Some of these hybridizations that you've described obviously occurred over a period of time and seem to reflect your increased understanding of different areas in which the organization lacked specific skills or talents or capabilities.

PHILLIPS: Yes. That's true.

COLLINS: The timing of the TIE contract came in the immediate aftermath of the fire. Was it more a function that the fire highlighted a series of problems, and Boeing was brought in to help solve them? Or did you sort of recognize the need for the sort of things that Boeing did before the fire and had hoped to create some kind of resource for solving those problems?

PHILLIPS: Some of both. I'm sure in the Smithsonian's interviews with Jim Webb, this subject has come up. Let me briefly describe my perspective. When the fire occurred, Jim Webb as the administrator was obviously very much involved and felt an appropriate amount of personal responsibility. I think we've talked some about the "Phillips Report." You've got to remember that this effort that finally became known as the Phillips Report had all been done prior to the fire. I'd had that major team effort of reviewing North American in both the CSM contract and their work, and in the S-II stage and their work, reviewing the North American Company's performance and conduct of those major programs, and had in the course of that identified a lot of problems, and North American in turn had identified a lot of actions they were going to take to fix their problems. So that was all behind us when the fire occurred, and Jim Webb was generally familiar with that work. It was our practice to keep him appropriately informed.

    Jim Webb took the initiative, after the fire, to start considering for himself and at his level whether North American as a contractor ought to get thrown out of the program and some other contractor brought in, or just what should be done. In that period, Jim Webb was calling me fairly frequently, and I was going over to see him fairly frequently and participating in these activities which he was taking the initiative on. One of those activities was to invite in a series of contractors, and to ask them, if they had the job of doing the spacecraft, what would they do? This was Jim Webb's initiative and way of looking at the problem that he felt existed. There were several contractors that came in and gave briefings and discussions. This whole process didn't take very long.

After we'd heard from each of the contractors that he invited in, when just the two of us were discussing the matter, he asked me what I thought we should do. And by that time, I really had made up my mind what I thought we should do, which was to write a sole source contract with the Boeing Company to provide what was then rapidly defined as the technical integration and evaluation work. This, in my mind, recognizing the goal that had been set and the job that we had to accomplish, and also of course recognizing my in-depth involvement with North American through the months that I did this review work that resulted in the "Phillips Report." I felt the way to get the program done best was to work on and with North American to see that they performed their job adequately, and I needed some additional help to do that, and I felt that what had been done in getting inputs from a number of contractors had sufficiently satisfied the needs for a competitive look, that we were justified in writing a sole source contract with Boeing to provide this service. So I told him that, and he said, "Okay, go do it," so that's what we did.

COLLINS: Did it cross your mind to try to augment BellComm in some way to take on this task? Would that have been an appropriate job for them?

PHILLIPS: Well, I don't recall that it crossed my mind, then, and even thinking back now, I don't really think it would have been the right way to proceed.

COLLINS: Can you give me a sense of why? Some of the things that I think Boeing came to do under the TIE contract are similar in some respects to what BellComm was doing.

PHILLIPS: Well, yes. But the fundamental capability of two major corporations was really involved. The fundamental capability of Boeing--and I'd worked with Boeing ever since back in the early fifties, on up through Minuteman--was just inherently what I've described. You know, they could quickly put together an in-depth group of very seasoned, experienced, competent engineers who understood the problem, the need and how to proceed, and they were able to do that in a matter of days. BellComm, coming from the heritage of the Bell Laboratories, was more of a scientific R&D organization and was not inherently built on developing the capability, if you will, for these massive systems. Not to demean the major telephone networks, but it's a different kind of job. And so BellComm was not inherently built on a foundation to be able to quickly pull in the kinds of engineers that were needed for this job. Boeing was.

COLLINS: Was there anything else you want to say about your Headquarters organization?

PHILLIPS: Yes, I should mention two other pieces of the organization that I haven't mentioned so far. One was a small organization assigned the responsibility for reliability, quality, and safety, and that was headed by a person initially, George White, who also had come up through the NACA system and was there when I came in. A very capable person who later moved on to some other job, and I gave the job to Will--I'll think of it. So that small group of NASA people, civil service, and I guess a few military assignees, I assigned the responsibility for, if you will, writing the rules for ensuring reliability and quality and safety. Now pieces of that of course are system engineering-related. It's not uncommon to have those functions report separately. As a matter of fact, I guess there are even essentially laws that require it, now.

    The other piece of the organization I haven't mentioned is operations. I had a director of operations who reported to me. His name was Jack Holcomb. He was by then a retired Navy captain who had come into NASA earlier on. He was there when I came into the program. I gave him the job of working the whole operations planning and preparation processes. So that gave him a very difficult job of working directly with the operations organization at Houston. I say that was a difficult job because the experience to that point in manned space flight operations was at Houston, and there was much more of a resistance to outsiders being involved in that sphere than there was in the other spheres of activity. But that notwithstanding, I think Jack did a super job of specifying the requirements for planning and ultimately the conduct of operations, and working with the people at Houston, the people at Marshall, and also extensively with the people at the Cape, to develop and oversee that whole process.

COLLINS: Maybe you've already answered this question. For these various functional offices that came under you, the program planning and control, director of testing, the systems engineering--and you mentioned that they related to the centers through various panels and review boards--how did their counterpart offices in the centers and the different program offices relate to them? What was the nature of that relationship, and how did that help them tie in with the centers?

PHILLIPS: Well, we required the organizational structure at each center to be, if you will, mirror images of my organization. My organization consisted of the program director--me--and whatever I had to help me directly there, and five subordinate directors: program planning and control; system engineering; test; reliability, quality, and safety; and operations. Those were the five, and we required that each project office at the centers organize the same way. So Rudolph at Marshall had the same structure. So each of these functional people had counterparts, and the same at Houston, and the same at the Cape, and over time, that functional counterpart organization learned to work well together, and it was an important piece of the teamwork, if you will, that was built up.

COLLINS: Okay.


Phillips 5 || Table of Content

Rev. 09/06/96

© 1996 National Air and Space Musuem

DCSIMG