NASA Shuttle-Mir Oral History Project
Edited Oral History Transcript

Jeffrey A. Cardenas
Interviewed by Rebecca Wright
Houston, Texas – 24 April 1998

Wright: I am speaking with Jeff Cardenas. [Interviewers are Rebecca Wright and Paul Rollins.] Jeff, could you start by telling us what you're currently doing with the Shuttle-Mir project.

Cardenas: My current responsibilities are co-chairman of Working Group 6, which is the Mir Operations and Integration Working Group. That's an additional duty I just picked up. It had been Rick Nygren up until the last month or so. My job before that was within Working Group 6, I was the Operations and Training IPT [Integrated Product Team] leader.

Wright: When we visited yesterday or day before on the phone, you suggested we come visit with you so we could kind of map out how all the Ops teams worked. So we're going to let you take it from here and proceed however you want.

Cardenas: I don't know how much you know about Phase 1 from a in the Working Group stand point.

Wright: Why don't you just take us back. Pretend we don't know anything.

Cardenas: Okay.

Wright: Have you ever had to do this before [give an overview], lecture people who are curious about this [process]?

Cardenas: Yes.

Wright: Was that captured on anything?

Cardenas: Not recently. Usually what's happened is because we've had a lot of people from CB [Astronaut Office - Johnson Space Center], from the office, transfer in and out, and because sometimes we've had to interface with them a lot and be the continuity across the increments, I'd had to go through this several times with several crew members.

The Phase 1 Program, under Frank Culbertson, the organization within that, within that he's got the different Working Groups. Let me see if I remember these. Working Group 1 is PAO [Public Affairs Office]. Working Group 2 is Safety; this is Gary Johnson. Do you have the names of all the Working Group chairs?

Wright: Yes, we do have that list, unless there's been some recent change.

Cardenas: I don't believe so. This is Debbie Rahn at NASA Headquarters. Working Group 3, I think officially it's Bob Castle, but you've got people like Bob Castle, Bill Reeves, Phil Engelauf, and Paul Dye -- all within that flight directors. This is actually what's called Flight Ops and System Integration, so actually you've got Bob Castle and Greg Lange or George Sandars, and now it's Bobby Brown, I think, who does some of the Hardware Integration.

Working Group 4, which is Mission Science, is John Uri. Before that it had been Nitza Cintron; John Rummel before then; I think Carolyn Huntoon before that.

Working Group 5. Was it Crew Exchange and Training? That's Charlie Brown, Tommy Capps. I'm going to come to [Working Group] 6 last. Working Group 7, which is EVA Working Group, that's Richard Fullerton. I think he's always had it. Working Group 8, which is Med Ops, the Flight Surgeon is Roger Billica and Sam Poole.

Working Group 9, which is JICR, which is Joint Institutional Communications Requirements, and that was originally set up by Gary Coen. I don't think it actually had a Working Group number when they started it. But Gary Cohen, and now it's Dan Jacobs.

Then, last, Working Group 6, MOIWG, Mir Operations and Integration Working Group, and that was originally Rick Nygren, Charlie Stegemoeller I don't know if you have that name or not. Charlie moved on. Rick's moved up. So that leaves me. The reason I was Ops and Training, the other fellow is Don Schmalholz, who does integration, hardware integration on that. There were some other fellows in here when we first started on some other things, but they've since moved on.

The way the Working Group 6 got started is when we originally did Mir 18, the Phase 1A stuff with Norm [Norman E.] Thagard, if you look at this, this would seem to cover everything, so you've got Working Group 3 and Working Group 4. Working Group 4 defined the science requirements for all of the Phase 1A, so both for the Mir aspect and the Shuttle aspect. Then when it came to implementation, these guys [Working Group 3] were only responsible for the implementation on the Shuttle. No one was responsible for implementation on the Mir. Leave that as it may, because I said, "Who's responsible for operations?"

They said, "Working Group 3."

I said, "Who's responsible for science?"

And they said, "Working Group 4."

I said, "Now, who's responsible for science operations?"

"Uh, no one."

So originally it was a part of Working Group 4, but because it became so big --these are the requirements -- and then you had another forum for implementation. That's where Working Group 6 came from. So this actually started late in the flow of development, so originally a lot of the stuff originally was assigned to work through some of the Working Group 4 stuff for the operations.

Within the MOIWG, it's kind of split up in an AIT [Analytical Integration Team] level with IPTs under it. This IPT is assigned mission management; that's a little bit of a misnomer. What this is, is more in the traditional Shuttle mission management role where you actually support payload complement on a Shuttle flight. So these guys don't really have a role during the long duration phases; it's only interfacing during the Shuttle aspects of it.

You have integration, which is basically the hardware development and processing, so pre-mission. You have operations, which is all the mission preparation activities, timelines, documentation, procedures, and then the real-time mission execution, all the post-flight assessments, things like that, reporting. And you have training.

Wright: IPT stands for?

Cardenas: Integrated Product Team. This is Analytical Integration Team, AIT. Those were the buzzwords at the time when this was set up.

