As NASA's Chief Engineer, Michael Ryschkewitsch is responsible for the overall review and technical readiness of all NASA programs.

NASA Tech Briefs: Michael, can you take us through your roles and responsibilities as Chief Engineer?

Dr. Michael Ryschkewitsch: I and my office are the stewards for the agency policy and program/project management, system engineering, software, as well as the engineering technical standards. In addition to that, we have the role of being responsible for all of the training and the knowledge management for engineering program project management on system engineering. And so the way that manifests itself is through our APPEL program and a set of courses, a lot of different knowledge management forums that vary from workshops to specific training. Some of those we do in partnerships with the mission directorates. It's experiential-based, and directed at knowledge that's learned on the job and augmented with formal training.

NTB: What kinds of specific training? And how important is that process?

Dr. Ryschkewitsch: The key for system engineers, project and program managers, and engineers in general, is that the bedrock of honing people's skills is to actually be doing things. The core of the training programs that we've put in place, though they're augmented by classroom training, reading and handbooks, is making sure that people, as they're growing into more and more responsible positions, have the right mentoring in place, and that we are overtly thinking about the next capabilities that they need to grow, and get them into an environment where they have the proper challenges in front of them. You always want people to be in the position where they have to take steps that they are a little uncomfortable with. As they learn, then they learn to take even bigger steps the next time.

NTB: What is your relationship with the NASA engineering community? How do you keep the lines of communication open?

Dr. Ryschkewitsch: Two ways: One of them is through the formal reporting processes that are primarily program- and project-oriented. They roll up through our NASA Program Management Council and our monthly baseline performance review, and we're heavily involved. But also, very directly, I lead the engineering management board, and have very frequent conversations with the engineering directors at all the centers. So I stay in touch of progress. Some of that is simply the routine of "Yes, we've done all the proper reviews, and everything looks good." Other times it's an engagement around specific technical issues that come up. Notable recent examples are the issues that we had with the Shuttle External tank stringers, and proving to ourselves that we had a system that was safe to fly. That involved a whole lot of episodic interactions, sitting down with people along the way, saying at various points in time, "What do we know? What do we not know? And how are we going to get to a point that we have adequate knowledge to be sure that we're safe to fly?"

NTB: What other teams are you working with?

Dr. Ryschkewitsch: Personally, the chair of the standing review board for the Mars Science Lab (MSL). I have quite a bit of interaction with pretty much every science mission director and project. Of course, the interactions with ones that are having challenges like the James Webb Space Telescope (JWST) are more frequent than others that are proceeding along smoothly. There's a lot of standup work, for example, in the new human spaceflight program, working with mission directorate and the engineering teams in support of programs and projects to try to get those properly defined and underway.

NTB: What are the most exciting engineering-related achievements that you've seen recently?

Dr. Ryschkewitsch: For a lot of these things on the science mission directorate, of course, we tend to see them in the front pages of the newspaper. There seems to be a new discovery every week, everything from the first really good images of Mercury, from the Mercury Messenger [space probe], to the latest Hubble [telescope] discovery. It's kind of astounding that we've become so used to a mind-blowing new discovery out of Hubble that it becomes almost routine, and you have to step back and say "Boy, we're in a position that we get to see something that human beings have never known before." Going into earth sciences: Almost on a weekly basis we're seeing some new revelation, or we're seeing an application of NASA technology. Everything from helping to map the extent and the effects of the Gulf oil spill to being able to assist the Forest Service in fighting wildfires. On the human spaceflight side, of course, we're into the last few missions for the space shuttle. We have a truly amazing national laboratory with a lot of potential. We're getting ready to put a new high-energy astrophysics instrument on there. It doesn't feel like coming to work, because there are so many exciting things that go on every day.

NTB: As Chief Engineer, your job is to assess policy and the technical readiness of NASA programs. When performing this task, what are you looking for, and what is your process and criteria when assessing a NASA program or project?

Dr. Ryschkewitsch: We have a pretty well codified set of entrance and exit criteria of where programs and projects ought to be at various stages of their lifecycle. Those are embodied in our program and project management standards, system, and engineering standards, and the handbooks that go with them. So those will be guidelines that say, "When we're supposed to be at a preliminary design review level of maturity, then we ought to be seeing these kinds of attributes."

