Category The Secret of Apollo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusion

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

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

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

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

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

THREE

The really significant fallout from the strains, traumas, and endless experimentation of Project Apollo has been of a socio­logical rather than a technological nature; techniques for directing the massed scores of thousands of minds in a close – knit, mutually enhancive combination of government, uni­versity, and private industry.

— T. Alexander, in Fortune

By far the largest programs within the National Aeronautics and Space Ad­ministration (NASA) during the 1960s were the manned space projects Mer­cury, Gemini, and Apollo. These differed from other NASA programs because of their massive scale and because several field centers, not just one, contrib­uted significantly to them. The NASA headquarters role was bigger for these huge projects than it was for smaller ones: headquarters coordinated the work of the different field centers. The manned space program contributed dispro­portionately to the management philosophy and style of NASA as a whole, defined by agency-wide procedures.1

While astronauts grabbed public attention, NASA managers and engineers quietly created the machines and procedures necessary for astronauts and ground controllers to operate them. With their personnel descended from German rocket pioneers and National Advisory Committee for Aeronautics (NACA) researchers, NASA’s informal groups brought years of aircraft and rocket design expertise to spacecraft design. These new technologies de­manded strict attention, and there were the usual number of failures. NASA personnel had to learn how to design manned spacecraft and man-rated rockets as well as how to direct thousands of new employees and scores of contractors.

Difficulties in making the transition from engineers to managers led NASA executives to look elsewhere for people with strong organizational skills. Ex­ecutives turned primarily to the air force, an organization that developed technologies similar to NASA’s. From its inception, NASA had used military personnel, but the importation of experienced air force officers reached its peak in 1964 and 1965, as the newly installed Apollo program director, Brig. Gen. Samuel C. Phillips of the air force, arranged the transfer of scores of air force officers to bring order to NASA’s chaotic committees. Phillips im­ported air force methods such as configuration control, the Program Evalua­tion and Review Technique (PERT), project management, and Resident Pro­gram Offices at contractor locations. By the end of Apollo, Phillips had grafted significant elements of Air Force Systems Command (AFSC) onto NASA’s original culture.

ESRO selected projects in consultation with scientific groups, a council rep­resenting the national governments, and its own scientists. Ad hoc groups recommended experiments to the Launching Programmes Advisory Commit­tee (LPAC), which in turn selected a few of them to form a satellite payload. The LPAC recommended payloads to the Scientific and Technical Committee and the Administrative and Financial Committee. These committees then pre­sented their assessments to the ESRO Council, which made the final decision. The Council passed its decision to ESRO headquarters, which then authorized ESTEC and the other ESRO organizations to begin work.9

Unlike ELDO’s, ESRO’s authority included contract placement and con­trol. The ESRO Convention required that ESRO ‘‘place orders for equipment and industrial contracts among the Member States as equitably as possible, taking into account scientific, technological, economic and geographical con­siderations.’’ To do so, ESRO created a register of member state suppliers. For items costing more than 10,000 French francs, ESRO’s financial rules required that ESRO request bids from industry, unless ESRO had ‘‘no alternative but to go directly with one supplier.’’ ESRO submitted all purchases of greater than 500,000 French francs to its Administrative and Finance Committee, along with any purchases outside of the member states.10

Although ESRO’s day-to-day affairs revolved around engineering, scien­tists heavily influenced the selection of projects and experiments. The short­term sounding rocket program consisted of seventy-one launches from Sar­dinia, Norway, Sweden, and Greece between 1964 and 1968. For the medium term, ESRO’s satellite program consisted of two spin-stabilized scientific spacecraft, known as ESRO-I and ESRO-II. Shortly thereafter, ESRO approved three more satellites: a polar orbiting satellite known as the Highly Eccen­tric Orbit Satellite (HEOS-A) and two complex attitude-stabilized spacecraft known as Thor-Delta 1 and Thor-Delta 2 (TD-1, TD-2).11

In 1963, scientists and administrators in ESRO’s Preparatory Commission initiated internal and contract feasibility studies for ESRO-I. Performed early in 1964, these contract studies contributed to the definition of the scientific payload. ESRO released its tender for ESRO-I in November 1964. After ESTEC engineers evaluated the resulting proposals, ESRO awarded several contracts in April 1965. The Laboratoire Central de Telecommunications of Paris re­ceived the contract for project management and satellite integration, and companies in Switzerland and Belgium received ‘‘associate’’ contracts.12 Each of these companies had subcontractors, including some American companies offering components not readily available in Europe, such as sun sensors, bat­teries, and test equipment.13

