Ask OCE — January 12, 2006 — Vol. 1, Issue 2

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.

What’s a data memo? Essentially, it can be anything worth documenting that might prove useful to someone on a project team. Even notes jotted on scraps of paper can prove worthy of making it into the file. “Something is better than nothing,” was the philosophy that led to this practice. Anyone can generate a data memo. Aside from the title block there is 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 process 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.

Jeff Bauer is Project Manager for NASA’s High Altitude Long Endurance (HALE) Remotely Operated Aircraft (ROA) at Dryden Flight Research Center.