Category The Secret of Apollo

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.