ESRO-II evolved at the same time — and with the same process. ESTEC scientists and engineers began internal design studies in July 1963 and awarded external design study contracts to a Belgian firm and a Swiss univer­sity.14 ESTEC engineers deliberately introduced variations in the designs that these institutions studied so as to assess different methods of attitude control.

After completion of these feasibility studies, ESTEC engineers wrote technical specifications used in the call for tenders in June 1964. In November, ESRO selected British firm Hawker Siddeley Dynamics as prime contractor, and Hawker Siddeley subcontracted to several British and French companies.15 ESTEC let separate contracts for the command, telemetry, and checkout sub­systems and also coordinated the ‘‘supply of sub-systems to the prime con­tractor.” Hawker Siddeley had responsibility for project management, speci­fications, interfaces, structures, and integration.16

The HEOS project started somewhat later and evolved similarly. In early 1964, a study group rejected a planetary mission because it would have re­quired the construction of large ground stations. Instead, the group recom­mended a spacecraft in a highly eccentric orbit around Earth. ESRO endorsed the project in July 1964, at which time ESTEC appointed a project manager. ESTEC conducted feasibility studies in late 1964 and issued calls for tender in June 1965. In November, ESTEC awarded the contract to a consortium led by Junkers Corporation.17 The Junkers team hired Lockheed Space Corporation from the United States to provide consulting and to supply high-reliability parts. Development began in January 1966. The HEOS project marked the first contract award to a consortium, a trend that would soon become the norm for European industry. Following American trends, it also marked the first use of an incentive contract instead of a cost-plus-fixed-fee contract.18

ESRO-I and ESRO-II took advantage of the National Aeronautics and Space Administration’s (NASA’s) offer to launch ESRO’s first two satellites free of charge. HEOS-A also used an American launcher, but ESRO had to pay for the service. NASA offered its junior partner technical assistance, including project training, reviewing test results, participating in joint reviews, conduct­ing launch operations, and supplying additional tracking and data acquisi­tion support. Goddard Space Flight Center (GSFC) managed NASA’s contri­butions. Through working groups and design reviews, GSFC space scientists and engineers guided ESRO personnel through their early projects.19

What did ESRO administrators, scientists, and engineers learn from GSFC personnel? GSFC managers began projects by issuing a project specification and a competitive tender. They expected the prime contractor to issue a space­craft handbook for experimenters and to attend monthly interface meetings with experimenters and other organizations. Cost-plus-fixed-fee contracts were the norm for development; administrators monitored them through monthly contractor reports. GSFC managers stressed the importance of change control, coordinating all design changes with contributing organiza­tions. The initiator of changes had to submit a written proposal to the project manager, who had final authority.20

GSFC and ESRO formed joint working groups for ESRO-I and ESRO-II so that ESRO personnel could learn from their NASA counterparts, so that NASA personnel could learn about European methods, and so that solutions for common problems and interfaces could be worked out. NASA provided representatives from its technical divisions, along with the project manager and representatives from Scout launch vehicle contractor Ling-Temco-Vought. The working groups covered topics such as mechanical and electrical inter­faces, launch and mission procedures, reliability and quality assurance, and testing and verification. The Europeans heeded American advice regarding interfaces, iteratively defining and reworking interfaces until they were con­sistent across subsystems and between the spacecraft and the launch vehicle.21

High-level ESRO administrators visited the United States in 1964. ESTEC’s technical director, chairman of the Scientific and Technical Committee, and Large Satellites Division chief visited NASA headquarters, GSFC, Princeton University, and Grumman Corporation to learn about the organizational and technical aspects of the Orbiting Astronomical Observatory project. In Feb­ruary 1965, the ESRO-I project manager and scientists visited Rice Univer­sity in Houston. After visiting Rice — and presumably NASA officials from the Manned Spacecraft Center—they visited renowned space scientist James van Allen of Iowa State University.22

