NASA Johnson Space Center Oral History Project
Edited Oral History Transcript

John W. Aaron
Interviewed by Kevin M. Rusnak
Houston, TX – 21 January 2000

Rusnak: Today is January 21, 2000. This oral interview with John Aaron is being conducted at the Johnson Space Center [Houston, Texas] for the JSC Oral History Project. The interviewer is Kevin Rusnak, assisted by Carol Butler and Rob Coyle.

I'd like to thank you for joining us again. Today I guess we're going to talk some about Space Station.

Aaron: Kevin, the thing I thought I would like to talk about today was my experience, since I was in the middle of the formative years of the Space Station program. Not a lot is written about the Space Station program in terms of how the decisions were made internally, in terms of how the program was going to be managed and how the program was going to divide up the technical work. So I thought I'd reflect on my experience and views on that, and also touch on how I think that maps as a very important thing to benefit from the experience as we go toward the future.

When it came time to do the Space Station in 1984, of course, I came on board after the preliminary planning had been worked. There was a concept of element group activity in '93 that was let out of NASA headquarters with a large contingent of cross-agency people, across all the centers had formulated there.

President [Ronald W.] Reagan announced the program formally as part of the State of the Union address in '84, in January, and then the decision was made that the program would be managed using a lead center concept. That would be where the program management was, and the program office, and that the components of the Space Station, in terms of the major hardware elements, would be distributed across four NASA centers, and that the lead center's job was not only to manage the program, but also divide up the work and then make sure the work was distributed in a way that we could integrate back together in launch and assembly.

That turned out to be a very difficult and challenging activity for which not only I, but I sensed others felt ill equipped to manage. Now, what do I mean by that? Certainly I was kind of ill equipped because of the fact that what was being mandated was fundamentally different principles than had been used to divide programs in the past. If you think back to the Apollo program—let me use that as an example—and also it was also true in the Orbiter and Shuttle program, the way NASA had been successful is we took very large projects and divided them up into stages or elements and major chunks of work, and those elements got built in various centers and locations, and then they were integrated back together and had very successful mission.

So if you look over on the campus today with the Saturn V that lays down, you know, you can almost just go through. There were vertical slices as to how that work was divided up. The thing that you say, well, gosh, that means we knew how to do this. Therefore, it shouldn't have been a challenge when you got to Space Station when dividing up this work. When the Orbiter and Shuttle came along, some of the key principles of how to divide up work technically were maintained, and therefore major chunks of the Shuttle program were allocated to various places. The Johnson Space Center had the responsibility to build the Orbiter. The external tank was the responsibility and organization at Marshall [Space Flight Center, Huntsville, Alabama], the solid rocket booster, as well as the main engines. So that was the second major experience we had in dividing up major programs into elements and having them be successfully developed and then brought back together.

So what was unique about Space Station? Why was that such a challenge? That's hard to characterize, a succinct answer to that question, but I think here's some of the things that were different. For one thing, the Space Station at that phase of this development and understanding was very much an integrated spacecraft, so divide up the Space Station the way we divided up the Apollo program or the Shuttle program would be analogous to take the Orbiter itself. How would you divide the Orbiter up between across four centers to build?

The other thing that came with that was, we wanted to divide it up in a way with certain ground rules about the components that were going to be in each of these elements, because you can visualize the elements or each of the pressurized modules, the external truss, you can visualize those as structure and they look unique. The one thing that you do have a choice on, there's end-to-end subsystems and components that go across all those pressurized modules. What I mean by that, because once you get past the primary structure, then you've got pumps and motors and fans and computers, circuit breakers, connectors, all those things, and that's what really makes a spaceship. It's what you stuff it with.

If you look at what drives your cost of a major new program, it's how much design and development effort you put into those kind of components. So on Space Station, when you look at how we were trying to do this in a very cost-effective manner, and the fact it was going to be a long-lived program, the two principles were, we ought to have common hardware to serve common functions.

That not only says that you get benefits by building the design work on a computer once and then ask everybody to use it, or build one pump and then ask each of the element suppliers to use it, you not only get the benefits theoretically of the fact that you only have one design and qualification effort, but also as you go downstream and you maintain these assets on orbit, then your logistic system could theoretically only have to deal with one computer, one size fits all, and you don't have to have so many in store. You can have inboard spares when you go up there. You don't have to have one that's a unique serial number for every module.

So it was those kind of considerations that says we need to divide the work up somehow and have it be developed in a way that we interchange and use common parts. So those are some of the considerations for why it was more difficult than in, say, the Apollo program or the Shuttle program, because if you look at those two programs and look inside each one of those stages or modules, you'll find that the emphasis was on getting it done, not necessarily on having common parts across the whole program.

Why are common parts difficult? This sounds like a good concept, right? The reason common parts are difficult is that you have to work through all the organizations to get them to agree on what the requirements are for the common parts, what it should do, how fast it should be, how much should it pump, how big is it, does it need to be oriented left or right? And tremendous amount of negotiations back and forth is involved.

NASA was used to dealing with technical interfaces at what I would call a very high level. Going back to Apollo, for example, the command and service module was assigned to one organization. The thing that organization worried about with respect to the other elements of the program was, well, what are my interfaces? In other words, if I can define my interfaces, then that's a set of negotiations I have to do with my peers, but once I get those defined, then I can go about controlling my own destiny to build this thing called a command module.

So through that process the people, our forefathers who laid out these programs, were very conscious of what interfaces meant, and they were very conscious, I believe, in retrospect, the fact that high-level interfaces should be minimized in the name of efficiency in a program and that you should define the interface at a location technically where you can stabilize the interface, that there's not a lot of maturation has to go on a far as the design process.

Aaron Cohen tells the story—and I think you probably know he started off as the command and service module project manager here and eventually went on to be center director—that when it came time to define the interface between the command and service module and the S-IVB, which is the next stage, which happened to be a Marshall stage, that he very much was conscious of the fact that he and others were insisting that he minimize the number of wires across that interface. So when he sat down with his peer—and I think his peer was Ludie [D.] Richard at that time, at Marshall—they took that principle and made sure that that interface between command and service module and the Saturn S-IVB rocket was less than 100 wires.

So there's an example there of the fact that our founding managers not only divided programs up, which I refer to as "divide and conquer," you divide and conquer it, but they were aware of the fact that when you bring it back together, you want the minimum number of interfaces that you can have, and that will not only help you be successful in the end in putting it all together at the end, but also it cuts down on the amount of interaction, dialogue and negotiations and changes. If you can stabilize the interface and freeze it and have it stay that way, then each organization can go do their thing without a lot of overhead.

I'm probably over-explaining that to you, so let me move forward. You move forward to the Space Station program. I was the deputy program manager in '84 and '85 and to a large degree was interacting in how to divide this work up. Of course, there's a lot of technical discussions we had.

Of course, we were steeped in overarching politics, and I'm not talking about just congressional politics, certainly not the congressional districts in each of the locations that hosted these centers, but the centers themselves were vying for work. Because if you remember, back in the '84 time frame, it wasn't clear how large NASA's pie was going to be as you go forward. So the agency kind of had this affliction of where most of the principals in the agency assumed it was zero-sum game; that is, the pie was only so big. So the name of the game was to increase the size of your slice.

