Guidelines for Writing Reports
Part of the grade for projects is based on the clarity and quality of the report. You get credit separately for completing the calculations/project successfully.
The reports (and indeed oral presentations) are meant to be an opportunity to practice your communication skills. These will be among the most useful skills you develop in engn courses. Since we tend to end up in a specialized field of engineering, we make daily use of material from only a subset of the courses we take, but we all write a heck of a lot of reports.
So when we grade the reports, we aren't looking for just a write-up of what your team did. Rather, we have the following 'big picture' questions in mind:
1. Would a person unfamiliar with the project be able to understand the report?
2. Is the report organized so a busy person can quickly understand (a) the problem that was solved; (b) why the problem was solved (c) What was the solution to the problem?
3. Does the report include all the information that would be necessary for someone to repeat the design process/calculations/experiments?
There is no 'right' or 'wrong' way to write a report - if your readers like it and learn from it with a minimum of pain, it's a good report. If not, it's a bad one. Often we write a report or paper (or, for those of us teaching classes, a lab or project description, an exam, or a homework problem) and think it's great, and it turns out to suck. Such is life. Actually, writing a report is a lot like human-centered-design - a good starting point is to put yourself in the position of your reader, and try to predict what they will want to see in your report. This is particularly important when you write a proposal (eg for a contract or grant), because the quality of your proposal has a huge effect on its chances of success.
That said, the following structure is very commonly used in engineering reports and is usually effective (proposals are different, but given the miserable success rate of my own proposals I am not the right person to advise you how to write those) . Not all of this is needed for class project reports - as long as those address the three 'big picture' questions they are effective, but the structure still helps guide what you might put in your reports.
1. Title, authors, affiliation/contact info
2. Executive summary or abstract. This should be something that your colleagues can read quickly and essentially understand everything that was done and your recommendation/conclusion, without having to read the rest of the report. It should be as short as possible.
3. Introduction - Explain why the problem you've solved is important and useful; cite relevant prior work; provide a high-level introduction to what you've done and why it is important, and help readers understand how the rest of your report is organized.
4. (titles/sections vary according to the content of the report) Describe the details of design process/analysis/experiments
5. Conclusions.
6. Acknowledgements (funding sources, eg)
7. References
8. Appendices - anything that would be needed to repeat the work done in the report but which is not important for the reader to understand the conclusions.
You readers (and in class projects, graders) will also evaluate the quality of your writing and presentation. As a rough guide:
1. Avoid hand drawn figs unless you are fortunate enough to have visual arts skills rivalling Leonardo da Vinci. Dont cut and paste figures out of the project description we provide.
3. Use an equation editor for equations - no hand drawn symbols, photographs of exercise books etc. The best free equation typesetting program is LaTeX, but it's not very easy to use and a bit of an over-kill for just a class project. MS Word and Pages both come with equation editors. Mathtype is a more user-friendly point-and-click editor with some nice features, but it has a subscritption fee.
4. If you use a symbol in an equation, it must be defined in the text.
5. Double check that graphs have labeled axes
6. Make sure graphs and figures have a caption
7. Make sure units are provided everywhere they are needed
8. Some people will tell you to avoid using the first person, and may even tell you to use the passive voice everywhere in technical writing. I don't like this rule very much and we don't insist on it in engn40, but be prepared to modify your writing if need be.
And finally - two last things -
1. Try not to write your report as a blow-by-blow account of what your team did. The conclusions are what the report is supposed to present. What the team did is much less important.
2. The report is an important part of the project. It's tempting to dump it on the team-member who never showed up to group meetings. Sometimes this works out OK, but it's risky! (It can be a bit like giving all the solos to the person who never showed up to band practices).
If you need more information about technical writing a google search will turn up a vast number of guidelines and books that may be helpful.