With little spacecraft experience, European contractors also used American assistance when they could get it. ESRO-II prime contractor Hawker Siddeley had ‘‘a considerable amount of technical liaison’’ with Thompson-Ramo- Wooldridge (TRW). Junkers hired Lockheed as a technical and management consultant for HEOS and to procure high-reliability components. These sup­plemented other European-American industrial interactions at that time, which included Boeing’s one-third purchase of Bolkow, TRW’s establishment of Matrel Corporation with Engins Matra, North American’s cooperation with Societe d’Etudes de la Propulsion par Reaction, and Douglas Company’s co­operation with Sud Aviation.23

British organizations also assisted ESRO. A visit by ESRO administrators to the U. K. Ministry of Aviation focused on financial estimating and report­ing procedures and the use of the Program Evaluation and Review Technique (PERT). On its projects, the Ministry of Aviation placed contracts for the en­tire development and planned future expenditures by acquiring predicted fi­nancial profiles from its contractors. The ESRO visitors found that the min­istry and some of its contractors used PERT/TIME for schedule planning. Because PERT was available in Britain only through International Business Machines (IBM) computers and produced summaries intended for ‘‘PERT oriented managements which are even rarer in the U. K. than PERT oriented project teams,’’ the ministry recommended that PERT was not a good solution for scheduling and cost-estimating problems.24

ESRO’s inexperienced project personnel depended on contractors. Accord­ing to ESRO-II project manager Ants Kutzer, one important innovation was to have ESRO representatives attend all project meetings between its two major contractors, Hawker Siddeley and Engins Matra. He stated that ‘‘although un­usual … the most valuable aspect… was that the ESTEC project team gained detailed technical knowledge of the design as well as experience.’’25

Kutzer was an acute student of research and development (R&D) manage­ment, having read American studies of R&D contracting, including those by RAND and the Harvard Business School that documented American missile management methods. He followed the development of scheduling tools such as PERT as well as early systems engineering texts. To Kutzer, the lesson of these early studies and tools was that for complex projects, managers needed to deploy new methods that identified ‘‘all of the activities required to meet the end objective.’’ These methods should, Kutzer said, show complex inter­relationships and constraints, including interfaces; predict the time and cost outcome; optimize resource allocation; and be flexible enough to adapt to rapid change.26

Because of the great diversity in nationalities involved in the ESRO-II proj­ect, Kutzer believed that it needed new management techniques. He empha­sized close coordination and communications between ESRO, GSFC, and the contractors. He felt that ‘‘informal exchange of ideas and techniques’’ in the NASA-GSFC working group and numerous subgroups made ‘‘a major contri­bution to project success.’’ Kutzer discussed formal specifications and docu­ments at regular meetings and supplemented them with informal meetings. To minimize the effect of ‘‘rather exhaustive listening to a foreign language,’’ Kutzer systematized meeting agendas to standardize the vocabularies used in the meeting. So too did ESRO-I managers.27

The HEOS program borrowed extensively from American management models, resulting in thorough advanced planning, stronger project manage­ment and systems engineering, and the development of European consortia. Junkers led the winning industry team, drawing extensively on Lockheed for management ideas. Lockheed helped to bring together the Europeans’ diverse companies and traditions in the process of developing the proposal bid:

The firms had mutually coordinated their bid proposals in Europe and after­wards met in Sunnyvale to write the definitive bid text. In these weeks, very lively discussions with the experienced specialists of the American firm led to strong contact between the executives of the European firms, which became decisive for cooperation in the realization of the project. Furthermore, the par­ticipants learned to link the same ideas with the same words. . .

The consortium’s bid consisted of approximately 1,000 pages, around one-third of which concerned management and cost-estimating questions. Without the advice of the American firm, this part in particular would not have undergone such a deep treatment.28

The Junkers team bid far surpassed earlier and contemporary bids in the detail and attention given to management. Junkers won the HEOS contract by a considerable margin. Junkers team members believed that they won by such a wide margin primarily because ‘‘it could be assumed [by ESRO] with great certainty that the bidders had constructed quite realistic time and cost plans.’’29 For later ESRO projects, European teams adopted the Junkers ap­proach, including using American consultants, constructing detailed man­agement plans, and employing close-knit consortia to carry those plans out.

Both ESRO and its contractors experimented with PERT and other plan­ning techniques to determine their utility for spacecraft projects. Europeans learned of PERT through American papers and contacts and acquired it through the use of IBM computers. As an experiment, the ESRO-I prime contractor, the Laboratoire Central de Telecommunications (LCT), proposed

