How to Write a Good Report
Bhaskaran Raman, Apr 2004

This short document describes how to write a good report. This is based on common mistakes I have observed over a period of time. While most of the following apply in general, they have been written with BTech/MTech/PhD students in mind.

The comments below apply for course projects, other semester projects, technical reports, theses (BTech/MTech/PhD). That is, technical writing in general. While a google search on the topic may churn out many hits, the following is tailored for IIT (Kanpur) students in particular.

I will first mention some general guidelines, then the structure of the report. Towards the end, I will also describe how to refine your writing, and how to give feedback on others' writing. Based on these, I will recommend a possible strategy for producing high-quality reports which have high potential for being published.

General Guidelines

These are some general things you should know before you start writing. I will try to answer the questions of the purpose of report writing, and the overall approach as well.

Purpose of a report: writing to be read

A key thing to keep in mind right through your report writing process is that a report is written to be read, by someone else. This is the central goal of report-writing. A report which is written for the sake of being written has very little value.

Before you start writing your report, you need to have in mind the intended audience. In the narrowest of possibilities, your report is meant for reading by yourselves, and by your advisor/instructor, and perhaps by your evaluation committee. This has value, but only short-term. The next broader possibility is that your report is readable by your peers or your juniors down the line. This has greater value since someone else can continue on your work and improve it, or learn from your work. In the best case possibility, your report is of publishable quality. That is, readable and useful for the technical community in general.

Overall approach: top-down

Take a top-down approach to writing the report (also applies to problem solving in general). This can proceed in roughly three stages of continual refinement of details.

  1. First write the section-level outline,
  2. Then the subsection-level outline, and
  3. Then a paragraph-level outline. The paragraph-level outline would more-or-less be like a presentation with bulleted points. It incorporates the flow of ideas.

Once you have the paragraph-level flow of ideas, you can easily convert that into a full report, by writing out the flow of ideas in full sentences.

While doing the paragraph-level outline, think also about (a) figures, (b) tables, and (c) graphs you will include as part of the report at various stages. You will find that many things can be better explained by using simple figures at appropriate places.

Another thing to nail-down while doing the paragraph-level outline is the terminology you will be using. For instance, names of various protocols/algorithms/steps in your solution. Or names/symbols for mathematical notation.

The overall approach also includes multiple stages of refinement, and taking feedback from others (peers/advisor/instructor). I will talk about these in more detail after talking about the overall report structure.

Structure of a report

The following should roughly be the structure of a report. Note that these are just guidelines, not rules. You have to use your intelligence in working out the details of your specific writing.


No report is perfect, and definitely not on the first version. Well written reports are those which have gone through multiple rounds of refinement. This refinement may be through self-reading and critical analysis, or more effectively through peer-feedback (or feedback from advisor/instructor).

Here are some things to remember:

Feedback: evaluating someone else's report

Evaluation of a report you yourself have written can give benefits, but it usually is limited. Even in a group project, it is not good enough to have one person write the report and the other person read it. This is because all the group members usually know what the project is about, and hence cannot critique the paper from outside.

It is best to take feedback from your peer (and of course return favours!). The feedback procedure is quite simple. The one reading has to critically, and methodically see if each of the aspects mentioned above in the "structure of the report" are covered. It may even help to have a check-list, although with experience this becomes unnecessary.

When I give feedback on a peer's report or a student's report, I usually take a print-out and mark-up at various points in the paper. You may follow a similar procedure, or something suited to you. Be as critical as possible, but with the view that your peer has to improve his/her work, not with the view of putting him/her down. Your comments have to be impersonal. Likewise, while taking feedback from a peer, take the comments on their technical merit.

Recommended strategy for producing a high-quality report

Based on the above, I recommend the following strategy for students who want to produce a high-quality report, which would then have a high potential for being turned into a publication:

Bhaskaran Raman
Last modified: Mon May 15 11:04:13 IST 2006