Category The Secret of Apollo

While Ranger and Surveyor floundered, the Mariner project showed JPL’s technical and managerial abilities at their best. After the successful flight of Mariner 2 (also known as Mariner R) past Venus in 1962, JPL targeted Mari­ner 3 and Mariner 4 at Mars, planning to launch during the next opportunity in November 1964.78 Together, they composed the MM64 project, which ex­tended methods adopted from Mariner R and Ranger.

MM64 manager Jack James used committees established on Ranger to help coordinate across the contributing organizations: JPL, Cape Kennedy, Lock­heed, and Lewis Research Center. Four committees coordinated guidance, control and trajectories, tracking and communication, launch operations, and launch vehicle integration. They had no official authority but made recom­mendations to project management. Headquarters named JPL the project management institution to which the other organizations reported.79

James improved communication between the project office, JPL’s techni­cal divisions, and external organizations. Mariner managers and engineers extended the concept of the hardware interface to include operational and management interfaces, including the spacecraft, launch vehicle, space flight operations, project and technical division management, science instruments, and operations. James enlisted the cooperation of JPL technical divisions by creating the Project Policy and Requirements document, which served as a ‘‘compact between the JPL Project Office and the JPL Line Management for execution of the project.’’ Each project manager met weekly with division rep­resentatives to consider ‘‘the most serious problems facing his particular area.’’ JPL also added a monthly meeting with division managers to ensure that they

By 1964, JPL learned by experience the typical profile of engineering changes and, con­sequently, how better to predict costs and schedules, as shown in this change request chart for Mariner Mars 1964. Adapted from From Project Inception through Midcourse Maneuver, vol. 1 of Mariner Mars 1964 Project Report: Mission and Spacecraft Develop­ment, Technical Report No. 32-740,1 March 1965, JPLA 8-28, 32, figure 20.

were familiar with Mariner’s problems and that they released personnel to work on them. These measures ensured sufficient attention to Mariner and made JPL’s matrix structure work.80

Change control had been one of James’s innovations on Mariner R, and he formalized it for MM64. The change control system expanded to include progressive ‘‘freezing’’ of specifications and interface drawings as well as hard­ware, culminating in a final spacecraft design freeze in January 1964 and a support equipment freeze in June 1964. After a freeze, changes could be made only through a change board, which allowed only modifications required for mission success. Project managers kept statistics on changes, noting that the majority of the project’s 1,174 changes occurred at subsystem interfaces and in subsystems that contained state-of-the-art equipment.

Project managers also formalized other processes developed first on Mari­ner R. MM64 management added requirements for parts screening, problem reporting, in-process inspection, comprehensive documentation, and “rigor­ous status monitoring.’’ The managers continued environmental tests, sys­tem tests, and quality assurance procedures developed from Corporal through Ranger. James also continued the Mariner R practice of the ‘‘P list.’’ Any problem making the P list received special attention, with ‘‘the most effective people available’’ assigned to solve the problem.81

James monitored progress through the use of three sets of schedules and through regular and special reports. The primary schedule reported top-level events and milestones in Gantt (bar) chart format to headquarters. The sec­ondary schedules consisted of Gantt charts for each subsystem, major com­ponent, or task. JPL managers called their third set of schedules flow charts, which represented the flow of all of the equipment destined to be integrated in the system test.82 These network charts ‘‘resembled PERT in format and intent’’ but were “intentionally not so extensive as to require handling by a computer.’’ Network flow charts showed the project’s critical path and sched­ule interactions of all subsystem components, integrated and updated from data supplied by JPL’s divisions. The project required updated schedules every other week, in conjunction with a formal report that compared progress with the schedule. Every two weeks, project personnel compiled the data on manual sort-cards that managers manipulated to discern trends and financial implications. Managers monitored some 1,100 flow chart events.83

When combined with the experience of JPL’s engineering staff, Mariner’s organizational techniques ultimately yielded success. Mariner 3 launched in November 1964, only to be declared dead within nine hours. The problem was in the design of the launch vehicle shroud protecting the spacecraft, de­signed by NASA’s Lewis Research Center. JPL took charge of the investigation and quickly developed a solution, leading to the flawless launch of Mariner 4 on November 28. Although the spacecraft had some in-flight difficulties, JPL engineers guided the craft to a spectacular conclusion in July 1965, as the spacecraft beamed 21 pictures of Mars back to Earth, as well as analyzing Mars’s atmosphere. JPL’s success contrasted sharply with five Soviet failures to reach Mars.84