Training was the last one. Originally this dealt with both flight crew, so training of the crew members, as well as the ground control and support personnel. What we did is move this over into here, because most of these people work for operations. So we moved that over there [Operations IPT].

Now, keep in mind when we did Mir 18 we did not have a lot of this in place, so this was really more going into Phase 1B, so ramping up to that. So you just put together little tiger teams to go off and do this. So it was kind of an evolution over that period.

In May of '95 -let me see. I'm trying to remember. I started working this in late '93. Thagard's flight was '95, so Shannon went up in '96. Around springtime of '95 [actually ’96], we decided to put these two together, so that's kind of how I inherited it. So it combined the two, so that's why I said operations and training lead on these two.

The integration guy was originally some other guy. I'll write the other names, too. His name is Don Schmalholz. The other guy is Dick Meyer. These are all integration guys. Gary Kitmacher. So those guys have filled in the role of integration. Mission management is Mike Hendrix and Karen Morrison. So that's how it flows.

This was the structure on the NASA side, and we have counterparts on the Lockheed-Martin side, who's the prime contractor on that. So across the board for the most part you have Lockheed-Martin. I forget the full name now. I just say Lockheed-Martin Engineering & Science. I forget what the full name is.

We also had some Krug [contractor] support, because when we did Mir 18, Krug supported not only the development of a lot of the science, but also some of the early science training, so we kept them on to support some of the training aspects out at Star City in Moscow. So there was a small Krug content on that. It's also Lockheed-Martin, but it's a different component. This was from the old Martin Marietta supporting that, and this was the actual Lockheed-Martin, and now they're all Lockheed-Martin, [referring to Mission Management] but they're two different schedules, two different parts of the contract. So this is a different house. This is under Gloria Salinas. She's the project manager. And this one is Robert Moeller.

Wright: Robert Moeller did Mission Management?

Cardenas: He supports this wing, so Robert Moeller's the Lockheed guy on that, and all the rest of this is under Gloria Salinas.

The is the structure we did and we had it kind of broken down by functions, by functional areas. In addition, we weren't very deep on the civil servants, so because we do not have the traditional team leads, enough bodies to do team leads for each individual increment, we got some more resources from MOD [Mission Operations Directorate] in here, so for each increment, we established like an Ops Director, an Ops Leads. The title was Ops Lead, because "Flight Director" on that, they objected to us using that term. So we just call them Ops Leads.

For NASA 1, for the first one for Thagard, I was the Ops Lead for that, but for NASA 2 through 7 we've had -let's see: that's three from MOD, one transferred from YA into MOD, and then the other was a Marshall [Space Flight Center] person. So I can give you all those names if you need them.

Basically what we did is when we set up the structure, Lockheed came back and said, "Okay. We're going to create increment teams." We had counterparts on this, in these functional areas, but then they also created increment teams across that, experiment teams. That's what I'll lay out. So you have a little bit of a matrix on that.

So you have within Lockheed-Martin operations, training, integration, and then across the top you had each increment. Here's increment 2, 3, 4, 5, 6, and 7. So, for example, for each of these they would create a lead for each increment, and then under that you had people assigned from what was the Ops group, assigned to do that, so you would have an Ops for that increment, a training lead for that increment, and you still had supervisors here. So what we did is, what we really wanted to do is actually create -let me back this up. What they did is actually created three teams on this, so what you did is end up repeating it. So the guy -to try to build on the experience, because you can't create five teams at the same time or six teams, rather, at the same time to do that, because we didn't have the budget or the resources. They did it and they just rotated them back around through.

So the guy who is working 3 is working 7. The team that did 4 left, so we had to use new teams for 5 and 6. I think that's how it came out. Two is actually -he did back to back on that, so he's probably got the most experience, and that's the one that we have right now. And that is basically the way the team staggered.

As the lead, he may not always be working with the same people, depending on who's available. People come and go through attrition. So you had these team leads in these areas to make sure all the schedules were met, to make sure all the hardware deliveries, all the training schedules, everything was made on that. Within that, he was assigned complements of teams within operations.

What we found in trying to structure it as far as the rotations within operations, we were trying to come up with two complete teams. When I say complete teams, it consists of an engineer, an operations support person, a data and communications engineer. This is like a payloads system engineer, what they call that. Data and communications, mission science representative. Also assigned to us was a biomedical engineer and a flight surgeon. Then you had remote PIs [Principal Investigators].

The things that we contracted Lockheed to provide were these four positions. If you notice, this mission science is the same as the mission science that we had from John Uri. And each one of these positions is three-deep. So you've got three of all of these. So what we wanted to do is come up with two complete teams, so you're talking about 24 people, and what they would do is, to give them time off, one group would work the odds, the other would work the evens, just to break them up randomly. But we weren't that deep to do that, to come up with two complete teams. The budget wouldn't support it, because we're under-budgeted.

So in some cases, for example, we had the same three engineers who work all the missions; same with the Ops support, same three. We work all three. Data and communications engineers, again we didn't have the budget to even provide the three, so we had two who worked all the time. We didn't even have the budget to send them over to Russia. Mission science -he didn't split them up by three. I think he's actually got five, but they work every mission, but within it they have leads for each one. So when you talk to John Uri, he can give you a breakdown on that.

