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