Category The Secret of Apollo

At its inception in October 1958, NASA consisted of field centers trans­ferred from other organizations. Three centers from NACA formed NASA’s core: the Langley Aeronautical Laboratory in Hampton, Virginia; Lewis Re­search Laboratory in Cleveland, Ohio; and Ames Research Laboratory near Sunnyvale, California. NACA researchers concentrated on empirical and mathematical investigations of aircraft design, including the ‘‘X series’’ of high-performance aircraft, high-speed aerodynamics, jet engines, and rocket propulsion.2

An ad hoc group of NACA researchers known as the Space Task Group (STG) promoted the development of space flight. By 1958, they had developed a blunt body capsule design to put a man into space. One other organization, transferred to NASA in January 1960, was key to NASA’s manned space efforts: Wernher von Braun’s Army Ballistic Missile Agency (ABMA) in Huntsville, Alabama, and its launch facilities at Cape Canaveral, Florida. NASA renamed the ABMA the Marshall Space Flight Center (MSFC), and the Cape Canaveral facilities eventually became the Kennedy Space Center (KSC).3 These two cen­ters created the massive rockets and launch facilities necessary to place men on the Moon.

The STG’s manned capsule, now christened Mercury, topped NASA’s

agenda. Engineers in the Mercury project were to create not only a space cap­sule but also a worldwide communications network. They were to marry the capsule and the network to the launchers under development by the army and air force. Langley Assistant Director Robert Gilruth headed the STG, which grew quickly and in 1962 moved to Houston, Texas, becoming the Manned Spacecraft Center (MSC).4

Gilruth was typical of NASA’s experienced engineering researchers. He graduated in 1936 with a master’s degree in aeronautical engineering from the University of Minnesota, where he designed high-speed aircraft. From Min­neapolis he moved to Langley Research Laboratory, developing quantitative measures for aircraft flying qualities, a job that later served him well in devel­oping manned spacecraft. His Requirements for Satisfactory Flying Qualities of an Aircraft became the standard for the field for some years. Gilruth’s next assignment brought him back to high-speed aircraft: developing wind tunnel techniques to measure hypersonic flow. Hypersonic flow problems led him to perform full-scale experiments dropping objects from high altitudes at Wal­lops Island off the Virginia coast. These experiments brought him into con­tact with rocketry, as he and his NACA colleagues developed and launched rockets to test their theories and technologies.5

In the early manned programs, Gilruth treated his engineering colleagues as technical equals. As his assistant, Paul Purser, described it, “Individuals around the conference table are not aware of being division chiefs or sec­tion heads—they are all people working on a problem.’’ Gilruth’s ability and experience made him more than just a manager. Future NASA Administra­tor George Low said in the early 1960s, ‘‘Gilruth works personally with many people in the Space Task Group. His method of operation is one of very close technical involvement in the project. He could tell you… every nut and bolt in the Mercury capsule, how it works, and why it works. I’ve been in many meetings over the last two or three years, where the whole picture would look very complex. After perhaps a half-hour’s discussion, Gilruth would come up with the right solution, and the rest of us present would wonder why we hadn’t thought of it.’’6 The STG’s hands-on approach to engineering would continue for years to come.7

In the fall of 1958, the STG established Mercury’s basic configurations and missions. Engineers planned to use existing rockets to launch the new space­craft-first von Braun’s proven Redstone and Jupiter boosters, then the air force’s more powerful but less mature Atlas. Congress gave NASA the same procurement regulations as the Department of Defense (DOD). Thus the new organization held a bidder’s conference in November 1958 to describe the pro­posed system to contractors, mailed out bid specifications, and required re­sponses in 30 days. In January 1959 NASA awarded the Mercury spacecraft contract to McDonnell Aircraft Corporation, a cost-plus-fixed-fee contract for $18,300,000 and an award fee of $1,150,000. STG engineers also started negotiations with the army and the air force for launchers.8

Two traditions distinguished Mercury’s management: the informal struc­ture and procedures of the STG, and the more formal approaches of McDon­nell Aircraft and the air force. STG engineers and scientists used commit­tees characteristic of research, simply creating more of them as Mercury grew. McDonnell Aircraft brought structured methods developed from years of interaction with the air force. Engineers from the STG and McDonnell Air­craft worked closely to resolve the numerous novel problems they encoun­tered. For Atlas, the air force used its own procedures and supplied represen­tatives to STG committees to define interfaces between Atlas and the Mercury capsule.9

Mercury’s driving force was a ‘‘bond of mutual purpose’’: determination to regain national prestige, fear of Soviet technical accomplishments, and pride in American capabilities. Managers gave tasks and the authority to perform them to young engineers. As one STG veteran put it, ‘‘NASA responsibili­ties were delegated to the people and they, who didn’t know how to do these things, were expected to go find out how to do it and do it.’’10 Working teams phased in and out as they completed their tasks; frequently they determined ‘‘a course of action and proceeded without further delay, with verification documentation following through regular channels.’’ In other words, engi­neers took immediate action without management review and left others to clean up the paperwork.11

This worked because of the extraordinary ‘‘flatness’’ and open communi­cation prevalent throughout the organization. STG leaders insisted that prob­lems be brought into the open. According to Chris Kraft, later the director of Johnson Space Center, all the people in the organization felt as if they could say ‘‘what they wanted to say any time they wanted to say it’’; Kraft called

The Mercury-Atlas organization was extraordinarily flat, with only three levels from NASA and air force headquarters to the working groups who built the spacecraft and launchers. Adapted from Mercury Project Summary, Including Results of the Fourth Manned Orbital Flight, SP-45 (Washington, D. C.: NASA, 1963), 19, figure 1-8.

this STG’s “heritage.”12 Managers tracked events through informal commu­nications and frequent technical reviews. They directed resources to problem areas, but they seldom intervened.13

On Mercury, and later on Gemini and Apollo, this sense of common pur­pose also prevented the development of bureaucratic sclerosis. As stated by one of the engineers on Gemini and Apollo, ‘‘You would see people who would try to build empires, who would try to be obstructionist, and they would be just absolutely steamrolled by this team. I saw it time and time again where there was this intense feeling of teamwork. It wasn’t always smooth, but it was like, ‘We’ve got a common goal.’’’14

The STG’s multiple committees became unwieldy as Mercury grew from a nucleus of 35 people in October 1958 to 350 in July 1959. To deal with the proliferation of committees, STG created another committee, the Capsule- Coordination Panel, subsequently upgraded to an office in Washington, D. C.15

NASA headquarters executives soon realized that the STG and McDon­nell had drastically underestimated the scope, cost, and schedule of the pro­gram. Within two months of its beginning, the estimated cost of the McDon­nell contract was $41 million, more than twice the initial estimate, while the air force’s estimated costs for the Atlas boosters increased from $2.5 million to $3.3 million. These increases led to a round of cost-cutting measures, yet costs continued to rise. The estimated cost of the McDonnell contract reached $70 million by January 1960. NASA Administrator Keith Glennan’s initial re­sponse was to visit the STG in May 1959. He came away impressed by the esprit de corps in the STG and the size and complexity of the project. With Congress and the administration willing to foot the bill and the STG rapidly tackling technical issues, Glennan elected not to intervene.16

In the summer of 1959, Gilruth organized the New Projects Panel to iden­tify manned projects beyond Mercury. The panel identified circumlunar flight (not landing) as the most promising goal.17 The most important technical de­velopments for a manned Moon mission were in the military’s rocket and en­gine programs. In January 1959, NASA acquired the air force contract with North American Aviation (NAA) to develop the huge liquid-fueled F-1 en­gine. NASA acquired the Saturn I launcher in January 1960 along with von Braun’s rocket team. Saturn was the only launch vehicle then under devel­opment that promised sufficient size for a manned lunar landing program. However, for the moment, it was a launch vehicle without a mission.18

In early 1960, NASA’s advanced planning groups concluded that a lunar mission was the best next step. NASA named the proposed new program Apollo, and in August managers announced they would award three contracts to industry for feasibility studies. The STG selected the Martin Company, General Electric (GE), and the General Dynamics Convair Division to per­form the studies. Study guidelines were so vague that when the Martin Com­pany engineers reported back in December 1960, STG engineers told them to include astronauts and to consider lunar landing and recovery. MSFC also sponsored its own feasibility studies, while the STG started an internal study.19

After the Bay of Pigs disaster and Yuri Gagarin’s flight in April 1961, the Kennedy administration proved receptive to NASA’s lunar mission planning. On May 25, President John F. Kennedy proposed that NASA land a man on the Moon ‘‘before the decade is out.’’ Congress enthusiastically agreed and immediately increased NASA’s funding.20

STG managers quickly moved Apollo from feasibility studies to devel­opment. Gilruth had prepared the groundwork, creating the Apollo Project Office in September 1960. Although the hardware configuration remained un­certain, the STG forged ahead, dividing the system into six contracts: launch vehicles, spacecraft command module and return vehicle, propulsion mod­ule, lunar landing stage, communications and tracking network, and launch facilities. Just before selecting NAA for the spacecraft command module in November 1961, MSC engineers changed the Statement of Work, meaning that they awarded NAA a contract to build a command module based on specifi­cations that NAA’s managers and engineers had never seen.21

With four Saturn stages under development, von Braun’s MSFC engineers did not have the resources to design, manufacture, and test all of the ve­hicles. They had to rely upon industry instead of their traditional in-house de­sign. MSFC managers transferred S-I stage development and manufacturing to Chrysler and awarded the new J-2 cryogenic engine to NAA Rocketdyne in June I960.22

MSFC inherited strong technical divisions from its army heritage, each based on specific disciplines such as rocket propulsion, structures, or avion­ics. The technical divisions coordinated project work through committees, contributing to MSFC’s typically large, interminable meetings. Contractors complained that MSFC managed by technical takeover. However, under the pressure of having many large, complex projects, project and matrix man­agement made inroads into MSFC’s discipline-based, functional organization. The divisions fought the change, forcing MSFC Director Wernher von Braun to clarify the power of project managers vis-a-vis the technical divisions.23

Von Braun was one of the world’s leading rocket engineers and a charis­matic leader. Even when immersed in administrative duties, he closely fol­lowed the technical details of MSFC’s rockets. Von Braun secured inputs from all participating engineers and technicians and arrived at a consensus through group meetings. He used an informal but disciplined system of weekly notes, requiring subordinates two levels below him to send him one page of notes summarizing the week’s events and issues. Von Braun then wrote comments in the margins of these notes, copied the entire week’s set, and distributed the notes for everyone in MSFC to read. They became popular reading because they contained the boss’s detailed comments on MSFC events and people.

This system of ‘‘Monday Notes’’ had a number of important ramifications. First, because von Braun required the notes to come from two levels below, the managers directly under him could not edit the news he received. Second, because of having to send weekly notes to von Braun, all managers formed their own information-gathering mechanisms. Third, the redistributed notes with von Braun’s marginalia provided a mechanism for cross-division infor­mation flow, because everyone saw comments on not only their own activi­ties but the activities of all other divisions. The notes moved information ver – tically—from the managers and engineers up to von Braun, and from von Braun down to the managers and engineers—as well as horizontally—from division to division.

