J-2X Extra Rocket Alchemy: How Paper Becomes Precious Metal

Alchemy isn’t practiced much these days in the medieval sense.  That’s a shame.  A little extra gold would be useful.  But there is little doubt in my mind that alchemy is exactly what is going on behind the scenes, deep within the dungeons of NASA as we develop a rocket engine. 

How do I know?  Because I have been one of the chief alchemists for J-2X (…in fact, I kind of like that title: “Manager of Alchemy”).  No, we don’t start with a heap of scrap metal and end up with bars of gold or the philosopher’s stone.  Rather, we start with a heap of paper and end up with a rocket engine – and, well, a larger heap of paper.  As much as bending and grinding and welding and balancing and casting and torquing, the story of the paperwork is big part of how a rocket engine comes to be.

Hold on!  Yes, I am endeavoring to present here a blog article about paperwork and, further, I am endeavoring to make it (reasonably) interesting.  Really.  All along I have tried to convey the complexity and scope of what it takes to design and develop a rocket engine.  It ain’t easy.  That’s why not everyone does it and even we don’t do it very often.  And, like it or not, paperwork is what makes it all happen.

Here is how we at NASA develop launch systems:

Joe Mega-genius wakes up with a vision for what NASA ought to be doing.  He alone has the image in his mind for a launch system for exploring space.  He single-handedly directs everyone at NASA and every contractor as to what to do, what analyses to run, how thick the metal of a feedline needs to be, how the launch pad should be configured, the shapes of the knobs on astronaut’s control panels, the material to be used for the springs in the check valves on the engine, everything.  He personally takes care of all management and business and procurement activities so that there is a single, non-contradictory point of contact for everything.  And nobody at any other NASA center or Congress or the Administration questions what he says so he gets all the money in the world to spend as he sees fit because, after all, he is Joe Mega-genius.

All it takes is one brilliant focal point and everything falls into place easily.

Guess what:  That’s a lie.  This is not how it works.  Further, that is NEVER how it worked.  Never.  All cinematic or mythological approximations of that scenario are, simply, myths.  Nobody can know that much or do that much.  It takes many, many people and (good) paperwork is the key to get many, many people successfully coordinated. 

Note that specifically what I want to talk about is the paperwork that enables and facilitates development.  That is somewhat different than the many products that result from a development effort other than the hardware itself.  Perhaps we can talk about all of those other products at another time.  I also don’t want to talk about the paperwork at the highest levels, between the Federal Administration and Congress, the Office of Management and Budget (OMB) and agency authorization bills and appropriations bills, etc.  Interesting stuff, but not quite right for this blog (to say the least).

Let’s start with the assumption that we have a mission.  Let’s say that it is simply this: Get XX payload to low earth orbit.  Okay, simple enough.

How?  Well, there are lots of ways to launch something.  There are different rocket configurations using different propellants in different combinations.  Each potential solution brings with it certain positive and negative aspects, consequences far and wide.  So, we have a trade study and come up with a “best” solution.  That “best” solution has a particular configuration and piece parts that all have to work together.  So, we write down what those various parts all have to do.  Those are the top-level requirements.

So, we start with one mission objective and now we have requirements for the launch vehicle itself, for the launch pad, and for the launch control center.  If we just focus on the launch vehicle, we then have to further break down the requirements into separate groups for the payload section – including, of course, a crew element if we’re putting people in space – and the various stages and boosters.  And, on those stages there will be engines, so you have to break down the stage requirements into separate groupings for the engines and the tanks and propellant feed systems and the structures and the electrical systems and guidance and control systems. 

Thus, you start with one extremely broad mission and, in just a few steps, have dozens of separate groupings of requirements for dozens of different things that all need to work together.  At each step along the way, you need to figure out a conceptual design, i.e., a series of plausible configurations and functions for the various components, and then assign those necessary characteristics as requirements before you take the next step downwards.  And if you should decide at any point along the way that you want to change something higher up in the chain, then, boom, you have repercussions throughout everything below. 

This whole process is called requirements decomposition.  The management of the process represents a huge task at the early part of a development program and remains important throughout as you head into the verification phase where you demonstrate that every requirement has been fulfilled.  In the diagram below, you see the decomposition process.  Every place where there is a dashed line and a red dot I’ve loft out details, i.e., lots more stuff. 

What is the result of all this by the time it gets to, say, the J-2X?  Well, for J-2X we’ve got just about 200 requirements dictated to our development effort from the vehicle project level.  These requirements cover performance characteristics and physical properties and functionality and safety and operations considerations and standards as to how things are made and analyzed, plus a bevy of items dedicated to how the engine effectively interacts with the stage.  These requirements define, at the top level, what the J-2X shall be when development is complete.

Now what?  You’re at the beginning stages of a development effort and you’ve got in hand a book of requirements to fulfill, so what do you do next?  You make plans. 
• You create a plan for the overall development effort.  This includes how many development engines are you going to build and test, how many tests you’re going to run, where you’re going to run those tests, what you’re going to do in terms of testing at the component level, what analyses are you going to do, what level of non-destructive and destructive evaluation will you be performing on built and/or tested hardware. 
• You also make plans for how you’re going to manage the office and manage the various “office disciplines” such as risk management, business management, systems engineering and management, and configuration management. 
• You have an overall plan for how and what safety-related assessments and analyses are going to be done and by when.  This needs to be tightly coordinated with other elements of the launch architecture since the whole notion of safety is a wholly integrated consideration.
• You have to generate a clear plan and process for how decisions are going to be made since nearly all big decisions have budgetary or schedule or technical risk implications.  To enable these processes you issue charters to delegate formal authority for decision-making boards. 
• And there’s much more…

So, that’s how you get started.  In the beginning, you don’t usually have any hardware.  All you have is paper (or, these days, computer files).  And you’ll hear lots of people complain about “paperwork this and paperwork that,” but without this foundation of documentation, nothing else can follow.  What does come next beyond this foundation is that you fulfill your plans.  You do the design, do the analyses, create the drawings, fabricate the hardware, assemble the engine(s), and then test the hardware to demonstrate that you’ve met the imposed requirements. 

Thus, just as the rocket engine is itself a complex machine, so too is the infrastructure coordinating the efforts of hundreds of people to arrive at the final product.  In some ways, it’s even more complex than the rocket itself: imagine a shiny rocket engine rising out of a pile of paperwork.  It is truly, in the end, almost alchemy.