What I’ve Learned from NASA

By Kerry Ellis

 

Seven years ago, I was hired as an editor for NASA’s ASK Magazine. Being a rare English major math minor hybrid and a generally curious sort who liked taking things apart to see how they worked, I was thrilled for the opportunity to get an inside look at NASA.

I was overwhelmed by how much I didn’t know about our nation’s aeronautics and space program. Thankfully, there were hundreds of scientists, project managers, and engineers who were as excited to teach me as I was to learn. (There are thousands more I’ve yet to meet.) And what I’ve learned is aeronautics and space exploration are hard, much harder than I’d imagined. In addition to that basic truth, I also learned there are important common lessons to be had from these one-of-a-kind missions.

 

Communication Matters

We’ve heard this countless times, but every story makes the point in a new way. The underlying message is the same—communicate openly and often!—but how it’s delivered can change. I learned that the root cause of most mishaps, be they in hardware, software, or requirements, could be traced back to miscommunication or a lack of communication.

I learned this early with one of the first projects I wrote about for ASK: Genesis. Before Mike Ryschkewitsch became NASA’s chief engineer, he was the deputy center director for Goddard Space Flight Center and spoke with me about the mission that unexpectedly crash landed upon reentry. He taught me why clear communication trumps heritage hardware in ensuring a mission flies as planned:

“You can’t just say, ‘don’t install g-switches upside down,’ as a lesson learned from Genesis,” said Ryschkewitsch . “There was confusion around what testing needed to be done and what the tests meant. One part of the team understood that repackaging the [Genesis] electronics meant losing the ‘heritage’ from Stardust. Other parts never clearly understood that, and it was never clearly communicated between those teams.” So when one team verified that the switches did what they were supposed to—which to them meant flipping from one orientation to another—another team thought full testing had been done, ensuring the switches flipped and made the correct connections.

Falsely assuming communication has occurred or understanding has been reached by all involved is a common problem. It’s the reason behind another often-heard adage at NASA: “Trust, but verify.” Though I first heard this repeated among systems engineers, it applies to all parts of a project. Everyone is working together to create a successful mission, which can be thought of as a system itself.

“I remind everybody constantly that we are all systems engineers,” explained [Bryan] Fafaul [from Goddard]. “I expect everybody, down to the administrative staff, to say something if they see or hear anything that doesn’t seem right. Remember, you need to be a team to be an A team.”

Resolving communication issues can help prevent larger, technical issues down the line. Speaking up can be difficult, but not doing so can result in disastrous mission failures.

The type of communication that occurs can also make a difference. While the consensus is to talk often, many agree that face-to-face conversations offer the most benefit, followed by teleconferences, then e-mail. Being able to see people’s expressions and hear their voices helps eliminate uncertainty around meaning or motives. It also helps build the trust these collaborations require.

Ed Rinderle, a Viking programmer, attributed some of Viking’s success to the working environment: “We were all gathered in one big bullpen, an open area, no cubicles or partitions. You got to know each other on a different level than had we been separated.”

According to Mike Landis [former NextGen project manager], “Real estate agents talk about location, location, location. From a project manager’s perspective, it’s communicate, communicate, communicate. It’s not just sending an e-mail out, it’s sitting down with the line management and researchers, understanding their requirements, and ensuring they have the resources they need to execute our plan.”

“When we actually went to their [Roscosmos] cafeteria and were able to eat with them, sit down with them, that helped,” added [Harold] Beeson [an expert on materials flammability in high-oxygen conditions from White Sands Test Facility]. “A meal is always a good thing to share.”

The working relationship among the team swiftly improved after that. [David] Urban [microgravity scientist from Glenn Research Center] explained, “We’d built a familiarity, they were relaxing, we had spent some time together and communicated during meetings.”

Building trust through communication also relies on following through on commitments, exactly as agreed to. Doing things as stated—whether in conversation or written requirements—also contributes to mission assurance. It’s why every piece of hardware and software goes through verification and validation. If you don’t thoroughly communicate changes, everyone will operate under the assumptions of what was previously written or heard.

 

Test as You Fly, Fly as You Test

I first heard this mantra at one of the Academy of Program/Project and Engineering Leadership’s Masters Forums, and since then I’ve heard it repeated often as a core lesson learned from many NASA missions. It seems obvious from the outside—test for the planned mission conditions and operations, then operate according to plan—but the thing about one-of-a-kind missions is the plan always involves the unexpected. (It’s tough to plan for discoveries you haven’t yet discovered.) And replicating conditions in orbit or deep space on Earth is never easy.

In one instance with Cassini, an engineer insisting on full testing revealed a flaw that would have resulted in data loss:

The team asked the Goldstone Deep Space Network (DSN) station located near Barstow, California, to transmit a signal to Cassini that would simulate the signal coming from Huygens. The team would then record the signal on board and play it back to Earth. They originally proposed using only a carrier signal, but one of the ESA [European Space Agency] engineers, Boris Smeds, pushed to make it a full simulation with telemetry. “Most people thought this was overkill, but we agreed to let him do it,” [project manager Robert] Mitchell says. As it turned out, the carrier signal was received just fine, but the telemetry was not. If they had done no test, or just the carrier test, the team would have lost a significant amount of Huygens’ data and would not have known about the problem until after the mission was completed.