This very open communication system provided MSFC engineers and managers with advanced notice of potential problems, often spurring criti­cal problem-solving efforts across the divisions. Some MSFC engineers com­plained about the extraordinary communication technique because it created an ‘‘almost iron-like discipline of organizational communication’’ in which ‘‘nobody at the bottom really felt free to do anything unless he got it approved from the next level up, the next level up, the next level up.’’ However, it did ensure that information flowed quickly and effectively throughout the orga – nization.24

Von Braun required all MSFC personnel to take ‘‘automatic responsibility’’ for problems. If MSFC employees found a problem, they were to solve it, find someone who could solve it, or bring it to management’s attention, whether or not the problem was in their normal area of responsibility. This intentional blurring of organizational lines helped create an organization more interested in solving problems than in fighting for bureaucratic turf.25

Apollo planners soon recognized a gap between Mercury’s short flights and the long flights and complex operations of Apollo. To bridge this gap, STG chief Gilruth authorized the Gemini program, which was to modify Mercury to accommodate two astronauts, perform orbital maneuvers, and rendezvous with other spacecraft. NASA awarded the Gemini capsule contract to McDon­nell without competition because it was a modification of Mercury. Gilruth split the engineering staff between Mercury and Gemini, and in January 1962 he established the Mercury, Gemini, and Apollo Project Offices.26

Like Mercury and Apollo, Gemini used coordination panels for day-to-day management. The Project Office established six panels: three for the spacecraft —mechanical systems, electrical systems, and flight operations — and one each for the paraglider,27 Atlas-Agena, and Titan II. They typically held weekly meetings, while the air force used its standard procedures to manage its por­tions of the program. Because the air force provided the Titan II and the Agena target boosted on an Atlas missile, air force and NASA managers established an additional panel to coordinate between them. Assistant Secretary of the Air Force for Research and Development Brockway McMillan and NASA’s Robert Seamans were the co-chairmen, with D. Brainerd Holmes of the Office of Manned Space Flight (OMSF) and Gen. Bernard Schriever of AFSC the highest-ranking members.28

Committees coordinated between engineers and managers at headquar­ters, MSFC, and MSC, particularly for interface designs and characteristics. By July 1963, there were so many committees that Holmes created another one, the Panel Review Board, to coordinate them.29

In the white heat of the early post-Sputnik era, technical achievement was the primary gauge of space program success, and political leaders left con­trol in the hands of the engineers who promised technical success. Engineers and scientists from the STG and MSFC used committees to coordinate their work, a habit inherited from research traditions of NACA laboratories and von Braun’s ‘‘Rocket Team.’’ Engineers rapidly developed rockets and space­craft, with little heed for cost. NASA and its contractors rushed into con­tracts and designs without firm requirements or a clearly defined mission, making schedule or cost predictions virtually impossible. For example, MSC and MSFC engineers wrote definitive specifications for their Apollo elements well after contract awards—and in the case of MSFC’s Saturn stage I, long after completion of the initial design, manufacturing, and testing.30 For the moment, this was not a problem, because Congress gave NASA more money than NASA asked for, allowing a continuation of conservative design tradi­tions on a much larger scale.

Despite significant technical progress, in 1967 ESRO was an organization in crisis, for financial, scientific, technical, and political reasons. The member states kept a short rein on ESRO’s finances, even tightening their grip as time passed. Scientists fought among themselves about which ESRO satellite pro­grams would be considered top priority, and program costs escalated. ESRO’s administrative structure made decisions difficult, and its satellite operations were awkwardly organized. Finally, the emergence of communications satel­lites was a catalyst to expand ESRO’s mission from pure science to commer­cial technology development. Between 1966 and 1968, ESRO and the member states confronted these issues, leading to significant changes in ESRO’s role and organization.

Although always troubled, ESRO’s financial status worsened in 1966. Mem­ber states controlled ESRO’s budget by setting three-year and eight-year caps. During the first three-year period, ESRO underspent its financial cap by 120 million French francs because it did not build facilities as rapidly as planned. Much to the surprise of ESRO’s administrators, scientists, and engineers, the ESRO Council refused to carry the funds forward to the next three-year period, 1967-69. Because ESRO planners had assumed that they would be able to carry these funds forward, ESRO’s programs were in jeopardy. Shocked administrators canceled ESRO’s most expensive program, the Large Astro­nomical Satellite. In addition, ESRO reduced the three planned TD missions to two, then eventually one.41

These reductions exacerbated scientific struggles over payloads and ex­periments. ESRO could not satisfy the atmospheric researchers, astronomers, geophysicists, and cosmic ray physicists competing to fly experiments. Sound­ing rockets were cheap enough to fly frequently, but spacecraft were a different story. In the end, scientists flew fewer experiments than they desired and had to take turns with complex missions.42

Overruns on ESRO’s early projects contributed to ESRO’s cost problems. ESRO-II project manager Kutzer estimated his project’s cost overrun at 50% with a schedule slip of 10%. In addition to this, ESRO had to build a second ESRO-II satellite because of the loss of the first in a launcher failure. HEOS performed better from a cost standpoint. Its project manager estimated the increase of the prime contract at 18% after accounting for inflation, with a 13% schedule delay. He considered this excellent and credited it to ESRO’s authority to choose contractors based on factors other than the cheapest bid. The Junkers team did not have the cheapest bid, but it did have by far the most detailed one. Cost increases, along with the loss of carryover funds, resulted in an immediate cut in current projects and pressure to cut future ones.43 The first new project to feel ESRO’s pressure to accurately predict and control costs was the Thor-Delta 1 and Thor-Delta 2 (TD-1/2) project.

Based on the successful example of the Junkers team for HEOS, most firms organized themselves into consortia for the February 1967 TD-1/2 contract award. In the design competition, contractor cost estimates ranged from 99 million to 176 million French francs. With such widely varying estimates, ESRO managers and engineers could not predict the final cost. ESRO even­tually selected the MESH consortium, consisting of Matra, Entwicklungsring Nord (ERNO), Saab, and Hawker Siddeley.44 ESRO management soon rued this selection, as MESH’s cost estimates grew dramatically, even during nego­tiations. Technical problems of three-axis stabilization led to these ballooning costs, which induced ESRO management to cancel the preliminary contract in mid-1968 and reduce the two-spacecraft program to a single satellite, TD-1.45 By that fall, ESRO reentered into a contract with MESH for a single vehicle with a simplified stabilization system.46

The economic potential ofcommunication satellites also confronted ESRO. In the early 1960s, NASA’s Echo, Telstar, and Syncom projects demonstrated the reality of satellite communications. The United States led efforts to create Intelsat, a semiprivate organization to develop commercial satellite commu­nications. To prepare for Intelsat negotiations, the Europeans organized the Conference Europeene de Telecommunications par Satellites (CETS [Euro­pean Conference for Satellite Telecommunications]), which, in turn, con­tracted with ESRO to investigate communications satellite design. At the same time, the French and Germans developed their own bilateral program, known as Symphonie, and Italy started its own program, known as Sirio. By 1968, the CETS effort through ESRO focused on television broadcasting in conjunc­tion with the European Broadcasting Union. ESRO’s new director-general, the British scientist Hermann Bondi, concluded that politically ‘‘ESRO could not

survive on a very narrow base of pure scientific research.’’ He resolved to con­vince his scientific colleagues of that fact.47

In the fall of 1967, ESRO management proposed to manage the CETS pro­gram as it had its earlier projects, by giving out a number of associate con­tracts, one with the integration task. This was no longer acceptable to Euro­pean industry. Having whetted their appetites on ESRO’s scientific satellites, and sensing the possibility of commercial gain on a larger scale, the contrac­tors put pressure on ESRO to let a single prime contract. As stated by CETS spokesmen, ‘‘Although the advantages of the ESRO proposition have been recognized—in particular the flexibility in choosing contractors, the con­trol of program costs, and the geographic distribution of contracts — certain delegations expressed very clearly the opinion that industry should be con­ferred global system responsibility, because this task permits them to acquire a highly profitable experience in the domain of technical management and finance of complex projects.’’ ESRO management caved in and gave industry the prime contractor role. However, ESRO maintained the tasks of prepar­ing specifications, defining the entire system (including ground system and infrastructure), and providing detailed supervision of performance, cost, and schedule. The prime contractor prepared system specifications and approved subsystem designs in collaboration with ESRO but otherwise managed, inte­grated, and tested the satellite.48

Big projects such as the Large Astronomical Satellite held another dan­ger for ESRO. On this program, the British and French national delegations insisted on contracting through their national organizations, as they did in ELDO. Only project cancellation saved ESRO from this dangerous precedent, which might have doomed ESRO to ELDO’s fate.49

Uneven contract distribution also created political problems for ESRO. As French leaders had planned, France won a significant percentage of techni­cal and facility contracts, with ESRO headquarters in Paris, and contracts for ESRO’s first three satellites. The Netherlands, with ESTEC on its soil, also did well. British and Italian leaders complained bitterly to the ESRO Council, de­manding that contracts be distributed to more closely match contributions to the organization.

The loss of carryover funds from ESRO’s first three years of operation caused a major financial crisis for ESRO, leading to several project cancella­tions. Although its cost overruns were smaller than those of many comparable American spacecraft projects, ESRO’s stringent financial rules amplified their effect. Technical troubles on TD-1 led to further cost increases, adding more pressure. When combined with the growing importance of nonscientific ap­plications like satellite telecommunications, pressure grew among the mem­ber states and within ESRO itself for changes in its goals and management. In response, the ESRO Council commissioned internal and external reviews to improve ESRO’s organization and management.

Systems management included techniques to improve engineering and reli­ability as well as methods for managers to coordinate and control large-scale development. The formal engineering methods ultimately used by Schriever’s organization, known as systems engineering, derived largely from military programs in World War II and the early Cold War. Schriever’s group would expand upon these ideas and ensure that they were adopted throughout the aerospace industry

Although historians have yet to determine all of the originators of sys­tems engineering, many of them were involved with the military. In addi­tion, systems engineering’s proponents almost all had connections with one of two major technological universities in the United States: the California Institute of Technology or the Massachusetts Institute of Technology (MIT). At Caltech, most early systems proponents received their education under the tutelage of famed aerodynamicist and first head of the air force’s Scientific

Advisory Board, Theodore von Karman. MIT’s systems approaches stemmed from the institute’s direction of the Radiation Laboratory and other military projects during World War II.2

One the primary sources of systems engineering was the organizational culture of American Telephone and Telegraph (AT&T). Bell Telephone Labo­ratories, perhaps the single largest group of researchers in the United States outside of academia, performed research and development (R&D) for AT&T. Bell Labs researchers typically assigned hardware prototype manufacturing to Western Electric, AT&T’s manufacturing arm. Because of the large size of the corporation and the multiplicity of projects, Bell Labs and Western Elec­tric developed formal specifications and paperwork to handle the relationship between Bell Labs researchers and Western Electric engineers and manufac­turing workers. In their relationships with outside contractors and the U. S. government, Bell Labs and Western Electric personnel found it natural to use these same formal methods. In this structured arrangement coordinating re­searchers and manufacturers was the kernel of systems engineering. Donald Quarles, who headed Bell Labs for a time and later became the assistant sec­retary of defense, was familiar and comfortable with Bell Labs’ ideas about systems engineering. Mervin Kelly, who also headed Bell Labs, became an in­fluential adviser to the air force on many systems.3

