Category The Secret of Apollo

Technical failures of aerospace projects are hard to hide. Rockets and missiles explode. Satellites stop sending signals back to Earth. Pilots and astronauts die. To the extent that systems management helped prevent these events, it must be deemed a technical success. Systems management methods such as quality assurance, configuration control, and systems integration testing were among the primary factors in the improved dependability of ballistic missiles and spacecraft. Missile reliability in air force and JPL missile programs in­creased from the 50% range up to the 80% to 95% range, where it remains to this day. JPL’s spacecraft programs suffered numerous failures from 1958 to 1963, but after that JPL’s record dramatically improved, with a nearly perfect record of success for the next three decades. The manned programs suffered a number of testing failures at the start but had an enviable flight record with astronauts, with the one glaring exception of the Apollo 204 fire. A strong cor­relation exists between systems management and reliability improvements.

The nature of reliability argues for the positive influence of systems meth­ods. For aerospace projects to succeed, there must be high-quality compo­nents, proper integration of these components, and designed-in backups in case failures occur. Only the last of these is a technology issue in the design sense. The selection and proper integration of components has more to do with rigorous compliance with design and manufacturing standards than it does with new technology. High component quality comes through unflag­ging attention to manufacturing processes, backed by testing and selection of the best parts. In a nutshell, it is easy to solder a joint or crimp a connec­tor pin but extremely difficult to ensure that workers perform thousands or millions of solders and crimps correctly. Even a worker with the best skills and motivation will make occasional mistakes. In systems management, so­cial processes to rigorously inspect and verify all manufacturing operations ensure high quality across the thousands of workers involved in the process.

Similarly, ensuring proper integration is a matter of making sure that each and every joint is properly soldered, every pin and connector properly crimped, every structure properly handled at all times, and all of these opera­tions rigorously tested. On top of this, ‘‘systems testing’’ checks for design flaws and unexpected interactions among components. In all of these issues, procedures and processes—not new technology—are the keys to success. Sys­tems management provided these rigorous processes and tests.

Once organizations dealt with component problems, they ran into the next most likely cause of failure: interface problems caused by mismatches between designs. By the mid-1960s, both the air force and NASA obsessively concen­trated on interface problems, which resulted ultimately from poor communi­cation, poor organization, or both. Engineers and managers recognized that differences in organizational cultures and methods made communication be­tween organizations more difficult than communication within an organiza­tion. Miscommunication led to incompatibilities between components and subsystems — incompatibilities often found when components were first con­nected and tested. More technology was not the solution. Instead, engineers needed improved communication through social processes.

Engineers enforced better communication by creating standard documents and processes. They required that one organization be responsible for ana­lyzing both sides of an interface and that the specifications and analyses be documented in a formal Interface Control Document. Many interface prob­lems were subtler than simple mismatches between physical or electrical com­ponents.

For example, engineers at Marshall Space Flight Center found that a ‘‘non­liftoff’’ of a Mercury-Redstone test vehicle occurred because the Mercury cap­sule had a different weight than the Redstone’s normal warhead, changing the time it took for the launch vehicle to separate from the launch tower. Because the combined launch complex-launch vehicle electronics required that the ve­hicle lift off at a certain rate, the changed rate led to a shutdown of the launch vehicle as emergency electronics kicked in to abort the launch.

Problems such as these were solvable not through technology but through better engineering communication and better design analysis. Once engineers understood all of the factors, the design solution was usually simple. The problem was making sure the right people had the right information and that someone had responsibility for investigating the entire situation. As ELDO’s history shows, getting an organization to pay for a change in an interface was often more difficult than formulating a technical solution. Authority and communication matter most in interface problems and solutions. Better orga­nization and better systems, not better technology, made for reliability in large aerospace projects by standardizing the processes and providing pro­cedures to cross-check and verify each item, from solder joints to astronaut flight procedures. These methods essentially provided insurance for technical success.

How much did this insurance cost? Did systems management lower costs or speed development compared to earlier processes and methods? Concurrency in the 1950s was widely believed to shorten development times, but at enor­mous cost. The secretary of the air force admitted that the air force could af­ford only one or two such programs. Schriever contended that concurrency saved money because it shortened development time. Because R&D costs are spent mostly on engineering labor, Schriever argued, shortening development time would reduce labor hours and hence cost. Most other experts then and later disagreed with him. Political scientist Michael Brown contends that con­currency actually led to further schedule slips because problems in one part of the system led to redesigns of other parts, often several times over.3

