Category The Secret of Apollo

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

From the beginning of the WDD, aircraft industry leaders complained bit­terly about R-W’s insider position. They believed that the ideal approach to weapons development was for the air force to let prime contracts to a single integration contractor, a position supported by the air force’s own regulations. These stated that the air force should hire a single prime contractor to de­velop, integrate, and test a weapon system, unless no company was qualified to perform the task. In this case, the air force itself could act as prime con­tractor. The latter position was Schriever’s justification for his approach to the ICBM program, with the important modification that the air force would in­stead hire a third party to direct technical coordination of the integration task. Industry leaders also pointed out that in R-W, the air force was creating a new, powerful competitor with close ties to air force planning and a concomitant edge in bidding.48

Normally, R-W should have been controlled by the air force in the way that any other contractor would have been. However, the air force had hired R-W to act as the air force’s technical assistant for ICBM development, in which position R-W personnel acted with virtually the same authority as the govern­ment. In 1954, Assistant Secretary of Defense for Research and Development Donald Quarles, formerly of Bell Labs, had insisted that R-W personnel be given “line” responsibility, with full authority to direct contractors, instead of “staff” status, where they would merely be advisers. This mirrored his experi­ence at Bell Labs, which acted as the technical direction authority to AT&T’s manufacturing arm, Western Electric. Bell Labs also performed this role with other contractors, sometimes on behalf of the government on high-priority military programs. This powerful position required that AT&T acquire sensi­tive data from other companies. As a regulated monopoly, AT&T could legiti­mately act in this capacity, as it essentially had no competitors.49

Caltech’s JPL and MIT’s Radiation Laboratory also acted as technical di­rection groups for the government, but these academic nonprofit institutions were little threat to industry. However, R-W was neither a nonprofit insti­tution nor a regulated monopoly, and in fact it competed for other projects against the same companies that it monitored on the ICBM program. Existing aircraft firms vigorously campaigned against the air force’s unusual relation­ship with the upstart company.

To protect his organization from criticism, Schriever enforced a hardware ban on R-W to keep it from acquiring lucrative hardware contracts on any programs in which it was the technical direction contractor. R-W ‘‘walled off’’ the technical direction work of STL from the rest of the company. Continuing concerns led R-W to establish a physically separate location for its headquar­ters — in Canoga Park, California. These measures did not satisfy industrial leaders, who continued to lobby against the company.50

Despite the clamor and the ICBM hardware ban, neither Ramo nor Wool­dridge believed that R-W could grow without manufacturing capabilities. They grasped every opportunity to expand manufacturing by aggressively pursuing hardware production products and contracts outside the ballistic missile program. These included process control computers, semiconductors, and a variety of aircraft and air-breathing missile components. Aggressive pursuit of hardware contracts paid off, as R-W received permission to build ballistic missile hardware to test ablative nose cones built by General Electric. Strongly backed by Schriever’s technical director, Col. Charles Terhune, STL then built the Able 1 lunar probe launched in August 1958 and the Pioneer 1 spacecraft launched by the National Aeronautics and Space Administration (NASA) in October 1958. These activities fomented even more severe indus­trial protests, as the hardware ban against R-W evaporated.51

Expansion on these and other ventures such as semiconductors stressed R-W’s finances. Ramo and Wooldridge leaned on their original investor, Thompson Products, for cash to expand facilities and capital equipment, and the ensuing negotiations led to an agreement that resulted in the merger of the two companies effective October 31,1958. The new combination, Thompson- Ramo-Wooldridge (TRW), became the aerospace giant that the older aircraft companies had feared.

TRW executives recognized the awkward position of STL in the new com­pany. STL handled TRW’s space business, including both the technical di­rection tasks for the air force and STL’s budding space manufacturing busi­nesses. Because of the air force connection, STL would always be vulnerable to charges of conflict of interest. To minimize this risk, TRW executives estab­lished STL as an independent subsidiary corporation with its own board of directors chaired by Jimmy Doolittle, a war hero with impeccable creden­tials and impressive ties to the air force and NASA. No TRW board member or senior manager sat on STL’s board. TRW executives recognized that they might have to divest STL, and through this reorganization they were prepared to do so.52

Although TRW was prepared to divest STL, neither Schriever nor TRW really wanted this to happen. TRW enjoyed significant profits from STL, and Schriever wanted STL’s experienced personnel directing the technical aspects of the air force’s ICBM and space programs. However, STL’s increasing in­volvement with space projects and hardware development fueled industry complaints, leading to congressional hearings in February and March 1959.

These hearings, chaired by Rep. Chet Holifield from California, featured vehement attacks against STL’s ‘‘intimate and privileged position’’ with the air force and equally strong defenses by Schriever and by TRW executives Simon Ramo and Louis Dunn. It became clear even to Schriever that as long as TRW acquired competition-sensitive technical information from other aerospace firms through STL, the clamor would continue. A plan to sell STL to pub­lic investors fell through when Air Force Secretary Douglas vetoed it on the grounds that STL would remain a problem as long as private owners used STL to make a profit. The Holifield Committee’s final report seconded this idea and urged that STL be converted into a nonprofit corporation like RAND and MITRE. Schriever reluctantly agreed, leading to the formation of The Aero­space Corporation on June 4,1960.53

At Schriever’s insistence, STL continued systems engineering and technical direction for the ballistic missile programs for the near future, but all others transferred to Aerospace. Dr. Ivan Getting became Aerospace’s first presi­dent, and a number of STL personnel transferred to the new corporation. This ended the controversy about TRW’s insider position with the air force, but as industry had feared, there was a powerful new competitor with which to contend. Aerospace became one of a growing breed of nonprofit corporations that served the air force and other military organizations.

Systems engineering, which required the coordination of all elements of the technical system, could be performed by a prime contractor for the sys­tem, by the air force itself, or by a nonprofit firm that had no interest in com­petition. The experience of R-W showed that a profit-making corporation could not act on behalf of the U. S. government to coordinate or control the efforts of its competitors. The function of systems engineering had to be con­tained within the government itself, a neutral third party hired by the gov­ernment such as Aerospace or MIT, or a prime contractor. With this contro­versy settled, the air force could now standardize systems management as its primary R&D method across all of its divisions.54

Standardizing Systems Management

By 1959, ongoing deliberations at air force headquarters were under way re­garding the applicability of Schriever’s ‘‘Inglewood model’’ to the rest of the air force’s development programs. A senior committee headed by the AMC commander, Gen. Samuel Anderson, agreed that the air force should adopt the methods used in Inglewood, with the planning and implementation of new projects on a systems, or ‘‘life cycle,’’ basis. Planning for the entire system would occur up front, and project offices would have the authority to man­age development, including funding authority. However, the committee split into three camps regarding the organization, advocating positions ranging from minor modifications to radical reorganization. In June 1960, the Air Staff selected the least ambitious plan, which did include installation of new regu­lations based on Schriever’s organizational processes, to be used on all the air force’s major development programs.55

The 375-series regulations for systems management originated with one of Schriever’s officers, Col. Ben Bellis, who headed an effort to document the procedures developed in Inglewood. After a series of reviews, the new regula­tions for systems management appeared on August 31,1960, and were applied to the air force’s major projects for missiles, space, aeronautics, and electron­ics. Subsequently revised and extended, these regulations became the institu­tional backbone of the new, Inglewood-inspired R&D system.56

Under the new regulations, the system program director gained significant authority. The air force required that the program director create and gain approval of a single document known as the System Package Program. Each System Package Program provided information on cost, schedule, manage­ment, logistics, operations, training, and security.57 The 375 regulations for­mally applied the ARDC-AMC project office concept across all air force major acquisition programs.

The more radical ‘‘Schriever Plan’’ to manage the air force’s R&D had been shelved by Anderson’s committee in 1959, but it gained new life in 1961 when Robert McNamara became secretary of defense. McNamara, trying to resolve the controversy over which service should gain the coveted military space mission, looked for evidence of managerial and organizational expertise to determine which service should lead space efforts. With several hints from the McNamara camp that the Schriever Plan would help the cause, Air Force Chief of Staff Thomas White approved it. Secretary of the Air Force Eugene Zuckert and McNamara signaled their pleasure by conferring all space research to the air force in March 1961.58

