NASA Johnson Space Center Oral History Project
Tacit Knowledge Capture Project
Edited Oral History Transcript

Donald S. Noah
Interviewed by Rebecca Wright
Houston, Texas – 9 July 2008

Wright: Today is July 9th, 2008. We are at the NASA Johnson Space Center to speak with Don Noah, Manager of the Space Shuttle Systems Engineering and Integration. This interview is being conducted for the JSC Tacit Knowledge Capture Project for the Space Shuttle program. Interviewer is Rebecca Wright, assisted by Sandra Johnson. We'd like to start today with you giving us your background on how you came to work with the Space Shuttle Program.

Noah: I came over to the Shuttle Program from Payload Safety in 1988. It was after the [Space Shuttle] Challenger [STS 51-L] accident, and we had the Shuttles going through Return to Flight at that time. When I came over, they were within a few months of flying something like the first flight for Return to Flight. I came over and was doing Cargo Engineering, and Larry [E.] Bell was the Manager at that time.

My primary purpose coming over was doing an integrated cargo hazard assessment for the complement of cargo we were flying on each mission. Each payload individually comes in with the set of safety requirements that they had to meet. But there was no one—and that was kind of a hole that we found in the Return to Flight—there was no one that was integrating the cargo from a safety aspect. So I came over to the Cargo Engineering Organization to go manage that process for doing an integrated hazard assessment for a cargo complement, which was made up of several different payloads.

I did that for a year, two years. Then I asked for some hardware projects that were coming along. Cargo Engineering, at that time, for each of the payloads, there was usually some interface hardware that needed to get built to meet some special requirements for those payloads. That office managed those different projects, so I asked to be assigned to some of those.

So I got assigned to the INTELSAT [communications satellite] reboost mission, which had three different hardware items that we managed out of Cargo Engineering. One was the payload power-switching unit, which we still use today, which is kind of nice every time I see that. The flight-support equipment for a capture bar that we used on INTELSAT reboost—an astronaut went and captured the INTELSAT satellite on the RMS [Remote Manipulator System], and then the capture bar had two functions. One was to capture the satellite, gain control of it; and then it had a grapple fixture on the end of it that the RMS was able to now maneuver it back into the cargo bay and attach it to—with EVA [Extravehicular Activity] assist—a new booster engine. The INTELSAT satellite's booster had failed, and so it was left in a low-Earth orbit; needed to be at geo-synchronous. So they strapped on a new booster that would put it up into geo-synch.

So I was Project Manager for those hardware items through supporting that flight. Then along came Shuttle-Mir [Program], which we talked about [in a previous oral history session, August 4, 1998], had great fun. I was assigned Integration Manager for the Russian docking module.

After that, got assigned as the Manager of Engineering Integration Office, which was kind of a branch in the Systems and Cargo Integration Office where they combined what was traditionally the Shuttle Systems Integration with Larry Bell's Cargo Integration. They combined those two offices and made one. Within that office, I was one of the Office Managers.

About four years later, I was asked to be Deputy of the Systems Integration Office. I was the Systems Integration Deputy until 2003. Then the new office in the [Space Shuttle] Columbia [accident, STS-107] Return to Flight [STS-114] they created in the Flight Ops [Operations] Integration Office, which John [P.] Shannon was the Manager, and I was Deputy to John Shannon for that.

After that I went to the External Tank [ET] Project and was a Technical Assistant to the Project Manager at first, and then her Deputy left. Sandy [Sandra C.] Coleman was the Project Manager at that time. She asked me to be the Deputy ET Project Manager, which I did for two years. Also during that time I was asked to be the Manager of the Michoud Assembly Facility [MAF, New Orleans, Louisiana], resident office for External Tank Project. About a year I did that in conjunction with doing ET Deputy Project Manager.

Then last year I came back to Johnson Space Center after living two and a half years in New Orleans to be the Manager of the Systems Engineering Integration Office. And here I am.

