Project Proposal




Department of Computer Science and Technology
Current students
Part II
Part II projects




Important dates
Project suggestions
Overseer groups
Project proposal
Advice on running the project
Progress report and presentation
The dissertation
Submission
Assessment
Supervisor briefing notes
Overseer briefing notes
Past overseer groups ➥
Part II Supervision sign-up
Part II Units of Assessment
Part II Supervisions overview
Continuing to Part III

Part III of the Computer Science Tripos
o
o
o
o
o
o
o
o
o
o
o
o
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. In order to help with this process, you are assigned two Overseers,
who, together with your Supervisor and Director of Studies, will provide advice on your ideas. The
deadline for project proposals is a little over one week into term, and is a hard deadline.
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 proposal will
be discussed informally with your Overseers, but is then submitted to the Head of the Department as
a formal statement of intent.
The main sources of inspiration are commonly:
1. Ideas proposed by candidates.
2. Suggestions made by Supervisors or Directors of Studies.
3. The project suggestions on the projects web page.
4. Past years’ projects. Most recent dissertations are available to read online,
5. 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 the Overseers to
accept it. Projects are expected to have a significant Computer Science content; for example, writing
an application program or game-playing program, where the main intellectual effort relates to the
area supported rather than to the computation, are not suitable. 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 a Supervisor or Overseer. 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
In some cases the most critical problem will be finding a suitable project Supervisor, somebody whom
you will see regularly to report your progress and obtain guidance about project work throughout the
year. This might be one of your main course Supervisors or a separate, specialist project Supervisor,
but it should not be assumed that a person suggesting a project will be willing to supervise it.
Supervisors have to be appointed by your Director of Studies, but in most cases it will be left up to
you to identify somebody willing and able to take on the task. The Overseers will be interested only in
seeing that someone competent has agreed to supervise the project, and that your Director of Studies
is content with that arrangement.
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
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. In particular, you should name the person responsible for you if your work
requires access to the Department research area. The signatures of these people should also be
present on the project cover sheet before submission.
What qualifies as a critical resource?
In some cases a project may need to use data or build on algorithms described in a technical report or
other document known to exist but not immediately available in Cambridge. In this case, this must be
considered critical even if work could start without the report or data.
Using any hardware or software other than that available through a normal student account on UIS
equipment (e.g. MCS) is considered non-standard. This includes personal machines, other
workstations (e.g. research machines in the Department), FPGA boards, or even Raspberry Pis if they
belong to someone else. Likewise, use of software written or owned by someone else that is not freely
available as open-source will be considered as non-standard and should be declared.
Additional MCS Resources
It is reasonable to suppose that disk space and machine time will be made available in amounts
adequate for all but extreme projects. Those who consider they may need more should provide a
reasoned estimate of the resources required in the project proposal in consultation with the
Supervisor. Additional file space should be requested through a web form, noting that:
 you should state in your application that you are Part II CST;
 requests for small increases of MCS space will need a very brief justification: please don't send
your proposal;
 requests for substantial increases should also be accompanied by a brief supporting email
to user-admin@uis.cam.ac.uk from your Supervisor.
Note that some MATLAB toolkits are not available on the MCS but might be available on Department
accounts.
Use of your own computer
If you are using your own computer, please state its specifications and also state your contingency
plan in case it should fail (such as using MCS or another personal computer). Please also state your
file backup plan and the revision control system you plan to use. If using your own computer 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.
Department Accounts
Access to Departmental computers can be granted if there is a good reason, e.g.
 collaboration with a particular research group;
 use of software not available on the MCS facility.
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 as an extra signature on the project cover sheet. In addition, your
Supervisor should send an email to sys-admin@cl.cam.ac.uk requesting the account with a brief
justification.
Some Department resources and the people who can authorise their use:
 Requests for resources involving a Department research machine should be authorised by a
Lecturer, Reader or Professor who is in charge of managing the equipment.
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 should sign your Project Proposal Coversheet as a Special Resource Sponsor.
Third-Party Resources
Resources provided by your College, other University departments or 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 their signature must be present on the project cover sheet. 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.
In the case of projects that rely on support from outside the University it will be necessary to procure
a letter from the sponsors that confirms both that their equipment will remain available right up to the
end of the academic year and that they understand that the results of work done by students cannot
be viewed as secret or proprietary.
You should bear in mind that the Examiners will require electronic submission of your dissertation and
code. 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 collection of data via surveys, interviews or online, release of instrumented
software, fieldwork, or experiments with human participants, such as usability trials or asking people
to evaluate some aspect of your work, then you must seek approval by submitting a human
participants request to the departmental Ethics Committee and record that you have done this by
ticking the appropriate box on your cover sheet. This must occur 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:
1. A brief description of the study you plan to do;
2. 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 Part II 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. You will need to identify the key components that
will go to make up your final product. 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. 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, unit-of-assessment 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. Ideally you should plan to start writing the dissertation at least six weeks before the
submission date.
Languages and tools
It will also be necessary to make decisions about operating systems, programming languages, tools
and libraries. In many cases there will be nothing to decide, in that the essence of the project forces
issues. 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 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) fall-back arrangements must be made 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.
Preparing the Project Proposal and consulting Overseers
You should keep in touch with both your Overseers from the briefing session until the final draft of
your project proposal, making sure that they know what state your planning is in and that they have
had a chance to read and comment on your ideas. Overseers will generally be reluctant to turn down a
project outright, but if you feel that yours sound particularly luke-warm about some particular idea or
aspect of what you propose you would do well to think hard (and discuss the issues with your
Supervisor) before proceeding. If Overseers declare a project plan to be unacceptable, or suggest that
they will only accept subject to certain conditions, rapid rearrangement of plans may be called for.
Dealings with your Overseers divide into three phases between the briefing session and submitting
your proposal. Most of the communications will be best arranged by email and all submissions of work
are on Moodle. Please be sure to take note of the various deadlines.
Phase 1 report: Selecting a topic
You start by preparing a Phase 1 report which, for 22/23 must be submitted on or before the first day
of Michaelmas Full Term in October Please pay careful attention to the points raised in the briefing
lectures regarding selection of an appropriate topic. You must certainly choose something that has a
defined and achievable success criterion. Note also that the marking scheme explicitly mentions
preparation and evaluation, so please select something that will require a corresponding initial
research/study phase and a corresponding (preferably systematic) evaluation phase.
You should complete a copy of the “Phase 1 Project Selection Status Report” and upload it to Moodle.
Subject: Phase 1 - your surname: your proposed dissertation title
Phase 1 Project Selection Status Report
Name:
College:
CRSID:
Director of Studies:
Please complete 1, 2 and 3 below.
1. Please write 100 words on your current project ideas.
2. Please list names of potential project supervisors, indicating
any interactions you have had with them, for example: not
contacted, awaiting reply, in discussion, agreed to supervise.
3. Is there any chance that your project will involve any
computing resources other than the Computing Service's MCS and
software that is already installed there, for example: your own
machine, machines in College, special peripherals, imported
software packages, special hardware, network access, substantial
extra disc space on the MCS.
If so indicate below what, and what it is needed for.
Phase 2: Full proposal draft: Filling out details
The details will include:
 Writing a description, running to a few hundred words.
 Devising a timetable, dividing the project into about 10 work packages each taking about a