All those motivations caused a lot of pressures in the early days to carve out work in the Space Station to a particular center kind of independent of whether or not they technically made sense. That's probably a bit harsh, but it's basically what was going on.

We had the Lewis Research Center [now Glenn Research Center, Cleveland, Ohio], the Marshall Space Flight Center, and JSC, and the Goddard Space Flight Center [Greenbelt, Maryland], all trying to divide up the spacecraft, which was an integrated spacecraft that, by its nature, probably shouldn't have been divided up anyway.

Rusnak: Can you name a specific instance of what you're talking about in terms of the technical expertise, not necessarily getting what they should?

Aaron: Well, yes, there's some good examples of that. Let's take the power distribution systems, for example. Normally the power distribution system, in terms of the circuit breakers and the power supplies and so forth, you would think would be a secondary aspect of building a module, a pressurized module. The development of those kinds of utilities, you know, needs to be steeped in an organization that's used to building things.

Now, the way we wound up dividing this thing up, for example, the power distribution inside a module, the responsibility for those components were not the same organization or same center that was building a module. In fact, it was the Lewis Research Center. So they were building the power supplies, the circuit breakers, and the converters that were going to be used in the lab module and the hab module and so forth.

Also, the research center was exactly that when it came to major manned space flight development. They were the research center, so they didn't necessarily come equipped with—certainly they came equipped with the technical knowledge, but not necessarily the experience of what it takes to build a successful manned spacecraft. So you had constant exchange back and forth between the pressurized module developer and what the distribution component should be.

Now, if you can picture a wiring diagram of how the organization looked, you could see that would be four work packages here as peers, right, reporting in to a program system engineering organization. Of course, in that case you've think, well, the right answer to that is you'll just have this top-level system engineering organization just define this in great detail and tell people what it is. That's difficult to do in a NASA environment, because each one of these NASA centers tends to be a separate entity. It's hard to have one government organization take direction from another government organization, much more difficult than, say, a government organization giving direction to a contractor that's building. So even though on a org chart it looks like the program organization is in charge and can give explicit direction to each of the centers, each center has its own way of doing business, its own culture, its own management infrastructure, and to some degree they act more like peers rather than a reporting mechanism.

So I'm kind of off the track, but that's an example where we had other cases where like Johnson Space Center was the center of excellence for life support system, had always been that way. The Marshall Space Flight Center wound up responsible for developing the pressurized element, the lab module and the hab [habitation] module where the crew was going to live. Well, the prevailing argument was, they've got to have the life support system to go with the module. So there's a case where the center of excellence tried to change from Johnson to Marshall for life support system, and there were a lot of growing pains and a lot of inefficiencies introduced as a result of that.

I'm a little off track here and we'll back and pick up now. So you picture us in '84, '85, '86, didn't really know what the Space Station configuration should be, that is, knowing what its configuration was, but what its general characteristics were. We were trying to divide something up very precisely, with a lot of interfaces, without knowing what it was we were trying to divide up. So it made the discussions—that means there was a lot of gaming could go on in discussions. We'd get in cases where NASA people would sit down and it's be easy to get in a conversation that one person is arguing that something was bad, and the other person arguing the same thing as a virtue. [Laughter] Because you get driven to those kind of discussions.

We also were trapped by cost. You say, why do I use the word "trapped"? Well, cost is always an important parameter, but the way we were trapped by cost as part of dividing this up, and why common hardware is so important, we were trapped by our own NASA cost model. Why were we trapped by our own cost model? Well, NASA traditionally, the way we develop what things should cost, is based on, tracing our wake, on what things cost in the past. The way that our cost models are racked up, they're all hardware-based. So you know that that's not right. It's not just the hardware you're building that costs money; it's also the program management analysis and integration and all the program management overhead. But that's hard to track.

So the way our cost model is laid out is, you picture on a diagram what the hardware is and then—I'm going to oversimplify this, but not much—you then visualize, well, how much is that hardware going to weigh? How many pounds on earth? What's that hardware's complexity? What's that subsystem hardware's complexity? And you load the model with elements of hardware, how much they weigh, how complicated is the subsystem, and are you building a crowbar or a high-tech water recycling system? You assign the appropriate. Then that gives you the cost of the hardware.

Of course, hardware doesn't go together by itself, so there's an estimate in there. What does it take to integrate that hardware together and make a system out of it? Then those are called raps, so you sign a factor that says, well, that's 20 percent more than the cost of the hardware. That's not the right number; I can get you the right numbers.

And you say, how much does it cost to put these systems together? That's another factor that gets you to an element. Then what's the factor that causes you to estimate what it takes to integrate elements together and do all the integrating analysis, all the design, work all the interfaces and all that?

So all NASA's costs had been accumulated over time in what I would call a traditional management structure that's much more pyramid, a pyramid management structure. It wasn't developed in an atmosphere that had large numbers of technical interfaces dominating the scene between the four major centers.

NASA does not have a good way to estimate what interfaces cost, and therefore it was hard for me, being a technical manager, even though I was a deputy program manager. I knew interfaces. I'd been in the development business. I knew that interfaces implicitly cost you, but you can't assign a factor to it. Well, when you're having long discussions, trying to divide work up, and the name of the game is to get more work on the table on your slice of pie, if you don't have good evidence of data, it's hard to win that argument.

So we were trapped by our cost model both being hardware-driven and not having any data in it that says what those interfaces cost. In fact, NASA's kind of gotten itself trapped in that. Because of that, there's not an over-awareness to track interfaces and try to minimize them.

Of course, it turned out to be very key to Space Station, in that because as we went through the growing pains from '84 through about '93, which is where I was literally in line in the Space Station management structure, we went through numerous redesigns. So as we did the redesigns, not only did we have a problem getting the first design done and made consistent across all four work packages and all four centers, but every time you did a redesign, either one of the participants or the major work packages could hardly go off and, on their own, optimize it at their level because every time you tried to optimize something, you ran into an interface, so you'd have to go negotiate with Marshall or Lewis and so forth. So you can visualize the overhead that you get into, trying to not only design something, but optimize it in that environment.

So we found that the only way to work that was the program management would set up these large ballrooms. We'd have to get in rooms with hundreds of people and negotiate very detailed things. A management analyst would sit there and tell you, "John, you guys violated Management 101." Yeah, probably did. But we do have to come up with a way to manage this, because it's a reality. And why is it a reality? Well, gone are the days when you get an announcement from the President to go to the moon in nine years, which implies "I don't care how you do it." So that problem is handed over to a technical management team and they lay out a program and you do it.

Today, if you announced going to the moon, there would probably be 200 pages of language that says not only, "Go to the moon," but, "but here's all the considerations that you ought to do. You ought to divide the stuff this way. You ought to have these 300 secondary objectives, and, by the way, we want to make this international partners." You've got to divide up the work among the international partners.

Rusnak: So do you think that's why Reagan's '84 State of the Union to do the same with the station in ten years didn't have the same effect?

Aaron: It didn't have the same effect for a couple of things. One is, even though he said that, there was not a shared imperative by this nation that it was important. To get things done, you need imperative. Space always kind of got into the syndrome of, well, we'll cut the budget. Of course, the nation said, "We'll cut the budget," but our reaction was, "Gosh, that's going to cost us money and it causes us to stretch out the program, so we'll have to extend it to another year." And I think the sense was, "Well, what's another year? You know. The moon will still be there. I mean, Mars will still be there. We'll get there some day. What's the imperative?"