Wright: The roles that you've had have varied, but certainly have had some common threads. Share with us the details about the memorable ones and the lessons you learned dealing with the challenges that you encountered throughout these different jobs.

Noah: Well, my entire career, I've been quite fortunate. I don't remember a job that I just never really loved coming out to work. So I was quite fortunate in that respect. Certainly my favorite jobs that I've had were the hardware project jobs. They were always a lot of fun. The INTELSAT reboost was a lot of fun. We had a tight schedule. It was a short time. Satellite was stuck in low-Earth orbit. Back then, we were flying commercial payloads. That was after Challenger, which we were getting away from that, but NASA still had some commitments for flying commercial payloads.

So INTELSAT was essentially a commercial payload, and time was money. When the satellite's not on orbit, it's not making money. So we had a fairly tight schedule to go implement that flight. It was really one of the first projects I had for developing hardware from concept to building to delivery to test verification and in flight. So going from womb to tomb on a hardware project is really the only way to get the experience. It was quite valuable in being able to pull that off.

One of the things that I learned out of that was that you got to get the right people doing the right jobs. After it was over, we had a few problems on flight that we worked through. That was exciting and kind of nail-biting for a while. But one of the things I learned in looking back over the project, and from the very beginning, if you don't have the right people doing the right jobs, then it can cause you problems later on.

Specifically in the case of that, I had a group of folks that were really good at designing EVA interfaces and EVA tools. So we had them design the capture bar that the astronaut was interfacing with, which made logical sense. But the capture bar had a capture mechanism on it, which there's another group within the JSC engineering that is very good at designing capture mechanisms. So not having those folks from the JSC engineering organization that does capture mechanisms involved in the design of that capture bar was a mistake. So that taught me you've got to make sure that you know what your mission is, you know what your requirements are, and then getting the right people on the project that can assist you in making sure you've got the right design and the right implementation. So that was a good learning experience.

Of course we talked about the Shuttle-Mir. That was one of the most fun things that I did. In dealing with the Russians, and the language barrier, and dealing with their culture, the engineering culture that those folks had. It was just incredible. It was a great experience from a personal standpoint as well as professional standpoint. Of course the challenges on that were getting past the cultural barriers. But the technical part was really not all that hard, because engineering is engineering. Doesn't matter what language you're in. So when you're talking about engineering things, it was actually quite easy. I was lucky in that the Russians that I was dealing with, we worked really well together. We had a common purpose.

There was another short-fuse project where from concept to implementation was less than two years to flight. Short turnaround projects like that are a lot of fun, because so many things have to happen quickly. You're not bored at all. It keeps you busy. Takes a lot of time away from your family, but it does keep you busy.

In working with the Russians, we had several technical challenges and agreements that we had to make to make sure that that mission would be successful. In working with them, we all seemed to have the common goal of getting to that point, and all the technical issues that we had were worked out fairly quickly, so it was quite enjoyable.

Certainly the ET project, when I was ET Project Manager. The project's managed out of [NASA] Marshall Space Flight Center [Huntsville, Alabama] and the Project Manager’s there. They wanted their Deputy to be on-site at the Michoud Assembly Facility in New Orleans, where the tank's built. Going to a manufacturing facility like that and being a part of the hardware, large hardware project, was certainly a great experience from a professional standpoint. You learn a lot.

During that time, we were in the Return to Flight activity. So we were not so much in production, getting tanks out the door, as much as reinventing how we put foam on the tank to go address the things that the Columbia Accident [Investigation] Board had suggested. So it was more of a development timeframe, which would be similar to when they first started designing the tank. We were redesigning how we put foam on the tank. We weren't necessarily playing with the formulation of the foam itself, but the techniques and the processes for how you put the foam on the tank makes a lot of difference in how well the foam adheres to the tank. You don't have debris falling aft as you're going uphill.

