It is written in the form it recommends, and contains examples of both good and bad styles. It is intended for undergraduate project students, and post-graduate students in their first year. It assumes a reasonable familiarity with Microsoft Word (although not at the level of an expert user), and a reasonable grasp of English grammar. This introduction chapter introduces this document, and contains some advice about writing reports for me to review. (You’ve now read the first couple of paragraphs of the introduction, and you hould have a good idea of what’s in the rest of the document, whether you have the necessary background to be able to understand it and might find it useful, and what’s in the rest of this introduction chapter. All reports should start like that. ) 1 Background to the Report I’ve been supervising undergraduate projects for a few years now, and I find myself constantly giving the same talks to different students. This is getting a bit tedious, and I find I often forget to mention something to one student, and a report then gets handed in at the end which isn’t as good as it could be.
So I decided to put down my thoughts (or at least those of them that I remember as I write this) and distribute this document. Other thoughts will no doubt occur to me later, and this document will be updated as I remember them. Please note that there is no accepted standard for project reports. Different supervisors will have different opinions and preferences about style; in some cases this document merely describes my preferences and opinions. Any student reading this document would be well advised to talk to his or her other supervisor as well, and attempt to write a document to satisfy us both.
Distributing this report written in Word has two additional benefits: it allows me to give examples of what I regard as good (and occasionally bad) styles, and it gives me the chance to distribute a sample style gallery that might be of some use. (If you don’t know what a style gallery is, look it up under Microsoft Word help. ) 2 Writing Reports for Me This is important, I want everyone to read this, so I’ll put it here. Strictly speaking you could argue that this section should be placed in the body of the report since it is not an introduction to anything that is discussed in more detail later, but since it’s short I can get away with it.
I am happy to read draft copies of a report before submission. However, I am not happy to read slightly different versions of the same chapter over and over again, and I won’t have time to read anything if I am presented with a large document only a few days before the deadline. I have come up with a few rules for how this can best work for both of us: 1) Run all chapters through a spelling and grammar checker before they get to me, and take note of the advice provided. This is particularly important if English is not your first language.
If the grammar and spelling are so poor that I have difficulty in understanding what you are trying to say, then be prepared to have the document returned. I’m afraid I don’t have the time, experience or qualifications to teach English as a foreign language. (There are a lot of on-line grammar tutorials on the Internet, which you may benefit from, and other help is available in the University – contact the University’s Centre for English Language Teaching http://www. york. ac. uk/celt/ for more advice. ) 2) Send me individual chapters one at a time, as soon as they are complete (or as soon as you want some comments on them).
This minimises the amount of reading I have to do at the end of the projects, and I hope will encourage you to write as you go along, always a good idea. Sadly, despite my best advice, every year some students leave their writing up to the last few weeks, then present me with a large document to review at the last minute. They are then disappointed when I don’t have time to do this. Recently, I’ve been given more project students to supervise, so I have had to be strict with the following rule: I will look at one chapter (or about 15 pages, whichever is shorter) every two weeks for each project student I have.
If you give me a document with more than one chapter to review, and don’t tell me which chapter to look at, I will only review the first chapter. At busy times, I will operate a queue system. I’m sorry about this, but I really don’t have time to do anything more; and this rule will enable me to be fairer with the amount of help I can offer to different students. 3) If you are sending me a chapter for the second time, then please clearly mark where the changes have been made, so I don’t have to read through the whole thing again. Try turning on ‘Track Changes’ in Word, or do a comparison of the current version with the last version I looked at then mark the new sections, perhaps using colour. ) 4) If English is not your native language, it is almost certain that there will remain a lot of grammatical and usage points which the computer’s grammar checker will not pick up. Experience has suggested that the best thing is to leave these until the end, and then for a native English speaker to go through the document once, to correct the grammar.
It is better if this person has not been involved with the project, so they don’t get too bored. 3 Structure of this Document The remainder of this document is arranged as follows: chapter two introduces some of the basic concepts of writing a project report, of common mistakes, and techniques to ensure that your report looks good. Chapter three is specific for users of Microsoft Word (the word-processing package being used to write this report), and is concerned with more detailed information about how best to write project reports using this program.
Chapter four provides a brief introduction to some issues if you choose to use LaTeX instead of Word. Finally, chapter five provides a few conclusions, a checklist, and makes some recommendations for how this report could be improved in the future. (A section like this, describing what is in the remaining sections of the report, should always be included in the introduction section of a report. Often, it’s the last thing in the introduction. ) The Basics of Project Report Writing
This chapter introduces some basic techniques and considerations about writing project reports: when to write; the structure of the project report; what sections should be included; what order they should be placed in; and what kind of information I am looking for when I read a project report. There are a lot of good introductions to report writing out there already (see for example, the information at http://www. amp. york. ac. uk/internal/ugrad/gen/tskills/t_skills. htm), and I won’t try and repeat all that information here. I will assume the reader is familiar with this material already (if you’re not, do look up and read these pages).
Instead, I will concentrate on the particular nature of the project report, the idiosyncrasies of Microsoft Word, and highlight what I have found to be the most common problems. 1 Before You Start The two most important things to do at the start: make a plan about how and when the report will be written, and find out who your target audience is. As far as the target audience is concerned, in the case of an undergraduate project report, you should be writing for any of your fellow students who are doing completely different projects.
This means you can assume any knowledge covered in the core courses, but not in any of the option modules. In the case of a first-year post-graduate report you are writing for someone with the core knowledge of an electronic engineer, but no knowledge about your particular subject area. There is an exception to this rule, which occurs when the academic supervisor who has been assigned to you knows nothing about your subject area, not even what is taught in the core courses (in my case, this happens when the project is done in JAVA, as I don’t speak the language).
It’s always a good idea to check with your academic supervisors (or whoever else might be reading the report) what they know. In the case of a project written in JAVA, I would appreciate an appendix on “introduction to JAVA and OOP”. (An appendix is an ideal place for information that only some of the readers of the document will require. ) The previous paragraph has a mistake in it. OOP is an acronym, and as such, it should be defined the first time it is used. (Having a glossary at the beginning does not eliminate this requirement. So it should have read “introduction to JAVA and object-oriented programming (OOP)”. 1 Planning and Top-down versus Bottom-up In terms of how to write the report, just as with computer programs, reports can either be written top-down (start with a list of chapter headings, then add the sub-headings, then write each section individually); or bottom-up (just start writing, and then fit a structure around what you’ve come up). And just like with computer programs, the best results usually come from a combination of the two approaches.
Top-down ensures that you don’t leave any important sections out; bottom-up allows you to write freely, without thinking about what you should be saying, and a more fluent and readable style can emerge. And please do write in fluent, easy-to-read styles. This isn’t a technical report going to your boss, this is a document that will be read by an academic over a weekend, when he’s probably got about seven others to read as well, and a dry ‘academic’ style can be tedious to a point beyond the ability of the brain to tolerate. This is one of my personal preferences: other academics may prefer a more formal, dryer style. I see no reason why technical documents should not be a joy to read; and I wish many more of them were. ) In terms of planning, as soon as you have an idea of what the project document is likely to contain, I would recommend writing a top-down structure and setting a timescale for when each section will be completed. Any plan you come up is almost certain to change as the project progresses; but it’s better to have a plan and change it than not to have a plan at all.
Then, up to the last three or four weeks, I’d recommend working in a bottom-up style, just writing about whatever interesting things have been going on at the time, and your current thoughts. As the project nears completion, these bits of writing can be fitted into the top-down structure, and any gaps identified. It’s an iterative process (the top-level plan often changes when you find there’s very little to say about something), but I would strongly recommend managing the process, rather than just hoping things will fit together at the end. 2 When to Write
You have been writing as you go along, I trust, even if it’s just keeping a detailed lab-book? This is one of the most important things. Leaving all the writing up to the end never results in a good report. This reflects one of the key differences between project reports and technical reports: a technical report is concerned with what has been done and what the results were; a project report is more concerned with how you did it. Remember, we are trying to give you a mark for all the work you did throughout the project (including the problems, bugs and dead ends), on the basis of a single document handed it at the end.
In fact, we’re almost more interested in the problems and bugs than in the final result. Leave all the writing to the end, and you will forget about some of the more frustrating bugs you found, irritating problems you had, and all the things you tried before you finally found a solution. Yet these attempts, ideas and frustrations are exactly what we want to read about. There are lots of marks available for having inventive ideas and problem solving, but we need evidence to award these marks: please let us give them to you. This is also one of the benefits of sending weekly emails with current progress, issues and concerns.
They can be used as a memory-jogger if the relevant sections of the report are not being written up as you go along. Another benefit is that they provide a diary of events that can be used to plot progress against the project plan. 2 Structure: What to Include A project report should include a front page, an executive summary or abstract, a table of contents, possibly a glossary, an introduction, a literature survey or market survey, some sections describing the work done, a conclusions and further work section, acknowledgements, bibliography, references, and appendices.
There’s no need for version control or a revisions page: a project report will only have one revision (another difference between project reports and technical reports). A few more thoughts on each of these sections follow: 1 The Front Page Probably isn’t part of this document, and can be prepared in a separate file if necessary (certainly that helps keep headers and footers off it). You’re often given specific instructions about what should be on this page and where. Stick to them. 2 Executive Summary or Abstract One or other of these should follow.
An executive summary is never any longer than one page, and often rather less. It is a one-page summary of the report, including the key results. It is written for managers who only have time to read one page: bear this in mind when you are writing it. An abstract is a description of what is in the rest of the document, without necessarily containing any of the key results. It’s about 100 words long, usually one paragraph, and acts as an advert for the rest of the report. After reading the abstract, a potential reader should know whether he wants to read the rest of the document or not.
Both executive summaries and abstracts get separated from the main report, so they must be capable of standing alone. That means no references and no cross-references in either. In most examples of an undergraduate or first-year postgraduate project report, I would suggest that an executive summary is more appropriate. Abstracts are more appropriate for technical papers, from where they are collected in abstracting journals and made searchable on the web; this isn’t going to happen here. 3 Table of Contents
Always include one of these (Word can generate them automatically, provided you use heading styles for your chapter and section headings), but make sure it’s not too long. For a project report, much more than a page isn’t sensible, it would take too long to find what the user wants to find. Not every sub-sub-sub-heading has to be here: use some discretion. Bear in mind that this is a table in name only: it doesn’t need a caption, and it shouldn’t have a border; that makes it look very odd.
Word can also automatically provide tables of figures and tables of tables as well (and tables of formulas, but that’s going too far). Include them if you like, I don’t mind. I don’t find them particularly useful myself, but they do add a couple of pages to the report if it seems a bit on the thin side. Individual chapters can have mini-tables of contents themselves; and this can be quite useful if the chapter has a lot of sub-sub-sub-headings that have not been included in the main table of contents.
This is a bit awkward to do in Microsoft Word (it’s very easy in LaTeX), so if you’re planning to do this, proceed with care. 4 Glossary I like these, I find them very useful. Not just for the acronyms, but any terms that you are using to represent a particular technical concept (for example a “method” in OOP) can be included here. However, note that this doesn’t mean you don’t have to define acronyms when you first use them. 5 Preface Some reports – notably PhD, MPhil and MSc thesis, have a preface at this point.
The purpose of the preface is to place the report in context of the degree, and to allow a statement that all the work that has not been attributed to others is your own. Have a look at some other theses to get examples of the requirements for this: it depends on which degree you are doing. 6 Introduction The introduction has two functions: to introduce the project (why you’re doing it, what part of your degree it takes (if you haven’t already said that in the preface), and what the aims were), and to introduce the report (what is coming in the following sections).
After reading this, the readers should know what the project is about, why you are doing it, whether they have the necessary background to read the rest of the report, and know how to find whatever they want in the rest of the report. As one famous American orator once said, when asked how he planned his talks: “first I tell ’em what I’m going to tell ’em, then I tell ’em, then I tell ’em what I told ’em”. While I wouldn’t entirely agree with that advice for presentations, it’s not a bad structure for a technical report. The introduction is the chance to tell the reader what you’re going to tell him.
Probably the most common fault with introductions is that they go into too much detail, too fast, assume knowledge that the reader doesn’t have, and don’t put the report in context. A useful vision image is that of a cone: the first paragraph of the introduction should be very broad, giving the so that everyone can understand how the subject of the report relates to something they are already familiar with. Then the following paragraphs should narrow the focus, explaining what part of the previous paragraph the report is concerned with, and explaining why it is an interesting part of the wider problem.
The last paragraph can then introduce the specific subject that the rest of the report will consider. 7 Literature Survey or Market Survey This should be the next section in: a literature survey for theoretical projects or a market survey for projects that ask you to build something for production. It’s evidence that you have looked at what others have done in the field. As the saying goes “a couple of weeks in the lab can save almost an hour in the library”. If you haven’t looked up what others have done before, you are almost certainly not working efficiently. 8 Sections Describing the Work
I’ll try in this section to give some advice about how to describe work done; this is often one of the hardest sections of the report to structure in an easily readable way. [Hypothesis/Purpose] For a project report, I’ve found these are best written chronologically, almost like a diary of how you got to wherever you did; this is the easiest way to impose a structure on the document. Of critical importance are the reasons why you made any decisions you did (if you don’t write these in the report, you are sure to be asked about them in the viva). [Previous experience.
It really does help the reader if there is a logical flow of ideas, rather than a whole series of facts and observations in no real order (or at least not in an order that is clearly stated at the beginning). Of course, there are a lot of parallels between the hypothesis/purpose to a section, and the introduction to the whole report; and between the previous experience and the literature review sections. Good reports are like fractals: no matter on what scale look you should be able to find the same structures. [Conclusions. ] 9 Management
Unlike projects in industry, we don’t really ‘manage’ these projects, we don’t have time. We just supervise them. You’ll have to manage yourself, in the sense of setting milestones, budgets and monitoring progress. In your report, it would be good to include a management section, including a breakdown of what you spend most of your time doing, how you planned your time, whether your original time-plan was followed, and if not, why not. 10 Conclusions and Further Work This is always one of the most interesting chapters to read (anyone short of time will tend to read the introduction and this chapter first).
A couple of rules about conclusions: they should always follow logically from the rest of the work, and they must never reference any material not included elsewhere. There should be no new information contained in this chapter, it is just a summary of what has been stated before, and what can be logically deduced from it. If there are a lot of ideas for further work, this could be separate chapter, coming just before the conclusions. 11 Acknowledgements It’s always nice to thank people that have helped you. 12 Bibliography
A bibliography is a list of sources that you’ve found useful for background information, but haven’t directly quoted, or taken any specific piece of information from. Alternatively, they might be sources that the reader can look for to get further information. They appear after the main text. Project reports may or may not have bibliographies, but they always have references. 13 References A reference is a source from which you have taken a specific piece of information. Unless your work is completely original (highly unlikely), you will have references.
The golden rule about references is that they should contain enough information for the reader to easily find the original sources without using a search engine. For a technical paper this means name of author(s), title of paper, journal or magazine title, date of publication, volume number and page references; for a book this means name of author(s), title of book, edition, date of publication and publisher. For a web-site, just the URL and the date you accessed it might be all you have, although most web-pages have titles, and if you know the name of the author then include that as well.
All academic publishers have their own set of (very strict) guidelines about the format of references. Unfortunately, they do not agree: the IEEE style is not the same as the IET style, and the Kluwer style differs again. The important thing is to be consistent. You could do worse than adopt the IEEE style . This includes such details as the titles of books of papers, conference proceedings or journals should be in italics, and the authors initials and surname should precede the title, which is placed in quotation marks.
Book titles should be followed by the edition number, publishers and publication year; journal titles by the volume, page numbers and date. Web-pages are usually not good references for two reasons: firstly many web-pages are not peer-reviewed and have not been edited for accuracy, so the information is not reliable; and secondly web-pages can change at any time, and anyone looking at your reference might not see the same thing that you saw. At the very least, the reference should have information about when you viewed the page.
Wikipedia is (sometimes) an exception: articles are read (and corrected) by many people, so that much of the information about technical subjects is often quite good (although there are some exceptions). There are two golden rules for using Wikipedia as a reference source: always read the “discussion” pages so you are aware of any controversy and can check whether anyone else has reviewed the article; and reference the actual version of the web-page you are reading (Wikipedia helpfully keeps a historical record of all previous versions of articles).
This is easy to do: just click on the “Toolbox” link on the left-margin menu, select the “Cite this page” menu item, then choose whichever version fits into the referencing style you have chosen (Chicago is a good one for engineering articles). At this point, I should add that I don’t encourage people to use Wikipedia (or any other encyclopaedia) as a reference source, since it is not the original source of any information: anything in Wikipedia has been taken from other publications available elsewhere, and there may have been an error in the process.
Appendices do not share the same numbering scheme as chapters. The first appendix is usually appendix A, then appendix B, etc; whereas chapters are more conventionally numbered. 3 Structure: Sections and Sub-sections You’ll note from reading section 2 that you’ve got a very clear idea of what is going to be in the remainder of this section (in all the sub-sections below section 2). This should be true of all levels in the hierarchy. For example, this section, on report structure, gives examples, both good and bad, of the use of hierarchy. 1 Close-Harmony Singing in the Balkans This shouldn’t be here.
Nowhere, in either section 2 or section 2. 3 (i. e. the preceding sections higher up the hierarchy) is any indication that there might be information in the following sub-sections on close-harmony singing in the Balkans. Don’t do this. 2 How Not to Write about Close-Harmony Singing in Vietnam 1 South Vietnam Note there was no text under the previous heading 2. 3. 2 How Not to Write about Close-Harmony Singing in Vietnam: one heading immediately followed another. Try to avoid this: it looks better if there is always at least a sentence, so the readers can check if they are interested in reading the rest of section 2. . 2, and if not, move on to the next section. However, just putting “this section of the report introduces close-harmony singing in Vietnam” adds no information to the title, so don’t just write that. Introduce the rest of the section, for example: “the techniques of close-harmony singing in Vietnam vary widely across the country, with significant differences being observed between the southern and northern regions”. 2 North Vietnam Oddly enough, I know absolutely nothing about close-harmony singing in North Vietnam.
However, you might like to note that this heading does not appear in the table of contents. I have restricted the number of levels of detail in the table of contents, so that items of interest can be quickly found. Use some discretion here: but I would think that for a project or MSc report, a table of contents much longer than a page or two is not going to be helpful. 3 Report Length Often the project guidelines will specify some number of pages. Do not write 150 page reports for an undergraduate project (unless you print them out triple-spaced for some reason).
No-one will have time to read them. Bear in mind the academics often get around four days to read eight project reports: we just don’t have time to wade through vast tomes. Make them as long as they need to be, but no longer. If you’re having trouble filling 40 pages (3rd year or taught MSc), 70 pages (4th year), or 100 pages (MSc by Research or MPhil/DPhil Transfer Report) the chances are you either haven’t done enough work, have left the writing up to the end and have forgotten all the details, or you’re not including some important information that I’d like to read about. What I Look For in a Project Report In this section of the report, I’ll describe what it is that gets credit in a project report. Always bear in mind that no matter how wonderful the gadget is that you’ve built, or how user-friendly the software; the majority of your marks will be given for the project report. If you have some brilliant idea, or solve some irritating bug in a creative way, you won’t get much credit for this unless you write it down in the report. If in doubt – write it down and include it (as an appendix if nowhere else seems appropriate). Project Report Marking At the University of York, we mark projects according to a number of criteria: format and presentation, grammar, originality, ability to work with others, ability to work alone, problem solving, dedication and the ability to plan, amongst them. To get marks, we need to see evidence for each of these things in the report. That means the format, presentation and grammar have to be good, and that’s quite straightforward to achieve; but it’s less obvious how to provide evidence of “ability to work alone”, or “originality”.
These things have to be done indirectly: the last thing I want to read is a table listing all the ideas you had during the course of the project, neatly summarised. The best way I know to do this is to write the main sections of the report in almost a diary form: for example, “the program didn’t compile, so it was suggested that the web be searched to see if someone else had come across the same problem. After some time spent searching for help; a page of known compile bugs was found [[i]], which suggested the use of the linker’s -qc option, and this then worked”.
Now I know whose idea it was to try this option, who thought of looking on the web, and who did the actual web-searching, and I can mark accordingly. (Personally, I don’t mind the use of the first person in writing reports, and the IEEE appear to agree with me [[ii]], but I know a lot of my colleagues differ with me on this issue. I suggest you check with your supervisors before starting to write. The safe option is to use the passive tense wherever possible, although that can make it difficult to identify who did what, a particular problem in group projects.
Some people use the “royal we”, but I’d discourage this, except of course if you happen to be the crowned head of a country. Reading sentences like “we inserted the disk into the machine” when all the fingers involved in the movement clearly belonged to one person is just a little too silly. I can tolerate formality, but not at the cost of accuracy. ) The ability to plan is perhaps best demonstrated in a separate chapter of the report. One thing that often separates 2. projects from 1st projects is the ability of the student to step outside the day-to-day linear task of just doing the project, and consider the project management aspects, and wider contexts as well. Why is the project being done? Who is going to be interested in it? What resources were available for the project? Were they sufficient? Could you have achieved more with more money? What was the original time-plan for the project, and was it followed? If not, why not, and how would you do things differently next time? Is it cost-effective? Has the project been worthwhile to you personally? What have you learned from it?
Has it changed your impression of what it means to be an electronic engineer / researcher? One other golden rule while I remember it: it must be obvious what you did, and what ideas you had yourself and didn’t find on a web-page or from other reference. (This is another difference between a project report and a technical report: in a technical report no-one would care whose idea it was, or who did what. ) Another golden rule while I’m at it, true for both project reports and technical reports: you should always include enough detail about any experiments performed that another researcher could come along and repeat your results. Resources on the Web There are a lot of good introductions to technical report writing on the web; but bear in mind that most of them are concerned with technical reports, not project reports (and the two are slightly different). It’s well worth reading a few of these to get an idea of the subject and issues of technical writing.