Johnson Space Center
 PeopleProgramsNewsInfoQuestions
  Search
Return to Johnson Space Center home page Return to Johnson Space Center home page

 

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

John P. Shannon
Interviewed by Rebecca Wright
Houston, Texas – 16 April 2008

Wright: Today is April 16th, 2008. We're at the NASA Johnson Space Center to speak with John Shannon, NASA's Space Shuttle Program Manager. 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 thank you again for spending some time with us this morning for this project. In February of 2008 you were named to your current position. But, if you would this morning, start with how you first came to work at NASA and then to the Space Shuttle Program?

Shannon: I started in December of 1987 as a fresh out. I had co-oped [cooperative education] for a couple different local companies and Rockwell [International Corporation] and Grumman [Aerospace Corporation]. I went into Mission Operations Directorate, and was in MOD for the first 14 years. I was in the Guidance, Navigation and Control Section there, and became a flight director and did ascent and entry flight director [tasks].

So I came in right after [Space Shuttle] Challenger [STS 51-L accident]. It was probably the year before STS-26 flew. I was a little bit involved with some of the work MOD did in the recovery. Then after [Space Shuttle] Columbia [STS-107 accident], I was asked to leave the Flight Director office and go be Frank [T.] Buzzard's deputy interfacing with the Columbia Accident Investigation Board [CAIB]. Then Bill [William W.] Parsons asked me to come over and do Flight Ops [Operations] for the reconstituted [Space] Shuttle Program after Columbia. So major changes of jobs after Shuttle accidents.

Wright: Share with us some of the details about lessons that you've learned dealing with the challenges of going to each of these roles and positions.

Shannon: Not going in the time in Mission Operations Directorate—of course that's a very specialized job in that when you're a flight director or a flight controller, you have to have tremendous knowledge of the systems that are being flown, the procedures of how each crew interacts with each other and the flight control team. It's very mission-focused. It's very different from a program type job, in that it is very insular and you're just accomplishing the mission, and you do whatever it takes.

Coming over to the program was very interesting, because it was in a time of significant turmoil and we were not sure how we were going to get back to Return to Flight. There were a lot of new procedures, a lot of changes to the way things had been done for 20 years. It was very challenging in that we just really didn't have a good idea of how we were going to get there. I think the team that Bill Parsons put together was able to work effectively with the Columbia Accident Investigation Board. We weren't going to fix everything, but we were going to fix enough things that it was going to justify bringing the Shuttle back to flight. We accomplished that.

It was very difficult though, because the problems that caused Columbia were very intractable problems. Because we lost the vehicle and we lost really most of the evidence of what happened early on. Of course it was recreated both from the recovered hardware but also from analysis of flight data, it was recovered what had happened, but we had the Columbia Accident Investigation Board that sat around for four to six weeks without a real good answer on what had exactly happened. So they turned to cultural issues.

They became very interested in some of the cultural aspects of the Space Shuttle Program, which was hard for everybody around here because our culture had been studied by FAA [Federal Aviation Administration] and military organizations and all these high-performing organizations that recognized we had a very good culture, and here the Columbia Accident Investigation Board, because they were not quite as familiar with us and they did not have an accident hardware problem to go work, they worked on these cultural issues, and I think that that set us off to go do some things that maybe were not as important as some of the hardware fixes that we did. So it was very interesting.

Wright: How did you take those experiences and actually gather any lessons that you can apply to what you're doing now?

Shannon: I think out of the Columbia accident, a number of things came through that were very loud and clear. One was there was too much control at the program manager level, and that you had one person for the most part that was responsible for the budget, and of course nothing happens unless there's a budget for it. They were also responsible for the schedule and any technical changes that were made to the vehicle. Most program managers were very adept at handling all three.