The Schriever Plan reallocated the procurement activities ofAMC to a new organization that also included the development functions of ARDC. ARDC was abolished, its place taken by Air Force Systems Command (AFSC), which came into being on April 1, 1961. Schriever, appointed the first commander of AFSC, now managed all of the air force’s major development programs in four divisions: the Ballistic Systems Division in San Bernardino, California; the Space Systems Division in El Segundo, California; the Aeronautical Systems Division in Dayton, Ohio; and the Electronics Systems Division in Lexington,

The air force’s Ballistic Systems Division and Thompson-Ramo-Wooldridge’s Space Technology Laboratory were in the center of a vast network of government and industry organizations, all of which learned aspects of systems management. ‘‘BSQ’’ represents the Ballistic Systems Division, and ‘‘SE/TD’’ stands for systems engineering and technical direction, the main function of STL. Courtesy Library of Congress.

Massachusetts. Ascending to command over all of the air force’s large acqui­sition programs, Schriever’s presence ensured the spread and enforcement of the 375 procedures.59

Standardization of R&D in AFSC went beyond the 375 regulations. By mid – 1961, Schriever’s organization molded status reporting into a highly sophisti­cated system, known as rainbow reporting because it presented each element of the system on pages of different colors in a small, brightly packaged book­let. Over the next few years, the rainbow reporting system evolved to include yearly and monthly milestone schedules, government and contractor finan­cial data, contractor manpower data, reliability data, procurement data, engi­neering qualification data, and the so-called PRESTO procedures for prob­lems needing immediate attention. They also specified acceptable formats and technologies for presentations to ensure commonality, helping the top-level managers to judge the programs on a consistent basis.60

With the establishment of AFSC, the Inglewood model of systems man­agement, including configuration management, became the dominant model for large-scale programs. In April 1961, Schriever’s authority and influence reached its apex, as he presided over all major development programs in the air force, using standardized methods of his own making.61 What Schriever and others did not foresee was that just as the air force could use systems man­agement to control contractors and its own officers, so too could the DOD use it to control the air force.

McNamara, Phased Planning, and Central Control

Within the DOD, the Office of the Secretary of Defense grew in power from 1947 to the mid-1960s. Over the years, the office progressively pulled critical decisions up the hierarchy, subordinating service interests and rivalries. Bene­fiting and exploiting this trend to the fullest was John F. Kennedy’s appointee to the office, Robert McNamara.62

McNamara trained at the University of California, Berkeley, and taught business courses for a short time at Harvard before World War II. During the war, he performed statistical analyses for army logistics, determining the quantities of replacement parts needed based upon statistical assessments of combat and operations. After the war, he joined Ford Motor Company, tagged as one of the mathematically trained ‘‘whiz kids’’ that reformed Ford’s dis­organized finances and helped turn the company around. He rose quickly, eventually becoming president.63

Famous for his faith in centralized control implemented through quantita­tive measurement, McNamara took advantage of the authority granted to the Office of the Secretary of Defense by the Defense Reorganization Act of 1958. This act gave the secretary of defense the authority to withhold funding from the services and transfer assignments between the services. Upon his appoint­ment to the office, in the spring of 1961 McNamara initiated a series of more than 100 studies known as McNamara’s 100 trombones, or the 92 labors of Sec­retary McNamara. The services readily complied with this request, expecting the novice secretary to get bogged down in conflicting piles of recommenda­tions.64

Without waiting for completion of the studies, McNamara also installed RAND chief economist Charles Hitch as the DOD comptroller. Given McNa­mara’s background as a Ford financial manager and Hitch’s qualifications as an economist, it was not surprising that they considered economic criteria to be foremost in making decisions for future weapon systems. Hitch’s Pro­gram Planning and Budgeting System required that life cycle cost estimates be performed before deciding whether to develop a new weapon system. This agreed with the result of one of McNamara’s studies — “Shortening Develop­ment Time and Reducing Development and Systems Cost’’—which claimed that ‘‘reducing lead time and cost’’ should be given the same priority as im­proving performance. It deemphasized the relentless push to higher technical performance and required that feasibility and effectiveness studies calculate technical risks and cost-to-effectiveness ratios.65

Following up on this study, in September 1961 McNamara assigned the task of improving R&D management to John Rubel, the deputy director of defense research and engineering. Rubel established model programs whose methods could then be copied throughout all of the services, starting with the air force Agena, TFX fighter, Titan III, and medium-range ballistic missile programs. Rubel required a ‘‘Phase I’’ effort to develop a preliminary design. This would ensure ‘‘that the cost estimates for the subsequent development effort’’ were ‘‘based on a solid foundation.’’66 The preliminary design effort would generate ‘‘a set of drawings and specifications and descriptive documents’’ to describe management methods, including schedules, milestones, tasks, objectives, and policies. Rubel had no reservations about forcing industrial contractors to organize and manage their projects in the way he wanted. If they wanted the job, they had to conform.67

He made clear in the request for proposals that go-ahead for Phase I did not constitute program approval. Previously, award of a preliminary design contract constituted de facto project approval for development and produc­tion. This was no longer true. Only the secretary of defense could approve a project, and he would not do so until completion of Phase I and a pro­gram review.68 According to Rubel, ‘‘The fact that improved definition is re­quired before larger-scale commitments are undertaken is neither surprising nor unique, although it is true that on most programs this definition phase has been less clearly identifiable because it has been stretched out in time and interwoven with other program activities such as development, model fabri­cation, testing and, in some cases, even production.’’ Rubel did not believe that a program definition phase would slow high-priority programs. ‘‘In fact,’’ he wrote, ‘‘our real progress should be accelerated as the result of obtaining a better focusing of our efforts.’’69

The phased approach brought several benefits to upper management. It promised better cost, schedule, and technical definition. If the contractor or agency did not provide appropriate information, management could cancel or modify the program. Organizations therefore made strenuous efforts to finalize a design and estimate program costs. The preliminary design phase provided management with a decision point before spending large sums of money, making projects easier to terminate and contractors easier to control.

By 1962, studies by Harvard and RAND economists had shown that DOD weapons projects had consistently large overruns and schedule slips, with missile programs having the worst record. The RAND study showed that for six missile projects, costs overran by more than a factor of four, with schedule slips greater than 50%. Other projects showed smaller slips, but all types aver­aged at least 70% cost overruns, and the average was more than 200% (triple the original cost estimates). The military was clearly vulnerable to criticism on cost issues, and McNamara efficiently exploited this weakness. His Program Planning and Budgeting System required that all of the services create five- year projections of programs and their costs, allocated not by specific services but rather across broad categories such as strategic offense or defense.70

Schriever sensed the change in national priorities and saw the impact of McNamara’s reforms. Replacing ‘‘concurrency,’’ ‘‘managerial reform’’ and ‘‘cost control’’ soon became the new watchwords. The immediate task facing Schriever in early 1962 was responding vigorously to the McNamara-Rubel initiatives, which he saw as cost control measures. In a February 1962 memo­randum, Schriever stated that cost overruns arose from ‘‘any one or a combi­nation of’’ factors, including deliberate underestimation, adherence to overly strict standards, too much optimism in estimating performance and sched­ules, vacillation or changes in program direction, and inadequate military or contractor management.71

One area that Schriever had to improve was cost estimation. His comp­troller’s office began by educating AFSC staff, instituting cost analysis training courses at the Air Force Institute of Technology in Dayton, Ohio. By Febru­ary 1962, the first class of 25 students graduated from this course. AFSC also developed the Program Planning Report, which allowed for improved analy­sis of cost data with respect to technical and schedule progress. He also had AFSC adopt and modify the navy’s new planning tool, PERT.72

