I was on an awards committee for the School of Engineering this year, attempting to give awards to the best undergraduate projects. The process is interesting, because the projects span a wide range of different disciplines and levels of sophistication. We had faculty as judges whose fields were computer science, computer engineering, biomolecular engineering, and technology management (no EE faculty this year). I was the “biomolecular” judge, though my training was in math and computer science and I taught computer engineering for over a decade before switching to biomolecular engineering. I was probably the only one of the judges who was at least somewhat familiar with all the fields represented by the projects, which is the first main point:
- An award-winning project has to be comprehensible to someone outside the group.
- Not only does the project description need to state the design goal (or research question) clearly, but it also needs to provide a justification for why anyone would care. Several of the project descriptions seem to have been written solely for the head of the lab with no material to help someone from outside the lab understand what was going on. These were not award-winning—they may have been good research, but the presentation did not make that clear. The more esoteric the research, the clearer the statement to outsiders needs to be.
A good heuristic for student reports (at all levels from freshman essays to PhD theses) is to write to an audience of people who might be interested in joining the research group, but aren’t yet in that field or subfield. So a senior design report should be written with juniors in the same major as the main audience, with a somewhat more general intro and conclusion. If you learned something in the process of doing the project, you can’t assume that your audience has already learned it.
For some of the projects, I had a hard time figuring out what the students were trying to do and what they had actually done, which brings us to the next three points:
- An award-winning project description starts with a simple statement of the design goal or research question.
- I don’t want to read three or four pages of background about a field before finding out what the project is. Start with a simple statement of the problem in one or two paragraphs, then give the background, justification, or work by others needed to put it in context.
- A thesis or student project report exists primarily to establish what the students have done.
- I get tired of reading reports full of passive voice, in which things happen, but no one does things. I want to know who did what: what the students did, what was done by other lab members, what was purchased, what was done by collaborators elsewhere, and so on. For a senior thesis, which is a single-author work, there should be much more “I” than “we”, and the plural should only be used when the other people involved have been explicitly and unambiguously named.
A thesis is not about science or engineering, but about the particular contributions of a specific person to science or engineering. A senior design report may be a team effort (and so “we” may be more appropriate), but it is still mainly about what the team accomplished, not about the product they produced.
- A project report must be specific and detailed.
- In general, a thesis provided more detailed information than a journal paper, which in turn was more detailed than a poster, which was often more detailed than a set of slides. We tended to favor more detailed reports (whether single-author or multiple-author) over shorter summaries, and complete reports are better than proposals. Since the deadline for awards is earlier than the end-of-the-year deadline for design reports and theses, there is an enormous advantage to students who write as they do the work, rather than pushing the writing to the end of the project. (Students who write as they go also generally produce better writing and do better engineering, because they are not letting themselves get away with fuzzy thinking, but making sure that they can explain themselves every step of the way.)
Of course, no project can win an award unless good work is done, which brings us to the last point:
- Award-winning work is carefully done as well as carefully described.
- Engineering awards are given for good engineering, not for sloppy work full of obvious errors, nor for proposals that five minutes’ thought would show have no hope of succeeding. The judges may not be in your field, but they are engineers and they pay attention to details. There were several projects that I saw this year which raised red flags, and I spent a little time on Google searches or Wikipedia to check to see whether what the students said was reasonable. Occasionally, I found that I had a misunderstanding of a subject and I re-read the report with a corrected knowledge base. More often, I found that students hadn’t done even simple sanity checks that are apparent to people well outside the field.
Although I said above that a report is “mainly about what the team accomplished, not about the product they produced,” it is still essential to have a good description of the product, with detailed block diagrams, schematics, program pseudocode, or whatever other documentation is needed to communicate the design. The goal should be to have a report that could be handed over to a new team, who could then continue the project without much delay.