Common Mistakes in Proposals and Reports
This is a list of Common Format Mistakes
1. All Figures need to have captions below the figure looking like this: Figure 1:
Architecture of the System
2. EVERY figure needs to be discussed in the text. You write something like: Figure 1
shows.... OR Is shown in Figure 1, etc.
3. A figure should appear AFTER it is mentioned in the text the first time. However, it
does NOT have to be right at that place, it can come later. Do not leave big white holes
(of no text) because you place a figure at the beginning of the next page. Fill the hole
4. Table captions are like figure captions but they come ABOVE the table. They are
numbered separately, so you will have a Figure 1 and a Table 1.
5. If you have no figures at all in your document then there is something terribly
6. Every (EVERY) reference that you have in the reference list at the end needs to be
mentioned in the text. Thus, in the text it will say  or [3,4]. For example: We have
used methods developed in . In the reference list there will be then , , . If
you copy whole paragraphs you need to place a  at the end of every paragraph or say at
the beginning of the section that "The material in this section is derived from ."
7. If you copy a figure it needs a  in the Figure caption.
8. There are several standard formats for references. Orders are fixed. You must start
with the author, never with the title. Formats are different for books, journal articles,
conference papers, book chapters, Web pages, MS Project reports, etc. I don't want to list
all of them here, please check the back of a book or of a report of a previous student.
People commonly forget the City for books. For Web pages you list everything you can find.
If there is no date, you put the date when you looked it up.
9. The format for citing a previous student is like this example:  Patel, M.,
Searching the Web for Names, MS Project Report, New Jersey Institute of Technology, CS
Department, Fall 2003.
10. I am very much into consistency. Either you type Web everywhere, or you type web
everywhere, but don't do both in one document. The same applies to names of system
modules. Capitalize them everywhere or nowhere.
11. Please don't make obvious spelling errors, like FOMR. If you can, don't confuse FROM
with FORM either (a very common spelling error).
12. There are STRINGENT rules of where you put blank spaces and where you don't put
them. There are NO blanks before period (.) semicolon, comma, or colon. But there are
blanks AFTER all these. You always put a blank space before a (paren pair), except in a
mathematical function. You NEVER put a blank space immediately after the ( or immediately
before the ). So this is 3 TIMES WRONG: Patel( see  ) wrote that ...
13. Make sure you don't have sentences ending in the middle, or with no subject or no
14. If you copy and paste material (never in the My Work section!) make sure that all
parts have the same font, the same space between lines, the same font size and the same
15. Every section must have a section number. Most sections will have subsections, such
as 2.4. You can even have 2.4.1 if you want.
16. Make sure you have a table of contents with page numbers that look nice and are
aligned with the right end of the page.
17. The Reference section does NOT get a section number.
18. The Appendixes (Appendices really) are numbered separately as Appendix A, Appendix
B, etc. Appendices do NOT have section numbers in front of them.
19. I have discussed the required sections (Abstract, Introduction, etc.) in detail on
other TWIKI pages. Make sure you have them. There is no literary freedom in writing
20. Make sure you use the right tense. In a proposal, in the My Work Section, there will
be a lot of "I will do..." In a report there will be a lot of "I did" (HOPEFULLY....).
21. There are different kinds of quotes. Open `` and close ''. Many people use close
both at the beginning and end. That does not look nice. Check your MS Word Settings for
22. I know it's hard to believe, but in American English a period or comma comes BEFORE
a closing double quote. You write "really," in your document. You never write: "really",
23. There are almost never paragraphs consisting of one sentence. There almost never
sections consisting of one paragraph. There are almost never sections that contain only
24. Use double spacing and probably font size - 11 (12 is fine)
25. Insert page number on each page
Common mistakes I have observed many times:
* Students write all sorts of stuff, some of it even good and interesting. The only
thing they don't write about are the programs that they actually wrote. This is so
annoying. The main things are missing. How did you solve the problem? How exactly did your
data structures look? What problems did you face? How did you solve them? What wrong steps
did you take, and how did you correct them? No, this should not be a line-by-line
description of your code.
o I guess what happens is that students think what they did is not enough or not
important enough, so they try to hide it. While this is sometimes really true, I have
found that often it is not, and this fear is unjustified.
o The other possibility is that when they write the report they already forgot a
lot of this stuff and are too lazy to go back to their own code to check it.
o It is well known that after a problem has been solved it often starts to look
trivial, and students are ashamed to write about something trivial in their reports.
* The second problem is that students don't understand or ignore the structuring.
o Now this is an extreme example. But I had the feeling on one report that a
student wrote the whole report first. Then s/he realized that there was no Abstract,
Introduction, etc. so s/he just wrote Abstract in front of the first page, Introduction in
front of the second page, and Conclusions in front of the last page. That's how it read.
o Normally you write the abstract AFTER you are all done, and it has to be a
complete summary of what you did in your work. Some students seem to do a "sampling from
memory." They write what they remember and omit what they don't. Again, you have to go
back to your own writing and look at it and put the appropriate stuff into the abstract.
This is about the work YOU did, not about "the Web has spread to every country of the
world" or similar platitudes.
o Conclusions are similar to the abstract, but they should contain hard
information, if possible result numbers (size of database, etc.), certainly module names
of work YOU did. Many conclusions could have been written BEFORE the work was done, and
often the conclusion is just copied from the proposal. This is a sure sign that the
conclusions are inadequate. Unless you really did zero work it is impossible to write the
conclusions before doing the actual work, and if the conclusions look that way, the
suspicion arises that you did zero work.