Engineering Memos

By John Casani

I first came to the Jet Propulsion Laboratory (JPL) 48 years ago, and was taught that what’s most important for project success is bringing good people on board, getting them to come together as a team, making certain that they’re all on the same page, and setting up the mechanisms to keep them communicating.

Following the release of the Columbia Accident Investigation Board (CAIB) Report, Alphonso (Al) Diaz, Goddard Center Director, was asked by NASA Administrator Sean O’Keefe to head up the agency’s response. The Diaz Team, as it came to be known, was charged with making sure the CAIB Report did not become another dusty volume on a shelf of old Agency Reviews.Al Diaz was appointed Goddard Center Director in January of 1998. Before that, he served as Goddard’s Deputy Director, beginning in 1996. Mr. Diaz began his career at NASA’s Langley Research Center in 1964, where he worked in a variety of technical management positions, principally on the Viking Program as the lead for the Gas Chromatograph Mass Spectrometer. This scientific instrument was the first to analyze the surface material on Mars in 1976.In 1979, Mr. Diaz began his work at NASA Headquarters, where he served in a variety of leadership positions, including program manager on the International Solar-Polar Mission (now known as the Ulysses Mission) and Galileo. Mr. Diaz has been awarded three Presidential rank awards, two as Meritorious Executive and one for Distinguished Service. He was also awarded a NASA Outstanding Leadership Medal in 1994 for his work on the Hubble Space Telescope First Servicing Mission and an Exceptional Scientific Achievement Medal for his work on Viking. Mr. Diaz has a Master of Science in management from the Massachusetts Institute of Technology (MIT).

That much is true to all successful projects — but, naturally, it’s not as simple as it sounds.

What, for example, are the most effective “mechanisms” for communication? Today, people think about email when they think about day-to-day communication and PowerPoint for presentations. But many believe, including me, that the advent of email and PowerPoint has, in some respects, eroded our culture of engineering communication.

Of course, if you need a quick answer, if you’re working with remotely located team members — then email can be a tremendous communication tool. So is PowerPoint for presenting an engineering summary or presenting the results of a design activity. But what’s important to note here is that neither email nor PowerPoint is an adequate substitute for engineering documentation.

By that, I mean if you have people working in a technical area, it doesn’t matter what it is, at periodic times you need to have them capture the engineering that has gone on. You need to do that with an engineering memo, or a workbook, or a technical report — whatever you want to call it. You need to do that to provide an audit trail of decisions that can be reviewed and challenged by peers.

For the record
A technical memorandum is what we used to call it. We used to have a form for the engineers; they would put their summary at the top, list their assumptions and the boundary conditions next, and then go through the analysis — sometimes even including a summary of some of the equations involved, plus the pros and cons they had considered. All of that preceded their recommendations and/or summary of actions taken.

That became a part of the engineering file. Anybody could go back and review that or challenge it. You could say, “Okay here is the analysis.” You could give it to another person or to another group and have them validate it or critique it. It also stood as a good way of handing off information about work that had been done to a newcomer on the project.

What I’ve seen over the last ten or fifteen years has been a gradual erosion of the discipline of that kind of engineering documentation. Again, I think it has a lot to do with the introduction of email and PowerPoint — which, once again, are tremendous tools for communicating but not for engineering documentation.

One way of putting it is that email and PowerPoint are more like sound bites. You can’t critique a PowerPoint presentation the way you can an engineering memo. It simply doesn’t have the structure and the completeness that you would find in a report or a memo. In many ways communicating has become easier, but it’s still necessary to keep track of where you’re going and the decisions that have been made.

The Mobile Service Tower is being rolled away from the Titan IVB/Centaur launch vehicle carrying the Cassini spacecraft.

But does it really matter?
Let me give you an example of a time when communication was at the root of a project’s demise. I was on the Failure Review Board for the Mars ’98 failures. The Mars Climate Orbiter failure was ostensibly caused by a metrics conversion error that led to a navigation failure. We were getting the navigation data by tracking the spacecraft to calculate the trajectory. The data that we got from the spacecraft augmented the data from the ground — but there had been some inconsistency noticed during the mission well before the failure at Mars orbit insertion.

When we observe an inconsistency during operations, our practice is to use an engineering reporting system, called an Incident Surprise Anomaly (ISA) report, to record the discrepancy. It’s only one page long, but it’s a formal report. Once it’s submitted, it gets tracked. During the course of a mission there may be 100 or even hundreds of ISAs. Once you write an ISA it becomes a permanent record in the system. It gets reviewed. Its ongoing status gets reviewed. Its closure gets reviewed. People have to buy off and say, “Yes, this Incident Surprise Anomaly, whatever it was, is understood now. We’ve taken the following steps to prevent it from happening again and we’ve corrected whatever it is.”

In the case of the Orbiter, the person who noticed this problem didn’t use the ISA form. He wrote an email message to the person that he thought could solve the problem. That person got the email message, and he looked at it and worked on it for a while. Then his boss gave him something else to do that this individual judged to be of higher priority than working on the problem outlined in the email.

Cassini Saturn Probe Undergoes Preflight Testing.

Here is a case where the guy who noticed the problem thought he was doing the right thing. He wanted to get the problem taken care of quickly. He sent the email out. The email went to where the spacecraft was being worked. The guy who received the email probably could have solved the problem. But he didn’t. It got forgotten.

If that message had been generated as an ISA, it could not have been forgotten. It would have become a permanent part of the engineering documentation. In our failure review report, we described the problem something like this, “Communication channels among project engineering groups were too informal.”

No one would argue that open communication is key to project success. What I’m suggesting is that we keep in mind that communication comes in many shapes and sizes — it’s not a one-size-fits-all concept. We need to reinforce the distinction between the need for rapid communication and the need for engineering documentation, which creates products that can be peer reviewed and that leave an audit trail for engineering follow-up and close-out.

About the Author

Keeping the lines openJohn Casani came out of retirement in 2003 to return to the project management ranks at the Jet Propulsion Laboratory in Pasadena, California. The engineering memos Casani champions in this article are far from being the only formal communication he sets up on his projects.”As a project manager, I hold two regularly scheduled meetings each week,” explains Casani. “One is with just the core project staff, and the other gathers a more extended set of people working on the project — including people matrixed to the project from each of the major technical areas.”In addition, the full project staff — including out-of-town team members from other NASA centers, government agencies, industry, and academia — are invited to monthly meetings and many of them make a point of attending the meetings in person. “This is the way that we can coordinate and keep track of how the project is going,” says Casani. “We keep everyone informed about what everyone else is doing.” Informal communication is just as important. Core team members are co-located in “our own corner of the building,” says Casani. “We’re in contact every day, almost every hour, in addition to the meetings we hold.” For more about John Casani’s remarkable career at JPL, see his story, “A New Spin,” in this issue.