On any given design, having systems management undoubtedly costs more than not having systems management, just as buying insurance costs more than not buying insurance. The real question is whether systems management reduced the number of failures sufficiently, so that it counterbalanced the re­placement cost. For example, a 50% rate of reliability for a missile system such as Atlas in the late 1950s meant that every other missile failed. With this failure rate, the air force and its contractors could afford to spend up to the cost of an entire second missile in improvements to management processes, ifthese pro­cesses could guarantee success. In other words, at a 50% reliability rate and a cost of $10 million per missile, each successful launch costs $20 million. Thus, if process improvements can guarantee success, then spending $10 million or less per missile in management process improvements is cost-effective.

In fact, the early Atlas, Titan, and Corporal projects achieved roughly 40­60% reliability. Reliability improvement programs — that is, systems manage­ment processes — improved reliability into the 60-80% range during the 1950s and early 1960s and into the 85-95% range thereafter.4 The reliability im­provement meant that roughly nine out of ten launches succeeded, instead of one out of two. Therefore, systems management could easily have added more than 50% to each missile’s cost and still been cost-effective. NASA’s efforts to ‘‘man-rate’’ Atlas and Titan could have added 100% to costs for Atlas and Titan and still been cost-effective, because success had to be guaranteed. In fact, considering the potential loss of not only the launchers but also the manned capsules and astronauts, NASA could likely spend 200-500% on launcher im­provements and still be cost-effective, considering the low reliability of these vehicles at that time. Pending detailed cost analysis, systems management was probably cost-effective if costs were measured for each successful launch.

Another way to assess systems management is to compare missile and space programs that implemented systems management methods with programs that did not. ELDO provides the most extreme example of little or no systems management. None of its rockets ever succeeded, despite piecemeal intro­duction of some systems management methods. Comparison of JPL’s Ranger program with the contemporary Mariner program provides another example, because the Mariner design was a modification of the Ranger spacecraft. With less systems management, Ranger’s first six flights failed, whereas Mariner achieved a 50% success rate, with later Mariner spacecraft performing al­most perfectly. After strengthening systems management, Ranger’s record was three successes out of four launches.5 Assuming Ranger and Mariner costs per spacecraft were roughly equal, Mariner cost less per successful flight than early Ranger.

Aside from pure cost considerations, failures hurt an organization’s credi­bility. In the rush to beat the Soviets, early space programs lived the old adage ‘‘There is never time to do it right, but there is always time to do it over.’’ They had many failures, but in the early days executive managers were not terribly concerned. By the early 1960s, however, failures mattered; they led to con­gressional investigations and ruined careers. Systems management responded to the need for better reliability by trying to make sure that engineers ‘‘did it right’’ so they would not have to ‘‘do it over.’’

It is no coincidence that engineers developed systems management for mis­siles and spacecraft that generally cannot be recovered. When each flight test and each failure means the irretrievable loss of the entire vehicle, thorough planning is much more cost-effective than it is for other technologies that can be tested and returned to the designers. This helps to explain why the bu­reaucratic methods of systems management work well for space systems but seem too expensive for many Earth-bound technologies. For most technolo­gies, building a few prototypes and performing detailed tests with them be­fore manufacturing is feasible and sensible. Lack of coordination and plan­ning (each of which costs a great deal) can be overcome through prototype testing and redesign of the prototype. This option is not available for most space systems, because they never return.

The evidence suggests that systems management was successful in improv­ing reliability sufficiently to cover the cost per successful vehicle. Although systems management methods were not the only factor involved in these im­provements, from the standpoint of reliability, they were critical. Process im­provements, not technology improvements, ensured the proper connection and integration of thousands of components. Systems management increased vehicle costs on a per vehicle basis compared to previous methods but re­duced costs when reliability is factored in.

Social and technical concerns drove the development of systems manage­ment. The dangers of the Cold War fed American fears of Communist domi­nation, leading to the American response to ensure technological superiority in the face of the quantitative superiority of Soviet and Chinese military forces. Military officers and scientists responded to the initial call by creating nuclear weapons and ballistic missiles as rapidly as possible.