But it was very easy, if you had a budget concern, to not do technical things that you might need to go do, or not take the time, expand the schedule out, because you had some pressures from [NASA] Headquarters [Washington, D.C.] or outside agencies or something else to meet a specific schedule. So you had the opportunity to have a very biased technical answer based on cost numbers, because you're trying to meet, as a program manager, a certain cost number and schedule pressures from the outside. So what the CAIB pointed out and what NASA very strongly embraced was if you laid all of those into the same position, that potentially you would have a condition where you would make a poor technical decision based on meeting your cost numbers or meeting your schedule.

Whether that was really the case in Columbia I don't think. I think we had in Columbia a failure of imagination. We'd had this foam release, but we never imagined that it could do what it actually did. Even in flight when we saw it hit the wing, it was a failure of imagination that it could cause the damage that it undoubtedly caused.

So what NASA set up was their governance model, which I like very much. You really have three independent paths. As the Program Manager, I'm responsible for the technical and the safety and the schedule, just like I was before, but I have help. The safety organization was enhanced greatly, and they have their own appeal route if they think I'm doing something that is unsafe or is not appropriate, they can appeal it up the path through Bryan [D.] O'Connor [Chief, Safety and Mission Assurance] at Headquarters.

The same on the technical side. If the engineering team thinks I'm making a mistake or doing something for the wrong reason or doing something unsafe, they have that appeal route through—since the engineering organizations are internal to the Centers—they can go through the Center Director, then up to the Chief Engineer. You can have things arbitrated. If the Program Manager doesn't agree with the safety or engineers, it can be arbitrated all the way up to the [NASA] Administrator level, which was all completely new.

That's happened once since Return to Flight. My goal of course is not to let that happen, to work out at the lower levels the safety needs and the technical needs. We've become a much more effective organization in doing that. One of the places where that really became clear was in the Mission Management Team work. I spent a lot of time reworking how the Mission Management Team would do its business during real-time execution of flights.

We brought a lot of safety guys and a lot of technical guys. We changed the way we talk about things. We really listen to their opinions. We require, whenever people come in with a presentation detailing something technical, if it's been heard before, that [they] bring forward the dissenting opinions that were out there. We hear those dissenting opinions. So, while I'm not sure the CAIB had time or the insight to be able to state exactly what our cultural problems were, it made us internally look very hard at our culture, and we found some areas where we could improve. I think we've been very effective in improving that.

Wright: You mentioned the governance aspect that has been implemented. Would you consider that an improvement for the overall management processes?

Shannon: Very much. Yes, I really do. Now other people will not, because they consider it to be a pain to deal with. They'd like to be the program manager that is all-powerful and can make the decisions and off you go. That's not very healthy. It's good for me to know that I have other folks that can challenge what I do, and it makes me make sure I understand all the diverse opinions out there and try and come to the best decision that I possibly can, and then be able to explain it in a manner that if it is appealed up the path I will be able to explain why I made the decision I made. I don't have a lot of ego, so if I get turned around on something that's fine, as long as everybody heard the discussion and they understand exactly why the decision that was made was made. Again it's more healthy, because it takes a little more time, but you get better decisions. I've seen that over and over and over again.

The other thing it has really benefited is that it makes the safety and the engineering team feel like they have a voice. Before they did not feel like they had a voice. Now they know that by necessity, because this may get appealed up, we have to listen to them and to their opinion and take it into account. Now I would like to think we would do that anyway, but you might not always. When you have the governance model in place that's in place, it makes you do that. So I see it as a huge advantage.

Wright: Are there other examples of improvements for risk mitigation and management processes that have come along since you've been working the last 20 years?

Shannon: There are a lot of smaller ones. One that I think is still in development that can be better, but I think we're much more on the right track, is our overall risk management system. We now track our top risks in the program. What I mean by that is we have each element go through and talk about what their biggest risks are. It's not just technical risk, it's also schedule risks and cost risks and mission success risks, if you're going to meet the manifest or meet the customer's needs or not.

We have a process called SRMA [Safety, Reliability, and Mission Assurance] which ranks them. Then we take a look at our top risks, and we report those up to Headquarters. It's very effective because once a month I review that at my main board, and it keeps in front of everyone what things we need to keep our eyes on, what kind of things we need to continue to work.

