Publications Topics:

Books

ASP Conference Series

Monograph Publications

IAU Publications

Books of Note

Purchase through the AstroShop

Journals

Publications of the ASP (PASP)

Magazines

Mercury Magazine

Archive

Guidelines for Authors

Order Mercury Issues

Mercury Advertising Rates

Newletters

The Universe in the Classroom

ASP E-mail Newsletters

Special Features

Astronomy Beat

Contact Us

Mercury, July/August 1995 Table of Contents

George S. Musser, Astronomical Society of the Pacific

(c) 1995 Astronomical Society of the Pacific

If NASA, science, and the aerospace industry don't work together, they may not be working at all. Managers have to give people room to excel; scientists must be realistic about cost; engineers need to solve problems rather than defend turf. Lunar Prospector is trying to put these principles into practice.

"Faster, better, cheaper" has been NASA's mantra since Daniel Goldin started to reinvigorate the space agency three years ago. Like "world peace," it's a goal that everyone agrees with, but no one is sure how to achieve. Domenick Tenerelli at Lockheed Martin Missiles and Space Systems in Sunnyvale, Calf. knows this more than most. Tenerelli was chief systems engineer on the Hubble Space Telescope, the most expensive robotic science spacecraft ever built. Now he is project manager on Lunar Prospector, a bargain-basement lunar orbiter in NASA's Discovery program.

People have long complained that NASA is a bureaucratic bog with no clear sense of purpose. Many of these complaints seemed unfair: The Apollo program set such a high standard for excitement that other programs inevitably look boring. Besides, alternative ways of working were few and far between. But the imperative to do things differently is greater than ever. Nowadays, if programs don't stay on schedule or within budget, they don't get more money; they get canceled.

For years, Tenerelli has been talking about how the space program has gone wrong and how it might be put right -- at the Space Telescope Science Institute in September 1989, the Ames Research Center in December 1994, the Jet Propulsion Lab in April 1995, and the Aerospace State Association, a group of state governors, in June. He spoke with Mercury in June.

Maybe you can tell me about the "standard method" for building spacecraft.

In September 1989, I was asked by the Science Institute to make a presentation on the relationships between NASA, science, and industry. I drew three circles with barely an overlap, and said that you have three power structures with their own agendas.

Industry views NASA as an organization that has considerable oversight over a program and, because of that oversight, increases costs and impacts schedule. Industry views scientists, at times, as being irrational: lacking sensitivity to what it means to meet cost and schedule. Scientists tend to view industry as an organizational structure looking for profit and, therefore, if the costs of a program increase, so be it. Some feel industry may carry out efforts in order that the program costs increase. NASA views industry as a power structure in competition with itself: that industry may be trying to take over responsibilities that NASA should have.

Of course, NASA is within government, and bureaucratic structure develops within NASA which is considerably different from industry. You have two major cultures acting in a manner that makes it difficult to meet schedule and cost. The science community can increase its power by going to groups that may be sympathetic towards its cause. It could be congressional people. Sometimes there are Nobel laureates who have influence right up to the president of the United States....

What happens when you have these power structures? It limits the amount of teamwork that you develop. It affects the cost, schedule, and performance of vehicles. And we have a lot of examples: Hubble, Mars Observer, Galileo, Gamma-Ray Observatory, maybe more. Somehow in this system, you're distracting people from what they should be focusing on. It gets to be a study in psychological behavior: Not only the major entities, but also the engineers who do the work, are not constantly thinking about how to make this program successful.

With the "standard method," we've built up these three major entities, and within each major entity you have power structures.... If you've got a program like Hubble or GRO, you automatically have brought in Johnson Space Flight Center, Kennedy Space Flight Center, plus your lead center, which may be Marshall or Goddard. And then you have NASA headquarters. Within industry, you also have organizations that have parochial views: Systems Engineering, Design Engineering, Integration and Test, Quality Assurance, Program Controls. They all develop their own turf barriers.

What were the power groups in science?