In the sixties, there was an imperative to do it that was shared throughout the country, so it was not just a statement; there was a real sense of urgency to do it. The station's never had that sense of urgency. There's nothing like a deadline.

The reason that I spent time on this is that the way the program got divided up in '85 and '86 caused a lot of technical interfaces to be generated at a high level between the NASA centers, because a large design effort and a very long convergence loop on design—in fact, we would hardly get a design converged, then understand what its cost was, and in the meantime it had grown to the point that your first conclusion is, we've got to redesign it again. That's how long the design loop was. A design loop you can do in months, not years.

The reason I dwell on this and relate this experience is that we did not divide it very efficiently. We tried to divide up their cost model, which was only technically driven, and we did not have an ability to establish an inefficiency factor for an interface at a high level. Now, there's two reasons you like to be able to understand that. One would be, you'd like to program that inefficiency into both your cost and your scheduling estimates. Well, that's a key benefit, but it wouldn't be the only benefit.

The key benefit would be perhaps that having some kind of indicator like that would cause you to stop and take notice as to whether or not you ought to change the interface, make the interface a different place. Rather than having the technical interface here, which may be unstable and create overhead, we could include this piece of function or this hardware with this element, and that would therefore give you a place to put an interface at a simple place, a more stable place.

Another analogy, another thing it might do, it would force you to come to terms with how monolithic or an integrated design that you want—let's go back to this computer analogy. You think, well, the most efficient way to do this is you have one computer solution you give to everybody. That creates interfaces and difficulties rounding up all the requirements and doing designs. I just went through that example.

It could be that you would conclude that, well, with a Russian partner or with an ESA partner, international partner called European Space Agency, or Japan, that maybe it does make sense in the overall scheme of things that they build a slightly different computer. They have slightly different needs. They could certainly do it quicker if we didn't have to go through all these negotiations. So you'd be able to balance out this business about if I do it from a hardware standpoint, very esoteric and monolithic, which is what you would do if you have one organization build it, and you build a very tight, integrated, efficient spacecraft, you might say, given the mandates of who needs to do this work, which are dictated by politics, the geopolitical things, would allow you to balance how much you need to optimize the hardware design and get you back in balance with optimized hardware design with an optimized program political design.

In other words, we need to have a way of assigning politics a technical value, the same way we assign weight and power and volume. See, when you do the systems engineering process, there are certain attributes of engineering, you know, in terms of constraints. How much power, how much weight, how much volume. If we had a way of saying politics or interfaces are an attribute and we put a tangible value on those in terms of numbers, then maybe we can divide programs up.

We certainly should spend, as we go forward in our NASA programs, spend more time being sensitive to that step. There's a tendency on the front end of the program to get caught up in the euphoria, get a lot of people involved that maybe haven't been through the hardware development phase, and therefore don't assign enough appreciation for this fact that chickens come home to roost if you're not careful how you design this out.

If you look at the International Space Station today, almost everybody is planning and bringing hardware to some degree to the Space Station. That makes the Space Station, from a management standpoint, a very massive program to manage. Now, as we go forward to the moon and Mars, very likely there's going to be even larger international endeavors. We can't turn that into the time scale it took to build Space Station. The Space Station, given a mandate and given to a very efficient design implementation organization, the Space Station could have been up there in 1992.

The original target—I won't say mandate—was that Space Station was going to cost 8 billion dollars. That was the estimate. And it was going to be launched on Columbus' 500th anniversary, which was in 1992. That would have been possible and practical, given a stable set of funding and design that would have been easily converged into something you could design and build. As you know, this is 2000, and we're still working on it.

Another key aspect of dividing work up is how to balance the following forces. Each participant that's bringing a major element of hardware—and this gets back to the same thing I've been saying—will bring the premise to the table that, "I'd like for my piece of hardware to be an integral part that you're dependent upon." The tendency is to make all this stuff very, very interlinked. Well, if you get it on a pure design piece of paper, that's probably the most efficient design, is on a piece of paper.

In terms of the way you manage programs, though, it causes you difficulty, because the more you explicitly interlock and interlink these things to be interdependent, the more your inflexibility is brought to bear when you're trying to execute the program, because so often we plan programs based on the fact that we think it's going to occur just in time and it's not going to be successful, and that's not real world. It means some percentage is going to be on time and some percentage is going to be successful, but it's not 100 percent. So the more you interlink interdependencies, the more you set yourself up to be impacted by both cost and schedule when one doesn't show up or one is late or one doesn't perform.

Unfortunately, those things happen to you when you're in the later phase of a program, when everybody's at their full strength marching army, because you've built up, you're down in the final throes of the program, getting it delivered when that happens. So everybody's at the marching army, maximum paychecks, and time is money. You can hardly keep that phenomenon from happening, because if their schedule slips, you can almost just multiply—I think my experience on these large program—your workforce cost times time. You think you could lay those people off. Well, that's not practical. That's not the way the world works.

So time is money. So that's another aspect of dividing work up, is you create interdependencies all across the country. At best, you're kind of loosely managing those because they are distributed. Then you become a victim of glitches that then everybody stands down while that one participant brings it to—now, to the degree you don't have interdependency, each can move on to completion or work around it, and I think that's key.

Those kind of cost and schedule eventualities, NASA needs a way to feed those effects back into the very front end of a program, in effect, this cost model, and affect the way you divide the programs up and affect the way you pick the amount of dependency and dependency that you want to have as a function of what the risk is of what each organization is bringing to the table.

If you take an organization that's got a good track record, they're not building something high risk, then a program manager might decide, "Well, we can afford to depend on that." If another group over here doesn't have a good track record, they're working on some high-risk stuff, may or may not happen on time, well, then the program manager ought to have the flexibility to say, "Yes, I know my cost model's telling me that it's the cheapest because it only weighs four pounds and so forth, but I believe, due to the risk factor, I need to plan an alternative right up front. So I'll build some other module over here that will allow me to continue."

Those are very much at the macro level the things that we all knew as—I came on the program in '84, and based on all the experience that I had in flight software as well as all the operational experience I had on the previous programs, we all knew, I think, honest and deep down, those were macro effects that we were violating, but the dynamics of the agency at the time, not only within the centers but on their respective contractors, because that's just an extension of the center's contractor relationship, since we didn't have a precise way to estimate that and assign it a numerical value, it caused it to be very difficult to make those kind of arguments in the face of taking work away from one center.

So there's the challenge of the future, because I believe distributed work is the way of the future. But the trick is to divide the work up such that the value of the work you're getting from an organization and its value to the program is not overshadowed by the amount of cost and effort it takes to integrate that into the program. And it's very easy to lose gain. "I'll give this piece of work to this organization," and they may be giving it to you free. It may be a contribution. And if you're not careful, you'll pay more to integrate that work into your program than the value of the work you gave away.

So that's my thoughts. It's a very complex subject, and I don't have all the answers, but the one warning I would have is it's something you have to very closely pay attention to.

Any questions? Any follow-up questions?

Rusnak: Do you think there is a practical way to essentially quantify these effects that you've been discussing? Obviously at the time you say it wasn't really practical, but now do you think there's a better method of doing that?