Where I think it has some improvement areas is in tying that back to the budget cycle, because I go into a budget discussion about where are we going to spend our resources, and it has to tie back to where your top risks are. Now informally we do that anyway. Say I want to spend some money over here working on this, or doing this engineering test, or in this wind tunnel, or whatever it is, because I know that's a top risk. I might not have known it was a top risk before when I wasn't reviewing them monthly, but I need to be able to tie it back and show that here's where my safety score is on this particular item, here is what I am doing now to the budget cycle, I am spending my money to reduce my major risks in the program. Informally we do that. We're trying to set up a formal process of doing that. When we do that, that'll help me out a lot more.

Wright: When we first sat down you mentioned that you have your experience in the program area, but you have spent 20 years in the midst of the day-to-day operations of flight controlling and flight directing. I'd like to ask you some of the lessons that you've learned in regard to improving, for instance, management performance. You've had such key leadership positions.

Shannon: It's changed a lot in 20 years and it's gone through cycles. But when I came here, the Centers were very insular. It was all internal to a Center. There was not nearly as much working across Centers. That's the nice thing about programs, is I have a strong team not just at Johnson but also at [NASA] Kennedy [Space Center, Florida], Marshall [Space Flight Center, Huntsville, Alabama], and Stennis [Space Center, Mississippi], and a team at MAF [Michoud Assembly Facility, New Orleans, Louisiana], it’s primarily contractors, Huntington Beach. So, if you're in the institution working for the Center, you may be a little bit focused on Center. When you're in the program, you're focused outwards.

It used to be very internal. You hear the fiefdoms and stovepipes and the little catchwords that folks like to use. We've changed over the last 15 years to a much more integrated team that's matrixed. Matrix management came along, and people really doubted it for a while, and horizontal organizational structures and integrated product teams and all that stuff, that was all new in the early '90s. The things that worked stayed. I don't hear TQM [Total Quality Management] much anymore at all, though we all had to go off and take little training classes, and there's been other things like that that have been out there.

But the things that really worked, they stayed, and so what you have now is you have just about every meeting you go to, certainly every program meeting, it's a very matrixed meeting where I have agreements to get support from Engineering, from Safety, from Space and Life Sciences, from the Mission Operations Directorate, Flight Crew Operations. I am not a direct supervisor of them, but they attend and support the meetings. It's a lot different from the way it was 20 years ago when I first came in. It's much more effective.

It's better because it keeps each of the individuals engaged. If they're an engineer, they can go off and work Space Station Program, they can work Shuttle Program, they can work Constellation Program maybe in the same week, do different activities and report back. I was worried at one time about performance measurements and how well we could provide feedback if people were not performing well. All that takes is a little bit of extra work communicating to their managers of the various organizations, who is doing well and where there are some areas of improvement.

Now folks coming in the doors can see it like this is the way it always has been and it works. It's been very beneficial from a manpower standpoint that we don't have to keep everybody inside the Shuttle Program and fence them off and not let them do anything else. It would be a huge challenge right now if I did that, because people would be saying, “What am I going to do in two years?” and walking out the door on me. But as I do more work for Constellation and we're constantly working with ISS [International Space Station], people have a lot of different avenues that they can go into that they're very familiar with. That'll help us all on our retention.

People have different styles [of management]. People are much more sensitive now than they were 20 years ago. We get all the helpful tips and harassing workplace and all those things out there. I think back to a lot of the bosses I had or that I saw and they would never have survived in the environment of today. Now you hope they would have evolved and changed, and of course they learned it from the guys that first came in the door. But it's a much gentler workplace than it used to be.

It used to be you got called on the carpet and they used colorful language. But it was also different, too, because it seems like people back then could yell or discuss or whatever in different meetings, but they'd get over it real quickly too. It was just the way it was. But now it's not quite like that. I don't know if that's a cultural phenomenon or not.