Later Ranger and Surveyor flights confirmed that JPL had dramatically im-

proved its spacecraft management and engineering expertise. Ranger’s last two flights, in February and March 1965, were technically superb. Between June 1966 and January 1968, JPL launched seven Surveyor spacecraft to land on the Moon, five of which succeeded.85

Surveyor’s management underwent significant changes late in the project. In September 1966, JPL managers changed the task structure of the HAC con­tract to a new system known as work package management,86 which realigned cost accounting and monitoring of tasks ‘‘to the individual performing groups in the contractor’s organization.’’ Along with the work breakdown structure, JPL required that HAC submit monthly financial reports with more detailed technical, cost, and schedule information. JPL and HAC management met once per month to cover these topics, with a further ‘‘consent to ship’’ meet­ing scheduled prior to the shipment of each spacecraft to review its test his­tory and problems. HAC and JPL managers developed a thorough ‘‘trouble and failure reporting system’’ that they considered innovative enough to pub­lish a special report on it. The process recorded all test anomalies, required failure analysis by cognizant engineers, involved independent assessments by HAC and JPL organizations, and provided status of failure reports and actions categorized by mission criticality.87

The Mariner Venus 1967 program (MV67) further formalized JPL’s man­agement and systems engineering. Taking advantage of this, MV67 used the MM64 design as a baseline. Project manager Dan Schneiderman, former spacecraft systems manager for Mariner R and MM64, defined a new manage­ment approach at the beginning of the project in a document entitled ‘‘Project Policy and Requirements.’’ He froze the entire MM64 design at the outset, re­quiring change control for any modifications necessary for the Venus mission. The project used three test models: one for antenna and development test­ing, another for temperature control testing, and the third for flight hardware environmental qualification. Engineers also used the qualification model for simulation and command checking during mission operations. Quality as­surance and reliability engineers screened parts, tracked and analyzed failure reports, performed failure mode analyses, verified test procedures, and wit­nessed tests.88

Schneiderman gave the spacecraft system engineer substantial responsi­bility, including preparation and publication of design specifications books for the flight and test equipment. Subsystem engineers supplied “functional specifications” for their subsystems and support equipment. The spacecraft system engineer also maintained current interface and configuration draw­ings and mediated ‘‘disputes arising out of disagreements between subsystem circuit designers.’’ Change control procedures and subsequent design modifi­cation lists were also that engineer’s responsibility. The system manager, the spacecraft system engineer’s supervisor, ran periodic reviews, which included the spacecraft systems interface and subsystems design review, the spacecraft hardware review, the spacecraft preshipping acceptance review, the launch readiness review, and quarterly headquarters reviews.89

MV67’s managers and engineers also trained spacecraft operators through the testing process. System testing checked interfaces between subsystems, be­tween the spacecraft and the launch vehicle, and between the spacecraft and the mission operations system and operators. JPL engineers found that they could train mission operators prior to flight by involving them in the inte­grated system testing at JPL and on the launch pad. The mission operations team members communicated with the spacecraft during these tests using their normal commands and equipment, and they ran compatibility tests with the Deep Space Network. Mariner 5, launched in June 1967, arrived at Venus in October. It functioned well, returning data from its atmospheric experi­ments.90

Later JPL managerial innovations included separation of configuration control paperwork and project scheduling from the system engineer. This routine work was given to a separate Project Control and Administration organization. JPL ultimately required all engineering change requests to in­clude cost and schedule impacts along with the technical changes, in effect recreating a version of the air force’s configuration management.

JPL went on to pursue new missions to Venus, Mars, and Mercury. Even­tually there were the famous Voyager missions to Jupiter, Saturn, Uranus, and Neptune. The laboratory’s success showed the maturity of its processes and experience. JPL’s preeminence in deep space exploration was undisputed.

Firms have shown themselves anxious to collaborate with ESRO as a means of gaining useful experience of the newer management techniques which are indispensable for the effec­tive control of the financial as well as the technical aspects of large and complex projects.

— J. J. Beattie and J. de la Cruz, 1967

The European Space Research Organisation (ESRO) presented a welcome contrast to the ongoing embarrassments of the European Space Vehicle Launcher Development Organisation (ELDO). Created as a service organiza­tion for European space scientists, ESRO overcame its initial organizational difficulties and developed a successful series of scientific satellites. Its achieve­ments proved that effective European space cooperation was possible. Al­though ELDO had been the Europeans’ prime organization to develop space technology, its failure paved the way for ESRO to become the route of choice across the management gap between the United States and Europe.

