Category The Secret of Apollo

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

-Jean-Jacques Servan-Schreiber, 1967

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusion

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

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

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

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

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

FOUR

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

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

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

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

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

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

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

Conclusion

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

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

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

SIX

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

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

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

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

The history of ELDO illustrates how critical motivation and authority are

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

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

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

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

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

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

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