In addition, we do have what's called discipline within the operations group. We have discipline leads, and they're responsible for doing the operations requirements documentation. In some cases these guys are also operations support, but they do all the preliminary documentation to establish what the operational requirements are driving the timelines, driving the flight procedures, the execution plans, things like that. So there are five of these guys, and they, again, end up supporting every increment. They're based on the science discipline, so one for human life sciences, one for microgravity, one for ISS RME [International Space Station Risk Mitigation Experiments]. At one time there were more advanced technology experiments. Now they've been lumped in with microgravity. So you have another one for advanced technology.

Actually, there were seven originally. HLS [human life sciences], microgravity, fundamental biology, which is out of Ames [Research Center], advanced technology, ISS RME. You had Earth Ops. You had Space Science. Seven. Advanced technology has gone into microgravity now. This also includes Space Medicine.

Wright: What is the ISS RME?

Cardenas: ISS is International Space Station Risk Mitigation Experiments. It originally was a part of -I'm not sure what it originally was part of, but now it's part of OZ, within Mike Suffradini’s group, and Rod Lofton is the leader. What they were doing is taking experiments or concepts, proof of concepts of ideas on station, making them like an experiment, and then putting them on board to test certain concepts and things like that. But the problem is these weren't coming in as mission science experiments through the Working Group 4. These things go directly, kind of bypass some of the gates, so it's a little bit awkward trying to understand, keep track of this after it's already been scheduled on a timeline. Same thing with some of the space medicine plans.

But anyway, these guys end up working all the missions, so if you look at who is actually assigned to a mission or assigned to go to Russia, we try to look at the functions we had to provide the things that needed to be taken care of in Russia, and then this was the first pool that we went to. If for whatever reason these guys weren't available, then we went to the discipline to see who we could send. Then the next fallback was anyone from the increment team. Because these guys had done all the mission preparation, and once the mission started, these guys worked in the facility here in the States and these guys worked in the facility in Russia. So, in the States the facility is Payload Operations Support Area [POSA]. In Russia their acronym for MCC [Mission Control Center] is TsUP, so we'll use that term a lot so they can understand what we're talking about.

Then within that it's Mir Operations Support Team [MOST]. We use this acronym because before we started with Thagard's flight we spent about a year and a half talking to people who had flown with the Russians, who had done business in this area, in operations and training, operations primarily, because that's what I was responsible for -how do you set up things with the Russians? How is their Control Center? Because we didn't want to come in with a Shuttle mind-frame, or even a Spacelab, to a degree. So we tried to play kind of dumb and just build on that, asking the same questions and looking at the same jobs that had to be done on Shuttle or on Spacelab, how do those migrate to a Mir environment? So we spent about a year and a half talking to the Europeans, we talked to the Austrians, to the Germans, to the French, to ESA [European Space Agency]. We didn't talk to any of the Japanese or, of course, Eastern Europeans at the time.

But basically, based on that, we tried to follow their structure for some of this stuff about having this support team over there, having flight surgeons, having the traditional CAPCOM [Capsule Communicator]. We had to provide the CAPCOM function out of there, because normally the Europeans were using the backup. What they do is in the Russian system you have a prime and a backup to train [flight crews]. So whoever wasn't chosen as the prime is the backup. He was actually the CAPCOM on the ground during the mission [in the European system]. American astronauts were not interested in doing that function. So Norm Thagard's backup we could not utilize as a CAPCOM.

In the European system they also use the flight surgeon, because they were with them through all the training, they were an integral part of this team. Our flight surgeons weren't interested in that function, so we had to use the Ops Lead, basically the NASA manager for this team over in Moscow. So he also had to serve as a CAPCOM. So there are limitations to how much we could copy from the Europeans, so the Russians got used to seeing the same structure on that, so they understood how we did business.

He is backed up, though. Originally we only had one person over there for NASA 2. For NASA 1 and for NASA 2, we went to actually two leads because of the sheer workload over there. He's got to work fifty, sixty hours a week, so we have a backup and they also serve as CAPCOM. Then also occasionally we do use the flight surgeon. The flight surgeon does talk to the crew member, but that's about medical issues, but he is available to provide that. So we've kind of been able to get over there. Then also any of these people in whom we have confidence, because actually what we found is they do like some variety in who you talk to. Provided the person on the ground knows what they're talking about, they do like variety, talking to different people about different things.

So that's kind of, in a nutshell, how this is split out. With regards to the training group over there, we actually had training coordinators both in the States and in Russia, and they had schedulers, documentation experts, a team of about seven or eight people here and a team of about two or three in Russia. Basically they were assigned long-term in Russia. As I mentioned, we had a training coordinator and kind of a scheduler in Russia, and then there was also support by a hardware engineer, but that was half time.

