Category The Secret of Apollo

From Weapons Research to Weapons Development

Corporal’s acceleration shifted JPL’s emphasis from engineering research to large-scale development. Fundamental research continued, but at only a frac­tion of JPL’s budget, as engineering and production budgets for the Corporal project climbed dramatically.

Dunn and Pickering led the Corporal project. Dunn came to Pasadena in 1926 from South Africa to study aeronautical engineering under von Kar – man, completing his doctorate in six years. Associates characterized him as a decisive, orderly executive who organized JPL on a project-oriented model. Pickering came to Caltech from New Zealand, taking a Ph. D. in physics in 1936, then joining the electrical engineering faculty. He worked on electron­ics for cosmic ray studies and expanded into telemetry and guidance design in 1944 at JPL. In 1950, Pickering was head of JPL’s Electronics Department, along with being the Corporal project’s director. Pickering preferred an aca­demic orientation, emphasizing technical excellence organized through work­ing groups.13

In October 1951, JPL froze Corporal’s aerodynamic configuration, and Army Ordnance committed Corporal to limited production, selecting Fire­stone Tire and Rubber Company to manufacture the missile. JPL expanded its staff and used the production missiles for test firings.14 Test firings were disap­pointing, as electronic components frequently failed. Although JPL engineers realized that rocket engine vibrations were a factor, they had seriously under­estimated the magnitude of the problem. As failures mounted, they began recording failure statistics. By summer 1953, with more than forty firings com­pleted, JPL calculated missile reliability at only 48%, even with the electronics wired into two strings of components such that if a failure occurred in one set, the other would continue to operate.15 Reliability problems threatened to

undermine the project and with it the credibility of Army Ordnance officers and JPL engineers.

The majority of early Corporal failures were in electrical systems such as power, guidance, radar, and telemetry. According to JPL engineers, ‘‘Neither the reason for the failure nor the specific part failing is known in most in­stances; failures are commonly attributed to vibration.’’ Consequently, they tested components with a sine-wave vibration generator and at high and low temperatures. They found that some components had resonant frequencies that could lead to physical breakage. Engineers developed a program to test all electronic parts and changed both vendors and parts. They developed a rule of thumb to repair failures on the spot but redesign a component if it failed three times.16

Whereas aircraft structural vibrations typically occurred at predictable fre­quencies matching the rotation rate of propellers or jet engine rotors, rocket engines produced vibrations at near-random frequencies. In addition, high speeds and changing altitudes placed strong, highly variable aerodynamic forces and vibrations on the missile’s structure. These shook loose or severed wires, connectors, and soldered components, causing electrical short circuits and intermittent connections. The failures raised havoc with the electrical sys­tems such as radio guidance, attitude control, and telemetry subsystems.17

One response was to acquire better flight data. Engineers placed acceler­ometers and strain gauges on the missile, and they sent the data through the radio system to be recorded on the ground. Because the speed of data collec­tion and radio transmission was too slow to capture the full profile of high – frequency vibrations, engineers constructed algorithms to calculate vibration frequencies and amplitudes from the infrequent data samples. These algo­rithms were sufficiently complex and data-intensive to require the use of an IBM programmable computer. After much work on these data transmission, storage, and processing problems, engineers found vibrations to be highly un­predictable.18

Because of the expense and inconclusive flight test results, engineers con­structed a vibration simulator to test individual components and component packages. They expanded component and package testing, and they formu­lated guidelines and standards.19 Vibration testing henceforth became a stan­dard element of component qualification and missile development.

JPL engineers also theoretically analyzed missile reliability. Assuming that each component had a measurable failure rate, engineers estimated missile re­liability simply by multiplying component reliability estimates. For example, for a missile with only two electronic components, where these components both had to operate and each had a 90% probability for successful opera­tion, multiplying their reliability estimates together gave a combined reli­ability estimate of 0.9 X 0.9 = .81, or 81%. In this way, engineers estimated the decrease in reliability as they added electrical components. With calculations such as these, engineers determined that adding a second parallel “string” of components significantly improved missile reliability.20

In light of the Korean War and the tense situation in Europe, the army de­cided to deploy Corporal despite its severe reliability problems. Both JPL and the army soon realized that Corporal was not designed for operations. JPL engineers had initially designed Corporal purely as a research vehicle using World War II vintage hardware, much of it out of production. When failures occurred, researchers investigated and fixed them on the spot. The army sent military crews to White Sands to learn how to prepare and fire the missiles, but they did not have the expertise of professional engineers. JPL’s lack of operations experience showed in its poor documentation and frequent de­sign changes. Poor training led to more failures and lower reliability, because operational reliability depended upon enlisted personnel to maintain and fire the missile.

Pushing Corporal into crash production aggravated the situation because the army had to use JPL’s sensitive laboratory equipment in the field. Many missiles failed tests because ground equipment had shifted out of tolerance. Even after relaxing tolerances, experience showed that on average, in the four hours necessary to prepare and fire a missile, one electronic component failed. The awkward, bulky equipment was extremely cumbersome. When a Corporal battalion moved, its convoy stretched sixteen miles!21

Flight instrumentation was another major problem. JPL engineers initially believed they needed little instrumentation for the tactical missile. This was a mistake. Jack James, an engineer assigned to this problem, reported that throughout a program of 111 development firings and 150 training rounds through June 1957, engineers and technicians modified every missile to in­stall instrumentation. With thirty tactical ground systems capable of firing

Corporal but only eleven telemetering stations and two telemetry processing facilities (one at JPL and one at White Sands), telemetering stations had to be shipped to the firing site and all data sent to JPL or White Sands for analy­sis. Because JPL had few personnel trained to analyze test data, substantial delays ensued. These experiences taught James that good vehicle design re­quired up-front consideration of testing and operational factors, with a design that incorporated sufficient instrumentation.22

As problems mounted, in November 1953 the army proposed to assign a commanding officer to JPL, a significant step toward turning it into a govern­ment arsenal. If the army wanted to control JPL, the trial balloon was ill-timed because it had little choice but to rely upon JPL to rapidly deploy Corporal. Although technical problems reduced JPL’s credibility, the urgency of speedy deployment weakened the army’s position even more. Army Ordnance back­tracked and in 1954 gave JPL even more responsibility for Corporal. Because JPL was the only organization capable of making the missile work, army offi­cers had little choice.23

The best efforts of JPL and the army improved Corporal’s reliability to an estimated 60%, the best achievable with its inherent design deficiencies. This left serious doubts as to its utility.24 Corporal’s real value was that it trained the army and JPL how to, and more importantly, how not to develop a missile. From this experience, JPL’s leaders recognized that academic, ad hoc design methods and loose organization were not sufficient to create an operational weapon. They vowed that on the next project, they would not repeat these mistakes.

Codified Knowledge

In bureaucracies, procedures define the functions of every job and who re­ports to whom. Procedures specify the communication channels, the data to be communicated, who analyzes data to create information, and who makes decisions based on that information. Systems management defined such pro­cedures for the organization of R&D.

Failure spurred the development of systems management. In the first mis­sile and space projects, few procedures or standards existed, for the simple reason that no one had built space vehicles before. Individuals used methods with which they were familiar, until they found them ineffective. As is typi­cal in pioneering work, individuals made mistakes and did not want to repeat them or have others make the same errors. They developed and documented new processes that avoided their initial errors. Later projects used these meth­ods, sometimes modifying them in accordance with new circumstances.

Procedures served two purposes: to pass on good scientific, engineering, or managerial practices; and to protect the organization and its individu­als from external criticism. Organizational and process changes typically fol­lowed technical problems rather than preceding them. Documenting the les­sons learned from success and failure, and standardizing successful practices, created consistency across the organization. To distinguish this kind of knowl­edge from other, more familiar forms such as mathematical, scientific, or tacit knowledge, we may call this codified knowledge.6

Codified knowledge is knowledge put into verbal or “algorithmic” form, typically documented in explicit written instructions. For example, the mili­tary relies upon regulations and procedures because officers frequently rotate to new tasks and positions. The military would degenerate to chaos if it did not have explicit written procedures to document the functions of each posi­tion and its processes. Small organizations where each individual understands all tasks need few procedures. However, beyond a certain organizational size, no individual can understand all tasks or processes, and written procedures become more important.

Individuals write procedures to accomplish a specific function. This helps to explain why systems engineers had such a difficult time explaining them­selves to their academic colleagues. Engineering researchers in academia de­fined themselves through a body of theoretical or empirical knowledge. More importantly, they prized the creative process, which cannot follow set rules or strict procedures. Although academic engineers performed specific tasks, such as writing proposals, performing research, and teaching, procedures had little meaning to them, because their research created new knowledge for which no procedures existed. By contrast, systems engineers performed a specific function, and their unique knowledge consisted of algorithm-like processes and procedures to analyze and coordinate the designs of other engi­neers. Systems engineers needed creativity to solve problems, but the pro­cesses that led them to the problems and the methods to coordinate the solu­tions could be standardized. Hendrick Bode, a systems engineer with Bell Laboratories, compared systems engineers to architects, acting as the bridge between builders and users, designing the overall system, and coordinating the entire effort.7

Contrary to the observations of some management theorists, bureaucracy is not inherently antithetical to creativity or to R&D in general. In fact, the his­tory of systems management shows that bureaucracy can be useful to ensure that all parties involved with R&D—the funders, the managers, and the tech­nical experts—have a part in the process. Systems management provides a framework in which R&D flourishes as a stable part of organizations. Further­more, elements of systems management, such as change control for design coordination, are essential elements of the technical processes in technology creation.

Systematic, Scientific, and Systems Management

Systems engineers and operations researchers often traced the lineage of their techniques to Frederick Taylor’s scientific management movement in the early twentieth century. To these mid-twentieth-century spokespeople, Taylor’s in­novation was the application of scientific methods to the analysis of processes. So too, systems engineering and operations research applied rational thinking to the processes of R&D. Just as systematic management standardized corpo­rate planning and communications at the end of the nineteenth century and scientific management rationalized manufacturing processes in the first de­cades of the twentieth century, systems management bureaucratized the R&D process in the middle of the twentieth century.8

One way to view these three management movements is to identify each with the group over which managers gained authority. In systematic man­agement, executive managers developed methods to coordinate and control lower-level managers and office workers. Scientific management extended their authority over industrial workers. Systems management expanded man­agerial authority over scientists and engineers. In systematic and scientific management, upper-level managers typically appropriated skills and knowl­edge from lower-level workers. Systems management did not appropriate skills but rather developed proxy measures to assess R&D workers.

Without the ability to develop technologies themselves, managers and mil­itary officers developed schedule and cost measurements to assess progress against a plan. The Program Evaluation and Review Technique (PERT) and the critical path method became popular in management precisely because they gave managers for the first time methods to assess technical work prog­ress without having to rely completely on the technical workers. Configura­tion management forced technical experts to give the cost and schedule in­formation necessary for managers to develop reasonable plans. Armed with relatively accurate schedule and cost data, managers could then monitor these factors as a proxy for technical progress. Because funding was the primary resource they controlled, managers finally had the means to monitor and con­trol the scientific and engineering teams.