MIT became involved with Bell Labs and with systems engineering in part through the Radiation Laboratory’s development of fire control systems dur­ing World War II. One major protagonist was physicist Ivan Getting, who worked on an MIT liaison committee that coordinated the integration of a Radiation Laboratory tracking radar to a Bell Labs gun director on the SCR – 584 Fire Control System. He soon realized that because of electrical noise, the two components working together behaved differently than the two com­ponents alone. Getting had to analyze the behavior of the entire system, not just its components. Because of various wartime exigencies, Getting coordi­nated the efforts of General Electric, Chrysler, and Westinghouse to manu­facture the system, acting as the de facto systems integrator and engineer for the project.4

Learning from this, in 1945 Getting made himself the liaison between the Radiation Laboratory and the navy’s Bureau of Ordnance for the navy’s Mark 56 project. He assigned the Radiation Laboratory as the system integrator for the project. The laboratory made all technical information available to Gen­eral Electric and the navy, checked and criticized designs, sent representatives to conferences, reported to the Bureau of Ordnance on progress, participated in and established procedures for prototype, preproduction, and acceptance testing, and assisted in training programs. To accomplish these functions, Get­ting arranged for the Radiation Laboratory to receive copies of navy and con­tractor correspondence, drawings, and specifications; to be notified of signifi­cant tests and conferences; to examine production designs or models; to have access to contractors and their engineers; and to inspect equipment.5 These arrangements established the formal function of system integration.6 From Getting’s position as a member of the air force’s Scientific Advisory Board and as technical director for Air Defense Command, and from weapon systems engineering courses taught at MIT, the idea of systems engineering spread throughout the air force.7

The 1949 Ridenour Report that led to the founding of Air Research and Development Command (ARDC) noted, ‘‘The role of systems engineering should be substantially strengthened, and systems projects should be attacked on a ‘task force’ basis by teams of systems and component specialists orga­nized on a semi-permanent basis.’’ Transferring authority from the compo­nent engineers at Wright Field, the report recommended that the project offi­cers and engineers who integrated components be given substantially more authority and autonomy.8 Implementing the idea took a good deal of educa­tion and exhortation, along with new regulations. Maj. General Donald Putt, a protege of Caltech’s von Karman, became commanding officer of Wright Air Development Center in 1952. He admonished the laboratory chiefs, ‘‘Some­body has to be captain of the team, and decide what must be compromised and why. And that responsibility we have placed on the project offices.’’9 Engi­neering personnel in the project office acted as systems engineers, with the responsibility for the integration of technologies into the weapon system, whether aircraft or missiles.

Systems engineering also played a prominent role at Hughes Aircraft Com­pany, where Simon Ramo had assembled a skilled team of scientists and engi­neers to develop electronic gear for military aircraft and the innovative Fal­con guided missile. The Falcon differed from contemporary air-to-air missiles in that it used sophisticated electronics to guide the missile to its target and hit it. Other missiles typically placed a large warhead near an enemy aircraft, then detonated it nearby using proximity fuzes. These required substantial amounts of explosives and hence also a big, heavy missile to carry them. Ramo and Dean Wooldridge instead used what they called the systems approach to determine a more optimal design for air-to-air combat.10

Like MIT’s Getting, Ramo formulated his notions of systems engineer­ing through work on complex military projects. Although he had worked at General Electric, where a number of organizations had the word ‘‘system’’ in them, his work on various components did not stimulate any interest in the processes of engineering. Moving to Hughes Aircraft, and soon heading his own organization devoted to military electronics and missiles, Ramo began to think more seriously about the processes common to Hughes’s varied tasks. Wondering how best to formulate and pass on the expertise necessary to ad­dress the complexities of missiles and electronic systems, Ramo began to pro­mote the idea of an academic discipline of systems engineering. However, his first opportunities to pass along these ideas came not through publication but through his involvement with Schriever’s ICBM program.11

Ramo’s company came into being as a result of a meeting between Ramo and Secretary of Defense Charles Wilson in 1953. At that meeting, Wilson ex­pressed displeasure that the eccentric Howard Hughes had captured a near monopoly on aircraft and missile electronics through Ramo’s group. Wilson informed Ramo that he intended to ‘‘break this monopoly’’ and would sup­port Ramo if he separated from Hughes. This catalyzed Ramo and Wool­dridge’s decision to form their own company, a decision soon rewarded when Deputy Secretary of the Air Force Trevor Gardner awarded them a contract to support John von Neumann’s ‘‘Teapot Committee’’ (chapter 2). Gardner was an old friend of Ramo’s, but despite this, Ramo and Wooldridge did not really want the ICBM systems engineering job because they correctly perceived that this would hinder their efforts to land lucrative hardware contracts. When the air force informed them in early 1954 that they would not acquire any air force contracts unless they took the ICBM systems engineering job, R-W accepted the contract from Schriever’s group.12

Schriever fostered close working relationships between R-W, the WDD of ARDC, and the SAPO of Air Materiel Command (AMC). Schriever and Ramo agreed that R-W personnel should be placed in offices adjacent to those of

Brigadier General Bernard Schriever and Dr. Simon Ramo at a building dedication at the Inglewood complex in 1956. Courtesy John Lonnquest.

their WDD counterparts. For example, the office of Schriever’s technical di­rector, Charles Terhune, was next to that of the R-W technical director, Louis Dunn. At the highest level, Schriever and Ramo were in frequent contact.13

Despite the close contact, the function of R-W personnel was not clear to Schriever’s group as late as April 1955. Schriever directed Ramo to assemble a briefing to describe for his officers and contractors the processes and tasks that R-W performed.14 This briefing was one of the earliest descriptions of systems engineering. R-W formed its Guided Missile Research Division (GMRD) in 1954 to handle the technical aspects of the ICBM programs. With Ramo head­ing the division and Louis Dunn, the former Jet Propulsion Laboratory (JPL) director, as technical deputy, the GMRD in April 1955 had five departments: Aeronautics R&D, Electronics R&D, Systems Engineering, Flight Test, and Project Control. While the Aeronautics and Electronics departments concen­trated on subsystems and components, the Systems Engineering, Flight Test,
and Project Control departments performed the bulk of ICBM integration tasks.15

Technical direction of contractors took place through monthly formal meetings as well as numerous informal meetings. R-W Project Control per­sonnel chaired the formal meetings, set the agenda, recorded minutes, and presented current schedules and decisions. Based on the results of these meet­ings, the Project Control Department issued Technical Directives, work state­ments, and contract changes. WDD officers reviewed Technical Directives, along with changes to work statements. They then submitted work statements and contract changes to the SAPO, whose officers then issued contractual changes and approved work statement modifications. Informal meetings were for “information only,’’ and WDD and R-W personnel coordinated this infor­mation as necessary. The Project Control Department handled official plans, schedules, work statements, cost estimates, and contract changes.16

Engineers in R-W’s Systems Engineering Department analyzed major de­sign interactions, studied electrical and structural compatibility between sub­systems and contractors, and issued top-level requirements. One good ex­ample was the nose cone trade study that cut Atlas’s mass in half. Another was an assessment of the Martin Company’s trajectory analysis. Department members found that Martin’s trajectory was less than optimal; by modify­ing it, R-W engineers increased the Titan’s operational range by 600 miles, the equivalent of saving 10% of its mass. R-W systems engineers performed experimental work in the laboratory when they needed more information, analyzed intelligence data on Soviet tests, and programmed early missiles. As noted by one critic of R-W, the engineers often double-checked contractors to avoid ‘‘errors, mistakes, and failures.’’17

By October 1956, the WDD and R-W came to a legal agreement about what systems engineering entailed. The agreement defined systems engineering in terms of three functions:

1. The solution of interface problems among all weapon system subsystems to insure technical and schedule compatibility of the systems as a whole.

2. The surveillance over detailed subsystem and over-all weapon design to meet Air Force required objectives.

3. The establishment and revision of program milestones and schedules, and

monitoring of contractor progress in maintaining schedules, consistent with sound technical judgment and rapid advancement of the state of the art.18

From 1953 through 1957, R-W’s role grew dramatically. Starting with docu­mentation of the Teapot Committee’s deliberations, R-W acquired a contract with Schriever’s new organization to perform long-range studies of ICBMs, to assess new technologies, and to help the WDD set up and operate its new facilities. Its funding grew from $25,494 through June 1954, to $833,608 from July 1954 through June 1955, and to $10,095,545 from July 1955 through June 1956. As R-W’s competence grew, Schriever expanded its role. R-W double­checked contractors’ work; controlled specifications, schedules, and other paperwork; and surveyed the technical horizon for new technological solu­tions. As Schriever himself later admitted, R-W became for the WDD what Wright Field and its component engineers were for aircraft development. For the first few years of expansion, R-W’s services were indispensable to the WDD; they cut program costs and improved ballistic missile performance.19

Along with systems engineering, Schriever initiated other methods to man­age the program. As he well knew, the system approach required planning for the entire weapon life cycle from the start of the program. One of Schriever’s first actions was to establish a centralized planning and control facility to facilitate application of this idea. The WDD established its own local and long­distance telephone services, including encrypted links for classified informa­tion and teletype facilities.

In the fall of 1954 Schriever and his staff developed a management control system. Every month, they required the air force, R-W, and associate contrac­tors to fill out standardized status report forms. One of Schriever’s officers controlled and updated the master schedules, placed on the walls of a guarded program control room. This room was both a place where managers could quickly assess the ‘‘official’’ status of the program and a place where Schriever and his deputies showed the program status and innovative management to visitors.20

A primary benefit of the management control system was the process of preparing the weekly and monthly status reports. Report preparation required that managers collect and verify data, identify problems, and make recom­mendations about how to resolve them. Schriever instituted monthly ‘‘Black Saturdays’’ for project officers to report difficulties. At these meetings, Schrie­ver and his top R-W and military staff reviewed the entire program and as­signed responsibility for resolving all problems to individuals there. These meetings endeavored to bring problems forward instead of sweeping them under the rug. As Schriever put it, ‘‘The successes and failures of all the de­partments get a good airing.’’21

While Black Saturdays brought some order to the technical aspects of the program, the Procurement Staff Division of the Ballistic Missiles Office at air force headquarters had to cope with the legal and financial mess created by Schriever’s disregard for standard processes. The financial officers insisted that ‘‘the technical directives [be] covered by cost estimates’’ because annual fund­ing from the DOD was insufficient to cover rising costs. Schriever fought these regulations as ‘‘examples of the ‘law’s delay’ ’’ but had to give in. In November 1956 he agreed to submit cost estimates, leading to new procedures in Febru­ary 1957. To ensure that R-W and the other contractors documented technical directives, the Guidance Branch of the WDD in October 1956 ‘‘began holding a contract administration meeting immediately after each technical directive meeting.’’ By January 1957 the Procurement Staff Division extended the prac­tice to all technical direction meetings.22