So I was there at a developmental timeframe, and that was a lot of fun. Toward the end of my tenure there with the ET Project, we were starting to address the production issues, bringing all the different production processes back online to start manufacturing tanks, which we did. So being there for that, and seeing how that activity goes, and being a part of it was quite enlightening. Quite frankly it helps you do your job. If you're in Systems Integration, understanding hardware and understanding how hardware's manufactured, understanding the design challenges that those people have and the issues that they deal with on a daily basis—it helps you do your job as a systems integrator.

In Systems Integration, you're looking across the entire program, which includes the External Tank, the Solid Rocket Motors, with the SRB [Solid Rocket Booster] systems, the Orbiter, the ground launch processing facility, and assuring that issues and items are worked in an integrated fashion. That when one thing affects one element, are there impacts to other elements that are a part of that system. I've been lucky.

Wright: Let me ask you a couple things that you were talking about, and how they pertain to, for instance, planning. You were talking about short-term projects, and then you were also talking about development, as far as the ET. How important is it, or in what elements of planning can you share with us that's essential to making a successful program?

Noah: Well, on the short-term projects, without a plan, it's impossible to be successful. There's lots of elements and there's lots of tools that have been developed. The Shuttle Program didn't invent these. These were invented way before even Apollo, because Apollo followed these same processes. But a lot of people don't like to spend a whole lot of time doing requirements. It's awful. One of the hardest things to do is to sit down and write down your requirements. But it's so important that you do that. You really have to be disciplined, and you really need to spend some time and make sure you have your requirements defined, because it will save you so much heartache and pain later on in a project that it's unimaginable to think about not spending some time there. If you don't write down your requirements, you'll never know when you're done.

Wright: I like that.

Noah: So in the short-term project, you force yourself. You sit down. You write your requirements. You have requirements reviews. You get other people to come in and help you write your requirements, different from the folks that wrote the original set. That way, you get a fresh perspective on what you're trying to do. A lot of times, they'll ask you questions that you don't really think about when you're going through. It's a lot easier to go look at someone else's work and make comments about that than it is to sit down with a clean piece of paper and start writing requirements. So if you're writing requirements, you write those down, then you have reviews, and have other people come in and help you refine those. Then usually you come out with a good set of requirements.

Once you've done that, then you go through your design processes. It is important. The PDRs and CDRs, which are Preliminary Design Reviews and Critical Design Reviews, are concepts that have been around a long time. There's different designs or different projects. You may tailor those to fit your project, but the concept of having an early design review to see if you're on the right track, and then a later design review once you've got most of your drawings done, 80 or 90 percent done. “Did I meet my requirements? Am I on the right track?” So those tools that are in place, that all projects at some point have gone through and dealt with, are things that really, you have to force yourself to go do.

Right at the beginning of the INTELSAT reboost, I hadn't really had a whole lot of experience in Project Management, so I did take a class that NASA Headquarters [Washington, D.C.] offered, and I think they still offer those. There was Project Management and Advanced Project Management. I took the Project Management class, which was a total of two weeks. It was two weeks separated by some time, but a total of two weeks. It was an excellent course. NASA does do a really good job of at least having training opportunities to meet your needs for no matter what kind of job you get. There's all kind of training out there.

The Project Management classes were quite helpful, that I took through the Headquarters organization that does the training. I had already started the INTELSAT project when I took this class, and so this kind of confirmed or strengthened some things that I was already doing, but then gave me some ideas to go do additional stuff. So certainly folks that are coming into NASA and taking advantage of the training opportunities that NASA has out there for you to do is quite important. They are usually good courses.

Wright: You also mentioned that in your current job you get to view the whole program and how everything needs to work together. With all those different aspects of it, how best do you plan for program efficiency, with budget constraints and requirement changes? Are there aspects you can share with us that you look for to ensure that the program will result in good efficiency?

