NASA NTRS2008
Even though working on a problem has been your primary effort for the past year, your leadership may have heard about this once in a briefing a decade ago. Now they are basically clueless. Pretend that you are talking to your daughter's fifth-grade class. Explain how your complicated gizmo works. If possible, do not use acronyms. Define your terms. Put your work in context. Assume your leader has no idea what you do, who you work for, or what your gizmo does. That is a good place to start. Remember, taking the next century to study the problem or spending the Gross National Product to invent a new solution are probably not going to be acceptable solutions. Real engineers and technicians build real hardware that works in the real world in a reasonable manner within a reasonable time at a reasonable cost. True, skimping on time or money can cause mistakes, but folks whose gizmos are delayed unreasonably or cost more than is practical get their programs canceled, force the business into bankruptcy, or give the market over to the competition. Real engineers and technicians always consider cost and schedule in their work. Raising questions is important. However, we are in the business of doing things. Engineers and technicians are paid to get things done. Yes, you have to identify the problem, frame the design, identify the tests, perform the analysis, and assemble the hardware. But the goal is to solve the problem. Nobody ever said flying in space was easy. We make it look easy the same way that an Olympic champion makes her sport look easy: by working hard at improving performance every day. Better are the results of a well-defined test. Remember that a test on a laboratory bench is always an approximation of reality, and rules similar to those for good analysis also apply. One should always be mindful of Mechelay's rule: "It is better to be stupid than to run a stupid test." Often we try to overtest. If a piece of hardware passes an unbelievably difficult test, then life is good. More often when an unbelievably difficult test fails, we are left with a very long discussion of why and what was wrong in the design or execution of the test. Make sure that the test is well defined. Even then, it is important to explain to your leaders what inherent accuracy (or error) the test conditions or equipment have and what the assumptions or initial conditions were for the test. Test results without a good understanding of the test's accuracy or the pedigree of the test assumptions are worth very little. Finally, there is flight test data. Always limited, never at the edge of the envelope, it still shows how the real hardware works in a combined environment. Flight experience is dangerous because it typically doesn't show how close to the edge of the cliff the equipment is operating, but it does demonstrate how the hardware really works. A flight test is the ultimate test, again taken with the knowledge that it is probably not the extreme but something more like the middle of the environmental and systems performance. Good understanding of a problem and its solution always relies on a combination of all these methods. Be sure to lead your leaders by using all the tools you have at your disposal. At the end of the day, decisions in space flight always come down to a risk trade. Our business is not remotely safe, not in the sense that the public, the media, or our legislators use the term. Everything we do has a risk, cost, schedule, or performance trade-off. For your leaders to make an appropriate decision, you need to educate them, lead them, talk with them, and engage them in the discussion until full understanding takes place. It's your job. *