With these new procedures to coordinate the legal and financial aspects of ICBMs, the air force could map out the ramifications of the various changes to the ICBM programs. Although this allowed for a modicum of order across the air force, only upcoming missile tests could determine whether the Atlas and the Titan would fly.

MSFC’s conservative tradition of rocket development traced back to von Braun’s work with the German Army in World War II and the U. S. Army thereafter. Step-by-step, precise methods characterized von Braun’s approach to rocketry. Each rocket drew upon the designs and experiences of previous rockets. Engineers made small changes in each successive rocket and tested each change to ensure that it did not compromise the design. They consid­ered flights successful even if they ended in explosion as long as they collected sufficient data to determine the explosion’s cause.31 Once designers found the problem, they modified the design and flew it to test the fix. Based on their many years of experience, they believed it virtually impossible to design an engine or a rocket without significant difficulties.

Although MSC and MSFC engineers differed in a number of ways, one similarity was distrust of contractors. Essentially, both MSFC and MSC engi­neers took apart and rebuilt the stages and capsules that contractors delivered to them. Boeing’s contract for the Saturn S-I first stage was a good example. MSFC’s original contract, awarded after a competition in 1962, gave Boeing partial responsibility for stage design and assembly but little responsibility for booster specifications or testing. Later contracts gave Boeing progressively more responsibility, until it was responsible for all aspects of the stage except for mission operations.32

Borrowing and extending practices from the air force and the navy, NASA closely controlled the contractors. NASA used Resident Manager’s Offices to monitor the contractors. NASA realized that on-site surveillance was “some­what sensitive from the point of view of the contractor’’ but persisted because of its belief in face-to-face communication, its distrust of contractor capabili­ties, and its trust in its own capacities. NASA’s infringement on contractor prerogatives included forced renegotiation of contracts and designs. For ex­ample, Lunar Excursion Module (LEM) contract winner Grumman supposed that it would build the design presented in its bid. Instead, NASA engineers redesigned the LEM and the contract.33

NASA Administrator James Webb expanded contractor penetration to penetration of its own field centers. He wanted a separate information chan­nel to check his own organization, and he hired GE for this purpose. The GE Policy Review Board, established in December 1962, was to provide system­wide coordination and integration. Neither MSC personnel nor MSFC per­sonnel wanted headquarters or GE to integrate them, however. As one GE manager later explained, ‘‘Frankly, they didn’t want us. There were two things against us down there [at MSC]. No. 1, it was a Headquarters contract, and it was decreed that the Centers shall use GE for certain things; and [No. 2] they considered us Headquarters spies.’’34 MSC management hampered GE’s attempts to fulfill its integration role, prohibiting “unannounced visits’’ and forbidding GE from taking any significant action unless approved by MSC. Field center resistance was effective, for in July 1963, Apollo’s new Panel Re­view Board abolished GE’s board. Later, after a long briefing to Administrator Webb, Apollo program director Phillips removed systems integration from GE’s contract.35

Headquarters also contracted with American Telephone and Telegraph (AT&T) to provide technical assistance. AT&T created a separate company called Bellcomm to provide headquarters with technical consultants, whom headquarters used to cross-check the field centers in the way that The Aero­space Corporation checked contractors for the air force. Bellcomm ultimately performed exemplary work in trajectory analysis, but field center engineers and managers avoided Bellcomm representatives because they believed them to be headquarters spies. The use of GE and Bellcomm failed to provide NASA executives with the means to control the field centers, because of the unequal power between the government and industry. NASA provided the funds, and industrial contractors were uncomfortable criticizing their source of funding. They knew better than to bite the hand that fed them.36

Perhaps the greatest challenge to NASA and contractor engineers was to make their new vehicles absolutely reliable so that humans could fly in them. Redundancy was one common technique to improve reliability. For example, MSFC engineers designed each Saturn stage with clusters of engines, so that if one failed, the remaining engines could continue the mission. Man-rating the air force’s Atlas and Titan missiles primarily meant adding redundant elec­tronic circuitry and failure detection circuits to the missile. NASA engineers thought of astronauts as redundant design elements that could improve the chances for mission success by taking over spacecraft functions if components failed.37

Ensuring high quality and safety was as much a function of management and organization as engineering design. Because a number of booster and capsule components were single string-meaning that if they failed, there were no separate backups-STG engineers rigorously verified individual components for high quality. In turn, quality depended upon every worker building each component with the finest workmanship.

The manned programs instituted special methods to make factory workers

aware of the importance of high quality. Taking advantage of the projects’ prestige and visibility, Mercury and Gemini managers distinguished NASA components and workers using special symbols. On the Gemini Titan II pro­gram, Martin management gave special worker certifications to top employ­ees, along with orientations, emblems, labels, badges, and even distinctive toolboxes, ‘‘painted Air Force blue and individualized with each worker’s name.’’ Astronauts visited production lines to encourage high standards and workmanship. Based upon Space Technology Laboratories (STL) recommen­dations, the program adopted strict inspections and random part checking for quality control. Tight control over manufacturing contrasted sharply with MSC’s loose internal structure and processes.38

Worker motivation for Apollo was extraordinary, contributing signifi­cantly to the high quality of components that went into the project. Most of the time, this was a major advantage. However, occasionally, it caused prob­lems. For example, at NAA, the wiring harnesses for the command module occasionally disconnected when the pins broke off in the connectors. They ‘‘found one lady out there who had evidently extremely strong hands, and she knew that she was working on the Apollo Program, so when she crimped, she crimped extremely hard, and she could actually crimp hard enough to de­form the tool and squeeze the wires to where they were almost broken. She was just trying to do her job a little better than normal, but actually she was causing us a lot of trouble. For her, they put a spatial stop on the tool so that she couldn’t crimp it any harder.’’39

Mercury and Gemini engineers created a system to track individual parts with manufacturing and test histories — to ensure that only fully documented, flawless parts became flight components. General Dynamics and Martin man­agers designated Mercury and Gemini launch vehicle components as critical, with special tags, paperwork, and procedures. At Martin, vehicle chaperones accompanied each vehicle through manufacturing, moving the vehicle and its paperwork through the factory. Using Martin’s program as a model, the air force and NASA initiated a similar program at Lockheed for the Agena tar­get vehicle. At the Factory Roll-Out Inspection, NASA thoroughly reviewed records for each vehicle component. Mercury engineers started their quality control program late, resulting in many component replacements when the

capsule or its components failed acceptance tests. Learning from this, Gemini managers began their quality control program right at the start.40

Military models were the basis for most of the STG’s few formal processes early in the program. The Source Evaluation Board was one example, as was the Mock-Up Inspection Board, a formal inspection of a full-scale system model. Another was the Development Engineering Inspection, where STG engineers certified the design to be ready for flight. Hardware qualification was another military import, using rigorous environmental tests to stress components. On the Apollo spacecraft, contractors prepared for the Space­craft Assessment Review, Customer Acceptance Readiness Review, and Flight Readiness Review. Contractors submitted written reports, which NASA com­mittees reviewed. Starting on Mercury, NASA also held flight safety reviews for each spacecraft to review modifications, testing, and preparations for launch and operations.41

Engineers at both centers believed in uncovering design problems through extensive tests and analyses. STG Director Gilruth and MSFC Director von Braun both believed that testing led to better understanding and improved designs. MSFC engineers tested engine stability by exploding small bombs in the rocket’s exhaust path to ensure that unexpected flow variations in the en­gine’s hot gases would not create instabilities that could lead to an explosion. STG engineers injected electrical failures into their designs to ensure that they would survive. Following air force ballistic missile practices, they searched for critical weaknesses in the design, making changes when they found them.42

NASA and its contractors tested components to ensure that they could sur­vive launch vehicle vibrations, the thermal and vacuum environment ofspace, and electromagnetic interference between electronic components. They also performed life tests to see how long components would last. Once compo­nents completed component tests and Preinstallation Acceptance Tests, engi­neers and technicians integrated them into a capsule. Contractors then ran Capsule System Tests, which verified that electronic wiring was working and that mechanical devices were functioning properly.43

One item not easily tested was the performance of the environmental and thermal control system of the entire Mercury capsule. Although vacuum chambers existed, none were large enough to test the whole vehicle. In late 1960, STG and McDonnell engineers developed a large vacuum chamber in which they could test the entire capsule’s environmental and thermal controls. This task, known as Project Orbit, found numerous problems, particularly in the reaction control system used to keep the capsule pointed correctly in space.44

To manage the large number of engineering alterations, the STG estab­lished for Mercury a Change Control Group, whose membership fluctuated based on the nature of the problem. Configuration control crept into the pro­gram through the air force’s supply of launchers for NASA. The air force estab­lished configuration control for Gemini’s Titan II in December 1962. Gemini engineers ‘‘froze’’ portions of the spacecraft design as early as March 1962, and Apollo contractors froze elements of their designs by June 1963.45

Despite these efforts, Mercury’s first test flights suffered their share of fail­ures. The first occurred in July 1960 during the first full-scale test of the Mer­cury capsule mounted on an Atlas booster. About one minute after launch, the booster failed as it accelerated through the period of highest aerodynamic pressure, leaving NASA and the air force to search for debris in the Atlantic off Cape Canaveral. The evidence pointed to a structural failure in the interface between the Atlas and the Mercury capsule, based on mechanical differences between the Mercury capsule and the Atlas’s normal complement of nuclear warheads. Engineers had not found this problem in earlier tests because they could not fully simulate the physical dynamics of the vehicle in flight. Fol­lowing the failure, the Mercury-Atlas coordination panel formed a new com­mittee to find and resolve interface problems. The next successful test flight, in February 1961, featured a structure-stiffening ‘‘belly band.’’ Engineers later included vibration and structural resonance characteristics of the combined launch vehicle-payload system in interface designs and documentation.46

Interface problems also dogged a test flight aboard MSFC’s Redstone booster in November 1960. The launcher lifted off the ground about four inches, then settled back onto the pad while the capsule’s escape rocket launched, dragging erroneously opened parachutes. Subsequent investiga­tions traced the failure to a timing problem between the Redstone electronics and the launch complex, caused by the different weight of the Mercury capsule compared to Atlas’s normal payload ofweapons. The weight difference caused a slightly delayed mechanical disconnection time for a shutoff signal to the

Redstone engines, resulting in the firing of the capsule escape system. MSFC engineers quickly fixed the problem, and the next test flight, in December 1960, was a success.47

These failures caused STG engineers to reevaluate their design philosophy. In a report to headquarters, they stated, ‘‘It has become obvious that the com­plexity of the capsule and the booster automatic system is compounded dur­ing the integration of the systems.’’48 Engineers from the STG, the air force, and the contractors investigated the causes of the numerous failures and fran­tically improved the design of the boosters, the capsules, and the interfaces between them. One important way in which NASA and the air force for­malized these relationships and processes was through the development of interface specifications that defined electrical and mechanical connections be­tween the capsule and the launch vehicle, along with vibration and accelera­tion loads.49