Schriever developed other ways to improve AFSC’s management capabili­ties. He established a Management Improvement Board, ‘‘made up of Gen­eral Officers having the greatest experience in systems management matters ranging from funding, systems engineering, procurement and production, through research and development.’’ Schriever had board members exam­ine ‘‘the entire area of systems management methods to include those of the Industrial complex as well as those of the Air Force.’’ He also reinstated the Air Force Industry Advisory Group, a Board of Visitors to improve working relationships with industry, and a program of ‘‘systems management program surveys.’’ AFSC also collected ‘‘lessons learned’’ information from programs and broadcast this information through publications and industry symposia. Schriever also used this information to produce management goals for AFSC.73

AFSC also communicated systems management concepts through educa­tion. Examples included a system program management course at the Air Force Institute of Technology and the creation of a systems management newsletter within AFSC. The Air Force Institute of Technology course used case studies taught by experienced program managers such as Col. Samuel Phillips of the Minuteman program. These program managers taught about program planning and budgeting, the McNamara reforms, organizational roles in system development, systems engineering, configuration manage­ment and testing, system acquisition regulations, program management tech­niques, contracting approaches, and financial methods.74

By the mid-1960s, the combination of AFSC management initiatives and the McNamara reforms produced a mature form of systems management that is still used in the aerospace industry today. Earlier concepts and practices of

concurrency contributed the detailed planning and systems engineering co­ordination necessary to rapidly develop large-scale technologies. When ICBM failures became the primary concern, engineers added change control, quality control, and reliability to the mix. Finally, the cost concerns of the early 1960s — driven by rising ICBM costs, the Vietnam War, and social issues such as the civil rights movement—contributed phased planning and configura­tion management. Both new methods provided mechanisms to better predict costs.

McNamara, duly impressed with the procedures and reforms in Schriever’s organization, used them — modified to include phased planning for central control—as the basis for the DOD’s new regulations for the development of large-scale weapon systems. In 1965, the DOD enshrined phased planning and the systems concept as the cornerstone of its R&D regulations. Having already spread to NASA, these processes moved throughout the aerospace industry. Even when the processes were not explicitly used, industry accepted the as­sumptions and ideas encompassed in these regulations.75

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.

Alliances between scientists and military officers had grown during World War II on the Manhattan Project, in the Radiation Laboratory, and in opera­tions research groups. The Cold War furthered this military-scientific partner­ship. Appealing to the imminent Soviet threat, military officers like Bernard Schriever promoted the systems approach in weapons development to quickly design and manufacture novel weapons such as ballistic missiles. Working with his scientific allies, Schriever built an organization initially run by mili­tary officers and scientists. Similarly, Army Ordnance officers allied them­selves with JPL’s research engineers to develop the Corporal missile. Both Army Ordnance and Schriever’s ‘‘Inglewood complex’’ spent immense sums of money in concurrent development, designing, testing, and manufacturing missiles as rapidly as possible. The result for Atlas and for Corporal was the same: a radically new, expensive, and unreliable weapon.

Prematurely exploding missiles created a spectacle not easily ignored. JPL’s engineering managers resolved to improve on their ad hoc methods and em­ployed the systems approach their next missile, the Sergeant. The air force’s next-generation missile was the Minuteman, on which Col. Samuel Phillips developed the system of configuration control to better manage costs and schedules. Both second-generation weapons were far more reliable than their predecessors, partly because of the switch to solid-propelled engines, and partly because of changes in organizational practices.

Over time, social measures of success changed. Initially, simply getting a rocket off the ground was a major accomplishment. Eventually, however, Congress expected that its large appropriations would buy technologies that worked reliably. Soon thereafter, congressional leaders wanted accurate cost predictions so they could weigh alternative uses for that money. Cost over­runs came to be seen as failures. This was particularly true in Europe, where leaders promoted space programs mainly to spur economic development.

The Ranger program and its aftermath illustrated the power of Congress to change organizations. Under William Pickering’s guidance, JPL used a loose matrix structure where most authority resided with the technical divisions. When Ranger’s failures exposed JPL’s organizational flaws, Congress required JPL to strengthen project management and implement more stringent pro­cedures. Pickering and JPL’s engineers resisted these changes, but Ranger’s failures weakened their credibility. When National Aeronautics and Space Administration (NASA) Administrator James Webb threatened to remove all future programs from JPL, Pickering had little choice. He gave in. Similar pressures influenced the air force in the early 1960s and the European Space Research Organisation (ESRO) in the late 1960s. Systems management was the end result in each case. The European Space Vehicle Launcher Development Organisation’s (ELDO’s) attempts to strengthen project management did not succeed, because of weaknesses inherent in its authorizing Convention and the uncooperative attitude of its member states.

The first figure illustrates the relationships between the four social groups. In the early Cold War, military officer-entrepreneurs and scientists provided the authority and methods. I distinguish here between those military officers such as Bernard Schriever who promoted new systems, and others, such as Samuel Phillips, who brought them to fruition. Schriever acted in an entre­preneurial fashion and Phillips as a classical manager. In the air force, this period lasted from roughly 1953 until 1959, the heyday of the Atlas missile, before its many test failures led to change. Schriever acted as a visionary entre­preneur, albeit in an unconventional blue uniform. JPL’s period of military entrepreneur-scientific control came from 1944 to 1952, when JPL’s research engineers developed Private and converted Corporal from research to produc­tion. In both cases, expensive, unreliable weapons led to a concentration on cost and dependability for the next missiles, leading to approaches based on engineering and managerial values. Jack James at JPL and Phillips of Minute- man typified the no-nonsense managers that demanded dependability. Un­like engineers focused on research, such as Caltech’s von Karman and Malina, most engineers focused on the design and development of technological sys-

Cold War social groups and alliances. At JPL from 1944 to 1952, and in the air force be­tween 1953 and 1959, entrepreneurial military officers and scientists (along with research engineers) formed a social alliance to promote novel weapons. After these periods, man­agers in the military and industry formed an alliance with design engineers to control costs and build dependable systems.

tems. For them, creating a product that worked was more important than creating one that was new.

NASA’s history differed somewhat from that of the air force, because in the early years of NASA, the scientists and engineers controlled their own projects and methods. At JPL, the research-based methods prevailed in the labora­tory’s early years, and again later when Pickering shifted the laboratory into the space program, and satellite launches (and failures) were frequent as JPL raced with the clock and the Soviets.1 JPL’s new projects reverted to ad hoc committees to get fast results. Similarly, former National Advisory Commit­tee for Aeronautics researcher Robert Gilruth of the Space Task Group ran the early manned programs with little interference from NASA Administra­tor Keith Glennan. Engineers and scientists made decisions locally in a highly decentralized organization. After the Ranger fiasco at JPL, and after the ar­rival of George Mueller and Samuel Phillips in the manned programs, NASA’s high-level managers and engineers quickly centralized authority. A similar story was unfolding at ESRO, originally conceived of as an engineering ser­vice organization for scientists. By 1967, commercial interests predominated and European governments changed ESRO into an engineering organization run by managers to ensure cost control.

It is more difficult to determine who, if anyone, ran ELDO. With an am­bassador as secretary-general and economic nationalism the primary driving force, ELDO did not have a single dominant group, one could argue. Neither engineers nor scientists controlled the organization. Nor could managers fos­ter the communication necessary to break national and industrial barriers. If ever there existed a purely political organization for technology development, ELDO was it.

Each social group promoted its characteristic methods. Military officers and industrial managers promoted project management to centralize author­ity and used contractor penetration to closely monitor industry. Both groups also used competition to keep contractors honest and developed cost predic­tion and control methods such as configuration management and work pack­age management. Scientists promoted analytic techniques such as statistical analysis of reliability, network mathematics, and game theory. Engineers used

Authority changes at NASA and ESRO. In early NASA and ESRO, scientists and research engineers were allied with de­sign engineers to build new technologies. After several years, both organizations shifted to more predictable development, with managers and engineers controlling events.

Systems management methods classified by the social groups that promoted them.

a variety of testing methods, inspection and statistical methods for quality assurance, and design freeze to stabilize designs.