You had a Space Telescope Science Institute on Hubble, and then you have major organizations -- for instance, with the Wide Field Planetary Camera, Caltech and JPL. You'll have a NASA project scientist. You'll have the individual Principal Investigators, who are very parochial about their science.... One of the problems with science is that it's fragmented. They may get together as a Science Working Group, but one has an instrument, the other one has an instrument, [and so on]. The success that group achieves is totally dependent on the breadth and understanding of the chairman....

How do the groups interact in the "standard method"?

Relative to NASA and industry, you'll always have an engineer or project manager in NASA who is a point of contact to the industry counterpart. If there's a point-controls engineer in industry, there's a point-controls engineer at NASA..... You had this tremendous oversight, almost one on one. It was very extensive, a lot of people who had their own agendas. Suppose you're a battery engineer. You might have a battery engineer at NASA, who may call once, maybe twice a day. He may want a number of reports, which may or may not be of use to the program. He's on the phone constantly, or visiting. "Where's that report that was due? Send that report."

Does it interfere with your ability to get things done?

It's there all the time. You're going to have constant telecons. You'd like to see the approach of one of the NASA people I worked with through the years, Gene Oliver [the former chief engineer on Hubble]. He used to say, "Domenick, don't show me anything. Don't contact me, I'm not going to contact you. Finish the job, and then when you're satisfied, then I want to talk to you." Now that's the ideal situation....

Where you get the interaction between the groups is in an Interface Control meeting [to prepare the formal mission specifications]. Then you do bring the science community, NASA, and industry together.... You can do it: You can get this communication going on, but it takes quite an effort. And it just stays at the interface between the groups.

In the organizational structure for Lunar Prospector, we actually are helping each other right into the designs of our particular hardware. For some of the instruments, Lockheed is going to provide the thermal controllers for [the science team]; we're going to do some of the structural design for the spectrometers. The Berkeley scientists have come back and done some excellent work on how we should put together the command/data handling subsystem [the computer that controls the spacecraft].

What would have happened in the "standard method"?

It never got that far. I can't say what would have happened if we'd ever had them coming in here and making recommendations on how to design a command/data handling system. Or us telling them: "We'll take on the thermal control responsibilities of that instrument."

With Lunar Prospector, all the problems become everybody's problems. You have a leader, but all see what the problems are. They become part of how we solve the problems. Of course you have to make the tough decisions, but we make them as a unit. Everybody understands that this is our total cost and this is what we have to do. So if a scientist says, "No, I can't meet that schedule," we present to him: We have a launch date, we have to get 2,000 hours of test, here's the date that we have to provide the instruments. If you can't meet that date, what's the work-around?

On the one hand, you imply that the "standard method" didn't have enough communication. On the other hand, you say that NASA was always asking for documents. Wasn't that a form of communication?

You see, auditing is only a one-way thing. I give information to the person that's auditing me. This isn't an open forum.... Somebody could audit an instrument and know what was happening on that instrument. But other scientists wouldn't know..... As far as truly understanding the design of the spacecraft, the Science Working Group really had very little insight. When you finally have a review of the complete design, you're presenting the design of a control system over a half-hour. I can assure you that there is no way in a half-hour that somebody in that room is going to understand how that system operates.....

Now, I will say this: People made attempts to try to keep the science community involved, especially when they started to get very vocal that they didn't know what was going on in the program. That's why they established the Space Telescope Optical Performance Analysis Team....

In the "standard method," it takes a special effort by somebody from the science community to know what's happening in industry. Here [on Prospector] we'll tell a scientist, "You want to see our command/data handling subsystem? Look at the whole design." They helped us with the design.....

So science felt that industry and NASA weren't telling them what was going on. Did industry and NASA feel the same about science?

No. Generally, industry thought that scientists were a group that you tried to stay away from. In general, right up to this new era, NASA people got very concerned if industry was talking to the science people....

So you've witnessed the parochialism on Hubble, and you intend for Lunar Prospector to get around that?

That's right. You have to learn how to give people total responsibility. On the work breakdown structure [the division of responsibilities], we say that anyone who has control over one of the blocks has total responsibility over that area.

Is that different from how it was before?