Mercury flight failures led to increased attention to Gemini and Apollo interfaces. In June 1963, the air force, NASA, Martin, and McDonnell initi­ated investigations of the structural and electronic interfaces between Titan and the Gemini spacecraft. Gemini managers created the Systems Integration Office in February 1964 to monitor spacecraft weight and interfaces between the spacecraft, the launch vehicle, and the Agena target vehicle with regular coordination meetings known as Interface Control Panels. Interface Specifi­cation and Control Documents recorded the results of these meetings. Engi­neers developed new tests, including electronic-electrical interference tests, joint combined systems tests, flight configuration mode tests, and wet mock simulated launch tests, all of which verified interfaces and launch procedures on the launch pad. Apollo personnel began to work on interface problems in July 1963, when the Panel Review Board standardized Interface Control Docu­ments and made MSFC the Apollo document repository.50

The STG and its successor, MSC, evolved from NACA’s hands-on research culture. Despite massive growth, the STG maintained informal mechanisms for coordination and control. MSFC too held fast to its discipline-based army heritage. Both organizations benefited from military and industrial processes used by their contractors. Because of their prestige and deep pockets, the manned programs commanded attention from everyone, from the top of the management hierarchy to the shop floor workers at contractor facilities.

Both MSC and MSFC were ultraconservative concerning their own de­signs. They emphasized reliability and safety above cost, allowing costs to in­crease. The exemplary flight records of Mercury and Gemini showed that this conservatism could help ensure that technical objectives were achieved. Con­sidering that the air force was then instituting a program to improve Atlas’s reliability to 75%, achieving a perfect flight record was no easy feat.51 However, the field centers’ proclivity to increase costs was a weakness soon exploited by Congress and NASA headquarters to tighten control.

Dutch physicist J. H. Bannier, former chairman of the CERN Council, headed ESRO’s external review. Bannier’s commission recommended strengthening project management by giving project managers control over technical spe­cialists and control over expenditures, ‘‘within well defined limits, in the same way as . . . the technical aspects of the work’’ were controlled. The com­mission also recommended that ESRO have more responsibility to issue and monitor contracts to relieve the Administrative and Financial Committee of trivial duties. It also advised separating policy decisions at ESRO headquar­ters from day-to-day project management and technical duties at ESTEC. Director-General Bondi defined new financial rules in November 1967 to en­sure a minimum 70% return of funding to member countries from ESRO con­tracts. By 1968, ESRO had implemented the bulk of the commission’s recom­mendations.50

Financial problems with the TD project and industry’s assertiveness spurred ESRO’s internal review, which focused on improvements to project implementation. Director-General Bondi initiated ‘‘urgent actions,’’ leading to the development of a working paper by Schalin, an ESRO headquarters ad­ministrator. Schalin’s paper, presented to the ESRO Council in March 1968, presented a blueprint for improving procedures for ‘‘forecasting, preparing for and implementing major projects in ESRO.’’ Basing his paper on ‘‘previ­ous efforts and a recent visit to NASA,’’ Schalin proposed changes to project cost estimation, contracting procedures, and project control.51

To improve cost estimation, Schalin proposed a version of NASA’s phased project planning, along with project cost-estimating formulas that GSFC ad­ministrators were developing. Schalin noted that on TD-1/2, ESRO and the MESH consortium did not develop reliable cost estimates until one year after contract award. On other contracts, a stable estimate did not occur until 75% of the funds had been committed. Schalin proposed that ESRO spend 5-10% of the total project cost for project definition and design phases to develop accurate cost estimates prior to final contract decision. He recom­mended adoption of Project Definition and Detailed Design Definition phases between feasibility studies and the development contract award. Both phases would use competitive study contracts lasting six to twelve months, using either fixed-price or cost-plus-fixed-fee contracts.

Schalin realized that past experience was the most reliable guide for early forecasts. With little experience, ESRO’s forecasts were problematic. NASA, on the other hand, had developed spacecraft cost-estimating formulas with a purported accuracy of 10-20%. ESRO administrators evaluated cost-estimat­ing techniques from GSFC and the Illinois Institute of Technology Research Institute, finding that ESRO spent a higher proportion of funding on admin­istration and less on hardware than did GSFC. This surprised ESRO admin­istrators, who had expected that their costs would be less than those of the United States. Instead, this ‘‘Atlantic factor’’ represented ESRO’s more difficult communication problems.52

Finally, Schalin recommended substantial changes to ESRO’s project con­trol methods. He noted that HEOS-A had developed extensive project con­trol procedures, which TD-1/2 implemented only after a huge underestimate. Schalin proposed a stronger contract support organization, in conjunction with rigorous change control based on detailed specifications, implemented through a network plan with work breakdown structures tied to the account­ing system. Schalin’s paper became the starting point for ESRO’s project man­agement reforms.53

By fall 1968, the Bannier committee’s organizational reforms and Schalin’s recommendations took effect. ESRO managers restructured the budget and introduced a new financial plan. ESTEC managers found that for current projects, ‘‘HEOS A2, being essentially a repeat, and the Special Project [TD-1], being further advanced, cannot be fully adapted to the new procedures.’’ For these, ESTEC increased the project manager’s authority with ‘‘extra staff con­trolling cost and contract matters.’’ It also provided more technical support

to project teams and implemented a ‘‘combined network/work package/cost control system.’’54

After considering the “possibility for the Organisation taking over the prime contractorship from industry,’’ TD-1 managers added twenty-three full-time personnel to the project, including eight for a new Project Con­trol Section, bringing the total to fifty. In addition, TD-1 used part-time staff from the technical divisions — the equivalent of forty full-time employees.55 Managers divided the MESH consortium’s tasks into 600 work packages, monitored on a monthly cycle of ‘‘data collection-processing-presentation- interpretation-decision.’’ For HEOS-A2 and ESRO-IV, which were follow-up projects to HEOS and ESRO-II, ESTEC managers used phased planning, al­though without competition.56

Phased planning crystallized into full-fledged procedures in June 1969, with the release of ESRO’s Phased Planning for Scientific Satellite Projects Guidelines. ESRO management intended phased planning to provide ‘‘clear and logi­cal build-up stepwise of information for management decisions’’ that maxi­mized project insight, yet minimized project commitment up to the deci­sion points. The guidelines defined six phases: mission studies, preliminary feasibility studies, project definition and selection, design and detailed defi­nition, development, and operations. For each phase, ESRO defined specific processes and products, which organization was to produce them, and who was to decide whether to proceed. By November 1969, ESRO’s Administra­tive and Finance Committee translated the phased planning guidelines into new procedures for satellite contracts. ESRO used the full phased planning procedure on its next satellite, COS-B.57

A second major initiative sponsored by Director-General Bondi was the development of a management information system (MIS). In August 1968, Bondi approved a proposal to establish an MIS Study Group. The study group’s efforts converged with ongoing activities at ESTEC to develop a proj­ect control system.58

Two MIS models stood out as particularly relevant: the Centre National d’Etudes Spatiales (CNES, the French space agency) chart room, and the NASA Marshall Space Flight Center (MSFC) MIS. The CNES chart room was entirely manual, where the chart room itself was the ‘‘data bank’’ of histori­cal, statistical, operational, and project information. MSFC’s system was an

Hoernke’s analogy of engineering and project control.

example of a fully computerized MIS that handled inventory, PERT project information, parts and reliability data, and videotape and library collections.59

To help determine what kind of system would be appropriate, MIS Study Group member H. Hoernke compared the concept of project control to the more general concept of control in engineering. He defined five components of an engineering control system: the process to be controlled; the sensor; the collator, which compares ‘‘what is taking place with what should be taking place’’; the memory, which records the standard for what should be hap­pening; and the effector, which changes the process toward the standard. On projects, various organizations performed the functions of the sensor, collator, memory, and effector. In his analogy, the project control group acted as the collator of data collected by various teams, and management acted as the effector.60

By November 1968, ESTEC personnel decided to use the IBM PMS 360 pro­gram for project control.61 This restricted management information to items compatible with the PMS program, including cost and schedule information stored in work breakdown structures. The IBM program could print a num­ber of standard reports, which Hoernke described in his assessment. In that same month, Hellmuth Gehriger of the ESTEC Contracts Division proposed to extend his division’s work to include “management services.’’ In early 1969, ESTEC management approved his proposal to create a Management Services Section, which would perform research on managerial problems, recommend standards, keep statistics on management performance, and aid ongoing pro­grams. Gehriger also proposed that this group, eventually called the Project Control Section, perform operations research and systems analysis studies.62

The MIS Study Group found numerous cases of redundant information generation, haphazard use, inconsistent levels of detail, and widely varying implementation of procedures and automation within ESRO. It concluded that creating an MIS would be a formidable task but provide substantial bene­fits. Aside from standard arguments that an MIS would improve management performance and organizational efficiency,63 the MIS group also argued for an MIS for political reasons. Foreseeing a possible merger with ELDO and CETS, the group deduced, ‘‘When two or more organisations merge, it is clearly the one that has the more organised structure that is at an advantage.’’ The group stated, ‘‘To control its contractors, ESRO must at least be as efficient as indus­try in managing the information problem.’’ It thought ‘‘ESRO should play a leading role in getting industry used to advanced management techniques.’’ In the opinion of group members, an MIS would give ESRO a distinct advantage in the coming bureaucratic battle.64

With Bondi’s endorsement, the MIS Study Group decided to develop a ‘‘semi-integrated system’’ where each ESRO facility would have its own com­puter system. This had the advantage of virtually ensuring the “rationalisation of information’’ at that site but the disadvantage of potentially promoting in­formation barriers between ESRO sites. A fully centralized system at Paris, the group believed, would be very complex and would politically generate ‘‘high resistance,’’ both from ESRO personnel at other facilities and from the national delegations.65

The resulting distributed computer system, called the Planning, Manage­ment, and Control (PMC) System, began operation in January 1971. At the be­ginning of a project, managers and engineers entered financial and schedule information, coded as work package numbers tied to the accounting system. The system generated reports, including internal budgets, plans, differences between plans and actual events, and changes to plans.66

At ESTEC, the Project Control Section of the Contracts Division ran the PMC System. The section’s director, Hellmuth Gehriger, became a vocal man­agerial theorist. He believed that project control was rapidly developing into a science. The project manager determined what had to be ‘‘project con­trolled,’’ and the project controllers determined how to manage the projects. Gehriger used the critical path method to schedule tasks in the phased plan­ning cycle and produced planning and control documents and information

The ESRO Planning, Management, and Control System.

flows to closely monitor project cost and schedule. From reported status in­formation, project control personnel prepared a Key Event Schedule Trend Analysis report that monitored schedule trends for slippage, a sign of im­pending technical and cost difficulties. Under Gehriger’s guidance, the Project Control Section developed a sophisticated management scheme that adapted American managerial concepts to the European context.67