Ultimately, systems management is a stable system because its methods and processes maintain roles for each of its constituent social groups. For sys­tems management to remain stable over many years and projects, it had to have mechanisms for its constituent social groups to effectively interact. In the end, the primary mechanism became configuration management.

Europe’s lag seems to concern methods of organization above all. The Americans know how to work in our countries better than we do ourselves. This is not a matter of ‘‘brain power’’ in the traditional sense of the term, but of organization, education, and training.

-Jean-Jacques Servan-Schreiber, 1967

July 1969 marked two events in humanity’s exploration of space. One became an international symbol of technological prowess; the other, a mere historical footnote, another dismal failure of a hapless organization.

‘‘One small step for man, one giant leap for mankind.’’ These words of American astronaut Neil Armstrong, spoken as he stepped onto the surface of the Moon in July 1969, represented the views not only of the National Aero­nautics and Space Administration (NASA) but also of numerous Americans and space enthusiasts around the world. Many journalists, government heads, and industrial leaders believed that the Apollo program responsible for Arm­strong’s exotic walk had been a tremendous success. They marveled at NASA’s ability to organize and direct hundreds of organizations and hundreds of thousands of individuals toward a single end. Even Congress was impressed, holding hearings to uncover the managerial secrets of NASA’s success.1

Apollo was the centerpiece of NASA’s efforts in the 1960s-the United States’ most prestigious entry in the propaganda war with the Soviet Union. Purportedly, the massive program cost more than $19 billion through the first Moon landing and used 300,000 individuals working for 20,000 contractors and 200 universities in 80 countries.2 It was a visual, technological, and pub­licity tour-de-force, capturing the world’s attention with television broadcasts

of the Apollo 8 voyage to the Moon during Christmas 1968, the Apollo 11 land­ing, and the dramatic near-disaster of Apollo 13 in April 1970. Whatever else might be said about the program, it was an impressive technological feat.

This American achievement looked all the more impressive to European observers, who on July 3, 1969, witnessed the fourth consecutive failure of their own rocket, the grandiosely named Europa I. Whereas Apollo’s mandate included a presidential directive, national pride, and an all-out competition with the Soviet Union, Europa I began as a cast-off ballistic missile searching for a mission. When British leaders decided to use American missile tech­nology in the late 1950s, their own obsolete rocket, Blue Streak, became ex­pendable. The British decided to market it as the first stage of a European rocket, simultaneously salvaging their investment and signaling British will­ingness to cooperate with France, a gesture they hoped would lead to British acceptance into the Common Market. Complex negotiations ensued, as first Britain and France — and then West Germany, Italy, Belgium, and the Nether- lands—warily decided to build a European rocket. All the countries hoped to gain access to their neighbors’ technologies and markets, while protecting their own as much as possible.

The European Space Vehicle Launcher Development Organisation (ELDO) reflected these national ambitions. Without the ability to let contracts or to direct the technical efforts, ELDO’s Secretariat tried with growing dismay to integrate the vehicle, while its member states minimized access to the data necessary for such integration. Not surprisingly, costs rose precipitously and schedules slipped. After successful tests of the relatively mature British stage, every flight that tried to integrate stages failed miserably. The contrast be­tween European failure and American success in July 1969 could not have been more stark, with American astronauts returning to Earth to lead a round – the-world publicity tour, while European managers and engineers defended themselves from criticism as they analyzed yet another explosion. ELDO’s record of failure continued for more than four years before frustrated Euro­pean leaders dissolved the organization and started over.

Apollo was a grand symbol, arguably the largest development program ever undertaken. Many observers noted the massive size and ‘‘sheer compe­tence’’ of the program and concluded that one of the major factors in Apollo’s success was its management.3 Learning the organizational secrets of Apollo and the American space program was a primary motivation for European government and industry involvement in space programs.4

French journalist Jean-Jacques Servan-Schreiber gave European fears of American domination a voice and a focus in his best-selling 1967 book, The American Challenge. Servan-Schreiber argued that the European problems were due to inadequacies in European educational methods and institutions as well as the inflexibility of European management and government. The availability of university education to the average American led to better man­agement of technology development in commercial aircraft, space, and com­puters. Europeans needed to learn the dominant American model for man­aging and organizing aerospace projects: systems management.

European space organizations needed to create or learn new methods to successfully develop space technology. Wernher von Braun’s rocket team in Nazi Germany confronted major technical problems in the 1930s and 1940s, requiring new kinds of organizational processes. In the 1950s, the army’s Jet Propulsion Laboratory (JPL) and the air force-through its industrial con­tractors — developed progressively larger, more complex, and more power­ful ballistic missiles. Both groups encountered obstacles that the application of more gadgetry could not overcome. Like von Braun’s group, these groups found that changes in organization and management were crucial. NASA’s manned program confronted similar issues in the 1960s, resulting in major organizational innovations borrowed from the air force. In each case, the unique technical problems of spaceflight posed difficulties requiring social solutions — changes in how people within organizations in design and manu­facturing processes related to one another.

While air force officers funded government R&D, industry performed most of the work. Because of industry’s dependence upon the military for R&D and production contracts, changes in the air force’s organization and procedures had significant ramifications for industry. Industry managers grappled with government directives and technical problems, resulting in a variation of the military’s model for technical organization: matrix management.

After World War II, aircraft companies shrank with the reduction in gov­ernment contracts and observed the services’ organizational and technologi­cal changes with interest. For missile programs and complex aircraft, aircraft companies built entire systems that included ground equipment, armament, and electronics. Aircraft companies began to reorganize their efforts around the complex new products. When the air force reorganized on a systems basis in 1952, aircraft contractors were well prepared. Each company, with a num­ber of complex projects under way, had to reconcile the new project-based organization with their traditional discipline-based, functional structure.

The Martin Company developed one of the first project management orga­nizations in the years 1952-53. William Bergen, an engineer who headed the pilotless aircraft group and the contract for the Naval Research Laboratory’s Viking rocket in the late 1940s and early 1950s, was an early promoter of sys­tem management. As he wrote in a 1954 Aviation Age article, ‘‘Within the com­pany we have created a number of miniature companies, each concerned with but a single project. The project manager exercises overall product control— in terms of an organization of all skills.’’ Martin quickly implemented Bergen’s innovation and expanded it to ‘‘cover all functions from design through man­ufacturing and distribution.’’76 The Martin Company’s systems approach in­cluded three elements: systems analysis to determine what to build, systems engineering to design it, and systems management to build it.77

Another example was McDonnell Aircraft Company’s F-4 Phantom pro­gram. In the 1940s, McDonnell designed aircraft by committees staffed with engineers from the functional departments, with owner J. S. McDonnell ar­bitrating disputes. When the navy awarded the company a contract to de­velop the F-4 in 1953, the company made young engineer David Lewis its first project manager. Lewis assigned three project engineers outside of the func­tional departments’ jurisdiction to make design decisions, while he built the project organization and acquired resources.78

Project management involved the separation of engineers from their func­tional departments so that the engineers reported directly to a project man­ager whose sole task was to run the project. As projects grew, the number of managers and engineers also grew, but all reported to project managers, not functional department managers. As explained by a business school pro­fessor in 1962, ‘‘The primary reason for project management organization is to achieve some measure of managerial unity, in the same way that physical unity is achieved with the project.’’79

With numerous projects under way, military contractors faced the prob-

lem of developing several of them concurrently. The old line-and-staff or­ganization no longer sufficed, as communication lines across functional de­partments became too long for effective coordination. H. F. Lanier, a project engineer for Goodyear Aircraft’s Aerophysics Department, explained:

The problem can perhaps be best illustrated by considering the difficulties of trying to fit a number of creative people into the precise and orderly line orga­nization shown in [the “traditional line organization’’ figure]. Under this plan, all work is thoroughly organized and all assignments rigidly controlled. Each individual has a definite area to cover, definite data to work with, and a schedule to meet. He also has a boss who tells him what to do and subordinates whom he tells what to do. This organization once set up is soon limited to the creative output of a few men who lead. Any innovation is difficult to introduce because it requires detailed instruction at all levels.80

