University of York, Department of Computer Science

How to Do a Project



1.   Introduction

I have prepared these notes to help undergraduate and MSc IP students in the Department of Computer Science to make the most of the experience of undertaking project work, and to bring their project work to a successful conclusion. In particular, I have tried to distil and to describe those aspects of the successful project which will enable you, the student, not only to get a good mark for your completed work, but also to learn a lot during the process of completing it. These are the two principal aims of the final-year or MSc IP project.

In order to shorten this essay, I'll assume that you are a final-year Computer Science student. Most of the following applies, mutatis mutandis, to all other undergraduate and MSc IP students. Significant exceptions are noted.

These notes are personal, and represent my own view of what constitutes good practice. Other supervisors might have different views, or different notions of relative priorities.

2.   Learning

Although the hard-nosed might disagree, placing more emphasis on securing a good mark, it is my own opinion that learning is the main purpose of project work. Even if you obtain only a low third-class mark in your project, I would say that the project has succeeded if the sum of your knowledge of Computer Science at the end of the project is significantly greater than it was at the beginning.

I think, incidentally, that this requirement explains why student-defined projects are so difficult to arrange. A good project entails a large amount of reading, of learning new techniques, approaches, programming languages, and so on. If you, the student, can see at the proposal stage exactly what is required - as you must, more-or-less, in order to write a successful project proposal - then the learning element of the project is almost bound to be inadequate. For example, a student who is interested in computer graphics might propose a project along the lines: ``Write a program to create this-or-that animation effect, using the such-and-such method of 3-D rendering''. The student might think, at the proposal stage, that the particular animation effect and rendering method are subjects in which he has been interested for a long time, and which he wants to explore. But this very interest almost guarantees that the amount learned during the project work will be small. In a nutshell: if, at the start of the project, you can see your way right through to the end, then it's almost certainly too easy.

You ought to expect the learning process to continue throughout the whole project period. In the initial stages you can expect to spend a lot of time in the library reading text-books and papers in academic journals, and a lot of time on-line exploring resources on the World-Wide Web. Later on, you can expect to apply the knowledge you have learned. This, too, is a kind of learning; in fact a deeper, more rewarding and more persistent kind than book-learning.

3.   Make the most of your supervisor

Throughout the whole project period, your supervisor will suggest avenues for you to explore. Make the most of your supervisor's suggestions. Even if you disagree with them, follow them up at least far enough for you to be able to justify your disagreement, both face-to-face and, later, on paper when you write your report.

It has been said that a failure to be supervised is the most common reason why a final-year project fails. Your supervisor wants you to succeed: a failing project reflects badly on the supervisor, just as supervisors often bask in the reflected glory of a first-class project. No-one can force you to accept your supervisor's advice, but you must at least consider it, and be prepared to say why you did not follow it. If your supervisor says that you are not working hard enough, that your planning is sufficiently adrift to put the success of the project at peril, or that you are following a trail which leads nowhere, then you would be well advised to take heed. We, the supervisors, can all recognize the danger signs. Remember also that we were students too, once upon a time, and most of us can still remember clearly what it was like to do a project!

It is a Departmental rule, set out in the Students' Handbook, that students who are carrying out project work must normally meet their supervisor once a week during term time. Project supervisions for MSc IP students continue during the summer vacation.

4.   The structure of project work

There are some supervisors who would say that it is desirable to prepare a project plan which shows, week by week, what you ought to be doing. There are many students who have such a plan, carefully drawn in coloured inks, stuck on the wall above their beds. There are many doctors' waiting-rooms full of students who are suffering from stress because, come the middle of the spring term, the plans they constructed at the beginning of the autumn term do not well reflect the reality of their progress - or lack of it.

I think it is better to adopt a more mature and, I think, realistic approach to project planning. In the first place, all projects are different, and a plan which is suitable for one project is not necessarily applicable to another. Secondly, when you start a project you will not be able to see your way right to the end - if you can, it's too easy - so you will not be able to construct a detailed plan at that stage. You just don't know during the early stages which of the later stages will turn out to be the most time-consuming.