ESRO’s success owed a great deal to its greater contractual authority (com­pared to ELDO) and to American assistance. While European industry and powerful interest groups focused on the military and economic significance of launchers, ESRO’s scientific satellites seemed insignificant. ESRO’s Conven­tion and procedures consequently had fewer provisions to protect national economic interests than did ELDO, giving ESRO authority that ELDO never had. In addition, whereas Americans did not want to aid Europeans in rock­etry or communications satellites, they cheerfully gave technical and financial assistance to European science.

These factors help explain ESRO’s rise from a small service organization

to the core of Europe’s integrated space organization. Through the authority of its Convention, the ability of its engineering and managerial staff, and the help of the United States, ESRO and its descendant, the European Space Agency (ESA), mastered the art of systems management.1

With Schriever’s organizational foundations set, the immediate task was to push ICBM development rapidly forward and create a detailed plan within a year. Headquarters control and oversight would come through the budget process, so Schriever knew that until he had his plans worked out, he had to keep the budget profile low. He reallocated budgets from several air force organizations and was careful not to ask for too much at the start. Over the long haul, Schriever knew that the massive budget that he needed would re­quire congressional appropriations and that he would have to vigorously de­fend his plan and its costs. To put off this day of reckoning, in October 1954 he requested a relatively small budget, realizing that there would have to be a major readjustment in the spring. ‘‘This support can be obtained by carefully planned and formalized action at the highest levels in the administration,’’ he recognized. In this breathing space, he developed his technical plans, costs, justifications, and political strategy.52

Selection of Atlas contractors was the next task of Schriever’s team. With the design still in flux, this would have to be done based on company capabili­ties instead of design competitions. Bypassing standard procurement regula­tions, Schriever ordered R-W to let subcontracts to potential suppliers to in­volve them in and educate them on the program. This allowed R-W to assess contractors as well as speed development and procurement. Schriever could not ignore all of the air force’s procurement procedures. He had his team cre­ate performance specifications and perform “prebidding activities’’ to pre­pare for a competitive bidder’s conference. Because of the in-depth knowledge R-W had gained through its subcontracts, Schriever had R-W contribute to the Source Selection Boards, providing inputs as requested by the air force. This was a serious (and possibly illegal) departure from standard procure­ment policy, which required that only government officials control contractor selection.53

Schriever directed R-W and his air force team to reassess the Atlas de­sign and to determine Convair’s role. Convair, which had been developing Atlas since January 1946, understandably believed that it deserved the prime contract to build, integrate, and test the vehicle. It vigorously campaigned against Schriever and the upstart R-W. Convair’s leaders sparred with Schrie – ver’s organization for the next few months before they resigned themselves to R-W’s presence. To appease the air force’s scientific advisers, and to gain electronics capability, Convair executives hired highly educated scientists and engineers. For his part, Schriever placed restrictions on R-W to maintain some semblance of support from the aircraft industry. In a memo dated Feb­ruary 24,1955, the air force prohibited R-W from engaging in hardware pro­duction on any ICBM program in which it acted as the air force’s adviser and systems engineer.54

R-W had three tasks: to establish and operate the facilities for the Ingle­wood complex, to assess contractor capabilities, and to investigate the Atlas design. R-W made its first important contribution in the design task. The re­quired mass and performance of the missile depended upon the size of the warhead and the reentry vehicle, for small changes in their mass led to large changes in the required launch vehicle mass. Working with the Atomic Energy Commission and other scientists, R-W scientists and engineers found that a new blunt cone design decreased the nose cone’s weight by half, from about 7,000 to 3,500 pounds. This in turn decreased required launch vehicle weight from 460,000 to 240,000 pounds and reduced the number of engines from five to three. This dramatic improvement discredited Convair’s claim to expertise and convinced Schriever, his team, and his superior officers that the selection of R-W had been correct.55

The most significant technical issue facing Schriever’s group in the fall and winter of 1954 was the uncertainty of the design. Group members simply could not predict which parts of the design would work and which might not. R-W had been investigating a two-stage vehicle, and the initial results looked promising. In March 1955, Schriever convinced Lt. General Thomas Power,

Pre-Gillette organization of ballistic missile development.

the ARDC commander, that a two-stage vehicle should be developed as a backup to Atlas. By May 1955, the WDD was working on Atlas, the two-stage Titan, and a tactical ballistic missile (ultimately known as Thor) as well.56

