- First filtering
- Resource availability
- Working with human participants
- Block plan of the project
- Planning for success
- Re-use of projects that have been attempted in the past
- Preparing the Project Proposal and consulting Overseers
From Idea to Definite Plan
Turning a rough idea into a well thought out and clearly presented project plan can be a large amount of work. This section suggests some of the variety of things to keep in mind when planning. The amount of effort needed at this stage will also vary greatly from project to project. At one extreme will be ideas that come from a Supervisor, where major details have already been identified and which use only standard computing resources. At the other will be ones that start off nebulous, or with a clear ideal objective but no clear understanding of whether it can be achieved within the year. Throughout the planning phase the things that can help you most will be strong leads from project originators and the judgement of those (e.g. Overseers) who have seen the process unfold before.
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 will not be 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.
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.
In some cases a project may need to build on algorithms described in a technical report or other document known to exist but not immediately available in Cambridge. If a proper demonstration of a project will rely upon the availability of bulk data (e.g. a sample database, or machine-readable versions of the text of a novel) then this must be considered critical even if work could start without the data.
Non-standard hardware is probably the form of resource that can cause most trouble here, where the term “non-standard” is to be taken to mean anything other than a normal student account on Computing Service equipment (e.g. MCS). Thus other workstations (e.g. research machines in the Computer Laboratory), elaborate graphics support, private computers, projects involving the construction of hardware (including getting chips fabricated via the organisers of the ECAD course) must count as special. Similarly the use of software beyond that already installed by and supported by the proprietors of the selected machines cannot be automatically assumed. Further information on special resources is given at http://www.cl.cam.ac.uk/teaching/projects/special.html
It is reasonable to suppose that disc space and machine time will be made available in amounts adequate for all but extreme projects, but those whose ambitions lean towards large databases or inherently lengthy calculations will have to check that they can be supported. In either case, a reasoned estimate of the resources required should appear in the project proposal. A modest increase in disc allocation on the MCS will be granted automatically, but you should read http://www.cl.cam.ac.uk/teaching/projects/special.html for further details and how to apply.
With these points in mind it is critical that the resources needed for any particular project be identified as early as possible - by project proposal time it will be necessary to have formal documented clearance to use any non-standard facilities.
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.
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 back up plan and revision control system if used (which is recommended). 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.’
Working with human participants
If your project involves experiments on human participants, such as 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 the Project Resource Form. Further information is on the web page:
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.
Block plan of the project
Large projects have to be broken down into manageable chunks if they are to be completed. You should take into account software engineering methods and should be prepared to justify your design choices in the dissertation. List the key components that will go to make up your final product. Plan an order in which you intend to implement them, 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.
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, vacations, revision and writing your dissertation. Looking at the detail of such a plan can give you insight into the feasibility of the project.
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. In the past projects have been carried out in C, C++, CLU, Lisp, ML, Modula-3, Prolog, Reduce and Java. Other languages that are supported by the Computing Service or are in regular use by a research group within the Laboratory will usually be acceptable.
Working in assembly code usually limits productivity too severely for it to make sense for project work, and BASIC becomes unduly clumsy as programs reach the scale expected of the project. 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. 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.
Planning for success
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.
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.
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 proper 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.
Preparing the Project Proposal and consulting Overseers
From the briefing session until the final draft of your project proposal is ready you should keep in touch with both your Overseers, 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. In most cases the best way of contacting Overseers will be using e-mail, and you should make a point of checking daily for messages that may have been sent to you. 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 e-mail, making sure to send copies to both Overseers.
Phase 1: Selecting a topic
You might already have thought of a suitable topic by the briefing meeting; if you have not, then you need to work quickly. 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” (available at
e-mail it, as a plain text message (not Word, HTML, PDF, PostScript
etc.), to your Overseers for their approval.
Phase 2: 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 well be preparatory work and the last three writing your dissertation, with the practical work in the middle. These should have 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
For more advice as to the content of your proposal, see Section 7.
Phase 3: Final draft
In the light of your Overseers’ comments, produce a final copy in the standard format. You now need to secure the signatures of your Supervisor and Director of Studies (in that order) and of the proprietor of any special resources that you need to use.
You do not secure signatures from your Overseers at this stage.
Simply submit the proposal.
Some time 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.