NTB: What kinds of controls are needed to manage technical engineering risks?
Dr. Ryschkewitsch: We have a pretty well-established process to do that. It begins with the program and project team, including the technical cadre sitting down and looking at the work at hand and identifying what the risks are that are ahead of them. Sometimes they are purely technical risks: "If this component fails, what is the impact of the mission, and how do we safeguard against that?" We can safeguard against a failure either by making sure that we built a really rugged component, or sometimes adding redundancy, or some kind of intentional workaround to the system.
Sometimes, the risks are programmatic in the sense of "Do we actually have enough time to develop this item? What happens if it takes longer than we think, and what are our potential workarounds?" And that whole process that begins the risk management process is really at the core of program and project management. Eisenhower's quote comes to mind: "Plans are nothing, and planning is everything." In many respects, a project and the technical execution of a project, as well as the programmatic execution of a project, is almost always a continuous re-plan at some level. And I mean that "re-plan" in the sense that, on any given day, you'll be seeing things that'll then start to emerge as problems that you didn't think were going to be problems, and now you need a backup plan. The key to make that successful requires some really good, hard discussions between the engineering safety mission assurance and the program and project management communities to be sure that we're always doing things with the appropriate level of rigor for the risk that we have on hand. And I don't want to leave out, when we're dealing with human spaceflight, the health and medical community is very much a part of that process as well. It's an ingrained, ongoing process, as opposed to very episodic things, and it's something that people have to live every day.
NTB: What kinds of projects currently excite the NASA engineering community?
Dr. Ryschkewitsch: About the only thing that doesn't excite the engineering community is when we have to wait. In terms of the specific things merging into our current environment, I think people are very excited about getting the new human spaceflight plans in place. There's a lot of anticipation of there being augmented funding in the technology arena under a new chief technologist, and that opens the door to a whole lot of small projects.
NTB: Can we dig into your background a bit? Which previous roles or achievements have helped you in your current role as chief engineer?
Dr. Ryschkewitsch: I came to the agency in 1982 without a formal engineering background, because I got my Bachelors in physics from the University of Florida, my PhD in physics from Duke University, then did a post-doc at the University of Delaware – all three in combination of low-temperature physics and high-pressure physics.
What prepared me in that background for coming to NASA was the fact that, in all those, we were doing hands-on experimental work and had to design and build all of our own equipment. Then when I came to NASA, I was very fortunate to have, as my first assignment, to work on the COsmic Background Explorer [cosmology satellite], the mission for which John Mather won his Nobel Prize. That mission was intentionally done as an in-house mission out of Goddard [Space Flight Center, located in Greenbelt, MD] because it had been through a fair amount of hiring, and there had been a good bit of generational turnover. They were looking at a hands-on, in-house program to train the next generation, and I was fortunate to be one of that next generation that was being trained.
That way a pretty seminal experience for me because I had to learn how spaceflight engineering is done, had a lot of good mentors along the way that knew how to yank me back from the edge when I got too close to it, but also knew how to let me get out front and try things. So that was a little over a seven-year process, from the time started on that until the time we launched it. Part of that process was also then having my first roles in leading teams and learning how to help a team to perform, as opposed to performing myself. Over time, I ended up moving up in the hierarchy from division chief, deputy director of engineering, director of engineering, and deputy center director. Each has a different set of challenges, but the common thread through all of them, and one of the things that I really love about NASA, is that this is the ultimate team sport, and it doesn't really matter which role that you're playing within that team if you can figure out how to help that whole team perform better. It's a real rewarding experience. Most of the things we do would simply not be possible for one or ten or even a few dozen. Figuring out how to mesh all of those gears in a way that the machine runs well and at a very high level is a very rewarding experience.