In most universities, carrying out a project is a mandatory assignment and independent of the preparation of the thesis. In this regard, if you want to get a good grade for your project, it is absolutely essential that you write a good report. It's the report that's qualified, it's not the results or anything else you've built during the project period. As important as your achievements are, if you don't write your work well, you'll get a bad grade.

How to write a project

The problem you have to solve is the following: transfer from your brain to paper your own experiences when carrying out the project and the knowledge you have acquired, in a coherent, logical and correct way.

There are several ways to achieve this. Each author has a different technique. A popular method is to write as fast as I can, regardless of consistency, structure or order, until you have written (or rather, typed) all the points you can think of. If your brain goes faster than your fingers and an idea that belongs to another part of the document comes to mind, jump to the bottom of the page and insert a few words there to remember that you need to expand that point later, and then continue where it was. The goal is to transfer as much relevant material from the brain to paper as quickly as possible. This method has been called "brain dump". It is practiced by some fiction writers as well as technical authors (Docherty, 1999).


First of all, we must strive to be absolutely precise. When you write, it's not enough for you to know what you mean; nor is it enough for your writing to admit the meaning you intend: it must not admit any other meaning. What you write should not be susceptible to misinterpreting. Take exceptional care in choosing the right word for the occasion. Don't write, for example, "optimal" if you want to say "good". "Approximate" means "close", so "very approximate" means "very close", which is not what many people seem to believe it means.


Precision in writing is above all a matter of care. However, good writing is not only accurate, but also vigorous, and that is much harder to achieve. It helps to have read a lot, especially novels. Here are some tips that can help you write with strength and vigor.

Prefer short sentences to long ones and short words to long ones, as long as the word short has the meaning you need. Brevity is a great virtue in technical writing. (But don't go too far; remember Horace's observation: "Brevis esse laboro, obscurus fio.") Avoid circumloquiums. "In almost all sectors of the computer market" can be replaced in most contexts by "almost everywhere".

Passive Voice

The question of whether passive voice should be used in technical writing is a complicated one. Most of the most senior writers continue to write "a program was written..." instead of "I wrote a program...". Many of your examiners may share this preference or prejudice in favor of the passive voice, but this style is almost deprecated throughout technical writing, and I advise you not to use it. Whatever you do, don't use the actual "us" ("we wrote a program" when it means "I wrote a program").

There is a general consensus that Latin phrases should be avoided in technical writing (although the occasional Latin quotation may give a false air of scholarship). The best rule is that a Latin phrase is acceptable if it abbreviates a circumlocutive phrase in English. Mutatis mutandis, for example, one of my favorites, is permissible rather than "making the appropriate changes", as any gloss in English seems ugly and unwieldy. "I.e." (note the Roman typeface and punctuation) is usually useful rather than "in other words" or "i.e.", and is widely understood. However, often "X, i.e. Y" can be replaced by "Y", because the writer realized while writing X that Y said the same thing, only better. "Eg" is overused and it is better to use it sparingly; prefer "for example".

Spelling and Grammar

You must take exceptional care in spelling. Bad spelling is a distraction for the expert reader. In most cases, misspellings have no excuse; there are many excellent spell-checking programs that take care of finding the errors for you, and excellent dictionaries (on paper) that will tell you what the correct spelling is. Be especially careful with words whose most common misspelling is a correct spelling of a different word. It is dangerous to let the spell checker "correct" a misspelling itself; many such "corrections" have been recorded, for example, recently in New Scientist.


The best and most famous typographic reference book is Horace Hart's Rules for composers and readers at the University Press, Oxford, colloquially and universally known as "Hart's Rules". It's a small book you should probably read from start to finish, but you can skip the section on Russian spelling if your report doesn't contain Russian words. This book, like Fowler's, has been continuously revised since its first publication. The last edition dates from 1983. It is still being printed, almost a century after its first publication, it is worth buying.


In general, the report should contain illustrations (figures or diagrams), but they should be relevant. Ask yourself if the illustration helps the reader understand the text. If the text is easily understandable without the illustration, delete it. If it is not, it is usually better to clarify the text than to add a diagram.

All illustrations should be prepared with a suitable program, such as pic, xfig or grap. They should not be drawn by hand. The only exception to this rule is circuit diagrams: given the current state of the schematic introduction packets, a hand-drawn circuit diagram is usually preferable to a computer-drawn one.

If possible, include the figures near the text that references them, rather than including them all together in an appendix. Circuit schematics are, again, a possible exception to this rule. It is normal to list the tables and figures at the beginning of the report, after the index.

Project Structure

Top Level Structure

At the top level, a typical report is organized as follows.


It is a couple of paragraphs - no more - summarizing the content of the report. It should be understandable to someone who has not read the rest of the report.


The scope of the project, setting the stage for the rest of the report.

Previous works

One or more review chapters, describing the research you did at the beginning of the project period.

Several chapters describing what you've done, focusing on the novel aspects of your own work.

Later work

A chapter in which you describe possible ways to continue or develop your work. Be imaginative but realistic.


It's similar to the summary. The difference is that here you should assume that the reader of the conclusions has read the rest of the report.

Bibliographic references