Noah: Each project element is responsible for how efficient they are. They're given a set of requirements that they need to go meet. So in meeting those requirements, they're given usually some budget marks, which are sometimes challenges from the budget office. So how efficient they do to get the requirements that they have that they need to go meet within the budget marks that they have is kind of up to them. I don't really get involved in that. How I go do the integration products that we're doing in this office certainly is under my authority and what I can go affect. But I don't look at it. That's not one of my jobs, is to go make sure that the Shuttle program is efficiently operating from a budget standpoint.

My primary job is to make sure from a technical standpoint that the different elements, interfaces are defined, and that each element is meeting those interface requirements, and that the whole system is performing as designed. So we do integrated analysis, reconstruction analysis, to verify that the whole system, during ascent, operated the way we predicted. That's a whole myriad of things that's involved in making sure that the vehicle is performing. We do risk assessments for the mission. One of the things that we added since Return to Flight from Columbia was a debris risk assessment process. So we've added that. The vehicle is shedding debris all the time. So we verify and do the assessment, is that debris within a risk that's acceptable to the program? As we get surprises or things change, then we go update our risk assessment based on the performance of the previous mission. So if we get surprised on a mission then we have to go back and go make sure, “Did we really cover that, or is it something new that we need to go cover?” We've gotten pretty good the last couple flights. Most of the debris events that we've seen have been within our risk assessment. So we're getting pretty close on that.

We do integrated hazard analysis within the office. We're looking across interfaces from a safety perspective. So I have folks that perform the hazard analysis. The hazard reports are really just good tools for identifying hazards and identifying controls. A lot of times, the controls are within each of the elements. So it's a good process for us to go through and identify what we need to go work on with the different elements. So the integrated hazard reports, in and of themselves, are just a tool to help us logically go through the different systems and verify that different elements are doing the right things in controlling unknown hazard for a particular system.

Then there's environments—induced environments, natural environments—that we go make sure that each element has the right set of requirements to go design to. We monitor those environments, both the natural environments—we just updated the natural environments for the launch pad with a new set of data—and we go monitor our induced environments, which are environments that are induced by operating the Shuttle. So we're constantly checking our induced environments to make sure they're within the allowables or design that the vehicles were designed to.

Wright: When we first started, you mentioned about having the right people. How do you determine who those right people are? How do you find them, and how do you keep them?

Noah: That's a good question. There’s two flavors of that. You can have the right people working directly for you. If you've got really good people that are constantly growing, you're not going to keep them very long. You'll keep them for a while, but they're wanting to go do other things, which is good. As long as you've got people that other people want, you know you've got the right people, or at least you've got good people here. So I've always wanted to have an organization that other people would see as an opportunity to grow their careers and be a stepping-stone to something that's maybe a little bit more responsibility. I've never really wanted to hold anybody back that wants to move out and go grow themselves and their career. So what that does, in my mind, helps me recruit other people that want to come into the office and work.

Finding the right people, a lot of times it's people that you worked with on specific issues or projects or whatever that maybe work for another organization, and it's someone that maybe has a good fit for a position that you need to go fill. You go ask them, and sometimes they come over because they want to go do that, and sometimes they don't.

We work quite a bit with our contractors, both USA [United Space Alliance] and [The] Boeing [Company]. By working through different functions that they have to go do, you get to know certain people. That sometimes is a good source for bringing folks and that you know are high performers, someone that may want to come work on the government side of the project.

It's a challenge sometimes, especially now that Shuttle is in a phase of retiring in 2010. We thought by now we would have trouble bringing folks within the Shuttle program because it's retiring, but we're finding that it's not really. There's still a lot of folks that want to work on the Shuttle program, which is kind of refreshing. But it is the only manned launch vehicle the United States has. So if you can work for that program for a year, you might as well. Personally, as long as they'll let me stay here, I plan to stay with Shuttle program until the very last mission. But sometimes that's not—because [N.] Wayne Hale and I both were saying that to each other, and two weeks later, they asked him to go do something different.

Wright: New opportunity?

Noah: New opportunity.

