Early in Michaelmas Term you need to submit a project proposal that describes what you plan to do and how you plan to evaluate it. The deadline for project proposals is in the first week of term. In case of sickness or another good reason, your Director of Studies can request a deadline extension on your behalf by contacting teaching-admin@cst.cam.ac.uk.
You must ensure that your Supervisor(s) and your Director of Studies are happy with your proposal before you submit it, and they will need to sign off on your proposal to confirm that they are happy with you choosing this project. Please send them drafts of your proposal well in advance of the deadline so that they have time to give you feedback. Often, several rounds of feedback and iteration are needed before your initial idea is refined into a suitable project plan, so make sure you leave enough time. Once you have submitted the proposal you can start work on the project.
Choosing a project
You have a great deal of freedom in the selection of a project, and should start narrowing down the possibilities by identifying starting points or ideas that appeal to you. These initial ideas should be refined to a coherent project plan, which is then submitted as the project proposal.
The main sources of inspiration are commonly:
- Ideas proposed by candidates.
- Suggestions made by Supervisors or Directors of Studies.
- The project suggestions on the projects web page.
- Past years’ projects. Most recent dissertations are available to read online,
- Proposals put forward by industry, especially companies who have provided vacation employment for students.
When ideas are first suggested or discussed it is good to keep an open mind about them—a topic that initially seems very interesting may prove unreasonable on further consideration, perhaps because it will be too difficult. Equally, many ideas on topics that are unfamiliar to you will need study before you can appreciate what would be involved in following them. Almost all project suggestions should also be seen as starting points rather than fully worked out proposals.
Notes on project choice
Some project ideas can be discarded very quickly as inappropriate. It is almost always best to abandon a doubtful idea early on rather than to struggle to find a slant that will allow your Supervisor(s) and DoS to accept it. Projects are expected to have significant Computer Science content; for example, writing an application program or game, where the main intellectual effort relates to the area supported rather than to the computation, are not suitable. Machine learning projects that simply use existing libraries and do not require much software development are not suitable either. Projects must also be about the right size to fit into the time available. The implications of this will best be judged by looking at past years’ projects and by discussing plans with your Supervisor or DoS. They should not allow you to waste much time considering either ideas that would prove too slight or ones that are grossly overambitious.
It is important to pick a project that has an achievable core and room for extension. You should pick a suitably challenging project, where you will likely have to learn new things in order to successfully complete it. In addition, it is expected that you will make use of existing libraries and tools (i.e. don’t reinvent the wheel) unless there is a good reason for producing your own implementation.
Re-use of projects that have been attempted in the past
Projects are intended to give you a chance to display your abilities as a computer scientist. You are not required (or indeed expected) to conduct research or produce radically new results. It is thus perfectly proper to carry out a project that has been attempted before, and it is commonplace to have two students in the same year both basing their projects on the same original idea.
In such cases it is not acceptable to run a simple action replay of a previous piece of work. Fortunately all projects of the required scale provide considerable scope for different approaches; producing a new variation on an existing theme will not be hard. Furthermore the report produced at the end of a previous attempt at a project will often identify areas that led to unexpected difficulties, or opportunities for new developments—both these provide good scope for putting a fresh slant on the ideas involved.
Supervision (changed in 2025/26)
Every Part II project has two supervisors: the Day-to-Day Supervisor and the Marking Supervisor. The Day-to-Day Supervisor can be almost anybody: for example, a PhD student, a postdoc, a lecturer, or an experienced person outside of the department. The Marking Supervisor must be a University Teaching Officer (UTO, i.e. lecturer/professor) in the Department, or someone of comparable experience approved by the Department. If the Day-to-Day Supervisor is a UTO, the same person can also be Marking Supervisor. The Day-to-Day Supervisor can also be your DoS, in which case the Marking Supervisor needs to be someone else.
Most of your guidance and support over the course of the project will come from your Day-to-Day Supervisor, whom you will normally meet every 1–2 weeks to discuss progress and any problems you are facing. The Marking Supervisor normally only gets involved at a few points in the process: giving feedback on your project proposal and approving it; checking in on project progress twice a term; attending your progress presentation; viewing the working artifact that you have developed; giving high-level feedback on one dissertation draft; and marking the final dissertation in conjunction with the Examiners. In case you have problems with your Day-to-Day Supervisor, it’s the Marking Supervisor’s responsibility to help you get back on track.
Finding suitable Supervisors is your responsibility. You can try contacting a UTO in the area you want to work in, and they might be able to suggest a Day-to-Day Supervisor for you or supervise a project themselves. You can also contact potential Day-to-Day Supervisors directly; if they are in the Department, their PhD Supervisor or PI would typically be the Marking Supervisor (but it could also be someone else). Do not assume that a person suggesting a project will be willing to supervise it. Formally, your Director of Studies has to appoint your Supervisors, but they will generally be happy as long as you propose someone competent.
The first critical role of both Supervisors is to help you develop and refine your project proposal. You need to work with them to ensure that your proposal is appropriate: not too easy and not too hard; challenging but not too risky. Listen carefully to any concerns they raise and be prepared to go through several revisions before you have a workable plan. The purpose of this process is to reduce the risk of you realising half-way through the year that your project is in fact impossible, and having to start over with little time remaining.
Resources
Each project will have a number of critical resources associated with its completion. If even one of these fails to materialise then it will not be possible to proceed with a project based on the idea; your Supervisors and Director of Studies can help you judge what might be a limiting issue.
The project proposal must contain as its last section a Resources Declaration. This must explicitly list the resources needed and give contact details for any person (apart from yourself) responsible for ensuring their availability. These people will also need to sign off on your project proposal.
What qualifies as a critical resource?
In some cases a project may need to use data, software, or hardware that are not immediately available in Cambridge. In this case, this must be considered critical even if work could start without that material.
In most cases you will use your own computer to work on the project. That is fine, but please state its specifications and also state your contingency plan in case it should fail. Please also state your plan for backups and the revision control system you plan to use. Please include the following text in your declaration:
I accept full responsibility for this machine and I have made contingency plans to protect myself against hardware and/or software failure.
Using any hardware or software other than that available through a normal student account on UIS equipment is considered non-standard. This includes research machines in the Department, GPUs, FPGA boards, or even Raspberry Pis. Likewise, use of software that is not freely available as open-source is non-standard and must be declared.
High-Performance Computing Resources
If your project requires computing resources that are greater than your own computer (for example, GPUs for model training or a cluster for a distributed computation), you must get a written guarantee that you can access this resource before submitting your project proposal, including an estimate of the resources and machine time required. Although the University and Department do have High-Performance Computing (HPC) and GPU clusters, these are not normally accessible to undergraduates, and you must not assume that you can use them unless this has been explicitly confirmed to you. There can be a cost to using these services.
It is possible to use commercial cloud computing services to rent computing resources. If you choose to do this, your project proposal must include an estimate of the resources required, and an explanation of how their cost will be covered. You may apply for credits from cloud vendors to use their services for free, but beware that applications for credits can be rejected, can take several months, and you need your application to be approved before you submit your project proposal if you want to include the use of credits in your proposal.
Department Accounts
Access to Departmental computers can be granted if there is a good reason, e.g. for collaboration with a particular research group. If you plan to use a Department account then state this and explain why it is needed in your resources declaration. If relevant, the signature of a sponsoring member of the department (e.g. the owner of the specific resource) is required to sign off on your project proposal. In addition, your Supervisor should send an email to sys-admin@cl.cam.ac.uk requesting the account with a brief justification.
Door Entry
Access to the Department can be granted if there is a good reason. If you require access to the secure part of the William Gates Building, you should state who will be responsible for you whilst you are on the premises. They will need to sign off on your project proposal.
Third-Party Resources
Resources (such as data or software) provided by anyone outside the Department, e.g. industrial collaborators, must be declared. The name and contact details (including email address) of the person in charge of the resource must be stated, and you must have their written confirmation that they are making the resource available to you at least until the end of the academic year. Resources from third parties can sometimes disappear unexpectedly, so please state why you believe this is not going to happen or else state your contingency plan in case it does.
Sponsors must understand that the results of work done by students cannot be viewed as secret or proprietary. The Examiners will require electronic submission of your dissertation and code, and they will not sign a non-disclosure agreement relating to your project. Therefore, you should not sign anything, such as a non-disclosure agreement, that would prevent you from submitting them.
Working with human participants
If your project involves human participants in any way, involves data relating to living individuals, or has the potential to otherwise cause harm, you must seek approval from the Departmental Ethics Committee. This includes the use of personal data that others have collected, your own collection of data via surveys, interviews or online, release of instrumented software that tracks user behaviour, fieldwork, or experiments with human participants, such as usability trials or asking people to evaluate some aspect of your work.
You can submit your application to the Ethics Committee after you submit your project proposal, but you must state in your proposal that ethics approval is required, and you must obtain the approval before any of these activities start. Please read the Department's ethics policy.
Your project Supervisor will help you to fill in an online form (read-only version) containing two questions:
- A brief description of the study you plan to do;
- The precautions you will take to avoid any risk.
Simple guidance related to the most common types of study is available on the School of Technology Research Guidance site. You may also find it useful to discuss your plans with the person supervising you for the HCI course.
After submitting the ethics review form, you will receive feedback from the Ethics Committee within a few days. You must not start any study involving human participants without approval from the Ethics Committee.
Planning the project
As part of the project proposal, you should provide a detailed description of the work that needs to be performed, broken down into manageable chunks of two weeks at most. You will need to identify the key components that will go to make up your final deliverable. Credit is awarded specifically for showing a professional approach using any relevant management or software engineering methods at all stages of project design, development and testing or evaluation. Plan an order in which you intend to implement the project components, arranging that both the list of tasks and the implementation order provide you with a sequence of points in the project where you can assess progress. Without a set of milestones it is difficult to pace your work so that the project as a whole gets completed on time.
Timings
When you have decomposed your entire project into sub-tasks you can try to identify which of these sub-tasks are going to be hard and which easy, and hence estimate the relative amounts of effort involved in each. These estimates, together with the known date when the dissertation must be submitted, should allow you to prepare a rough timetable for the work. The timetable should clearly make allowance for lecture loads, module coursework, vacations, revision, and writing your dissertation. Looking at the details of such a plan can give you insight into the feasibility of the project.
You should plan to start writing the dissertation at least six weeks before the submission date. Writing always takes longer than you expect, so it is wise to start early – for example, you can start writing the Introduction and Preparation chapters before the implementation is complete, and you can start writing the Implementation chapter before you are finished performing your evaluation.
Languages and tools
It will also be necessary to make decisions about operating systems, programming languages, tools, and libraries. In some cases there will be nothing to decide because the essence of the project forces certain choices. However, where you do have a choice, then take care to balance out the pros and cons of each option. It is expected that students will be prepared to learn a new language, framework, or operating system if that is a natural consequence of the project they select.
Uncommon languages or ones where the implementation is of unknown reliability are not ruled out, but must be treated with care and (if at all possible) you should make fall-back arrangements in case insuperable problems are encountered.
Risk management
Projects are planned at the start of the year, and consequently it can be hard to predict the results of decisions that are made; thus any project proposal involves a degree of risk. Controlling and managing that risk is one of the skills involved in bringing a project to a successful conclusion. It is clear where to start: you should identify the main problem areas early and either allow extra margins of time for coping with them or plan the project so that there are alternative ways of solving key problems. A good example of this latter approach arises if a complete project requires a solution to a sub-problem X and a good solution to X would involve some complicated coding. Then a fall-back position where the project can be completed using a naive (possibly seriously inefficient, but nevertheless workable) solution to X can guard against the risk of you being unable to complete and debug the complicated code within the time limits.
Planning the write-up
As well as balancing your risks, you should also try to plan your work so that writing it up will be easy and will lead to a dissertation in which you can display breadth as well as depth in your understanding. This often goes hand-in-hand with a project structure which is clearly split into sub-tasks, which is, of course, also what you wanted in order that your management of your work on the project could be effective.
A good dissertation will be built around a varied portfolio of code samples, example output, tables of results and other evidence of the project’s successful completion. Planning this evidence right from the start and adjusting the project specification to make documenting it easier can save you a lot of agony later on.
Submission and Content of the Project Proposal
Completed project proposals must be submitted via Moodle by the published deadline. Once both your Supervisors and your DoS have told you that they are happy with your project proposal, please submit it through this online form. Another UTO may check your submitted proposal and contact you in case of concerns. If all is fine we won’t contact you, so you can start working on your project as soon as you have submitted the proposal.
Format of the proposal
The submission form asks for a few details (project title, names of your Supervisor(s) and DoS, whether ethics approval is required, and provider of any special resources required). The rest of the proposal should be submitted as a PDF file that may be up to 1000 words long. It consists of the following:
- An introduction and description of the work to be undertaken.
- A statement of the starting point.
- Description of the substance and structure of the project: key concepts, major work items, their relations and relative importance, data structures and algorithms.
- A plan for evaluating your project to determine whether it has been a success.
- Plan of work, specifying a timetable and milestones.
- Resource declaration.
Introduction and description
Explain both the background to the work you propose to do and of the objectives you expect to achieve. You should give details of specific goals to be achieved and precise characterisations of the methods that will be used in the process. You should identify the main sub-tasks that make up your complete project and outline the algorithms or techniques to be adopted in completing them.
Starting point
A statement of the starting point must be present to ensure that all candidates are judged on the same basis – namely, the work you have done between October and May. If you have done a significant amount of work in the area of your project before the proposal submission, for example creating a significant body of code or other material that will form a basis for your project, you must declare it as your starting point.
Provided a proper declaration is made here, it is acceptable to build your final project on work you started earlier, or to create parts of your programs by modifying existing ones written by somebody else. The larger the input to your project from such sources, the more precise and detailed you will have to be in reporting what baseline you are starting from.
Success criteria and evaluation plan
A proposal must specify what it means for the project to be a success. It is unacceptable to say “I’ll just keep writing code in this general area and what I deliver is what you get”. It is advisable to choose a reasonably modest, but verifiable, success criterion which you are as certain as possible can be met; this means that your dissertation can claim your project not only satisfies the success criterion but potentially exceeds it. Projects that do not satisfy the success criterion are liable to be seen as failures.
Along with the success criteria, you must explain how you plan to evaluate your project – that is, how you demonstrate in your dissertation that the success criteria have been met. This could take many forms: performance measurements, tests for correctness, experiments with human subjects, comparisons with alternative approaches, formal proofs, etc. – but it is important that your plan for evaluation is clear.
An unclear evaluation plan is the weak point of many project proposals, but a thorough evaluation is a crucial part of rigorous science. Think about how you will convince a skeptical reader of your dissertation that you have been successful. It’s not sufficient to have done some neat work: you also need the evidence to back up your claims, and the evaluation is how you produce that evidence.
Work plan
You need to describe how your project is split up into two-week work packages and milestones, as explained in the planning section. Some of these might be preparatory work and reading, some implementation, some evaluation, and some writing your dissertation.
Each work package must have a due date (e.g. “10 November”, not “week 5”) and a clearly defined deliverable: that is, what you plan to have achieved by that point. It is important that it is measurable, so that you can tell whether you are on track or not. It is likely that some things will take longer than planned and others go quicker, and that is okay – you don’t lose marks if you revise the timetable over the course of your project. But you need to be able to tell whether you are on track or not so that you don’t run out of time to complete your evaluation and write your dissertation.
It is also essential that you take into account other demands on your time in your work plan. Module assessment and supervision work can take a lot of your attention during term time, and you also need to include some time to rest and recharge. Including some buffer time in case earlier work packages overrun is also wise.
Resource declaration
You should list resources required, as described in the resources section.