Technical issues then reared their ugly heads, as the early missile systems exploded and failed frequently. Investigation of the technical issues led to the creation of stringent organizational methods such as system integration and testing, change control, quality inspections and documentation, and configu­ration management. Engineers led the development of these new technical coordination methods, while managers intervened to require cost and sched­ule information along with technical data with each engineering change.

The result of these changes was systems management, a mix of techniques that balanced the needs and issues of scientists, engineers, military officers, and industrial managers. While meeting these social needs, systems manage­ment also addressed the extreme environments, danger, and automation of missile and space flight technologies. By meeting these social and technical needs, systems management would become the standard for large-scale tech­nical development in the aerospace industry and beyond.

TWO

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Development of rockets began before World War II in a number of Euro­pean countries. Most important was the German program leading to the A-4 ballistic missile, better known as the V-2. Like other early rocket projects, it originated with amateurs in the late 1920s. Just prior to Hitler’s ascension to power in January 1933, Army Ordnance coaxed young engineering student Wernher von Braun to be the technical director of its rocketry program. Army Ordnance drew a veil of secrecy over the project, and the Nazi regime soon began to pour large sums into it. Von Braun’s team successfully developed the A-4 rocket, which terrorized the populations of Antwerp and London in 1944 and 1945. Although its military impact was limited, it caught the attention of military technologists around the world.11

After the war, each Allied power acquired German rocket technology and experts. The United States acquired the lion’s share of both, with rocket parts for more than sixty A-4s and program leaders including von Braun and Arthur Rudolf. The Soviet Union acquired a large number of technicians, a few of the leaders, and parts for some twenty A-4s. With German assistance, Brit­ain launched three A-4s in October 1945 from a site near Cuxhaven. The French acquired a small group of experienced Germans from Peenemunde, who began working at Vernon on an A-4 derivative vehicle and a new rocket engine.12

In March 1949, the French Directorate for Armament Studies and Fabrica­tion decided to build Veronique, a single-stage, liquid-fueled sounding rocket. From 1951 to 1964, French engineers extended the design, improving altitude performance from 2 to 315 kilometers. They initially tested this unguided rocket in southern France, later testing it at Hammaguir in the Algerian desert under the direction of Col. Robert Aubiniere.13

After the 1956 decision to build an indigenous nuclear force, missile de­velopment expanded rapidly. French engineers began development of larger rockets capable of placing a small satellite in orbit. In 1960 the French state rocket consortium, Societe pour l’Etude et la Realisation d’Engins Balistiques (SEREB [Society for Study and Development of Ballistic Engines]), concluded that it was possible to build such a rocket, eventually known as the Diamant. The French created their own space agency to fund the launcher project, while SEREB developed the stages and the military tested them. With some assis­tance from Col. Edward Hall, the U. S. Air Force officer who initially devel­oped the Minuteman intercontinental ballistic missile, these efforts came to fruition with France’s launch of a small test satellite in November 1965 from Hammaguir, making it the third country to launch a satellite.14

The British were also active in rocket design and in the development of nuclear weapons to place on rockets. They tested their first fission bomb in 1952 off the coast of Australia and their first fusion weapon in May 1957 over Christmas Island. From the late 1940s on, they developed a number of missiles, including air-to-surface, surface-to-air, air-to-air, and ship-to-air weapons. When in 1954, U. S. Secretary of Defense Charles Wilson offered to collaborate with the British on a ballistic missile, the British expressed interest and began their own studies. The Americans allowed the formation of agree­ments between the British company DeHavillands and Convair on the missile structure, and between Rolls Royce and North American Aviation for the en­gines. Based on these agreements, the British developed a large liquid-fueled rocket known as Blue Streak.15

It soon became apparent to the British, as it had to the Americans, that liquid-fueled rockets were poor weapons because of their immobility, cum­bersome logistics, and long preparation time to launch, which made them vulnerable to a Soviet first strike. American missile efforts quickly surpassed those of the British, and in 1956 the United States offered to place Thor missiles in Britain five years sooner than Blue Streak would be available. British offi­cials accepted the offer in 1958, and to avoid duplicating Thor’s capabilities, increased Blue Streak’s required range to 2,500 miles. In April 1960, British military leaders canceled Blue Streak in favor of purchasing American air – launched Skybolt missiles and sea-launched Polaris missiles.16

