The Project Report - Presentation Advice
Whilst the Marking Scheme for projects gives details of the topics that will receive marks, a report that keeps strictly to these items only is likely to be very boring indeed! Thus, whilst each of the topics must be covered, this should be done within a larger framework. A well written and interesting report is likely to gain more marks than one that just follows the marking scheme; in particular it will make the difference between a good project that is awarded over 70, and an excellent project that wins a prize. These notes are intended to explain the difference, though they will need to be interpreted for each project since "one size does not fit all".
A project report should explain not only what was done, but why it was done. In addition this explanation takes place on a number of different levels. The writer of any report must constantly think of the reader. For a student's report, the reader should be assumed to be someone who has taken the same course as the writer, but who has no knowledge of the application being developed. Thus "simple" technical issues that have been covered in a module can be stated without explanation, but the application itself will need to be described in some detail.
A project report tells a story. In fact it should tell three stories - simultaneously. Story X is the story of the problem. It explains the problem to be solved, what it is and why it needs to be solved (often this is called the "Business Case"). Later in the report Story X continues with an explanation as to why one solution has been chosen, as distinct from another, and why this is suitable for the problem (for the Business Case). Towards the end of the report Story X concludes with an explanation as to how well the final solution satisfies the problem. In the event that something outside the student's control results in the solution failing to satisfy the problem (fully), this should be explained, possibly with statements of what would have been done, and due account will be taken by the examiners.
Story Y is the story of the solution. It provides the technical explanation of possible solutions for the problem, and why the chosen solution is suitable (technically). It continues with a description of how the chosen solution was developed, the difficulties that were encountered and how they were resolved. Whilst techniques that have been covered in modules do not need to be explained, their use may need to be justified (unless it's obvious). New techniques learnt for, or developed from, the project should be explained.
The third story, Story Z, is unusual in a technical report, though it is required in a project report. It is the story of how, and why, the author approached the project in the way that s/he did, and what s/he has learnt from the exercise. Only real decisions should be explained - an example of an unreal decision explanation is why one person did not use a project lifecycle that is intended for use in large and long projects with 10's, or even 100's, of workers.
Whilst Story Z is normally covered in separate sections, Stories X and Y are usually inter-twined as explanations of how the solution was developed to satisfy the problem are developed. Key issues to be covered are mentioned in the Marking Scheme, but whether the report is excellent or not depends on how it is put together. A well written report flows nicely, is presented logically, and is easy to understand (note that the often used phrase "presentation is everything" applies to both the layout and to the contents). More time should be spent describing the "difficult" bits, and less time spent describing routine, or obvious, actions (though they often do need to be present). Reports that have the potential to attract a prize display a "spark" which is difficult to describe, but easy to detect; in particular it is clear to the reader that the author is fully master/mistress of his/her subject.
PHJ, 09/07