Wright: Maybe history will tell us later. What about program efficiency, some of the lessons that you've learned coming up in those leadership positions that have helped you create a more efficient program?

Shannon: Well, the matrix management is obviously the biggest thing by far. When you talk about efficiency, there's a lot of different paths you can go down. Cost-efficiency and coming to technical solutions or meeting the manifest. There's a lot of different ways you could do it. We're phasing over right now in the Shuttle Program where when we did Return to Flight, money was almost no object, which is really strange for a space program. Engineers get really used to that environment. They really like it. But it was whatever it takes to get the Shuttle back to flying, and there were no bad ideas, and everybody ran off and did everything they could think of.

Now that we've flown nine times since Return to Flight, we're having to back up because we do have cost controls. Some things didn't work as well as you might have hoped that they would work, and you have to back up. So we're going through a transition of leaning out the program quite a bit, from the “spend whatever you need” days of Return to Flight to, “Hey, let's pick the best processes, the best things that we can do to maintain the safety. Let's get rid of the other stuff that was not value-added that maybe took additional workforce, that I could go use for Constellation now or I could go use to speed my processes up.”

That's a change. As you change that culture, especially coming after Columbia, you worry that people are going to think, “Oh, they're backing off all the things they needed to do to make us safe to go Return to Flight.” Of course we're not doing that at all. Matter of fact, I think it makes you more safe if you're concentrating on the things that really add value to the program, as opposed to things that you were just doing because you didn't know what else you were going to go do.

But backing out of anything is very difficult. We always said in the Flight Director Office, once you put a flight rule in the book it's in there forever, because then you have to justify pulling it out and it's a rule, and rules are gospel to flight directors and flight controllers. You can't ever pull anything out. Well, it's the same way with the program. You have to be very careful that when you make a change you understand the full impacts of that change. Cost, schedule, processing time.

That's a difficult thing now as well, is some of the changes we made like to the external tank, they were made as good ideas to reduce debris, whether you needed to reduce the foam debris coming off the tank or not in that specific area. If it was a change that would reduce debris, it was automatically assumed to be good and was put out there. When we found out that we're late on some tank deliveries, and when you try to find out why are you late on tank deliveries—I went out to the plant. One of the changes that was in an area that was not a risk to us, had never shed foam before, but some folks in Marshall engineering thought it was a good idea to go and rework it. They took an hour-and-a-half process and changed it into a 55-day process. We had another area that didn't really shed foam, they took it and it delayed the tank by about a year because they were reworking how they did it.

So the danger was when you were in an environment like Return to Flight, where all answers are good answers, because we didn't know how we were really going to get back to flight, making decisions that sound good but you don't understand the full scope. You don't understand how this is going to affect processing time. It doesn't do me any good to have wonderful tanks that are delivered in 2011 when I'm not allowed to go fly them anymore. That's where we were headed. We did not understand cost impact, we did not understand schedule impact, and we just looked at the technical side, so we got overbiased in one area. It made us a very inefficient program, because it wasn't value-added, and it was because we didn't understand the full scope. So what did I learn out of that?

What I learned is you have to keep asking questions. That even if it looks like a good idea, you have to understand the full scope of any change you make before you change it. Drives people crazy. It's obviously the right thing to do. Just make the decision and move on. That's very rarely true. There are very rarely any free decisions. You're going to hit budget, you're going to hit some other technical piece of it, you're going to have some rework because you changed the mold line in the vehicle and the aerodynamics change, so you got to go recertify a bunch of stuff.

It might impact how the Orbiter was certified. Or it just might impact how quickly you can get a tank out the door. So I'm going to have a six-month time period where I can't go fly a Shuttle flight, because I don't have any tanks coming to the Kennedy Space Center. It's all because we made changes back in '04 that are just now, the engineering is coming up there. And nobody asked in '04 when we were trying to recover, “Well, how long will this make the get-the-tank-out-the-door cycle?” There was no appreciation for that at all.

