navigation page

Project report writing.

(Both Undergraduate and MSc.)



Book resources

For a plentiful supply of books on "how to write technical reports" go to either

Blackwell's bookshop

or (if you must), to

Amazon

and enter the phrase technical report writing in the subject or title search fields.



General remarks

One of the problems in writing a page like this, which hopes to satisfy the demand from students for information on how to write project reports for submission as part of the course-work requirements for degrees at the University of Surrey, is that the reader will be tempted to take the advice as a firm prescription.

There are many different kinds of projects, and many different kinds of appropriate project reports. Therefore the advice tendered here is of a general kind, setting out the principles behind a successful project report, rather than a prescription for the detailed structure, which will necessarily vary from project to project.

The advice here is also written from the point of view of an examiner who has read several hundred project reports in the past, and who has ideas about what makes for a good report.

Consider the reader.

In any piece of technical writing it is important to slant the style of the report towards the intended reader(s). In the case of the project reports considered here, the primary reader will be the examiner and the secondary reader the supervisor. The most important from your point of view is the examiner. Consider that (s)he will have a preferred rate for the presentation of information. Try to match the rate at which ideas are presented to the abilities of the examiner. It is not necessary to compromise the style of the report so that it can be read by a range of people with differing backgrounds and points of view.

Your examiner is faced with the task of reading 10-20 project reports like yours over a period of at most 48 hours. The examiner will not have much idea about your project except for the title. Therefore you need to create in the mind of the examiner, a clear idea of what was the intention of the project, what was your contribution, what were your sources of information, and what you personally achieved, within several minutes of first opening your report. If you can achieve this, then the report has done its work regardless of how successful the project was technically.

Overall structure

It is best if the report proceeds from the more general overview to the more detailed considerations as the project is read. Examine how you yourself read things. You probably pay much attention to the first page or two, then if you haven't grasped what the content is about you tend to lose interest and skim idly through the remainder trying to find significant ideas. These may or may not be forthcoming.

In the past many project reports have failed to leave the examiner with a clear idea or feel for the project; that is why we also run oral project exams, which usually establish the facts far faster and more accurately than can be done by the report. This is one of the reasons academics go to conferences to present their papers, rather than just relying on the written word.

The report therefore has two purposes. First, it has to create an initial impression, and then it has to fill in detail after the message has been conveyed by the oral presentation. At the time of the oral, many students have often said "as you will have read in my report..." and then refer to some arcane point of detail. It is not reasonable to expect the examiner to have gained more than a general view of the project from the report, particularly given the time pressures (s)he is under. Therefore the detail in the report is primarily there for reference purposes; for students who come later and read the report, and for completeness. Such detail may not make the impression intended.

Advice (not prescriptive).

Objectives and results first.

It is best to present the objectives of the project, and the main results and outcomes, clearly in the first two or three pages, possibly in the abstract but certainly in the introduction. The personal contribution you made should be clearly stated. Therefore you need to specify your sources of information...

Methods and references to other work next.

The references list of course comes at the back end of the report, but the pointers to it should be in this section.

The methods used (constructional, measurements, software design procedures, etc) should follow, with detailed references to the sources of information. References should be full; title, author, date, publication, page numbers, ISBN or ISSN number where appropriate, where the information is shelved possibly (if it is a data book from the lab for example), or the Internet url or phone number of the person giving a "private communication". References should be actually referred to in the text, therefore for example write "see reference 23" if you want to refer to a data sheet for a transistor type, for example. Don't photocopy the data sheet and bind it into the report for padding purposes; a clear reference is sufficient.

Results

A results section should follow. Testing of the project, apparatus used, measurements taken, graphs, tables, photographs, and so on.

Discussion

Now comes the discussion section, where you compare the results with the intentions of the project. If you wish to include an indication of the chronological development along which the project proceeded, it may well be placed here. You can also give an indication of the scope for future work, and discuss how you might have approached the project differently were you to do it again. You might also indicate what you learned from the project, and put in any comments on the factors which enabled or impeded the project.

Conclusions.

Here you summarise the main objectives and results, as in the introduction, but from the perspective of the reader who has read the intervening chapters and needs reminding what it was all about.

References

Here is the list of references.

Appendices

Here you put the supporting detail. It is best to err on the side of conciseness, so don't bind in absolutely everything that is relevant. In the appendices you place for example, earlier designs of your circuit which did not work, your list of measurements on intermediate stages of the project, and, in general, anything which YOU did yourself which does not appear elsewhere. Please keep other people's output out of the report altogether; in the past many reports have consisted of several pages of the student's own work and many tens of pages of textbook material and data sheets, etc. This does not impress the examiner who is under time pressure. (S)he wants to know what was YOUR personal contribution.


Copyright D.Jefferies 1998
D.Jefferies email
8th January 1998