Skip to content


Although projects may have widely different durations, they typically follow a similar structure as illustrated in Fig. 1.

Project structure

Figure 1: Correspondence between the project structure and the report

In Fig. 1, the blue boxes correspond to the main activities that make up the project while the green boxes correspond to the main sections of the final project report. Choosing a topic is shown in orange because it is best to think of that stage as taking place before the project starts. Most of the elements of the diagram are discussed in detail in later sections of these notes. However, there are a few points specifically related to the diagram that are worth pointing out.

The abstract

Although the abstract appears at the beginning of the report, it should be written last. That is because it summarises the whole report in less than one page. This differentiates it from the introduction in that it includes a summary of the methods, results and main conclusions as well as introducing the problem.

The practical work

The diagram shows the practical work as an activity that occurs after the project method has been defined. This is not strictly speaking accurate: it is better to think of dividing the practical work into two phases. The first is where you try things out in an ad-hoc fashion to test out options, compare alternatives and generally reassure yourself that your methods are feasible. This is best done in parallel with the background research. As you go through this first phase, you should make notes about the things that you try and about any decisions that you make. These notes will be useful when you come to describe your methods in the methodology chapter. You should also carefully store away any small pieces of code or other early results that you think will be useful later on. The more organised you are during this exploratory phase, the easier everything will be later on.

The second phase of practical work is a much more structured and systematic activity in which you carefully follow the plan as defined in the methodology chapter. The Reader of your report is not particularly interested in the exploratory phase; it is this systematic - and therefore repeatable - phase which is the more important.

Another interesting point to notice is that the practical work itself does not typically have a corresponding chapter in the report. In very practical software engineering projects you may see an implmentation chapter which describes the detailed solutions to problems encountered during the project. However, it is more common to focus on the results of the work and how those results address the aim of the project. For example, in a project where the aim is to evaluate the appropriateness of a software framework in a particular context it will certainly be necessary to build some software using the framework, but the main interest is in how appropriate it is and not on the actual implementation itself. In that case, the main report would focus on the evaluation part and any interesting implementation details would be placed into appendices. That is the meaning of the dashed line in the diagram.


The previous section used an example in which the aim of the entire project was to evaluate the suitability of a software framework. In that example, you would report the results of that evaluation in the results and discussion chapter. This is an example of the case where the aim of the project is an evaluation; however, all projects need another type of evaluation in which you evaluate the quality of the project itself. That is the intention behind the evaluation box in the diagram. Ideally, you will have identified an explicit method for judging the quality of the project process and its results. An important feature is that whatever method you use, it should not rely on your own opinion.