Because at that time nobody thought we would be out of tanks. Matter of fact, we slowed down production on tanks at that time, because we didn't have anywhere to store them. We filled up the VAB [Vehicle Assembly Building]. We've flown all those. They're all gone. And I have one tank in the program right now that's being mated up as we speak. The next tank is not coming out the door for four more months. So I've got an issue. I inherited all this stuff, so it's going to be interesting to see where it comes out.

Wright: That leads into the next topic of lessons learned about planning.

Shannon: Yes, we're going through a significant planning cycle right now. It's a change cycle, because the Shuttle Program and the manpower associated with the Shuttle Program is going to be an integral part of flying the next set of vehicles that we go fly. So we're trying to change this organization that is very process-oriented, that has known how to do their job for 30 years really, it's been about 30 years, into a very lean organization that is very flexible, that can go do flight tests on unmanned vehicles. Huge change in culture. It can help us out because you take different risks, you make different technical decisions based on flying a different type of vehicle and flying it manned or unmanned.

How do you do that? Well, the other thing I've got is retention issues. How do I get everybody to stay in the program until we fly our last flight? Especially if they think after our last flight they're going to get a pink slip. Those two go together, and it's all about planning, it's all about how do I define what the organization is going to look like, how do I define the individual transition plan for each person that's out there and make sure that they know what their job is going to be, if there is one in 2010, and what they'll be doing for Constellation, and then engage them early, get them started early.

So it takes all the angst out of the process, they know where they're going to go, they know what they're going to do. If they're not in a critical job for the next program, we define, “Hey, we need you to stay until this time, and then this is going to be your job when you get out,” or we say, “Hey, we're not going to have something for you, you need to go find something at this time, if you can stay till this time we'll give you this much retention and try to keep you around that way.” It's a huge amount of work, because they're all very detailed personal plans for each person. There's no other way to do it though. You have to go through, and you have to make that decision. To do that you have to come up with the basic organization you're going to need three years, four years down the road, and then map from this organization to the next organization. Talk about planning, it is a huge, huge task. We're right in the middle of it right now.

Wright: Underlining most of what work is done with the Shuttle is always that aspect of risk. So there's the risk assessment, risk management, risk mitigation. Can you give us some lessons and some best practices that you've learned from dealing with all that element of risk? Especially these last five or six years?

Shannon: This will sound weird. I think we overmanage risk in the Shuttle Program, which is probably a mouthful to say. We home in on certain areas, and I always say we're fighting the last battle. We home in so much on foam and impacts to the vehicles. We've flown nine flights since Return to Flight. We've had no significant issues at all. Matter of fact, it's been wonderful performance. But we can't let it go.

What I worry about is that we're so focused on the one area, and we have so much being spent both intellectually and financially on an area, that we pretty much have taken care of that we're missing something else. The vehicle is incredibly complicated, no escape system, you’ve got to get it right. So you try to keep the team focused on all the areas out there. There's a great little commercial that's been out there. I don't know if you've seen the two basketball teams, and you're supposed to follow the white team passing the ball and count how many times, and you do that. But in the middle of it a bear comes in and starts moonwalking, and you never see it because you're counting how many times this team passes. I showed it to my team last time we all got together, and it's a great analogy. We're so focused on the one task that we see in front of us, you totally miss this other thing that comes out of nowhere and is obvious. And if you had an accident you'd go back and you'd say, “How in the hell did you miss the moonwalking bear?” It's right there, it's right in the middle of the screen, but you're too busy over here looking at how many times the white team is passing the ball back and forth. It's actually a commercial to watch out for motorcyclists. You don't see what you're not looking for.

It's a great analogy, and that's what I worry about on risk. I think the SRMA system we set up that goes and identifies top risks, it makes people think a little bit outside of what the primary focus has been lately. As new problems crop up on a flight, we're very judicious in making sure that we document those in SRMA and we talk about the what-ifs so we don't have the failure of imagination.

But a lot of that is judgment stuff and where do you spend your money, and again that goes right back to I need to be able to tie my risk management system back to my budget cycle so I can spend the money in the right spots.

