Data Memos

By Jeff Bauer

Background
When I came on board the Environmental Research Aircraft and Sensor (ERAST) Project, first as Chief Engineer and later as Deputy Project Manager, there was a lot to keep track of — four flight projects and numerous technology development initiatives. One company, AV, had developed a system for documenting their project activities that proved especially effective in communicating project status. AV’s activities were unique in that they were developing a solar-powered aircraft for atmospheric research that would take the vehicle to altitudes above 80,000 feet. My background was in flight research, not solar power, and certainly not with a vehicle of such a unique design as the Pathfinder.

What allowed me to stay abreast of their progress was their system of using project data memos. What’s a data memo? Essentially, it can be anything worth documenting that might prove useful to someone on the project team. Even notes jotted on scraps of paper proved worthy of making it into the file. “Something is better than nothing,” was the philosophy that led to this practice, and I would have to agree. Great efforts were made to make it easy for anyone to generate a data memo. Aside from the title block there was no format required.

Data memos are meant for those who are on the project team, and are intended to communicate to the entire team what is going on. I found them an excellent means of sharing information and providing everyone with access to the information in a timely manner, as well as serving as reference points later in the project. I know for myself there were several occasions where I was able to get insight into what other people were doing and how this impacted different disciplines, especially the flight operations. The data memos allowed me to ask intelligent questions, and they served to educate me on systems and technology that I was not familiar with.

Moreover, data memos allowed us to nip what we perceived as potential problems earlier in the design than we might have found otherwise, for example, at a design review. By reviewing the data memos, changes could be implemented early enough that they did not substantially impact cost or schedule. Overall, this kind of practice engenders openness, teamwork, and trust between team members.

Procedure

1. I am working on a document, e.g. Power Requirements for the flight termination system. These are the requirements, and the document becomes how I want the requirements to be met.
2. Once I have completed the document, I send it to the individual who maintains the database. This person (the record keeper) assigns a number to it and sends it out to the distribution list, which is essentially everyone involved in the project. People can decide for themselves if they want to keep it or not or archive it themselves.
3. The record keeper is also charged with logging the data memo by number and subject. Thus, if someone on the project received a data memo, deleted it, and then decides at a later date that it’s important and wants it back he can get it off the server.
4. As the project evolves and as you gain more knowledge about particular subjects, you will often go back and add information to the original data memo. If you decide to add to or comment on a data memo, you send your new data memo back to the record keeper, who distributes it and logs it as a response to the original.
5. In general, if you needed access to a memo you didn’t have, you could get the record keeper to look it up for you by providing information on the title, author, or date, etc. Often the best way to obtain an old memo was to ask the author for a copy. If I knew that a memo was written regarding the solar panels, I would call the engineer responsible for the panels and ask him for the memo. He would generally give me the memo number and I would get a copy from the record keeper.

About the Author

Jeff Bauer is currently a Deputy Project Manager on the Hyper-X project at the NASA Dryden Flight Research Center. He has served on the NASA Headquarters lead team to plan the first flight of an aircraft on another planet (Mars), and led NASA Dryden’s efforts to support the Mars Aircraft Project, developing the flight test infrastructure. He recently served on an agencywide team to assess the agency’s implementation of the Faster, Better, Cheaper principles.