Wright: It's interesting you mentioned him, because he was a manager for you, and we were just talking about people. How do you build an element of trust between your team and the management?

Noah: For me, my first inclination for people is to trust them. It's not been that hard to do, working at NASA, because almost everybody out here wants to do the right thing. If someone ever loses my trust, they'll probably never get it back. There's been very few of those, because most folks are passionate and committed and want to do the right thing. That's not just, I don't think, so much because of my personality or who I am, I think that's just the way this program attracts those type of people, or has in the past. So my tendency is usually trusting folks unless they prove otherwise, and that's very rare.

From my own perspective and someone gaining my trust, or like Wayne Hale trusting me, a lot of times, that's truly gained in you give some responsibility, maybe a small responsibility or something, and how do they respond to that. As you work through different areas over a career, you learn to trust someone based on their performance in previous tasks. So if you give a task with less responsibility up front, and they do a good job and report to you on a regular basis, and you trust their judgment on that, then you give them a little bit more responsibility and they do a good job, and they use good judgment in making decisions. So you work through experience with someone. There's different levels of trust relative to how competent is the person technically. You get that from the experience of working with them.

Integrity is another trust—does the guy lie to you or not? My inclination is I always assume someone's going to tell me the truth, unless they prove otherwise. Once they prove otherwise, then it's real hard to get that trust back. Usually they need to go work somewhere else, because I'm not going to work with them. But that's been very rare, because most folks here are committed to doing the right thing.

So in my mind, there's two levels of trust. One is I can trust that person to make sound technical decisions, and I can trust that person to always tell me the truth. In most cases, you measure the first one, the technical, based on work experience with the guy. Then just the second one's based on experience, has the guy or person always been truthful to you.

Wright: Along those thoughts, if you were responsible for training or equipping the next group that are coming in to work for the future of the space program, what would you use and what techniques would you want to instill?

Noah: Along the same lines of building trust, or just in general?

Wright: Just in general. What kind of tools would they need? What's their background? What do you think would be best to equip this next group of space agency leaders?

Noah: It kind of depends on what that person wants. When I think about a new set of folks coming in, out of college or out of different jobs, it's what are their career motives and what are their objectives for where do they want to be later on in their career. A lot of folks are really not suited for being managers. In some cases, they want to be in leadership positions. Sometimes they work toward that goal, and they at some point get in a leadership position, and they're not really happy doing that. Then there are some folks, the lucky ones, that actually early on recognize that they don't want to be in leadership positions, and they want to be in technical positions. They're much more happier later in their career if they're still working.

Fortunately, JSC in the past has allowed those two career paths, to where someone can be in a technical leadership-type position where they are recognized as a technical expert in specific field. Then they give you the career path to go through management. I actually didn't think I'd like being in the management. They asked me to do it, and I said, "Okay." I actually found out I enjoy it also. I like the technical part, but I don't mind. Actually I like the personal part, the management part of the leadership.

So I happened into it by, "Okay, well, they asked me, so I'll do it." I never really planned—a lot of folks say in their career, they had a plan out here. "I want to be the manager of this office by the time I'm whatever." I never really did that. I always looked in not so much a 20-year plan, but I always looked in the next five years, say. "What type of job would I like to be doing within the next five years?" I always moved to positions that I enjoyed doing. I got offers for jobs that I really didn't think I'd like doing that, and I took them down, even though they were promotions. So I only moved to jobs that I knew I'd like doing that job.

I would recommend that to people. Don’t move to a job just for a promotion, because that's the wrong reason. It's a lot easier to get up and come to work when you really like what you're doing. The money difference is not that much between the different grade structures in civil service. So the recommendation is try a lot of different things. You need to try, early in your career, a supervisor job. If you can rotate into one or do it on the fly, if you think you want to get into management, that's the right place to start. Then you'll understand whether or not you like people reporting to you, or if you want to just be from a technical standpoint, then you make those career forks in the road as you get to them.