Considerably. Let's say a person was responsible for the attitude control system, all of its hardware. We had subcontract managers for each major piece of hardware. This guy [with the responsibility for attitude control] couldn't even deal directly with the subcontractor to his subsystem. He had to go through a subcontract manager. On budget: His budget was controlled by somebody else. When the hardware was in the shop, an organization called Program Controls followed that hardware. You also had a test group, which wrote the sequences to verify that attitude control system, and the analysis for that data was done by the test group.

In the Lunar Prospector program, the person in charge of attitude control creates an integrated product team. The subcontracts all report to him. He writes his test sequences; he defines the schedule for manufacturing; he follows that hardware through the shop; he's given the budget, he lays it out. So now he's got the responsibility and the authority....

I'm wondering why the old system developed at all.

Because bureaucracy developed. In the '60s they had more of the leadership ability and desire to understand technical things. Kelly Johnson [the famous aerospace engineer who designed the U-2 and SR-71 spy planes] was a person who had those abilities. He developed multi-disciplined people. They could work with each other.

But in the early '70s a different philosophy was adopted by a lot of people in both industry and NASA: "I'll just manage people." The people who got into better positions didn't have the ability to judge technically. Now, if I lack the technical abilities, what happens? A good-old-boy club develops. Some people didn't have the independent knowledge to make decisions and therefore you got, "Well, if I do something which affects this particular person, then, geez, he might come back and hurt me. How do I make sure that I've covered myself?"...

If suddenly you're not part of the consensus, but you're taking a position that's different, then you're viewed as a person who's not taking on a position that other people feel is the right position.... You're getting into some deep things here on what can cause the destruction of major companies. When you have management structures like that, then the talented people no longer necessarily rise to the top, because it becomes very politicized. "Am I taking the position that someone else is taking?" The culture becomes politically motivated, as opposed to purely technical....

The manager sees everyone is developing their own empires. He wants to have as many people under him as possible (or she, usually it was he). There're going to be layers of management. In this Lunar Prospector program, there's only one manager: me. You know what you'd have in a normal program? There could be 20 to 40 managers.... You minimize turf barriers once you minimize the number of managers. Everyone has their opportunity to either accept or criticize. It's a very open system.

So there can be no accusations of "I didn't know" or "Somebody hid it from me."

Unless there's incompetence. These systems are successful as long as you're dealing with competent people. You have to have talented people. That's what made the Skunk Works [Kelly Johnson's Lockheed division] a success....

A person who comes into the organization, how does he get to the top? There is no clear path. He has to love engineering. He wants to make sure that carrying out a successful engineering job is the most important reason for having a job, versus a person who is going to say, "I want to become a vice-president." The person who wants to become a vice-president has a different agenda in life.

What's an example of things the management/promotion-oriented person will do?

I ask young engineers, when I'm interviewing them to come into my organization, "What do you want to be?" If they tell me they want to be an engineer, I know I've got somebody who can work within the culture I want to develop. If he tells me he wants to be a vice-president, I know I have a problem. One young engineer asked me, "If I come into your organization, how many people are going to be reporting to me?"

The engineer who wants to become an outstanding engineer says, "I want to go down to the shop and make sure that they're manufacturing my parts correctly." He talks to the people in the shop, he gets with QA, he sees how he's affecting other parts of the subsystem. If the goal is, "How do I become the chief of the program?" then he'll get involved in things that'll distract him. I've had people say to me, "Oh, geez, I want to be part of that meeting, because so-and-so VP is going to be there."

Does it happen a lot with people?

It happens when you develop strong bureaucratic systems, if you show a path that leads to supervisor or division manager.

Of course, that [the lack of layers] could be a problem, too. A young engineer coming out of school, he may want to see that path. He wants to make decent money sometime. So what do you have to replace it? There's got to be some reward for them, some recognition for their talents. You have to pay them well; in their pay scale, they've got to be at the top. And you've got to make sure they get recognition as far as rewards are concerned. You've got to promote to reward them for their performance accomplishments, as engineers.

As opposed to being advanced to the next level of management?