Aaron: Unfortunately, no. I don't know that we today can go back and capture the cost on Space Station in such a way that you can distribute it back to the origin of what the hardware should have cost and then what caused it to be greater than that, and therefore assign some kind of value to this phenomenon.

I still think that it's probably left to the judgment of the management that sets the programs up. The only way to really go collective would be to have enough programs done in enough different ways and good enough records kept that you could then go back in retrospect and collect the cost and make comparative analysis.

It's not unlike the Packard Commission. The Packard Commission—and I'm not going to have my facts straight here—back in probably the seventies, Packard was commissioned by the President, or at least in the administration, to go do a study on why things cost what they cost. The Packard Commission, I understand, went to the automakers, went to the military, went to NASA, and went to other various commercial companies and looked at their products, looked at their cost to try to draw some analogy. I'm going to oversimplify this, but they came back with the fundamental conclusion as that things cost the way they cost because of who's built them, not what they are. In fact, I think the story I heard was that the commission said, "Before you tell me what they're going to build, tell me who's going to build it and I can almost predict what they cost."

Now, if we had data around all that, so you could map certain organizational models against a product, then maybe you could get some trends about what things cause things to cost less and what things cost more. I think we know. I mean, there are certain people in the agency and outside the agency that have gone through large developments, I think they implicitly know what causes you to cost money and what causes you to not cost money.

Of course, if you can define a project to take the minimum amount of time, it's going to cost you the minimum amount of money. So it sounds awful simple, but there's a lot of factors goes into that, including what we just talked about. If you can have the wherewithal and the prerogatives to design something in a small organization, make all those decisions, design will go a lot quicker, and right on down the line. It's the decision time that kills you, the time to make a decision.

Let's see. That's probably enough on that subject, because, like I say, it's a complex subject. There were a lot of other things going on in Space Station in terms of what the agency was trying to do with the Space Station that also contributed to its difficulties, but it wasn't just this that was going on.

The agency, as a result of the Hearth Committee report in the '82, '83 time frame, concluded that NASA ought to strengthen its in-house capabilities, its in-house engineering capabilities, and that as part of revitalizing the agency and reestablishing that internal capability, they said one of the objectives of Space Station is to reinvigorate the agency. That caused us to come to terms with, well, if we're going to design Space Station in-house, how are we going to do that? Where are we going to get the people? They obviously have to come from multiple centers.

Getting those people assembled together and working together, I think the agency did not appreciate how long it took to build an organization out of a diverse group of people and get them operating as a homogeneous set. In fact, the agency's management weren't always patient enough. In my experience, because we built about three different organizations to design and build Space Station, we had the skunk works here in the Nova building for almost two years, Neil [B.] Hutchinson and I put together a program-level organization as part of being the lead center, and that brought a bunch of people together that hadn't been used to working together, and it took about two years. Reston [Virginia], that was then, of course, the skunk works had disassembled and they all went back to their respective centers. We put the level B organization together, that Neil and I put together, and we made some mistakes. Took us a while to get those worked out. In fact, about the time we got them worked out is when they decided to disband that and move it to Reston.

Reston went through the same throes of what it takes to get people recruited and together and start working together, and, in fact, about the time—and they had a lot of start-up pains, and they were just starting to be effective when they were disbanded and Alpha came along. Now, what's my message there? Having been in the middle of that, it's easy to assume, well, let's do it this way. Let's put together a new organization. Let's put together a new paradigm, and it'll be better. There's not enough allowance for the realities of how long it takes to put an organization together and get it operational in a homogeneous set and be effective.

In fact, the NASA management, unfortunately, runs out of patience just about the time that it starts being effective and it gets recombined somewhere else. I've watched '93, a whole new organizational concept was put in place on Space Station in '93, called Alpha, and it's taken a number of years for that organization to come together and be effective.

So change is a way of life. Change is good. But we should not trivialize the overhead and inefficiency that gets introduced if you're not careful, as a part of the front end of change. In fact, if you look at what we're looking here at Johnson Space Center now in Space Station, it's a lot of cases where we're turning back to the fundamentals of how programs were originally done here. Of course, the fundamental question could often be, well, why do we part so easily from things that have worked? That's a tough question. I've wrestled with that one because we did Apollo a certain way, and to a large degree that just mapped right into Skylab, mapped into the Orbiter and the Shuttle program.

So why are we so anxious to try new paradigms? Well, for one thing, there's always the motivation, because it's true what we do takes a lot of detail, planned, takes a lot of effort, takes time, and so it's easy to view these programs from the outside—Apollo, Shuttle, and so forth—is that, gosh, there must be a less expensive, quicker way to do this. And I would agree with you, there is. There is. There's lots of cases where that is true. But yet be careful how you go implement those. It's too easy to trivialize. In fact, NASA itself sometimes, us guys inside NASA, I don't know whether it's our mental makeup or what, often trivialize what we do and not accurately reflect how complicated it is and how much detail it takes, how much planning it takes. It's easy to just think, well, spin Orbiter a hundred times, it's just a pickup truck, just an old pickup truck. That's not the case. So it's easy to stand on the outside, if you're not careful, and say, "Well, that may be a tried and true method, but that's way overdone. Let's jump over here and do this."

One has to be very careful about wholesale paradigm shifts in the way you do things. So each program, to some degree, always before they launch and really get serious, I've found, kind of return back to fundamentals, and station is probably doing more of that than previous programs that I've been involved in, and I've been involved in all the manned programs here at Johnson Space Center except for Mercury.

Rusnak: Do you think either the Apollo or the Shuttle model would have been more effective for station?

Aaron: Well, yes and no. If you just look at it from a technical guru standpoint, yes. I mean, because we would be finished by now, and time is money. If we wouldn't have had all the mandates of Congress and the administration, Russian participation and all that and four major work centers working the way we did, it wouldn't have had that. So I guess it's a function of what value you assign. Is the highest value literally building something and flying it or how do you weigh that into the fact that the space program is also used by administrations as an element of international policy?

So it depends on how you judge it, but if the program had started out in '84 and stuck to tried and proven principles like Apollo management structures and Shuttle management structures, spacecraft would have been up there long ago.

Rusnak: Given the mandates that NASA really couldn't do much about: having to use international partners and spreading the work out, is any of the earlier models even applicable in that context?

Aaron: Yes. Yes. I mean, if you'd have had the same values in the management at the top level, because the Apollo program was divided up. It was divided up because one place wasn't big enough to do it. Didn't have the resources to do it. I mean, it was [unclear] over the country. But as I said earlier, the overarching principle division of work then was divide it in a way that doesn't introduce inordinate overhead, managing it and putting it back together. Had we been steeped in those same principles and value systems and stuck to them when we divided up the Space Station and didn't yield to people's individual prerogatives or center organization prerogatives or tendencies and stuck to our knitting, you could have done something with international partners. There's a way. We would have been much more effective and been much closer than where we are.

There has to be a way of dividing it up that makes sense. You can't let all the participants come to the table and do à la carte. "I want that, but I don't want this." You say, "Wait a minute. Those two things logically go together." "I don't want that. I want this." It can't be a grazing exercise. [Laughter]

Rusnak: That's a very good analogy.

Aaron: And to combat that, it has to be steeped in principles of the implication of grazing.