In the meantime, Schriever considered how best to fund the program. One possibility was to allocate the funds to a number of different budgets, then pull them back together in Schriever’s group. This approach would hide the true budget amounts from effective oversight. However, the budgets required were too large to hide in this manner. With programmatic invisibility un­likely, Schriever’s deputy, William Sheppard, argued that the best approach was to have a “separately justified and separately managed lump sum.’’57

Schriever had already discussed this approach with Gardner, and the two of them plotted a political strategy. Many of Schriever’s budget actions required coordination with and justification to various organizations. Frustrated with the delays inherent in this coordination, Gardner and Schriever decided that they had to increase Schriever’s authority and funding and decrease the num­ber of organizations that could oversee and delay ICBM development. Both Schriever and Gardner recognized that they needed political support, so they vigorously sought it in Congress and within the Eisenhower administration. Gardner and Schriever briefed President Dwight D. Eisenhower in July 1955, eventually convincing him and Vice President Richard M. Nixon — with John von Neumann’s timely support — to make ICBMs the nation’s top defense priority.58

With the president’s endorsement in hand by September, Schriever pre­sented to Gardner the entire air force approval process, which required 38 air force and DOD approvals or concurrences for the development of ICBM testing facilities. Appalled, Gardner had him show it to Secretary of the Air Force Donald Quarles, who asked them to recommend changes to reduce the paperwork and delays. Gardner and Schriever formed a study group, load­ing it, as Schriever put it later, ‘‘pretty much with people who knew and who would come up with the right answers.’’ Hyde Gillette, the deputy for budget and program management in the Office of the Secretary of Defense, chaired the group, which was to recommend management changes to speed ballistic missile development.59

Despite objections from AMC, which did not want to lose any more au­thority, the Gillette Committee agreed with Schriever that the multiple ap­provals and reporting lines caused months of delay. In consequence, the ‘‘Gillette Procedures,’’ approved by Secretary of Defense Charles Wilson on

Ballistic missile organization — Gillette Procedures. Solid lines with arrows show the direct chain of authority. The air force’s commands have no authority over ballistic missile development, and the Air Staff has input only through the Department of Defense Ballistic Missile Committee.

November 8,1955, funneled all ballistic missile decisions through a single Bal­listic Missile Committee in the Office of the Secretary of Defense. Although evading ARDC and AMC for approvals and decisions, Schriever’s organiza­tion needed to provide them information. Schriever stated: ‘‘We had to give them information because they provide a lot of support, you see, so it wasn’t the fact that we were trying to bypass them. We just didn’t want to have a lot of peons at the various staff levels so they could get their fingers on it.’’60 The Ballistic Missile Committee reviewed an annual ICBM development plan, and the Office of the Secretary of Defense would present, approve, and fund the ICBM program separately from the air force’s regular procedures. In the development plan would be information on programming (linking plans to budgets), facilities, testing, personnel, aircraft allocation, financial plans, and current status. By 1958, AMC managers had trimmed industrial facility lead time from 251 to 43 days, showing the effectiveness of the new process.61

The Gillette Procedures relegated AMC, ARDC, and the operational com­mands to aiding the ICBM program, without the authority to change or delay it. From a parochial air force viewpoint, the only good thing about the pro­gram was that the completed missiles would eventually become part of the Strategic Air Command. Many in the air force did not take ballistic mis­siles seriously enough to fight for control over them. Col. Ray Soper, one of Schriever’s trusted subordinates, noted that ‘‘the Ops [operational com­mands] attitude, at the Pentagon, was to let the ‘longhairs’ develop the sys­tem — they really didn’t take a very serious view of the ballistic missile, for it was thought to be more a psychological weapon than anything else.’’62

With the adoption of the Gillette Procedures, Schriever garnered authority directly from the president, with a single approval of a single document each year required for ICBM development. Schriever’s organization drew upon the best personnel and air force services, without having them interfere with his authority or decision processes. These new procedures represented the first full application of project management in the air force, where the project manager had both technical and budget authority for the project. Prior to this time, each project drew funds from several budgets and thus required separate justifications for each. The Gillette Procedures made the air force’s financial and accounting system consistent with the authority of the project manager, although Gardner was unable to separate the ICBM budgets from the rest of the air force.63 With these procedures in hand, Convair and the contractors under control, and the air force’s regular bureaucracy shunted out of the way, Schriever drove the ICBM program at full speed, with little heed to cost, using the strategy of concurrency.