Over here you had kind of the same thing -training coordinator, scheduler, again a hardware engineer. You had a documentation. You actually had a manager on this side. Actually, in some cases you actually had two schedulers, because you're preparing for two increments at a time. Sometimes you would have two coordinators, depending on what was going on on some of this stuff. From this pool is where this person would come from, so also they were pulling double duty in that case. So usually it was the scheduler on that. So some of the job kind of evolved.

So I guess based on our phone discussions, what you're looking for is this, or are you looking for all these names?

Wright: It's like a can of worms. I was looking for that, but then now you've spelled it all out.

Cardenas: The function of this [MOST] is to interface with the crew member and to interface with the Russians. The function of the team back in the States is overall management of the increment. So these guys have to make sure that the requirements are documented correctly and that the right products are put in place for these guys to go off and work. So these guys are only as good as the product that these guys turn out. So if he's given garbage, you know, he's go to call people in the middle of the night, and that's what we were trying to get away from. Take all that overhead off, because it's hard enough. The cultural and language problems with the Russians, as well as talking to the crew member, take all that overhead and let them work it back here, because these are the guys who did it pre-mission, pulling that together.

We try to encourage as much of a relationship between this lead per increment and the NASA operations lead, although a lot of times this guy [Increment Lead] actually was more knowledgeable than this guy [NASA Ops Lead], because this guy also had to support the training sessions and build a rapport with the crew member pre-mission. So just talking about odds and ends, whatever, so he didn't always know the background on something, what was going on during the integration flow. I mean, we're really stretched to the limit on this as far as bodies. I think we're about 30 or 40 percent under budget.

I asked one of the guys from MOD to do an independent assessment. If we're looking at all the functions -I didn't have these out -I said, "These are all the functions we've got to cover. How many people do you think it would take?" His estimate was about 30 or 40 percent higher than what we had.

Wright: How many people does this involve per mission?

Cardenas: Per mission?

Wright: You were talking about how they overlap and some continue on and some are on every mission.

Cardenas: Our operations staffing was around -I'm trying to remember if it was loaded or not. I think it was a little under thirty, so we had thirty people to do all this on the contractor's side. Then we had about two or three civil servants, myself. I kind of had a part-time deputy, but that didn't always work out. Under ten to do the training between Lockheed and Krug. So, overall, this whole thing was a little under fifty people.

On any one increment, then, you would have -now, this would go that once the mission was launched, he would just jump to the next mission. So he didn't have a role during the mission execution phase. So do you want to look at while the mission is running or preparing for the mission?

Wright: Let's do one, then the other.

Cardenas: Okay. Pre-mission, you'd have one, two, three, four. He'd have these guys assigned, but these guys were working double duty. So if you're just looking at heads, if you're trying to do a budget thing -

Wright: Do you want to help us out so we don't have to come back and ask you again? When you say "this" and point -

Cardenas: I'm sorry. Okay.

Wright: It won't get on the recorder.

Cardenas: Sure. From the increment team you would have four. You probably have about three heads out of the discipline lead that you could support. Maybe one or two out of here.

Wright: "Out of here" which means?

Cardenas: The operations team supporting it. So I imagine around ten or eleven. From an operations perspective, let me go back and double check. Let me actually bump that more to fifteen, because you wouldn't have what they called -they also had the term "payload systems engineers" out of the integration supporting the hardware development. So, pre-mission, you'd have about fifteen people. Once the mission got started, that would drop to around ten, doing the actual day-to-day mission operations. Now, if something comes up, you could pull in more resources, someone who was working something downstream. You could free up and double bookkeep. So that made it very interesting, looking at monthly charges, what they're charging against, stuff like that, because sometimes it was splitting hairs. Three hours he had to do one thing, the rest of the day he was covering something else.

My personal feeling is, some of the plans to do station, a little bit overkill, where you've got six or seven teams, plus one in training, accounting for other stuff, but this is the other extreme, though.

Wright: You proved it could be done with less people.

Cardenas: Yeah. Now, keep in mind, some of the requirements we had, this was going on early, starting when we had the problems on Mir, we started adding. We've added some more bodies to that. So on top of that, what we've added to this, originally to do the timelining and the planning was supposed to be a function of this guy over here. Once he got over there, he had so much overhead, what we've added to this is called the timeline engineer, and there are three of those. So starting with NASA 5, we just did some testbedding, but for NASA 6 and 7, we added a timeline engineer. Normally what we did is within this group he had an Ops Lead. That Ops Lead was responsible for doing the timeline engineering. So for NASA 5, this Ops person went to Russia to start it off on, so they counted in that mix. So if you take that figure of ten, we'll bump it up one to eleven for the timeline engineer.

We also added what's called a Mir systems engineer, because of the problems they had on Mir, to follow the actual -that was not our original responsibility, to track what's going on in the Mir systems, because we were following the payload systems from the U.S. side. So they've added MOD people, Mir systems engineer. Those are three people. Again, that was starting with NASA 5, so that moves it up to twelve. So at any one time you're looking at twelve people on console or directly responsible for what happens that day.

