writing_a_project_report [PATS2]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Writing the Project Report ======

Once you have gathered and organised enough material you can turn it into written prose. To write effectively requires sustained concentration over long periods of time. Even with the incremental authoring possibilities that word processing offers, writing is best done in long uninterrupted sessions. Most people find it difficult and tiring.

There are rules you can follow which may make the task easier and which will certainly improve the quality of your writing, but unfortunately there are rather a lot of these and in a guide of this size we can only offer a few pieces of general advice:
  * keep your potential readership in mind;
  * identify commonality;
  * use sections and subsections to structure your work and to provide appropriate breaks for the reader;
  * do not include "padding" - include only what is necessary to "tell the story" and justify your work;
  * follow appropriate academic and professional stylistic conventions. We recommend that you read journal papers relevant to the general area of your project, as well as project reports held in the library and online; this is a normal research activity.

The project report's structure does not necessarily dictate the order in which you write it. If you want you can start by writing the Introduction, then the Background section, and so on, but this is up to you. Some people start by writing the Introduction first which gives direction to writing the other sections, but others prefer to leave writing the Introduction until last, as reports rarely turn out as planned. We recommend that you start with the middle sections, then write the Introduction (guiding the reader to what they will find in the report), then the Conclusions (bringing the report together at the end) and Reflection, and finally the Abstract (summing up the entire report). However you tackle the writing up, we recommend that you:
  * write as you go along, rather than leaving all the writing until last (writing takes longer than you think, and is best done when the ideas remain fresh in your mind);
  * leave time for someone you trust to proof-read your work, and for you to correct errors (it is not your supervisor’s responsibility to correct your written English);
  * read your work out loud to yourself. There are many advantages to this, not least the realisation that if you run out of breath your sentences are probably too long. Mainly, however, if you read "silently", you will tend to read what you meant to write, rather than what you have in fact written, and will run the risk of missing errors.

===== Potential Readership =====

Always keep your potential readers in mind and repeatedly review what you have written, putting yourself in their place. Look at the draft, sentence by sentence, and ask yourself: 'Will this make sense to the readers given their existing knowledge and what I have told them up to now?' You can consider the potential readership as
  * your academic supervisor,
  * your project moderator/internal examiner,
  * the external examiner (usually a computing professor from another university),
  * and quite possibly future students and others interested in the topic.
So, as noted earlier, do not explain things which are common knowledge to such readers.

Also, if your project report is of sufficient quality, your supervisor may consider submitting part of it to a journal for publication as a paper, in which case it may eventually be read by a substantial number of computing and other professionals.

===== Identifying Commonality =====

You can often both clarify text and reduce its bulk if you can identify generality or commonality among the ideas you are expressing. You can then revise the text so that the common factors are described first, followed by details of how specific individual ideas differ from them.

===== Sections and Subsections =====

The main body of the project report should be divided up into sections, along the lines suggested in [[Arranging Material and Structuring the Project Report]] or otherwise, as appropriate. Each section should, if necessary, be divided up into subsections, and so on recursively. Such nesting can be used to suggest some kind of hierarchical relationship between sections. This can become obscure though if the nesting gets to more than about three levels deep.

It is important that you start each section and subsection with a summary of the rest of the material in it, i.e. inform the reader of what you are about to tell them. This has the effect of "softening up" the reader so that when they move on to the body of the section they feel confident about the direction in which you are taking them. They are reassured at regular intervals when they encounter ideas that you have told them to expect. Without the overview the overall effect is like a mystery tour of ideas, with each new idea coming as a surprise. It is sometimes difficult to appreciate the need for this when you are the author because you are already intimately familiar with the whole route that the report takes.

Each major section should begin on a new page. All sections and subsections should be numbered and headed. Numbering should be like this: 3.10.7 – for subsubsection 7 in subsection 10, in section 3.

===== Stylistic Conventions =====

There are all kinds of stylistic conventions relating to technical writing that you should try to follow. For example:
  * do not use shortened forms such as "don't" for "do not";
  * avoid colloquialisms and slang words;
  * use British English and write in complete sentences;
  * divide your writing up into paragraphs;
  * generally, you should write in the "third person". The "first person" can be used, to avoid the report becoming stilted, though it is recommended that its use be limited; for example, it may be appropriate to use "I" when stating an opinion rather than the common "It is the author’s opinion...". 

Writing where the language style or typography, e.g. font or character size, change arbitrarily looks amateurish and can be very distracting for the reader. Use typography to support the content. Other places where consistency should be maintained include:
  * bullet points,
  * use of hyphens,
  * use of capitalisation,
  * technical terms,
  * abbreviations,
  * use of symbols.

To some extent you can use your own judgement about what conventions to follow. Whatever you do though, you must be consistent.
Site Tools

Page Tools