Blue Streak’s cancellation as a weapon led British officials to consider its potential as a satellite launcher. Technically this was feasible. The key ques­tions were political and economic. First, the British had sunk £60 million into the project, which needed £240 million more. Such large expenditures would divert scarce funds and technologists from other scientific and technological endeavors. Second, the technology could be obsolete by the time it was com­pleted. On the other hand, Britain would no longer depend on the United States to launch satellites, an important advantage if communication satellites became commercially viable. Prime Minister Harold Macmillan wanted to use Blue Streak to forge closer relationships with France. Needing French support to join the Common Market, Macmillan calculated that a joint launcher pro­gram with France would smooth Britain’s application process. Supported by the American leaders, who continued to favor European integration, he de­cided to approach the French in late I960.17

The French reaction was cautiously optimistic. French military leaders ex­pressed keen interest in gaining access to inertial guidance technology and nose cone reentry technologies. Because the United States prohibited the ex­port of these technologies to France, this could have been a fatal objection. In other words, if the French insisted on acquiring inertial guidance and re­entry technologies as part of the deal, there would be no deal. Unexpectedly, French President Charles de Gaulle threw himself behind the project, even without the military technologies. De Gaulle saw the project as a means to fulfill French technological ambitions, using space and nuclear programs to create a permanent “technological revolution’’ to support a strong and inde­pendent France. Because the project supported this goal, he supported the project. In a meeting with Macmillan in January 1961, he agreed to join the project and to jointly approach other European governments, under the con­dition that the launcher’s second stage be French. Macmillan and de Gaulle scheduled a conference the next month in Strasbourg to broach the subject with other governments.18

The Germans accepted an offer to build the launcher’s third stage. This gave them the opening to rocketry that they would not undertake alone be­cause of the Nazi V-2 heritage. That left the question of the Italians, who were already building sounding rockets under American license and had just begun their own launch program with a sea-based launching platform in collabora­tion with the United States. The British, who were by fall 1961 desperate for an agreement because of their financial problems, put substantial diplomatic pressure on Italy to join. Negotiations produced the convention for ELDO in March 1962, with Italy to build the satellite test vehicle.

Britain paid a heavy price for its desperation, stuck with 38.79% of con-

tributions to the £70 million Initial Programme, scheduled for completion by the end of 1965. France, Germany, and Italy paid 23.93%, 18.92%, and 9.78%, respectively, and Belgium and the Netherlands paid 2.85% and 2.64% to build the ground and telemetry equipment. The convention came into force in Feb­ruary 1964 after Britain, France, and West Germany ratified it.19

ELDO’s structure emphasized national interests. Because ELDO based con­tributions on existing programs, Britain and France insisted upon managing their stages through their national government organizations, according to their own procedures. ELDO provided but did not control the funding. Be­cause member states contributed funding in fixed proportions but spent it according to costs, each country had a built-in incentive to increase costs to recoup its investment. For example, if Belgium overran its budget by 50%, it would contribute only its 2.85% share to that overrun.20 Member states severely circumscribed ELDO’s authority, rendering cooperation difficult at best. The job of the Secretariat required delicate negotiation skills, a fact rec­ognized in the appointment of Italian ambassador R. Carrobio di Carrobio to the post. When ELDO came into official existence in February 1964, Carrobio would need all of his diplomatic talents.

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

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

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

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

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

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

Systematic, Scientific, and Systems Management

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We are in a technological race with the enemy. The time scale is incredibly compressed. The outcome may decide whether our form of government will survive. Therefore, it is impor­tant for us to explore whether it is possible to speed up our technology. Can we for example plan and actually schedule inventions? I believe this can be done in most instances, provided we are willing to pay the price and make no mistake about it, the price is high.

— Colonel Norair M. Lulejian, 1962