Managers did not eliminate working groups or appropriate the technical knowledge of scientists and engineers. Instead, management superimposed hierarchy over technical teams through the imposition of project manage­ment and configuration control. Project management gave one manager con­trol over project funds. Working teams designed the system and periodi­cally reported their progress through design reviews. The products approved in design reviews became baselines, changeable only through management approval tied to cost and schedule. “Management by the numbers’’ became popular at this time in part because these numbers served as proxies for tech­nical knowledge. In earlier times, managers could directly understand and control their workers. With knowledge workers, this was no longer possible, and ‘‘the numbers’’ became the substitute of choice.

Through systems management, government officials could assess future technologies with systems analysis and control current projects through proj­ect management and systems engineering. On highly technical projects such as the military’s weapons programs or NASA’s space projects, the govern­ment’s ability to command industry became powerful indeed. Systems analy­sis, project management, and systems engineering have become standard techniques throughout the government and indeed throughout much of American industry.

People today often criticize NASA for its bureaucratic ways, yet when NASA has relaxed its grip, it has endured failures such as the Challenger accident or the Hubble telescope’s embarrassing optical problems.9 The ‘‘faster, better, cheaper’’ mantra of the 1990s is of questionable value for space programs. How many of the bureaucratic methods of systems management can be eliminated before there are large-scale failures? Recent events, such as the loss of recent Mars probes, show that NASA cannot eliminate many systems management methods. It is folly to think that it could be otherwise for space projects.

Proponents of the ‘‘faster, better, cheaper’’ approach want to return NASA

to the days of frequent, relatively inexpensive spacecraft and launchers built by small, informal teams. As we have seen, however, the ‘‘good old days’’ were also times of frequent failures, huge cost overruns, and common sched­ule slips. NASA managers and engineers created the formal mechanisms of systems management explicitly in response to the problems of ‘‘ad-hocracy.’’ Systems management, as recent spacecraft failures once again prove, is cost- effective on a per-successful-flight basis for space projects.

Another criticism comes by comparison with Japan. The Japanese devel­oped a managerial system based on quality. This system, according to pro­moters of methods such as total quality management (TQM), is superior to the American system because it focuses on the ‘‘voice of the customer’’ and because workers on the factory floor have a voice in improving the manufac­turing process. The Japanese method is a direct outgrowth of American-style Taylorism and has often been roundly criticized in Japan as being too rigid and controlling. The quality methods developed in Japan stem from the same concerns with reliability that the American aerospace industry had. Whereas Japanese managers and engineers focused on the reliability of mass produc­tion processes, their American counterparts concentrated on the reliability of R&D. Both approaches used inputs from the working teams, in the United States with R&D scientists and engineers, and in Japan with the manufactur­ing engineers and production line workers. The TQM promoters believe that paying more attention to ‘‘the customer’’ and to quality will solve American ills.10

The Japanese approach, bred in the ‘‘stable-tech’’ automotive and similar mass production industries, may well be suitable for American mass produc­tion industries but is not well suited to R&D. Japanese industry has been quite successful at copying American innovations and mass-producing them but far less successful at producing its own innovations. The Japanese are far more likely to gain from American systems management for their R&D than Ameri­cans are to gain from applying manufacturing-based TQM to R&D, for the simple reason that systems management developed as an R&D process and TQM did not.

One last consideration points to the broader importance of systems management. Systems management methods have spread far beyond aero­space. As early as 1972, Ida Hoos described numerous government organiza­tions that adopted systems analysis and probably other elements of systems management as well. She decried this as the unwarranted spread of techno­cratic methods to areas in which they were inappropriate. That is undoubtedly true.11

One significant place where systems management spread is the computer software industry. The information industry is now the current exemplar for American industrial dominance. Computer software has supplanted hard­ware as the glamour product. Yet software development is exactly where sys­tems management methods developed in the computer industry. In the late 1950s, the largest software company was the System Development Corpora­tion (SDC), which spun out of the RAND Corporation to develop software and training programs for air force air-defense systems. Programmers trained in systems methodology at SDC on air force programs diffused throughout the United States, spreading the systems approach for programming far and wide.12

More than with any hardware artifact, software development is a pure pro­cess, and the final product is itself a process. Current methodologies in soft­ware development, such as structured or object-oriented programming, are variations on systems themes: simplifying interfaces, enhancing communi­cations, considering the entire product, and dividing tasks into simple work packages. Whatever might be said about software, the industry is rarely deemed overconservative or lacking in innovation. Perhaps systems ap­proaches prevent computer programmers and computer scientists from find­ing a radically better way of developing software. Or perhaps they are the only thing preventing software from sinking into total chaos.

The officers, managers, engineers, and scientists who created systems man­agement in the first two decades of the Cold War did so because they believed in the efficacy of technology to protect and promote the values of the United States. After this time, the apparent effectiveness of these methods in creating missile, space, and computing technologies led technologists and managers in other nations to mimic Americans. Through the combined efforts of these groups of people, technological innovation has become a standardized com­modity throughout the Western world. Systems management has tamed R&D.

Political, military, and business leaders now plan for new technologies years in advance, using the services of scientists and engineers to promote their visions of the future. Systems management has become one of the primary tools of our technological civilization. Change is now the norm, a standard­ized product of systems management.

The Secret of Apollo

This book builds on historical research I carried out over the last seven years and also on my own history and values. I did not begin with the intention of studying systems management or systems engineering, subjects familiar to me from my background in the aerospace industry. In fact, I made some effort at the start not to do so, to avoid my own biases. Originally, I wanted to use my aerospace experience but also to separate myself somewhat from it so as to look at the history of the aerospace industry from a more detached stand­point. I eventually decided to investigate more closely the Spacelab program, a joint effort of the National Aeronautics and Space Administration (NASA) and the European Space Agency (ESA). This seemed a good choice because I knew something of space technology but little about manned laboratories or ESA.

Spacelab looked like a good case of technology transfer from the United States to Europe. Yet I found little novelty in Spacelab’s hardware technology, and neither did the Europeans. So why were they interested in this project? They wanted to learn howto manage the development of large, complex space systems — that is, the methods of ‘‘systems management.” Soon I encountered the “technology gap” and “management gap” literature, the pervasive rhe­toric about “systems,” and the belief in the Apollo program as a model for how to solve social as well as technical problems. This was a worthy topic, particularly because no other historian had investigated it.

Systems approaches emphasize integrative features and the elements of hu­man cooperation necessary to organize complex activities and technologies. Believing that humans are irrational, I find the creation of huge, orderly, ratio­nal technologies almost miraculous. I had never pondered the deeper impli­

cations of cooperative efforts amid irrationality and conflict, and this project has enabled me to do so.

I owe a debt of thanks to many. At the History Office at NASA headquar­ters, Roger Launius, Lee Saegesser, and Colin Fries were helpful in guiding me through the collections. Julie Reiz, Elizabeth Moorthy, and Michael Hooks provided excellent service at the Jet Propulsion Laboratory archives, declassi­fying numerous documents for my rather diffuse research. At the European Community archives at the European University Institute (EUI) in Florence, Italy, Gherardo Bonini located numerous documents and provided many rec­ords I would not have otherwise noticed, sending some to me later when I found that I needed more information. The Technical Information and Docu­mentation Center at the ESA’s European Space Technology Centre (ESTEC) opened its doors (literally) for me, allowing me to rummage through store­rooms full of documents, as well as its collection of historical materials. ESTEC’s Lilian Viviani, Lhorens Marie, Sarah Humphrey, and director Jean – Jacques Regnier were all extremely helpful. John Krige, who headed the Euro­pean Space History project, provided travel funding to visit the EUI and ESTEC archives. I am particularly grateful for his help and trust in me, be­cause he jump-started my research when it was in its very early stages.

In 1998 and 1999 I performed related research for the Air Force History Support Office, contract number F4964298P0148. This provided travel funds and support for my graduate student Phil Smith. I am grateful to Phil for doing much of the ‘‘legwork’’ to dig up archival materials in the Boston area and at Maxwell Air Force Base in Montgomery, Alabama. Chuck Wood in the Space Studies Department of the University of North Dakota encouraged me in this work, and I appreciate his understanding and support for this re­search among my other faculty duties. I thank Cargill Hall, Rich Davis, and Priscilla Jones for their efforts on my behalf in the History Support Office. Harry Waldron at the Space and Missile Center was extremely helpful in gath­ering further materials on ballistic missiles.

Also providing funding for my research was the University of Minnesota Research and Teaching Grant and Dissertation Fellowship program. The pro­fessors at the University of Minnesota with whom I studied from 1992 to 1997 taught me much of what it means to be a historian. David Good and George

Green introduced me to the literature of economic and business history. Ron Giere inspired me to consider philosophical and cognitive issues and to rec­ognize the value of theory, not just for philosophy, but for history as well. Ed Layton and Alan Shapiro stressed the importance of thorough research. Roger Stuewer’s kindness and concern brought me to Minnesota to begin with, and his courses in the history of nuclear physics were important for my under­standing of the European background of large-scale technology development. Robert Seidel helped me to write with more conciseness and clarity and to see several implicit assumptions that I had made. My adviser, Arthur Nor – berg, prodded me to keep moving and to maintain a steady focus on the core issues — the concerns that led me to this project. He kept bringing the ‘‘big picture’’ questions to my attention.

A few scholars significantly influenced my thinking. Joanne Yates’s ap­proach in Control Through Communication formed an important early model for my work. James Beniger, Ross Thomson, Theodore Porter, Tom Hughes, and Daniel Nelson all influenced this research as well. John Lonnquest and Glenn Bugos performed recent research on the air force and navy that directly links to mine.

A number of scholars have reviewed this manuscript, either as a whole or in articles derived from it, and given me significant feedback that has helped in various ways. These include Alex Roland, Harvey Sapolsky, John Krige, John Staudenmaier, Roger Launius, Tom Hughes, R. Cargill Hall, John Lonn­quest, my committee at the University of Minnesota, and the anonymous re­viewers with Technology and Culture, History and Technology, History of Tech­nology, Air Power History, the Air Force History Support Office, and the Johns Hopkins University Press. The anonymous Johns Hopkins University Press reviewer gave me excellent critiques. I owe to him or her the insight that con­currency is not really a management method but rather a strategy that re­quires a strong management method to succeed.

To the extent that this work succeeds, I owe all of these people who helped me along the way. Any flaws that remain are my own.

Finally, I must thank my wife, Diane, and my two sons, Casey and Travis, for being patient with me through this long and arduous process. Only as I look back now do I realize how difficult it has been.

I sincerely hope that this work helps others recognize that the ‘‘systems’’ in which we all take part are our own creations. They help or hinder us, depend­ing upon our individual and collective goals. Regardless of our feelings about them, they are among the pervasive bonds that hold our society together.

Systems Management, Air Force Style

The informal management methods that characterized the manned program’s first few years did not last. New OMSF chief George Mueller understood very well that he would have to implement rigorous cost prediction and control methods to address NASA’s unruly engineers and R&D projects. To do this, he would turn to the management methods with which he was familiar, those developed in the air force and at Thompson-Ramo-Wooldridge (TRW).