fortnight of your effort. The first couple of these might be preparatory work and the last
three writing your dissertation, with the practical work in the middle. These should be
identifiable deliverables and deadlines leading to submission of your dissertation at the
beginning of the Easter Term. You will probably write your progress report as part of the
fifth work package.
 Determining special resources and checking their availability.
 Securing the services of a suitable Supervisor.
Send all this to your Overseers and ask them to check the details.
Phase 3: Final proposal
In the light of your Overseers’ comments, produce a final copy in the standard format.
You do not secure signatures from your Overseers at this stage. Simply submit the proposal.
Shortly after submission the Overseers will check your proposal again and, assuming that the
foregoing steps have been followed carefully, all should be well and they will sign the proposal to
signify formal acceptance. If the proposal is not acceptable you will be summoned for an interview.
Submission and Content of the Project Proposal
Completed project proposals must be submitted via Moodle by noon on the relevant day.
Format of the proposal
A project proposal is expected to be about 1000 words long. It consists of the following:
1. A standard cover sheet
2. The body of the proposal (see below).
When emailing drafts of your proposal to Overseers, please make sure they contain all of the
information required on the final cover sheet.
The body of the proposal should incorporate:
1. An introduction and description of the work to be undertaken.
2. A statement of the starting point.
3. Description of the substance and structure of the project: key concepts, major work items, their
relations and relative importance, data structures and algorithms.
4. A criterion that can later be used to determine whether the project has been a success.
5. Plan of work, specifying a timetable and milestones.
6. Resource declaration.
Introduction and description
This text will expand on the title quoted for your project by giving further explanation both of the
background to the work you propose to do and of the objectives you expect to achieve. Quite often a
project title will do little more than identify a broad area within which you will work: the accompanying
description must elaborate on this, giving 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 subtasks that make up your complete project and outline the algorithms or techniques to be adopted in
completing them. A project description should give criteria that can be used at the end of the year to
test whether you have achieved your goals, and should back this up by explaining what form of
evidence to this effect you expect to be able to include in your dissertation.
Starting point
A statement of the starting point must be present to ensure that all candidates are judged on the
same basis. It should record any significant bodies of code or other material that will form a basis for
your project and which exist at project proposal time. Provided a proper declaration is made here, it is
in order to build your final project on work you started perhaps even a year earlier, or to create parts
of your programs by modifying existing ones written by somebody else. Clearly the larger the input to
your project from such sources the more precise and detailed you will have to be in reporting just
what baseline you will be starting from. The Examiners will want this section to be such that they can
judge all candidates on the basis of that part of work done between project proposal time and the time
when dissertations are submitted. The starting point should describe the state of existing software at
the point you write your proposal (so work that you may have performed over the summer vacation is
counted as preparatory work).
Success criterion
Similarly, 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, as in real life,
liable to be seen as failures to some extent.
Work plan
You will need to describe how your project is split up into two- or three-week chunks of work and
milestones, as explained in the planning section.
Resource declaration
You should list resources required, as described in the resources section.
Failure to submit a project proposal on time
Any student who fails to submit a project proposal on time is in breach of a Regulation and will no
longer be regarded as a Candidate for Part II of the Computer Science Tripos. The Chairman of
Examiners will write to the appropriate Senior Tutor as follows:
Dear Senior Tutor,
XXX has failed to submit a project proposal for Part II of the Computer Science Tripos. The
Head of Department was therefore unable to approve the title by the deadline specified in
Regulation 17 for the Computer Science Tripos [Ordinances 2005, p268,amended by Notices
(Reporter, 2010-11, pp.94 and 352, http://www.admin.cam.ac.uk/univ/so/2011/chapter04section9.html#heading2-43)]. XXX is therefore in breach of the regulation and is thus no
longer eligible to be a Candidate for Part II of the Computer Science Tripos. Please could you
take appropriate action. I am copying this letter to the Secretary of the Applications Committee
of the Council.
Yours sincerely,
------------------------Chair of the Examiners
Department of Computer Science and Technology
William Gates Building
JJ Thomson Avenue
Cambridge, CB3 0FD