ESRO management did not give its project managers complete control. In December 1969, the head of ESTEC’s Satellites and Sounding Rockets Depart­ment proposed that ESTEC assign all project personnel to his department, thereby giving him and the project manager control over all project person­nel. ESRO Director of Administration Roy Gibson refused. Although Gibson agreed that ESTEC’s use of manpower was ‘‘extravagant,’’ he did not “recom­mend the same cure.’’ Gibson believed that the proposal would ‘‘lead to the

Satellites and Sounding Rockets Department becoming an independent state within a state.’’ Instead, Gibson argued for better coordination of manpower within a matrix system. This accorded with the opinion of the head of the Personnel Department, who noted that the ‘‘home division’’ contained the ‘‘reservoir of knowledge’’ required for projects.68

Over the next four years, ESRO managers struggled with the division of authority between the project manager and the technical divisions. ESTEC established a new Programme Coordination Division to coordinate person­nel between the projects, the technical divisions, and the European Space Operations Centre. After difficult negotiations, ESTEC Director Hammar – strom issued a directive that required project managers to create and review a support plan twice each year and to request support from technical divisions through standardized forms.69

ESRO’s financial and political crises of 1967 and 1968 spurred a series of or­ganizational reforms. Under pressure from national delegations and Director – General Bondi, ESRO managers followed a path well trodden by the U. S. De­partment of Defense and NASA. ESRO adopted phased planning to provide management decision points and better cost estimates. For the TD project, it was too late to implement phased planning, so instead ESRO created the Project Control Section and implemented configuration management tech­niques, which ESRO used on all later programs. By 1971, the ESRO MIS was partially operational at ESTEC under Gehriger’s Project Control Section. ESRO personnel looked forward to the impending merger with ELDO and CETS, believing they had the organizational advantage.

The merger would soon take place, spurred by ELDO’s failure as well as the opportunities and hazards ofthe American shuttle program. On Spacelab, the Europeans’ contribution to the shuttle, the new ESA changed from being NASA’s junior apprentice to being NASA’s partner. To make this partnership work, NASA would require even further ‘‘Americanization’’ of European man­agement methods.

Whatever preferences Schriever and his team had for rapid development, they insisted upon flight tests to detect technical problems. ICBMs were extremely complex, and some failures during initial testing were inevitable. Testing would uncover many problems as it began in late 1956 and 1957.

Missile testing differed a great deal from aircraft testing, primarily because each unpiloted missile flew only once. For aircraft, the air force used the Un­satisfactory Report System, whereby test pilots, crew members, and mainte­nance personnel reported problems, which were then relayed to Wright Field engineers for analysis and resolution. The problem with missiles was the lack of pilots, crew members, and maintenance personnel during development testing. Instead, manufacturers worked with the air force to run tests and ana­lyze results.23

Because each ICBM disintegrated upon completion of its test flight, flight tests needed to be minimized and preflight ground testing maximized. The high cost of ICBM flight tests made simulation a cost-effective option, along with the use of ‘‘captive tests,’’ where engineers tied the rocket onto the launch pad before it was fired. R-W engineers estimated that for ICBMs to achieve a 50% success rate in wartime, they should achieve 90% flight success in ideal testing conditions. With the limited number of flight tests, this could not be statistically proven. Instead, R-W thoroughly checked and tested all compo­nents and subsystems prior to missile assembly, reserving flight tests for ob­serving interactions between subsystems and studying overall performance. Initial flight tests started with only the airframe, propulsion, and autopilot. Upon successful test completion, engineers then added more subsystems for each test until the entire missile had been examined.24

By 1955, each of the military services recognized that rocket reliability was a problem, with ARDC sponsoring a special symposium on the subject.25 Statis­tics showed that two-thirds of missile failures were due to electronic compo­nents such as vacuum tubes, wires, and relays. Electromagnetic interference and radio signals caused a significant number of failures, and about 20% of the problems were mechanical, dominated by hydraulic leaks.26

Atlas’s test program proved no different. The first two Atlas A tests in mid- 1957 ended with engine failures, but the third succeeded, leading eventually to a record of three successes and five failures for the Atlas A test series. Simi­lar statistics marked the Atlas B and C series tests between July 1958 and Au­gust 1959. For Atlas D, the first missiles in the operational configuration, re­liability improved to 68%. Of the thirteen failures in the Atlas D series, four were caused by personnel errors, five were random part failures, two were due to engine problems, and two were design flaws.27

Solving missile reliability problems proved to be difficult. Two 1960 acci­dents dramatized the problems. In March an Atlas exploded, destroying its test facilities at Vandenberg Air Force Base on the California coast. Then, in December, the first Titan I test vehicle blew up along with its test facilities at Vandenberg. Both explosions occurred during liquid propellant loading, a fact that further spurred development of the solid propellant-based Minute – man missile. With missile reliability hovering in the 50% range for Atlas and around 66% for Titan, concerns increased both inside and outside the air force.28

While the air force officially told Congress that missile reliability ap­proached 80%, knowledgeable insiders knew otherwise. One of Schriever’s deputies, Col. Ray Soper, called the 80% figure “optimistically inaccurate’’ and estimated the true reliability at 56% in April I960.29 That same month, Brig. Gen. Charles Terhune, who had been Schriever’s technical director through the 1950s, entertained serious doubts:

The fact remains that the equipment has not been exercised, that the reliability is not as high as it should be, and that in all good conscience I doubt seriously if we can sit still and let this equipment represent a true deterrence for the Ameri­can public when we know that it has shortcomings. In the aircraft program these shortcomings are gradually recognized through many flights and much train­ing and are eliminated if for no other reason, by the motivation of the crews to keep alive but no such reason or motivation exists in the missile area. In fact, there is even a tendency to leave it alone so it won’t blow up.30

ICBM reliability problems drew air force and congressional investigations. An air force board with representatives from ARDC, AMC, and Strategic Air Command reported in November 1960, blaming inadequate testing and train­ing as well as insufficient configuration and quality control. It recommended additional testing and process upgrades through an improvement program. After the dramatic Titan explosion the next month, the secretary of defense requested an investigation by the Weapon Systems Evaluation Group within the Office of the Secretary of Defense. A parallel study by the director of De­fense Research and Engineering criticized rushed testing schedules. In the spring of 1961, the Senate Preparedness Investigating Subcommittee held hear­ings on the issue. The members concluded that testing schedules were too optimistic. With technical troubles continuing, its own officers concerned, and congressional pressure, Schriever’s group had to make ICBMs operation­ally reliable. To do so, the air force and R-W created new organizational pro­cesses to find problems and ensure high quality.31

Solving ICBM technical problems required rigorous processes of testing, inspection, and quality control. These required tighter management and im­proved engineering control. One factor that inadvertently helped was a tem­porary slowdown in funding between July 1956 and October 1957. Imposed by the Eisenhower administration as an economy measure, the funding reduc­tion slowed development from ‘‘earliest possible’’ deployment (as had been originally planned) to ‘‘earliest practicable’’ deployment. As noted by one his­torian, this forced a delay in management decisions regarding key technical questions related to missile hardware configurations, basing, and deployment. This, in turn, allowed more time to define the final products.32

Reliability problems were the most immediate concern, and AMC officers began by collecting failure statistics, requiring Atlas contractor General Dy­namics to begin collecting logistics data, including component failure statis­tics, in late 1955. In 1957 AMC extended this practice to other contractors, and it later placed these data in a new, centralized Electrical Data Processing Cen­ter.33 R-W scientists and engineers statistically rationed a certain amount of ‘‘unreliability’’ to each vehicle element, backing the allocations with empiri­cal data. They then apportioned the required reliability levels as component specifications.34

Starting on Atlas D, Space Technology Laboratories (STL)-the succes­sor to R-W’s GMRD-scientists and engineers began the Search for Critical Weaknesses Program, in which environmental tests were run to stress com­ponents ‘‘until failure was attained.’’ The scientists and engineers ran a series of captive tests, holding down the missile while firing the engines. All compo­nents underwent a series of tests to check environment tolerance (tolerance for temperature, humidity, etc.), vibration tolerance, component functions, and interactions among assembled components. These required the develop­ment of new equipment such as vacuum chambers and vibration tables. By 1959, the Atlas program also included tests to verify operational procedures and training. STL personnel created a failure reporting system to classify fail­ures and analyze them using the central database.35

Environmental testing, such as acoustic vibration and thermal vacuum tests, detected component problems. The failure reporting system also helped

Atlas D launch, October 1960. Atlas reliability began to improve with the D series. Courtesy John Lonnquest.

identify common weaknesses of components. Other new processes, such as the Search for Critical Weaknesses Program, looked for problems with compo­nents and for troublesome interactions. These processes identified the symp­toms but did not directly address the causes of problems. For example, some component failures were caused by a mismatch between the vehicle flown and the design drawings. Solving problems, as opposed to simply identify­ing them, required the implementation of additional social and technical pro­cesses. Engineers and managers created the new social processes required on the Minuteman project, and from there they spread far beyond the air force.

In technical terms, NASA’s organization and procedures proved successful on Mercury and Gemini. Both programs boasted enviable flight records, com­pleting their objectives and successfully returning their astronauts on every flight. On the other hand, both programs featured large cost increases. Mc­Donnell’s Mercury capsule contract grew at an astounding rate, from an initial contract of $19,450,000 in 1959 to a total of $143,413,000 by the program’s end in 1963. Within months of its start, Gemini was headed for large cost increases as well. NASA funded the increases, although Congress began to ask questions in the fall of 1962.52

OMSF’s Holmes, overseeing the three manned space flight programs, saw the escalating cost trends as well as anyone. A hard-nosed project manager from Radio Corporation of America’s (RCA’s) Ballistic Missile Early Warn­ing System, Holmes realized that something had to be done if Apollo was to meet Kennedy’s 1969 deadline to land a man on the Moon. Holmes also rec­ognized that Kennedy had staked his reputation on the manned program and would go to great lengths to ensure its success. Based on this, he felt no par­ticular need to control costs and instead requested more funds from NASA Administrator Webb.53

Holmes first asked Webb to go back to Congress for a supplemental appro­priation. Despite Kennedy’s support, Webb recognized that Congress was be­coming uneasy about NASA’s burgeoning costs, and he refused. Holmes next demanded that Webb strip other NASA programs to support the manned pro­gram. When Webb again refused, Holmes went over his head, appealing di­rectly to President Kennedy. This infuriated Webb, now placed in the uncom­fortable position of justifying why he should not strip other NASA projects to fund Kennedy’s priority program. Although Kennedy was not sure that he ‘‘saw eye-to-eye’’ with Webb on this issue, he backed his chosen administrator. Webb replaced his insubordinate OMSF director with STL executive George Mueller (pronounced “Miller’’).54

Under the circumstances, further cost pressures were unwelcome. In March 1963, Gemini project manager James Chamberlin admitted that the project required another huge infusion of money. The unwelcome news led to his replacement by Charles Mathews. Mathews immediately set up a commit­tee to improve cost estimation at NASA and McDonnell. After another year of strained budgets and organizational crises — invariably related to novel portions of the project — Gemini’s budget stabilized, leading to an enviable record of flight success. However, cost estimates had risen from $531,000,000 to $1,354,000,000 between 1962 and 1964.55