Mueller began his career in 1940 working on microwave experiments at Bell Telephone Laboratories. After the war he taught electrical engineering at Ohio State University, and in 1957 he joined Ramo-Wooldridge’s STL as the director of the Electronics Laboratories. He moved up quickly, becoming program manager of the Able space program, vice president of Space Systems Management, and then vice president for R&D. Mueller helped build the air force’s bureaucratic system to control large missile and space projects.60

Before Mueller started his NASA duties, he performed his own investi­gation of OMSF. His first impression of NASA was that ‘‘there wasn’t any management system in existence.’’ The many interface committees and panels worked reasonably well but did not penetrate ‘‘far enough to really be an effective tool in integrating the entire vehicle.” Most seriously, Mueller found no means to determine and control the hardware configuration, leaving no way to determine costs or schedules. Mueller concluded that he had to ‘‘teach people what was involved in doing program control.”61

In August 1963 Mueller invited each of the field center directors to visit him. He explained his proposed changes and how they would help solve NASA’s problems with the Bureau of the Budget and the President’s Science Advi­sory Committee. Mueller explained, ‘‘If we didn’t work together, we were sure going to be hung apart.’’ Mueller had little trouble convincing Apollo space­craft manager Joseph Shea at MSC that his changes were necessary, given Shea’s prior experience at TRW. However, he met resistance from MSFC lead­ers. When MSFC manager Eberhard Rees challenged Mueller’s proposals, Mueller retorted that ‘‘Marshall was going to have to change its whole mode of operation.’’ Two weeks later, at another MSFC meeting, von Braun gave Mueller ‘‘one of his impassioned speeches about how you can’t change the basic organization of Marshall.’’ Refusing to back down, Mueller told him that MSFC’s laboratories ‘‘were going to have to become a support to the pro­gram offices or else’’ they ‘‘weren’t going to get there from here.’’ Von Braun, in response, reorganized MSFC on September 1, 1963, to strengthen project organizations through the creation of the Industrial Operations branch.62

Webb strengthened Mueller’s position by making the directors and proj­ects at MSC, MSFC, and KSC report to OMSF. Mueller reduced attendance at the Manned Space Flight Management Council to himself and the center di­rectors to ensure coordinated responses to OMSF problems. Borrowing from the air force Minuteman program, Mueller also formed the Apollo Execu­tive Group, which consisted of Mueller and Apollo contractor presidents. The group members met periodically at NASA facilities, where Mueller pressured them to resolve problems.63

Facing the same dilemma Holmes faced—Apollo’s slipping schedules and cost overruns—Mueller concluded that the only way to achieve the lunar landing before 1970 within political and budget constraints was to reduce the number of flights. In his ‘‘all-up testing’’ concept, each flight used the full Apollo flight configuration. This approach, used on the Titan II and Minute – man programs, violated von Braun’s conservative engineering principles. Von Braun’s existing plan used a live Saturn first stage with dummy upper stages for the first test. The second test included a live second stage with a dummy third stage, and so on. By contrast, the all-up concept used all flight stages on the very first test. This reduced the number of test flights and eliminated different vehicle configurations, with their attendant differences in designs, ground equipment, and procedures.64

Saturn V program manager Arthur Rudolf cornered Associate Adminis­trator Robert Seamans at a meeting, showing him a model of the Saturn V dwarfing a Minuteman model, saying, ‘‘Now really, Bob!’’ Seamans got the hint — Mueller’s concept did not apply to the more complex Saturn V. En­couraged, Rudolph showed the same models to Mueller. Mueller replied, ‘‘So what?’’ The all-up concept prevailed.65

In November 1963, Mueller reorganized the Gemini and Apollo Program Offices, creating a ‘‘five-box’’ structure at headquarters and the field cen­ters. The new structure (see figure) ensured that the field centers replicated Mueller’s concept of systems management and provided Mueller with better program surveillance. Inside these ‘‘GEM boxes,’’66 managers and engineers communicated directly with their functional counterparts at headquarters and other field centers, bypassing the field centers’ normal chain of com­mand. As one NASA manager put it, ‘‘Anywhere you wanted to go within the organization there was a counterpart whether you knew him or not. Whether you had ever met the man, you knew that if you called that box, he had the same kind of responsibility and you could talk to him and get communication going.’’67

Mueller’s new organization initially wreaked havoc at NASA headquarters, because the change converted NASA engineers who monitored specific hard­ware projects into executive managers responsible for policy, administration, and finance. For several months after the change, headquarters was in turmoil as the staff learned to become executives.68

NASA’s organizational structure changed as a result of Mueller’s initiatives, but he could not always find personnel with the management skills he desired. Shortly after assuming office, Mueller wrote to Webb, stating that NASA could use military personnel trained in program control. Because of the air force’s interest in a ‘‘future military role in space,’’ Mueller believed that it would agree to place key personnel in NASA, where they would acquire experience in space program management and technology. NASA, in turn, would bene-

George Mueller’s ‘‘five box’’ structure replicated the headquarters OMSF organization through the OMSF field centers. Adapted from “Miscellaneous Viewgraphs,’’ circa January-February 1964, ‘‘Organization and Management,” folder LC/SPP-43:11.

fit from their contractual experience and program control methods. Mueller stated, ‘‘It is particularly worth noting that the Air Force, over a period of years, has developed the capability of managing and controlling the very con­tractors upon whom we have placed our primary dependence for the lunar program.’’ He proposed to place Minuteman program director Phillips in the position of program controller for OMSF and contacted AFSC chief Schriever regarding this assignment. Schriever agreed, but only on the condition that Phillips become Apollo program director. From this position, Phillips would transform NASA’s organization and would become known as Apollo’s Rock of Gibraltar.69

Phillips surmised, ‘‘NASA had developed to be a very, very professional technical organization, but they had almost no management capability nor experience in planning and managing large programs.’’70 Phillips turned to the air force for reinforcements and to his most valuable tool from Minute – man, configuration management.

In a January 1964 letter to Schriever, Phillips asked for further air force per-

Подпись: Image not available.

George Mueller (left) and Samuel Phillips (right) imposed air force management methods on Apollo by introducing new procedures and bringing dozens of air force officers into NASA’s manned space flight programs. Courtesy NASA.

sonnel to man OMSF’s program control positions. After AFSC assigned two officers to NASA, Phillips created a list of fifty-five positions that he wanted to fill with air force officers. Such a large request entailed formal negotiations between NASA and the air force for Phillips’s ‘‘Project 55.’’ Secretary of the Air Force Eugene Zuckert agreed to consider transfers if NASA better defined the position requirements, so that he could ensure that the positions would en­hance the officers’ careers. In September 1964, the joint NASA-air force com­mittee reported that ninety-four air force officers already worked in NASA and that forty-two of the fifty-five additional positions requested should be filled by further air force assignments. The air force reserved the right to select junior and midgrade officers for NASA tours of at least three years. Eventu­ally, Phillips requested and received assignments for 128 more junior officers, who were mainly assigned to Apollo operations in Houston.71

Mueller and Phillips placed officers in key managerial positions through-

out the Apollo and Gemini programs, particularly in project control and con­figuration management offices. Phillips also requested a few senior officers by name. By December 1964, NASA and the air force agreed to assign Phillips as Apollo program director. NASA assigned Brig. Gen. David Jones as deputy associate administrator for Manned Space Flight (Programs), Col. Edmund O’Connor as director of MSFC Industrial Operations, Col. Samuel Yarchin as deputy director of the Saturn V Project Office, and Col. Carroll Bolender as Apollo mission director.72

Phillips recognized that NASA’s engineers would resist his primary control technique, configuration management. To meet this issue head-on, he sched­uled a Configuration Management Workshop in February 1964 in Los Ange­les. Each NASA and contractor organization could invite two or three people, except MSFC, which could invite six. At the conference, Phillips stated, ‘‘Coming out of Minuteman and into Apollo, I think I’ve been identified as a procedures and methods man with a management manual all written that I intend to force on the Apollo program and down the throats of the exist­ing ‘good people’ base. So I ask myself, ‘WHY PROCEDURES AND METH­ODS?’’’ Phillips noted that good processes and methods made good people’s work even better and that they enabled the manager to communicate and control more effectively because they created a ‘‘high percentage of automatic action.’’ Because of Apollo’s rapid growth, the program needed better com­munications between NASA and contractor organizations, and all parties had to use consistent language. Phillips stated that good procedures had a high probability of preventing oversights or shortcuts that could lead to catastro­phe. He noted, ‘‘The outside world is critical, including the contractors, Con­gress and the GAO [General Accounting Office], and the press.’’73 Solid proce­dures would help to protect NASA from criticism, by preventing failures and by documenting problems as they were found.

Phillips explained his system of design reviews and change control, both of which would help managers control resources. He viewed the field cen­ters as Apollo prime contractors and considered configuration management a contractual mechanism to control industry. Phillips proposed strong project management along with a series ofreviews tied to configuration control. Con­sistent with military doctrine, Phillips believed that ‘‘diffused authority and responsibility’’ meant a ‘‘lack of program control,’’ so he assigned responsi-

bility for each task to a single individual and gave that person authority to accomplish the task.74

To aid his initiative, Phillips modified Apollo’s information system. In the existing headquarters program control and information system, data were collected from the field centers each month, and then headquarters managers reviewed the data for problem areas and inconsistencies, at which time they advised the centers of any problems. Instead, Phillips wanted daily analysis of program schedules and quick data exchange to resolve problems, with data placed in a central control room modeled on Minuteman. He immediately placed contracts for a central control room, which eventually contained data links with automated displays to Apollo field centers.75

At MSFC, Saturn managers already had a control room to track official program activities. Saturn V manager Arthur Rudolf assigned names to each chart on the control room wall, so that whenever he found a problem, he could immediately call someone who understood the chart’s details and im­plications. The charts varied over time, as new ones representing current problems and status appeared, replacing charts addressing problems that had been resolved.

This room, although useful, had its problems. Rudolf did not like PERT and reverted instead to ‘‘waterfall’’ charts (Gantt, or ‘‘bar,’’ charts arranged in a waterfall fashion over time). Project control personnel translated PERT charts into Rudolf’s waterfall charts, located in a small room across the hall. Because the control room displayed the ‘‘official’’ status of items, it did not always have the kind of information Rudolf wanted. A typical problem would be that a hardware item might be completed but the paperwork might still be incomplete. The control room information would not be updated until the paperwork was complete, and hence it did not reflect the true status of the hardware. By contrast, the ‘‘mini control room’’ across the hall had ‘‘grease – penciled’’ charts with more up-to-date information. With MSFC personnel calling contractors to get status updates, this mini control room buzzed with activity.76

Phillips devoted great effort to the promotion of configuration manage­ment. His headquarters group worked with the air force to develop the Apollo Configuration Management Manual. Issued in May 1964, this manual copied the air force’s manual, which AFSC officers were updating at the time. He wrote letters to the field center directors emphasizing the manual’s impor­tance and directed them to develop implementation plans. By fall 1964, the field centers were actively creating configuration control boards (CCBs), de­veloping the forms and procedures, and directing contractors to implement configuration management.77

