Writing a good technical report of your work is as important as carrying out your experiments and technical analysis.Often B.Tech /M.Tech students are clueless about how to go about it.
Well objectively speaking, the first step to start covers the following things :

  • General do's and don'ts (that's plain common sense)
  • Format of the report
  • Draft planning
General do's and don'ts :
  • Avoid spelling and grammatical mistakes or formatting errors.
  • Prefer short sentences to long sentences.
  • Back-up your report in progress in at least 2 to 3 reliable and safe places.
  • Start early, don't wait for the completion of your work in its entirety before starting to write.
  • Feedback should go through the following stages ideally: (a) you read it yourself fully once and revise it, (b) have your peers review it and give constructive feedback, and then (c) have your advisor/instructor read it.
  • Make sure you mention the background to, and aims of, the investigation
    Include the basic concepts and theory relating to the investigation.
  • Describe the procedures used. Identify major sources of error and explain how they were dealt with.
  • Only data directly relevant to the calculation of final results should be
    presented, omit raw data. Graphs are a particularly effective way of
    presenting results – only use table where it would make more sense that
    providing a graph.
  • Final results should be presented clearly and concisely; include an analysis of errors, but omit details of arithmetical manipulations.
    If computer code was used or written, give details of the checks and
    validations you performed on the code.
  • The interpretation of the results must be discussed, and improvements and
    possible extensions of the work suggested.
  • Give references to any books, articles or other sources of information (e.g.
    web sites) that have proved useful in preparing the report, or carrying out
    the work.
Format of the report :

  • Title and abstract: These are the most-read parts of a report. This is how you attract attention to your writing. The title should reflect what you have done and should bring out any eye-catching factor of your work, for good impact.

    The abstract should be short, generally within about 2 paragraphs (250 words or so total). The abstract should contain the essence of the report, based on which the reader decides whether to go ahead with reading the report or not. It can contain the following in varying amounts of detail as is appropriate: main motivation, main design point, essential difference from previous work, methodology, and some eye-catching results if any.

  • Introduction: Most reports start with an introduction section. This section should answer the following questions (not necessarily in that order, but what is given below is a logical order). After title/abstract introduction and conclusions are the two mainly read parts of a report.

    • What is the setting of the problem? This is, in other words, the background. In some cases, this may be implicit, and in some cases, merged with the motivation below.
    • What exactly is the problem you are trying to solve? This is the problem statement.
    • Why is the problem important to solve? This is the motivation. In some cases, it may be implicit in the background, or the problem statement itself.
    • Is the problem still unsolved? The constitutes the statement of past/related work crisply.
    • Why is the problem difficult to solve? This is the statement of challenges. In some cases, it may be implicit in the problem statement. In others, you may have to say explicitly as to why the problem is worthy of a BTech/MTech/PhD, or a semester project, as the case may be.
    • How have you solved the problem? Here you state the essence of your approach. This is of course expanded upon later, but it must be stated explicitly here.
    • What are the conditions under which your solution is applicable? This is a statement of assumptions.
    • What are the main results? You have to present the main summary of the results here.
    • What is the summary of your contributions? This in some cases may be implicit in the rest of the introduction. Sometimes it helps to state contributions explicitly.
    • How is the rest of the report organized? Here you include a paragraph on the flow of ideas in the rest of the report. For any report beyond 4-5 pages, this is a must.

    The introduction is nothing but a shorter version of the rest of the report, and in many cases the rest of the report can also have the same flow. Think of the rest of the report as an expansion of some of the points in the introduction. Which of the above bullets are expanded into separate sections (perhaps even multiple sections) depends very much on the problem.

  • Background: This is expanded upon into a separate section if there is sufficient background which the general reader must understand before knowing the details of your work. It is usual to state that "the reader who knows this background can skip this section" while writing this section.

  • Past/related work: It is common to have this as a separate section, explaining why what you have done is something novel. Here, you must try to think of dimensions of comparison of your work with other work. For instance, you may compare in terms of functionality, in terms of performance, and/or in terms of approach. Even within these, you may have multiple lines of comparison -- functionality-1, functionality-2, metric-1, metric-2, etc.

    Although not mandatory, it is good presentation style to give the above comparison in terms of a table; where the rows are the various dimensions of comparison and the columns are various pieces of related work, with your own work being the first/last column. See the related work section of my PhD thesis for an example of such a table :-).

    While in general you try to play up your work with respect to others, it is also good to identify points where your solution is not so good compared to others. If you state these explicitly, the reader will feel better about them, than if you do not state and the reader figures out the flaws in your work anyway :-).

    Another point is with respect to the placement of related work. One possibility is to place it in the beginning of the report (after intro/background). Another is to place it in the end of the report (just before conclusions). This is a matter of judgment, and depends on the following aspect of your work. If there are lots of past work related very closely to your work, then it makes sense to state upfront as to what the difference in your approach is. On the other hand, if your work is substantially different from past work, then it is better to put the related work at the end. While this conveys a stronger message, it has the risk of the reader wondering all through the report as to how your work is different from some other specific related work.

  • Technical sections: The main body of the report may be divided into multiple sections as the case may be. You may have different sections which delve into different aspects of the problem. The organization of the report here is problem specific. You may also have a separate section for statement of design methodology, or experimental methodology, or proving some lemmas in a theoretical paper.

    The technical section is the most work-specific, and hence is the least described here. However, it makes sense to mention the following main points:

    • Outlines/flow: For sections which may be huge, with many subsections, it is appropriate to have a rough outline of the section at the beginning of that section. Make sure that the flow is maintained as the reader goes from one section to another. There should be no abrupt jumps in ideas.
    • Use of figures: The cliche "a picture is worth a thousand words" is appropriate here. Spend time thinking about pictures. Wherever necessary, explain all aspects of a figure (ideally, this should be easy), and do not leave the reader wondering as to what the connection between the figure and the text is.
    • Terminology: Define each term/symbol before you use it, or right after its first use. Stick to a common terminology throughout the report.
  • Results: This is part of the set of technical sections, and is usually a separate section for experimental/design papers. You have to answer the following questions in this section:

    • What aspects of your system or algorithm are you trying to evaluate? That is, what are the questions you will seek to answer through the evaluations?
    • Why are you trying to evaluate the above aspects?
    • What are the cases of comparison? If you have proposed an algorithm or a design, what do you compare it with?
    • What are the performance metrics? Why?
    • What are the parameters under study?
    • What is the experimental setup? Explain the choice of every parameter value (range) carefully.
    • What are the results?
    • Finally, why do the results look the way they do?

    The results are usually presented as tables and graphs. In explaining tables and graphs, you have to explain them as completely as possible. Identify trends in the data. Does the data prove what you want to establish? In what cases are the results explainable, and in what cases unexplainable if any?

    While describing a table, you have to describe every row/column. And similarly while describing a graph, you have to describe the x/y axes. If necessary, you have to consider the use of log-axes.

    If you are presenting a lot of results, it may be useful to summarize the main take-away points from all the data in a separate sub-section at the end (or sometimes even at the beginning) of the results section.

  • Future work: This section in some cases is combined along with the "conclusions" section. Here you state aspects of the problem you have not considered and possibilities for further extensions.

  • Conclusions: Readers usually read the title, abstract, introduction, and conclusions. In that sense, this section is quite important. You have to crisply state the main take-away points from your work. How has the reader become smarter, or how has the world become a better place because of your work?

Draft planning :
  • Identify the story you wish to tell. Often this can be simply done bydeciding which diagrams and graphs of data you wish to include.
  • Draw up a plan of what you want to say and how this fits around thediagrams/graphs you want to use.
  • Extend you plan to an outline that includes all the section headings youwill need.
  • Check through the outline to see that sequence is sensible and thatnothing vital has been ignored.
  • Check your outline through with someone else e.g. fellow student, tutoror demonstrator.
  • Write a first full draft of the report.
  • Check the first draft through for consistency, obvious errors andomissions (e.g. figure captions missing? References still to do?) If you can get a friend to read through it critically so much the better.
  • Revise the draft and re-check until satisfied.
  • Submit report.


Project report templates :
B.Tech/UG Project report template

M.Tech/PG Project report template

How to Write a Technical Report 1204833578131877 3

0 comments

Post a Comment

Your feedback is valuable.