The individual project is in many ways the most important single component of the MSc 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 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 course.
The Projects Coordinator(s) are responsible for the overall coordination of MSc individual projects. You can contact the coordinator(s) if you have any problem with the formal organisation of your individual project.
To pass your project you must demonstrate the ability to conduct basic background research, to produce a non-trivial implementation or piece of theoretical work, and to write a report. Specifically, a project must:
Here are the steps in choosing an individual project.
The three preferences indicated in the last step must involve at least two different supervisors.
Please do not deselect the projects you have selected in the first step even if they are not one of your shortlist preferences. Selection information provides valuable feedback on the popularity of projects.
The idea for your project may be a proposal from a member of staff or your own, or perhaps a combination of the two. You should discuss the projects that interest you with the supervisors as soon as possible so that you have plenty of time to think about the best choices for you. Not every project is suitable for every student; some may be specifically tailored to a particular degree or speciality, 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.
If you have your own idea for an individual project (an "own 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.
Own projects can be based in other departments. However, the official supervisor of the project must be an academic in this department. Such projects will not be approved unless a suitable internal supervisor can be found.
Own project proposals can originate from outside the College (e.g., from actual or potential employers or sponsors), but you must provide clear details of what the project involves, have the approval of the Course Director, and find an official supervisor for the project from within the department. In exceptional cases permission may be given by the Course Director to do the project work in another institution or country, subject to suitable arrangements for regular contact with your supervisor. Own projects based in industry have special rules.
Allocation of projects (and, therefore, supervisors) to students is performed by the Projects Coordinator who takes account of your indicated preferences and the those of the supervisors. However, please note that allocation is an over-constrained probem: your first preference cannot be guarateed, 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 may be allocated one of your alternative preferences, or even asked to indicate further preferences among your selected projects.
You are permitted to develop software or hardware on your own equipment, provided that you can duplicate it here in College for demonstration to your supervisor. However, you should prepare a fall-back position in case your equipment misbehaves. Remember that the software on home computers could be unreliable at times. It is not unusual for a potentially good project to be spoilt by bugs in compilers, libraries, etc., on home computer equipment.
You will need to make a request to CSG if you wish to use software that is not currently provided. A request can then be made to purchase it if an acceptable alternative is not available. A purchase request will need the support of your supervisor and is not guaranteed to be approved.
Please note that there is no excuse for failing to keep adequate backups. If you lose your program, your data, or your report because of a system failure, no allowance can be made. Extensions will not be granted under these circumstances.
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. You should inform the supervisor of your college address and any changes to it, so that they can contact you, if/when necessary. If you need to talk to your supervisor between meetings and cannot locate them in their office, leave a note or send email, asking them to suggest a time when they will be available. Prepare a written list of points you wish to discuss before you go to see your supervisor. Take notes during the meeting so that you do not forget the advice you were given or the conclusions that were reached.
As engineering professionals you should be aware of the relevant codes of ethical conduct. You should also be aware of and take interest in IT-related legislation. To these ends you should start by ensuring you have read the following documents:
You should discuss possible legal, social and ethical considerations with your supervisor at the start of the project. Your aim should be to fill in this ethics checklist. It is possible that you will tick "No" for all items of the checklist, but they must all be considered.
Your final report should include:
A penalty of 10% will be deducted from your project mark if these two appendices are missing or unsatisfactory.
The background report should describe the research you have completed in preparation for the work of the project, due on the date given on the main page. You should summarise the essential material related to the subject of the project. There is no minimum or maximum page length, but typical reports are between 10 and 20 pages long. The material can be incorporated into the project final report.
You should also include a separate section on progress that describes: the activities and accomplishments of the project to date; any problems or obstacles that might have cropped up and how those problems or obstacles are being dealt with; and plans for the next phases of the project.
Finally, you should include the completed ethics checklist described in the section Legal and Ethical Considerations.
Submission is via CATE in the usual manner (the exercise can be found in the Summer Term period for your respective course). The report is not marked for credit. Extensions will be granted only in the most exceptional circumstances.
The project report is an extremely important part of the project. It serves to show what you have achieved and should demonstrate that you:
Your second marker will most likely not have followed the project throughout and will only have a short time to see a demonstration. For this reason they will rely heavily on the report to judge the quality of your work. You should also appreciate that the external examiner, who plays a crucial role in the final recommendation, has 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 definitely 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 any software, hardware, theory, etc. that you develop during the project are merely a means to this end. Do not make the mistake of leaving the report 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.
A project will not be awarded a distinction if its report is not of distinction quality, no matter how good the technical work is, and a project will not pass if its report is poor, even if the technical work is acceptable.
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.
Remember that quantity does not equal 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. Also, it is important to appreciate that the appropriate size and structure of the report can vary significantly from one project to the next. Despite these variations, however, most good reports have the following components in common:
Title page: This has the standard form given here.
Abstract: The abstract is a very brief summary of the report's contents. It should be about half page long. Somebody unfamiliar with your project should have a good idea of what it is 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 they 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. If possible you should include page numbers indicating where each chapter/section begins. Try to avoid too many levels of subheading. Try if possible to stick to sections and subsections; subsubsections are usually avoidable.
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 the reader. It should summarise everything you set out to achieve, provide a clear summary of the project's background and relevance to other work, and give pointers to the remaining sections of the report that contain the bulk of the technical material.
Background and related work: The background and related work section of the report should set the project into context by relating it to existing published work that you read at the start of the project when your approach and methods were being considered. There are usually many ways of approaching a given problem, and you should not just pick one at random. Describe and evaluate as many alternative approaches as possible. 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. Do not be afraid to acknowledge the sources of your inspiration; you are expected to have seen and thought about other people's ideas, so your contribution largely will be putting them into practice in some other context.
Body of report: The central part of the report typically consists of three or four chapters detailing the technical work undertaken during the project. The structure of these chapters is highly project dependent. Usually they reflect the chronological development of the project, e.g., design, implementation, experimentation, and optimisation, 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. For implementation projects you should describe and justify the design of your system at some high level, for example by using any of the design methods taught during the first- and second-term courses, and should document any interesting problems with, or features of, your implementation. Integration and testing are also important to describe. Your supervisor will advise you on the most suitable structure for these middle sections.
Evaluation: All projects need to contain a serious and careful evaluation of their results. The specifics of the evaluation method (e.g., user study, experiments, formal proof review, etc.) are intrinsic to the nature of the project, so this is something that you must discuss and agree with your supervisor early in the project. Ideally, a presentation of the method and results of your evaluation should be included in its own separate section of the report.
Conclusions and future work: All good projects conclude with an objective evaluation of the project's successes and failures, and suggestions for future work that can take the project further. 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. Your assessors are bound to spot the limitations of your work and you are expected to be able to do the same.
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 you should state where it is published, including full issue number, 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).
Appendices: Appendices contain information that is peripheral to the main body of the report. Information typically included are things like program listings, tables, proofs, graphs, or any other material that would break up the theme of the text if it appeared in situ. Large program listings are rarely required, and should be compressed as much as possible, e.g., by printing in multiple columns and by using small font sizes, omitting inessential detail.
Ethics: You should include two appendices explaining the ethical and professional considerations of your project.
User guide: For projects that result in a new piece of software, you should provide a proper user guide providing easily understood instructions on how to install and use it. A particularly useful approach is to treat the user guide as a walk through of a typical session, or set of sessions, that collectively display all the features of your software. Technical details of how the software works is rarely required. Keep it concise and simple. The extensive use of diagrams illustrating the software 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 as an appendix to the main report.
A note on ISOs and MRes research projects: Your MSc individual project must be distinct from any ISO/MRes you previously conducted. The principle is this: You cannot receive credit in both an ISO/MRes and the MSc individual project for the same work (i.e., no "double dipping").
This does not mean your project must be in a different area, but it does mean that it must be a significant extension in its own right. If your ISO/MRes is related to the project, you must include within the project report an explicit and detailed summary of the results of that ISO/MRes and its relationship to the project. This summary should be approximately three to five pages in length, and should be given as a subsection of the background section.
A particular issue arises when your ISO/MRes contains, or is substantially, a literature review that is relevant to your project. A summary of this can be reproduced with attribution in the project report (most likely in the background section). However, since the survey was assessed as part of your ISO/MRes, it will not contribute to the assessment of your project. The implication, then, is that your project and its report must compensate, that is, by being more substantial in some other way, such as in the ultimate result achieved or in the depth of the evaluation performed.
A note on plagiarism: Avoid plagiarism at all costs: 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 at the point they are referred to or used, rather than just listing them at the end. The College takes a very strict line on plagiarism; you are advised to review the College's official plagiarism policy.
Near the end of your project but no more than one week after the due date of the project report you must give an oral presentation and demonstration to your supervisor and second marker. The oral presentation will provide an overview of the project, its goals, and its accomplishments. The demonstration will indicate the degree to which the goals have been realised in a tangible form (typically as running software).
You are responsible for arranging with your supervisor and second marker a suitable time for the oral presentation and demonstration. You should arrange this time well in advance, as schedules are tight at that time of year. The exact format for the oral presentation and demonstration will be decided between you and your supervisor.
The assessment of the project will be undertaken by the supervisor and a second marker in the first instance. A selection of projects, including all borderline cases, are assessed by several other qualified persons, and by an external examiner. Note that some element of originality is expected in all projects.
Appropriate implementation details, such as source code or circuit diagrams, should normally be included as an appendix, together with indications of sample runs. Projects that are predominantly survey reports must be backed up with experimentation, implementation, theoretical or conceptual analysis, new illustrative examples, and so on.
Projects are given one of the following grades when awarded marks in the indicated ranges:
A Pass-level project is one that displays an ability to solve well-defined, moderately low-risk problems competently. However, the project may lack ambition or fail to overcome the more difficult challenges associated with the problem area. The resulting software/hardware should be broadly functional, although it may be limited in scope.
A Merit-level project is one that displays both breadth and depth and should demonstrate a high level of individual technical competence and professionalism, although the final output might lack elements of novelty or sparkle. There should be at least a moderate level of risk in the project's objectives, in that the project was not completely specified at the outset or that the work presented some difficult challenges that needed to be overcome. All implementation work should be solid in terms of design and correctness, although there may be scope for improvements.
A Distinction-level project is one that demonstrates significant breadth and depth. It involves a combination of sound background research, an outstanding implementation or an outstanding piece of theoretical work, and a well-structured and well-presented report detailing the project's background, objectives and achievements. The project involves significant technical problems that have been largely, or completely, overcome.
A Distinguished-level project is similar to a Distinction-level project, but in addition it must contain a substantial and significant original contribution from the student. This should be publishable in some form, or be potentially marketable. There should be no substantial weaknesses beyond those reasonably expected given the project timescale. The quality of the report must be excellent. The report must display a comprehensive understanding of the relevant related work, and must include detailed evaluation of the project's contributions with respect to this. The reports of Distinguished projects will be published on the departmental web site, and will serve as examples of our top projects.
Three aspects of each project will be assessed.
One of the most useful things to know about individual projects is the common pitfalls. Why do some projects go wrong? Here are some of the common causes of failure:
January: Project proposals are posted. You should study the project proposals, and discuss several of them with the members of staff who proposed them. Proposals will continue to arrive during the term, so keep looking at the list. You can also suggest your own ideas for an individual project, provided that you prepare a detailed project description and discuss it with a member of staff who is willing to be your supervisor.
February: Submit your project preferences via the DoC Project Portal. Soon afterwards, the project allocation will be conducted.
End of examination period through the summer: You should start work on your project as soon as you have completed your examinations. Plan your work. You have the whole summer before you and it is very easy to underestimate the time required to complete the project. Do not write the report in the last week, but write it as you work on the project.
Early June: You should submit a background and project progress report. You should summarise the essential material related to the subject of the project, as well as detail the work that you have done so far together with your plans and schedule for timely completion of the project. The background and progress report will be reviewed by your supervisor. Details of how to submit the report can be found here.
Late Summer: Arrange an oral presentation and demonstration of your project with your supervisor and second marker (and anyone else who may be interested in the subject area) well before the submission date. The format should be decided in consultation with your supervisor.
Early September: Submit your final report in electronic form.
The only formatting requirement for your report is that it should be clearly readable, with enough whitespace for your markers to make notes if they want to. The suggested font size is 11 or 12pt, with a clear margin (2--3cm) on all sides. Go here to read how to achieve this using either Microsoft Word or LaTeX. A LaTeX template including a formatted title page is available.
Reports are to be submitted by the deadline specified on the main page, unless an extension has been authorised in writing by the Course Director and agreed with your supervisor. Only in the most exceptional circumstances will an extension be granted.
There are two files to submit electronically in CATE:
Imperial College London
Department of Computing
Name and Initials
Submitted in partial fulfilment of the requirements for the MSc Degree in XXXXX of Imperial College London