We can never solve the problem of “we don’t know what we don’t know,” but by acting on what we do know, and testing according to that knowledge, we may be able to oust some of those unknown unknowns before they become problems. In the projects I’ve learned about, the factors that most often make or break a NASA mission are the quality of communication and the thoroughness of testing. Getting those two things right goes a long way toward ensuring the technical and operational success of any project.

But no NASA project exists in a vacuum. To compete successfully for scarce funding, missions must make a convincing case for their scientific and societal value, so another vital aspect of project success is stakeholder support. And the biggest stakeholder for NASA is the general public.

 

Reach Out for Support

Many project managers and systems engineers tout the benefits of networking when problem solving—reaching out to other experts to gain their expertise or insight. A different type of reaching out can have a greater impact in keeping a project going: public outreach. Support from the public, or from scientists wanting new data, can be a strong argument against project cancellation.

“The reality is that every year you have to defend your program,” [Dougal] Maclise [who worked on the solar-powered Pathfinder unmanned aerial vehicle] says. “The best way to keep a program alive is to get the user communities to say they need the data your program provides them. Thus it behooves you to spread your base of support far and wide.”

The Environmental Research Aircraft and Sensor Technology program’s Pathfinder project appealed to local farmers, children, and universities. Word eventually made its way back to NASA about everything the team was doing to support the local community.

“Suddenly money that hadn’t been available before appeared [from NASA], and this gave the project some extra lift, so to speak, making our attempts at another world-record altitude flight an even more viable goal,” [Jenny] Baer-Riedhart explains.

Getting the public, international partners, and scientists on board gives projects extra voices to fight for mission completion. It can also result in unexpected and beneficial collaborations beyond aeronautics or spaceflight, like when industries learn about new technology created for NASA projects and brainstorm new ways to use it.

 

Expanding Technology Innovation

One of the most important things I learned working for NASA, and something I think is often lost when the general public thinks about the agency, is how much of what NASA does affects our daily lives. The knowledge obtained by doing these missions does not stay locked inside the government. And I don’t mean just the scientific knowledge we gain by studying Earth, other planets, and galaxies.

Because NASA is building one-of-a-kind missions, a lot of new technology gets invented along the way. That technology is reused and repurposed in thousands of ways. Better known as “spin-offs,” these innovations are embedded in our local communities. What’s surprising is how few people outside the agency realize this.

For example, working in space has allowed NASA engineers to help remote villages obtain clean water.

“We’re working in extreme environments in both cases,” said [Dan] Garguilo [a systems engineer at Johnson Space Center]. “When you have to plan project implementation in the developing world, you have a finite amount of money and resources to do the project; it’s almost like working in space. You have to plan everything out to the nth degree, account for all the tools you’re going to need, know what materials are available for you. You have to work efficiently and take your environment into consideration. All these things are similar to when we’re working on ISS [International Space Station] or other planetary missions.”

Thanks to NASA spin-off technologies, doctors can help diagnose patients located thousands of miles away. Firefighters can put out fires faster. Farmers can remove harmful chemicals from soil. Ophthalmologists can diagnose diseases earlier and more accurately. NASA technology is also responsible for polished brass coating on plumbing fixtures, cordless handheld vacuums, UV blocking in sunglasses, shock-absorbing sports shoes, wireless headsets, and refrigerated display cases at grocery stores. And this is a very small sampling from thousands of examples. What we put in to NASA we get tenfold in return. (See NASA’s annual Spinoff publication for more examples.)

I expect everybody, down to the administrative staff, to say something if they see or hear anything that doesn’t seem right. Remember, you need to be a team to be an A team.

 

More to Know

Perhaps the biggest lesson I’ve learned is no matter how much we know about aeronautics and space exploration today, there’s always more to learn. Stories and experience from past and current missions are continuously captured and told to help today’s missions and those who will innovate in the future. And every mission has multiple stories, different knowledge and perspectives from everyone who worked on them.

Sharing those stories and that knowledge is why I do what I do every day. Not just for the obvious value of getting that know-how circulating across centers, agencies, academia, and the world, but because I love learning and telling those stories.

What NASA does is amazing. I’m proud to be one small part of it.

 

Related Links

• Genesis: Learning from Mistakes
• Leadership, Teamwork, and Focus: Viking’s Landing on Mars
• Cassini-Huygens: International Cooperation for Astronomical Achievement
• Cultivating a Community

 

More Articles by Kerry Ellis

• Kepler: The Long Road to Other Worlds (ASK 47)
• WIRE: Learning from Failure (ASK 45)
• International Life Support (ASK 44)
• Permission to Stare-and Learn (ASK 42)
• X-15: Pushing the Envelope (ASK 40)