With Congress increasingly concerned with costs, Webb instigated an in­ternal investigation of NASA projects in early 1964.56 Deputy Associate Ad­ministrator Earl Hilburn chaired the investigation to study NASA’s project scheduling and cost estimating methods. In confidential reports submitted in September and December of 1964, Hilburn described NASA’s abysmal record on cost and schedule control. Engine development showed by far the largest schedule slips, at 4.75 times the original estimate. Hilburn found significant slips in launch vehicles requiring new engines (3.09), manned spacecraft (2.86), ‘‘simple’’ scientific satellites (2.85), and astronomical observatories (2.83). Classified by field center, he found that the Jet Propulsion Laboratory (JPL) had the smallest schedule slips (1.6) and MSC the largest (3.06). The newest centers, MSC and Goddard, showed the largest slips, and the older centers (JPL, Langley) showed the smallest. Costs varied similarly.57

Hilburn noted that the DOD experience was also ‘‘one of over-runs and schedule slippages in the majority of cases.’’ He concluded that these results were behind recent changes in DOD procurement, ‘‘including program defi­nition, and incentive contracting.’’ Based on DOD precedents, NASA had al­ready begun converting contracts from cost-plus-fixed-fee contracts to incen­tive contracts that awarded firms a higher fee when they performed well and a lower fee when they did not. The Hilburn Report lent support to contract con­version at NASA, which NASA implemented from 1964 through 1966.58 NASA also adopted the DOD practice of phased planning, requiring contractors to better predict costs and schedules during a definition phase of development. The directive had little initial impact because of disagreements about imple­mentation, and more importantly, because few new projects started in 1966 and 1967.59

NASA’s manned space programs were among the worst offenders as NASA’s budget exploded between 1962 and 1964. Having grown accustomed to gener­ous, even extravagant budget increases without justification or congressional concern, NASA’s continued cost excesses were understandable, if not justifi­able. As in other organizations, the time came when its initial growth surge and justification had to slow and managers had to predict and hold to fund­ing profiles. At the highest levels, NASA could replace recalcitrant executives and implement new standards and processes, but to truly predict and control costs, NASA would have to implement rigorous procedures on its research and development (R&D) programs.

By 1972, European space programs were in the most severe of their many political crises. ELDO’s first Europa II launch had failed, and an international commission was investigating the organization’s many flaws. German and Italian leaders backed away from their commitments to ELDO. The United States offered the Europeans a part in the new shuttle program as a way to cut development costs and to discourage the European launcher program. In addition, the United States sent ambiguous signals to European governments on its willingness to launch European communications satellites. All Euro­pean governments agreed on the criticality of satellite telecommunications, but ESRO’s charter did not allow commercial applications, and the telecom­munications organization CETS had no satellite design capability. A sense of crisis pervaded negotiations among the European nations concerning their space programs.

Each of the member states of ELDO, ESRO, and CETS confronted the myriad problems and opportunities differently. The United Kingdom deci­sively turned its back on launch vehicles in favor of communications satel­lites. British leaders believed it wiser to use less expensive American launchers, so as to concentrate scarce resources on profitable communications satellites. Doubting that the United States would ever launch European satellites that would compete with the American satellite industry, French leaders insisted on developing a European launch vehicle. German leaders became disillu­sioned with launchers and were committed to cooperation with the United States. Because of their embarrassing failures on ELDO’s third stage, they wanted to acquire American managerial skills. Italy wanted to ensure a ‘‘just return’’ on its investments in the European programs by having a larger per­centage of contracts issued to Italian firms. For smaller countries to partici­pate in space programs, they needed a European program.

The result of these interests was the package deal of 1972 that created the ESA. Britain received its maritime communications satellite. France got its favorite program, a new launch vehicle called Ariane. Germany acquired its cooperative program with the United States, Spacelab, a scientific laboratory that fit in the shuttle orbiter payload bay. The Italians received a guarantee of higher returns on Italy’s investments. All member states had to fund the basic operations costs of the new ESA and participate in a mandatory science program. Beyond that, participation was voluntary, based upon an a-la-carte system where the countries could contribute as they saw fit on projects of their choice. European leaders liquidated ELDO and made ESRO the basis for

ESA, which came into official existence in 1975. ESTEC Director Roy Gibson became ESRO’s new director-general and would become the first leader of ESA.70

Two factors drove the further Americanization of European space efforts: the hard lessons of ELDO’s failure, and cooperation with NASA on Spacelab. By 1973, both ELDO and ESRO had adopted numerous American techniques, leading to a convergence of their management methods. On the Europa III program, ELDO finally used direct contracting through work package man­agement, augmented by phased planning to estimate costs. ESRO managers had done the same in the TD-1 program and in ESRO’s next major project, COS-B. ESRO’s two largest new projects, Ariane and Spacelab, inherited these lessons.

For Ariane, ESRO made CNES the prime contractor. CNES had responsi­bilities and authority that ELDO never had. ESRO required that CNES pro­vide a master plan with a work breakdown structure, monthly reports with PERT charts, expenditures, contract status, and technical reports. CNES would deliver a report each month to ESRO and would submit to an ESRO re­view each quarter. CNES could transfer program funds if necessary within the project but had to report these transfers to ESRO. ESRO kept quality assurance functions in-house to independently monitor the program. Reviewers from ESRO required that CNES further develop its initial Work Breakdown Struc­ture, which was ‘‘neither complete nor definitive,’’ and specify more clearly its interface responsibilities. The French took no chances after the disaster of ELDO and fully applied these techniques, as well as extending test pro­grams developed for ELDO and for French national programs such as Dia – mant. French managers and engineers led the Ariane European consortium to spectacular success by the early 1980s, capturing a large share of the com­mercial space launch market.71

While Ariane used some American management methods,72 Spacelab brought another wave of American organizational imports to Europe. This suited Spacelab’s German sponsors, who wanted to learn more about Ameri­can management. NASA required that the Europeans mimic its structure and methods. ESRO reorganized its headquarters structure to match that of NASA, with a Programme Directorate at ESRO headquarters, and a project office at ESTEC reporting to the center director. The NASA-ESRO agreement

required that ESRO provide a single contact person for the program and that this person be responsible for schedules, budgets, and technical efforts. Con­trary to its earlier practice, ESRO placed its Spacelab head of project coordi­nation with the technical divisions such as power systems, and guidance and control. ESRO used phased project planning, eventually selecting German company ERNO as prime contractor. ERNO contracted with American aero­space company McDonnell Douglas as systems engineering consultant, while NASA gave ESRO the results of earlier American design studies and described its experience with Skylab.73

To ensure that the program could be monitored, NASA imposed a full slate of reviews and working groups on ESRO and its Spacelab contractors. NASA held the Preliminary Requirements Review in November 1974, the Subsystems Requirements Review in June 1975, the Preliminary Design Review in 1976, the Critical Design Review in 1978, and the Final Acceptance Reviews in 1981 and 1982. Just as in the earlier ESRO-I and ESRO-II projects, NASA and ESRO instituted a Joint Spacelab Working Group that met every other month to work out interfaces and other technical issues. Spacelab managers and engi­neers organized working sessions with their NASA counterparts, including the Spacelab Operations Working Group, the Software Coordination Group, and the Avionics Ad Hoc Group. European scientists coordinated with the Americans through groups such as the NASA/ESRO Joint Planning Group. The two organizations instituted joint annual reviews by the NASA admin­istrator and the ESRO director-general and established liaison offices at each other’s facilities.74

ESRO did not easily adapt to NASA’s philosophy. From the American view­point, ESRO managers could not adequately observe contractors’ technical progress prior to hardware delivery, so NASA pressed ESRO to ‘‘penetrate the contractor.’’ NASA brought more than 100 people from the United States for some Spacelab reviews, whereas in the early years of Spacelab, ESRO’s entire team was 120 people. Heinz Stoewer, Spacelab’s first project manager, pressed negotiations all the way to the ESRO director-general to reduce NASA’s con­tingent. According to Stoewer, NASA’s presence was so overwhelming that ‘‘we could only survive those early years by having a close partnership be­tween ourselves and Industry.’’75

NASA engineers and managers strove to break this unstated partnership

and force ESA76 managers to adopt NASA’s approach. During 1975, NASA and ESA engineers worked on the interface specifications between Spacelab and the shuttle orbiter. During the first Spacelab preliminary design in June 1976, NASA engineers and managers criticized their ESA counterparts for their lack of penetrating questions. To emphasize the point, NASA rejected ERNO’s pre­liminary design. ESA finally placed representatives at ERNO to monitor and direct the contractor more forcefully.77

One of the major problems uncovered during the Preliminary Design Re­views was a large underestimate of effort and costs for software develop­ment. These problems bubbled up to the ESA Council, leading to a directive to improve software development and cost estimation. ESTEC engineers in­vestigated various software development processes and eventually decided to use the NASA Jet Propulsion Laboratory’s software standard as the basis for ESA software specifications. ESA arranged for twenty-one American software engineers and managers from TRW to assist. TRW programmers initially led the effort but gave responsibility to their European counterparts as they ac­quired the necessary skills. With this help, software became the first subsystem qualified for Spacelab.78

Another critical problem was Spacelab’s large backlog of changes, which resulted from a variety of causes. Organizational problems magnified the tech­nical complexity of the project, which the Europeans had underestimated. One major problem was that ESA allowed ERNO to execute ‘‘make-work’’ changes without ESA approval. ESA, whether or not it agreed with a change, had to repay the contractor. Another problem was the relationship between ESA and NASA. The agreement between the two organizations specified that each would pay for changes to its hardware, regardless of where the change originated. For example, if NASA decided to make a change to the shuttle that required a change to Spacelab, ESA had to pay for the Spacelab modifica­tion. This situation occurred frequently at the program’s beginning, leading to protests by ESA executives.79

Spacelab managers solved their change control problems through several methods. First, they altered their lenient contractor change policy; ESA ap­proval would be required for all modifications. Second, ESA management re­sisted NASA’s continuing changes. In negotiations by Director-General Roy Gibson, NASA executives finally realized the negative impact that changes to the shuttle had on Spacelab. As ESA’s costs mounted, NASA managers came to understand that they could not make casual changes that affected the European module. The sheer volume of changes to Spacelab reached the point where ERNO and ESA could not process individual changes quickly enough to meet the schedule. In a ‘‘commando-type operation,’’ ESA and ERNO negotiated an Omnibus Engineering Change Proposal that covered many of the changes in a single document. ERNO managers decided to begin engineering work on changes before they were approved, taking the risk that they might not recoup the costs through negotiations.80

Technical and managerial problems led also to personnel changes at ESA and ERNO. At ESA, Robert Pfeiffer replaced Heinz Stoewer as project man­ager in March 1977, while Michel Bignier took over as the program director in November 1976. At ERNO, Ants Kutzer replaced Hans Hoffman. Kutzer, who was Hoffman’s deputy at the time, was well known as the former ESRO – II project manager and a promoter of American management methods. After his stint at ESRO, Kutzer became manager of the German Azur and Helios spacecraft projects. For a time, ESA Director-General Roy Gibson acted as the de facto program manager because of Spacelab’s interactions with NASA, which required negotiations and communications at the highest level.81

