School of
Information Technologies
General Guidelines for Final Project Report
Also see specifications in the Report Marking Guideline to be found on the course web site under “Marking
Guides”.
Style, layout and length
A ‘boilerplate’ (Project Report - 'boilerplate') is provided on the course web site for your guidance. You should
deviate from this only when you are sure have a good reason. You should also use the Word template provided
(ISYS3207 Word Document Template (.dot file)) unless you are confident that they can improve on the
typography suggested.
A nominal length of 20 pages is suggested for the report. This does not mean that it has to be this long. If the
report is excessively long it will fail to serve its purpose, which is to solve the client’s problem, because the
client will not have time to read it. There is some merit in being able to identify the key issues for your client
and to write succinctly.
Intended audience
The Project Report should be written with the client in mind as the intended audience. There is a tendency for
teams to write their report with a view to ‘fooling the examiner’ rather than informing the client. For example
the use of flowery language and vague references to impressive sounding theories, rather than ideas expressed
clearly in lay terms will not attract good marks. Teams should take great care to find the exact word to use in
each case. Take care that specific or technical words are used correctly.
The role of ‘proof reader’ of the document is crucial. It is important not to let through any spelling errors,
inaccuracies or poor expression. Good layout is also important.
Sections of the report
1. Introduction and motivation
Almost universally introduction provided are too brief to be useful. Whilst for the Project Proposal the length
had to be limited in the final Report there is ample opportunity to set out all aspects of the client’s current
context and activities so that the research question or information systems problem becomes obvious. It should
contain substantive facts about the client’s “world” that impact on the question or problem being researched and
how it was dealt with. It should be at least two or three pages in length.
There should be no need to supply any further details or information in the subsequent sections such as the
problem definition or objectives. You should be able to demonstrate to your client that you really do understand
what they do and why they want the research done or the problem solved.
No mention of the “requirements of the course ISYS3207” should be included. The proposal is intended for the
client to read. It should be ‘a compelling read’ so that your client will be motivated to read on.
2. Research question or problem definition
This section should brief and clear, with a wording like:
“The following problems facing the client were identified:
1.
It is at present not possible to …,
2.
etc etc”
The wording of the numbered items must be consistent with the stem (“problems facing the client were
identified:”). Often new material (explanations, details, etc.) is included in this section that should have been in
the Introduction. This should be removed and placed correctly.
3. Objectives
This section should also be short and succinct, with wording like:
“The objectives of the project were :
1
1.
to facilitate the collection of ….
2.
etc etc”
Once again, the wording of the numbered items must be consistent with the stem. Often the objectives are
confused and are not really testable, that is, the client needs in principle to be able to test at the end of the project
whether or not the objectives have been achieved.
4. Review of literature and related work
Do not simply list every book, article and web site you looked at. Some attempt must be made to evaluate the
worth of various sources in terms of the research question and the needs of the client. Each source reviewed
must be properly cited. Remember that the references are for the client’s benefit and should demonstrate that
you have properly researched the problem domain. In the case of system development projects some attempt to
evaluate existing systems of similar type should be evident. Quality here is more important that quantity and
your evaluation in terms of your client’s needs is crucial.
5. Methodology
This section perhaps should have been called “method”, rather than “methodology”. It is all right to mention
some of your favourite methodologies, but really the client is not all that interested. What he or she wants to
know is “what you did” in order to answer your client’s question or solve your client’s problem.
This section of the Report is in many cases too brief and does not clearly indicate step by step how the team
went about the investigation. It should be one or two pages in length. If you refer to methods and techniques that
you have read about elsewhere then you must also indicate to the client how these techniques are relevant and
whether they turned out to be useful in the present project.
The Report should list the steps actually taken in sufficient detail that would enable the client to replicate the
work. It should also explain any changes from the steps suggested in the Proposal and why they were made.
6. The Research
Prototype Development
or
This is the major section of the Report. It can be several pages long. See Report Marking Guideline for details.
The content will vary widely depending on the project, but it should be the major part of the report and it should
attempt to answer the client’s research question or explain how their problem can be solved.
You might want to break it down into subsections for clarity. Still the writing should be clear and succinct,
remembering that your client is a busy person who want answers not a lot of flowery language and padding. Do
not include material that the client will not want or have time to read. Some material, such as results of a survey
or experiment, or user evaluation, can be placed in an Appendix if it is though to be important but not essential
for the report. This will not count towards the length, nor will it be assessed. It is for the client’s benefit.
If you have developed a prototype system then you can refer to this and maybe include some screen shots, but
the key thing to do is to show how such a system will help solve the client’s problem.
In either case you should include mention of how the client’s response to the research was evaluated.
7. Summary of findings
This needs to be short and punchy, a kind of executive summary. It should provide your client with a clear idea
of what you set out to do, what you did. Your client may well read this section first.
8. Recommendations
The recommendations should indicate to your client what he/she should do next as a result of your research. I
might describe how to go about implementation. If your work failed, it might suggest what to do instead.
9. References
References should be limited to those that actually proved useful for the research and that the client may find
useful in solving their problem. It is not intended to be a ‘bibliography’. It should only include those sources
discussed in the Literature section, but should be properly referenced so that the client could look them up.
Geoffrey Kennedy
Unit Coordinator
2