Rusnak: So were there any, do you think, technical obstacles to the completion of Freedom or were they all in how it was structured from the management and how it was divided up?

Aaron: Well, Freedom, as you can tell, had its trials and tribulations. Personally—and I don't know this to be very popular—my view is—and, of course, people will say, "John, you're biased because you were in the middle of it," and that may well be true. We all have the perspective from where we sit, right? My sense, Freedom went through a lot of growing pains and we had a lot of twists and turns and ups and downs, but it was kind of like the organization stuff I talked about with the skunk works and the Level B and the Alpha. We were disbanded—not we. I shouldn't say that, because that personalizes it. Freedom was disbanded about the time it had its act together. That's a judgmental thing. I mean, I think we knew when the launch date was going to be. I thought we had enough material, enough hardware designs, and it was stable enough that we could actually predict the launch dates. We could predict we had an overrun, but it was an overrun that you could see and you could predict and therefore quantify.

I think the unfortunate thing about Freedom—and, of course, it's all timing—it was disbanded about the time it had its act stabilized. I mean, we probably knew when the launch was within six months, with certainty. So that's a byproduct of the fact that I think we finally got the organization stabilized, finally got the interfaces stabilized. In fact, we had reached the point, which is always healthy in a program where each of the individual organizations were no longer coming to the table trying to carve out more work. They already realized they had all the work they could do. In fact, they were returning work to the table. And when you get to that point, I think everybody realizes they're in the same boat, so there's a whole motivation of working together.

You know, programs kind of go through a phase where euphoria and signing up for more than they can do and getting in competition with each other, they reach a phase where they realize they may have bit off more than they can do, and then we're all in the same boat together. So there's a whole gel that happens in an organization when it's not in competition anymore and it's just trying to get the job done.

It took a long time for Freedom to get the organizations across the country into that mode of, "Oh, gosh, we've got to do this thing and we've got to do this together." It took them longer than the usual time to get there, but I think we had gotten there about the time we were disbanded.

Rusnak: So did the subsequent redesigns retain any of that or was it starting from scratch?

Aaron: In terms of the Alpha redesign or the current redesign, of course, when you look at it, of course, the major difference is the Russian contribution. But if you look at the U.S. pieces of it, the pieces were reassembled in terms of how they go together, maybe, and they may go together different, but basically they evolve back to the same pieces they started with. Modules pretty much are the same modules. The truss is the same truss. It's still got the Alpha joints and Beta joints. All that stuff came back in. So in terms of the pieces, it evolved back pretty much to where it was on the U.S. side. The thing that was totally wholesale changed out was the organizational approach.

Rusnak: How so? What was it like after?

Aaron: In addition to redesign of Space Station, in fact, in '93, I think you know that not only did we redesign the Space Station, but we went back in and looked at a clean sheet of paper with some fundamental options. There was an Option A, B, and C. The selected option out of that was Option A, was really a stripped-down version of Freedom. It was stripped down to the point that things had to be added back to make it fly in spacecraft.

In addition to all that redesign, technical redesign that was going on in the '93 time frame, there was also an attempt to deal with this management interface that I referred to, the fact that four centers, four different NASA centers—by then, three—were playing in this, they each had their own separate contracts, so there was an attempt to come to terms with this thing I've been talking about, this overhead of all these interfaces being created at a program level, at the highest level, and the fact that that was causing inefficiencies in the program.

The paradigm shift that came out of that was, "Let's go back to a different model." And it was back to a model that NASA, because NASA primarily used lead centers for big intercenter developments, they said, "Let's go back to something that's more equivalent to the Air Force way of doing business." These are kind of my words. "We'll have a small self-contained program office that the Air Force calls a SPO, and a way to solve all these different contracts that these centers have, interacting with each other with all these high-level interfaces and interchange and uncertainty. We'll aggregate all that together into a prime contractor. So we'll have a very normal and capable prime contractor and a small NASA program office as a SPO, and the program office will divest itself of dependency on the institution." Very fundamental change, because NASA's major programs have always had a major institutional underpinning, and I think that was a large contribution to their success.

Now, over time the Alpha program, which is International Space Station, has gone more and more back to the institution to get that technical expertise and underpinning to fill in some of the gaps that have shown up in the program. Very fundamental shift.

Rusnak: Yes, it certainly was. You mentioned the redesign and the different options explored. You worked on Option C, the single launch. Can you talk about that a little bit?

Aaron: Well, yes, I could talk at length about that. First thing I could describe, it's probably the most fun work I've done in the last ten years. But that's probably not what you want to talk about. I can tell you how I got involved in Option C. That's also kind of an interesting story.

Rusnak: Sure.

Aaron: And I could also talk about what the three options were about. Back in the '93 time frame there was a number of things happening. There was a change of administration. Of course, that always adds uncertainty into a very large program, particularly a large program that has implications of international policy. There was a lot of concern about the expenditures of NASA and expenditures of the country in general. It's hard to believe it's only six years ago, with all the booming and surpluses today. There was a big press on that.

So when the new administration came in and became aware of some of the costs and technical difficulties Freedom was having, in fact, I was managing Work Package 2 at the time, and my major contractor had, in the January time frame, just tabled about a 500-million-dollar overrun. So at the same time that the administration was taking office, this 500-million-dollar overrun for me or for my contractor was tabled, and that just kind of fueled the fire with respect to that they either canceled this program or significantly reduce its cost.

So I was removed from the program management structure in February of '93. I don't know whether you know about that story or not. I was removed in a kind of interesting way. Did I touch on this the last time?

Rusnak: You did mention a little.

Aaron: There was a certain senator that called for my resignation because of “waste, fraud, and abuse.” So I was taken off the program in February. In March is when the agency then had asked that working with the President, the fact that we ought to go pursue a cheaper option. So in January I had been moved from program management over to the engineering side of the institution to work systems engineering, and I was in the engineering institution here when the call came to go study options. It was a multi-center option set of work. There were three major centers involved in the options, because you couldn't just have one center do it. That might be collusion and bias.

So there was three options that came out of the first set of preliminary discussions, Option A, B, and C. Option A, like I said, was the scaled-down version of Freedom, and it was blueprinted with a technical group in the Marshall Space Flight Center. Option B, I would call it the streamlined Freedom. It wasn't so much the strip-down, it was the streamlined Freedom, and it was orchestrated out of the Langley [Research Center, Hampton, Virginia] contingent. Option C was a radically different concept, it was a concept that, no surprise to you after hearing this conversation, that tried to go tackle some of the fundamental problems we had that were driving cost. So Option A and B, if you stood back ten miles, it still looks like the same Freedom.

Option C would even look different at ten miles, and it was going after the following thing. It was going after the fact that all these options had previously been built around the Shuttle as the delivery vehicle, so they had to be modular, took a lot of Shuttle launches. The fact that they were modular going into space drove a lot of EVA and there's a lot of overhead and concerns about EVA. And since it involves a lot of Shuttle launches and a lot of EVA, it causes time to be inserted into the program, so, as I've said before, time is money.

So, well, how do you make a very low-cost Space Station? Well, you put it up in one launch. And if you put it up in one launch, you put it up in one module. Put it on one module, then you don't create these interfaces EVAs so every time you go thirty feet you don't have to stop for the bulkhead and start creating some more interface. So Option C was borne out of this idea that we go tackle the fundamental things that would drive us over our cost.