Now, they rotate those between the rotations to Russia, nominally anywhere between four to six weeks. We've had to adjust that a little bit because of these charter flights now we're required to take. What we did is, the way we came up with that number is when we talked to the Europeans, they had a flight in late '94, which was about a thirty-day flight, and they found out that after thirty days, people on console, basically they hit a wall. So they just happened to stretch it to the limit. They just got lucky that that's how long the mission would last. So what we did is we took that and we really didn't know how much you could use them after that, so when we set up Mir 18, we said, "You guys can go over for a four- to five-week rotations and that includes a week of handover. Go over for that period. When you come back, take some time off and then go back in the flow, supporting the POSA [Payload Operations Support Area]."

So before they go over from the POSA to the TsUP and they're required to be in the POSA two weeks before they go over there, so they can get up to speed, have them directly responsible. So if you look at it, you've got one engineer in Moscow, one engineer in the States, and one who's either just gotten back or preparing to go. So you can kind of spread it around. The problem is for this mission, if I've got a problem on something downstream that I've got to work on, on sorting out requirements or working procedures, then I get taxed if this guy's sick or he takes vacation. So we're really thin on that.

You've added these two positions [Systems Engineer and Timelining] in there. What that did is that freed up to do actually some of the intensive timelining, because it's a very manual process in the Russia system. Also the Mir Systems Engineer who can go talk to the Russia systems, for the vehicle systems for their water production, for their attitude and control, things like that.

The other interest is that a lot of these systems, they're using the same, like their Service Module and in their FGB, so we're interested in saving this system, because they're using the same system for station. So seeing how it works now.

So all the support, strictly speaking, goes through NASA 7, which ends with STS 91. Well, NASA 7, from a flight crew standpoint, ends with this, 91, when Andy Thomas comes back. However, we'll be doing some science activities on the Mir until the Russians come back. The actual Mir 25 crew comes back in August of '98. So there's a little over a two-month gap there. We'll be bringing back -I'm not sure what the responsibilities are with these, because this actually came through YA and MOD. I'm not sure. It would not make sense to have been following these systems all this time and then drop it, so I'm not sure how this will continue, but it won't be necessarily part of the Phase 1 Ops team. Timeline engineer will be pulled back. Mission science will be pulled back. Data and communications will be pulled back. Basically we'll just have an engineering and operations support personnel over there.

So starting after 91, we'll be going with two guys for the rest of the period. I think in this case one guy has volunteered actually to stay for the full two months, and the Ops support, I think, will be rotating them in and out. So, two, maybe three rotations on that.

Because this was kind of short-handed [Data and Communication Engineer], we had people there through NASA 2, I believe, and then basically after that, this was on call. We tried to get out of the computer business and actually have Marshall through the NISN support provide these, because they had actually guys in country and that was their primary job, because we'd have to stop and send parts and things like that, go through Customs. So it would be at least a two- to three-week delay if something were to break. So basically this is a job primarily in the POSA, supporting the servers and the data transfers back here.

If you want all these names, I can get them to you. Gloria Salinas is a good one to start, and she could probably point you in the right direction, because, as I mentioned, there are supervisors in each of these areas. There are leads across all this. The only one that's left the company is the Increment 4 team. However, these people are still available. One actually works -I think you talked to Tony Sang.

Wright: Yes.

Cardenas: One works with Tony Sang and the other one, I think, works for Boeing.

Wright: Typically where were these people's areas of expertise? When you were pulling these people, were they aerospace? Clearly some of them are medical people. Are they aerospace engineers, scheduling-type people?

Cardenas: Not at my level. They did have some here who had configuration management expertise, especially at this level, who had budgets and schedules, who were very adapt at the software programs you can use to develop schedules and things like MS Project and things like that.

For the support on here, they were primarily engineers. There was some science background. Also the majority of these people had space lab experience. Some had even worked Spacelab and, kind of like myself, were starting to get involved with station. So they had a little bit of a knowledge that way, and that's one thing that we've also tried to do, is try to be a testbed for the Phase 2 concepts, although that's always been interesting, because they're not very mature yet in all these things. So we don't mind being a guinea pig for Phase 2, but come in with a system that you've already gone through a shakedown on, and we'll try to use it. Especially in a timeline, we try to use some of the planning tools that they're going to use for Phase 2. In approaching the Russians, "You guys are going to have to use this, or you've agreed to try to use something like this for the International Space Station. Why don't we try to work together and we can help you learn some of it and we'll testbed some of this stuff out."

So we try to do that for the planning systems, for the inventory management systems, for the procedures developments systems, and for the logistics and resupply stuff. And we've only had success with one of those. When I say "success," a system that was in some kind of shape that we could use it now. All the others, it was kind of fragmented or they're too new, it's too young, or there wasn't any interest. For whatever reason, it didn't work out.

So, like I said, for the most part, in some cases we did stub our toe because where we had to get some more people in, they didn't have the experience that we needed, so we did stub our toe on a couple of things, but we made sure at least there was someone there to try to mentor them. In some cases we had to kind of throw them into the fire on some stuff, but we did the best we could to make sure they got up to speed.

Wright: They had the potential to do the job, if not the experience.