From its early beginnings as a student research project, JPL relied on its own expertise. Its engineers developed new technologies prior to and during World War II and contracted their successful solid-rocket innovations to in­dustry. Corporal and Sergeant continued this pattern, with JPL performing the initial analysis, design, and development and contracting to industry for manufacturing. In the NASA era, JPL continued to develop new technologies, contracting for small items that it did not want to manufacture, or as with Surveyor, when it did not have enough personnel to take on more work.

Recognition of the ‘‘systems concept’’ marked JPL’s transition from re­search to engineering development. JPL engineers found that they could not develop entire weapons and their operations using research structures and processes. Engineers had to develop all aspects of the missile, not just those that were “technically sweet.’’ By the mid-1950s, the difficult experience of Corporal led to the systems approach on Sergeant, with formal methods to ensure reliability and operational simplicity. In the late 1950s, JPL reverted to informal processes to create small spacecraft in a great hurry, leading to a spotty reliability record. By the mid-1960s, after disaster on Ranger, JPL engi­neers and managers had learned once again not to rush into building systems before laying the groundwork.

Reliability was another concept JPL learned from Corporal and Sergeant. Corporal had an abysmal operational record, partly because of the failure of electronic components when shaken by rocket engine vibrations, and partly because of a design never intended for operational use. These two lessons formed JPL’s primary belief regarding reliability: good design, solid manufac­turing practices, and rigorous testing made a reliable product. This approach served JPL well — but not well enough for deep space. New kinds of failures plagued JPL’s early spacecraft, including short circuits caused by floating par­ticles, and software errors. JPL solved these problems through performing component inspection, using simpler designs, coating exposed wires with in­sulating materials, and instituting ‘‘systems tests’’ to flush out interactions be­tween subsystems and in command sequencing.

Change control became one of JPL’s primary means to control projects. Jack James, project manager for Mariner Venus 62 and MM64, developed pro­gressive design freeze on Sergeant to ensure delivery of design information from JPL to Sperry. James and his supervisor, Robert Parks, used the concept again on the Mariner Venus 62 project, then formalized its use on MM64. The Ranger project began to use James’s new process after the Ranger 5 investiga­tion.

Systems engineering, which began as coordination between technical divi­sions and between JPL and its contractors, became a hallmark of JPL. By 1963, JPL engineers taught space systems engineering at Stanford, where Sys­tems Division Deputy Chief John Small described systems engineering as the “coordination of several engineering disciplines in a single complex effort.’’ According to Small, systems engineers looked at the interfaces and resolved ‘‘problems so as to benefit the overall system.’’ They also coordinated the over­all test program, defined command sequences to operate the spacecraft, and analyzed ‘‘the various interactions’’ between subsystems to determine where subsystem redundancy would most improve chances for mission success.91 Other engineers described systems analyses and tradeoffs performed to de­termine the best mix of components and operations for a given mission.92

JPL engineers repeatedly found that many technical problems could be solved only by using organizational means. Problems with missile reliability demanded engineering design changes, parts inspections, and test proce­dures. Systems engineers solved interface problems by maintaining interface drawings, mediating subsystem disputes, and chairing change control meet­ings to track and judge design modifications. By 1965, JPL’s managers and engineers had learned these lessons well and had become the technical leaders they always believed they were.

JPL developed organizational processes equivalent to those created for the air force’s ballistic missile programs. Strong project management, systems engineering, and change control formed the heart of JPL’s system, just as they had in Schriever’s organization. Both organizations developed them as re­sponses to reliability problems and to political pressures from higher authori­ties. For JPL and the air force, engineering processes for reliability and change control as well as managerial processes for project and configuration manage­ment formed the basis for large-scale development. Although JPL influenced robotic spacecraft development and organization at NASA, it had relatively little influence on NASA’s manned programs. The manned programs could have learned from JPL’s experiences of the 1950s and early 1960s. Instead, they underwent their own crises. Rather than asking for help from their sister field center, they instead turned to the air force.

FIVE

The creation of ESRO began with the activities of Edoardo Amaldi, Italian physicist and one of the founders of the Conseil Europeen pour Recherche Nucleaire (CERN [European Committee for Nuclear Research]). In the sum­mer of 1958, after a conversation with his friend Luigi Crocco, a rocket pro­pulsion expert and professor in Princeton University’s Department of Aero­nautical Engineering, Amaldi proposed a European space program modeled on CERN. The new space organization should have high goals, Amaldi said, comparable to efforts in the United States and the Soviet Union, but have ‘‘no connection with whatsoever military agency.’’ He believed that it should be ‘‘open, like CERN, to all forms of co-operation both inside and outside the member countries.’’2