The complex weapon systems of World War II and the Cold War involved enormous technical difficulties. Scale was not the problem, for large-scale systems such as the telephone network, electrical power systems, and sky­scrapers had existed before. Rather, the difficulty lay in the heterogeneity of the components, their novelty, and their underlying complexity. Military per­sonnel were unfamiliar with the new technologies of rocket engines, nuclear weapons, and guidance and control systems.

New technology provided opportunities for military officers with a techni­cal bent. Allied with scientists and research engineers, these officers promoted the ‘‘air force of the future’’ over the traditional ‘‘air force of the present.’’ Through wide-ranging research and fast-paced development, the air force would maintain a technological edge over its Communist adversaries. Sepa­rating research and development (R&D) from current operations, these offi­cers created new methods to integrate technologies into novel ‘‘weapon sys­tems.’’ In so doing, they brought into being new organizations and niches for technical officers, scientists, and engineers.

Of the new technologies developed during World War II, ballistic missiles were among the most promising. The marriage of ballistic missiles with fusion

warheads promised an invulnerable delivery system for the ultimate explo­sive. At the push of a button, an entire city could be obliterated within thirty minutes. While the bomber pilots who dominated the air force’s leadership vacillated, technical officers and their scientific allies pressed ahead and past air force skeptics, winning top-priority status for intercontinental ballistic missiles (ICBMs). Led by Brig. Gen. Bernard Schriever, their success was the apex of scientific influence in the military and laid the foundation for a new way of organizing R&D. Combining scientific novelty with the military’s need for rapid development, this new approach became known as concurrency.1

Concurrency replaced the air force’s prior management methods for large – scale technology development. If the technology of ICBMs had been less com­plex, or if their development had occurred at a more relaxed pace, then the air force’s existing management techniques might have sufficed. Facing the combined impact of technical difficulty and rapid tempo, however, the loosely organized technical divisions of the air force’s development groups could not cope. Equally important, the scientists who advised the air force’s leaders did not believe that traditional methods and organizations would succeed. Based on their recommendations, Schriever created a centralized, tightly planned management scheme to implement the air force’s complex new weapon sys­tem as quickly as possible. To understand the changes that Schriever and his allies wrought, we must turn to the air force’s methods prior to the develop­ment of ICBMs.

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

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

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

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

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

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

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

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

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

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

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

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

Without any staff members except for those supplied by the national govern­ments, and with technical problems more complex than originally thought, ELDO’s Preparatory Group moved the project, now known as Europa I, slowly forward between 1961 and 1964. Although the first and second Blue Streak launches in 1964 succeeded, delays and technical difficulties led to sub­stantial cost escalation, from the 198 Million Accounting Units (MAU)21 origi­nally budgeted (the equivalent of £70 million) to 400 MAU at the end of 1964.22

Commercial communication satellites soon troubled ELDO executives and national representatives. Americans tested their commercial viability with the Early Bird satellite in 1965 and controlled the market through Intelsat, the international consortium for satellite telecommunications. Europeans wanted to break the American stranglehold. In 1964, the ELDO Secretariat reported that an upgraded Europa I launcher could place 20-40 kilograms of equip­ment in polar orbit and that a more powerful ELDO B rocket could place a 1,000-kilogram communications satellite in geostationary orbit in the 1970s. The next year, French officials proposed that ELDO scrap Europa I and in­stead immediately begin work on ELDO B. Other delegates vetoed this as too risky but agreed to reconsider it later.23

Spurred by massive overruns that they disproportionately funded, the Brit­ish reversed their strong support of ELDO in April 1966. They now believed that Europa I would be obsolete and its commercial potential limited and stated that they would neither participate in rocket upgrades nor contribute beyond existing commitments. Under pressure from the other delegations, the British agreed in June 1966 to remain in ELDO, but only if the organization re­duced the British contribution. In July, delegates agreed to this but also voted to fund an equatorial base, inertial guidance improvements, and the Europa II rocket, which could launch up to 150 kilograms into geostationary orbit. The new cost was 626 MAU, more than three times initial ELDO estimates. Britain would not contribute to any costs above the agreed 626 MAU level.