Configuration management required that NASA have firm requirements and specifications for Apollo, which did not yet exist, despite three-year-old contracts between NASA and its contractors. Phillips ordered NASA head­quarters and systems contractor Bellcomm to develop definitive specifica­tions. Not wanting Bellcomm to take over this task, field center and contrac­tor personnel quickly became involved, resulting in firm specifications for all Apollo contracts.78

NAA recognized that with Phillips as Apollo program manager, failure to enhance configuration management ‘‘could well be a serious mistake,’’ so it led a study of the process. Under Phillips’s plan, NASA placed preliminary speci­fications under change control after the Preliminary Design Review, and the hardware under change control after the First Article Configuration Inspec­tion. NAA’s group discovered that after the Critical Design Review, NASA did not elevate the final design specifications to contractual status, which could lead to contractual disagreements over design specifications changes. NAA raised this to NASA’s attention, resulting in further enhancement of configu­ration management.79

Phillips soon encountered the resistance he expected. Some of it was passive. He tried to educate NASA personnel about systems management through air force project management and systems engineering courses at the Air Force Institute of Technology, where he occasionally lectured. Despite his enthusiasm, only a handful of NASA engineers and managers attended the one-week course.80

Other resistance was overt. At the June 1964 Apollo Executives Meeting, Phillips had his headquarters configuration control manager describe con­figuration management to the field center directors and industry executives. After the presentation, the NASA field center directors argued against Phil­lips’s plan.81 MSC Director Gilruth had heard that configuration manage­ment cost one additional person for every manufacturing team member. If this was true, then configuration management would be far too expensive.

Phillips’s team replied that based on Minuteman experience, configuration control required only one person per one hundred manufacturing team mem­bers. Air force configuration managers described how Douglas Aircraft took four months to confirm the S-IV stage configuration prior to testing and de­livery to NASA, whereas on the Gemini Titan II, a program with configuration management, it took two days.82

MSFC Director von Braun objected: ‘‘This whole thing has a tendency of moving the real decisions up, even from the contractor structure viewpoint, from the one guy who sits on the line to someone else.’’ Boeing President Bill Allen replied, ‘‘That’s a fundamental of good management.’’ After all, he said, ‘‘Who, around this table, makes important decisions without getting advice from the fellow who knows?’’ Von Braun retorted, ‘‘The more you take this into the stratosphere and take the decisions away from the working table — I think the object of this whole thing is to remove it from the drawing board.’’ Allen, whose company had originally created configuration management, re­plied that you merely had to move the ‘‘top engineering guy into the position of the Configuration Manager.’’83

Frustrated in this argument, von Braun retorted that because the mili­tary produced a thousand Minutemen, whereas there was only one or just a few Apollos, ‘‘We have to retain a little more flexibility.’’ Again, Boeing’s Allen disagreed: ‘‘Maybe I don’t understand, but in my simple mind, it doesn’t make any difference with respect to what has been outlined here, whether it’s R&D, Saturn, or whether you’re trying to produce a thousand letters.’’ Von Braun replied, ‘‘If you want to roll with the punches, then you have to main­tain a certain flexibility.’’ OMSF chief Mueller intervened; on the Titan III program, the first with configuration management from the start, Mueller noted, ‘‘Everything is on cost and schedule, even though it married solids and liquids.’’84 Mueller concluded, ‘‘Configuration management — doesn’t mean you can’t change it. It doesn’t mean you have to define the final configuration in the first instance before you know that the end item is going to work. That isn’t what it means. It means you define at each stage of the game what you think the design is going to be within your present ability. The difference is after you describe it, you let everybody know what it is when you change it. That’s about all this thing is trying to do.’’85

Mueller, who had the ultimate authority to force implementation, quelled executive objections, but resistance continued in other forms. MSC assigned only one person to configuration management by October 1964, slowing its adoption there and at MSC’s contractors. There was continued engineering resistance to change control, Phillips noted: ‘‘Engineers always know how to do it better once they’ve done it, and want to make their product better.’’ Yet ‘‘even engineers will admit that changes first of all must be justified,’’ he added.86

Contractors had one last chance to charge additional costs to the govern­ment before NASA could control them in detail using configuration man­agement. They used the opportunity, preventing full implementation into late 1965 by charging high rates to implement configuration control systems. NASA auditors found numerous deficiencies, including incomplete engineer­ing release systems, no configuration management of major subcontractors, uncontrolled test requirements and procedures, poor numbering systems, lack of documentation, and, in a few cases, no system at all.87

With continued exhortation and substantial pressure, Phillips established configuration management on Apollo by the end of 1966, with four different levels of change control and authority: contractor, stage and system manager, program manager, and program office. Contractors could authorize changes that did not affect any other contractors or specifications. Stage and system managers could authorize changes within their own systems. Only program manager offices at the field centers could authorize changes affecting inter­faces between stages, systems, or field centers. Phillips in the Program Office authorized changes to the master schedule, hardware quantities, or the over­all program specifications. The full system included six formal reviews, after which NASA approved or modified the specifications, designs, and hard-

ware.88

Because the Apollo program had been under way for three years before Phillips took control, many of the designs never underwent the initial reviews called for in the new system. NASA had awarded Apollo contracts without accurate specifications, revised the design after contract awards, and designed and even tested system components without specifications. Only one element, the Block II command module for the lunar orbit and landing missions, fol-

Phillips’s review processes for Apollo, which he used to ensure the success of the moon landings. Adapted from Robert C. Seamans Jr. and Frederick I. Ordway, ‘‘The Apollo Tradition: An Object Lesson for the Management of Large-Scale Technological Endeav­ors,” in Frank P. Davidson and C. Lawrence Meador, eds., Macro-Engineering and the Future: A Management Perspective (Boulder, Colo.: Westview Press, 1982), 20.

lowed Phillips’s process in its entirety.89 Other vehicle elements began their first design reviews at their state of maturity when Phillips levied his require­ments.

Phillips augmented configuration control with other information sources. He held daily and monthly meetings with program personnel. In turn, Muel­ler and Seamans reviewed Apollo each month, and Webb reviewed it annu­ally. The project developed a computer system to automate failure reports, cost data, and parts information. Apollo’s Reliability and Quality Assurance organization developed into an important management tool, supplying in­formation on reliability, test results, and part defects as well as current plans, status reports, schedules, funding, and manpower. It forwarded quarterly and weekly highlight reports on each major system element.90

The two years following the hiring of George Mueller in September 1963 marked Apollo’s transition from a loosely organized research team to a tightly run development organization. Mueller made important early decisions, in­cluding instituting his GEM box organization formalizing systems engineer­ing, reliability and quality assurance, and project control on the manned pro­grams. Mueller forced von Braun and Gilruth to adhere to his all-up decision, sharply reduced flight tests in favor of ground testing, and gave more respon­sibility to contractors. Finally, he started the importation of air force officers to implement program control, beginning with Minuteman director Phillips.

Phillips brought in air force officers to implement configuration manage­ment. Configuration management required precise knowledge of the system specifications and design, the baseline against which managers and systems engineers judged changes. This, in turn, required a series of design reviews and managerial checkpoints that progressively elevated specifications and de­signs to controlled status. Despite resistance, by 1966 Mueller and Phillips augmented NASA’s processes by firmly establishing air force methods within OMSF. The new management methods could not prevent all technical prob­lems or make up completely for the earlier lack of management control, nor did contractors uniformly enforce them. For most technical programs, the most difficult times involve testing problems that arise. Apollo would be no different.

Establishing the WDDS Authority

With Schriever’s organizational foundations set, the immediate task was to push ICBM development rapidly forward and create a detailed plan within a year. Headquarters control and oversight would come through the budget process, so Schriever knew that until he had his plans worked out, he had to keep the budget profile low. He reallocated budgets from several air force organizations and was careful not to ask for too much at the start. Over the long haul, Schriever knew that the massive budget that he needed would re­quire congressional appropriations and that he would have to vigorously de­fend his plan and its costs. To put off this day of reckoning, in October 1954 he requested a relatively small budget, realizing that there would have to be a major readjustment in the spring. ‘‘This support can be obtained by carefully planned and formalized action at the highest levels in the administration,’’ he recognized. In this breathing space, he developed his technical plans, costs, justifications, and political strategy.52

Selection of Atlas contractors was the next task of Schriever’s team. With the design still in flux, this would have to be done based on company capabili­ties instead of design competitions. Bypassing standard procurement regula­tions, Schriever ordered R-W to let subcontracts to potential suppliers to in­volve them in and educate them on the program. This allowed R-W to assess contractors as well as speed development and procurement. Schriever could not ignore all of the air force’s procurement procedures. He had his team cre­ate performance specifications and perform “prebidding activities’’ to pre­pare for a competitive bidder’s conference. Because of the in-depth knowledge R-W had gained through its subcontracts, Schriever had R-W contribute to the Source Selection Boards, providing inputs as requested by the air force. This was a serious (and possibly illegal) departure from standard procure­ment policy, which required that only government officials control contractor selection.53

Schriever directed R-W and his air force team to reassess the Atlas de­sign and to determine Convair’s role. Convair, which had been developing Atlas since January 1946, understandably believed that it deserved the prime contract to build, integrate, and test the vehicle. It vigorously campaigned against Schriever and the upstart R-W. Convair’s leaders sparred with Schrie – ver’s organization for the next few months before they resigned themselves to R-W’s presence. To appease the air force’s scientific advisers, and to gain electronics capability, Convair executives hired highly educated scientists and engineers. For his part, Schriever placed restrictions on R-W to maintain some semblance of support from the aircraft industry. In a memo dated Feb­ruary 24,1955, the air force prohibited R-W from engaging in hardware pro­duction on any ICBM program in which it acted as the air force’s adviser and systems engineer.54

R-W had three tasks: to establish and operate the facilities for the Ingle­wood complex, to assess contractor capabilities, and to investigate the Atlas design. R-W made its first important contribution in the design task. The re­quired mass and performance of the missile depended upon the size of the warhead and the reentry vehicle, for small changes in their mass led to large changes in the required launch vehicle mass. Working with the Atomic Energy Commission and other scientists, R-W scientists and engineers found that a new blunt cone design decreased the nose cone’s weight by half, from about 7,000 to 3,500 pounds. This in turn decreased required launch vehicle weight from 460,000 to 240,000 pounds and reduced the number of engines from five to three. This dramatic improvement discredited Convair’s claim to expertise and convinced Schriever, his team, and his superior officers that the selection of R-W had been correct.55

The most significant technical issue facing Schriever’s group in the fall and winter of 1954 was the uncertainty of the design. Group members simply could not predict which parts of the design would work and which might not. R-W had been investigating a two-stage vehicle, and the initial results looked promising. In March 1955, Schriever convinced Lt. General Thomas Power,

Pre-Gillette organization of ballistic missile development.

the ARDC commander, that a two-stage vehicle should be developed as a backup to Atlas. By May 1955, the WDD was working on Atlas, the two-stage Titan, and a tactical ballistic missile (ultimately known as Thor) as well.56

