How to write a project report

The project report should introduce the reader into the topic of your project as well as highlight and discuss the main results. As target audience imagine someone who works in the broader domain but is not familiar with the project. With the help of the report an independent researcher should be able to follow the aim of the project and to understand your results. The introduction and the discussion should help to see your project in the broader scope of the domain. Finally, all results should be reproducible with the information in the protocol together with the source code.

Title page

The title page should contain:


The introduction gives the reader the required background of the domain as well as the state of the art and introduces all projects, methods and data needed for the project of the course. At the end of the introduction your project should be shortly introduced, mainly what is the aim and how it will help to improve the understanding of the domain.

Material and Methods

This section collects all the information needed to reproduce the results. All resources used and other projects you used data from should be listed together with version or the date you accessed them. Known methods, used data sets, established pipelines or protocols, used tools, packages or software should be shortly described. In addition, the tools and programming languages you used are listed here with the used versions. Appropriate references to literature, databases or web-resources should be included. The material and methods section should have subsections for the individual methods or material/data used.


The result section is the main part of the lab report and present the results of your work. Depending on the type of your project the focus can be on a newly developed method, the implementation of an algorithm, the resulting software, simulation or testing results or on the produced data. If you implemented a significant software (more than a short shell script), the structure of the tool(s) and the workflow can be described. Why was something implemented as it is and how do the several components work together to process the data? Crucial parts can be presented as pseudo code to allow a better description. In general, the source code is not part of the report, but should be submitted in a documented form, together with the report. For the generated data make sure, that it can be reproduced. Note down the required parameters and processing steps. If you wrote a shell script to automate a workflow, refer to the script and describe the single steps.  With subheadings the text can be structured and the different steps or tasks can be lined out. A short sentence to note the purpose of the next step facilitates the reader to follow your project (e.g. load data/images; reformat data; derive descriptors; test statistics). The results should be presented in a neutral way without judgement. The discussion section is the right place for the interpretation of the results.


The discussion takes up the work proposed in the introduction and reviews the results and sets them in the context of the domain. It should be discussed if the results correspond to the prior expectations or why they do not. Do the results fit to the results of other projects or do they contradict? Also, any shortcoming or new questions can be mentioned and explained.


The references are noted as number in brackets or, preferable, the author and the year, e.g. (Wilmut et al., 1997). In the bibliography all references have to be formatted in a uniform way. This is best done by using a citation manager and selected a citation style, like “Cell Press” for this example:

Wilmut, I., Schnieke, A.E., McWhir, J., Kind, A.J., and Campbell, K.H. (1997). Viable offspring derived from fetal and adult mammalian cells. Nature 385, 810–813.
It is encouraged to use a citation manager like Zotero (recommended), citavi, mendeley, endnote, bibtex or the like to manage your references, which facilitates the reorganisation of text blocks with references in the document and automatically generating the required reference list for the document. If possible use articles from journals instead of web pages. If you refer to a specific data set cite the resource and note the identifier of the data set. If you have to cite a web page, always add the date when you accessed it the last time.  If you use images in your report that are not made by you, always check the copyright (it may be relaxed for academic use) and mention the source and author in the figure legend as well as if you modified it (e.g. Modified after …)


Figures must be numbered and always have a figure legend. The reader has to be able to understand the figure with the legend without the main text. All sub-figures, arrows, letters and numbers should be explained. Every figure has to be mentioned and referenced in the main text.

Source code and data

Your source code and produced data should be documented and submitted together with the lab report as a zip file of folder. Each file should contain a short comment of its purpose and comments in the source code and descriptions of the main functions will help also for a better understanding. If source data is not large or not easy to download from the internet it should be also contained in the zip file. Otherwise links to the required data-sources or repositories should be included in the description. The same applies for the produced data or results, if not easy to reproduce the resulting data files should be included or otherwise a clear description or script of how to reproduce the data. A short readme-file and a table of content has to be included to understand the different files. In case of data files also mention the version or how it was generated. The zip file should contain a cleaned set of files, all of the temporary files, results from test-runs or large data files that can be easily reconstructed should be removed.