What we're looking for very early on in the lifecycle project, when we're in the formulation phase, is a solid process that identifies where the technological challenges are going to be with the mission, in particular with the development of new technologies and reducing the risks that they have. Typically we don't see mission failures as a result of new technologies, but we frequently see programmatic challenges when we've underestimated how long or how much money it's going to take to get something mature to the point that we're ready for flight.

So we're looking for a very well-defined process that lays all of that out, and checkpoints along the way that allow us to assess whether we've actually gotten the progress that we had intended or we need to step back and do some more work before we go on to the next steps.

NTB: In the chain of events of a NASA program or project, where are you and what role do you play?

Dr. Ryschkewitsch: As the agency chief engineer, typically, I'm directly involved in the large projects, in the decision-making process, as we commit to the next phase of activities at different points in the lifecycle. For example, during the transition from our formulation of projects to the development of projects, I'm very heavily involved in the review cycle and the decision-making that goes into making the final commitment to develop the project and making sure that we have the adequate resources in place and the schedule. The other big area of engagement is typically in the process leading up to the point of which where we say we're ready to fly. For example, in the shuttle launch commitment process, I sit on the agency flight readiness review board, which is the culmination of a number of review panels that start at pretty low levels: sometimes at the board or box or subsystem level, or up through major element levels, like external tank or the orbiter itself. It's a program readiness board that makes sure that everyone has gotten everything done. After that, that's the point at which we say, "We're ready to go fly."

NTB: What are the biggest technical challenges for NASA's engineers that you've seen in the field?

Dr. Ryschkewitsch: There are always very specific ones that crop up in projects. Often times, in a development project of a one-of-a-kind system, it'll be in the actual transitioning of a technology from the point at which we've built an engineering model, or built some kind of a test model that's sitting on a bench, and transitioning it into flight. That process tends to be fairly expensive, can take a long time, and it's at the point where in the lifecycle of the project, typically, other things are starting to accelerate. So that's always a challenge to make sure that we can keep that up and do it with the proper vigor to be sure that we don't let problems creep in.

If I look at the challenges that are in front of us right now, our biggest single one is figuring out how to do the things that we need to do for the future. We call it affordability. It's really to do it in a way that's as efficient and effective as it possibly can, so that, within the resources that the Congress and the President give us, we do as much as we possibly we can with that.

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.

NTB: What is your biggest challenge as chief engineer?

Dr. Ryschkewitsch: The fun part is just trying to keep track of all the things going on across the agency. In times of transition, there are always challenges associated with trying to make sure that we're finding the most constructive path forward both balancing the near-term needs of the programs and projects to keep things moving ahead, as well as the longer-term needs of the institution and the workforce.

We're in a multigenerational activity. Our very big missions will sometimes take decades, from the time that they're first a gleam in the eye of a scientist or project team to the time they launch them. The present science advisor and administrator has said that Mars is our ultimate destination. That's a multi-decade activity as well, which means that it's not only important that we perform efficiently and effectively on the projects that we have in front of us today, but that we also maintain a healthy institution in terms of the technical capabilities that are rooted in the centers, and vary especially the workforce that we're going to need. The people that will be in leadership positions by the time we get to Mars are people that we haven't hired today. It's very important that we're working with the NASA workforce, but also that we're also making sure that we do the right things to create a vibrant pipeline of people, which really starts with middle schoolers when they decide whether to take algebra or not, or to focus on science classes and to go into a technical field.

NTB: What is your favorite part of the job today?

Dr. Ryschkewitsch: I'll give you two answers that are kind of at the opposite end of the spectrum. It is immensely rewarding to see one of our mainstream science missions launch, and to know what it takes to do that and all the people that have done that.

The other end of the spectrum is I just get a huge charge out of talking with the young engineers that come in here and think that it's not possible for them to have a better job in the whole world. They're excited about coming here, and I just know that they're going to be doing great things for the next 20 to 30 years.

For more information, contact This email address is being protected from spambots. You need JavaScript enabled to view it..

To download this interview as a podcast, click here .


NASA Tech Briefs Magazine

This article first appeared in the July, 2011 issue of NASA Tech Briefs Magazine.

Read more articles from this issue here.

Read more articles from the archives here.