HEOS spacecraft. On the HEOS project, European contractors formed their first consortium based on recommendations received from U. S. contractor Lockheed. Courtesy NASA.

using IBM PERT/Cost software. LCT management found the reports gener­ated very useful for analyzing completed and future activities and expenses. They delivered reports every three months to ESRO, including a cost plan, a bar chart for management, and a detailed cost report. Because ESTEC did not have PERT but wanted its own PERT plan for top-level project events, ESTEC managers updated their own network by hand from LCT’s PERT results. The ESTEC project team also generated weekly bar charts. Near the end of the program, as the spacecraft progressed in a serial fashion through testing, the project stopped using PERT, switching to simple bar charts.30

HEOS prime contractor Junkers developed sophisticated PERT networks, using a detailed monthly cycle for acquiring inputs and generating outputs. In part because Junkers’s incentive contract rewarded a launch in early 1969, Junkers emphasized the use of PERT to control schedules. It created an 800- event network for HEOS, backed by a system of Planning Change Notices that tied PERT to engineering and management changes. As LCT had done on ESRO-I, Junkers produced bar charts for managers and more detailed net­work listings for planners, and it also used PERT/Cost with generally favorable results.31

ESRO-II management also used PERT through prime contractor Hawker Siddeley but paid more attention to developing new techniques to measure project progress and to implement configuration control. Project manager Kutzer recognized that although configuration control as used by the U. S. Air Force was useful for ESRO-II systems engineering, he could not imple­ment it, because of the lack of experience and lack of detailed requirements for ESRO-II. Instead, ESTEC engineers established the requirements through the ‘‘unusual approach’’ of attending all technical and contractor meetings. They limited themselves to being ‘‘technically suspicious and taking nothing for granted,’’ and they tried to be “pessimistic about success and to find weak links,’’ to ensure strong testing, and ‘‘to support the contractors.’’32

Hawker Siddeley’s project manager developed a new process to assess progress during specification development. He created an empirical method whereby planners gave each proposed specification a ‘‘marks loading,’’ a nu­merical value that depended upon the amount of work expected. The engi­neer responsible for the specification could estimate the percentage of work completed against the specification. For example, a specification worth 50 marks loading and estimated at 60% complete would be given a current marks value of 30. By adding the total of all current marks values and dividing this sum by the total marks loading for the project, Hawker Siddeley acquired an estimate of the amount of work completed and the amount remaining.33

After completing the specifications and establishing a design baseline, Kut – zer and Hawker Siddeley’s managers implemented a configuration control process. They developed standardized forms that summarized subsystem status, including acceptance test status, reliability, defect reports, modifica­tions, and information and action items still required. When the subsystem successfully passed its tests and supplied the relevant paperwork, ESTEC issued a Design Acceptance Note that formally accepted the subsystem. After issuance of the Design Acceptance Note, engineers could modify the design only by submitting a Modification Proposal Authorization Form. It included the modification and the reasons for it; the estimated cost, schedule, and weight impact; and its effect on other subsystems, documentation, and firms.34

One European deficiency was the lack of environmental test facilities suit­able for satellite checkout. Europeans knew from American published papers and personal contacts that satellites had to be thoroughly tested on the ground, including vibration testing, charged particle radiation testing, and thermal vacuum testing. ESRO’s initial program included substantial invest­ments in facilities, including environmental test facilities. By 1966, ESTEC managers had two vacuum chambers and vibration systems under construc­tion. In 1966, ESTEC used its own vibration system and vacuum facilities to test the ESRO-I structural test and thermal models. Prior to completion of ESTEC’s facilities, ESRO and its contractors used British, French, and Ameri­can facilities.35

Largely because of their lack of environmental test facilities, European companies did not have parts that met the high standards typically associated with American satellites. All three of ESRO’s initial satellites procured high – reliability electronic components from the United States.36 When American companies could not deliver these scarce components on schedule, delays of several months ensued for ESRO-I and HEOS. Only the ESRO-II pro­gram avoided significant delays in procurement of high-reliability American parts.37