My advice is to divide the project period into three broadly consecutive sub-periods, which I call research, donkey-work and writing-up. By ``broadly consecutive'' I mean that they normally follow one another in that order, but some overlap is to be expected. You should allocate at least one-third of the available time (six weeks for a PR3 project) to writing-up. The remaining two-thirds (twelve weeks) should probably be divided about equally between the research and the donkey-work, but this division is flexible, and in practice the two will overlap.

Throughout your project work, from the very beginning, you should keep a note-book in which you should write your good ideas as you have them and summarize what you are doing. You should also jot down the bibliographic details of papers and books you read, and a summary of their main relevant points. It's easy to forget what you read, or - worse - where you read it, and the keeping of a note-book from the very beginning of your project work will save you much worry and time at the writing-up stage. Instead of a note-book you might prefer, as I do, a series of document wallets containing loose-leaf sheets. This has the advantage that you can rearrange the sheets and put them in order. Whichever method you use, it is essential to keep some form of written record.

4.1.   Research

All project work is meant to begin with a period of reading and research. During this period, your ideas about how you will approach the project work will crystallize, and you will learn the new techniques, background knowledge and perhaps programming languages which you will need to complete the project.

Students are encouraged to research, specify, design, construct, test and evaluate. The research (e.g. a literature review) might feed in to any of the later stages: they are all helped in effectiveness, and given intellectual weight, by research.

Credit will be given for research, and will also be given for specification without design (``my excellent and extensive researches, intelligently pursued, have led me to the following specification as the end-product of my work; there was no time for design, but it would have proceeded along the following lines, using the following methods ...''), or design without construction (``here is my complete design; the reasons why I believe that it would, if implemented, do the job correctly and efficiently are as follows ...''). There should always, of course, be evaluation: but that must be evaluation of such of the previous stages as have been completed.

If a refusal to be supervised is the primary reason for failure, the secondary reason is surely a neglect of the research period of the project. Students often think, quite wrongly, that the aim of the project is to make something (e.g. a compiler or a robot), or to do something (e.g. analyse a family of algorithms). They rush in (where angels fear to tread), and start writing programs (or wiring up circuit boards, or whatever), without having done the preliminary research.

There are several undesirable consequence of this precipitateness. First, the research might indicate that the methods employed in the program are flawed, and the time spent programming consequently wasted. Secondly, programs attempted too early, before you have the necessary background research under your belt, will take you longer to write, because you simply do not know what you are doing. Finally, it is your report which will be marked, not normally your programs, few of which will even appear in the report. Your initial misguided efforts at programming will therefore earn you few marks. Your initial research, on the other hand, will give you the first chapter or two of your report, and will underpin all of the remainder, so it will contribute very significantly to your final mark.

4.2.   Donkey-work

The project proposal will tell you what you are expected to achieve. Your initial research will have shown you how to achieve it. The next step is to apply the knowledge you have gained in order to achieve the objective.

Do not under-estimate the work involved in this stage of the project. A PR3 project takes 360 hours, which is 20 hours per week over two terms, or four hours every day of a normal working week. MScIP projects are essentially full-time during the summer vacation.

It is difficult to be specific about what is involved in this stage, because projects vary greatly. Your supervisor will advise you. It is however important to understand the type of work which will most impress your examiners and secure a high mark.

Although examiners are warned not to expect research-quality work from an undergraduate or MSc IP student, examiners will none the less be impressed by evidence of original thought, new ways of doing something, new approaches to old problems, and so on. For many problems there is a humdrum, obvious solution and a number of original or unusual ones. Prefer the unusual to the commonplace. (Make the most of this freedom: the inclination of many employers is towards the obvious and safe solution.) But be sure that your unusual solution is really applicable to the problem.

Most projects involve an element of comparison of different methods. This is harder than it sounds. You must invent or unearth in the literature sufficient methods to compare. Many students respond to this requirement by setting up a number of straw men, which they proceed to demolish. This is not wise. Your alternatives must be realistic.

4.3.   Writing-up

This is so vitally important that it is the subject of a separate essay.


Written by Dr A.J. Fisher/Project co-ordinator: jc@cs.york.ac.uk