Wright: When you first got here, you mentioned it was right after Challenger, and you were starting to learn and be part of the flight controller system, and of course since then you've learned a lot on the job training, and I'm sure had some formal training along the lines. Are there some lessons or some specific types of training that you learned along the way, or maybe something that was instilled in you by someone who was here during that time, that you feel is something that you use every day or you use as part of what you do to determine what your style of management will be?

Shannon: I think working in MOD you really learn to work the details and look at it from a broad systems engineering standpoint. That was great training. I had some incredible mentors there that provided just the way you went about it. In MOD, they simulate two, three times a week. For launches and entries, you do it more than that. So it's like a test every day when you go to work. You go sit on console, and based on your systems knowledge and your knowledge of the flight rules and your knowledge of the conditions of the day, you have to make decisions. Then you debrief. You talk about what decision you made, and how good or bad it was, and were you listening, and did you communicate with the right people that were out there.

That's wonderful training. As a matter of fact, to the Mission Management Team, we brought the concept of debriefs to that team, which was very uncomfortable for everybody when we first started out. Coming from the flight control background, it did not bother me at all. I went first since I was chairing the team, and I totally bared my soul and said all the stupid things I'd done and that I would never do them again, and here's how I got into it. And one by one the engineering guys that had never done that before opened up, and they liked the concept. So we've added debriefing, even on major meeting stuff, to our repertoire of things that we go and do.

Knowing that, ops folks then are trained to take information in, even if it's a limited dataset, and make a decision and move on. Engineering folks are not trained that way. They're trained in a manner that is very different, where you go collect all the data you can, all the data, you spend the money, you take the time, you analyze that data, you benchmark other areas, have the huge complete set, you talk about it for a while, and then you come to a decision maybe at some point. Very different culture. Ops guys get frustrated with engineering guys, engineering guys get frustrated with ops guys.

We talk about diversity around here. Diversity is not gender, it's not race, it's between ops guys and engineering guys, that's our biggest cultural battles that we have. Of course [N.] Wayne [Hale] was an ops guy. Parsons was an ops guy. I'm an ops guy. Drives the engineering guys crazy. Steve [Stephen J.] Altemus even, the head of engineering, is an ops guy. So what do you do? You have to adapt your style of management to embrace the engineering guys. You can't say, “Okay guys, here's the data, here's the obvious solution, boom, we're going to go do it, see you later, meeting's over,” because we would exercise the governance model quite a lot if we did that.

So what you do is you talk around the problem. You have huge patience. You talk about all aspects. You make sure you gathered as much data as you possibly can. You talk about different options. It's a much more full process. The ops guys are pulling their hair out and lying on the floor going crazy because they obviously see the answer. It's not always the answer we end up with either. But it's very different.

The other one is engineering folks tend to need a little more time, and so the way we do that is we have premeetings, we have many more premeetings than I would normally think we ought to have. You can't just bring it to one board and make a decision and go. We have a premeeting where the engineering team gets to lay out all the things they think about and all the stuff they're worried about. You have to pick the managers for those meetings very adeptly, make sure the right person's in there that will listen to them, that will hear all of it, that will document dissenting opinions, that will work through all the data. Then when you get to the big meeting, the engineering guys feel like their concerns have been heard, you don't have to do the big circle around the problem because they've already done that, and you can more directly go to the heart of the problem and work it.

But it's a very different culture than the ops guys. That's a real significant issue. I can disenfranchise a huge number of people if I get into a meeting and make a decision in two or three minutes. Then they dig in their heels, and it becomes very difficult to get team consensus at that point. It's very, very difficult, because they feel like, “Well, you're not listening to me and how hard it is.”

I did have a little bit of formal training and went off to Harvard Business School for three months, and anybody who's a senior manager, if they have the opportunity to go do that, ought to go do that, because you go through business cases, it's in the business school, do three a day, two on Saturdays, you take a huge amount of time to prepare. You learn so much. You talk about things you would never talk about in the government, and with international partners. So I was probably more influenced in management style just by doing that fellowship than any other thing at NASA.