Lanier concluded that the long lines of communication needed breaking down. Ad hoc means did not suffice over the long term or for large projects: ‘‘The usual solution was to allow a great deal of ‘co-ordination’ and ‘liaison’ to be handled informally. Effectively, supervisors unleashed their men and gave the program general direction but let detailed instructions be formulated after the fact. The loose method has been reasonably successful. The next obvious step is to attempt to systematize the process.’’81

Often the first attempt at systematization was to form committees of func­tional supervisors. This did not work once meetings became too large or too frequent: ‘‘Usually the committee members are also line supervisors and hence can meet only for a fraction of the time required for efficient system de­velopment. In other words, actual development by a committee is employed most effectively on an occasional relatively huge problem. When large systems problems are the prime business, then a permanent fix must be made.’’82 For this purpose, Lanier explained, ‘‘The solution seems to be a committee of project or systems engineers — individuals trained to be jacks of all trades, and who are relieved of line responsibility for administering operating sec­tions.’’ Project management aligned engineers to the project but left undeter­mined their relationship to the rest ofthe organization. Lanier recognized that engineers had relationships to both the project and the remainder of the orga­nization, where the engineers had to go when the project ended. Engineers

Traditional line organization and lines of communication. For complex projects, the communication lines become too long. Adapted from H. F. Lanier, ‘‘Organizing for Large Engineering Projects,’’ Machine Design 28 (1956): 54.

therefore reported to both project and line management. Lanier called this dual reporting the project-line combination organization. The new organiza­tional form had a “two-dimensional” or “matrix” form.83

The evolution of General Dynamics’ Astronautics Division, responsible for the Atlas missile, typified the organizational changes brought on by the divi­sion’s involvement in several military projects. For most of the 1950s, Con – vair ran Atlas as a single-project organization. Initially, Atlas (then known as Project MX-774) was directed ‘‘by a project engineer who was assigned a small team of designers and technical specialists plus an experimental shop for fab­rication of the hardware.’’ By 1954, one year after the acceleration of the Atlas

Project-line method of organization, later known as the matrix organization. Adapted from H. F. Lanier, ‘‘Organizing for Large Engineering Projects,’’ Machine Design 28 (1956): 57.

project, Convair reorganized the project around the program office and had a force of 300 personnel, mostly engineers. In 1955, the company created the Astronautics Division to carry out the work of the Atlas program. By 1958, the work force had increased to 9,000, and by 1962, it was up to 32,500. General Dynamics made Astronautics a full division in 1961. Astronautics managed this rapidly expanding organization as a single project throughout the period.

However, with the development of different versions of the Atlas, and the development of new projects such as the Centaur upper stage and the Azusa tracking system, ‘‘priority problems were created in functional line depart­ments, with resultant conflicts over authority and the jeopardizing of perfor­mance, scheduling, and cost.’’ The Astronautics Division responded to this problem by ‘‘utilizing a program control plan called the ‘matrix’ system which provided a director for each program undertaken by the company.’’ Program directors and department managers resolved priority conflicts.84

By 1963, Astronautics organized every new major program with the project system using the matrix structure. Atlas Program Director Charles Ames de­scribed the organization in the following way: ‘‘Under this system, the pro­gram director… is responsible for the successful accomplishment of the project. . . Generally, personnel working full-time on a project are assigned to the project line organization. The project line activities are organized to fit the specific task. . . Personnel not assigned to the project line organizations work in functional or ‘institutional’ departments. Institutional engineering maintains strong scientific and applied research groups as well as preliminary design and systems analysis groups.’’85

Required by the military, and prompted by their own complex projects, to institute project management, the contractors fit the weapon system con­cept and its project management into their organizations through the cre­ation of matrix management. Matrix management provided companies with the means to move engineers across projects while maintaining disciplinary expertise, becoming the industry standard by the 1960s. Matrix management allowed the government to manage each project with systems management while also permitting each corporation to coordinate and control the multi­plicity of projects in a way that was consistent with the corporation’s overall strategy.86

Conclusion

The air force policy of concurrency kept the ballistic missile program on the fast track, in keeping with the perceived urgency of the Soviet threat in the 1950s. Industry reacted by developing matrix management, allowing several projects to be managed simultaneously. Unfortunately, in the desire to elimi­nate red tape and bureaucracy, Schriever’s organization also removed many of the checks necessary to coordinate technical details and budget for large systems. The result was a series of missile failures, compounded by huge cost overruns.

To remedy this situation, the WDD’s successor, the BMD — along with R-W and its successor, TRW — developed methods to improve missile reliability. These included exhaustive testing, component inspection and tracking, and configuration control to ensure that the design matched the hardware that was launched. Schriever’s group expanded the methods of configuration control into configuration management, an important process that tied cost estima­tion to engineering changes. The air force modified contracts based upon the accepted changes.

By the early 1960s, the air force integrated these concepts into AFSC and its administrative processes for weapon system development and procure­ment. These processes incorporated systems engineering, systems analysis, re­liability, and configuration control. Schriever’s authority grew, soon encom­passing the air force’s space programs, but at the same time he gave up his independence from the air force bureaucracy. AFSC made systems manage­ment the standard for large-scale systems.

Schriever soon found that McNamara’s centralizing changes, particularly phased planning, eroded his independence and slowed the pace of develop­ment. With one hand he fought the changes, and with the other he rolled with the punches and promoted managerial innovation within AFSC. Just as Schriever and his technical officers promoted standardization to better con­trol their organizations, so too did McNamara, promoting standardization across the entire DOD. Schriever’s methods, developed to centralize manage­ment of large-scale projects, provided the basis upon which McNamara could then control all military R&D programs.

The problems and solutions faced by the air force were not unique. Dur­ing the 1950s, the army’s JPL was a leader in missile development, confronting similar problems and developing similar solutions to its air force and navy competitors. JPL provides a good point of comparison with the air force ex­perience, as it transitioned from military missiles to civilian satellites, and from Army Ordnance to NASA.

FOUR

Despite the imposition of systems engineering and configuration manage­ment on MSFC, they remained foreign concepts to members of Huntsville’s engineering family. They had been working together on rockets since the 1930s, and the many years of experience had taught them the technologies, processes, and interactions necessary to build rockets. These engineers under­stood rocketry and each other so well as to make formal coordination mecha­nisms such as systems engineering redundant. The efforts of Mueller and Phillips had brought configuration management and air force methods to contractors, but the functional, discipline-based laboratories remained the centers of power in MSFC.

As MSFC’s effort on the Apollo program peaked in 1966 and layoffs threat­ened, however, MSFC leaders realized that they would have to diversify be­yond rocketry to keep themselves in business.112 In new fields such as manned space stations and robotic spacecraft, MSFC’s unmatched ability in rockets meant little, and they soon found new utility in systems engineering.

By the summer of 1968, von Braun recognized that he needed to strengthen systems engineering at MSFC. He called in Philip Tompkins, a communi­cations expert from Wayne State University, to study MSFC’s organization and recommend how better to implement systems engineering. At the time,

Mueller was pressing von Braun to emphasize systems engineering in the design of the Skylab space station. Von Braun explained to Tompkins that Mueller, who had been trained in electrical engineering, thought more natu­rally in terms of a ‘‘nervous system’’ than he, who thought of rockets as ma­chines. Von Braun belatedly saw the validity of Mueller’s point of view and was determined to reorient MSFC along systems engineering lines so as to better coordinate MSFC’s design efforts.113

Tompkins investigated MSFC’s organization and soon concluded that the design laboratories were overly oriented toward ‘‘low-level subsystems engi­neering.’’ As one manager stated it, ‘‘If we had a lawnmower capability at the Marshall Center, we’d put lawnmowers on all the vehicles.’’114 To com­bat this, Tompkins recommended significant strengthening of the systems engineering office. With this change, systems engineering by late 1968 be­came a much stronger element within MSFC, albeit weaker in the traditional rocket groups than the newer organizations that focused on other projects. As MSFC’s ‘‘family’’ organization and expertise in rocketry grew less important, systems engineering took their place. Formal coordination processes replaced the informal methods that sufficed in von Braun’s heyday.

