Back to Top

I became a project manager at age twenty-two at Eglin Air Force Base. I managed the droning of the B47 to fly unmanned, and I had zero experience to take on that task. What I learned is the real way you acquire risk aversion: I was scared to death that I’d fail.

This developed a characteristic that I carried with me throughout my career. The strongest thing a project leader can feel, in terms of risk, is the risk of failing. So I took it upon myself to learn everything about the airplane and the guidance control system by searching out the best in the aerospace community. At that time, Lockheed was doing a modification of the aircraft. Boeing designed and built the aircraft, and Sperry was doing the guidance control system. I made sure that I spent hours and hours with each of them to understand exactly what I was responsible for.


The pattern that I established for my career was one of research and faith in the skills of other team members. Through the years as I worked on other projects, the philosophy I developed is that you can be very successful if you spend the time to organize yourself, find qualified people, and understand the objectives. Once you decide what you need to do, you can organize people around it. You can get the skills. That’s the strongest way you can become risk averse—to be dependent on the strengths of others and bring them into the program as best you can.

When we worked on Viking, the first landing mission to Mars, it was done at Langley Research Center, which is really a technology center. Langley was selected because of its strong technology base, and the Jet Propulsion Laboratory (JPL) was busy with the Mariner and Voyager projects.

We ended up using this to our advantage. Not only did we concentrate on finding qualified people, but we found that by doing the project at a technological center, we were able to get people who were strong in the technical skills it took to do the re-entry, to solve aerodynamic problems, and to develop the parachute. So Langley turned out to be a technological advantage.


But the parachute reminds me of the different ways in which the first and second Mars Missions dealt with risk. They were both successful, but the roads getting there were different. In 1969 we did a fulllanded simulated test at White Sands. We simulated the spacecraft in the necessary ways and developed the parachute very early. The reason we did that was to make sure that the parachute got sized properly, since the whole integration of the spacecraft was going to be built around the size of it.

The recent Rover Missions on Mars waited too long to do that test. They did it about nine months before they were supposed to launch and the parachute didn’t fully deploy. So they had to go back and do a redesign of the parachute, but the whole spacecraft was designed and fixed. At that point there were many variables to look at and problems to solve, and the risks went up tremendously because of the limitations they had in changing the design.

So not only should you organize yourself and get qualified people, but you have to do things early. You’ve got to build enough reserve in your thinking so that you can minimize problems. The other thing is: If you have a threat of cancellation over your head, or your project might be moved to another center, or parts of it are being deleted—you allow for that, and you adjust. If you stop working because you’re worried about changes to your program, you start adding risks to it.


Also, you have to be disciplined in carrying out very critical analysis. Don’t move on without it. On Viking, we brought the science community in early for the 1975 launch. They attended every design review and participated very strongly. We wanted their fingerprint on everything that was done from an engineering viewpoint.

My mentor Jim Martin insisted that if this was going to be their opportunity for a scientific achievement, then they needed to participate in the program all along the way. Would you believe that 72 scientists moved to JPL from their various universities for one year during the Viking Mission just because he said that was where the action was? He said, “If you want to play on my program, that’s the way it’s going to be.” You can’t avoid risk over the telephone.


During Viking, we also developed about 500 scenarios of all the things that could possibly go wrong during the development and flight. We adopted a very pessimistic view and used these scenarios to establish various plans for cost offsets, budget shifts, and solutions to technical problems.

We did have a problem that I’m not proud of, but it also taught me something about risk. We had money problems, and we were told that we weren’t getting any more money. The cost was fixed, and the schedule was also fixed since it was a planetary launch.

Well, we had a risk problem related to a test. One of the problems with the fixed budget was that we weren’t going to be able to perform the terminal-landing test. This was a very sophisticated full-systems test where we would drop the spacecraft through a Mars landing simulation. We had pitched the cost problem to headquarters, saying we needed $1.2 million dollars, and we were denied the money. So we were going to have to launch without the critical terminal-landing test—a very high-risk decision.

Jim Martin accepted it at the time. He said, “Ok, as long as you hold my hand, I’ll jump into the pool with you.” So we made the decision to go ahead with it. We ended up being successful, but there was a large amount of risk attached. If we had failed we would have lost $1 billion dollars (and this was in 1970) because we couldn’t secure the $1.2 million for the necessary preliminary test. That just doesn’t make sense. It wasn’t a schedule problem; it was strictly a cost problem.


This is where I really learned a big lesson. As a project leader, you’ve got to take the problem before management and tell them the risks that they are taking by withholding funds. You’ve got to be tough and hang in there. At this point, we were seven years into the project. Jim decided to swallow hard, pray a lot, and cross his fingers that the test worked. We had a happy ending, but under other circumstances, it could have been a disaster.

This is an example where management made the decision to take the risk against the security. I think that’s the thing that has to change. We’re in a high-risk business, and we have to approach it in a conservative way. But the Agency needs to realize that sometimes the failures make you learn and progress.

I’m not saying that you set out expecting to fail, but there is such a thing as so much risk-aversion that you don’t do anything. You’ve got to maintain a healthy amount of it and move ahead. And these are just some of the strategies I learned over my fifty years that have helped me to do that.


There have been times when I’ve taken over a project in the middle, and also times when the project has been in the formative stages. In every case, I’ve gone off-site and started to look at—and fix—duplication. Everybody has to be in first grade again. I say, “Stand up and tell me what you think your job is.” They do that. Then you start listening.

Sometimes I’d find out that two or three people were doing the same thing. So I started to fix it. I’d find out where the holes were, where there is somebody who is not doing anything. So you work it out so that everyone is clear about exactly what they are doing and what the goals are.

Then you have to empower people to build a high-performance team. This team has to be willing to communicate and tell you exactly where you are. You do this by dealing with the complete human circle: the social aspects, the commitments, the truthfulness, the relationships, the passion—all the things that we measure in people. Then you can take their technical skills and apply them in a way that really drives the system to success.

A process doesn’t get the spacecraft built. A logo or a motto doesn’t make it happen. It’s people.


  • Sometimes pessimism can help to reduce risk. Planning for possible problems and developing a cost and schedule-efficient way of dealing with them can provide an important project “safety net.”
  • A small amount of funding is never worth the failure of a large-scale project. Project managers have to fight to get the resources they need to do things right—not cross their fingers and hope for the best.


In a situation where mistakes and misjudgments can cost millions of dollars, how do you strike the right balance between healthy risk-aversion and playing it too safe?


About the Author

 ask21_guastaferro Angelo “Gus” Guastaferro has had a lengthy career in Program and Project Management, both at NASA and with private industry. His previous story, “Bringing Up Baby,” was printed in ASK 17.

About the Author

Share With Your Colleagues