Department of Computer Science and Technology

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.

First filtering

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.

Resource availability

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

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 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 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 coversheet. 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. List the key components that will go to make up your final product. Credit is awarded specifically for showing a professional approach using any relevant 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.

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#, FSharp/OCaml, 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 (see Section [*]).

You should complete a copy of the “Phase 1 Project Selection Status Report” (available at and e-mail it, as a plain text message (not Word, HTML, PDF, PostScript etc.), to your Overseers for their approval.

        [Deadline: Noon on the Monday after the briefing]

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 details.

        [Deadline: Noon on the Friday one week after the briefing]

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.

        [Deadline: Noon on the Friday two weeks after the briefing]

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.