In the meantime, Schriever considered how best to fund the program. One possibility was to allocate the funds to a number of different budgets, then pull them back together in Schriever’s group. This approach would hide the true budget amounts from effective oversight. However, the budgets required were too large to hide in this manner. With programmatic invisibility un­likely, Schriever’s deputy, William Sheppard, argued that the best approach was to have a “separately justified and separately managed lump sum.’’57

Schriever had already discussed this approach with Gardner, and the two of them plotted a political strategy. Many of Schriever’s budget actions required coordination with and justification to various organizations. Frustrated with the delays inherent in this coordination, Gardner and Schriever decided that they had to increase Schriever’s authority and funding and decrease the num­ber of organizations that could oversee and delay ICBM development. Both Schriever and Gardner recognized that they needed political support, so they vigorously sought it in Congress and within the Eisenhower administration. Gardner and Schriever briefed President Dwight D. Eisenhower in July 1955, eventually convincing him and Vice President Richard M. Nixon — with John von Neumann’s timely support — to make ICBMs the nation’s top defense priority.58

With the president’s endorsement in hand by September, Schriever pre­sented to Gardner the entire air force approval process, which required 38 air force and DOD approvals or concurrences for the development of ICBM testing facilities. Appalled, Gardner had him show it to Secretary of the Air Force Donald Quarles, who asked them to recommend changes to reduce the paperwork and delays. Gardner and Schriever formed a study group, load­ing it, as Schriever put it later, ‘‘pretty much with people who knew and who would come up with the right answers.’’ Hyde Gillette, the deputy for budget and program management in the Office of the Secretary of Defense, chaired the group, which was to recommend management changes to speed ballistic missile development.59

Despite objections from AMC, which did not want to lose any more au­thority, the Gillette Committee agreed with Schriever that the multiple ap­provals and reporting lines caused months of delay. In consequence, the ‘‘Gillette Procedures,’’ approved by Secretary of Defense Charles Wilson on

Ballistic missile organization — Gillette Procedures. Solid lines with arrows show the direct chain of authority. The air force’s commands have no authority over ballistic missile development, and the Air Staff has input only through the Department of Defense Ballistic Missile Committee.

November 8,1955, funneled all ballistic missile decisions through a single Bal­listic Missile Committee in the Office of the Secretary of Defense. Although evading ARDC and AMC for approvals and decisions, Schriever’s organiza­tion needed to provide them information. Schriever stated: ‘‘We had to give them information because they provide a lot of support, you see, so it wasn’t the fact that we were trying to bypass them. We just didn’t want to have a lot of peons at the various staff levels so they could get their fingers on it.’’60 The Ballistic Missile Committee reviewed an annual ICBM development plan, and the Office of the Secretary of Defense would present, approve, and fund the ICBM program separately from the air force’s regular procedures. In the development plan would be information on programming (linking plans to budgets), facilities, testing, personnel, aircraft allocation, financial plans, and current status. By 1958, AMC managers had trimmed industrial facility lead time from 251 to 43 days, showing the effectiveness of the new process.61

The Gillette Procedures relegated AMC, ARDC, and the operational com­mands to aiding the ICBM program, without the authority to change or delay it. From a parochial air force viewpoint, the only good thing about the pro­gram was that the completed missiles would eventually become part of the Strategic Air Command. Many in the air force did not take ballistic mis­siles seriously enough to fight for control over them. Col. Ray Soper, one of Schriever’s trusted subordinates, noted that ‘‘the Ops [operational com­mands] attitude, at the Pentagon, was to let the ‘longhairs’ develop the sys­tem — they really didn’t take a very serious view of the ballistic missile, for it was thought to be more a psychological weapon than anything else.’’62

With the adoption of the Gillette Procedures, Schriever garnered authority directly from the president, with a single approval of a single document each year required for ICBM development. Schriever’s organization drew upon the best personnel and air force services, without having them interfere with his authority or decision processes. These new procedures represented the first full application of project management in the air force, where the project manager had both technical and budget authority for the project. Prior to this time, each project drew funds from several budgets and thus required separate justifications for each. The Gillette Procedures made the air force’s financial and accounting system consistent with the authority of the project manager, although Gardner was unable to separate the ICBM budgets from the rest of the air force.63 With these procedures in hand, Convair and the contractors under control, and the air force’s regular bureaucracy shunted out of the way, Schriever drove the ICBM program at full speed, with little heed to cost, using the strategy of concurrency.

The Inception of ESRO

The creation of ESRO began with the activities of Edoardo Amaldi, Italian physicist and one of the founders of the Conseil Europeen pour Recherche Nucleaire (CERN [European Committee for Nuclear Research]). In the sum­mer of 1958, after a conversation with his friend Luigi Crocco, a rocket pro­pulsion expert and professor in Princeton University’s Department of Aero­nautical Engineering, Amaldi proposed a European space program modeled on CERN. The new space organization should have high goals, Amaldi said, comparable to efforts in the United States and the Soviet Union, but have ‘‘no connection with whatsoever military agency.’’ He believed that it should be ‘‘open, like CERN, to all forms of co-operation both inside and outside the member countries.’’2

Amaldi learned from Crocco and from American aeronautical engineer Theodore von Karman some difficulties in modeling a European space orga­nization on CERN. Because the military had developed virtually all rockets, excluding the military would be difficult. Crocco also believed that it would be difficult to convince European parliaments to spend the huge sums necessary for space-based science research. Von Karman thought it necessary to include the military at the beginning to jump-start the civilian effort. He suggested working through the North Atlantic Treaty Organization. Amaldi demurred and eventually found a strong ally for his purely scientific space organization in his friend Pierre Auger, a French physicist and CERN ally.3

When Amaldi contacted Auger in February 1959, Auger was organizing the French Committee for Space Research. Auger was supportive ofAmaldi’s pro­posal and suggested the French organization as a model. French scientists and administrators were considering a two-phase program: a small initial effort based on sounding rockets, and a more ambitious program to include satel­lite launches and lunar or solar probes. After the two men met in April 1959,

Amaldi helped establish an Italian space research committee on the French model. Amaldi also sent a paper titled ‘‘Space Research in Europe’’ to promi­nent scientists and science administrators in Western Europe.4

These contacts led to an informal meeting of scientists from eight different countries at Auger’s Paris home in February 1960. At the next meeting, held in April 1960 at the Royal Society in London at the behest of the British National Committee for Space Research, the British presented their extensive space re­search plans and the possibility that the British government might offer the Blue Streak rocket as the basis for a European launcher. Auger hosted the next meeting in Paris in June 1960 to consider ‘‘A Draft Agreement Creating a Pre­paratory Commission for European Collaboration in the Field of Space Re­search.’’ 5 During the second Paris meeting, British delegates removed launch­ers from discussion because of negotiations under way between the British and French governments concerning the use of the Blue Streak. With launcher considerations eliminated, the scientists and scientific administrators focused on creating a European space research program using sounding rockets and satellites.6

Further discussions clarified the purpose and scope of ESRO and estab­lished goals for its initial scientific program and facilities. ESRO would sup­port space scientists throughout Europe. It excluded launch vehicles, although at the request of the Belgian delegation, it did include the development of sup­porting technologies. ESRO planners envisaged a two-phase effort: an initial program using sounding rockets, and a more advanced program of sophisti­cated scientific satellites.

Bruising negotiations determined the sites of ESRO facilities. To expedite coordination with ELDO, ESRO’s headquarters wound up in Paris. ESRO’s most important facility was its engineering unit to develop spacecraft and integrate scientific experiments, the European Space Technology Centre (ESTEC). Originally located in Delft, The Netherlands, ESTEC soon moved to the small coastal town of Noordwijk, north of The Hague. The telemetry data analysis center went to Darmstadt, West Germany, the sounding rocket range to Kiruna, Sweden, and a small science research center to Delft. A new sci­entific research center with ill-defined functions, located near Rome, satisfied Italian demands for an ESRO facility. In 1967 ESRO officials moved satellite tracking to Darmstadt, where combined with the data analysis center it be­came the European Space Operations Centre. ESRO established remote track­ing stations in Alaska, Norway, Belgium, and the Falkland Islands.7

European scientists originally conceived of ESRO as an organization run by scientists, for scientists, on the model of CERN. CERN provided an infra­structure for European physicists to perform experiments with particle accel­erators. In CERN’s organization, scientists determined the technical content of projects and infrastructure, and ran daily affairs. Administrators had little control over CERN’s funding, and significant overruns developed.

ESRO provided a similar service function to space scientists through provi­sion of sounding rockets, satellites, and data collection and analysis facilities. Scientists selected ESRO’s experiments, but, unlike in CERN, engineers devel­oped and operated the infrastructure. The British insisted on strong financial controls, ensuring that if ESRO overran its budget, it would cut projects in­stead of forcing governments into funding overruns.8 Because the founding scientists did not want ESRO’s scientific expertise to rival that of the member states, they restricted ESRO’s scientific research capabilities, making its engi­neering character more pronounced. ESRO’s engineering culture made it a very different organization from CERN.

Ten countries signed the ESRO Convention of June 1962: the United King­dom, France, Italy, West Germany, Belgium, The Netherlands, Sweden, Den­mark, Spain, and Switzerland. ESRO came into official existence on March 20, 1964, with Pierre Auger as secretary-general.

Applying the Systems Approach

By mid-1953, JPL’s continuing research in solid-propellant rocketry led to the conclusion that solid propellants could equal or exceed liquid propellants in performance as well as eliminate the cumbersome logistics of liquid-propelled missiles. Following up on this conclusion, Army Ordnance funded several studies, from which it selected JPL’s Sergeant. JPL managers and engineers stressed their recent recognition that missiles had to be viewed ‘‘as true sys­tem problems’’ that considered ground-handling equipment, operations, and training as well as technical improvements such as an improved guidance sys­tem and solid-propellant propulsion. Warning Army Ordnance about the dire consequences of making Sergeant a crash program, JPL Director Louis Dunn stated that ‘‘a properly planned development program’’ would ‘‘pay for itself many times over’’ by avoiding changes to production and operations.

Shortly after the army accepted JPL’s proposal, Dunn left to head Ramo – Wooldridge’s Atlas project. Corporal project manager William Pickering be­came JPL’s new director in August 1954. Pickering reorganized the laboratory to mirror academic disciplines on the Caltech campus.25

Even though he structured JPL on an academic model, Pickering recog­nized some of its limitations. Noting, ‘‘R&D engineers may not necessarily fully appreciate military field conditions,’’ Pickering assigned ‘‘certain person­nel a particular system responsibility as a sole task.’’ They performed studies of training, logistics, organization, and other factors to determine the ‘‘in­strumentation, training and schooling requirements, the caliber ofpersonnel requirements, and a typical Table of Organization for the missile battalion.’’26 Pickering assigned Robert Parks as project manager and Jack James as Parks’s deputy. James soon developed processes that would significantly change JPL’s management practices.

Jack James graduated from Southern Methodist University in 1942 and began his career at General Electric (GE) in Schenectady, New York. Starting by working on turbine engines, he soon transferred into the Test Engineering program, where he rotated through a number of laboratories and projects to gain experience. During World War II, he served as a navy radar officer on the battleship South Dakota. After the war, he returned to GE.

