How to prepare a project report.

Write a detailed report from your major

Meaning of Project Report

A Project Report is a document which provides details on the overall picture of the proposed
business. The project report gives an account of the project proposal to ascertain the
prospects of the proposed plan/activity. Project Report is a written document relating to any
investment. It contains data on the basis of which the project has been appraised and found
feasible. It consists of information on economic, technical, financial, managerial and
production aspects. It enables the entrepreneur to know the inputs and helps him to obtain
loans from banks or financial Institutions. The project report contains detailed information
about Land and buildings required, Manufacturing Capacity per annum, Manufacturing
Process, Machinery & equipment along with their prices and specifications, Requirements of
raw materials, Requirements of Power & Water, Manpower needs, Marketing Cost of the
project, production, financial analyses and economic viability of the project.

How to write a Project Report

A tidy, well laid out and consistently formatted document makes for easier reading and is
suggestive of a careful and professional attitude towards its preparation. Remember that
quantity does not automatically guarantee quality. A 150 page report is not twice as good as a
75-page one, nor a 10,000 line implementation twice as good as a 5,000 line one.
Conciseness, clarity and elegance are invaluable qualities in report writing, just as they are in
programming, and will be rewarded appropriately. Try to ensure that your report contains the
following elements (the exact structure, chapter titles etc. is up to you):
Title page
This should include the project title and the name of the author of the report. You can also list
the name of your supervisor if you wish. IMPORTANT: Before submission you should
assemble a project directory which contains all your software, READMEs etc. and your
project report (source files and pdf or postscript).
Abstract
The abstract is a very brief summary of the report's contents. It should be about half a page
long. Somebody unfamiliar with your project should have a good idea of what it's about
having read the abstract alone and will know whether it will be of interest to them.
Acknowledgements
 It is usual to thank those individuals who have provided particularly useful assistance,
technical or otherwise, during your project. Your supervisor will obviously be pleased to be
acknowledged as he or she will have invested quite a lot of time overseeing your progress.
Contents page
This should list the main chapters and (sub)sections of your report. Choose self-explanatory
chapter and section titles and use double spacing for clarity. If possible you should include
page numbers indicating where each chapter/section begins. Try to avoid too many levels of
subheading - three is sufficient.
Introduction
This is one of the most important components of the report. It should begin with a clear
statement of what the project is about so that the nature and scope of the project can be
understood by a lay reader. It should summarise everything you set out to achieve, provide a
clear summary of the project's background, relevance and main contributions. The
introduction should set the context for the project and should provide the reader with a
summary of the key things to look out for in the remainder of the report. When detailing the
contributions it is helpful to provide pointers to the section(s) of the report that provide the
relevant technical details. The introduction itself should be largely non-technical. It is useful
to state the main objectives of the project as part of the introduction. However, avoid the
temptation to list low-level objectives one after another in the introduction and then later, in
the evaluation section (see below), say reference to like "All the objectives of the project
have been met...".
Background
The background section of the report should set the project into context and give the
proposed layout for achieving the project goals. The background section can be included as
part of the introduction but is usually better as a separate chapter, especially if the project
involved significant amount of ground work. When referring to other pieces of work, cite the
sources where they are referred to or used, rather than just listing them at the end.
Body of report
The central part of the report usually consists of three or four chapters detailing the technical
work undertaken during the project. The structure of these chapters is highly project
dependent. They can reflect the chronological development of the project, e.g. design,
implementation, experimentation, optimisation, evaluation etc. If you have built a new piece
of software you should describe and justify the design of your program at some high level,
possibly using an approved graphical formalism such as UML. It should also document any
interesting problems with, or features of, your implementation. Integration and testing are
also important to discuss in some cases. You need to discuss the content of these sections
thoroughly with your supervisor.
Evaluation
Be warned that many projects fall down through poor evaluation. Simply building a system
and documenting its design and functionality is not enough to gain top marks. It is extremely
important that you evaluate what you have done both in absolute terms and in comparison
with existing techniques, software, hardware etc. This might involve quantitative evaluation
and qualitative evaluation such as expressibility, functionality, ease-of-use etc. At some point
you should also evaluate the strengths and weaknesses of what you have done. Avoid
statements like "The project has been a complete success and we have solved all the problems
asssociated with ...! It is important to understand that there is no such thing as a perfect
project. Even the very best pieces of work have their limitations and you are expected to
provide a proper critical appraisal of what you have done.
Conclusions and Future Work
The project's conclusions should list the things which have been learnt as a result of the work
you have done. For example, "The use of overloading in C++ provides a very elegant
mechanism for transparent parallelisation of sequential programs". Avoid tedious personal
reflections like "I learned a lot about C++ programming..." It is common to finish the report
by listing ways in which the project can be taken further. This might, for example, be a plan
for doing the project better if you had a chance to do it again, turning the project deliverables
into a more polished end product.
Bibliography
This consists of a list of all the books, articles, manuals etc. used in the project and referred to
in the report. You should provide enough information to allow the reader to find the source.
In the case of a text book you should quote the name of the publisher as well as the author(s).
A weakness of many reports is inadequate citation of a source of information. It's easy to get
this right so there are no excuses. Each entry in the bibliography should list the author(s) and
title of the piece of work and should give full details of where it can be found.
Appendix
The appendices contain information which is peripheral to the main body of the report.
Information typically included are things like parts of the code, tables, test cases or any other
material which would break up the theme of the text if it appeared in situ. You should try to
bind all your material in a single volume and create the black book.