Cardenas: Right. That's what we were looking for -potential -so that if they did stumble, at least there was someone there to help them up. We weren't going to send them to Russia for six months, like a single point [of failure] kind of thing.

Wright: This is knowledge and experience and an adventure, because everybody that has moved into this has had no prior expertise.

Cardenas: Yes. See, I had worked Mir 18, and the problem was when we did Mir 18, it was assigned to this no longer exists the Life Science Projects Division, which is SE. So we did the implementation. SD, which is the Medical Sciences Division, because on Mir 18 a lot of stuff were medical investigations, human life science investigations, there was only one or two things that were outside the scope of that, but we lumped it in. So they defined the science and the requirements, and then we did the majority of implementation.

When you moved into Phase 1B, starting with Mir 21, you had SD only for HLS [Human Life Sciences] and SMP [Space Medicine Program], so you had a whole slew of other things. You had, like I mentioned, all these other investigations -non-human life sciences, microgravity, which SD had no experience in. I mean, they were only supporting requirements in this area. So you had all these other disciplines, and now we're being managed by Working Group 4, mission science, and the implementation now, all this structure comes out of the division I'm in right now, Payload Projects Office. To be honest, I'm not even sure if that's the name, because they changed it a couple of times.

There was very little continuity as far as heads between what we did for Phase 1A and what we did for Phase 1B. Originally this was supposed to be given -I was supposed to stay in SE. Then it didn't work out with the configuration they had at the time, so me and one or two other guys transferred over to SM and picked up that job. So all these people here, during this time frame they had worked STS 71, but from a pure Spacelab. They had nothing to do with the Mir aspects of it. So when we came over, they were expecting us basically to tell them how everything was done. I said, "We just did one flight. We can help you go on flight, but we've got to work together to try to lay all this out."

So our instructions were, we don't expect the contract support to know how to -it's not just a turnkey, "I write the task and you fill in all the spaces." It's like all of us have to work together on this. All the questions, all the stuff that they got done on the Shuttle and on the Spacelab flight, you know, if you did it this way in the NASA system, how would it manifest itself in the Russian system? Some cases, maybe it didn't apply. For example, all the communications things. You don't have that many with the crew member. Our responsibility early on is to track the systems there. We just hooked up to the interface.

So a lot of the stuff didn't match over, but at least ask the question. I said, "I don't expect you to know the answers, but at least be sharp enough to ask the question and then we'll work together and figure it out." Do we need a document to do this? Do we need to bring this up and close this with the Russians? Do we need to write a letter and say this doesn't apply? That kind of stuff.

That's how a lot of this stuff has evolved. A lot of the stuff during Mir 18 we didn't have to worry about, like I said, because it was a one-time deal. Our only responsibilities were to support the crew member on orbit and the science complement that was with them. That's the same way that the Europeans did, because the Europeans didn't do any of this, the Mir systems tracking. I mean, they were interested if a thermal loop broke, how was that going to affect the crew member, how was that going to affect one of their facility class hardware that was providing a coolant or something. So it was a learning process.

Wright: You've mentioned a couple of times that Thagard was a one-shot deal. Then it wasn't too long after that, you got brought in. Did that time period between the one-shot deal and Lucid going up, was it as busy as the board looks?

Cardenas: Yes, because what you did is, he went up in January. I'm trying to think. January, February of '95. He came back in June. In June of '95, because we use -again, it's kind of skewed because you had these Working Groups split up, and even within that, integration had its own schedule; operations had its own schedule, and training had its own schedule. If I needed to develop a procedure here, I may have needed it at this training session two months before. Or the hardware for this training session may not have been documented till two months later. So it was a real mess. They were being trained on stuff that maybe didn't even look at all like what was going to fly. So trying to pull these schedules together across this, because it's different Russians and the Russians don't talk. We've explained to them. They've said, "You want us to have this here, but this guy doesn't need it. I can't get it signed for another month."

This was a mess, and we probably erroneously mirrored the problems on the Russia side. Luckily we were all together so we could try to sort this out and hammer the issues out. But he came back in June of '95, was the first training session for this increment [NASA 2], and that's only six, seven months before she launched. Like I said, we didn't put these together until like late spring, until the middle of Thagard's flight. So I was back here, to be honest with you, to try to pull these things together to make these schedules match to support this increment. Plus not only this increment, but you had to work this one and this one, and start planning for this one. Because normally within a Shuttle time frame, you're given four years. In a Spacelab you're giving four years to develop hardware. You have to get funding and then four years later you launch. This thing is about fourteen months. So by the time I get approved, by the time I get the money to go pay the engineers to develop a piece of hardware, it's like a year before launch. I can't develop flight hardware in five or six months. I can get it certified and ready to go through this process, ready to get trained and ready to document everything.

So it's really been, in some ways, like I said, a learning process, but this concept of Express payloads for station, you've got to be careful how complex you make them and how you sell that, that's going to solve everyone's problems, because it doesn't. It doesn't. Adding more people and more dollars doesn't, depending on where the bottleneck is. If the bottleneck's on the PI and PED side, all that means is there's more people breathing down his neck. You know what I mean? Because he's got to answer to these schedules and these schedules, these schedules, etc. So it's tight. Now, actually going into NASA 6, there was some breathing room because we only had two increments coming up. So last fall wasn't bad.