That's right. You've got to find something to replace that. Make sure that you encourage them to take training programs, and that they get accepted into the program. Encourage them to go for their master's degrees, their Ph.D.s, and once they get it, reward them again. Increase their salary....

What happened in this business is that people became specialists. If you were a communications engineer, that's all you did: communications.... In a Skunk Works-type of philosophy, an engineer has to be very systems-oriented. He always has to be thinking about what happens to that other person.

To what extent do you think the multiple layers of management grew out of the complexity of the missions? It would seem that complex vehicles would require complex management structures.

Don't forget now, on Hubble, we had a systems engineering organization, which actually did a lot of other things. We ended up doing key elements of test planning. In the controls area, we were doing all the analysis for the spacecraft. We were doing an awful lot of the operations work, even design engineering. We had the responsibility for designing and building hardware for what was generally considered part of test and integration. Why? We had a very efficient organization. You can have one or several Skunk Works-type environments even in a big program like Hubble. There were no series of managers in my systems engineering organization....

The Skunk Works model, you feel, can be implemented regardless of the size of the program?

I recommended it for [a certain large program].... How do you implement it on a bigger program? There are some basic ground rules. You've got to have competent people and they've got to be "projectized." That means they are part of your group. Unprojectized is: Let's say I have a subsystem specialist. He's part of a matrix organization, so I borrow him for a period of time. His true boss is not the program, but somebody in some other organization. His loyalty is split.

In the "standard method," the accountability came about from the auditing. How does your system have accountability? Say, if someone doesn't perform, you fire them?

That's right. You have to be demanding. There was a statement made about the "standard method" that 90 percent of the work was done by 10 percent of the people. But in NASA's "faster, better, cheaper," you only can have people who are efficient. Not only that, but they stay in there and do an awful lot of work on their own. Everybody's a worker, no watchers....

How do you have outside verification? How do you make sure that that hardware's really working?

When it's on the vehicle and you check it out according to the requirements.... When you do it in a team effort, each PI has to understand the data we're getting back and how we're operating his instrument. So he has to have knowledge of how the command/data handling is carrying out the function relative to his instrument. So there's somewhat of a cross-check there. Then you can have outside peers come in.

How would a peer review work?

You have to bring in experts. You have to make sure get the right experts, who know how to understand a vehicle.... In a lot of cases, they're not necessarily going to have time to go through everything you've done, but they're going to look at the capabilities of the people. A lot of it is going to be based on the judgment of the people that they see making the presentation, or that they may spend several days talking to.

How does this differ from the audit procedure in the "standard method"?

You call the peer review. In other words, I'm going to establish, as the project manager, when we're going to have peer reviews.... But it's not an ongoing process.

And you think that peer reviews can maintain the quality control that the "standard method" was at least intended to do?

Well, I'm not sure you even need the peer review, but I have it just because questions like that will come up. I say that, if you have a talented team, you don't need this. I feel we implemented this in Systems Engineering on Hubble Space Telescope. Look at this: All the responsibilities that we had in Systems Engineering -- which went beyond systems engineering, into design engineering and test planning -- had 100 percent success....

In the "standard method," the documentation that's required of you, the number of reports, it just becomes so voluminous. It's called a Contract Data Requirements List, and it's a huge number of reports that are required. You name it. They'll review it and correct your grammar. Therefore on this [Prospector] you try to only document what truly is important to the program.

Can you give me an example of the information that it would not have been necessary to ask for?

On Hubble we carried out Mini-Flight Readiness Reviews -- a tremendous set of documentation, and I'm not sure that there was one useful thing that came out of it....Another example was some of the systems engineering plans that were put out. Useless....

Some people will require subsystem specs on certain programs. A subsystem spec may be 200 pages.... I looked at one not too long ago, from a major program going on right now, and it was just way, way too detailed. It's like giving directions to the Lockheed plant, telling you every block, go 50 feet, go left on that block. Go down to the second stop light. The first street is 250 feet, the second street length is 375 feet, therefore the total length is 625 feet. Now you make a left on that corner. The speed limit on those two blocks is 25 miles, however the police allow you go to 33 miles per hour, and therefore you should be able to get there in 1 minute 37 seconds. Some of these things I've seen, it almost gets that bad....

