 Welcome to another in the series of guest lectures on NASA's program and project management. Today we will be discussing management issues as they have appeared in the men's spaceflight programs. Our participants are Aaron Cohen, director of NASA's Lyndon B. Johnson Space Center, Henry Pol, JSC's director of engineering. I'm Joe Loftus, assistant director for plans at the Johnson Space Center. I'd like to begin our discussion by asking each of our participants to briefly talk about themselves. Aaron, would you briefly summarize your career since you graduated from Texas A&M and tell us a little about what you did before you became a manager? Okay, after getting out of Texas A&M I went to the Army from 1952 to 1954 and then from 54 to 58 I was with RCA, Radio Corporation of America and then from 58 to 62 I was with the General Dynamics Corporation and then in 62 I came to the Johnson Space Center. I had various jobs at the Johnson Space Center primarily in the guidance navigation area and managing that activity with the Draper Labs, MIT Instrumentation Lab at that time and then deputy of the Systems Integration Office. In the period of 1968 to 72 I was command service module project manager and then from 72 to 82 I was the Arbiter Project Manager, 82 to 86 I was the director of research and engineering and from 86 to the current time I'm director of the Johnson Space Center. Thank you, Henry. Would you tell us a little bit about yourself? Well, I graduated from Texas A&M too. I was drafting, spent two years in service. I started out as a test engineer on Redstone in Huntsville, Alabama. I worked on the Jupiter on the Saturn. I got in some design work, design the small rocket motors that we put in the wind tunnels up at the telehomba. I came down here, I was subsystem manager on the RCS for Apollo. I was section head from about 64, 65, I can't remember when, to about 67, branch chief from 67 to 79, division chief from 79 to 86 in the propulsion power division and in 86 I became director of engineering. Very good. Erin, would you briefly summarize what you think are the key things that a manager must do to achieve success? Well, I really think that one of the key things is have some, in your career, have some early hands-on experience. But I think you have to start out with saying that the key elements or the exact elements of managing, being a good manager of the programs of yesterday or yesteryear may not be exactly the same key elements of today. So I think you have to take, you have to understand that. I think we have to start with that point. The new program managers, project managers are going to have different pressures than the old one. On the other hand, I do think there are some factors that are common. One is I start off, I think some early hands-on experience is important. Whatever small project they may be, to carry a project through, to see how drawings are made, to see how a design comes about, to see how parts are machined, how you process parts in the factory, how you do the testing, I think that's all very important. If a person can do that, I think you set a good foundation for a project manager. Of course, that is one item I think that's important. The other item I think is key, is very important is you need to be patient. You need to understand people and be people-oriented. You need to be able to communicate with people, communicate with people both in all directions, downwards, upwards, and laterally. You need to be able to communicate, be people-oriented, and make people feel you want to hear what they have to say. I think you have to be able to take criticism. You've got to be able to take criticism and not become defensive and do that type of thing. I think you need to have to know when to compromise. You need to know when to compromise and get a solution rather than argue for a point that you feel that strong. Those, I think, are some of the key elements that make up, I think, the attributes in programs for yesteryear and programs of tomorrow, or similar key elements, I think, in a person becoming a program manager or project manager. What are the major changes that you've seen in the management of NASA projects over the years? Well, I think the two big programs that I managed was the command and service module for the Apollo program. And Henry might want to add a little bit on this. And then the Arbiter, the one in the 60s and one in the 70s. And I think if you had to say the differences are the pressures you may have, both a little bit from the external pressures. If you go back to the Apollo era, I think if you look at the Apollo program, I think you see the key thing you had to do was to look at performance. I think performance was primary, schedule was second, and then cost. And I think those are the three elements, of course, of program management or performance, schedule and cost. And those are the three trade-offs that a program manager has to continually do. I think in the shuttle era, you still had performance was still very key. Still, I would say, number one. But I think cost was an overriding schedule. I think cost was more important than schedule. In the space station era, I'm not sure I can tell yet. I think certainly all three are still very important. And I'm not sure that all the pressures that the space station people are going to have yet have come to bear. I think cost may even override with schedule being second and maybe performance going, oh, Henry, you might want to add something to that. No, I agree with that. I think one of the things that we've gotten into now is that lack of flexibility in cost. You know, Apollo, we never had enough money in Apollo, but we did have a lot more flexibility in how we can use it than we have now. Oh, yeah, in Apollo, I would say that if you had a problem in Apollo and you had a problem, you could go multi-pads to get the solution and then pick the solution you wanted. But you could carry multi-pads for a while. In the shuttle program and the arm program, I think what you had to do in that case was to pick the, not go parallel path, pick the solution you wanted. And you know, with good judgment and good decision making, I hope that decision was right, but not go parallel paths for that long. And I think that's one of the differences. In the shuttle program, you couldn't even continue a program. You had to start it and then you had to stop it because you had to take those funds and transfer them someplace else and pick up and get that one up to the even keel and then go back and pick up the other project and bring it along to keep everything going along on the even keel. And I think the program of the space station there, there's going to be a lot of pressures. And I think if you can keep those fundamentals I talked about in front of you, I think you can overcome those, the new pressures that might come about. One of the things that has been talked about a great deal recently is organizational cultures. How would you characterize the NASA and JSC's cultures? Have they changed? Do they need to change? Well, I think again there's some very fundamental things with culture. I think that at the Johnson Space Center, I think we have a culture that is, I don't know if you'd call it participant management, or there's certainly an interactive activity, interaction activity that takes place in making a decision. We have been left with the legacy that if you have an issue, that you have a concern, you feel free to express your concern. We weigh the problem, we work the problem, and if the answer may not always come out the way people want it, but you're explained what decision you make and you go on from there. I think that the only culture change that I see that may take place is maybe some external environment that says there are more external pressures in terms of overview committees. But even then, if you go back in the early days, we still had a lot of overview committees. So I'm not sure I see a big change except for the one fact at the Johnson Space Center is that we had previously had the one big program of Mercury, Gemini, Apollo. It would come up, then go away. Today we have shuttle, and it's going to be with us for a long time, and we've got space station that's going to be with us for a long time. And then if we go on to the Lunar Mars Initiative, that's going to be with us for a long time. So I think the culture is going to have to be able to accept and adapt to how you handle large multiple programs at the same time. Henry, do you have anything? Well, there's a couple of things that I see that has changed with time and is kind of changing back now. First one, we started out with Apollo. We had a few what I'd call mature people, and then we had a large number of people that's fresh out of college. When the shuttle program started, then we had that experienced team that went through the Apollo program. We learned an awful lot in Apollo program. And now as we start on space station, we're going to develop space station with a few mature people and a lot of young people again. So we're kind of moving back toward the type of organization that we had in there. Well, let me ask you, Joe, what do you think? You've been around. What's your feeling on that? Well, I think, as you pointed out, JSC developed a very unique kind of culture. Outside observers have characterized our decision making as being collegial and have had difficulty understanding why we seem to be able to do it. But I think it's because we've dealt with issues that are very complex, very technical, and in which no one person had all the technical expertise to make a decision. So there was always this collegial discussion, and then the program manager, because he was the appointed decision maker, made the decision. Well, that's a good point. I'm glad you brought that up. The program manager is like the board, the chairman of the board. He has 51% of the vote, and I think that is the important thing, that the program manager has to recognize that responsibility, and you do have to give him 51% of the vote. Erin, one of the things that might be interesting to discuss is why JSC uses a matrix management system. It was fashionable when we were formed in the 60s. It's no longer so fashionable in industry, but we still use it. Well, I think there's several reasons why you basically use a matrix management. You use a matrix management for one reason is if you want a good check and balance on the program. That's one reason why you use it. In fact, I would say that was the reason why we originally used it, was because we wanted to have a check and balance of the various parts of the institution on the program, and that is a very good attribute to have. The other reason why I use a matrix management is because you have multiple programs, and that's the way you handle multiple programs is going to matrix management. Now we're going into multiple programs, so we're going to have to use matrix management for that reason, but the original reason was more for the check and balance. There are some disadvantages, as you know, of matrix management. You don't have the autonomy. The program doesn't have the complete autonomy. As a project manager, I've got to admit, sometimes I was very frustrated with that, but I've got to tell you that as a project manager, I learned to love it because you do have that check and balance, and I think that check and balance is important. Of course, at the Johnson Space Center, I think there's another reason why it could be very difficult for us to eliminate the matrix management, even though some places are getting away from it, is because we have the very intricate interweaving of our operations activity with our design activity, and I think that is probably the only way you're going to be really able to do that is with the matrix management system here at the Johnson Space Center. But I'm not sure that fits all organizations or companies today. Oh, Henry, you have? Yeah, I think, you know, in our situation, matrix management gives us a great deal of more flexibility to use the expertise that you have when you don't have a great deal of depth. You can use the experts on a lot of different programs. You can use them this week on this program, next week on this program, and next month on that program over there as problems arise in each one of those programs that usually don't happen at the same time. And I think there's another message here about management, that any organization can work so long as it's the will of the people and the will of all of the people to want it to work. And I think that's one of the key ingredients to making an organization work. The best organization in the world will not work if the people don't want it to work. And I think that's one of the things that we've been able to do here is to keep everybody with a sense of responsibility, a sense to want to do the job of feeling responsible for making the hardware work. And that's been a key ingredient to making matrix management work here at this center. Joe, I'd like to hear again, I'd like to hear what you have to say because I know you studied management systems for some time and I'd like to hear what you have to say about that. Well, I think that as a government organization responsible for the initiation and the continuing management of programs, we do not have as narrow and sharp a focus as you can create in a business enterprise. And I think the complexity of our task forces us into a matrix management. Well, that's the operations element that I was talking about. Yes. In the context then of this management structure, how would you deal with the various elements of cost, schedule, and performance as they are embodied in the various functional elements that work with you? Well, of course, you hit the key of the whole program management theme of the balance of performance cost and schedule. That is a continuing trade. And that is the, you might say, that is the life a project or program manager lives with from the conception of the program to its end. It's a continuing trade off. And you can never solve, you can never make everybody happy you will never make everybody happy with those three elements. That's a continuing trade off. You know, I used to use a very simple analogy when I used to work with people they'd come to my office and I'd say, okay, now what I want you to do is help me. I would like you to play like for a moment that you're in business for yourself and you can't afford to produce a bad product. So you want to improve it. On the other hand, you're in business to make a profit, and you can't afford to put all this money into it. Now, help me figure out how to do that, how to get that product out on time. So I really think it boils down to that. The one thing that I think you can't afford to do in the man program, and I think it's true in the in the unmanned programs too, is you can't afford a failure. Failures are very expensive. And so the safety and reliability and quality has got to be maintained in that. And so and there's ways to do that. And you can still balance off those three parameters and still get a very high quality, high quality product, reliable product and safe product. So it is a tough job. And there is no closed form solution. There is by there, let me believe me, there is no closed form solution to to that trade off. It is a continuing, continuing trade of those three parameters. We've talked a good bit about engineering. Could you talk a little bit about how you use your program control and your business analysis people? Yeah, let me do that. And let me do that in the context of a term I call avoiding pitfalls. If you go back and you look at the history of program managers and project managers, the first pitfall, the first thing that happens is when you become a project manager, you have euphoria. You know, that's the greatest thing that ever happened to you. In fact, my wife used to say the greatest thing that happened during the day became the Orbiter Project Manager, and then on it was really tough. But it is the euphoria you become. But then you got to avoid the pitfalls. And the first pitfall you really have as a project manager is normally cost overruns. That's the first thing you normally see is cost overruns. The second problem a project manager, a pitfall the project manager has is scheduled. And then normally you'll solve the cost problem by either replacing the project manager or somebody figuring out how to do it and then the schedule is the problem you have to run into. And then of course it becomes the performance problems and getting it done and getting a good product. But getting back to your specific question, I think in that context the project control is the important element in helping you avoid those pitfalls. You need to use your contract as a good tool. You need to have the project control office help you manage that contract. You need to have a good configuration control. You need to be able to have them give you a good budget estimate, keeping up with your schedules. And if you do that, give you that insight, those are the ways, over and above the technical as you pointed out, those are the ways that you could potentially, you have the best chance of avoiding those pitfalls. And I think it's an extremely important element of it. Engineering is good and is important. But believe me, the business management end of a program is vitally important to the success of a program. Henry, perhaps you and Erin could speak to the subject of what should be the proper relationship between the government engineering organization and program management organization and its contractors. Yeah, but could I come back to the last question for just a minute on program control? Sure. You know, one of the things that you find about engineers is that engineers for some reason do not like to deal with budgets. They do not like to deal with costs. They'll deal with schedules fairly well, but they don't like to deal with budgets and costs and frequently don't keep track of the effort that's being produced per length of time that they're working on it and their cost will get out of hand. And I think that's one of the key areas where a good program control office comes into play is they tend to keep the schedule, the budget, and the balance of the program in proper focus. Okay. Do you want me to take a shot? Let me answer that other question because I've been thinking about it while you. I think if you go back to the Apollo 204 fire and this thing always sticks in my mind, there was a statement in the report that said that, and I'll paraphrase that in doing spaceflight, human spaceflight, you have to overcome a hostile external environment and to overcome a hostile external environment, you need teamwork. So I think that's the thing. You need a teamwork between the contractor and the government. I don't think there's any question about that that you need teamwork. On the other hand, you need to have a plan, an implementation plan that you can award the contractor when he does a good job, but you also need to penalize the contractor when he does a bad job. So I do think you need teamwork and to get a good, safe, reliable, efficient product, but you do need a way to penalize him when he doesn't do a good job and award him when he does a good job. Yeah, the only thing I could add to that here would be that you both need a good understanding of the product that you're going to produce. You know, you both need to be working toward the same game plan, and both parties need to understand that very, very clearly. And that's what you mean by teamwork. Yes, that's right. But you've got to have that. It's very, very critical. And also to the teamwork, I mean the fact that the way NASA operates, and I think that's typical at all centers, we do pride ourselves, and I think we justifiably so, that we do have a technical capability and technical excellence. And many times we have the technical capability because of our facilities, because of the way we have done things, that our technical capability, I think, and sometimes tends to be in selected areas greater than some of our contractors. In some areas our contractors have better technical capability than we have, and I think we need to know how to utilize both of those to full advantage. That's especially true, Erin, in those areas where we've had the opportunity to go through several programs in sequence, and then you've got another contractor that's a new owner on the street. Erin, how would you like to talk for a moment or two to the subject of the relationship between the program office and the institution of the center itself? Well, of course, with a matrix management system, they're very intertwined. You know, you can always argue, are the programs here for the institution or is the institution here to serve the program? And I think it's a little bit of both. I think that as we stated before, there is a support from the institution to the program. If you look at the Johnson Space Center specifically, we have basically an engineering organization under Henry, we have an operations organization and a science organization, and then we have the supporting functions. And those are all matrixed, you might say, support to the program manager. And as we said before, he gets inputs from that. There's a check and balance where the institution does support the program manager, but you do have to say that the program manager, you have to give somebody that rain and the program manager, if he fulfills the criteria, I said that we start off this discussion on, if he fulfills that criteria, he's justifiable having 51% of the vote and making the right decision. Henry? I think I could even make a stronger case for the 51% because if it was not for the programs, you would have little need for an institution because our total endeavor is in support of the projects or the programs at hand. And it's a matter of how you go about doing it. Well, that's right. Erin, it might be good to take a couple of cases in point. What was your most trying decision during Apollo? Well, there were a couple, Joe. And then I'd like to, you and Henry were there too. There was a couple. One, I remember very distinctly, which I probably learned one of my biggest lessons from was, I think the admission was Apollo 11, but I think it was. There was an inertial measurement unit that was a little bit out of spec, not much out of spec. And we were thrashing around whether we should remove that inertial measurement unit. And if you know, the lunar module was pretty flimsy, and I would say flimsy, but it didn't have a very hefty structure. It was on the stack, out on the pad. And we had to make a decision whether we should replace that inertial measurement unit or should we live with it. And we went to, we talked about it a long time. We went to George Low and we really recommended, gave him all the data, but we came up with a recommendation that says, we really should not change that IMU out, the inertial measurement unit out. There's a risk in doing it. We can live with it. And he thought for a moment and looked at us. He said, if we can remove that issue from the equation, we ought to go change it out. So I want to go change the IMU out. So that was a good point. That was a good lesson that I learned and always keeping the back of my mind. The other one was one, I think it was, I don't know if it was Henry or one of his people in the propulsion area that came to me. And that was on Apollo 8, where we had this issue on the injector of the SPS engine, where we found that that's a long story. We found that if you fired the injector dry with both banks of the engine that you could have a detonation and essentially cause a pressure spike and damage the chamber. And I have one of Henry's guys, or Henry bought it to me. And here we ready to fly Apollo 8 to the moon, first time we ever left the Earth's gravity going to the moon. And the way we were going to do it is we were going to fire both banks of those engines when we got into lunar orbit so we could be sure we got into a good burn. And that could have been a bad, that's the way the process was set up. So these guys brought that to me. And I got pretty excited about it. Here was the 11th hour and I had to figure out, but they came to me with a solution. They said, what you could do is you could fire on the way out, you could fire out of plane, just wet the bank with one engine and as you go fire the other bank with the other engine, get back in plane, not destroy your free return trajectory and have both banks wetted so you can fire both engines be safe. But I was the one who had to call George Low, tell him that, that at the Cape. And that was an interesting experience and I did that. But I think the message there was that, and I think there's a very key message there. And I think that's probably one of the most important lessons to learn. And that is that you should, a project manager, or a manager, should give the feeling to the people that he works with that they can bring him problems and they can bring him any kind of problem and that he's willing to understand that and work with them to a solution. And so that was a very healthy situation. I think if you can instill that type of feeling amongst all your people, I think you'll be very successful. Henry, how do you try to create that sense in your subsystem managers? You do it by giving them a feeling of responsibility. That it is their responsibility to make absolutely certain that their hardware is going to fail. It's going to work. If they feel like it's going to fail, it is their responsibility to bring it forward. And it's not always pleasant. One of the most difficult things sometimes is going to tell your boss something that you know your boss is not going to like. I can remember when this, excuse me, one night they called me at home about 11 o'clock at night and told me they had a pop in the command module when they were servicing RCS. And I was out there a few weeks before and the tanks were creaking and popping and I didn't think too much about it. But the next morning I walked in and told one of my engineers that they had a pop in the tank and he said, shoot, they pulled a standpipe in too. He says, I just ran those calculations last week. They pulled a standpipe in too. That was the one where we pulled the command module up. We didn't replace the tank on it. That wasn't the pleasant thing to have to go forward and tell somebody that we thought they pulled a standpipe in too with no way to get in there. Sure enough, they did. They pulled it in too. But that is a good, that's the right way to. I can give you another if you got just 10 seconds. Another good example. On the RCS tanks, they were made out of titanium 28 days into a 30-day test. One started leaking, very small leak. They cut that piece out, analyzed it, said it was caused by a fingerprint. That paper came across my desk. I looked at it. It looked fine. I signed it, sent it on its way, sent one of the engineers out to look at those tanks. He came back says, Henry, we can't let them get away with that. That was not a fingerprint. I said, why? He said he'd take a monkey to get in there, put his finger in there, make a long story short. We wouldn't put 10 tanks in test after much arguing over it, but he wouldn't give up. Every day he came in at least once. He says, Henry, we have to do something about that. That was not a random failure. And so finally I got the nerve to go forward and tell the program manager that we had a problem. And when I did, we got 10 tanks in test and 98 hours in the test, three of them blew up, just broke wide open. Of course, then you didn't have to worry about it anymore. We fixed it, but it is through his integrity and his concern and him not letting it die that kept us from having a problem on the first Apollo flight. And somehow that needs to be reinforced every day of every week. If you don't do your job and you don't do it good, the bird won't fly. And so I see that as one of our major jobs as managers, is to convince the people that we're working with every day that it's their responsibility to understand their hardware. And if they see something that they feel is not right, bring it forward and talk about it. If you don't get the answer you want that day, you bring it forward again and try to convince the people that you're right. In the final analysis, if after you do that two or three times, then you go back and you do it the way that you've been directed to do it. But you make every effort to convince them that you're right. We've taken some examples from Apollo. Do you have one or two similar cases in the shuttle program? Yes. Of course, the thing we didn't talk about, which I think is important, is decision making. And decision making is very important. And timely decision making is even more important. And by definition, by timely decision making, I don't really mean that you have to make a decision right away. It's got to be timed properly. Sometimes it's right away and sometimes you wait. And sometimes you don't always have all the information you need to make the decision, but sometimes you need to make the decision without all the information. And the fact that you've made a timely decision, the fact that you waited, you have a good chance to be right. A couple of items in the orbit program that come to mind. One was early in the program, we had to decide what type of landing system to use. And it was a technology issue, which we were going through in terms of what was the right technology to pick. And we were looking at that time back in the early part of the program, the 72-time period, whether we should go with the microwave landing system. Now that to make the decision today would be pretty straightforward. But in that time period, it was pretty hard to decide whether you should go with the microwave landing system. I didn't have all the information. You know, I didn't have it, but I thought it was timely to do it. And we, I didn't really want to pay the money to pick up all the technology development and take that risk. On the other hand, the performance looked awful good. So weighing that, I made the decision to go with the microwave landing system, and it turned out to be the right decision. We went with it. It's been very successful, and it's been one of our better systems. Another one is, we were arguing one evening about, that reversed on me. This one was a good decision. We were arguing one time about the number of structural test articles we needed, and my budget was pretty tight. And the engineering people came in and said, we needed, I forgot how many structural test articles, and I looked at the budget that it would cost to do that, and I said, no, we're going to cut five of them, three or four, five or something like that. And I made that decision. Now it turns out that it was a timely decision. They came back to me about two months later, and they really had a very good technical briefing of why technically, from a safety point of view, they really needed the added articles, and I put them back in the program and didn't hurt anything because I didn't make a timely decision, was able to pick up those added test articles. That ties in two things. One, the people weren't afraid to come back, as Henry pointed out, to tell you that you were wrong. And number two, I made a timely decision, which gave me time to fix the problem. So I think there's two ends of the spectrum. And I think, Erin, that's one thing that we have to be constantly balancing against a correct decision. You know, sometimes we can get in the trap or a mode of feeling like we might make a mistake. And a lot of times the greatest mistake of all is not making a decision. Well, I think that's right. And I do think the other thing is, I think you have to be able and be able to accept the criticism and the fact that you made a bad decision and reverse yourself if you have to. I think that's another important characteristic. We've talked right up until now about the details of managing a project, but both you and Henry have also managed line organizations. And I'd like you to comment on what you perceive as the differences in the management of a line organization versus a project. Well, there are a lot of similarities. There's no question there are a lot of similarities in managing a project and in managing a line organization. I think the biggest difference as I see, and I'd like to hear what you have to say in Henry after I finish, but I think the biggest difference I see in managing a line organization that it does take a lot more time with your people in a line organization, certainly a center director and certainly as a director of research and engineering than it does in managing a project. It takes a lot more time. You still have trade-offs as managing an institution versus managing a project. It's not as strong on cost and schedule and performance as much as it is on other parameters, but like parameters. So there's a lot of similarity and I think the fundamental, but I do go back to say to you that the fundamental way that we start off this discussion, the fundamental characteristics I think are about the same. Henry? I think you're right on here and the major difference that I see between being a project manager and being a director of a line organization is that you have the administrative responsibilities of your people in a line organization where generally a project manager spends very little time in the administrative responsibilities with their people. First off, they don't have a large number of people that they have to supervise directly. They have a lot of people that support them, but they don't have to worry about the administrative part of it. And that's a large part of trying to keep the spirit up, the can-be attitude up in an organization. And that responsibility follows largely on line organizations. What do you have to say about that? Well, I think Henry's point is the one that comes to my mind is that line organizations, management's primary responsibility is the development of their people. And the people are then used to support the programs. So it's much more of a paternal kind of management as opposed to objective achievement kind of management. What do you see to be the most significant issues that we're going to face in the next five to ten years? Well, I think as far as NASA is concerned, NASA specifically, I think we need to continue to maintain our technical excellence. I feel that we need to continue to bring on good people. We need to continue to train our good people. We need to give them the right working environment in terms of facilities, in terms of laboratories. We want to stay a technically proficient organization. And I think that's probably the fundamental thing for all NASA centers. We want to be sure they have the right capability to maintain their educational proficiency, their formal education. Whatever field it may be, I think that's important. I think we need to, as you and I personally have talked many times, I think we need to have successful programs. I think failures are very devastating and we need to be able to maintain the momentum, whether it's an unmanned program, whether it's a man program, we need to have successful programs and we need to minimize our risks, our failures. On the other hand, we can't be afraid to do something. We've got to be bold, we've got to be aggressive, so we can't let that shadow the way we do things. So I would say those are to me the most significant challenges that we have in the future. I guess the final point is with the advent of the thing I talked about before, multiple programs, large programs, things we'd like to do in the future, I think we need to become even more productive than we are, we have been in the past and that's in all areas. Henry, what do you see as the major issue? I agree with Aaron totally. There's two key areas. One is developing confidence and maintaining confidence in our people. You know, you have to have confidence in yourself, you have to be able to know where you're coming from in order to direct and manage a program and that takes time to develop, especially with the young people, I would say five, seven, eight years to develop that confidence in themselves and I think we've been blessed with that. I also think that we have to continue to look at more efficient ways and better ways of doing business to eliminate duplication. It is not possible for us to continue doing business the way we are and support all of the programs that's on the plate and do all the things that we are to be doing. You know, we're just now to the point of where we can make space a fun place to work and play in and there's a lot more work out there that needs to be done than we can get around to. So I see that as the two major areas that we have to work on. Aaron, what should young engineers or other professionals just starting out on their careers in NASA do to prepare themselves for positions in management? Well, I think first and foremost whatever their field is, as you pointed out, whether it be in the business management area, whether it be in the human resources area, or whether it be in the technical engineering science area, operations area, I think you need a good formal background. I think you cannot get away from a good formal background in education. I think that's extremely important. I think as we start off this discussion, I do think trying to get some early hands-on experience in a total systems aspect of a program is very beneficial and I think that ought to be in the hardware area if you can and even in the analysis area if you can or some type of hands-on experience whether it be in the engineering area, science area, operations area or even in as I said the human resource or business management area. I think it's very important to get hands on and start it from the ground up. So I think that's extremely important. And I think the other attributes, as I said before, the patience, the integrity, honesty and being able to communicate are really the attributes for a young person if he wants to make it happen, you might say, in a successful program management arena. Henry, would you want to comment on? I'm not too sure I can add a whole lot to what Aaron came up with. I usually can always find something to add to something. But that's the key things that you have to develop confidence in yourself and one way a person goes about doing that is being able to take a project and do it. So you get a feel for what it takes to do that job and then you get a feel for what it takes to do a little bit larger job and a little bit bigger job. And I'm a firm believer on a person starting out at the bottom in an organization and learning the trade and working the way up through the system. And I think it's those first years, the foundation that you get during those first few years that's extremely crucial to doing a good job, having the tools to do a good job down there. Let me tie you into this, Joe. You've been around a long time. You've seen it all happen. What's your take on it? Well, I think I'm a subscriber as you and Henry are to the early hands-on experience. And I think there's a reason for that in the sense that once you have become expert in something yourself, when you move into positions where you deal with subjects that you're not so knowledgeable about the content, you have learned how to recognize the work of an expert because it has characteristics or tool marks and it helps you in evaluating the decisions you have to make. We've talked about our relationships with the contractor and within the various elements within the center. One of the things that it might be worthwhile to talk to Aaron about program management as we're doing it in the station is our relationships with our headquarters and our sister centers. Well, I think that's a good point. I'm really glad you addressed that. I think it gets back to really what I said before, an item I said before is teamwork. There's no question that teamwork is really the element, I guess an underlying element of all success. I think we've got to have teamwork with our centers within NASA and we certainly have to support the program directors and the associate administrators and headquarters because they are really the people that are setting the stage for the whole program and I think we need to have teamwork with them and for them and with the centers. I think that's extremely important. And I think I've seen that come a long way. I think we have come a long way in that regard. I think we all recognize that's going to be the element of success of both our man programs and our unmanned programs and I think we're demonstrating that more and more every day with the leadership we have of the center directors and the associate administrators and with the administrator and deputy administrator. So I think it's extremely important. Henry, how do you see the relationship amongst the various directors of engineering at the centers? I don't know quite how to answer that because I don't know how it used to be that good. But I tend to agree with Aaron that the thing that we have to have is honesty, integrity, teamwork. You know, you've got to have those three and you've got to have sincere desire to try to do what is right for the program. You know, you can't let too many other things creep in. And as long as we can keep our focus on trying to figure out what is really the best thing to do and get on and do it and make a decision, you know, I think that's one of the most important things that we can do. Aaron, I think we've covered most of the points that come to my mind as to what one should address in program and project management, but perhaps you would like to summarize what you think of as the key tools that the manager has to achieve his objectives? Well, the one thing that a manager doesn't like, or two things a manager doesn't like, one is a surprise and the other is a failure. And that surprise could be in the budget area, the schedule area, or the performance area, and the same thing with the failure, whether it be a test failure or whether it be something more significant. So I think that with those underlying issues, those underlying stipulations, I think you have to have the intelligence and the staying power, you might say, which is what I would say is almost a 24-hour-day, seven-day-a-week job to keep on top of those parameters so that you don't get surprised, you don't have a failure, and it's just by working the details, have people that are willing to bring you that information and have people that are willing to help you make those decisions, whether it be your own people or your contractors that help you make those decisions. So I think if you can set that type of work, if you can put that type of energy into it, and you can get that type of people around you, not have yes people around you, but have people that will bring you the problems and bring you the potential solutions, I think you've got a very, very high probability of avoiding the pitfalls of the type of things that would cause you to fail. Henry, do you have any further comment? Program manager's got to be tough as nails. I mean, you've got to not feel intimidated or not let the system overwhelm you. There's lots of decisions that are tough, tough decisions, decisions that's going to make absolutely no one happy, that has to be made in a timely fashion, and it takes someone with a great deal of fortitude to be able to make those decisions and make them in a timely, decisive kind of a way. And I think that's one of the most important ingredients that a project manager has to have that tends to differentiate a project manager from a director of engineering or division chief or some of those other kinds of jobs. There's lots of unpopular decisions that has to be made and someone has to make it and that decision generally falls on the project manager. For our last observation, Aaron, I'd like to address, you to address the question that says we're losing the generation that has had this experience of Mercury, Gemini, Skylab, Apollo, Shuttle, and some people express a concern as to whether we will have the management capability and depth as we go into the future. Well, I think we are losing, we have lost a lot of people in that regard. The time has caught up with us in that regard or time has caught up with some of the people. On the other hand, I really think from a more positive point of view, I think that we do still have a lot of people around, good people around. We do have education programs. We do recognize, I think, the key elements of good program management and the key elements that are going to require a person to have the tools to be a good program manager or a good engineer or a good scientist or business management. I think we recognize those. And I would say this, I would say that the people that I see, the young men and women coming out of the universities today, I'm pretty high on them. I look at what some of the young people we've hired and we're hiring quite a few, as I'm sure all centers are. I think I have no question in my mind, I really have no question in my mind that they will be able to step up to the challenge of the large new programs that I hope that we're working on that will come to pass in the future, which I think will come to pass in the future. And I just have no question in my mind that we're going to have the right people. We've got the right attitude. We've got the right leadership. All the centers feel that way. So I just, I feel that if we keep going down the path we're going with the emphasis we have that we'll have the capability to do the big programs in the future. Henry, would you like to comment? I didn't agree with Aaron 100%. I think we need to remember that we went to the moon with a young team of people. You know, we had a few experienced people and a lot of kids out there and not a one of them let us down. The ones that we're getting today are the country's finest. You know, they're much better educated than we were. They have a much better foundation to start out. They work just as hard. They have the same kind of worth ethic that we had. And I think when the time comes for them to take over this responsibility, they will not let the country down. I'm confident of that. I don't think you can give them too much responsibility too quick right now. Aaron. Henry. Thank you very much. And this concludes this discussion of program and project management in a manned spaceflight program setting. Thank you. Thank you and goodbye.