Also, of course, you build one single stage, it would present a problem. We knew that this thing will really be tough to divide up. You try to divide this thing up, you'll really get expensive. We didn't really deal with that. Our proposal was, one organization ought to build it.

Option C also had the benefit, we thought, as a side benefit it would create an unmanned launch vehicle at the same time. So the way these options were worked is that they had formed a temporary ad hoc program office in Crystal City, Virginia, and they were giving out the directions. We had local managers of each option at the center. I was Option C. Henry [O.] Pohl and Don [Donald C.] Wade and I, just kind of the three of us, managed Option C, and we aggregated about 200 people across the center here and put together this very radical concept.

A very interesting thing happened as a result of that. I think the agency first viewed that, "Oh, that's interesting, but those guys will never pull that off. They're trying to cram too much stuff into one launch vehicle." But I tell you, the more we worked on it and the more detail we got into it, the more natural it became as an engineering solution. As we got about halfway through it, it was clear it was going to be a paper design. I mean, it was going to be something you could go build. So a lot of attention turned to it.

An unfortunate thing about that is I think less attention turned to Option A, so there probably should have been a lot more engineering scrutiny put on that configuration, as I mentioned earlier, because a lot of the things had to grow back, as I just told you.

But when it came time in June to make the selection and the Vest Committee which had been put together by the administration to look at this, when you read their report, I think deep down that probably was the consensus that that was the best technical solution, even though it was radical, it was new. The fact that we were building it out of reusable parts from the Shuttle program, we just started building it out of Shuttle components, that not only makes it cheap, because you don't have to do the redesign, it also says that the Shuttle and station could have a shared logistics program.

So the Vest Committee, the way I read that report, probably came to the conclusion that that's the best technical solution, but there were two significant down sides to Option C. One was perception and the other was—these are my words—one was probably the perception and the other was what about the international partners. Such a monolithic design, it's alleged that when showed that to the Russian delegation, they said, "That's a very eloquent design, but you don't need us. You don't need us. Where do we fit? You don't need us." So since we had so much volume, I think the European Space Agency in Japan were concerned about the same issue. So we had over-optimized, I suspect. That's probably the thing that really killed it.

The perception—let me dwell on that a second. It's awful hard, even though we were building out of Shuttle components and was going monolithic and we thought had a very controlled understanding of the development cycle to do it, it's hard to sell to Congress and other places that we can make this thing cheaper because we're going to start with a clean sheet of paper and it's going to be totally different. There was that perception of "That can't be."

From an engineering standpoint, it wasn't necessary orthogonal, but from people who were viewing it from the outside, it just had that look about it. How could you do it quicker and cheaper by starting over? So those were its two major downfalls.

That was in June. I think the selection was on June 10, 1993. Don't know why I remember that. But then once that selection was made, the Alpha, the "A" configuration was made, I stayed on with my skunk works here and worked on refining the Option A out with how to incorporate the international partners. So we kind of just moved on to incorporating design features into Option A and getting JSC prepared to receive the program management organization, which moved down here in October '93.

So it was a very rewarding time frame. I think if you talk to people in this center that worked on Option C, they'll all tell you it was probably the most fun thing they've done in a long time because it was pure engineering and it was a lot of innovation went into it and it resulted in a design that accomplished functions kind of naturally as opposed to having forced design accomplished functions. So if you go talk to anybody in the center here, they'll all tell you that was a fun project.

Rusnak: We did actually talk to Chet [Chester A.] Vaughn about it, and he expressed similar sentiment about how enjoyable it was to work on.

Aaron: In fact, Chet was our contact. He represented Option C in Crystal City [Washington, DC]. He probably told you that. And he probably told you that Don Wade, Henry Pohl, and I were leading the team down here to build this, so we were feeding him stuff every day. Fun time. So even though I was kind of kicked off the Space Station in February, I resurfaced on Option C a month later.

Rusnak: Did Option C draw any technical heritage from either Skylab or, like with Shuttle, there was the concept of using a Shuttle C, which was the unmanned-type vehicle.

Aaron: It drew a lot of heritage on Option C. In fact, that study was let out of Marshall. A very detailed study had been done on Shuttle C. For the record here, Shuttle C was taking the Shuttle basic building blocks and building an unmanned launch vehicle out of it. So the aerodynamics, the shape, all that we built on the database that was worked on Option C.

A lot of us had the advantage of having been part of the Orbiter development, Shuttle development, so I knew all the avionics components almost by heart, and I knew how they would fit in. The other people here at the center that were working on it had that Shuttle heritage, so they very easily knew how to damp Shuttle components to that solution, because, you know, spaceships tend to all be built out of the same thing. And when you look at the Shuttle, you think, well, it's primarily a launch and delivery vehicle. Well, it is, but it's also a mini space station when it flies. So a lot of the components are directly usable in that environment.

Back to my first discussion, it's the design of the components that cost you money, right? That and the program management. And we proposed a very monolithic program management structure for this. It would be a single organization with a very tight management structure.

Rusnak: What about the integration of the other centers?

Aaron: Our plan was, there would not be any. That's how we would be able to save the money. Certainly we had to go buy extra copies of main engines and so forth, but those are more of a purchase arrangement rather than a design arrangement. So there wasn't going to be any. That was why you could logically say we could do it as quick as we could and for the kind of costs.

Rusnak: Of course, getting back to the political discussion, you were mentioning before that without taking those into effect, it makes it difficult to sell that.

Aaron: Makes it very difficult to sell that. It makes it difficult to sell it as to why it's that much cheaper, to go back to that. Since we were building it from an Orbiter kind of cost model, an Orbiter kind of model, then the Orbiter cost model was, we thought, much closer to what it would actually be. We weren't trying to extrapolate one experience to a brand-new experience.

Just to give you an example, one of the things we did was redesign a power system from Freedom, and the fact that the way Freedom was built and the way it was distributed with all the distribution losses and all the various kind of isolations that you need because it's modular, if I remember my numbers right, we were able to generate the same amount of power to the end user with solar arrays that were probably 30 or 40 percent less acreage. We probably took 30 or 40 percent of the inefficiencies out of the generation distribution system. I've got the numbers in there. Of course, when the station people first looked at it, they saw the size of the solar arrays, they said, "Well, that doesn't generate enough power." And I said, "Don't be misled. What we've done is work the inefficiencies out of it such that even with smaller acreages, we deliver considerable bus power to the users," which is what counts.

Again, back to what is the objective. Is it to have a monolithic design that's very efficient technically or to have a program that's shared around the world?

Rusnak: Did you want to say any more about your participation in the Space Station since that point?

Aaron: That's been a very rewarding thing. Of course, in '93, after having worked Option C and prepared the organization to receive the program office here and hand it over to the people—that doesn't sound right—merged the people into the line organizations at station, I went back to being the head of the systems engineering office in engineering directorate, and the primary job there was to integrate and orchestrate all the higher engineering support to both the Shuttle program and the station program. So my role changed to more of lending support, supporting special issues, putting teams together of the 400 people that support Space Station from my organization, rather than directing the day-to-day management decisions.