Technical problems soon pushed costs past the limit. In February 1968, after two failures of the French second stage, the British invoked ELDO’s new procedures for projected cost overruns. Two months later, the British announced that they would make no further contributions to ELDO. Italian delegates, angered by the refusal of France and Germany to include them in the bilateral Symphonie communications satellite, and also by their inability to recoup ELDO contracts for their own space industry, refused to agree to a French-German ‘‘austerity plan’’ that would have cut Italian portions of the program. After yet another rocket failure in November 1968, this time of the German third stage, delegates from France, Germany, Belgium, and the Netherlands agreed to make up the shortfall in British and Italian contribu­tions to complete a scaled-back program. Italy finally agreed to rejoin, but Britain would supply its first stage for only two more test flights. After that Britain would be through with ELDO. The remaining partners agreed to fund studies for a first stage replacement.24

NASA International Programs chief Arnold Frutkin noted the “half­hearted and mutually-suspicious character of participation by its [ELDO’s] members.’’ European governments held together only insofar as the United States resisted European commercial interests. With Europeans united in their suspicions that the Americans intended to monopolize communication satel­lites, Frutkin believed, ‘‘US offers in space and other fields of technology will continue to be regarded with extreme and often irrational suspicion until the comsat issue is resolved.’’ In sending mixed signals, American leaders helped keep ELDO alive.25

Changing technological objectives contributed to ELDO’s problems. With­out firm objectives at the start, ELDO and French studies showed that ELDO needed a more powerful launch vehicle to place communications satellites into orbit. The French, who viewed ELDO as an essential part of their drive for independence from the United States, were willing to pay the price. So too were the Germans, who subsidized their own reentrance into rocketry. The Belgians and Dutch believed they needed to go along with their power­ful neighbors. As long as ELDO guaranteed the Italians technically interesting tasks, Italian leaders would contribute. However, the British had little to gain in that the first stage was operational. Convinced of American willingness to launch European satellites, British leaders believed it more important to fund applications satellites than launchers. These differences might have been over­come if ELDO’s rockets had proved successful.

The air force’s R&D methods trace back to the creation of aircraft in the first decade of the twentieth century. Because the army did not create an arsenal to develop aircraft, contractual relationships between the Army Air Corps and the aircraft industry governed military aircraft development. The Army Sig­nal Corps ordered its first aircraft from the Wright brothers in 1908 using an incentive contract that awarded higher fees for a higher-speed aircraft.2 Army evaluation and testing of aircraft began near the Wrights’ plant in Dayton, Ohio. These facilities soon grew into the Air Corps’s primary complex for air­craft development and testing.

While European powers rapidly developed aircraft for military purposes, the U. S. Army kept aircraft development a low priority. World War I broke American lethargy; in 1915, Congress created the National Advisory Com­mittee for Aeronautics (NACA) to promote aircraft research, evaluation, and development for the military and the aircraft industry. Engineers at NACA’s facility at Langley Field in Hampton, Virginia, concentrated on the testing and evaluation of aerodynamic structures and aircraft performance, using new wind-tunnel facilities to test fuselages, engine cowlings, propeller designs, and pilot-aircraft controllability. The United States mass-produced a few Euro­pean designs during the war but rapidly dismantled most of its capability after the war’s end.3

Between World War I and World War II, the Army Air Corps fostered air­craft development at a leisurely pace. Typically the engineering and procure­ment divisions at Wright Field in Dayton contracted with industry for aircraft, which officers, civilians, and operational commands then tested. Army Ord­nance and the Army Signal Corps developed the armaments and electronic gear that Wright Field personnel then integrated into the aircraft. Wright Field procured the components, then modified them as necessary to inte­grate them into the aircraft. Funding constraints were more important than schedule considerations, leading to a rather deliberate development and test­ing program commonly described as the ‘‘fly before you buy’’ concept.4

After the Air Corps released design specifications, contractors designed, built, and delivered a prototype known as the X-model to the Air Corps. The Air Corps tested this model, making recommendations for changes. After completion of X-model testing, the contractor made the recommended design changes, then developed the Y-model production prototype. The Air Corps then ran another series of tests and made further design recommendations. After approval of the Y-model, the contractor released the production draw­ings and built the required number of aircraft.5