As far as training, depending on which path you want to go, you need to kind of decide which path you want to go. If you can't really decide, then you need to try a little bit of both. As I said, NASA has—at least during my career, and I know they have this because I still see the same type classes coming through for my folks—they have lots of really good training opportunities for folks to go develop those skills, either in management or in technical. They allow you to go out and work on your degree. Either part-time or you can go take a leave of absence and go work on an advanced degree. So NASA is very good at allowing folks to go develop themselves professionally, and their career. Most managers that I have were all very amenable to allowing that.

I ended up getting my Master's in Finance at night, going to night school. Took me four years, but I finally got it. But that was from a personal—you got kids at home and all that stuff. So from a personal standpoint, it was the right way for me to go. But NASA's very good at allowing people to go off, take a year leave of absence, and work on either a Master's or even some folks have gone up and done Doctorates. So take advantage of the training opportunities that NASA does afford you. Decide which career path that you think you want to go down. If you're going down one career path, and you realize that's not going to be the way you want to go, it's not that hard to change and go in a different direction.

Wright: Speaking of leaving, you mentioned that you were a couple years working out of New Orleans. Can you share with us what the differences are working from different Centers? Also, might want to add into that, because you mentioned when you were working with the Russians, that was a different culture. But are there different cultures at the different Centers, and even within the different groups that you integrate, that you have to learn so that you can best manage?

Noah: One of the things that working at different Centers—and I highly recommend it, if your personal life can allow you to do that, working at different NASA Centers. And the Shuttle does a pretty good job. There's lots of folks that have worked at [NASA] KSC [Kennedy Space Center, Florida]. In my case I went to MAF, which MAF is an extension of Marshall Space Flight Center, just like White Sands [Test Facility, New Mexico] is an extension of JSC. Especially in the job that I have now, where integration, you got to deal with a lot of people.

Working at Marshall, you've got ETs, Main Engines, and Solid Rocket Motors, three different major projects for the Shuttle program were all at Marshall. Having worked at Michoud and going back and forth to the Marshall Space Flight Center in Huntsville quite a bit, you build relationships with those people. Whether you know it or not, just by knowing people makes—when I have an issue or something, I know all the folks at Marshall that I need to go call and talk to. It's a lot easier to do that when you know someone more on a personal basis than just out of the cold, a name on an org [organization] chart over there. So networking and building relationships across the different Centers—and Constellation, heck, they're spread over ten different Centers. Building those relationships among the people is very important.

The culture between Marshall and JSC is really not all that much difference. They've got an excellent engineering organization over there, and they've got excellent Project Managers. They do a really good job of developing their managers. They've had, in the past decade or two decades, probably done maybe a little better job than JSC has done because of the type of work that they do there and the hardware projects that they've had. JSC, luckily we did do the X-38 [crew rescue vehicle] here at JSC, which gave our engineering folks some hands-on design and manufacturing experience for a spaceship, which is quite important. So there's really not that much difference between them from an engineering culture. There's a few things that the Marshall folks do a little bit different than the JSC folks. But really they're all about the same. It's not that big of a difference.

The real benefit, in my mind, is not so much of understanding a different culture as much as building relationships with the people and getting to know folks across the different Centers that help you when you're working issues, that it's quite easy to go call those folks up.

Wright: What would you consider that has been the hardest lesson or maybe the best lesson that you've learned through your career?

Noah: Best or hardest lesson. Best lesson. I don't know, that's a tough one. Thinking from the hardest lesson. Hardest lesson being something that I just didn't want to learn it, but I really needed to anyway?

Wright: Maybe you needed to.

Noah: I don't know. That's a tough question. I'll have to think about that.

Wright: Okay, we'll let you think about it. What advice would you share with someone wanting to join the space program now?