ESA and ERNO eventually passed the second Preliminary Design Review in November 1976 by developing some 400 volumes of material. The pro­gram still had a number of hurdles to overcome, of which growing costs were the most difficult. Upon ESA’s creation, the British insisted that ESA, like ESRO, have strong cost controls. For a-la-carte programs such as Spacelab, when costs reached 120% of the originally agreement, contributing countries could withdraw from the project. Spacelab was the first program to pass the 120% threshold. After serious negotiations and severe cost cutting, the mem­ber states agreed to continue with a new cap of 140%. Eventually, ESA de­livered Spacelab to NASA and the module flew successfully on a number of shuttle missions in the 1980s.82

The transfer of American systems engineering and project management methods to ESA was effectively completed by 1979, with the creation of the Systems Engineering Division at ESTEC, headed by former Spacelab project manager Stoewer. According to Stoewer, one of the System Engineering Divi­sion’s main purposes was to ensure ‘‘more comprehensive technical support to mission feasibility and definition studies.’’ The Systems Engineering Division established an institutional home for systems analysis and systems engineer­ing, which along with the Project Control Division ensured that ESA would use systems management for years to come.83

Conclusion

ESRO began as an organization dedicated to the ideals of science and Euro­pean integration. The CERN model of an organization controlled by scien­tists, for scientists, greatly influenced early discussions about a new organiza­tion for space research. However, space was unlike high-energy physics in the diversity of its constituency, the greater involvement of the military and in­dustry, and the predominance of engineers in building satellites. Engineering, not science, became ESRO’s dominant force.

From the start, ESRO personnel looked to the United States for manage­ment models. Leaders of ESRO’s early projects asked for and received Ameri­can advice through joint NASA-ESRO working groups for ESRO-I and ESRO- II. The United States offered ESRO two free launches on its Scout rockets but would not allow the Europeans to launch until they met American concerns at working group meetings, project reviews, and a formal Flight Readiness Re­view. On HEOS, executives and engineers from the loose European industrial consortium led by Junkers traveled to California for advice, where Lockheed advised much closer cooperation, along with a detailed management section in its proposal. ESRO’s selection of the Junkers team by a large margin made other European companies take notice, leading to tightly knit industrial con­sortia that at least paid lip service to strong project management.

When ESRO’s member states refused to let ESRO carry forward its surplus in 1967, they immediately caused a financial crisis. Significant cost overruns on TD-1 and TD-2, along with strong pressure to develop telecommunications satellites by issuing a prime contract to industry, spurred ESRO to beef up its management methods. ESRO adopted from NASA models phased plan­ning, stronger configuration control, work package management, and an MIS at each ESRO facility.

American influence persisted through the 1970s. On Spacelab, NASA im­posed its full slate of methods onto ESA. Some, such as contractor penetra­tion, ESA initially resisted, before technical problems weakened the Euro­peans’ bargaining position. ESA managers and engineers eagerly adopted other methods, such as software engineering, once they realized the need for them. These became the standards for ESA projects thereafter.

Europeans created an international organization that developed a series of successful scientific and commercial satellites, captured the lion’s share of the world commercial space launch market, and pulled even with NASA in technical capability. To do so, they adapted NASA’s organizational methods to their own environment. In the process, ESRO changed from an organiza­tion to support scientists, into ESA, an engineering organization to support national governments and industries. ESA’s organizational foundation, like that of NASA and the air force, was systems management.

EIGHT

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

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

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

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

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

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

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

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

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

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

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

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

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

The Minuteman project was the critical turning point for air force ICBM pro­grams. First, its use of solid propellants instead of troublesome liquids greatly simplified and decreased the dangers of ICBM launch operations. Second, the Minuteman assembly and test contractor, Boeing, brought to the Inglewood complex a new management technique that would become the centerpiece of the air force’s R&D management process: configuration management. The combined effect of solid propellants and configuration management was a dramatic improvement in ICBM reliability and cost predictability.

By 1957, a solid-propellant alternative to troublesome liquid-fueled ballis­tic missiles such as Atlas and Titan became feasible. Col. Ed Hall, Schriever’s propulsion manager, had, along with R-W and a number of contractors, been studying solid propellant technology for some time and had evidence to show that it could be developed for large-scale ICBMs. Hall pointed out to Tech­nical Director Charles Terhune that solid-propelled rockets did not involve costly, time-consuming, and dangerous liquid-propellant loading procedures. Although liquid-propelled rockets had higher performance, it took several hours to prepare them for launch. Solids, on the other hand, could be launched within seconds; once loaded with propellants and placed in their launch configuration, they were ready to go with the push of a button. Hall now had evidence to show that solids, which heretofore could perform ade­quately with only a small size, could now be manufactured and perform ade­quately on a much larger scale, making solid-propellant ICBMs feasible.36 Solid propellants eliminated dangerous liquid-propellant loading operations that destroyed launch pads and killed workers. This in itself was a tremen­dous advantage. However, the use of solid propellants did nothing to fix subtle problems associated with unintended component interactions resulting from poor designs, or worse, resulting from flight hardware that did not match any­one’s design.

On Atlas and Titan test flights, engineers found that a number of test fail­ures resulted from mismatches between the missile’s design and the hardware configuration of the missile on the launch pad. In the rush to fix problems, the launch organization, contractors, or air force had made modifications to missiles without documenting those modifications. To fix this problem, STL personnel and air force officers developed a reporting procedure known as configuration control to track and connect missile design changes to missile hardware changes. Because these often involved manufacturing and launch processes, configuration control soon controlled process changes as well.37

While inspired by problems endemic to ballistic missiles, configuration control drew from the Boeing Company’s aircraft programs. The air force learned about configuration control through the Minuteman project, where Boeing was the assembly and test contractor. Boeing’s quality assurance pro­cedures used five control tools:

1. formal systems for recording technical requirements

2. a product numbering and nomenclature system for each deliverable contract item

3. a system of control documents with space for added data on quanti­ties, schedules, procedures, and so forth

4. a change-processing system

5. an integrated records system38

In addition, Boeing’s ‘‘change board’’ ensured that all affected departments reviewed any engineering or manufacturing change and committed appropri­ate resources to effect it. The air force soon saw the importance of this process innovation and made it into a critical new management process, with its own organization and staff.39

Boeing’s processes supplanted the concept of the ‘‘design freeze.’’ The de­sign freeze was an important milestone in aircraft development, the point when engineers stopped making design changes so that hardware could be built to that design. Once the design was frozen, engineers or operators could make design changes only by submitting a formal change request. Engineers then made sure that corresponding changes were made to the hardware and the production facilities.

Ballistic Missile Division (BMD, successor to the WDD) officers and STL engineers used configuration control to coordinate changes and ensure the compatibility of designs and hardware. The key to configuration control was the creation of a formal change board with representatives from all organi­zations, along with a formal system of paperwork that linked specifications, designs, hardware, and processes. Although initially linking design drawings to hardware, BMD officers and R-W engineers soon realized that by expand­ing configuration control to include specifications and procedures, they could control the entire development process.

Through configuration control, systems engineers linked specifications to designs, designs to hardware, and hardware to operational and testing pro­cedures. Engineers brought proposed changes to the configuration control board. Air force officers soon linked configuration control to contracts, tying engineering changes to contract changes. The air force established configura­tion control in the fall of 1959 on Minuteman; soon, configuration control had been extended to its other space and missile projects.40 Officers and managers vigorously promoted configuration control because of its utility in linking engineering, management, and contracts.

By the early 1960s, the coordinating role of STL and The Aerospace Cor­poration 41 had evolved into a procedure called systems requirements analysis, in which technology development was managed through the control of re­quirements. For example, at the highest level a requirement would be written to develop a ballistic missile system to deliver a one-megaton payload over 5,000 miles with an accuracy of 1 mile. Systems engineers divided this re­quirement into at least three statements at the next level. These three would then be broken down into numerous requirements to create hardware compo­nents, operating procedures, and so on. Major programs involved thousands of requirements, corresponding to thousands of components and procedures. Systems requirements analysis made the design traceable to requirements of increasing specificity.42

Detailed requirements analysis, and more importantly, configuration con­trol, found a powerful advocate in Col. Samuel C. Phillips, who in 1959 re­placed Col. Ed Hall as the manager of Minuteman.43 Phillips, who graduated in 1942 with a bachelor’s degree in electrical engineering from the University of Wyoming, had steadily worked his way up the air force’s hierarchy as a skilled technical manager. After serving as a pilot in Europe in World War II, he started in 1950 as a project engineer at Wright-Patterson Air Force Base. Through the 1950s, he held an assortment of positions, including electron­ics officer for atomic weapons tests at Eniwetok Atoll, chief of operations at the Armament Laboratory at Wright-Patterson, project officer for the B-52 bomber, chief of the bombardment aircraft division, chief of the fighter mis­siles and drones division, and eventually, logistics chief and materiel director of Strategic Air Command in England. Phillips was quiet, forceful, and tactful, and he brought the tools developed by Schriever’s team to Minuteman.44

In 1959, managers at Boeing, or possibly Phillips himself, realized that by a simple extension of configuration control, they could gain financial as well as technical control over the project.45 The idea was simple. All a project man­ager had to do was compel engineers to give cost and schedule estimates along with any technical change. If the engineer did not give the informa­tion, the project manager rejected the change. With this added information, the project manager could predict and revise the project’s cost profile, along with its schedule. This also allowed the manager to track the performance of each engineer or group of engineers — he could now hold them accountable to their own estimates. Managers tied the process to specific design configura­tions and eventually to the hardware itself. In addition, procurement officials and industry managers could write contracts against specific design configu­rations and negotiate cost changes based upon each approved change. Phillips and others transformed configuration control into “configuration manage – ment,” a critical managerial tool to control the entire development process. Others soon recognized its utility, leading in 1962 to the creation of general regulations and guidelines for configuration management.46

Through configuration management, and also because of its solid- propelled rocket design, Minuteman boasted an enviable development record, coming in on cost and on schedule. Because of Minuteman’s much better reli­ability and launch-on-demand capability, the air force soon phased out most liquid-propellant missiles as weapons. Higher performance made liquid – propellant missiles excellent satellite launchers, and they and their descen­dants performed well in this role. In their capacity as launchers, the Atlas, Titan, and Thor-Delta vehicles attained reliability exceeding 90% from the mid-1960s through the 1990s.47

Configuration management — along with further attention to quality through inspections, training, and associated documentation—became an organizational pillar of the air force’s management system. Its importance can hardly be overstated. Managers from the turn of the century through the 1950s had searched for ways to predict R&D costs and to control scientists and engineers. Configuration management achieved this control on develop­ment projects, as it allowed accountants and lawyers to tie technical modifica­tions to contract modifications, including costs. Configuration management enabled government to control industry. However, the government officials who wielded the authority had make clear distinctions between those doing the controlling and those being controlled. To do this, they would have to modify the anomalous position of R-W.