Wright: Has it continued to evolve for each one, or once you get a point -

Cardenas: You mean the workload?

Wright: The whole matrix, all of this.

Cardenas: It's settled down a little bit, but now the problem is, this is the end and people see it coming up. So do I wait till the end and then hope that I can transition to something Monday morning when I come in? Or if there's something out there, why not? Like when we lost these guys [NASA 4]? They were not assigned to any other flights because we already had the other teams in place. So they actually booked -one booked in the middle of the mission, the other one booked the minute the things landed, so we're still struggling with that to get all the documentation to close that out. Because these guys have other assignments.

Wright: I received some of the briefing reports from the program. I saw the email stacks. I'm sure we don't have all the documentation for each of these folks.

Cardenas: There's a guy under Gloria, Jim Thompson, who does the archiving, and he can even print out a list of everything he's responsible to archive. I talked to Charlie, and he said, "Yeah, go and get the debrief reports." This is the only one that's come out so far. This should be coming out next week. I'm writing the executive summaries on them, so these should be coming out also shortly. Then you've got mission reports. This is coming out. We just signed that. So they're starting to come out.

We have records from NASA 2, but maybe over the summer we'll go back and make it consistent with this, the same look and feel. But also another thing is, people are big on these lessons learned and having debriefs. Well, by the time you debrief this, you might already be into the end of NASA 3. So anything I learned from Increment 2 I cannot always directly apply. If it's something in the Control Center that I learned that I don't do that again, I fix it right away. I take an action. I close it that day. So next time I get the report in, I don't do it the same way, or whatever it was. I have to fix it right away because if I wait till debrief, till everybody sits down and agrees how to do it, I'm already out of this increment and I'm starting this one up. Realistically, I can't put it down in black and white from a mission preparation phase till this one.

We try to tell PIs that, "If you did an experiment here, plan on your lessons from there, or your analysis that you're going to be able to do that. Skip an increment or maybe two so you can get on the ground and assess it and analyze it, and then start up again." Because even one increment in the middle makes it tight. You've got to have a really good staff in there. What's complicated is the communications with the Mir, because you don't get the data instantaneously. There may be a delay of several days. So I have a plan, but it's based on what I thought I was going to get back down. I have to give myself enough time period to do that. We do work that.

For example, when you come in with a replanning request to schedule change when you want something scheduled, you've got to give us at least a week's notice, because we've got to work it within the Russia system and the way they do their planning and scheduling for their timelines. Granted, that's maybe not directly applicable to the station, but there is sloppiness in the Russia systems and they expect it, because they don't try to schedule down to the five-minute mark.

Cardenas: On station, there's probably some middle ground that we have to shoot for, because otherwise you're going to burn people out. I mean, no matter how much they love the space business -

Wright: Your body can only take so much.

Cardenas: Yeah. And, to be honest with you, I tried to dig around and find, before we started this, from Sky Lab, how we did things and stuff like that, and it's out there, but no one really analyzed it. They just kind of documented what happened. No one really analyzed it and said for long-term flights.

The Russians, the schedule these guys work over there is they'll alternate people on different schedules depending on what's going on. The Ops Lead and the backup will usually work like one week. They'll either work a Saturday or a Sunday, and then the normal work week, they'll work all mornings, eight to five, because the first COM [Communications] pass -and these are Russian times -so you work 8 a.m. to 5 p.m., or you come in the afternoons and you work like 2 p.m. to 10 p.m. So there's always someone there when the crew's awake. There's always an American presence when the crew's awake. We won't go to that after this period [through NASA 7]; we'll just be there during the normal eight-to-five hours over there, because that's when the main management is on the Russian side. So eight to five, then roughly two to ten for these positions.

For these positions over here, normally what we've done is we go to what's called an ABBA, which the lead for NASA 2 came up with. What you do, you come in eight to five on that day, and that would be your A shift. The next day you go to B. So then I go home and then I don't have to come in till two to ten. But then I'm there two to then, but then I have to come in the next morning again. What that does is, he found that allows them to give them some overlap and some free time and also some time off, so it's a little different schedule. So he ends up working like a morning, then he works an evening and a morning, and that makes it rough because you get off at ten and you have to be back in at eight, but that's just for one day. They try to play with different options, and it depends on what the workload is, different people. If you're not a morning person, that kind of thing. But we try to formalize that a little bit so we don't have a lot of deviation.

To be honest with you, one of the other problems we had is that this whole Working Group 6 function was mandated to Space and Life Sciences [Directorate], so it was our responsibility to make this work. When we didn't have enough civil servants to do some of these jobs that we had, like operations lead, we went out and we asked for support in doing this, because we didn't have not only the right people, but not enough of the right people to get this job done.

We had a hard time getting people interested in coming over and going to Moscow for six months. I think part of the incentive to come do this was because it would be good preparation for Phase 2 or it would look good within station. They didn't come just for love of Phase 1 or for love of space and life sciences.