Why did NASA’s most experienced group of engineers take so long to em­brace systems engineering? Three factors contributed: the almost exclusive use of in-house capability for rocket development and testing, the extraordi­nary continuity of von Braun’s team, and the continuity of the team’s R&D project. From the mid-1950s until the early 1960s, von Braun’s team members relied upon their own capabilities to design rockets, using external contrac­tors sparingly. When they did use contractors, they did so for only specific components, or they closely monitored the contractors, such as Chrysler for the Redstone and Jupiter. The use of contractors significantly increased for the Saturn V project, and systems engineering began to make inroads into MSFC at this time. However, not until MSFC diversified out of rocketry and many of the original team began to retire in the late 1960s did systems engineering become a major element of Marshall’s R&D process.

The continuity of von Braun’s team, along with the continuity of the tech­nologies upon which the team worked, helps to explain the dismissal of sys­tems engineering at MSFC. Simply put, when each team member knew the job through decades of experience and knew every other team member over that period, formal methods to communicate or coordinate were redundant. Rocket team members knew their jobs, and each other, intimately. They un­derstood what information their colleagues needed, and when. When they began to work on new products such as space stations and spacecraft in the late 1960s, it was no longer obvious how each team member should communi­cate with everyone else. Formal task planning, coordination, and communi­cation became a necessity, and systems engineers performed these new tasks.

Conclusion

Systems management evolved as the manned space programs developed. Like the ballistic missile programs before them, the manned programs were in­augurated with few cost constraints and substantial external pressure to speed development. Despite massive cost overruns, the programs continued for the first few years with few questions from headquarters or Congress. Glennan, and later Webb, let the STG, MSC, and MSFC do their jobs with minimal supervision. These organizations used informal engineering committees to manage the manned programs. When NASA needed rigor in manufactur­ing and component quality, it had the air force and its industrial contractors to supply them. Informal methods frequently produced technical success but failed miserably at predicting costs.

Spiraling costs led Holmes, the first head of OMSF, to challenge Webb. Holmes’s failure made it obvious to his replacement, Mueller, that he had to control costs. To do so he enlisted the help of air force officers, led by Phillips. Mueller forced MSC and MSFC to adopt stronger project management, in­stitute systems engineering, expand ground testing, and report more thor­oughly to headquarters. Phillips instituted configuration management and project reviews throughout Apollo to control technical, financial, and con­tractual aspects as well as the scheduling of the program. Air force officers brought in by Mueller and Phillips propagated the reforms and transformed OMSF’s organizations into project-oriented hierarchical development orga­nizations.

Systems management made development costs more predictable and cre­ated technically reliable product, but at a price. The disadvantages of systems management would become apparent later, but for the moment it was a mana­gerial icon. If there was a secret to Apollo, it was Phillips’s organizational re­forms, which transferred air force methods to NASA, superimposed upon the technical excellence of STG and MSFC engineers. Europeans would eventu­ally make a concerted effort to learn the managerial secrets of Apollo, but not before trying their own ideas, and failing miserably.

SIX

Between 1962 and 1965, NASA’s organization changed from a series of engi­neering committees to a mixture of committees overlaid with a managerial hierarchy. Similarly, between 1950 and 1964, JPL’s committee structure gave way to hierarchical project management. Schriever’s entrepreneurial Western Development Division also used ad hoc committees from 1953 to 1955, sepa­rated from the rest of the air force hierarchy. From 1956 onward, the air force hierarchy increasingly asserted control. These shifts signified changes in the balance of power between the hierarchical models of organization used by military and industrial managers, and the informal committees used by engi­neers and scientists.

The novel technologies of the 1950s required the services of scientists and engineers, who through their monopoly on technical capabilities influenced events. Schriever’s alliance with scientists in the 1940s and 1950s brought sci­entists to the forefront of the air force’s development efforts. In NASA’s first few years, engineers at the field centers effectively controlled NASA and its programs. In both cases, scientists and engineers extensively used committee structures to organize activities. These working groups generated and used the information necessary to create the new technologies. Knowing that Con­gress would pay the bills, scientists and engineers essentially ignored costs. Indeed, if they could have made correct cost predictions, these would to some extent have invalidated their claim to be creating radically new technologies. Schriever shared the scientists’ ‘‘visionary’’ bias. He argued for radical new weapons and the methods to rapidly create them by reminding everyone of the Soviet threat.

By the 1960s, the need for radical weaponry declined. When in 1961 re­connaissance satellites showed the missile gap to be illusory, arch-manager Robert McNamara, the new secretary of defense, immediately imposed hierar­chical structures and centralized information systems to assert control. Simi­larly, the air force asserted control over Schriever’s organization when re­liability problems led to embarrassing questions from Congress. Ironically, the methods used by the air force and the Department of Defense to con­trol Schriever were the methods that Schriever’s group had created to control ballistic missiles. NASA’s turn came after 1963, as Congress clamped down in response to NASA’s wildly inaccurate cost estimates. Air force R&D veterans Mueller and Phillips imposed hierarchy and information systems over NASA’s engineering committees.

NASA’s early history showed that committees could successfully develop reliable technologies, but only when given a blank check and top priority. On the manned space flight programs, NASA’s engineers and contract person­nel had ample motivation. With clear goals and a national mandate, formal control mechanisms were unnecessary. Informal methods worked well both inside and outside NASA, as NASA engineers exerted firm control of con­tractors through informal but extensive contractor penetration. As long as Congress was willing to foot the bill for huge overruns, NASA’s committees sufficed. When motivation was overwhelmingly positive, goals were clear, and funding was generous, coordination worked.

The history of ELDO illustrates how critical motivation and authority are

to an organization’s success. ELDO’s primary function was to coordinate sev­eral national programs through committees whose only authority was their ability to persuade others. Unfortunately for ELDO, the national governments and industrial companies were at least as concerned with protecting their technologies from their national and industrial partners as they were with co­operation. By 1966, both the national organizations and ELDO began to rec­ognize problems with this situation, and they created an Industrial Integrating Group to disseminate information. Without authority, neither the integrat­ing group nor ELDO could bridge the communication gaps between contrac­tors, leading to a series of interface failures and ultimately to ELDO’s demise. Without motivation, authority, or unitary purpose, ELDO failed.

The trick to designing new technologies within a predictable budget was to unite the creative skills of scientific and engineering working groups with the cost-consciousness of managerial hierarchies. JPL and the air force devel­oped the first link: configuration control. In both organizations, configuration control developed as a contractual association between the government and industry. Industrial contractors already used the design freeze as the break­point between design and manufacturing. Configuration control in the air force linked the design frozen by the engineers to the missile as actually built. When managers found that a number of missile failures resulted from mis­matches between the engineering design and the ‘‘as launched’’ missile, air force managers implemented a system of paperwork to link design drawings to specific hardware components.

At JPL, configuration control developed because JPL designed the Ser­geant missile, while industrial contractor Sperry was to build it. Deputy Program Director Jack James realized Sperry needed design information as soon as possible, so he required JPL engineers to document and deliver in­formation in several stages. At each stage, James and others integrated the various engineers’ information into a single package. James then controlled design changes by requiring engineers to communicate with him before mak­ing changes. This gave James the opportunity to rule on the necessity of the change and to ensure communication with other designers to coordinate any other implications of the change. This “progressive design freeze’’ worked so well that James imported it into his next project, Mariner. James and other managers expanded the concept on Mariner and its successors to include cost

and schedule change estimates with every technical modification, thus tying costs and schedules to technical designs.

The air force also realized that tying cost and schedule estimates to engi­neering changes was a way to control engineers. Air force managers and engi­neers from The Aerospace Corporation expanded the concept to include the development of specifications. Soon the air force made specifications contrac­tually binding and tied specification changes to cost and schedule estimates, just as it did for design drawings and hardware. This system of change con­trol for a hardware configuration, tied to cost and schedule estimates, became known as configuration management. Minuteman program director Phillips recognized configuration management as an important tool, and he imposed it on Apollo to coordinate and control not only contractors but NASA field centers.

