Basic structure of a typical project report

Most reports describing a problem-solving exercise have the same basic structure and
consist of about six chapters. The titles given here for the chapters are meant to be
indicative rather than prescriptive - use common sense to decide what is best to permit
your readers to find their way around your report.
This section presumes that you are doing a typical "build an artefact to solve a
problem" project, but the principles embodied in it apply to all types of project,
including business and social science ones. The next section discusses alternative
structures for your report if that is not the case.
1. Introduction
This chapter is essential. It should start off by setting the context for the work. For
example:
         Where did the project suggestion come from?
         Why is it an interesting problem?
         Why hasn't it already been solved?
Usually you start with a very broad statement of the problem and refine that down to
more specifics. The introduction to my PhD thesis started off talking about
programming languages in general before moving on to compilers, then to separate
compilation in general and then to separate compilation in Ada (which was what I
investigated). Unless yours is a problem area with which all readers of your report
will be familiar (very unlikely), you will want to describe the problem in some detail
and give sufficient background information for everyone to understand it.
The introduction should then describe the objectives, aims or goals of your particular
piece of work. Your overall aim was presumably to solve a particular problem or to
answer a particular question. This could be broken down into a number of specific
objectives that together work towards achieving the aim. Few projects set out to solve
a problem completely, so what particular parts did you choose to tackle? These can be
identified as some of your objectives. No project is without constraints, in time,
money, equipment, etc. These inevitably affected your objectives. Say how.
The introduction should end with a section that leads the reader in to the rest of the
report. You often see things along the lines of "In chapter 2 we will describe X and
then in chapter 3 show how it can be used to solve the problem described in chapter
1". Look at some previous reports (or academic papers) that have this sort of structure
to see examples of what can be written here. The important thing is to give your
reader a clear picture of what your report is setting out to tell them and where they
will find particular parts of your case.
2. Review
All projects include some element of review. Your work is done in the context of an
academic discipline, computer science (or business or social science). Show how it
fits into the framework of that discipline. You've read books and papers describing the
problem you are trying to solve. You've read books and papers describing potential
solutions to the problem. Review them.
What do we mean by review? There are two main purposes in conducting a review.
Firstly, in tackling your project, you decided to take some particular approach. You
need to give your reader sufficient background knowledge for them to be able to
appreciate why the approach you took was valid or best. Since they may not be
familiar with either the problem or the possible solutions or both, you need to provide
them with a basic grounding in the important and relevant material.
This does not however mean that you should include a detailed tutorial. You can for
instance refer them to a book that gives a full explanation and confine your
description to just the rudiments. Examples to illustrate points are useful.
Secondly, you need to demonstrate that you considered all the possible solutions to
the problem and that you took all available material into account. This part of the
review usually summarises quite succinctly approaches that have been taken by other
people in similar situations. Some will have been successful and some not, and this
should be indicated. It is perfectly all right to express justified disagreement with
something you've read - "criticism" (in the positive sense of the word) is often an
excellent feature of a review.
The most important attribute that your review should possess is relevance. Don't
include things that you've read that contributed nothing to your project. Where you do
include something, don't just be descriptive - explain how and why it is relevant to the
rest of your report.
3. Design
If you've built something (hardware or software) to solve a problem, you had to make
some design decisions along the way. (If you didn't your project must have been very
mundane and probably very boring!) Why did you choose to do something one way
rather than another? Why did choose to include one thing but leave out something
else? Which factors did you think were most important and which did you choose to
ignore?
Don't just list your decisions; place them in a context. It should be possible for the
reader to understand how your design decisions contributed to meeting your
objectives. Also important is that you show the method by which you accomplished
your design - "process" is as important as "product" to an engineer. What processes
did you use? How did they contribute to ensuring that what you did was
complete/consistent/correct? Don't just write about what you did, nor how you did it.
Why you did it is most important.
The starting point for your design is of course your requirements - what the customer
wants the artefact to do. In some projects the requirements are specified in advance.
The customer provides document that (in more or less detail) specifies the behaviour
of the item to be constructed. More commonly, the customer has a more vague "need"
for something, and it is part of the project itself to refine that into a more detailed set
of requirements. A project that doesn't have a written set of requirements is not a very
good one, though it would not be normal to describe the requirements in much detail
in the body of the report. Better is to include the requirements specification document
as an appendix to your report (see later about appendices) and only in this chapter
highlight the points relevant to your design. If a detailed discussion of how you
elicited, analysed and specified the requirements is necessary (for "necessary" read
interesting and relevant), it could be a separate chapter before this one.
If you followed some particular design methodology then you almost certainly
produced a design document of some description. Again, the full version would
probably appear as an appendix to your report, with only the interesting bits discussed
here. In particular you would expect to say why certain things appear in the design in
preference to others. You would also give examples of things you rejected (with
reasons), which probably don't appear in the design document and therefore would not
appear anywhere if you didn't mention them here.
The "design" stage is often held to be the key stage of your project. It is certainly the
part of project reports that is most closely looked at by external examiners! It is the
one where you can show off your ability to apply your engineering and commercial
knowledge and skills to best advantage. This is precisely what you will be doing in
your working life if your chosen career is in any way related to your degree.
4. Implementation
After you designed your solution to your problem, you implemented it. This section
normally describes how you did that. What tools and techniques did you use? What
difficulties did you encounter and how did you overcome them?
Some students believe that this section is equivalent to writing the internal
documentation of a program. It isn't. When you are documenting a program, you want
to include a lot of detail so that when someone else comes along to maintain the
program they can understand how and why you did everything. The essential attribute
of documentation is completeness - nothing left out. In contrast, this chapter of your
report should only address issues that are interesting. Mundane details about how the
program is structured should be left out. On the other hand if you developed a new
algorithm (however short) or applied an old technique in a new way then that is of
interest and should be included.
There are many possible ways of structuring this chapter and which of them is most
appropriate will vary significantly based on what you have done and the way you
went about doing it. Certainly, the structure should reflect major stages in your
artefact development process or major components of it (or both). Some of the
sections might be short (e.g. because they way you did something was "routine")
while some of them may deserve more attention because of the extent to which they
are "interesting".
If in your project you designed something but did not build it, there may still be scope
for an equivalent to this chapter. In that you could discuss issues that would probably
arise during future implementation and provide advice on how potential problems
could best be prevented or solved.
5. Evaluation
Once you designed and built something, you probably evaluated it in some way. At
the very least, you tested what you built to see whether it did what your customer
wanted it to do. Evaluation usually comes in one of two forms: either you compare
what you did with your objectives, or you compare what you did with what someone
else did.
Involving the customer, or potential users of the system, in the evaluation is always a
good idea. The ideal would be to install your artefact in the environment in which it
was designed to operate, and gain user feedback on how well it does its job or
compares to existing systems. Second best is to demonstrate the artefact to likely
users and get their opinions. If this can be done in a simulation of the real
environment, then so much the better. Feedback from users or customers which is
structured (e.g. the results of objective tests or the responses to a questionnaire or
survey) is more useful than their verbal comments.
Like in the implementation chapter, you do not want to give lots of boring, mundane
detail here. So for example, you would not normally describe in excruciating detail
exactly what tests you conducted and their results, but you would describe in general
terms what you did (your strategy) and what results you obtained.
Again, like in the design chapter, if you have either followed a standard method for
evaluation or made one up yourself, you should describe it. Of course, your own
method would take more description than a reference to a well-known method.
6. Conclusions
The conclusions chapter is where you tie up all the loose ends in the previous
chapters. It is most important that it relates to what you have described previously,
and that it does so in a relevant and concise fashion.
Years of watching TV series like "LA Law" and "Rumpole of the Bailey" have taught
me the rudiments of legal procedures. At the start of a trial, each side makes a
statement about what they are going to show during the course of the trial. (For
example, the prosecution says it is going to show that the defendant was at the scene
of the murder, had fingerprints on the murder weapon and had a motive for killing the
victim, so therefore must be guilty). This is like the introduction to your report. Then
each side presents its evidence. This is like the body of your report. At the end of the
trial each side has a chance to "sum up", to summarise how each piece of evidence
contributes towards proving whatever it is they are trying to prove. The conclusion of
your report is like that. (Extending the analogy, the role of the jury is taken by the
examiners of your report who judge whether you have or have not done what you said
you were going to do.)
In your summing up, you need to show how what you did contributed to meeting the
objectives you set in the introduction. In doing so, it is appropriate to repeat (in
summary form) key points from your review, design, implementation and evaluation
as necessary. You need to make a convincing case because if you don't, what you
describe will not "hang together" - each stage of your project will seem like it is
disconnected from the others.
Unlike a legal case, it is perfectly OK to have some loose ends left at the end of a
project. Sometimes there will be aspects that you simply did not have time to address.
Other times there will be things that you were unable to do because of force of
circumstances. Above all there will have been points raised during the course of the
project that you did not anticipate and were not within your scope to tackle. All these
things can be discussed in this chapter and, where further work can be identified, a
distinct sub-section "Suggestions for further work" should be included. Supervisors
love that section because it often provides a fertile source of ideas for next year's
project students!
You probably also want to reflect upon the work that you've done. Could you have
done it better and, if so, how?
The final part of your conclusions should be a mirror image of the first part of your
introduction. Whereas in the introduction you started off broadly in setting the context
for your project and then got more specific, in the conclusions you should show how
your specific conclusions fit into the broader context. You do not have to advance the
boundaries of mankind's knowledge very far but at least you should be able to say
which boundary it is!
Non-typical projects
It is not our intention to tell you that the above is the only (or best) way of structuring
a project report. Indeed of the chapters described above probably only the
introduction and the conclusions are essential, though a review chapter (or two) will
probably be found in 99% of project reports, and some element of design in all BCS-
accreditable ones. Rather we are trying to indicate the major areas you will want to
write about, with the ordering of them arranged according to the purpose of the report.
If you decide that you need to have all the above sections, there are other ways of
arranging them. For example if your project consisted of four quite distinct activities
then you might choose to have the body of your report consist of four chapters, one on
each activity, with each chapter perhaps having sections addressing design,
implementation and evaluation. Alternatively, it may be best to consider the design of
each separately, but to consider the implementation and evaluation of them together.
Whatever way you choose, you should do so to facilitate the reader's understanding of
the points you are trying to make.

University of Portsmouth
Computing & Multimedia Programme Area
Final year project undertaken in partial fulfilment of the requirements for the
BSc (Honours)/MSc Degree in [Degree title]
[Title of project]
by
[Full name of student]
Supervisor: [Name of supervisor]
Project unit: [Project unit code]
[year, e.g. 2001]
Abstract
The abstract of the project should be between 150 and 300 words in length and appear
on the title page. It should provide a synopsis of the project, stating clearly the nature
and scope of the work undertaken. It should include a brief statement of the objectives
of the project, the work done, methods used, problems encountered and conclusions
reached.

Other content
Normally the order of presentation will be:
1. 1.      Title page and abstract
2. 2.      Table of contents
3. 3.      Acknowledgements
4. 4.      Chapters
5. 5.      List of references
6. 6.      Appendices