It completely changed the way I looked at how I treated organizations and people and how you arrive at solutions to problems. I still call those guys probably once a month. I'll call one of the old professors there and talk to them about certain issues, and they're always extremely helpful. So as senior managers get into their positions, if they can have an opportunity to do something like that and then touch back with those folks every now and then to talk about the issues of the day. And they love it. If I call these guys they're so excited, because they get to help the Space Shuttle Program, figure out what we're going to do. A couple of them have gone down and seen launches. They're so excited about it, and they give you good information. You can't believe the vast amount of experience these folks have of course that I don't have. I haven't been here that long. I haven't faced that many outside-the-federal-government kind of problems. They have. So finding those people on the outside that you can trust that are good touchstones whenever you're facing a problem, it's hugely helpful. It's extremely beneficial.

Wright: Sounds like good solid training, which easily leads me into my next question. How would you recommend to best train and equip the next generation of space agency employees that will be working with you for the next 20 years?

Shannon: Well, we're going through a new time, and it's pretty exciting. Because the focus is on design, development, test, and evaluation. The DDT&E function. Now you're coming into a sustaining engineering role for people that were here 25 years ago, they developed the vehicle, and now you're just watching over it and sustaining it, maybe upgrading it a little bit. This is a whole new rocket family that we're developing.

So the skills are going to be different, and you have to get a little bit more away from the ops, which is more of the sustaining role, and more to the engineering. We have to have two things. It's a huge amount of discipline to work the details and make the appropriate decisions, but also decisions have to be made, and the guys that are coming in the door, they have to be extremely technically competent, they have to understand the systems, they have to talk to other people, get the lessons learned from other programs, talk to their counterparts at Marshall, talk to their contractor counterparts, make sure they fully understand the problem, and then make a decision and move forward.

That's something we haven't had to do for quite a while, so it's going to be interesting to see how this plays out. Working the details, making decisions and sticking with them, and realizing that if you made a dumb decision you can come back in the next day and say, “That was a dumb decision, I need to change that.” That's okay, and there shouldn't be any punishment or any retribution for that kind of stuff. But it's going to be an exciting time. We've got a lot of work to do over the next several years.

They've talked about people losing jobs and it's ridiculous, because our budget is actually going up, and budget is directly correlated to jobs. When people talk about those jobs, it's the Shuttle jobs going away, but they never tell the other side of the story of the Constellation jobs that are coming forward, and the unallocated $1.2 billion worth of assets out there that are going to hire people. So it's an interesting environment.

Wright: It is, and you mentioned earlier about the diversity within the different types and groups. How do you teach the lessons that you talked about, or those processes to that many different kinds of people so you don't lose these lessons learned?

Shannon: That's a good question. I did not appreciate the split between ops and engineering, and I don't think many people did, until maybe post-Columbia. I think it really pushed that out into a forward position. How we talk about that, how we engage the team on that, I don't know. I don't know that we've actually thought about how to do that other than we talk about it every time we get together. But that is our biggest cultural issue in my opinion. It's not any of the other classical things. It's the people that were brought up as operators and people that were brought up as true engineers doing design work, how they work together.

Wright: What do you think was the hardest lesson that you had to learn in the last 20 years?

Shannon: Probably the best lesson I think is that you have to trust the people that you're working with, and you have to let them know that you trust them. But along with that goes when you say something, you have to make sure they know they can trust you by following up and doing what you said you would do. If you don't have that trust, then just the whole process breaks down. I'll tell you right now in the program there's some people that provide dates when they're going to have different pieces of hardware available that I don't trust, because I think they either pad their schedule to make themselves look better, or they're afraid that they're going to be negatively graded so they give you a fictitious schedule, and then later on after a grading period they'll update it with something that is more realistic. That's so difficult to manage.