On Lunar Prospector -- and this is going to be true even of most large programs -- if you put together a very good contractor end- item spec, which describes the key requirements of the subsystem, then you may not need another subsystem spec....

I was describing the approach of Lunar Prospector to Frank Carr [Goddard project manager on Hubble]. He says to me, "Geez, that reminds me of the very early days, when they showed confidence and trust in people."

We've been talking about the management structure in industry. Some of the comments you raised at Ames last December were directed at scientists: that their overconservative mission requirements inflated costs.

What I said was that -- this is prevalent throughout the whole system -- if a scientist needs a pointing requirement of two-tenths of an arcminute, he may call out a tenth of an arcminute, maybe even less. They'd overstate the requirement. And once the requirement is overstated, that just goes through the whole system. It may add a much more sophisticated control system, which means I'll have to complicate my command/data handling. I probably also need a more complicated safe-mode system on the vehicle. More complicated to test it, more hours to test it, and more complicated to set up my flight command systems once the vehicle is in orbit.

Contamination is another one. I see people calling out very difficult requirements for contamination for science programs, even now, which are unnecessary. They may call out very severe requirements on molecular contamination, but there's no path [for the molecules to get] from the spacecraft into their instrument. It's going to cost you a lot, that very clean system.... Now, on Lunar Prospector, we describe to them what it means: "Listen, what do you really need? And then if you really need something like that, how can we do it without imposing some of these extreme cleaning requirements."

This overstating of requirements, was that a symptom of the lack of communication?

Oh, without question. When I carried out my work on Hubble, I wanted a contamination requirement.... When Bob O'Dell [Hubble Science Working Group chairman] brought up these requirements for contamination, [another key scientist] said, "Don't bother with that stuff. Just tell them to do the best they can."

So I saw Bob O'Dell at lunch break and I said to him, "You can't do that. We've got to have a requirement, Bob. Once we have that requirement, we can implement a contamination control program." In their executive session, he was strong enough to get a sensible contamination control requirement. And it was very successful.

On Lunar Prospector, we have very loose requirements for contamination, because you don't have that type of system. You don't have that enclosure of the instruments; you're not viewing at Lyman alpha. It's got to be magnetically clean, but that's different. That's why we brought a scientist in who understands magnetically clean spacecraft, to tell him, "OK, give me a requirement and how to monitor it."...

It seems that NASA doesn't have a big role on Prospector. Do you think that worries people in NASA?

I don't know. I'd say it's surely worrying the people who don't run a program like this, because it means a very small staff at NASA....

For instance, Ames has Sylvia Cox. She's good to work with. She's hands-off. She'll say, "You know, have you made sure you've let the NASA workers know you may need this from them?" But it's a very cooperative way. She'll say to us, "You know how NASA thinks and how they're planning to put their budgets together. If you give them an input, that protects your money for the next three months."... Mark Saunders and Scott Hubbard [NASA managers for Prospector] have allowed us to run the program in this manner.

How do you keep the competition, between your team and other lunar missions, at a positive level? How do you prevent it from getting into back-biting?

Oh, it does get into back-biting. We have some people right now... on a campaign to kill Prospector. Yet, other people have been contacting us, wanting to work with us; we get tremendous amount of encouragement. We're getting both; I'd say more positive than negative.

How do you reach out to other programs?

You've got to be open with them, sharing things....

I think you have major changes, for example, at JPL right now. John McNamee [project manager for Mars Surveyor '98] is doing things completely different. He's told me that the inputs we gave him have been very helpful on how he's structuring things....

There's an awful lot riding on how we run this program. If we're successful, we then will become the way that programs are carried out in the future. If it turns out that problems occur in this method, it's going to affect things.... We're in the early phases of Lunar Prospector. We're just getting into the details of completing a preliminary design and some critical design reviews. The real proof of the pudding is when you start building your hardware.

GEORGE S. MUSSER is the editor of Mercury magazine. Domenick J. Tenerelli's email address is tenerelli_domenick@mm.ssd.lmsc.lockheed.com.