From the mid-1920s, Wright Field assigned a project engineer from its Engineering Division to monitor all aircraft design and development. By the late 1930s, Wright Field assigned a project officer to each aircraft in develop­ment, along with the project engineer and a small supporting staff. For ex­ample, in the Bombardment Branch before World War II, Col. Donald Putt and five other officers managed six aircraft projects with the assistance of a few secretaries and Wright Field engineers assigned to tasks as needed. Be-

‘‘Fly before you buy’’ sequential development, typical of the Army Air Corps in the 1920s and 1930s. Adapted from Benjamin N. Bellis, L/Col USAF Office DCS/Systems, ‘‘The Requirements for Configuration Management During Concurrency,” in AFSC Management Conference, Air Force Systems Command, Andrews Air Force Base, Washington, D. C., AFHRA Microfilm 26254, 5-24-2.

cause of the slow pace of development, the limited role of the government in testing and approving designs, and the fixed-price contracting method typi­cal before the war, this small staff sufficed. Project officers focused on aircraft safety and on finding design weaknesses.6

As war loomed in 1940, Congress legalized negotiated cost-plus-fixed-fee (CPFF) production contracts. With a flood of funding and a goal of build­ing 50,000 aircraft, the Air Corps immediately signed letters of intent to get design and production moving, with cost negotiations deferred until later. Under the prior competitive bidding process, procurement officers did not need to understand the financial details of a manufacturers’ bid, because the manufacturer — not the government-lost money if it underbid. However, under CPFF arrangements, cost overruns were the government’s problem. The Air Corps Procurement Branch grew rapidly to collect information and negotiate with contractors to assess the validity of cost charges and determine a fair profit.7

Unless Congress extended the authority to negotiate contracts after the war, the military’s capability to control industry and influence scientists and their new technologies would dramatically decrease. Fortunately for the mili­tary, the Procurement Act of 1947 extended the military’s wartime authority and tools, including the formerly controversial negotiated contract mecha­nism, into peacetime.

The importance of the 1947 act should not be underestimated, for it per­petuated government use of CPFF contracts. This had several significant rami­fications. First, the CPFF contract reduced risk for industry. Where high risk was inherent, as it was in R&D, this drew profit-making corporations and uni­versities into government-run activities. Second, to reduce government risk, CPFF contracts required a government bureaucracy sufficient to monitor con­tractors. Third, CPFF contracts turned attention from cost concerns to tech­nical issues. This “performance first’’ attitude led to higher costs but also to a faster pace of technical innovation and occasionally to radical technologi­cal change. Last, the CPFF contract provided some military officers with the means to promote technological innovation along with their own careers.8

Negotiated contracts formed the basis for Cold War contractual relation­ships between government, industry, and academia. Government officials be­came both partners and controllers of the aircraft industry in a way unimag­ined before the war, with expanded procurement organizations that made the federal government a formidable negotiator. To fully exploit their extended authority to create new weapons, however, the Army Air Forces would also have to solidify its relationships with scientists and engineers.

JPL’s entry into the space program came through an alliance with the Army Ballistic Missile Agency (ABMA) on the Jupiter intermediate-range ballistic missile program. In 1955 and 1956, JPL worked with ABMA on a backup radio guidance system and the reentry test vehicle for Jupiter. The radio guidance work gave JPL the funding and opportunity to improve radio communica­tions between ground systems and flight vehicles, later evolving into JPL’s Deep Space Network. The reentry test vehicle was a spacecraft in all but name. ABMA and JPL performed reentry test flights between September 1956 and August 1957. The Army Ordnance commander, Gen. John Medaris, ordered the remaining rocket hardware to be put into storage, hoping to launch a spacecraft.34 For the moment, Medaris had to wait; the navy’s Vanguard was to launch the first U. S. spacecraft. However, the failure of Vanguard’s first test flight in December 1957 paved the way for the army.35

With public pressure building in the wake of Sputnik, President Eisenhower gave the army the green light to unleash Wernher von Braun’s ABMA team and Pickering’s engineers at JPL. Pickering seized the opportunity. By partici­pating in the space race, Pickering could return JPL to engineering research instead of the drudgery of weapon systems development. In a brief discussion immediately preceding a meeting to assign responsibilities for the orbital at­tempt, Pickering convinced Medaris to assign JPL the spacecraft and tracking network. JPL engineers quickly designed a high-speed stage, eventually des­ignated Explorer 1, consisting of clusters of Sergeant solid motors and a cylin­drical can that contained telemetry equipment and scientific experiments.36

