Successful teams plan for the future while realizing current goals. Future team members greatly benefit from explicit and accessible records of previous team actions and decisions. Recording these decisions formally and informally is essential to organizational development. Here’s a few ideas on how to best do this.

Reporting helps to provide structure to research and design work, passes on information to future team members, and showcases results to competition judges, external sponsors, faculty advisors, and the larger academic community. Unfortunately, reporting data and lessons learned is often neglected because reporting is seen as secondary to the team’s mission. Although this is inevitable in some respects, knowing it and working to meet both short-term and long-term needs simultaneously is essential for the long-term health of a given team.

Team Reports

Teams should aim to produce some form of report or documentation of their activities. This is often a function of many teams’ simultaneous existence within an academic course. Often, documentation is part of the competition process, with documents submitted for review being a major part of engineering design evaluation. Even without formal requirements, documentation is a great way to pass on information to future teams. Quality reports are therefore essential. Reports should be concise but thorough and written with a particular audience in mind—external judges, sponsors, other team members, faculty advisors, etc. Be careful to write reports in language that is easy to understand; eliminate or explain jargon or slang that might require some specific context to understand. Although there are no hard and fast rules regarding what a report should cover, there are some basic types of information that are useful to consider including:

• Contact information: First and foremost, any report should include information about the author so that readers can ask questions.
• Abstract/keywords: Long reports in particular should be abstracted so that potential readers know what is and is not included at a glance.
• A clear organizational structure: Headings and subheadings make it easier to pick out key ideas and often help structure arguments in an effective manner. Long reports should have a table of contents to make this structure more evident.
• Supporting data: Arguments and conclusions should be supported by available data. Detailed data is often easiest compiled and represented in an appendix, but summary data is often best embedded in the main text to support arguments.
• Disconfirming data: Particularly for internal reports, knowing what did not work can be as or more valuable than knowing what did. This may not be as possible to integrate in public reports like theses or competition design reports where a consistent and tight argument is required, but documenting failures and lessons learned in those cases can also be helpful.
• Personal observations: Similarly, observations, stories, and anecdotes are often unreported in public or professional reports but unless recorded can be lost to future generations. As with disconfirming evidence, this may be best represented in a more informal and private report, but failing to document such observations can lead to a lot of valuable information disappearing permanently.

Recording Information in Real Time

Formal and informal reports are usually based on some foundation of raw data, whatever form that takes given the problem (e.g., simulation data, spreadsheets, notes, back of the envelope calculations). Recording information in real time is essential in producing quality reports—it is very easy to forget particular details that may prove to be important down the road. The traditional manner of doing so is through lab notebooks. Notebooks provide a simple way of recording information in one central place. Pages are bound so that information can’t be lost or removed without evidence of its missing. This makes a notebook superior to scrap paper, writing on one’s hand, etc. In cases where one’s notebook is not available and other means of recording are used, notes should be transcribed or appended to the notebook as soon as possible so disparate pieces of information are not lost.

Notebooks should not be edited documents but rather a means of documenting data in real time. This includes failures, incorrect assumptions, faulty drafts, and questions that may later seem to be pointless or poorly thought out. Notebooks should be seen as a documentation of process, failures, and observations that can provide the raw data required for reports, not as a formal report itself.

Increasingly, the traditional notion of a notebook as work in progress is complemented by computer communication technologies. In many respects, a working directory on a computer network is an electronic notebook, comprised of many files at various stages of development. Again, the important consideration is to maintain numerous iterations to document progress and evolution. Computers make it all too easy to save over older iterations, thus destroying evidence of how a final version emerged.

Programmers are well conditioned to saving iterations and often use formal version control software systems to help organize what can quickly become a huge and complicated database of previous iterations. Less formally, it’s possible to do this simply by remembering to save multiple iterations of files and naming files in a way that makes the iterative development process clear. Tools like Microsoft Word change-tracking can also be useful in noting iterations in progress for written documentation.

Electronic mail can also be a useful means of documenting progress over time. In a well-used e-mail network, it is possible to trace the evolution of a project simply be reading through old e-mail archives. E-mail has the added benefit of sharing progress with other interested team members in real time. Too often, notebooks and personal files are individual artifacts; if the problem requires more than one person’s input, these notes need to be shared. E-mail is a quick and easy way to do this, although excessive use can become its own source of information overload.

Balancing Current Stresses and Future Needs

Documenting in real time takes time. Real-time documentation should happen as soon as possible. It is often a good idea to budget a small amount of time each day simply to document what transpired in whatever form most convenient. It is all too easy to drop this in particularly stressful situations, but this should be avoided whenever possible since it is very likely that the current stresses will encourage one to forget important details. Similarly, writing a good report takes time. Rushed jobs are likely to be poorly written, contain partial information, and have poorly structured arguments. Budgeting time to write good reports and planning around required deadlines is essential. For example, the Formula SAE team previously required technical reports to be written by the end of the academic term. The spring reports in particular were of sporadic quality as a result, because the report deadline coincided with the end of competition and most team members were too tired to care enough to write a solid report. Moving that deadline up and making spring reports more closely tied with fall reports significantly increases the chances of well-written documents.