Jerry Madden retired from NASA in 1995 as Associate Director of Flight Projects at Goddard Space Flight Center. During his distinguished 37-year career, he was considered by many of his peers to be one of NASA's "premiere" Project Managers. Outside the agency, Jerry is widely recognized -- and often quoted -- for his 100 Lessons Learned for Project Managers, a collection of mostly serious, sometimes funny (128 actually) observations about project management that he compiled over the years.
Since his retirement, Jerry has remained active by serving on several NASA review boards, by working part time at the Smithsonian Institution's Air and Space Museum, and by sharing his wealth of knowledge about project management with anyone who has a mind to tap his abundant generosity and frankness.
How do you like being a reviewer? Does it feel like you're on the other side of the fence, so to speak?
Unfortunately, you get the same feeling. At least I do. You feel responsible for the mistakes that are made. That's what you're there for, to make sure these people don't make any mistakes. You hope when you go to a meeting you find nothing -- that things are fine. But that doesn't happen too often.
What advice would you give a young project manager at NASA today? Let's say someone who has just been assigned his first project.
The first thing I tell them to think about when putting together their team is look at who you have available to you and what are their backgrounds. Once you've put together a good working team and explained to them how you are going to run the show, the next thing you've got to do is get a cursory knowledge of what you're going to be doing. Learn the basics of the project. If you're going to fly a scientific mission, the least you've got to do is go out and learn about the science that's going to be done. Get a couple of general books. Don't try and get too detailed an understanding because you'll never be able to catch up if you aren't already knowledgeable in the subject. Read so that you understand the nomenclature and to get a grasp of the basic principles.
One thing that a manager has to know is the nomenclature and what it means. When I first started in this business, I was a mathematician and was working on telemetry data. I didn't know anything about telemetry, so I went down to Radio Shack and got a simple book on telemetry. When an engineer came in and started spouting off about this stuff, he couldn't believe that I knew what he was talking about. It's very painful to listen to a presentation of supposed facts and you don't even understand the language. I've been to meetings where somebody gets up to explain something using the language that goes with that trade and all of a sudden you'll notice eyes glass over because they've lost it. You can't afford to be one of those glassy-eyed guys if you're the project manager. You've got to understand what people are saying.
What's the greatest difference between the world of a NASA project manager today and when Jerry Madden was a NASA project manager?
|In the old days, you could hold the whole spacecraft in your mind.
Project management itself hasn't changed. What has changed is that the systems have gotten so much more complicated. In the old days, you could hold the whole spacecraft in your mind. Now you can't hold one subsystem in your mind. In the early days, the people who were building the hardware knew what they were building, knew all its functions, and if someone gave them a piece to build that wasn't right they'd know it. Now they don't. It's too complicated.
What should a project manager be doing then in this sort of environment?
You still go out and get the best people you can. You give them the authority to do their job. You give them the most resources and money you can. For instance, you get a systems engineer who understands his main job is the requirements and interfaces. To me a failure today -- and it was a failure before, and it will probably always be a failure -- is that you don't have someone interfacing with the people who are actually doing the work. You have to have someone on your project who understands manufacturing and building hardware and can talk with the technicians who are putting it together and find out if they are having any problems. The same is true with the software. Someone has to understand how the stuff is organized. One program I was reviewing we looked at the software and everything was going along fine, but something didn't feel right and we could never put our finger on what it was until it blew up. If someone had gone down to the people who were doing the programming and putting the subroutines together, you would have found out that these people were concerned and worried, but they had to get the work out, and they were getting it out, right on schedule -- it's just that the work didn't WORK.
If you were a project manager at NASA today, what would you be doing differently than 15 or 20 years ago?
Paperwork. I'd be doing lots more of it. Managers today have so much damn paperwork to do. They spend maybe 40 percent of their time, if they spend that much, managing the actual work they think they're managing. The paperwork has multiplied in every direction.
Paperwork I suppose is a byproduct of the complexity, but is it possible to manage a project today without all that paper?
Oh no, you need all that paperwork just to identify everything that's going on. You also need to have a risk management plan. We used to laugh when the first risk management reports appeared. If a project manager didn't know the risks he was facing, he shouldn't be building anything. Now much of the risk is buried in the details and is hard to evaluate from the top, so a good analysis of risk has to be done.
Were you a risk taker?
|With the early spacecraft there were definitely things you could do that you couldn't get away with today.
Of course I was. A project manager has to be. More importantly, though, you've got be able to learn from your mistakes. Some of the risks I took in the early days were foolish, but I learned. One time I had a weight problem and threw out the inertial dampers. When it came around to another program and we had a weight problem again, one of my men came to me and said, "Are you going to get rid of the dampers again?" and I told him, "No because I only need to make an ass of myself once." That's the truth; once was all I needed.
Was it easier to be a risk taker in those days?
With the early spacecraft there were definitely things you could do that you couldn't get away with today. That's because they weren't as expensive as they are today. The more money that is at stake, generally the less risk you could take. In the old days, we used to have a saying, 'The freight train leaves.' The scientists knew exactly what we meant by that. If you don't make the flight on time, we're not waiting for you. On a mission where there were 15 or 16 scientific instruments, we wouldn't give a second thought to flying without one. We'd fly without two. We used to say we'd put a lead brick on board to cover the weight. On the present space craft all the instruments are so damn expensive you don't lift off without one of them.
What do you think about the Faster, Better, Cheaper culture?
|If you go and look at most of NASA's failures, it's usually something small that someone overlooked.
The Faster, Better, Cheaper culture is fine, but if you're doing something Faster, Better, Cheaper it has to meet those criteria. A small satellite in the $100-million range you can do Faster, Better, Cheaper, but everyone has got to understand you're taking a risk. You can't do something extremely complicated Faster and Better. You can do it maybe Better, but you can't do it Faster and Cheaper too. It takes a certain amount of time. You also have to have extremely good people on the Faster, Better, Cheaper project -- better than you have on the bigger projects. To do something Faster, you normally have to cut corners. To do it Cheaper, you cut some of the manpower. You've got to make sure you are cutting the right manpower.
In your 100 Lessons Learned for Project Managers, you said it's not the big things that do a project in, it's the little things.
You rarely get clobbered by the esoteric things. If you go and look at most of NASA's failures, it's usually something small that someone overlooked. The one that got me was a very simple power supply. We had flown over 60 of these. The people putting it together were brand new, so why not give them something simple. They were easy to build and therefore it was supposed to be a mundane task. We ended up losing the spacecraft because a screw was too long and it shorted the power supply. On another spacecraft, the screw was too short. A screw for one of the modules was holding on by less than a thread. Nobody looked at it. We were lucky that time. The point is, it's not unusual for that kind of thing to happen.
When you selected your people for a project, what criteria did you use?
I wanted people who would take charge. Someone who would say this is my piece of the puzzle and wanted to manage it. I would give my people the greatest leeway I could. There were only a few things they couldn't do, and they knew what those were. Other than that, whatever decisions were made in that area were made by them. I didn't micromanage. I think anyone who tries to micromanage today is a fool. There's too much detail. Somebody has to be very familiar with what's going on in great depth, and the project manager cannot do that. He has to count on his people to do it for him.
Would you suggest that the project manager handpick every individual on the project?
Normally I would let the people in charge of areas of the project make their own choices. But the project manager should try and know everyone. It also doesn't hurt to know the people not on your project. I remember one time we were in deep trouble and needed help, so we asked the Center to give us some backup support. We gave them a list of 12 people who could fill our needs. None of the names we asked for was available, so they offered us a couple of others. We didn't take anybody they offered because we knew we would have been worse off than with nobody.
Do you think that management itself has evolved over the course of your career and in recent years?
|I've seen too many beautiful plots and charts where the data underneath crumbled if you touched it.
I think the basic management principles are the same, but the tools are better. The computer gives you a lot of different methods of looking at what is going on. The ability to have your data laid out in nice graphs and charts so that you can visualize where you're at, that's certainly nice to have. Provided the data is accurate. That's something that's always worried me. I've seen too many beautiful plots and charts where the data underneath crumbled if you touched it. I think the computer really helps the modern-day manager, if he uses it correctly, but the first thing is you have to be able to trust the data.
Is there any single characteristic that you've recognized among the superior project managers?
The best project managers are the ones who pick the right people to manage the day-to-day work of the project. In some ways, he's fundamentally nothing more than that, someone who picks good people.
How do you learn to do that?
By working with people. If you're not a people person, you really shouldn't be a project manager. There are good ones who aren't, but for some odd reason that no one can account for they still manage to get the right people to work for them.
Is that the only talent you feel is worth noting?
Yes. Because people are what make a project.