At GE, James worked for Richard Porter on the Hermes project to test-fire modified V-2 rockets. At the end of World War II, Porter had worked on the Paperclip project, which brought German rocket engineers and technicians to the United States, and Porter brought a number of the Germans with him to GE. GE developed the radar guidance system, and James worked with SCR – 584 radar systems, on which he ‘‘had the chance to make many mistakes.’’ In 1949, after the Research and Development Board picked JPL to manage the Corporal project, James moved to Pasadena. He had a ‘‘nightmare job’’ get­ting GE to deliver the guidance system, because GE had hoped to manage the project and had ‘‘lost heart in the job.’’ After Dunn left JPL, James helped complete Corporal.27

One of Corporal’s irritants was its lack of instrumentation for telemetry data. James, who was the project manager for the first two Sergeant flights, designed instrumentation into the new missile for testing and troop training, even though this added extra weight. Engineers could reconfigure telemetry equipment and measurements, depending upon the missile’s use for engineer­ing development, testing, or training — or for its final military purpose.28

Another of Corporal’s faults was horrendous reliability and maintenance. Sergeant incorporated the vibration testing established on Corporal for com­ponents. James also investigated the maintenance problem theoretically, to determine the best design, procedures, and supply inventories. He noted that some branches of the army recommended that suppliers create test equipment to isolate faulty components down to the piece-part level. In contrast, his analysis showed that small numbers of larger replaceable packages were more cost-effective. Because the army levied stringent reliability requirements, Ser­geant engineers developed a strict failure reporting system that required docu­mentation about how engineers would permanently repair each failure.29

To Pickering, Parks, and James, the systems approach meant including re­liability, testing, and maintenance early in the design process. Sperry Rand Corporation, which the army selected to manufacture Sergeant, created a sys­tems engineering program for test equipment. It consisted of formal and in­formal meetings and conferences, coordination of engineering changes, and the development of consistent testing, reliability, and maintenance methods at JPL and Sperry and in the army. Sergeant managers and engineers standard­ized environmental testing standards, safety procedures, component mount­ing practices, and maintenance procedures. They also separated testing into five major phases: feasibility flights, guidance system development, system development and integration, engineering model flights, and system proof tests.30

JPL used old and developed new organizational structures and procedures in its relationship with Sperry. Army Ordnance defined institutional arrange­ments, using JPL as the contractor responsible for technical research, devel­opment, and cognizance. Sperry was to manufacture the missile as the prime contractor, but not until it learned how to build the system as co-contractor with JPL. JPL engineers issued Technical Guidance Directions, and Sperry next provided cost estimates. With JPL’s approval, Army Ordnance officers then funded Sperry on a cost-plus-fixed-fee basis. The army required two re­views, a Design Release Inspection and a Design Release Review, both held early in 1959.31

Because of the planned transition from JPL to Sperry, James required that JPL engineers describe their designs in a series of documents that James sent to Sperry. This forced JPL engineers to synchronize design work to a fixed schedule and to produce consistent documentation. If an engineer was un­sure about how a design interacted or connected to a neighboring subsystem, that engineer would simply check the design document’s latest release. James also instituted a system of document change control so that engineers could not arbitrarily change their designs. Modifications would pass through James, who would ensure design and documentation consistency through a Research Change Order.32 This progressive design freeze, augmented with change con­trol, turned out to be one of the most significant organizational elements in the success of Sergeant.

Engineering changes were a prominent source of conflict between JPL and Sperry. Coordination between the two started in 1956, with Sperry assigning a number of engineers to work with JPL in Pasadena. In 1957, monthly co­ordination meetings that alternated between Pasadena and Sperry’s new Utah facility began. After negotiations with Sperry, JPL managers extended their Research Change Order system so that it governed engineering and produc­tion changes at JPL and Sperry. That same year, the two organizations cre­ated a biweekly Operational Scheduling Committee that initially governed the scheduling and preparations of test rounds but soon included broader coordi­nation and contractual issues. Continuing problems led to a project-based re­organization at Sperry, and both organizations established Resident Offices at each other’s facilities. The Sergeant Action Review Committee, formed in December 1959, reviewed all design changes, allowing only those that were mandatory.33

On Sergeant, JPL proved its capability as an army arsenal, with full capa­bility to design, develop, and oversee a missile from inception to operational deployment. JPL engineers developed the procedural expertise necessary to convert research technology into operational weapons, including reliability and maintenance, systems analysis, project scheduling and coordination, and phased planning. JPL Director William Pickering supported these systems methods, although he clung to an academic-style organization. Contractual relationships between the army, JPL, and Sperry led to the development of formal systems to report and respond to failures, and to progressively freeze and document the engineering design as it progressed. Jack James recognized their utility to coordinate diverse design activities and would apply them again on spacecraft projects, as JPL underwent its second major transforma­tion from an army arsenal to a National Aeronautics and Space Administra­tion (NASA) field center.

Management and the Control of Research and Development

Control. .. depends upon information and activities involving information: information processing, programming, decision, and communication.

— James Beniger, The Control Revolution, 1986

Since at least the Middle Ages, Western society’s fascination with sophisti­cated technology has demanded organizational solutions. By the middle of the nineteenth century, railroads in Europe and the United States required professional managers to run them.1 As the scale of operations increased, ex­ecutives developed “systematic management’’ to coordinate and control their midlevel personnel.2 At the beginning of the twentieth century, Frederick Winslow Taylor, publishing his major work in 1911, devised a means — by way of “scientific management’’ — of extending managerial influence to the fac­tory floors of increasingly large industrial enterprises.3 In both systematic and scientific management, information provided the levers that managers used to control their subordinates. Frequently working with engineers, managers gathered information from lower-level staff and then used that knowledge to reorganize work processes and control employees.4

Scientists and engineers eventually posed far more difficult challenges to managers. Universities trained these ‘‘knowledge workers,’’ as management consultant Peter Drucker referred to them in the late 1940s, to be dedicated to their careers and their specialties, not to their employers. They generated new ideas in an undefined process that no one could routinize, thus ruling out scientific management techniques. Their specialized knowledge placed them

beyond the competence of most managers. Even if technical personnel wanted to share their knowledge with managers (which they typically did not), they could not clearly describe their creative process. Only after the fact, it seemed, could managers control the products or the technologists who created them. Even so, managers seldom perceived research and development (R&D) man­agement as a critical issue.5 Drucker suggested a solution he called manage­ment by objectives. According to this approach, managers and professionals jointly negotiated the objectives for the agency or firm on the one hand and for the individuals on the other, each worker agreeing to the terms. Individu­als and agencies or firms would harmonize their respective goals.6

The management-by-objectives strategy worked reasonably well for man­agers overseeing individual knowledge workers, but it did little to coordi­nate the efforts of scientists and engineers on large projects, on which experts organized (or disagreed) along disciplinary lines and could form only tempo­rary committees for the exchange of information. Much like with the unique and short-lived Manhattan Project, the experience of complicated programs such as ballistic missiles demonstrated that traditional organizational schemes would not suffice. Scientists and engineers found that they needed some indi­viduals to coordinate the information flowing among working groups. These ‘‘systems engineers’’ created and maintained documents that reflected the current design, and they coordinated design changes with all those involved in the program. Perceptive managers and military officers realized that central design coordination allowed them to gain control of both the creative process and its lively if unruly knowledge workers.

This study examines how scientists and engineers created a process to coordinate large-scale technology development-systems management—and how managers and military officers modified and gained control of it. The story owes a debt to the insights of Max Weber, who noted long ago that modern organizations form standardized rules and procedures that create and sustain bureaucracies.7 Scholars since then have elaborated upon the develop­ment of these procedures as a process of ‘‘knowledge codification,’’ one that can be formally internal to individuals or informally contained in the com­munications between or among individuals.8 For organizations to learn, to adapt, and to sustain adaptations, they must have processes that are both flex­ible and durable. Recent scholarship on these so-called learning organizations has pursued and elaborated on this view, providing a perspective congenial to a historical analysis of management. By means of communication, feedback, and codification, organizations can be said to learn and retain knowledge.9

Systems management first developed in the air defense and ballistic missile programs of the 1950s, across many aerospace organizations. These programs, like any other large-scale technologies, came into being as a result of nego­tiations among various organizations, classes, and interest groups.10 Scientists typically created the core ideas behind new systems or the critical elements that made them possible or useful. Engineers developed the subsystems and integrated them into a complex vehicle. Military officers promoted these com­plex vehicles as a means of besting their Cold War foes. Managers controlled the resources required to produce the new systems. Systems management was embraced because it assigned each of these groups a standard role in the tech­nology development process. Systems management became the core process of aerospace R&D institutions, modeled largely on management techniques developed on army and air force ballistic missile programs. Methods devel­oped for air defense systems paralleled those for ballistic missiles, but in the bureaucratic battles of the early 1960s, ballistic missile officers and their meth­ods triumphed, forming the basis for the air force’s procurement regulations.11

This book thus traces a path through the literature on the history and poli­tics of aerospace development and weapons procurement.12 Instead of pro­viding another case study of a particular project or organization, it pieces together a story from elements that include military and civilian organizations in the United States and Europe. This approach has the distinct advantage of providing cross-organizational and cross-cultural perspectives on the sub­ject, as well as showing the dynamics of the transfer of management methods. NASA and the European programs encountered the same kinds of technical and social issues that the air force and the Jet Propulsion Laboratory (JPL) had previously come upon, and ultimately they looked outside of their orga­nizations to help resolve the problems. NASA looked to the air force (and to a lesser degree to JPL), and a few years later the Europeans gleaned their methods from NASA. The Apollo program became a highly visible icon of American managerial skill — the symbol of the difference between American technical prowess and European technical retardation in the 1960s and early 1970s.

European frustration reached its peak in 1969, when NASA put men on the Moon while the European Space Vehicle Launcher Development Organisation (ELDO) endured yet another failure of its launcher. ELDO only haphazardly adopted American management methods, and the lack of authority meant that those that ELDO did adopt could not be consistently implemented. The failures of ELDO ultimately proved to be the spur for the Europeans to over­come their historic hostilities and create a highly successful integrated space organization, the European Space Agency. This new agency and its predeces­sor, the European Space Research Organisation, borrowed extensively from NASA and its contractors. NASA’s management methods, when adapted to the European environment, became key ingredients in Europe’s subsequent successful space program. The air force, the army’s (and later NASA’s) JPL, NASA’s manned space programs, and the European integrated space pro­grams all learned that spending more to ensure success was less expensive than failure.

The modern aerospace industry is paradoxical. It is both innovative, as its various air and space products attest, and bureaucratic, as evidenced by the hundreds of engineers assigned to each project and the overpriced compo­nents used. How can these two characteristics coexist? The answer lies in the nature of aerospace products, which must be extraordinarily dependable and robust, and in the processes that the industry uses to ensure extraordinary dependability. Spacecraft that fail as they approach Mars cannot be repaired. Hundreds can lose their lives if an aircraft crashes. The media’s dramatization of aerospace failures is itself an indication that these failures are not the norm. In a hotly contested Cold War race for technical superiority, the extreme envi­ronment of space exacted its toll in numerous failures of extremely expensive systems. Those funding the race demanded results. In response, development organizations created what few expected and even fewer wanted—a bureau­cracy for innovation. To begin to understand this apparent contradiction in terms, we must first understand the exacting nature of space technologies and the concerns of those who create them.

