Guide to Individual Projects

Objectives

The individual project is by far the most important single piece of work in the degree programme. It provides the opportunity for you to demonstrate independence and originality, to plan and organise a large project over a long period, and to put into practice some of the techniques you have been taught throughout the course. Whatever your level of academic achievement so far, you can show your individuality and inspiration in this project. It should be the most satisfying piece of work in your degree. It is worth about a quarter of the final year marks.

The Project Co-ordinator

The Project Co-ordinator, Tony Field, is responsible for the overall organisation of the final year individual projects. You can contact him whenever you have any problem with the organisation of your individual project. Email: ajf@doc.ic.ac.uk, Room 376.

Choosing an Individual Project

The idea for your project may be a proposal from a member of staff or your own, or perhaps a combination of the two. The Project Administration System allows you to browse projects proposed by members of staff and to enter your own proposals.

Staff Proposals

For projects proposed by members of staff you should discuss the project with the proposer as soon as possible so that you have plenty of time to think about the best choices for you. Note that not every project is suitable for every student: some may be specifically tailored to a particular degree (e.g. BEng, MEng, ISE) and some may only suit students with a very specific set of interests. Each proposal will indicate these constraints in order to help you to make an informed choice.

Own Proposals

If you have your own idea for an individual project it is your responsibility to find a member of staff who both approves of the proposed programme of work and is willing to supervise it. You should first add your proposal to the database, then discuss it with prospective supervisors. The Project Coordinator will be happy to help you find a supervisor but you cannot assume that one can be found in every case.

Project Oursourcing Exercise

This is only applicable to Computing MEng4 students. Information can be found here.

Assessment

It is important when choosing a project to understand the way it will be assessed. A good first-class project involves a combination of sound background research, a solid implementation, or piece of theoretical work, and a thorough evaluation of the project's output in both absolute and relative terms. A good tip is to try to think of the project as an "investigation", rather than an effort to deliver a fully-functioning "product". Proper evaluation of the project is thus crucial to achieving high marks (see below).

The very best projects invariably cover some new ground, e.g. by developing a complex application which does not already exist, or by enhancing some existing application or method to improve its functionality, performance etc.

A straightforward implementation project is acceptable, but you must appreciate that it is unlikely to gain high marks, regardless of how well it is done. Likewise, projects which are predominantly survey reports, unless they are backed up with experimentation, implementation, or theoretical analysis, e.g. for performing an objective comparison of surveyed methods, techniques etc. Pure survey reports, with no supporting implementation or theory, are not acceptable.

Further details of the assessment criteria are given below.

Choosing the right project

The projects offered by staff may vary substantially in breadth, depth and degree of difficulty. The most important thing is to shortlist a set of projects that are right for you . Some students are better suited to well-defined and relatively safe projects that provide scope for demonstrating proficiency with a low risk of failure. Other students are better advised to tackle harder, riskier projects that require a high degree of original input and/or technical problem solving. If you are looking to achieve high marks in your project and, particularly, if you are hoping to win one of the illustrious project prizes, or achieve "Distinguished Project" status, you should choose your shortlist with particular care. The potential supervisors will be happy to offer advice on the suitability of a project, given your individual background, strengths and ambitions. Remember that it is important to balance ambition and realism when making a choice.

Allocation

The administration system requires you to specify one preferred project and two others. If you choose from the published proposals your first choice of project cannot be guaranteed since individual supervisors can only take responsibility for a limited number of projects. In some cases you may be allocated the project but another member of staff will be assigned to supervise it. Failing this, you will be allocated one of your other choices. It is extremely important to appreciate that the enthusiasm and interest of the supervisor is one of the keys to a successful project. Some students are disappointed when they do not get their preferred choice. However, you should bear in mind that it is much better to be supervised by an enthusiastic proposer of a `second choice' project, rather than someone who has reluctantly agreed to supervise a `preferred choice' project on behalf of the original proposer.

Equipment

You are permitted to develop software or hardware on your own equipment, provided that you can duplicate it here in College for the demonstration day. However, you should prepare a fallback position in case your equipment misbehaves.

If you require non-standard resources from CSG, e.g. specific hardware or software or access to specific machines, you must make a formal request to CSG as detailed in the CSG guidelines on project resources. Ideally, requests for resources should be submitted within two weeks of the project allocation date.