Noah: I can't imagine doing anything else. In my mind, this is the best work in the country. You don't have to grow up. I mean, a kid loves to shoot rockets. Except for now you get to shoot really big rockets. I just couldn't imagine doing anything else. So I'm a little biased in telling someone, from a career standpoint, go work for NASA. Absolutely, go work for NASA, or one of the contractors. The contractors, in my mind—some folks don't have the same view, but I do—we're all one team. I don't really care what kind of badge you've got on. Each has different responsibilities and different perspectives on what we do relative to making Shuttle successful. Contractors do some great, interesting work. NASA does great, interesting work.

One thing that working on the government side versus the contractor side, the government side sometimes lends you to have a better flexibility as far as moving about different career paths. In the contractor, I know some folks that have done similar type things in the contractor, but it seems like it's a little bit harder. They get more focused on a specific technical capability or skill, and they develop that for that person. That's what he is. Then he may go a different path being a manager, but if he doesn't go to the management, he's that skill. That tends to be at least the way I've viewed it.

But I would recommend to anybody that's trying to think of a career path that this is the best job in the country. It ain't the best paying job in the country. Go to work for Exxon if you want to get best paying job, or one of those type of jobs. Or go sell insurance if you want to make more money. But if you want to have more fun, go work in the space program.

I'm reading a book called Angle of Attack [Harrison Storms and the Race to the Moon by Mike Gray], have you read that?

Wright: Yes.

Noah: It's a great book. So just like those guys in the '60s were excited about working on the space program and going to the Moon, I feel the same way even now, just launching Shuttles. I don't care if we're going to the Moon or not. Working in the space business is lots of fun.

Wright: One of the focuses of this project is for best practices and sound processes. Is there anything else you can think of that you'd like to add that you've seen work well? We'll even take some of those things that you've seen that didn't work very well.

Noah: We kind of went through it with ISS [International Space Station] program, and then with Constellation program up—and not everybody in either one of those programs is like this, but you hear folks talk about, "Well, Shuttle's doing it, it must be archaic or wrong. So we're going to do it different over in this next program." The problem is Shuttle didn't invent everything Shuttle does. They had the Mercury program, the processes they put in place. They learned from that. Gemini program, and then people learned from that. Apollo program. Of course, all three of those were going concurrently. But those processes that people were putting in place then were things that they were learning from experience. Shuttle came along, and the same people that did all that stuff did Shuttle. They took the lessons learned and put those processes in Shuttle, and then had to go develop some processes that weren't applicable to those other projects. So they had to invent it.

As Shuttle's invented, the processes that we invented back in the early ‘80s are changed over time, because as we learn lessons from doing those processes, we changed them and refined them. So I would hope that people would take the processes that we have for Shuttle—and they may not be transferrable directly. But they are applicable, and you should take the lessons.

Now, one of the things that we're doing in SE&I [Systems Engineering and Integration] is—I've asked my contractor and my folks that work here in the office—is we're putting together SE&I one-on-one courses. So for each one of our functions, we're putting together a course that's anywhere from two to three days to explain what we do, why we do it, and what products you get. So I'm doing that for each one of our stuff. Then I'm archiving the desk instructions for how to go do that, the nuts and bolts the contractors use in actually going and fulfilling those.

We're talking with Constellation—at least at Marshall, which as part of my ET background, I've got contacts at Marshall Constellation program, because a lot of those folks that used to work ET are over working Constellation. We're talking with them about giving their folks these classes. Like I say, they take the information they get from us and morph it or change it or make it fit, tailor it to fit their needs. So it's just taking our experience and using that to go fit their program. I don't expect them to take it carte blanche and do it exactly the way we did it. But they can at least learn from what we're doing, and then tailor it to fit their needs.

So that's one thing we're doing in this office to make sure that we capture and write down what we do, why we do it, and then we'll go off and do the presentations to the different organizations that ask for it, Constellation being the main customer, to pass those things along.

Wright: Sounds good. Our time's up. But we thank you and appreciate you offering all the information you did today.

Noah: It's my pleasure.

[End of interview]