Each project acquired American expertise through direct consultation and interaction with GSFC personnel. During a design review by GSFC person­nel in October 1966, NASA experts stated that ESRO had not sufficiently ac­counted for the space thermal environment and needed to perform further analysis and testing. In response, ESRO created a complex thermal model and added a test in a French thermal vacuum chamber, both of which verified the adequacy of the original design. NASA reviewed ESRO-I launch operations plans in October 1966. After the Flight Readiness Review at ESTEC from Au­gust 12-16, 1968, ESRO managers and engineers waxed enthusiastic: ‘‘It was a great moment for the Project Team, when at the end of the Flight Readi­ness Review, the NASA experts declared ESRO-I flight ready.’’38 GSFC experts performed similar reviews for ESRO-II and HEOS between 1966 and 1968.39

After some initial problems, ESRO’s satellites operated successfully. ESRO – II launched in May 1967 but never made it into orbit, as NASA’s Scout launcher exploded during ascent. ESRO regrouped and successfully launched a second model in May 1968. ESRO-I successfully launched in October 1968, and HEOS in December.40

ESRO personnel began their first projects recognizing their own inexperi­ence and took advantage of NASA’s offer to help, both in launching their first two satellites for free and in training ESRO personnel in spacecraft de­sign and management. European managers, engineers, and scientists visited the United States to learn American methods, and their American counter­parts reciprocated by visiting ESTEC during working group meetings, de­sign reviews, and Flight Readiness Reviews for ESRO’s satellite projects. GSFC personnel gave substantial help to ESRO, as did American contractors TRW and Lockheed to ESRO’s prime contractors Hawker Siddeley and Junkers for ESRO-II and HEOS. ESRO and its contractors used American models for its testing programs, planning methods, configuration control, and reliability as­sessment. They also acquired and used PERT with the help of IBM computers. On HEOS, Lockheed advised European contractors to emphasize manage­ment issues, leading to a strong consortium that won the bid by a large mar­gin. The Junkers consortium’s successful bid was the model for contractor consortia on later bid opportunities. The technical success of the satellites ESRO launched in 1968 and 1969 showed the value of ESRO’s methods.

We have found that concurrency is as unforgiving to inept management principles as a high performance aircraft is to pilot error. In fact, it requires MORE formality, not LESS.

— Lieutenant Colonel Benjamin Bellis, 1962

By 1955, Bernard Schriever’s Western Development Division (WDD), in con­junction with the Special Aircraft Projects Office (SAPO) and Ramo-Wool – dridge Corporation (R-W), had implemented concurrency to rapidly move intercontinental ballistic missiles (ICBMs) from development into testing. As tests unfolded in 1956 and 1957, Schriever’s officers and contractors found, much to their consternation, that Atlas failed at an alarmingly high rate. In the rush to push ICBMs into service, Schriever had created an organization that was remarkably informal and flexible but whose disregard of regular pro­cedures also cut out many essential functions of the air force’s bureaucracy. Many of these techniques had been put into place to ensure that there was communication among technical, financial, legal, and operational personnel. Focusing explicitly on the technical issues, Schriever’s officers and contractors let other concerns fall to the wayside. Problems with financing and schedul­ing were compounded by technical problems endemic to radical new tech­nologies.

To fend off criticism, Schriever’s organization had to improve the reliability of the complex weapons and better predict and control costs. This required more formal engineering and management practices. Engineers made mis­siles more dependable through exhaustive testing, component tracking, and

configuration control. Managers improved cost prediction and control using new tools like the Program Evaluation and Review Technique (PERT) and new procedures such as phased planning. The end result was systems management, a means to create new technologies rapidly but also to plan and control the excesses of concurrency. The new methods slowed development but increased reliability and cost predictability of air force technology programs.

While justifiable under the perceived national emergency in the 1950s, the huge costs of concurrency could not be sustained forever. To achieve cost control, Schriever and his cohorts adopted centralized, formal management techniques. Inherent in this shift was a slowdown in the pace of technological innovation, imposed by managerial checkpoints. Replacing a rapidly paced world of novel wonder weapons promoted by military officers and scientists was a more sedate world of dependable weapons and predictable adminis­tration offered by engineers and managers. Consistent with Secretary of De­fense Robert McNamara’s determination to centralize control and authority for weapons development, Schriever’s modified techniques became the basis for the new Air Force Systems Command and by 1965 the heart of the Depart­ment of Defense’s (DOD’s) development processes.1

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.