So it's very much of a different role. It was work their problems, put teams together to do that, and respond to the programs as opposed to direct the program. A very much different role, but a very rewarding role because I got to work back more on the technical and less in what I would call the management fray. But a certain management fray at that level. Probably a lot of people sit in rooms and watch the program manager and think they've never, never done that before, that that's probably a pretty easy job, that it seems like that's pretty straightforward and all that. I tell you, after having sat there conducting change boards as a program manager is probably a simple thing to do. It's the management fray that goes on behind the scenes and the twists and turns we all have to go through, that's a tough job.

So I view program management from the side of the table very differently now than I used to before I became program management. It's a tough job and there's a lot of things that go on that you're influenced by, pulled by, and have to deal with, that's not apparent to the average support person who's sitting on the side of the table. I have a whole new appreciation for that as a result of having been there. Probably shouldn't be that way, but that's the way it is.

Rusnak: That's true. Well, if we could pause for a minute, because we need to change our tape.

Aaron: Okay. I've been talking about Space Station in terms of how organizations had to divide up work and work together and so forth, and so as a result of working in Space Station about '84 through '87, the Space Station program was moved to Reston and I found myself moved off to work the exploration program, Mars exploration. Through that process I wound up replacing Sally Ride when the decision was made to transition Mars exploration planning from an ad hoc committee approach to a line organization and institutionalize it at NASA headquarters.

Dr. [James C.] Fletcher was the administrator at the time, and so I went to headquarters, became an AA [associate administrator] for exploration, and started putting together my thoughts on how do to Mars and lunar exploration. The first thing I noticed about headquarters was, of course—and I suspect it was very much different—my first thing I did was, well, in order to do exploration since I'm working for Dr. Fletcher, I need to have access to Dr. Fletcher. So I asked the other AAs, I said, "I assume that you all have periodic status meetings with Dr. Fletcher, because I'm thinking about setting one up and I'm wondering what you call them and so forth. I assume you have one-on-one tag-ups periodically."

All the other AAs, as we were sitting down in the little cafeteria up there on the seventh floor of the NASA headquarters building, said, "No, we don't do that." And I thought, "Now, that's kind of interesting."

But I went ahead and set up, I think every two week or a week review with Fletcher, because since I was going to start working, laying out the programs, I was new in town, I felt I had to have his portfolio if I was going to go work with the centers and try to get work out of them, and if I was going to represent myself and NASA the agency to Congress, I at least ought to figure out, make sure I knew what the party line was and all that, because those were very dicey times about exploration, because there was a large sentiment all the way back to the [Richard M.] Nixon administration, is that NASA's just about staying in little Earth orbit, going to the moon and Mars; it's not something you can talk about.

So I started meeting with Dr. Fletcher, and I had a small group of ten people I had organized into my little organization, and my management theory was that I didn't want to have more than ten people. I wanted just enough people to orchestrate this thing, but I didn't want it to be an organization large enough to be a threat to anybody. It turns out that's very key about an organization. You want just enough to do the work and keep the system honest if you're at the executive level, but if you can, don't get bigger than you need to be, because people will perceive it as a threat. As long as you're small, nobody senses you're competing with them, and if you're going to get cooperation with an organization, you don't want that kind of competition threat. So I had a little group of ten people and I was getting my message from Dr. Fletcher periodically.

The dialogue, myself and Dr. Fletcher, always went kind of like this. There had been a number of exploration studies about how to go to Mars, and, of course, from a mathematics and trajectory standpoint and with certain kind of technology, there's not too many different ways to go to Mars. It's been pretty well figured out. You can adjust the decimal places here and there, but basically if you're talking about chemical rockets, there's a certain way you're going to go to Mars.

So I tried to bring the perspective to the agency that says I wasn't just necessarily going to go off and polish the next study and polish the digits about how to get there; I was going to try to work with each one of the NASA centers and organizations to see if I couldn't co-opt the NASA centers and organizations into having each of their initiatives synergistic with that objective. And that was based on my perception at the time—and I think it was true—that the biggest obstacle of going to Mars was inside the agency itself, that we may have difficulty selling this program, but if we don't sell it inside the agency and get everybody working together toward that, then we haven't got a chance outside the agency, because as each of the major AAs went out to brief Congress and so forth, they had been kind of laboring under this fixed-sized pie. Of course, they would try to go modulate the politics behind the scenes, I found out, and increase their size at somebody else's expense.

So Dr. Fletcher kept trying to drive me in the direction of, "John, when are you going to have the next study done? When are you going to have the next study done? When are you going to have me analysis about what it takes to send one person to the moon, two persons to the moon, three persons?"

And I kept talking to him about what I was doing to get the agency to cooperate by taking each of the initiatives and demonstrate how they could be synergistic with that, because I didn't have but a very small budget at that time, so I was kind of under the mercy of what I could co-opt them or cajole the Code Ms and the Code Es and the Code Ss to go to—finally he was getting frustrated with me, because every time I went to see him every month, he wanted to know the results of my study, and here I was talking to him about this organizational concept for NASA, and the fact that I'd been around all the centers and places.

He finally stopped the meeting one day. He said, "John, stop. You know, I've been wondering what's going on." He says, "But I have finally figured out what you're up to." He says, "You're not working on refining how to go to Mars; you're working on how to integrate this agency." And he says, "If you're going to work on that, we need to get some more people involved in this meeting." He says, "I need to get Dale [D.] Myers in here. I need to get the AA." Of course, that was just music to my ears. But it was kind of a fundamental revelation finally about six months into this that my approach was not just going to be to go polish the digits about how to get there, but it was to how to get the agency working together and then maybe through that process we could then talk with one voice external to the agency.

Dr. Fletcher was an interesting guy. You know, he came back to the agency primarily to help us recover from the Challenger accident, and he was totally focused on that when a major controversy associated with the Space Station blew up in his face. He brought back [Gen.] Sam [Samuel C.] Phillips to do a study about what to do about Space Station in terms of what it is and how it's managed, and Sam Phillips made his tour, with Chuck [Charles W.] Mathews, around all the centers, and went back and concluded that we ought to divide the program up totally different, that we ought to go inside outside. Everything built on the outside would be built in one center, and everything that's inside ought to be built by another center. We called it the Inside/Outside Option. And that we ought to move the program management to the Washington, D.C., area. That was building back on his Apollo experience, because I believe Sam Phillips' [unclear] organization was in L'Enfant Plaza in the sixties, separate and distinct from NASA headquarters, so he thought it ought to be in the headquarters area, just close enough to have good communications, but just far enough away to not be overly influenced by the day-to-day whiplash of the political environment.

So when that was announced, of course, that energized all the politics around the center as well as other centers, as well as all the delegations, congressional delegations, which caused a hearing, a major hearing on the [Capitol] Hill. I went up to participate in that hearing. Of course, I was from Texas, and of course they always kidded me in Washington, D.C., about being from Texas.

I think that day that that hearing happened because there was a hearing on the Space Station in terms of the fact that the way the work was going to be redistributed, why are we doing this, why is this the right option. I'll never forget that hearing lasted almost all afternoon.

