By James Wood
The New Horizons mission encountered an issue with the Atlas V booster RP-1 fuel tank four months before launch — a remarkably complex problem that involved NASA Headquarters, Safety and Mission Assurance, NASA Engineering and Safety Center, and the folks at Lockheed Martin who designed the system. We needed a way to communicate the facts and logic of the situation in greater detail than a typical briefing package provided. PowerPoint was not going to cut it. Engineers have a terrible rap for not being able to write and, to be fair, most aren’t asked to do so. If I’m not asked to do something and I don’t push myself to do it on my own, I won’t ever cultivate the skill, and writing a clear, complete white paper is a skill worth cultivating.
I wrote a lengthy paper describing the Atlas V RP-1 qualification tank failure and our resolution for the Pluto New Horizons mission because I realized we needed a better way to communicate our approach for acquiring and evaluating the data required to make a very tough flightworthiness decision. We needed to articulate specific details and our logical framework in a manner that people who had to come to grips with the issue on multiple levels — technical, management, mission assurance — could understand.
On Launch Complex 41 at Cape Canaveral Air Force Station in Florida, the fifth and final solid rocket booster nears the top of the Lockheed Martin Atlas V rocket in the Vertical Integration Facility.
Photo Credit: NASA
Writing out the logic that leads to a conclusion is a great way to clarify your reasoning to yourself and others. When I write things down, I’m forced to tighten my logic. Many of us think well “on our feet,” but there’s always a danger that the logic developed during a rapid interchange of ideas and solutions has crucial defects that aren’t immediately apparent. Darren Bedell and I, the chief engineers in the Kennedy Space Center Launch Services Program, subscribe to the rule that our logic for resolving a problem has to make sense when written down. I might have something of a preconceived opinion (admit it, most of us do), but when I start writing it out, I find that, wait a minute … this piece of evidence fits here, that fits there, and then, you know, something else might not fit at all anymore. That’s when we realize the logic has a flaw, and we need new logic, or more data, or fresh input — and often all three.
Putting the details and logic in a form that can be read, re-read, and studied also communicates complex problems better than a set of PowerPoint charts accompanied by a verbal briefing. The specifics of the New Horizons problem were difficult to communicate. You could explain them with spoken words and charts to a manager or stakeholder who then might say, “OK, I get it, this makes sense.” But when that person talks to the next person, who talks to the next person, and so on up the chain, you end up playing the telephone game. Even with the best of intentions, things get lost or distorted. Especially for a complex issue like this one, a single wrong or missing detail can be worse than knowing nothing. In addition to testing our reasoning, the white paper helped accurately communicate all the important information to everyone involved.
(Left to right) David Kusnierkiewicz, New Horizons mission system engineer; Glen Fountain, Applied Physics Lab project manager; and Alan Stern, principal investigator from Southwest Research Institute, take part in a dress rehearsal for the New Horizons launch at their consoles in the Atlas V Space Flight Operations Center on Cape Canaveral Air Force Station.
Photo Credit: NASA
Managers of technical review processes have to keep in mind that many people don’t process information very well in a meeting. And people miss meetings or parts of meetings. Before starting the white paper, I had already been convening eight-hour Engineering Review Boards (ERBs) where we hammered out decisions one after another. We can do it — we’re used to doing it, we’re capable of doing it, and practice has schooled our minds to think reasonably well in those forums. But that doesn’t mean that somebody who wasn’t schooled in those forums won’t have a valid point. So I asked myself, “What’s another way I could communicate what we developed in that forum?” We write down our recommendations and rationale from ERBs, but usually not in the kind of detail that would help someone understand what led to our conclusions. The paper for the New Horizons booster RP-1 tank ended up being forty pages long, because that’s what it took to convey the important thoughts clearly.
You simply can’t hand somebody a briefing package and expect him or her to understand the rationale for a decision if they haven’t been exposed to the meeting where the material was presented and discussed. I see that mistake made over and over again. Sometimes you can get the gist of a discussion from the package, and sometimes you can’t. The RP-1 problem was an issue where the briefing package couldn’t tell you the real story.
A white paper allows you to communicate to a wider audience, so people don’t fall victim to the telephone game, and you reach people who are technically capable of criticizing your logic and your data but could not attend your review boards. Ralph Roe of the NASA Engineering and Safety Center couldn’t attend a single one of my review boards, but he provided very effective and useful input through criticism of the white paper and offered recommendations for strengthening our logic. One of his immediate observations after reading an early draft was we had failed to provide a rationale for adequate fatigue life, which is the amount of strain our parts can take before they fail. We had discussed our fatigue life rationale in many forums, but it didn’t appear on any charts. Neither had we done a thorough job of writing that rationale down. I ended up writing another ten pages to express our logic and, in the process, found that our rationale was actually stronger than we’d originally thought. Providing folks an opportunity to offer constructive, informed input outside the lengthy and intense technical meetings adds considerable strength to the technical approach to a complex problem. I run forums open to everyone as long as they don’t bring up cost and schedule, but not everybody can engage verbally or devote time to those forums. That’s an important lesson learned for me.
After New Horizons, Darren Bedell, our other chief engineer, said, “You know, that worked exceptionally well. I’ve got another problem — it’s not similar, but it’s complex. People are being victimized by the telephone game, and we’ve held these awful, lengthy ERBs. Let me write down what we did and why and try that out for people to review and criticize and offer their comments.” It worked beautifully. I understand that the folks working to resolve the shuttle external tank foam issues have also made excellent use of this strategy.
Technicians install strips of the New Horizons mission decal on the spacecraft fairing in the Payload Hazardous Servicing Facility.
Photo Credit: NASA
The white paper tool was always in our toolbox, but I think we now know better how to use it effectively. You don’t often see NASA technical managers writing long narratives explaining why they did what they did and how all the details fit together, but that may be the best way to capture the logic and context of complex decisions. It can be useful both to people at the management level who have not been directly involved in the work and to somebody who’s down deep in the mud with me and my team. White papers are a labor-intensive tool best used when no other will do the job. Writing a twenty-to forty-page white paper for every decision you make is not possible or necessary, and not everyone is used to writing, but we should use it more. Sometimes it’s the only way to go.
ASK Magazine would like to extend special thanks to Matt Kohut, member of the APPEL team and editor of the ASK OCEnewsletter, for his assistance.
About the Author
 |
James Wood is one of the two chief engineers for NASA’s Launch Services Program. After receiving a B.S. in physics, he worked in the industry as a guidance and control systems engineer for several years before joining NASA in 1995. He has been the chief engineer for thirty-five missions since joining the Launch Services Program in 1999. |