Configuration management satisfied the needs of managers, systems engi­neers, financial experts, and legal personnel. Systems engineers used con­figuration management to coordinate the designs of the subsystem engineers. Managers found configuration management an ideal lever to control scien­tists, engineers, and contractors because these groups could no longer make changes without passing through a formal CCB. Financial and legal experts benefited from configuration management because it tied cost and sched­ule changes to contractual documentation. One business school professor be­lieved that configuration management was influential as a systematic way to resolve group conflicts in NASA projects.2

The CCB was the link between the formal hierarchy and the informal work­ing groups. At the board, the project manager and project controller evalu­ated changes from the standpoint of cost and schedules. Disciplinary repre­sentatives evaluated change requests to see if they affected other design areas, while systems engineers determined if the proposed change caused higher – level interactions among components. The CCB ensured frequent commu­nication between the groups. Through the linkage of hierarchies and work­ing groups, and the processes that tied paperwork to hardware, configuration management was the heart of systems management and the key to managerial and military control over scientists and engineers.

Missiles were developed from simple rocketry experimentation between World Wars I and II. Experimenters such as Robert Goddard and Frank Ma – lina in the United States, von Braun in Germany, Robert Esnault-Pelterie in France, and Valentin Glushko in the Soviet Union found rocketry experimen­tation a dangerous business. All of them had their share of spectacular mis­haps and explosions before achieving occasional success.5

The most obvious reason for the difficulty of rocketry was the extreme volatility of the fluid or solid propellants. Aside from the dangers of handling exotic and explosive materials such as liquid oxygen and hydrogen, alcohols, and kerosenes, the combustion of these materials had to be powerful and controlled. This meant that engineers had to channel the explosive power so that the heat and force neither burst nor melted the combustion chamber or nozzle. Rocket engineers learned to cool the walls ofthe combustion chamber and nozzle by maintaining a flow of the volatile liquids near the chamber and nozzle walls to carry off excess heat. They also enforced strict cleanliness in manufacturing, because impurities or particles could and did lodge in valves and pumps, with catastrophic results. Enforcement of rigid cleanliness stan­dards and methods was one of many social solutions to the technical problems of rocketry.6

Engineers controlled the explosive force of the combustion through care­fully designed liquid feed systems to smoothly deliver fuel. Instabilities in the fuel flow caused irregularities in the combustion, which often careened out of control, leading to explosions. Hydrodynamic instability could also ensue if the geometry of the combustion chamber or nozzle was inappropriate. Engi­neers learned through experimentation the proper sizes, shapes, and relation­ships of the nozzle throat, nozzle taper, and combustion chamber geometry. Because of the nonlinearity of hydrodynamic interactions, which implied that mathematical analyses were of little help, experimentation rather than theory determined the problems and solutions. For the Saturn rocket engines, von Braun’s engineers went so far as to explode small bombs in the rocket ex­haust to create hydrodynamic instabilities, to make sure that the engine de­sign could recover from them.7 For solid fuels, the shape of the solid deter­mined the shape of the combustion chamber. Years of experimentation at JPL eventually led to a star configuration for solid fuels that provided steady fuel combustion and a clear path for exiting hot gases. Once engineers determined the proper engine geometry, rigid control of manufacturing became utterly critical. The smallest imperfection could and did lead to catastrophic failure. Again, social control in the form of inspections and testing was essential to ensuring manufacturing quality.

Rocket engines create severe structural vibrations. Aircraft designers rec­ognized that propellers caused severe vibrations, but only at specific frequen­cies related to the propeller rotation rate. Jet engines posed similar prob­lems, but at higher frequencies corresponding to the more rapid rotation of turbojet rotors. Rocket engines were much more problematic because their vibrations were large and occurred at a wide range of nearly random frequen­cies. The loss of fuel also changed a rocket’s resonant frequencies, at which the structure bent most readily. This caused breakage of structural joints and the mechanical connections of electrical equipment, making it difficult to fly sensitive electrical equipment such as vacuum tubes, radio receivers, and guidance systems. Vibrations also occurred because of fuel sloshing in the emptying tanks and fuel lines. These ‘‘pogo’’ problems could be tested only in flight.

Vibration problems could not generally be solved through isolated tech­nical fixes. Because vibration affected electrical equipment and mechanical connections throughout the entire vehicle, this problem often became one of the first so-called system issues — it transcended the realm of the structural engineer, the propulsion expert, or the electrical engineer alone. In the 1950s, vibration problems led to the development of the new discipline of reliability and to the enhancement of the older discipline of quality assurance, both of which crossed the traditional boundaries between engineering disciplines.8

Reliability and quality control required the creation or enhancement of so­cial and technical methods. First, engineers placed stronger emphasis on the selection and testing of electronic components. Parts to be used in missiles had to pass more stringent tests than those used elsewhere, including vibra­tion tests using the new vibration, or ‘‘shake,’’ tables. Second, technicians as­sembled and fastened electronic and mechanical components to electronic boards and other components using rigorous soldering and fastening meth­ods. This required specialized training and certification of manufacturing workers. Third, to ensure that manufacturing personnel followed these pro­cedures, quality assurance personnel witnessed and documented all manufac­turing actions. Military authorities gave quality assurance personnel indepen­dent reporting and communication channels to avoid possible pressures from contractors or government officials. Fourth, all components used in missiles and spacecraft had to be qualified for the space environment through a series of vibration, vacuum, and thermal tests. The quality of the materials used in flight components, and the processes used to create them, had to be tightly controlled as well. This entailed extensive documentation and verification of materials as well as of processes used by the component manufacturers. Orga­nizations traced every part from manufacturing through flight.9

Only when engineers solved the vibration and environmental problems could they be certain the rocket’s electronic equipment would send the signals necessary to determine how it was performing. Unlike aircraft, rockets were automated. Although automatic machinery had grown in importance since the eighteenth century, rockets took automation to another level. Pilots could fly aircraft because the dynamics of an aircraft moving through the air were slow enough that pilots could react sufficiently fast to correct deviations from the desired path and orientation of the aircraft. The same does not hold true for rockets. Combustion instabilities inside rocket engines occur in tens of milliseconds, and explosions within 100 to 500 milliseconds thereafter, leaving no time for pilot reaction. In addition, early rockets had far too little thrust to carry something as heavy as a human.

Because rockets and satellites were fully automated, and also because they went on a one-way trip, determining if a rocket worked correctly was (and is) problematic. Engineers developed sophisticated signaling equipment to send performance data to the ground. Assuming that this telemetry equip­ment survived the launch and vibration of the rocket, it sent sensor data to a ground receiving station that recorded it for later analysis. Collecting and processing these data was one of the first applications of analog and digital computing. Engineers used the data to determine if subsystems worked cor­rectly, or more importantly, to determine what went wrong if they did not. The military’s system for problem reporting depended upon pilots, but con­tractors and engineers would handle problem reporting for the new technolo­gies — a significant social change. Whereas in the former system, the military tested and flew aircraft prototypes, for the new technologies contractors flew prototypes coming off an assembly line of missiles and the military merely witnessed the tests.10

Extensive use of radio signals caused more problems. Engineers used radio signals to send telemetry to ground stations and to send guidance and de- struct signals from ground stations to rockets. They carefully designed the electronics and wiring so that electromagnetic waves from one wire did not interfere with other wires or radio signals. As engineers integrated numerous electronic packages, the interference of these signals occasionally caused fail­ures. The analysis of ‘‘electromagnetic interference’’ became another systems specialty.11