I was sitting there and there was a person who worked in political affairs for NASA, named Mary D. Kerwin. I don't know whether you've met Mary D. or not. Of course, Texas is a long way from Washington, right? Particularly inside the Beltway. It so happens that afternoon I think every congressman and every senator from the state of Texas came through and made a statement. Well, you can imagine how many that is. It must have been twenty or thirty. I forgot the exact number. It was after one after another. Of course, their concern was a lot of work had been taken away from the Johnson Space Center and, therefore, the state of Texas. Mary D. Kerwin finally leaned over to me about fifteen into it, and she says, "John, you're from Texas. Just how many congressmen and senators do you guys have down there?" [Laughter]

Well, the upshot of all that was that the Congress called for standdown on Space Station for ninety days. They absolutely stopped our work and told us we had the wrong answer, and told us to go back and redesign this thing. Well, it's interesting how Congress viewed what had happened, particularly the Texas delegation. They viewed that since the insides had been redistributed to the Marshall Space Flight Center and the Johnson Space Center was going to build the outside, and since the crew lives inside, that obviously—this is really interesting—obviously the command and control of the Space Station, which had always been, you know, the expertise of how to come in and control a Space Station was always in Houston, right, in mission control, that this option was transferring command and control of ISS, of the Space Station, from the Johnson Space Center to the Marshall Space Flight Center. That was what all the flap was about. Well, that's the way the flap was articulated.

So I came up with an innovative idea and it also solved a technical problem at the time, in that we had these things called common modules. Not only did the pressurized module—no, I don't have a picture. Not only did the pressurized module have the cylindrical volume aspects, but in the side of each module was a docking mechanism so that you could plug these things in, in a pattern, that this one plugged into the side of this one, and this one plugged into the side of that one, and you could make a racetrack out of it.

That's a neat concept except for two things, technically. One is, we never could visualize in space how you put that last piece together. A little difficulty there. The second thing was, by the time you built the module and built all these berthing mechanisms into it, it was so heavy you couldn't launch it. It was very heavy.

So I came up with the idea and collaborated with Aaron Cohen, I said, "Aaron, we can solve this technical problem with this and also maybe solve this perception problem with the congressional delegation by creating these nodes. Why don't we take and build a pressurized volume here and we'll make it kind of round, and we'll put a node between each one of the modules. That way the modules can only have one mechanism on the end, and this node will give you volume. In fact, we could arrange the modules so they contain all the experiments and all the research equipment, and we could put the command and control stations in these nodes. And JSC could build the nodes, we could outfit them with the command and control. And then since the Marshall Space Flight Center is used to building laboratories like Spacelab and Spacehab and Skylab, they could build the laboratories."

So I went to Washington and proposed that, and Andy Stofan [phonetic], he jumped on the idea, because he was the AA at the time, and went over to see Dr. Fletcher. Well, by that time all the dynamics had changed, so the idea was quickly—I said, "Oh, wait a minute. Wait a minute. We've got to go to an independent center called Langley and get this configuration confirmed."

So JSC didn't get to participate much in that rearrangement. It was assigned to Langley, which, of course, was considered to be a neutral center, to make sure that was a good engineering solution. And sure enough, they confirmed that to be a good technical solution, so when they presented it back to Congress, that they'd come up with this technical solution which solved a number of problems, but also returned command and control back to Houston. [Laughter]

Rusnak: That was quite an innovative solution.

Aaron: And, of course, the nodes still live today. Option A—there's another interesting epilogue to this story. Option A, the one that was a part of the A, B, C discussions in '93, one of their redesigns to save money is they went back to this common module that had this racetrack pattern with all the docking mechanisms integral to the module, because that saves you the node structure and the node outfitting. Well, fortunately, Option A had to go through the same process of learning that it's too heavy to lift, and so if you look at the configuration today, it's got nodes in it. It's not in a racetrack. [Laughter] You know, what goes around comes around, right? This agency sometimes has a short memory.

But Dr. Fletcher, he was totally ambushed that day in the congressional hearing because of the fact that a fundamental change had been made and it stirred up—not only introduced technical problems, but it stirred up the whole—I think we stood down for ninety days. So that gives you a feel for how steeped into—how much Congress was dictating the configuration of the Space Station.

In fact, that's one thing that did improve. Back in the '84 to '89, '90, '91 time frame—I skipped a chapter that causes great difficulty. We had congressional staffers telling us how to design Space Station. The interesting background on that was, it's almost back to this zero-sum pie, zero-sum game. In that time frame, I don't think as much today, but in that time frame, there was this debate certainly outside the agency and inside the agency, I call it the manned/unmanned wars.

If you were part of an unmanned research community, the perception was that your programs were always being cut and always being curtailed because these manned spacecraft—and probably today you'd use a different term; you'd call it human spacecraft—but I'm going to explain this in the terminology that was used in the eighties. The unmanned spacecraft were being curtailed and truncated at the expense, as a byproduct of the manned spacecraft, that the manned spacecraft of these big programs, that took all this money, and they were just the big hogs at the trough, so that's when the debate started that you spend your money much more effectively if you spend on unmanned projects.

Now, the interesting thing about that, though, if you go back and look at when the unmanned programs did their best in terms of money, it was always when the big manned programs were working. The unmanned programs had more money during Apollo era than they've ever had since. In fact, that's kind of where the 20 percent rule came from, that unmanned programs in NASA in those days get at least 20 percent of the total budget, because that's kind of what happened in Apollo, trying to get back 20 percent.

So we had this unmanned/manned war going on. Well, when Space Station came along, it was a human spacecraft, manned spacecraft. In fact, that's what space stations are about. They're not about unmanned spacecraft. That was our viewpoint, at least. But we had the appropriation committee in the House who were determined it was first going to be an unmanned spacecraft, and wrote language into the bill about what unmanned capabilities we had to have before people could be on there, could live there.

Well, that caused us technically all kind of difficulties, because that just laid another set of constraints on the table that, from our standpoint, said you've got to build a space station backwards, and makes it much more difficult to build, because we couldn't put up a pressurized module first. We had to put up an unmanned set of platforms first with a certain amount of power and capability, and then once we accomplished that, then we could add a pressurized module. That's just one indication of the amount of technical drivers that we were getting inserted right in the middle of our design process.

Now, that changed. One thing that happened that was fortunate about that is that when Alpha came along in '93, that changed. There's not near as much direct engineering instructions in the congressional language as there was in the Dick Mao [phonetic] days. I'll go ahead and mention his name. I mean, one of the primary drivers of that was a staffer named Dick Mao, who worked for the House appropriations committee.

You know, you can add so many engineering constraints onto a design that you become over-encumbered with constraints and therefore you come up with a very inefficient design. That's just an example of the environment we were in. We had to worry about what it cost, who was going to build what piece. We had instructions from Congress about what sequence to put it up in. I mean, it was just on and on and on. Constraints are good, but you can get too many of them.

You know, 8 billion is—did anybody ever talk to you about the 8 billion dollars and what was magical about 8 billion dollars?

Rusnak: No, I don't believe so.

Aaron: Let's save that story for another day. When Space Station was first put on the table, before we even knew what it was, it was ordained it wouldn't cost more than 8 billion dollars. We were two year into the program before Neil and I really realized. Of course, for the first—I'll back up just a second. For the first couple of configurations that were arrived at, they never did fit 8 billion dollars. We always came back to this number. Neil Hutchinson and I, he was program manager and I was deputy, we were two years into the program before we finally figured out where 8 billion came from. And I'll share that story with you on another day.

Rusnak: Leave us in suspense?

[End of interview]