Reporting results
In many ways, the Results chapter is the most important one in the whole project report. After all, this is the payoff for the Reader after going through all the preceding sections. Because the other sections lead up to this point, it is important that the results are described in a clear and systematic way, setting out all the details that the Reader might want to know.
The results themselves should reflect both the aim of the project and the way in which it was carried out. The table below shows some illustrative examples.
present_to_all
| Aim | Method | Format of main results |
|---|---|---|
| Feasibility of a software solution | Build and test prototype | Success rates for a range of test cases |
| Quantify cybersecurity incidents | Longitudinal traffic analysis | Tabulated numerical (possibly statistical) summary data |
| User opinions on project management | Interviews | Description of themes identified |
| Digital media creation | Design thinking + peer feedback | Summary of positive/negative comments |
The link between the results presented and the rest of the project should be clear in terms of their type and format. Ideally, the format of the results should have been seeded in the methodology chapter so that there is no effort required on the part of the Reader to understand the information that is being presented in the results chapter.
For clarity, it is important to maintain a distinction between the results data and your interpretation of that data. The interpretation should go into the discussion section as described below. Other possible errors in the results section include
- Including an overwhelming amount of raw data
- Including redundant or irrelevant information
- Repeating background information or methods
- Ignoring negative results or results that do not support your hypotheses or conclusions
- Presenting figures or tables that include errors or are difficult for the Reader to understand
present_to_all
- What do the results mean?
- Are there any surprises? How might you explain them?
- How do your results compare with other similar published results?
- What limitations are there?
Discussion
Your job as the author of the project report is not only to present the results of the work to the Reader; it is also to explain what they mean. This is the role of discussion. If you have used a statistical method, for example, your results may be a single table of numerical data with appropriate annotations. However, the implications of those figures will not be completely clear without additional commentary.
As part of your discussion, it is common to compare the results that you have obtained with similar studies from the literature. This adds value to your project by making an explicit reference to the context in which it is carried out. It allows the Reader to situate your work in relation to the work of others. For example, are you replicating a previous study for verification purposes? Are you exploring limitations of your context compared to that of others? Have you extended existing work in some way?
There is some flexibility in how your structure the material around results and discussion. One options is to present just the results themselves in one chapter and to provide your discussion of those results in another. That might be appropriate, for example, for a creative digital project where the discussion might centre on how the work related to its specific context and how it could be further developed.
Another option is to combine results and discussion into a single chapter. This might be preferable if your have a series of small results. It would make sense in that situation to present the first result followed immediately by some discussion, and then go on to the next.
Choices like these should be made with reference to the experience of the Reader: which options would work best in your context? Which one would communicate the content most clearly?
present_to_all
- Introduction
- Changes to the plan
- Technical artefacts
- Result 1
- The result itself
- Discussion
- Result 2 ...
- Conclusion
Structure
Assuming that you will be interleaving results and discussion as described above, the following schema provides a template that you can adapt to suit your project. As with many other example structures in these notes and elsewhere, you should not necessarily force your content to conform.rather you should modify the example structure to suit your requirements.
x Results and discussion
x.1 Introduction
All chapters should have an introduction that outlines what is coming up and helps to make the link with the previous chapters. Here, you could identify general points that will help the Reader interpret what follows. For example, if your project relies on a questionnaire as your main data collection method, you would provide summary information in the introduction on how many responses you obtained, how many responses had to be discounted for various reasons and the size of the resulting dataset.
x.2 Changes to the plan
The methodology section sets out your intentions. However, your plans may need to be adjusted for practical reasons once you actually start work. This subsection should identify any such changes so that the Reader can adjust their expectations. In doing this, you can highlight additional limitations on the results.
x.3 Technical artefacts
Any project that involves the construction of a technical artefact such as a network design, software prototype, questionnaire, etc. should include a description of the artefact in the results chapter. It may be a summary of the artefact with links to further details in appendices. The amount of detail you include here depennds again on the aim of the project and the needs of the Reader. It the construction of the artefact is itself the main aim of the project, then there should be a substantial amount of detail; on the other hand, if the artefact is a means to an end, there should be less detail with most of the content of the chapter given over to the subsequent data collection and analysis. For example, a project might aim to compare two machine learning approaches applied to the same problem, To do this, it is necessary to construct a software environment where the machine learning algorithms can be executed, but the main interest of the project is in their comparative performance. You would therefore summarise the construction of the test environment and concentrate on the analysis of the performance data.
x.4 Result 1
This section may warrant a short introduction of its own to remind the Reader why it is relevant to the overall aim of the project. In some projects, this may be unnecessary. As always, you should be guided by the effect that you will have on the Reader's experience. Your priority should always be to make the task of the Reader as easy as possible. If that means providing signposting text, for example, that is what you should do. The Reader should never be left wondering what it is they are looking at. On the other hand, you should avoid taxing the Reader's attention by providing superfluous or repetitive material. Getting the balance right is a judgement call.
x.4.1 The result itself
Here, you should present the expected data. Numerical data is typically presented in tables, possible also accompanied by charts. If you choose to present only a chart, you should include the raw data (or a representative excerpt) in an appendix.
For qualitative data, you might present the emergent themes that you have identified accompanied by appropriate explanatory commentary. In such as case, a separate section for discussion may not be needed. However, you should still be sure to make a clear distinction between the result and your interpretation of that result. In qualitative projects, it is common to include excerpts from the raw data to underline specific points that you want to make. These should be used sparingly with the majority of the data relegated to an appendix.
x.4.2 Discussion
This is where you explain to the Reader your interpretation of the result you just presented. You should bear in mind that your personal opinion does not count for much on its own. Any points you make in this section should be accompanied by an argument or rationale. You should also, if possible, make reference to external benchmarks. This provides the Reader with sufficient justification for accepting your characterisation. Try to avoid the temptation to make comments like "From the table it is clear that...". What seems clear to you may not be as clear to the Reader. You need to explain your reasons for believing that the results have such a clear interpretation.
x.5... Further results
Repeat section x.4 as many times as needed.
x.? Conclusion
Once all the results have been presented and discussed, you can summarise the whole chapter here. It would be appropriate to relate your findings to the overall aim of the project. Although that sounds like something that would appear in the Conclusion chapter, that is not really the case. The purpose of the conclusion is to summarise the whole report, but not to present any new information about it. Usually, the main conclusions follow directly from the discussion of results, and it is natural to keep the two things together.
Statistics
Many projects have the potential for the application of statistics during data analysis. There are established conventions for the presentation of statistical results, and you should attempt to apply those rules. There are many references available to help you get the conventions right from blog posts to textbooks.
Remember that every article you have included in your literature review can also act as a model for how to present your work.
Tips for writing a results chapter