Note that there is no excuse for failing to keep adequate backups on your home computer. If you lose your program or your data or your report because of a system failure you will simply lose marks. No extensions will be given at the end of the project for you to re-type a lost report, for example.

Meeting Your Supervisor

You must make sure that you arrange regular meetings with your supervisor. The meetings may be brief once your project is under way but your supervisor needs to know that your work is progressing. If you need to talk to your supervisor between meetings and cannot locate them in their office, leave a note, or send mail, asking them to suggest a time when they will be available. When you go to see your supervisor (or second marker) you should have prepared a written list of points you wish to discuss. Take notes during the meeting so that you do not forget the advice you were given or the conclusions that were reached.

The Project Report

The project report is an extremely important aspect of the project. It serves to show what you have achieved and should demonstrate that: Most of the project assessors will not have followed the project throughout and will only have a short time to listen to a presentation or see a demonstration. For this reason they will rely heavily on the report to judge the project. Also, if in the end your overall degree marks put you on a boundary between two degree classifications, the final outcome can be influenced significantly by the quality of your project. You should appreciate that the external examiners, who play a crucial role in the final recommendation, have only the report by which to judge your project performance.

Many students underestimate the importance of the report and make the mistake of thinking that top marks can be achieved simply for producing a good product. This is fundamentally not the case and many projects have been graded well below their potential because of an indifferent or poor write-up. In order to get the balance right you should consider that the aim of the project is to produce a good report and that software, hardware, theory etc. that you developed during the project are merely a means to this end. Don't make the mistake of leaving the write-up to the last minute. Ideally you should produce the bulk of the report as you go along and use the last week or two to bring it together into a coherent document.

The physical layout and formatting of the report is also important, and yet is very often neglected. 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. Many supervisors will advise you to use LaTeX as this solves most of the formatting problems for you. This is not a requirement, but be aware that if you use a system like MS Word you may have to invest more time to get the layout right. If your report is to contain a substantial number of mathematical formulae you are strongly advised to use LaTeX.

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). Make sure this directory is readable! On the front page of the report you should print the directory path so that your project can be accessed electronically if needed. You can update this any time after submission of the report but a version of it should exist at the time of submission.

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 scene 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 sometimes 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 something like "All the objectives of the project have been met blah blah...". A project that meets all its objectives is, by definition, weak and unambitious. Concentrate instead on the big issues, e.g. the main questions (scientific or otherwise) that the project sets out to answer.

Background The background section of the report should set the project into context by relating it to existing published work which you read at the start of the project when your approach and methods were being considered. There are usually many ways of solving a given problem, and you shouldn't just pick one at random. Describe and evaluate as many alternative approaches as possible. 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 prior research. The published work may be in the form of research papers, articles, text books, technical manuals, or even existing software or hardware of which you have had hands-on experience. Your must acknowledge the sources of your inspiration. You are expected to have seen and thought about other people's ideas; your contribution will be putting them into practice in some other context. However, avoid plagiarism: if you take another person's work as your own and do not cite your sources of information/inspiration you are being dishonest; in other words you are cheating. 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. Make sure you read and digest the Department's plagiarism document .

Body of report The central part of the report usually consists of three of 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. although this is not always the best approach. However you choose to structure this part of the report, you should make it clear how you arrived at your chosen approach in preference to the other alternatives documented in the background. 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, for example based on numerical results, performance etc. or something more qualitative 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 blah...; - you will be shot down immediately! 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", or "The overheads of linear-time n-body algorithms makes them computationally less efficient than O(n log n) algorithms for systems with less than 100000 particles". Avoid tedious personal reflections like "I learned a lot about C++ programming...", or "Simulating colliding galaxies can be real fun...". 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, or extending the project into a programme for an MPhil or PhD.

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. You should give the full title and author and should state where it is published, including full issue number and date, and page numbers where necessary. 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. For example:

[1]  Bennett, A.J., Field, A.J. and Harrison, P.G., "Modelling and Validation of Shared Memory Coherency Protocols", Performance Evaluation, 1996, Vol. 27 & 28, 1996, pp. 541-562.

rather than just listing the source as "Performance Evaluation 1996".

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, proofs, 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 if possible.