ONE

Smoke, Fire, and Recovery

Apollo’s troubles began in September 1965, when NAA’s second stage rup­tured during a structural test.91 Engineers pinpointed the fault, and in the process MSFC managers concluded that NAA’s management was to blame for shoddy workmanship. By October, the Industrial Operations manager, Brig. Gen. Edmund O’Connor, told von Braun, ‘‘The S-II program is out of con­trol.’’ He believed its management was to blame. O’Connor was equally blunt in a letter to Space and Information Systems Division (S&ID) President Har­rison Storms: ‘‘The continued inability or failure of S&ID to project with any reasonable accuracy their resource requirements, their inability to identify in a timely manner impending problems, and their inability to assess and re­late resource requirements and problem areas to schedule impact, can lead me to only one conclusion, that S&ID management does not have control of the Saturn S-II program.’’92

Phillips went immediately to NAA with a ‘‘tiger team’’ of nearly one hun­dred NASA personnel to ‘‘terrorize the contractor,’’93 reporting the team’s

Apollo with its major contractors identified. Apollo was perhaps the largest single R&D project of all time, integrating many contractors for its stages and requiring massive launch and operations facilities and organizations. Saturn V contractors not identified. Courtesy NASA.

findings in December 1965 in what later became known as the Phillips Re­port. While writing to NAA that ‘‘the right actions now’’ could improve the program, Phillips privately wrote Mueller that NAA’s president was too pas­sive. Storms, Phillips said, should ‘‘be removed as president of S&ID and be replaced by a man who will be able to quickly provide effective and unques­tionable leadership for the organization to bring the division out of trouble.’’94

NAA responded by placing Gen. Robert Greer, retired from the air force, in charge of the S-II program. Greer updated the management control cen­ter and ensured more rapid exchange and collection of information through Black Saturday meetings modeled after those in Bernard Schriever’s ballis­tic missile program. Greer also instituted forty-five-minute meetings every morning, eventually cutting back to twice a week. Greer’s reforms began to take hold but did not prevent the May 1966 loss of another test stage because of faulty procedures. NASA clamped down further, requiring NAA to develop better methods for managing and planning its work. In the summer of 1966, after two years of studies and preparation, NAA deployed work package man­agement for the S-II and Command and Service Module.95

Work package management extended project management to lower project levels and combined accounting and contracting procedures by creating a specific work package for each program task. The company assigned respon­sibility for each task to one person, a mini project manager for the task who accounted for performance, cost, and schedule in the same way and with the same tools as the overall project manager. Each work package was a ‘‘funda­mental building stone,’’ with specifications, plans, costs, and schedules to help managers in their monitoring. Prior to the development of work packages, ‘‘It was difficult to say what manager was responsible for a particular cost increase because there were 10 or 15 functional and subcontractor areas involved.’’96 In later versions, the work package numbering scheme matched that for cost accounting.

Grumman’s difficulties on the lunar module also attracted NASA attention. Troubles first appeared in schedule slips on its ground support equipment in the spring of 1966. Alarmed at Grumman’s growing costs, Phillips sent a management review team to Grumman that summer, prompting Grumman to sack the program manager, establish a program control office, and move Grumman’s vice president to the factory floor to monitor work. By fall, NASA pushed Grumman into adopting work package management.97 It did not im­mediately solve Grumman’s difficulties. The primary problem was a late start due to NASA’s delayed decision to use lunar orbit rendezvous. However, work package management and the new program control office found and resolved problems more quickly than before.

Despite these difficulties, Apollo moved briskly forward until its most se­vere crisis struck on January 27,1967. That day, astronauts and KSC personnel were performing tests in preparation for launch of the first manned Apollo mission. At 6:30 that evening, the three astronauts scheduled for that mis­sion, Virgil Grissom, Edward White, and Roger Chaffee, were in the spacecraft command module testing procedures. At 6:31, launch operators heard a cry from the astronauts over the radio, ‘‘There is a fire in here!’’ Those were their last words. All three astronauts died of asphyxiation before launch personnel reached them.98

KSC personnel immediately notified NASA headquarters. Administrator Webb hurriedly planned for the political fallout. He sent Seamans and Phillips to Florida, while he persuaded the president and Congress to let NASA per­form the investigation.99 NASA’s investigation concluded that the causes of the disaster were faulty wiring, a drastic underestimation of the dangers of an all-oxygen atmosphere, and a capsule design that precluded rapid escape. No one had realized how dangerous the combination was. NASA had used a pure oxygen atmosphere in all of its prior flights, as did air force pilots in their high-altitude flying. As Col. Frank Borman, one of NASA’s most experi­enced astronauts, put it during the Senate investigation, ‘‘Sir, I am certain that I can say now the spacecraft was extremely unsafe. I believe what the message I meant to imply was that at the time all the people associated and responsible for testing, flying, building, and piloting the spacecraft truly believed it was safe to undergo the test.’’100

Congress did not prove NASA to be negligent or incompetent. One of the investigation’s important results was a nonfinding. Despite searching long and hard, Congress did not find fault with Phillips’s management system. Phillips had already uncovered problems with NAA and had been working for some time to make improvements to its organization and performance. The management system used to organize the capsule design was NASA’s original

committee-based structure, upon which Phillips had superimposed configu­ration management. He and his management system came out unscathed.

Congressional investigations did uncover some of NASA’s dirty laundry, particularly problems with command module contractor NAA. Sen. Walter Mondale of Minnesota learned of the Stage II Phillips Report and confronted Webb about problems between NASA and NAA. Caught by surprise, Webb said he did not know of any such report, which at that moment he did not. After the hearing, he found out about it from Mueller and Phillips. Furious, Webb launched a ‘‘paper sweep’’ to search for more skeletons in the closet. The sweep uncovered a memo written by GE to Apollo spacecraft director Joseph Shea, warning Shea of the danger of fire in the command module. Shea had passed the memo on to his safety and quality assurance people, who re­sponded that no significant dangers existed. GE, already in a sensitive situa­tion because MSC considered it to be spying for headquarters, did not push it any further.101

Webb reacted angrily to these revelations. He believed OMSF had been far too independent and secretive. Webb told Seamans, ‘‘You have to penetrate the [OMSF] system, don’t let Mueller get away with bullshit.’’ The problem, according to Webb, was a lack of supervision by NASA’s executive manage­ment. Mueller had ‘‘followed the policy in Houston of obtaining the very best men they could for the senior positions, and had, as a part of the process of obtaining them, given assurances that they would have almost complete free­dom in carrying out their responsibilities.’’102

After Seamans left NASA in late 1967, Webb expressed shock at the poor management system.103 Webb probably did not realize how decentralized NASA’s management really was. Executive managers routinely delegated most decisions to lower levels. In the wake of the fire, this did not seem wise.

When NAA refused to make swift and comprehensive changes — and even expected to be paid a fee for the burned-out spacecraft—Webb called Boe­ing to see if it would take the job. Boeing said that although it did not want to take over the job, if pressed it would do so. Webb returned to NAA, de­manding that it remove S&ID head Storms, further centralize Apollo project management, eliminate any fee for the failed spacecraft, and pay for improve­ments. NAA did not take the chance that he was bluffing. NAA was extremely unhappy with the entire situation because from its viewpoint, NASA was at fault. Shortly after contract award, over NAA’s objections, NASA had directed a change from a nitrogen-oxygen atmosphere to an all-oxygen atmosphere.104

One problem uncovered during the investigation was GE’s unwillingness to contest NASA over safety issues with a pure oxygen atmosphere. At the heart of the problem was industry’s reluctance to confront NASA when indus­try was dependent on government funding. Despite his substantial political acumen, Webb appeared not to comprehend this. He had hired GE and Bell – comm to strengthen headquarters’ ability to monitor the field centers in 1962; after the fire, Webb repeated his mistake by expanding Boeing’s role from integrator of the Saturn V to integrator of the entire Apollo-Saturn system to ‘‘penetrate the OMSF system.’’ Phillips, who understood the political prob­lems inherent in the GE and Boeing integration efforts, revised the Boeing contract to avoid the negative consequences of Webb’s misconception.105 In essence, Webb wanted to use GE, Bellcomm, and Boeing as an arm of NASA headquarters to control MSC, MSFC, and KSC. This could not work because these contractors could not challenge NASA field center personnel for fear of losing their contracts.

Boeing, as part of its contract, further integrated the management system. The ‘‘teleservices network’’ connected NASA project control rooms with hard copy data transmittal, computer data transmission, and the capability to hold a teleconference involving MSC, MSFC, KSC, Michoud (where the Saturn I was manufactured), and Boeing’s facility near Seattle. Boeing copied MSFC’s program control center design at each facility.106

After the fire, NASA placed even more emphasis on achieving high quality and safety through procedural means. In September 1967, NASA set up safety offices at each field center, along with the first project safety plan. The next month, MSC established a Spacecraft Incident Investigation and Reporting Panel to look into anomalies. A month later, NAA created a Problem Assess­ment Room to report and track problems.

Phillips ordered an astounding array of program reviews to prepare for Apollo’s upcoming missions. He wrote to field center managers to ensure that they used the upcoming Design Certification Reviews to evaluate all potential single-point failures.107 In January 1968, he ordered a complete system safety review, analyzing the interaction of the mission with the hardware, astronauts, ground systems, and personnel. Other reviews included those for quality and metrology, launch vehicle and spacecraft schedules, the communications net­work, flight readiness, mission planning, subcontractors, site selection, the Lunar Receiving Laboratory, flight evaluations, anomalies, crew safety, inter­face management, software, and lunar surface activities.108

NAA’s procedures exemplified the upgraded problem reporting system. Engineers reported failures on a Problem Action Record form. Reliability engineers sent failed components to the appropriate organization, which re­sponded by filling out a Failure Analysis Report describing the physical cause of the failure and the corrective actions taken or recommended. If the orga­nization determined that an engineering change was necessary, it submitted a change request to the change boards. The program control center tracked report status, and a centralized reliability ‘‘data bank’’ recorded the problem and its resolution. Follow-up failure reports and dispositions closed all failure reports.109

Another change in the aftermath of the fire was a further strengthening of configuration management, primarily through changing CCB operating pro­cedures. An October 1967 rule disallowed nonmandatory changes for the first command and lunar modules and required the MSC Senior Board to rule on any and all changes to these spacecraft. A February 1968 ruling required man­agers to consider software changes and their ramifications in CCBs. In May 1968, Apollo Spacecraft Manager George Low specified that the MSC CCB had authority over all design and manufacturing processes.110

By 1968, tough CCB rules slowed the program as trivial changes came to the attention of top managers. Eventually, even Phillips realized that central­ization through configuration management could go too far. In September, MSC managers classified changes into two categories: Class I changes, which MSC would pass judgment upon, and Class II changes, which could be ap­proved by the contractors. Classification did not by itself help much, so in October 1968 Phillips gave Level II CCBs more authority, while higher levels ruled on schedule changes.111