References should be relevant. A typical report of a PR3 project may contain around a page of relevant references, if the initial investigation period was well used. Don't include references you haven't read, however relevant they may seem to you. If you're referring to standard material that's covered by a large number of textbooks, choose one or two really good ones and cylate them, rather than a long list of mediocre texts.

There are many styles for citing references. Although there are strict rules (e.g. British rules) for citing references, my advice is not to worry about them; instead, look for a reputable magazine in the library and copy its style. Or, copy the example below. It is important to be consistent, complete and unambiguous; beyond that, it doesn't matter much what he does (Frankel, 2001).

Citation style example
Quotes in the text:

Mander, in "Notes on a System Specification Method", [Mander 1983] gives the following ...

... as described by Briggs [1983a] ...

Thimbleby's guidelines [Thimbleby 1983] suggest that ...

Different methodologies have been [Tully 1983] examined.

Several recent publications in this field [Wand 1980d, ACM 1971] have been very influential.

List of references at the end of the report:

ACM 1971.Association for Computing Machinery, Second symposium on problems in the optimisation of data communication systems, ACM (1971).

Briggs 1983a. J.S. Briggs, "The design of AIR and its use in Ada separate compilation", in SERC workshop on Ada software tools interfaces, ed. P.J. Wallis, University of California. P.J. Wallis, University of Bath (1983).

If you adopt this style, when citing a reference, you do not need to repeat the author's name or authors' names ("Jones and Sanderson [Jones y Sanderson 1999] have proven..."). Write instead "Jones and Sanderson [1999] have demonstrated...", and cite the reference as "Jones and Sanderson 1999".

A numbered reference system, such as the default format produced by the Unix refer tool in conjunction with troff, is also acceptable. I myself prefer numbered citation styles, which I find much less annoying and easier to see; for example, "Jones and Sanderson¹ have demonstrated..." or "Jones and Sanderson [1] have demonstrated...". These forms, permitted by the Rules of the Handbook, appear to be the two dominant citation styles in academic journals.

You may want to refer to electronic sources, in particular material found on the World-Wide Web. It is not enough to put "found on the WWW" instead of a quote. The "Bibliographic Formats for Citing Electronic Information" website offers tips for citing online sources.

As much as possible, avoid citing unpublished bibliography. However, it is acceptable to cite university reports and doctoral theses.

"References" are always cited in the text. Other works that you have appealed to but have not been cited should be listed in a section called "Bibliography".

Note that "et al." requires a period after the abbreviation "al." (for "alia"). It means "and others", and can only be used to refer to people, usually in reference lists. It's the animated form of "etc.", which also requires a dot.

Lower Level Structure

Structure is a recursive concept. A well-structured report has its top-level sections well ordered, and it's easy to get it right; but each section must be in itself well ordered, and that is more difficult.

Most paper documents, and many online documents, are read linearly from start to finish. This is certainly true for an examiner reading a project report. Therefore, the writer of a well-structured document avoids forward references whenever possible. Try to avoid typing "... as we will see in chapter 10, ...", especially if the material in chapter 10 is essential to the understanding of the text at the point at which the reference occurs. Sometimes these references are unavoidable, but most of the time they are a sign that the text needs to be reordered.

In the past, to reorder the text you had to "cut and paste" with scissors and real paste. Today, the word processor has made these operations so much easier that there is no excuse for a sloppy structure. Take your time and keep reordering words or phrases within sentences, sentences within paragraphs, paragraphs within sections and sections within the entire report until you get it. Try to achieve a logical progression from beginning to end, with each sentence based on the previous ones.

Subdividing the sections

If the chapters are numbered 1, 2, 3, ..., the sections of chapter 1 shall be numbered 1.1, 1.2, ... . It is permissible to subdivide a section: the subsections within section 1.1 shall be numbered 1.1.1, 1.1.2, ... . However, do not nest subsections to more than four levels: subsection is acceptable, but subsection is not. It is quite possible, with care, to write even a large and complex book without using more than three levels.

Footnotes are a hassle for the reader. They interrupt the linear flow of the text and demand a mental effort of stacking and folding that requires conscious effort. There are rare occasions when footnotes are acceptable, but they are so rare that it is best to avoid them altogether. To delete a footnote, first try putting it inline, surrounded by parentheses. It is likely that the poor structure that concealed the footnote device will become evident and can be improved by cutting and pasting.

Our specialists wait for you to contact them through the quote form or direct chat. We also have confidential communication channels such as WhatsApp and Messenger. And if you want to be aware of our innovative services and the different advantages of hiring us, follow us on Facebook, Instagram or Twitter.

If this article was to your liking, do not forget to share it on your social networks.

Also you might be interested in: How to write an essay

Bibliographic References

KJ, Frankel RM. Getting qualitative research published. Educ Health 2001; 14: 109–117.

Docherty M, Smith R. The case for structuring the discussion of scientific papers. Br Med J 1999; 318: 1224–1225.

International Journal for Quality in Health Care vol. 16 no. 3 © International Society for Quality in Health Care and Oxford University Press 2004; all rights reserved

How to write a project

How to write a project

Abrir chat
Bienvenido(a) a Online Tesis
Nuestros expertos estarán encantados de ayudarte con tu investigación ¡Contáctanos!