Automation also included the advanced planning and programming of rocket operations known as sequencing. Rocket and satellite engineers de­veloped automatic electrical or mechanical means to open and close propul­sion valves as well as fire pyrotechnics to separate stages, release the vehicle from the ground equipment, and otherwise change rocket functions. These ‘‘sequencers’’ were usually specially designed mechanical or electromechani­cal devices, but they soon became candidates for the application of digital computers. A surprising number of rocket and satellite failures resulted from improper sequencing or sequencer failures. For example, rocket stage sepa­ration required precise synchronization of the electrical signals that fired the pyrotechnic charges with the signals that governed the fuel valves and pumps controlling propellant flow. Because engineers sometimes used engine turbo­pumps to generate electrical power, failure to synchronize the signals for sepa­ration and engine firing could lead to a loss of sequencer electrical power. This in turn could lead to a collision between the lower and upper stages, to an engine explosion or failure to ignite, or to no separation. The solution to se­quencing problems involved close communication among a variety of design and operations groups to ensure that the intricate sequence of mechanical and electrical operations took place in the proper order.12

Because satellites traveled into space by riding on rockets, they shared some of the same problems as rockets, as well as having a few unique features. Satellites had to survive launch vehicle vibrations, so satellite designers ap­plied strict selection and inspection ofcomponents, rigorous soldering meth­ods, and extensive testing. Because of the great distances involved-particu – larly for planetary probes-satellites required very high performance radio equipment for telemetry and for commands sent from the ground.13

Thermal control posed unique problems for spacecraft, in part because of the temperature extremes in space, and in part because heat is difficult to dissipate in a vacuum. On Earth, designers explicitly or implicitly use air currents to cool hot components. Without air, spacecraft thermal design re­quired conduction of heat through metals to large surfaces where the heat could radiate into space. Engineers soon designed large vacuum chambers to test thermal designs, which became another systems specialty.

Unlike the space thermal environment, which could be reproduced in a vacuum chamber, weightlessness could not be simulated by Earth-based equipment. The primary effect of zero gravity was to force strict standards of cleanliness in spacecraft manufacturing. On Earth, dust, fluids, and other contaminants eventually settle to the bottom of the spacecraft or into corners where air currents slow. In space, fluids and particles float freely and can dam­age electrical components. Early spacecraft did not usually have this problem because many of them were spin stabilized, meaning that engineers designed them to spin like a gyroscope to hold a fixed orientation. The spin caused particles to adhere to the outside wall of the interior of the spacecraft, just as they would on the ground where the spacecraft would have been spin tested.

Later spacecraft like JPL’s Ranger series used three-axis stabilization whereby the spacecraft did not spin. These spacecraft, which used small rocket engines known as thrusters to hold a fixed orientation, were the first to en­counter problems with floating debris. For example, the most likely cause of the Ranger 3 failure was a floating metal particle that shorted out two adjacent wires. To protect against such events, engineers developed conformal coating to insulate exposed pins and connectors. Designers also separated electrically hot pins and wires so that floating particles could not connect them. Engi­neers also reduced the number of particles by developing clean rooms where technicians assembled and tested spacecraft.

Many problems occurred when engineers or technicians integrated com­ponents or subsystems, so engineers came to pay particular attention to these interconnections, which they called interfaces. Interfaces are the boundaries between components, whether mechanical, electrical, human, or “logical,” as in the case of connections between software components. Problems between components at interfaces are often trivial, such as mismatched connectors or differing electrical impedance, resistance, or voltages. Mismatches between humans and machines are sometimes obvious, such as a door too high for a human to reach, or an emergency latch that takes too long to operate. Others are subtle, such as a display that has too many data or a console with distract­ing lights. Finally, operational sequences are interfaces of a sort. Machines can be (and often are) so complicated to operate that they are effectively unusable. Spacecraft, whether manned or unmanned, are complex machines that can be operated only by people with extensive training or by the engineers who built them. Greater complexity increases the potential for operator error. It is probably more accurate to classify operator errors as errors in design of the human-machine interface.14

Many technical failures can be attributed to interface problems. Simple problems are as likely to occur as complex ones. The first time the Ger­mans and Italians connected their portions of the Europa rocket, the diame­ters of the connecting rings did not match. Between the British first stage and the French second stage, electrical sequencing at separation caused com­plex interactions between the electrical systems on each stage, leading ulti­mately to failure. Other interface problems were subtle. Such was the failure of Ranger 6 as it neared the Moon, ultimately traced to flash combustion of propellant outside of the first stage of the launch vehicle, which shorted out some poorly encased electrical pins on a connector between the launch ve­hicle and the ground equipment. Because the electrical circuits connected the spacecraft to the offending stage, this interface design flaw led to a spacecraft failure three days later.15

Some farsighted managers and engineers recognized that interfaces repre­sented the connection not simply between hardware but also between indi­viduals and organizations. Differences in organizational cultures, national characteristics, and social groups became critical when these groups had to work together to produce an integrated product. As the number of organiza­tions grew, so too did the problems of communication. Project managers and engineers struggled to develop better communication methods.

As might be expected, international projects had the most difficult prob­lems with interfaces. The most severe example was ELDO’s Europa I and Europa II projects. With different countries developing each of three stages, a test vehicle, and the ground and telemetry equipment, ELDO had to deal with seven national governments, military and civilian organizations, and national jealousies on all sides. Within one year after its official inception, both ELDO and the national governments realized that something had to be done about the ‘‘interface problem.’’ An Industrial Integrating Group formed for the pur­pose could not overcome the inherent communication problems, and every one of ELDO’s flights that involved multiple stages failed. All but one failed because of interface difficulties.16

By the early 1960s, systems engineers developed interface control docu­ments to record and define interfaces between components. On the manned space projects, special committees with members from each contributing or­ganization worked out interfaces between the spacecraft, the rocket stages, the launch complex, and mission operations. After the fledgling European Space Research Organisation began to work with American engineers and managers from Goddard Space Flight Center, the first letter from the American project manager to his European counterpart was a request to immediately begin work on the interface between the European spacecraft and the American launch vehicle.17

Systems management became the standard for missile and space systems because it addressed many of the major technical issues of rockets and space­craft. The complexity of these systems meant that coordination and commu­nication required greater emphasis in missile and space systems than they did in many other contemporary technologies. Proper communication helped to create better designs. However, these still had to be translated into techni­cal artifacts, inspected and documented through rigid quality inspections and testing during manufacturing. Finally, the integrated system had to be tested on the ground and, if possible, in flight as well. The high cost and “nonreturn” of each missile and spacecraft meant that virtually every possible means of ground verification paid off, helping to avoid costly and difficult-to-analyze flight failures. All in all, the extremes of the space environment, automation, and the volatility of rocket fuels led to new social methods that emphasized considerable up-front planning, documentation, inspections, and testing. To be implemented properly, these social solutions had to satisfy the needs of the social groups that would have to implement them.

Pride in accomplishment is not a self-sufficient safeguard when
undertaking large scale projects of international significance.

— Kelley Board, after Ranger 5 failure

The Jet Propulsion Laboratory (JPL), located in Pasadena, California, and managed by the California Institute of Technology, began as a graduate stu­dent rocket project in the late 1930s and developed into the world’s leading institution for planetary space flight. Between 1949 and 1960, JPL transformed itself twice: first, from a small research organization to a large engineering de­velopment institution, and second, from an organization devoted to military rocketry to one focusing on scientific spacecraft.1

JPL’s academic researchers did not initially recognize the many differences between a hand-crafted research vehicle and a mass-produced, easily oper­ated weapon, or highly reliable planetary probes. The switch from research to development required strict attention to thousands of details. Properly build­ing and integrating thousands of components was not an academic problem but an organizational issue. JPL’s engineering researchers learned to become design engineers, and in so doing some of them became systems engineers.

Learning systems engineering on tactical ballistic missiles, JPL managers and engineers modified missile practices to design and operate spacecraft. The most significant missile practices that carried over to spacecraft were organizational: component testing and reliability as well as procedures for change control. A few JPL managers learned these lessons quickly. However, it

took a number of embarrassing failures for JPL’s academically oriented engi­neers and managers to accept the structured methods of systems manage­ment.

JPL independently recreated processes that the air force developed on its ballistic missile programs: systems engineering, project management, and configuration control. The history of the two organizations shows that the processes were the result of not individual idiosyncrasies but larger technical and social forces.