User Guide For projects which result in a new piece of software you should provide a proper user guide providing easily understood instructions on how to use it. A particularly useful approach is to treat the user guide as a walk-through of a typical session, or set of sessions, which collectively display all the features of your system. Technical details of how the package works should be in the body of the report. Keep it concise and simple. The extensive use of diagrams illustrating the package in action prove particularly helpful. The user guide is sometimes included as a chapter in the main body of the report, but is often better in an appendix.

Program Listings Complete program listings should NOT be part of the report except in specific cases at the request of your supervisor.
The project report(s) must be bound in a departmental folder and must include a standard title page produced by the project co-ordinator. More of this nearer the date.

You are strongly advised to spend some time looking at the reports of previous project students to get a feel for what's good and bad. All reports from the last few years are available in hard copy form in the CSG library on level 2. In June 1999 we introduced a "Distinguished Project" classification, which is a formal recognition of outstanding projects for which no official prize was awarded. The complete list of prize winners and the other distinguished projects, along with links to the final reports, can be found here.

Project Assessment

The initial assessment of the project will be undertaken by the supervisor and second marker. The assessment will then be completed by the assessment team which is made up by supervisors and second markers of other projects, and by other teaching staff and researchers who are interested in the subject area. The team members will attend your presentation and agree a team mark. The team marks are later moderated to ensure that the marks are globally consistent. The projects are marked under the following headings:

Background Preparation This component assesses the way you arrived at your initial project specification, work programme and list of objectives. It particularly addresses the background research undertaken and the manner in which your approach and programme of work fits in with the current state-of-the-art. It is worth about 15% of the final mark.

General Competence This assesses your overall approach to the project and your ability to overcome the inevitable complications which arise. The specific areas in which you will be assessed are management and organisation, reliability and punctuality, overall technical competence, and your individual contribution to the project. This part of the assessment is worth about 25% of the final mark.

Technical achievement This assesses the main technical output from the project. It addresses specific issues such as the design, correctness, elegance, usability etc. of the final product and the significance of the work in relation to the state-of-the-art. It is worth about 30% of the final mark.

Report This part of the assessment is worth about 30% of the final mark.

The Project Presentation and Demonstration

One of the most important skills which the individual project aims to assess is your ability to communicate your ideas and work. As part of the assessment you will be required to give a presentation and demonstration of your project to your assessment team.

Each presentation will be timetabled for between 30 and 40 minutes (to be announced) including a demonstration where appropriate and questions. All presentation rooms will be networked. Your supervisor and second marker will be part of the team but you should bear in mind that the majority of the panel will not be familiar with your project; you should take this into account when planning your presentation. Your supervisor will help you to structure your talk and will be willing to go through it with you beforehand. The presentation is not assessed separately but is a compulsory component of the project. The assessment team will not allocate a mark for a project unless there had been a formal presentation. The objective of the presentation is to find out exactly what you have done and to ensure that you get an accurate mark that is consistent with other projects - it is not designed as an opportunity to shoot you down!

Bear in mind, that if you develop any software or hardware on your own kit, then you have to duplicate this kit here in College. It is your responsibility to ensure that the project works on that kit or to bring your own in for the presentation.

The Prize Finalists Day

The top projects recommended by each assessment team will be reviewed shortly after the presentations and a shortlist of prize candidates will be drawn up. These "prize finalists" will be invited to re-present their work at a special celebration event open to the department, alumni and invited guests from industry. All finalists will receive a special award from the Department. At the end of the day there will be a vote for a "Best Presentation" award and the departmental project prizes will be decided some time afterwards on the basis of the presentations, reports and assessment team comments. The end-of-year party will be held in the evening.

Grade Boundaries and Minimum Requirements

The grade boundaries set for individual projects are roughly in line with those of the overall degree programme, that is: Important - There are strict minimum requirements for individual projects for both the MEng and BEng degrees. In order to obtain an MEng degree at all, you must achieve at least 40% in you individual project, and in order to obtain honours in the BEng degree you must achieve at least 30% in the individual project. These requirements hold regardless of your performance in the other components of the degree.

Pitfalls

Some of the most useful things to know about individual projects are the common pitfalls. Why do some projects go horribly wrong? Here are some of the common causes of failure:
As important as the project is, however, do not let it interfere with your exam revision. You should plan not to spend any time on your project between the end of the spring term and your last examination.


Project timetable

Back to the projects home page