So people outside the directorate, my impression is, came in with different agendas, and in some cases that caused a little bit of problems because different ways of doing business. For example, we would establish policies. You'd have one lead doing things one way, another lead doing things a different way. You won't get that in a short-duration flight, but you will get that after three or four weeks, things come out. So we've tried to be adaptable, to be flexible, and we've said, "Nothing is cast in concrete. If you've got a better way of doing business, we'll do it." But we don't like to change just to change.

Wright: Isn't that part of people's management style in general?

Cardenas: Yeah, and we try to be very careful about that.

Wright: But there are rules.

Cardenas: Yeah. Management style is one thing, but here's the process, here's the policy that we do things, and we try to stick to that, because the ones to suffer is these guys [contractors], because this guy will say, "On this flight I did it this way. On this I did it that way." So these are the guys having to adjust to the different management styles, and not the other way around. You've got to learn to work with different people on that. And the fact that it's NASA sometimes was awkward. Because you could challenge these, but you couldn't challenge that, because of that.

Wright: That's quite an accomplishment, considering you didn't have a whole lot of information when you stepped into this.

Cardenas: Yeah. You know, the way it got started like in late '93, when we were doing just the Mir 18, I was asking one of the guys who was setting it up, "Who's going to take care of this? What about this? What about that? Who's going to set up the things in the Control Center? What about the training flows? Who's going to monitor from this side? What do we do with the data products?"

He said, "That's a good question. Why don't you look into that."

What I was afraid was, because it was so tied to STS 71, they were going to come to us at the last minute. So the STS 71 was June of '95. I was afraid they were going to come back at the last minute and say, "Oh, by the way, can you add this on to your stuff?" And we would have already been down the road and we already had Shuttle documentation, which it didn't really fit into because that was only during the Docked phase. So I was afraid we were going to end up inheriting it anyway, so I'd rather at least know about it up front so I could at least plan for it. Over in this, it was just me and another guy working these issues over there, and he was tied up in the Shuttle flights and the Spacelab flights.

Wright: So what were you doing before you got this task?

Cardenas: Before I opened my mouth on the Russia stuff, I was working the Shuttle, like Spacelabs, space and life sciences, IML, a lot of the Spacelabs, because I was in SE, so any mission that had a life science complement on, we were supporting. It wasn't only some of the Spacelabs; there were some standalone Shuttle flights, and then also I was working station. So half and half. So when this came along, you know, I didn't get any help; I just had to like absorb the other. So I was split between the three. As I mentioned, there was another guy I worked with, actually for, so he was a prime on the Spacelab flights. So when this came up, he was shoving off towards me, anyway. But I had to drop a lot of the station stuff. So since this has come up, it's taken all my time. I haven't worked anything Spacelab or any of the ISS stuff.

Wright: Will you go to station now?

Cardenas: I don't know. I don't know. I have not seen any transition plan for anyone. Right now a lot of these functions are being done by OZ within station, which is Mike Suffradini. They do have, I think, a few of our contractors over there supporting them, either through SAIC or USA or Boeing, but there's no civil servants who have Phase 1 experience.

Wright: From what you were describing, it seems to be somewhat totally out of character of how NASA's done business in the past. Did these forty to fifty folks adjust well to that? It sounds like the magic word to work on was "teamship" and be flexible.

Cardenas: Yes. I think so. But because they came from a payload background. From payload background, everything is different. I mean, there are things you have to do, a process you have to go through, but every payload is different. There are some similarities in terms of the design on some of the things, and they have to meet the interfaces, but every payload is different and every Spacelab is different from the last one in the way the thing is put together, which is not always the case on the Shuttle side. Basically it's the same basic Shuttle. There are some mods and differences between each Shuttle, but basically the thing is going to operate the same way, every Shuttle flight. So these guys have been pretty flexible. The MOD support between here and here hasn't always been, because they're in the mind-set of cookie cutter. Originally some of the training concepts that we had were based on Shuttle experience, Shuttle systems training, not payload training. So we really screwed up on that one, I think, when we started down that path.

We tried to take a cookbook approach to doing the training rather than saying, "Look. We're already in a jam because we've only got ten, twelve months to prepare a training template. Let's hit what we think we can hit, the high points. What are the critical skills we need to establish?" Because it's a different mind-set when you're preparing someone for two weeks, you just do it, do it, do it almost to the last minute, and then he can almost do it in his sleep in some cases. But where he's going to forget that after a month, when the payload has been scheduled a month into his flight, what is he going to remember? What key points do I have to give him to try to help him remember here? And then what on-orbit tools also is he going to need to go forward with that?

That's what I'm saying; I think they're flexible because of that, you know. Some of the people came in and said, "On Shuttle flights, on Spacelab flights, we had this." And that's a good question. "What will we have on this flight?"

"Well, you'll need that and this is the document." Or, "That's a good idea. Let's create that document. Let's go off and do that. We think that's got some use either on orbit or for the ground team."

[End of Interview]