The Apollo project met its technical and schedule objectives, landing men on the Moon in July 1969 and returning them safely to Earth. Anchored by configuration management, Phillips’s system weathered the storm of prob­lems uncovered through testing and Apollo’s most severe crisis, the 1967 death of the three astronauts and the ensuing investigations. Despite strenuous ef­forts, congressional critics did not find many flaws with Phillips’s manage­ment scheme and concurred with NASA that the fire resulted from a tragic underestimation of the danger.

Configuration management was Phillips’s most powerful tool. Whenever problems occurred, his almost invariable response was to strengthen configu­ration management. Having found that his favorite method could be over­used, by the end of 1968, Phillips gave lower-level CCBs more authority. Con­figuration management formed the heart ofApollo’s system and has remained at the core of NASA’s organization ever since.

Concurrency

Rapid development of ICBMs required parallel development of all system ele­ments, regardless of their technological maturity. Schriever called this con­currency, a handy word that meant that managers telescoped several typically serial activities into parallel ones. In serial development, research led to ini­tial design, which led to prototype creation, testing, and manufacturing. Once the new weapon was manufactured, the operational units developed main­tenance and training methods to use it. Under concurrency, these elements overlapped. Schriever did not invent the process but rather coined the term as a way of explaining the process to outsiders.64

Schriever’s version of concurrency combined concepts learned over the previous decade. Parallel development had been practiced during World War II on the Manhattan and B-29 projects. Management structured around the product instead of by discipline had also been used on these projects. The combination of ARDC and AMC officers into a project-based office was a method applied since 1952, and Schriever’s use of R-W to perform systems analyses like the Atlas’s nose cone design had also been foreshadowed by the RAND Corporation’s development of systems analysis after World War II. Schriever claimed that concurrency was a new process. But was it?

One difference was that in the 1950s parallel development, once a wartime expedient, became a peacetime activity. With Congress exercising detailed oversight typical of peacetime, Schriever had to explain his processes in more detail than his wartime predecessors had. As Secretary of the Air Force James Douglas later told Congress, ‘‘I am entirely ready to express the view that.. . you have to subordinate the expenditure… to the urgency of looking to the end result.’’ Or as Gardner succinctly stated, ‘‘We have to buy time with money.’’ The term ‘‘concurrency’’ helped explain and justify their actions to higher authorities.65

A second major difference was in the nature of the technologies to be inte-

Concurrency. Adapted from Benjamin N. Bellis, L/Col USAF Office DCS/ Systems, ‘‘The Requirements for Configuration Management During Con­currency,” in AFSC Management Conference, Air Force Systems Command, Andrews Air Force Base, Washington, D. C., AFHRA Microfilm 26254, 5-24-3.

grated into ICBMs. In pre-World War II bombers, for example, engineers simply mounted machine guns at open side windows. However, with the B-29 bomber, and for postwar aircraft, operators maneuvered machine guns with servomechanisms within a pressurized bubble, itself part of the airframe. Similarly, missiles had to be built with all elements planned and coordinated with each other from the start. Postwar weapons were far more complex than their prewar counterparts and more complex than the nuclear weapons of the Manhattan Project. Concurrency in the Cold War required far more detailed planning than previous concurrent approaches.

One application of concurrency was in selection of contractors for Atlas, and then for Titan and Thor. R-W performed the technical evaluations and gave input to ad hoc teams of WDD and SAPO personnel. The AMC-ARDC committees selected which companies they would ask to bid, evaluated the bids, and selected a second contractor for some subsystems. Selecting a con­current contractor increased chances of technical success, stimulated better contractor performance by threatening a competitive contract if the first con­tractor performed poorly, and kept contractors working while the air force made decisions. To speed development, the SAPO issued letter contracts, de­ferring contract negotiations until later. In January 1955, the SAPO formal­ized the ad hoc committees, which became the AMC-ARDC Source Selection Board.66

To maximize flexibility and speed, Schriever initially organized the WDD with disciplinary divisions modeled on academia. Only in 1956 did the pro­liferation of projects lead him to create WSPOs for each project, consisting of AMC and ARDC representatives, as required by the weapon system con­cept. Until that time, most work occurred through ad hoc teams led by officers to whom Schriever had assigned the responsibility and authority for the task at hand. For example, when the WDD began to develop design criteria for facilities in March 1955, Schriever named Col. Charles Terhune, his technical deputy, ‘‘team captain’’ for the task. He also requested that R-W personnel as­sist. Terhune then led an ad hoc group to accomplish the task, and that group dissolved upon task completion.67

The fluid nature of the ad hoc groups and committees may well have maxi­mized speed, but they also played havoc with standard procedures of the rest of the air force, which after all had to support ICBM development. Schriever initiated a series of coordination meetings with AMC, Strategic Air Com­mand, air force headquarters, and other commands in December 1954. After the December meeting, the AMC Council decided it needed quarterly reports from the WDD to keep abreast of events. Over the next six months, AMC planning groups bickered with WDD personnel over reporting and support, as AMC needed information for personnel and logistics planning. AMC tried to plan tasks from Wright Field, whereas the WDD (and soon the SAPO) ac­complished planning rapidly on-site, with little documentation or formality. AMC accused the WDD of refusing to provide the necessary data, whereas the WDD accused AMC officers of a lack of interest.

Disturbed because Schriever’s crew had neither WSPOs nor Weapon Sys­tem Phasing Groups (normally used to coordinate logistics), AMC had some reason to complain. As stated by the assistant for development programming, Brig. Gen. Ben Funk, ‘‘The normal organizational mechanisms and proce­dures for collecting and disseminating weapon system planning during the weapon system development phase did not exist,’’ leading to gaps in the flow of information necessary for coordination. By the summer of 1955, SAPO per­sonnel at the WDD made concerted efforts to pass information to AMC head­quarters and to bring AMC planning information into the WDD.68

Schriever’s need for speed led to extensive use of letter contracts through 1954 and 1955. Procurement officials in the SAPO and technical officers in

the WDD realized that they needed to track expenditures relative to technical progress, but the rapid pace of the program and the lack of documentation quickly led to a financial and contractual morass. Complicated by the WDD’s lack of personnel and the new process of working with R-W to issue technical directives, contractual problems became a major headache for the SAPO and AMC and another source of friction between Schriever and AMC leaders.69

The SAPO had authority to negotiate and administer contracts but initially lacked the personnel to administer them over the long term. Instead, SAPO personnel reassigned administration to the field offices of other commands ‘‘through special written agreements.’’70 This complicated arrangement led to trouble. Part of the problem was the difficulty of integrating R-W into the management of the program. R-W had authority to issue contractually bind­ing ‘‘technical directives’’ to the contractors, but instead of using these, R-W personnel sometimes ‘‘used the technical directive as a last resort, preferring persuasion first through either periodic meetings with contractor person­nel or person-to-person visits between R-W and contractor personnel.’’ This meant that many design changes occurred with no legal or contractual docu­mentation. Because officers in the SAPO did not have enough personnel to monitor all meetings between R-W and the contractors and were not initially included in the ‘‘technical directive coordination cycle,’’ matters soon got out of hand.71

This problem emerged during contract negotiations, as SAPO procure­ment officers and the contractors unearthed numerous mismatches between the official record of technical directives and the actual contractor tasks and designs. As differences emerged, costs spiraled upward, leaving huge cost overruns that could not be covered by any existing or planned funding. A committee appointed to investigate the problem concluded in June 1956 that ‘‘almost everyone concerned had been more interested in getting his work done fast than in observing regulations.’’ It took the committee some­what more than six months to establish revised procedures acceptable to all parties.72

The initial application of concurrency in Schriever’s triad of the WDD, the SAPO, and R-W sped ICBM development but also spread confusion, dis­rupted communications with other organizations, and created a mountain of contractual, financial, and, as we shall see, technical problems. Flexible com­mittees flicked in and out of existence, while supporting organizations out­side of Schriever’s group struggled to acquire the information they needed to assist. The strategy of parallel development, separated from the air force’s normal routine, produced quick results, but the mounting confusion begged for a stronger management scheme than ad hoc committees.

Conclusion

World War II and the Cold War enabled the military to consolidate and ex­tend its relationships with both academia and industry. When in 1947 the Pro­curement Act gave the DOD the permanent authority to negotiate contracts, military officers enlisted the support of academia and industry. Air force offi­cers such as Hap Arnold, Donald Putt, and Bernard Schriever used scientists to create a technologically competent and powerful air force. Two models for relationships between the air force and the scientists evolved. First, RAND, the SAB, and the RDB continued the voluntary association of scientists with the military, as had occurred in World War II. However, the DCS/D and ARDC represented new air force efforts to gain control over the scientists through a standard air force hierarchy. Both models would continue into the future. Through these organizations and their personnel, air force officers hoped to develop the air force of the future.

When ICBMs became a possibility in late 1953, Schriever capitalized on his scientific connections, urging John von Neumann to head the Teapot Com­mittee, which recommended that ICBMs be developed with the utmost speed and urgency. While Schriever and Assistant Secretary of the Air Force Trevor Gardner maneuvered behind the scenes to promote ICBMs, the Teapot Com­mittee recommended the creation of a scientific organization on the Los Ala­mos model to recruit scientists to run the ICBM program. Unsure of the in­dustry’s capability to develop the Atlas ICBM, Schriever and Gardner hired R-W to serve as the technical direction contractor, an adviser to air force offi­cers, and a technical watchdog over the contractors.

Feeling bogged down in ‘‘Wright Field procedures,’’ external approvals, and funding difficulties, Schriever and Gardner appealed to President Eisen­hower to break the logjam. The president complied, and so Schriever, armed with a presidential directive, hand-picked a committee to develop procedures that gave him the authority to acquire the services he needed from the air force without having to answer to the air force. The Gillette Procedures carved out a space in which Schriever, his officers, and scientific allies could craft their own development methods, largely separated from the air force’s standard processes.

Under ‘‘concurrency,’’ Schriever’s complex of the WDD, the SAPO, and R-W created and adopted a number of methods to speed ICBM development. With funding a nonissue, these organizations and their contractors tossed aside standard regulations and developed alternate technical systems such as the Titan ICBM to ensure success. The air force’s regular methods, based on academic-style disciplinary groups, no longer sufficed. Schriever broke away from dependence on Wright Field’s technical groups and committees, but in the first years of ICBM development, he merely substituted his own officers and contractors, unencumbered by paperwork. The WDD, the SAPO, and R-W recreated an ICBM-oriented Wright Field on the West Coast, albeit with­out the years of history and bureaucracy.

The proof of their efforts would come when ICBM testing began in the late 1950s. As long as the Cold War remained hot and his scientific friends de­livered technical success, Schriever could sustain concurrency. Unfortunately, tests would show that these new wonder weapons had major problems. Under these circumstances, politicians and managers would rein in the rapidly mov­ing ICBM programs, replacing Schriever’s all-out concurrency with a new, centralized bureaucracy that incorporated some of the key lessons of ICBM development.

THREE