Follow this link to skip to the main content
NASA logo, Jet Propulsion Laboratory, Caltech button    
JPL Home button Earth button Stars & Galaxies button Technology button
Genesis Search for Origins banner
Home button
Mission button
Spacecraft button
Science button
News button
Education button
Team button
Pre-Launch button
Flight Team button
Recovery button
Science Team button
Interactive button
Archived Homepage
Interview banner
  Richard Bennett  

Richard Bennett System Engineer
View Richard's Resume


The following interview occurred September 2, 1999 between System Engineer Richard Bennett, Jet Propulsion Laboratory (JPL), and Senior Associate Alice Krueger, Mid-continent Regional Educational Laboratory:

A.K. You work for the Genesis mission as the Mission System Engineer at the Jet Propulsion Laboratory. What does your job title mean?

R.B. This job places me in a position as chief engineer of the [Genesis] project. Our project, because it is a partnership with several other institutions, requires that there be one central engineering activity that covers all participants. The science requirements [of the mission] parse between the partners. Our work must lead to one end product that fits together and performs together and complies with the science decrees of the mission.

A.K. Why is your job important?

R.B. Everyone thinks his or her own job is most important. Indeed, systems engineering is like any job on the project, it is equally important. Everybody has to play together to produce the end product. The responsibility is on the office of the mission engineer. With my staff, I make sure everything comes together. The subsystems must perform the intended function and work. The spacecraft must fit on the rocket. The mission designers must be able to fly the end product. Without this you lose the glue that holds this whole model together.

A.K. What is risk management? Why is it important to the success of the mission?

R.B. Another aspect of my job is responsibility for risk management. In reality, this is a function of the project management office. I not only take on the role of chief engineer, but I help project management define future risks.

Risk management is a little different from problem management. With problem management, you have identified real issues to deal with such as lack of hardware or personnel not being available when you need them. Risk management is an attempt to peer into the future and to guess or dream up problems that might or are likely to occur. I must assess how likely the problem is and its consequences. These are measured qualitatively as high, medium, or low. We have a Risk Management Plan that tells how we define the risks.

Once risks have been identified and assessed we must develop a mitigation approach if the likelihood or consequences are significant. There are certain ways you can deal with risks that are defined. For instance, the aerospace industry along with NASA keeps an eye on program problems that cut across organizational boundaries. When another program finds an issue, it puts out an alert. We recently picked up an alert that a particular electronic part may have a manufacturing defect. The defect is subtle, and only shows up when the part is exposed to certain voltage conditions. Our jaws dropped. "Oh my gosh! We're using some of those parts." 'Turns out the parts are in at least two equipment boxes on the spacecraft. Now, I can predict two possible outcomes. We might have to get those parts changed out or we may determine that the condition that caused the problem is not present in our design. Now, no one knows what the right thing to do is. So, I carry a risk against the suspect subsystem boxes of taking the part out later and replacing it. In the meantime, we will gather additional test data about the problem and compare the test performance with what is expected of our units. We will weigh whether it will ultimately cause us problems or not. We will then decide a course of action. I have to prepare scenarios for different possible decisions. Those potentially impacted have to determine what would happen and how to handle it. We could watch the problem, there may be enough money to handle it if it should occur, or we might invest money now to insure against the problem.

A.K. Tell me more about how a project like Genesis handles identified or potential risks.

R.B. There are four main ways to handle risks. These are avoidance, insurance, abatement, and acceptance. These strategies are standard industry approaches, and are in compliance with NASA guidelines.

To attempt to avoid risks, you could change the [design] requirements, you could change the environment causing the risk, or you could transfer the activity to a subcontractor or other source that provides less risk.

As insurance against risks, the project holds contingency funds and financial reserves. Contingency funds are money to account for in-scope changes to provide risk coverage. For example, suppose delivery of a certain element will be delayed by a week and that will impact the start of the system test flow. Management might accept the delay, which will cost money to hold our people longer, but they could use contingency funds for this. Reserves are funds to use for out-of-scope changes to accommodate a given risk.

Abatement is often the focal point of most of our risk management. You could reduce likelihood or reduce consequences. To reduce likelihood of a risk, for example, if a delivery is predicted to be late, you could ask the subcontractor to work double shifts or weekends to make up for lost time. To reduce the consequences of a late delivery, we could work with the receiving organization to develop work-arounds to reduce the impact.

The fourth thing we could do is to simply accept the risk. When a risk comes along, we could say, "Hey, it's very likely something will happen." Then we look at the end results and say "Hmmm, that end result won't hurt." I keep track of trip wires, which are indications or events that occur early in risk development that point to a high likelihood of occurrence.

A.K. Other system engineers work on the Genesis mission. How do you interact with them?

R.B. The way we interact is through the Mission Engineering Team (MET). I chair a weekly meeting of the lead engineers of the partnering organizations. We develop requirements, analyses, work design trades, go over the status of things one organization needs from another, schedules, and I maintain an action plan and a resolution list. Then, of course, there is a lot of just, plain, traveling. My staff and I will visit all partnering organizations on a regular basis to participate with them and help resolve crosscutting engineering issues.