JPL engineers used processes developed on Sergeant and the reentry test vehicle. By the summer of 1956, ABMA and JPL had tested rocket motors in small vacuum chambers to ensure that they would operate in space. Engineers expanded these tests to examine the Explorer spacecraft’s capacity to with­stand large temperature variations in a vacuum, such as it would encounter when in the Sun or in the shade of the Earth. JPL engineers replaced vac­uum tubes with transistors, repackaged electronic components, and tested the entire package with random-vibration tests. In addition, they used re­dundancy to increase the chances for success if one component failed. JPL’s ground telemetry systems were ready. When in January 1958 the ABMA’s Jupiter rose from Cape Canaveral, JPL’s Explorer 1 spacecraft and ground sys­tems functioned perfectly, returning scientific data leading to the discovery of the Van Allen radiation belts and confirming that micrometeorites were not a problem.37

ABMA and JPL followed Explorer 1 with a series of spacecraft in the Ex­plorer and Pioneer series. Because the primary goal was to compete in a prestige race with the Soviets, engineers hurriedly lashed together existing technologies to jury-rig space missions. Explorer 2-Explorer 6, Pioneer 3, and Pioneer 4 had a mixed record, with several successes and several failures. Be­cause of the urgency of the space race, neither the army nor Congress ques­tioned this record. Spacecraft failures occurred out of sight, unlike spectacu­lar rocket explosions and their unpleasant publicity. JPL engineers, used to the army mentality of firing many test rounds, thought of these early space­craft as test rounds and were not overly concerned with achieving a perfect record. They rushed into space and reverted to the earlier Corporal mentality of small project groups using informal methods.38

Despite the exploits of ABMA and JPL, the army lost its battle against the air force and the new NASA for a significant space role. On January 1, 1959, President Eisenhower transferred JPL to NASA, and the ABMA soon there­after.39

For NASA, JPL proposed a new program for lunar and planetary explo­ration known as Vega. Vega was to develop a third-stage rocket and spacecraft similar to Explorer’s high-speed stage and payload. Its spacecraft design was far more complex than Explorer’s because it needed to operate for months in transit to the Moon, Venus, or Mars. The Vega spacecraft was to feature important new technologies, including solar panels, three-axis attitude stabi­lization, and a flight computer. Just as after Corporal, when JPL managers and engineers planned the Sergeant missile as a ‘‘systems job,’’ JPL engineers and managers carefully planned for Vega, succeeding the hastily built Explorer and Pioneer spacecraft.40

JPL Director Pickering selected Clifford Cummings as Vega project direc­tor. Cummings had worked under Pickering on Corporal and Sergeant, de­veloping analytic tools. He believed that better maintenance required better analysis of training programs and costs, supply networks and logistics, test equipment, and vehicle design. Vocal and outspoken, Cummings believed that scientists and engineers could work out difficult problems through work­ing groups and a thorough test program.41

Cummings and his deputy, James Burke, organized Vega’s test program using lessons from Corporal, Sergeant, and Explorer. He and Burke planned a mockup spacecraft for structural and mechanical tests as well as an engineer­ing model for environmental and electrical tests. Only after the engineering model passed these tests would JPL build the flight spacecraft. Vega featured a new ‘‘systems test’’ that would simulate the flight sequence and events with all of the spacecraft subsystems working together. Engineers were to record test results on specialized forms for later analysis. After engineers assembled and tested the spacecraft in this manner, they would then perform the same tests in a large vacuum chamber, then in a vibration test facility, and finally at Cape Canaveral prior to launch.42

Plans for Vega did not come to fruition because NASA Administrator Keith Glennan canceled the program in December 1959 to avoid duplication of the air force’s previously secret Agena upper stage. Glennan decided to use the air force’s Atlas-Agena for NASA’s early missions instead of Vega. Never again would JPL work on the rocket designs upon which it had made its reputation. In place of Vega, JPL acquired NASA’s robotic lunar and planetary missions, which became the Ranger, Surveyor, and Mariner programs. Time spent plan­ning for Vega was not completely wasted, as its design studies and test plans carried over to Ranger.43