It's been said a couple times, NASA's an all-volunteer organization. We may look like the military but we're not. Since it's all-volunteer, you have a lot of extremely smart people who for the most part could probably go make more money outside. So you have an all-volunteer organization who if they quit or were fired would go make more money and be more financially successful anyway. That's a very difficult group to manage. The one thing that keeps people here is the mission. You don't get to do this anywhere else.

I think that's key to understanding that people want to be here. There are other things they could do outside and be more financially successful, but not get the job satisfaction. So you have to make sure also that you're providing that job satisfaction to them. You're making sure they have the opportunity to grow and learn and be a big part of the mission. We spend a lot of time doing that as well, making sure that people feel like they're appreciated for what they do. But again it all goes back to the trust piece. You have to be able to trust the team. As program manager, I am completely at the mercy of all the guys that are turning the wrenches and doing the Michelangelo-like sculptures on the foam to make sure that it doesn't liberate and that they did their job appropriately. I can't go check all that stuff. You need to go and trust them.

Wright: Well, let me offer this question as a final one. What advice would you share with someone joining the program?

Shannon: The Shuttle Program, or just NASA in general?

Wright: Maybe both. The Shuttle Program and NASA.

Shannon: Well, the Shuttle Program, we are at a pretty stiff pace right now. We're trying to finish up. We're trying to make sure we support Station as best we can. I would strongly encourage, and I am encouraging my senior leadership. We have probably the most difficult task we've had in a long time right now, because we have to fly it out, we have to fly it out safely. If we splash a Shuttle, the next program's in huge jeopardy and NASA as a whole is in huge jeopardy. So we have to pay attention. But I also firmly believe that in the Shuttle Program, we have a unique set of skills on people that are able to design, develop, assemble, flight test, launch, operate spacecraft.

That workforce really doesn't exist anywhere else. So the Shuttle Program has to get involved in the next program so we don't have this big gap between flight programs. We can pull them back on the schedule to the left a little bit by engaging our workforce. So we want to do both. We want to be extremely vigilant, do smart things, accomplish a more significant manifest flightwise, we're going to fly more flights in the next two years than we have in the last three, meanwhile we're engaging the next program.

I was just out at Stennis Space Center for the first flight test review. It's a year away for the next program. So we have to engage that workforce into that as well. That solves my retention problems. Because everybody that's here because they like to go fly rockets in space, they're really excited about it. We're doing our favorite thing, flying the Shuttle, but we're also doing the next program kind of work as well. So you have to be very flexible, and you have to go outside your comfort zone a little bit, because there's a lot of things that we do in the Shuttle that are not going to be applicable to the next program. It's a very well-defined program. The next program is not at all. We have to help make it that way.

Coming into NASA, I almost wish I was coming in as a new hire right now because the Station's almost complete, we've got all our partners heavily engaged. The Japanese, part of their lab is up, more is going to go up. The Automated Transfer Vehicle by the Europeans is up. The Russians are still doing their thing. We're flying out the last part of Shuttle. We've got HST [Hubble Space Telescope] coming along, our last servicing mission to Hubble. So it's going to be an incredible year next year as well.

But also you've got this great new program where we're going to go back to the Moon and we've got that in our capability to do, and we either do it or we don't, it's completely up to us. So it's an incredibly exciting time. When I used to do tours as a flight director, I used to tell all the congresspeople and staffers and senators and things that would come, I'd say, “I love the Shuttle; I'd trade it all in a heartbeat for an exploration program.” Voila, here we go. So it's going to be an exciting time.

Wright: We look forward to it and learning more about how you do what you do during the next 20 years.

Shannon: I'll still be here. So we'll do it in 20 years. That'll be good.

Wright: Well, that's good news. Anything else you want to add?

Shannon: I appreciate you doing this. This is valuable. It's good stuff.

Wright: Well, thank you. We appreciate it.

[End of interview]

Return to JSC Oral History Website

Go to NASA home Go to JSC home

Curator: JSC Web Team | Responsible NASA Official: Lynnette Madison | Updated 7/16/2010
Privacy Policy and Important Notices

Information JSC History Portal