For example, look at flight systems. My counterpart is Nick Smith. He helps design with his team the spacecraft that will meet the requirements that I supplied to him through the [Genesis] Mission System Requirements Document. He will look at the top end requirements and will implement those on the spacecraft. He is not responsible for the science instruments. He must recognize they exist and provide accommodation for their care and feeding. He must get them the power they need and know how to control them. He looks to other organizations to develop those instruments. Each organization has a lead engineer. LMA [Lockheed Martin Astronautics] has systems engineers worried about each subsystem: the spacecraft structure, propulsion and attitude control, the telecommunication system, data handling, power, and thermal design.

A.K. What is your typical work day like?

R.B. Let's not talk about a typical day. My work involves quite a bit of correspondence, both written and verbal, with various organizational leads. It involves generation of requirements and oversight that those requirements are implemented properly. I answer technical questions from one organization to another. My staff and I will work with the science team to make sure that the engineering implementation does not impact the science quality or quantity. We interface with the PI [Principal Investigator Don Burnett] and his team to be sure that they understand potential impacts and accept them, or else we develop a different approach. There is quite a bit of travel. We are a diverse team, with sites in southern California, Denver, New Mexico, Florida, and Texas. My staff or I will be on the road visiting team members, and participating in system level meetings for input and oversight.

A.K. What kinds of problems exist in your work for the Genesis mission?

R.B. One of the most difficult problems to overcome is the lack of co-location. It makes our job much more challenging. The major team members are separated; hence there is a lot of communication by telephone or electronic transfer of information. So the words you say and the words you write down have to be very clear. I find many engineers are visual people. We sketch things to make points. When you don't have that capability with a team member, it makes it real challenging.

We mitigate this problem by getting on the road. It helps to meet eyeball-to-eyeball. You build relationships with people and they know who you are. I find folks are more than just dedicated designers and production people. They have their own lives and dreams. When you get to know people, you understand what motivates them and that builds trust. When you deal face-to-face on a regular basis, it's easier. When you are working difficult contractual issues that mean spending more resources; you need to understand and know the people you are dealing with in order to maximize the benefits for the whole project.

A.K. What kind of education and career path led you to become an engineer?

R.B. My career path was born out of both hobbies and education. I didn't know I would end up in aerospace. When I was real young my Dad got me interested in building things and electronics. In middle grammar school he helped me build crystal radios and balsa wood airplanes. I got a lot of joy and entertainment from making stuff. I was fascinated by electronics, primarily because of the space program. I grew up in a spectacular era, pre- and post-Apollo. In junior high I wangled my way into shop classes so I could build electric motors. In high school, junior college, and college I enjoyed solid state electronics.

I stumbled into aerospace when I began to interview for jobs toward the end of my college work. I was looking for a job that would allow me to design and create electronic products. I wanted to lay out schematics and produce hardware that does something. My first job ended up at a large aerospace company. I picked them because they offered me the design work that I was so much interested in. My first assignment turned out to be for the NASA mission Pioneer Venus.

My first assignment was the development of a block decoder. Information sent by a spacecraft to the ground station is supplemented with additional data like the time it was received and the ground station ID that received it. This information was called header information and not understood by the ground computers that analyzed spacecraft performance and health. The only way to know the spacecraft status was to separate the raw telemetry from the header information. So, I built a unit to do just that, and it was capable of recognizing data from two spacecraft and four planetary probes. It was exciting to go to Florida, to the Cape, to watch the integration of my unit into the main system that was used during flight. It was ironic that I left that company just about the same time when Pioneer Venus quit sending data some 14 years later!

A.K. What is your family life like?

R.B. My family life is probably like a lot of others. My wife and I have two sons in junior high and high school. We enjoy sports and travel. My youngest son is a Little League all-star and quite the scholar. My oldest son enjoys music, playing the guitar and is getting his feet wet learning to play golf.

A.K. What kind of advice would you give to young engineers who are interested in space?

R.B. There are some important things to consider when getting into this type of career. Clearly if your focus is aerospace engineering work, there are probably some very specific courses in school to focus on. If you want to do design work, get a four-year degree from a well-known and accredited school. I have spent a lot of time hiring young engineers. Some get sucked into programs in schools that are not accredited or are not recognized as solid educational training institutions. They attempt to hire in to big companies that don't recognize their degrees and end up as technicians and have to take night school classes to get where they want to be. It is very important to select an accredited institution whose accreditation is recognized by the company where you want to work. Call the employment office and ask them what accreditation they accept. Then find a school whose program has that accreditation. Don't be misled by schools promoting their great programs. . .check first; apply later.

Second, make sure whatever you want to do is something you love. Work is a place you should look forward to going to. I used to work on "black world" [classified] projects for the Department of Defense. You can design a lot of stuff, but I, personally, didn't get a lot of satisfaction out of it. You hoped the stuff you designed was never needed, and you couldn't tell anyone what you were working on. In a commercial or NASA environment, you can work for the benefit of science and mankind. You can share your experience with family and friends. You can feel good about what you do, who you do it for, and why.

~~~ button
+ Freedom of Information Act

+ Privacy/Copyright

Curator: Aimee Meyer
Updated: November 2009

go to go to go to