What do you think?
Rate this book
New Series in NASA History
The Secret of Apollo: Systems Management in American and European Space Programs
Winner of the Emme Award for Astronautical Literature from the American Astronautical Society How does one go about organizing something as complicated as a strategic-missile or space-exploration program? Stephen B. Johnson here explores the answer―systems management―in a groundbreaking study that involves Air Force planners, scientists, technical specialists, and, eventually, bureaucrats. Taking a comparative approach, Johnson focuses on the theory, or intellectual history, of "systems engineering" as such, its origins in the Air Force's Cold War ICBM efforts, and its migration to not only NASA but the European Space Agency. Exploring the history and politics of aerospace development and weapons procurement, Johnson examines how scientists and engineers created the systems management process to coordinate large-scale technology development, and how managers and military officers gained control of that process. "Those funding the race demanded results," Johnson explains. "In response, development organizations created what few expected and what even fewer wanted―a bureaucracy for innovation. To begin to understand this apparent contradiction in terms, we must first understand the exacting nature of space technologies and the concerns of those who create them."
312 pages, Paperback
First published June 26, 2002
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 9 of 9 reviews
July 29, 2020
This is not for the general reader. It smells like a reworked PhD dissertation (that may explain some sociological blather in the last chapter about competing interest groups, rather than mission success). However, it might be of great interest to someone (like myself) who has worked in major space system development. It traces the history of how effective system management methods were developed, from the first crash programs in the 1950s (Atlas and Corporal missiles) to the successes of NASA in Apollo and the European Space Agency in Spacelab.
The early programs were run by research engineers and scientists, using informal and ad-hoc methods of control, partly because of the Cold War urgency of missile development, and partly because of the research development heritage of the German rocketeers and the American National Advisory Committee for Aeronautics (predecessor of NASA, founded in 1915). The resulting missiles worked poorly and failed often. The Air Force learned rapidly, and did much better with the next generation of missiles (Minuteman). The Jet Propulsion Laboratory (JPL) started out working for the Army, then switched to primarily supporting NASA after the latter was created to manage the civilian space program. They learned more slowly, and the Ranger probes they managed had an embarrassingly high failure rate. Personnel and processes from the Air Force were imported into NASA, to the great improvement of system management for the Apollo program. (Systems Engineering methods were adopted later at Marshall Space Flight Center than elsewhere in NASA, apparently because of the long history of in-house rocket development, going back to the 1930s among the many Germans there, made informal methods workable.) Meanwhile, in Europe, the European Launcher Development Organization (ELDO) "combined many of the worst management ideas into a single pitiful organization" (p. 178), and was dissolved without ever achieving a successful space launch. A science-oriented European Space Research Organization (ESRO) vigorously imported American space system management methods and did much better; it was reorganized into the engineering-oriented European Space Agency (ESA) in 1975 and co-operated with NASA to create the Spacelab laboratory that flew as a Space Shuttle payload. ESA continues to be a major space agency today.
So what are the secrets to good systems management? Project organization and a strong Project Manager (rather than separate organizations for engineering, test, etc.). Separate offices for systems engineering, system integration, quality, reliability, and so forth. Close supervision of contractors, with visibility into their processes and progress before product delivery. Work package management. Phased planning. And change control, which has remarkable prominence for such a dull and process-oriented endeavor. It turns out that you can't let an engineer with a screwdriver make a change on his own, however good it seems to him at the time. Every change needs to be written up, costs and effects assessed, and approved by a Configuration Control Board that understands the entire system.
Some interesting definitions: Systems management is a "bureaucratized research and development process" taken out of the hands of scientists and research engineers for the sake of assuring definite results. Systems engineering is "coordination of several engineering disciplines in a single complex effort."
The early programs were run by research engineers and scientists, using informal and ad-hoc methods of control, partly because of the Cold War urgency of missile development, and partly because of the research development heritage of the German rocketeers and the American National Advisory Committee for Aeronautics (predecessor of NASA, founded in 1915). The resulting missiles worked poorly and failed often. The Air Force learned rapidly, and did much better with the next generation of missiles (Minuteman). The Jet Propulsion Laboratory (JPL) started out working for the Army, then switched to primarily supporting NASA after the latter was created to manage the civilian space program. They learned more slowly, and the Ranger probes they managed had an embarrassingly high failure rate. Personnel and processes from the Air Force were imported into NASA, to the great improvement of system management for the Apollo program. (Systems Engineering methods were adopted later at Marshall Space Flight Center than elsewhere in NASA, apparently because of the long history of in-house rocket development, going back to the 1930s among the many Germans there, made informal methods workable.) Meanwhile, in Europe, the European Launcher Development Organization (ELDO) "combined many of the worst management ideas into a single pitiful organization" (p. 178), and was dissolved without ever achieving a successful space launch. A science-oriented European Space Research Organization (ESRO) vigorously imported American space system management methods and did much better; it was reorganized into the engineering-oriented European Space Agency (ESA) in 1975 and co-operated with NASA to create the Spacelab laboratory that flew as a Space Shuttle payload. ESA continues to be a major space agency today.
So what are the secrets to good systems management? Project organization and a strong Project Manager (rather than separate organizations for engineering, test, etc.). Separate offices for systems engineering, system integration, quality, reliability, and so forth. Close supervision of contractors, with visibility into their processes and progress before product delivery. Work package management. Phased planning. And change control, which has remarkable prominence for such a dull and process-oriented endeavor. It turns out that you can't let an engineer with a screwdriver make a change on his own, however good it seems to him at the time. Every change needs to be written up, costs and effects assessed, and approved by a Configuration Control Board that understands the entire system.
Some interesting definitions: Systems management is a "bureaucratized research and development process" taken out of the hands of scientists and research engineers for the sake of assuring definite results. Systems engineering is "coordination of several engineering disciplines in a single complex effort."
July 21, 2020
I read this to learn about those NASA systems engineering secrets that Dominic Cummings is always blogging about. Got some interesting information about the structural evolution of US and European space exploration and a bit about gradually freezing designs and so forth from a systems engineering standpoint. The book was written in 2002 and the author is adamant that SpaceX style iterative development, if applied to rockets, will only lead to delays, cost overruns, and explosions. Well, SpaceX does have more explosions than ULA which employs a very US space traditional systems engineering standpoint but no more than is typical for a modern rocket company. I wonder if the difference is modern simulation technology or something organizational. Well, it's going to take another book to figure that out.
July 16, 2021
Well, I think you need an interest in the space field to find it interesting. However there are bits and pieces that also is valuable for the everyday reader, such as understanding “it’s not rocket science” and that the complexity of all contractors is complex.
Also interesting to hear the parallel development of the European space sector and how much it owes the foundations of from NASA.
Also interesting to hear the parallel development of the European space sector and how much it owes the foundations of from NASA.
June 7, 2020
Pretty dry, but also a fascinating history of the development of systems engineering and management in the aerospace sector. Lots of great anecdotes and lessons learned.
Want to read
October 15, 2016mentioned in Team of Teams
November 14, 2009
Let's face it: you wouldn't read this book unless you or someone you cared about was a Systems Engineer. But. If you ever wanted to know WHAT it is, WHERE it comes from, and WHY organizations use it, this is the scholarly book for you.
May 15, 2009
This book was hard to follow in that it jumped around among unfamiliar systems, however it follows the birth and development of systems mgmt.
August 1, 2014
Interesting look at Systems Management, especially when comparing to software design practices. Not for the faint of heart, this is a dry-read.
Displaying 1 - 9 of 9 reviews