In the automotive industry, we take engineering seriously and we do "system engineering". However, I have yet to find somebody who can tell me a good definition. What it means changes according to context. On my quest to understand it, I have read a few books by now. "The Secret of Apollo" was the closest one so far.
The historic context seems relevant to understand it. In this case, we must look at the history from World War 2 until the sixties. The Manhattan Project cost $22 billion (in 2021 USD). The project started in 1942. Three years later, two novel weapons worked on the first try in Hiroshima and Nagasaki. Usually, Oppenheimer gets the spotlight because his life provides a more dramatic story. However, the logistics mastermind was General Groves.
The Manhattan project built multiple new plants all over the USA. They invented new engineering processes on the way. They captured uranium ore internationally. They captured scientists from Nazi Germany. They did all of that in secret.
A bomber pilot in WW2, Bernard Schriever became the mastermind behind the next level, intercontinental ballistic missiles (ICMBs). This time, it was not just a project. It was the creation of an ecosystem, a whole industry. Larger rockets than ever before had to be built because nuclear warheads were heavy. They installed hundreds, then thousands of missiles.
Rocket science was not just for war though. It also started the space race and eventually project Apollo landed a man on the moon in 1969. As associate administrator of NASA, George Mueller gets the mastermind halo here. It is this time period which the book, The Secret of Apollo, is about.
The problem systems management solves
What do the projects from Manhattan to Apollo have in common? They worked at the frontier of human knowledge, so scientists were not just consulted but involved. They worked at large scale which required solid engineering. Lots of money was spent and many managers tried to control costs. It was always about national security, so the military was involved. It is those four groups the book highlights: Scientists, engineers, military officers, and managers. Systems management is a collection of methods which nicely balances the needs of those groups.
Each of them is necessary: Scientists provide novel technology. Engineers make the technology useful in practice. Managers optimize resource use. Officers provide focus on the actual goal.
There is no fixed balance. For example, in early NASA times, scientists and engineers dominated, but later managers and engineers got more power.
On the flip side: If your situation does not involve all four of them, the systems management is probably not the right approach.
For example, the book briefly touches on the automotive industry, specifically Total Quality Management (TQM), for an alternative to systems management.
The Japanese approach, bred in the "stable-tech" automotive and similar mass production industries, may well be suitable for American mass production industries but is not well suited to R&D. Japanese industry has been quite successful at copying American innovations and mass-producing them but far less successful at producing its own innovations. The Japanese are far more likely to gain from American systems management for their R&D than Americans are to gain from applying manufacturing-based TQM to R&D, for the simple reason that systems management developed as an R&D process and TQM did not.
Johnson is a proud American, apparently. An entire chapter of the book is about how Europe (today's ESA) failed with rockets until they finally learned systems management from NASA.
Also, I'm working in the automotive industry. This isn't for me? Not so fast, Johnson also addresses software development and automotive software might be different.
One significant place where systems management spread is the computer software industry. [...]
More than with any hardware artifact, software development is a pure process, and the final product is itself a process. Current methodologies in software development, such as structured or object-oriented programming, are variations on systems themes: simplifying interfaces, enhancing communications, considering the entire product, and dividing tasks into simple work packages. Whatever might be said about software, the industry is rarely deemed overconservative or lacking in innovation. Perhaps systems approaches prevent computer programmers and computer scientists from finding a radically better way of developing software. Or perhaps they are the only thing preventing software from sinking into total chaos.
Ok, he acknowledges that some questions are still open. Anyways, the closing paragraph of the book summarizes what it is for.
Through the combined efforts of these groups of people, technological innovation has become a standardized commodity throughout the Western world. Systems management has tamed R&D. Political, military, and business leaders now plan for new technologies years in advance, using the services of scientists and engineers to promote their tools of our technological civilization. Change is now the norm, a standardized product of systems management.
Systems management is coordinated large-scale technology development, would be my one-sentence summary.
How systems management solves the problem
Let us take a look at this collection of methods. The book does not go into them in detail, since that is left to groups.
-
Scientists: Operations research, systems analysis, cost-benefit analysis, functional organization with committees, and quantitative reliability.
-
Engineers: System engineering, systems integration, contractor penetration, functional organization with committees, design freeze, change control, qualitative reliability, quality assurance, environmental and system testing.
-
Military officers: Concurrency, technical direction, control rooms, project organization, configuration management, multiple source competition, and system testing.
-
Managers: Phased planning, PERT / critical path method, contractor penetration, project and matrix organization, configuration management, work package management, and quality assurance.
This is the list of ingredients apparently. Proven in use at NASA over multiple projects, even decades by now. What the book is unable to tell is the recipe; how much of each? Well, the question is hard because we cannot quantify "how much" we use a method. It also changed over time as mentioned above.
Some things never change
For anybody working in large-scale projects, everything seems to repeat. I found myself nodding along for several stories in this book. For example, since the amount of information flowing around in a large project is too much for any individual, misunderstandings and rumors are unavoidable. Every once in a while it erupts in politics, like the following resistance against configuration management.
MSC Director Gilruth had heard that configuration management cost one additional person for every manufacturing team member. If this was true, then configuration management would be far too expensive.
Next step in the playbook: The change champion steps up and tries to defend against the rumor with facts.
Phillip's team replied that based on Minuteman experience, configuration control required only one person per one hundred manufacturing team members.
Then someone else takes the debate to a higher level.
MSFC Director von Braun objected: "This whole thing as a tendency of moving the real decisions up [...] from the one guy who sits on the line to someone else." Boeing President Bill Allen replied, "That's a fundamental good management." After all, he said, "Who, around this table, makes important decisions without getting advice from the fellow who knows?" Von Braun retorted [...] Allen, whose company originally created configuration management, replied that you merely had to move the "top engineering guy into the position of the configuration manager."
I chuckled at the word "merely".
The root cause for disagreement is usually that people have different experiences from past projects. So everybody pushes their anecdotal evidence dressed up with smooth-sounding principles like "flexibility".
Frustrated in this argument, von Braun retorted that because the military produced a thousand Minutemen, whereas there was only one or just a few Apollos, "We have to retain a little more flexibility." Again, Boeing's Allen disagreed.
Eventually, some authority decides based on their anecdotal evidence.
OMSF chief Mueller intervened; on the Titan III program, the first with configuration management from the start, Mueller noted, "Everything is on cost and schedule, even though it married solids and liquids." [...]
Naturally, a top-down decision gets defused on its way down the hierarchy.
Mueller, who had the ultimate authority to force implementation, quelled executive objections, but resistance continued in other forms. MSC assigned only one person to configuration management [...] There was continued engineering resistance to change control, Phillips noted: "Engineers always know how to do it better once they've done it, and want to make their product better." Yet "even engineers will admit that changes first of all must be justified."
Also a classic is that in between someone claim that the core idea is very simple.
"Configuration management – doesn't mean you can't change it. It doesn't mean you have to define the final configuration in the first instance before you know that the end item is going to work. That isn't what it means. It means you define at each stage of the game what you think the design is going to be within your present ability. The difference is after you describe it, you let everybody know what is is when you change it. That's about all this thing is trying to do."
It is so simple. Why don't you understand? Everybody who works in large projects or corporations knows this feeling.
Who should read this book?
This book is a good introduction to the history of systems management if you bring the motivation. It is not a "life-changing, everybody should read it" book.
Since I work in large-scale projects myself, I can relate to the challenges described in a way, which would have been impossible for me six years ago. If you don't have that experience yourself, the book is abstract. You might find yourself thinking "why didn't they simply..." objections.
Before this book, I already read some others about this history:
- "Now It Can Be Told: The Story Of The Manhattan Project", an autobiography of General Groves.
- "Racing for the Bomb: General Leslie R. Groves, the Manhattan Project's Indispensable Man" by Robert S. Norris
- "A Fiery Peace in a Cold War: Bernard Schriever and the Ultimate Weapon" by Neil Sheehan
The Secrets of Apollo is a dry book but also a short one. Having some deeper knowledge of specific historic parts was helpful. On my reading list is still "Doing the Impossible" by Slotkin, which focuses on Georg Mueller at NASA. All those books have more detail and more story. The Secret of Apollo provides the overarching summary. So I recommend it to anybody who really wants to know this history. This is the best summary I know.