Amaldi learned from Crocco and from American aeronautical engineer Theodore von Karman some difficulties in modeling a European space orga­nization on CERN. Because the military had developed virtually all rockets, excluding the military would be difficult. Crocco also believed that it would be difficult to convince European parliaments to spend the huge sums necessary for space-based science research. Von Karman thought it necessary to include the military at the beginning to jump-start the civilian effort. He suggested working through the North Atlantic Treaty Organization. Amaldi demurred and eventually found a strong ally for his purely scientific space organization in his friend Pierre Auger, a French physicist and CERN ally.3

When Amaldi contacted Auger in February 1959, Auger was organizing the French Committee for Space Research. Auger was supportive ofAmaldi’s pro­posal and suggested the French organization as a model. French scientists and administrators were considering a two-phase program: a small initial effort based on sounding rockets, and a more ambitious program to include satel­lite launches and lunar or solar probes. After the two men met in April 1959,

Amaldi helped establish an Italian space research committee on the French model. Amaldi also sent a paper titled ‘‘Space Research in Europe’’ to promi­nent scientists and science administrators in Western Europe.4

These contacts led to an informal meeting of scientists from eight different countries at Auger’s Paris home in February 1960. At the next meeting, held in April 1960 at the Royal Society in London at the behest of the British National Committee for Space Research, the British presented their extensive space re­search plans and the possibility that the British government might offer the Blue Streak rocket as the basis for a European launcher. Auger hosted the next meeting in Paris in June 1960 to consider ‘‘A Draft Agreement Creating a Pre­paratory Commission for European Collaboration in the Field of Space Re­search.’’ 5 During the second Paris meeting, British delegates removed launch­ers from discussion because of negotiations under way between the British and French governments concerning the use of the Blue Streak. With launcher considerations eliminated, the scientists and scientific administrators focused on creating a European space research program using sounding rockets and satellites.6

Further discussions clarified the purpose and scope of ESRO and estab­lished goals for its initial scientific program and facilities. ESRO would sup­port space scientists throughout Europe. It excluded launch vehicles, although at the request of the Belgian delegation, it did include the development of sup­porting technologies. ESRO planners envisaged a two-phase effort: an initial program using sounding rockets, and a more advanced program of sophisti­cated scientific satellites.

Bruising negotiations determined the sites of ESRO facilities. To expedite coordination with ELDO, ESRO’s headquarters wound up in Paris. ESRO’s most important facility was its engineering unit to develop spacecraft and integrate scientific experiments, the European Space Technology Centre (ESTEC). Originally located in Delft, The Netherlands, ESTEC soon moved to the small coastal town of Noordwijk, north of The Hague. The telemetry data analysis center went to Darmstadt, West Germany, the sounding rocket range to Kiruna, Sweden, and a small science research center to Delft. A new sci­entific research center with ill-defined functions, located near Rome, satisfied Italian demands for an ESRO facility. In 1967 ESRO officials moved satellite tracking to Darmstadt, where combined with the data analysis center it be­came the European Space Operations Centre. ESRO established remote track­ing stations in Alaska, Norway, Belgium, and the Falkland Islands.7

European scientists originally conceived of ESRO as an organization run by scientists, for scientists, on the model of CERN. CERN provided an infra­structure for European physicists to perform experiments with particle accel­erators. In CERN’s organization, scientists determined the technical content of projects and infrastructure, and ran daily affairs. Administrators had little control over CERN’s funding, and significant overruns developed.

ESRO provided a similar service function to space scientists through provi­sion of sounding rockets, satellites, and data collection and analysis facilities. Scientists selected ESRO’s experiments, but, unlike in CERN, engineers devel­oped and operated the infrastructure. The British insisted on strong financial controls, ensuring that if ESRO overran its budget, it would cut projects in­stead of forcing governments into funding overruns.8 Because the founding scientists did not want ESRO’s scientific expertise to rival that of the member states, they restricted ESRO’s scientific research capabilities, making its engi­neering character more pronounced. ESRO’s engineering culture made it a very different organization from CERN.

Ten countries signed the ESRO Convention of June 1962: the United King­dom, France, Italy, West Germany, Belgium, The Netherlands, Sweden, Den­mark, Spain, and Switzerland. ESRO came into official existence on March 20, 1964, with Pierre Auger as secretary-general.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusion

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

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

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

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

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

THREE

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

— T. Alexander, in Fortune

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Lieutenant Colonel Benjamin Bellis, 1962

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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