Project Setting & Allocation: 
Information for Staff

 

Project suggestions submission by		Spr/3/Mon
Vetting starts		Spr/3/Mon
Vetting finishes (supervisor-defined projects)		Spr/6/Fri
Vetting finishes (student-defined projects)		Spr/10/Fri
On-line project selection begins		Spr/7/Mon
On-line project selection ends	(first iteration)	Spr/9/Fri
On-line project selection ends	(second and final iteration)	Spr/10/Fri

1. The Project Coordinator (PC) issues a call for proposals

(mid-Dec).
2. PC distributes a list of moderators for all projects.

(Spr/2/Mon)
3. Supervisors submit the URL of their projects to both PC and the moderator assigned, and inform PC about reduced loading. Moderating process begins.

(Deadline: Spr/3/Mon)
4. Supervisors receive feedback directly from moderators, and inform them when projects are updated accordingly. Nowhere is PC involved at this stage of project revision. This action may require more than one iteration.
5. Moderators inform PC when a member of staff's list of projects has been given a green light.

(Deadline: Spr/6/Fri)
6. PC compiles an index Web page containing pointers to all projects' Web pages, and makes it available to students and staff. Selection of projects begins.

(Deadline: Spr/7/Mon)
7. Students make their choices, preferably after having discussed projects with the supervisors.<-

(Deadline: Spr/8/Fri)
8. The database is closed for students, and staff are invited to finalize their selections.

(Spr/8/Sat - Spr/9/Wed)
9. The database is closed for everyone. All allocations where the student has been allocated one of her/his choices, are final. They are published, those students and projects are removed from the database and the current state of staff loading updated.

(Deadline: Spr/10/Mon)
10. Steps 7-9 are repeated with the remaining students and unallocated projects.

(Spr/10/Fri).
11. All remaining students are allocated projects within the existing constraints on loading in one of the following ways:
• after direct negotiation, supervisor and student agree upon a project and they both notify PC
• an unallocated project is assigned randomly otherwise.

1. Please create your project list in HTML format. Put it in your personal web space, and email the URL to me and your moderator. I shall then create an index, in the Department's ``locally accessible'' area, with links to everyone's suggestions. I will not accept submissions in any other format.

You might wish to copy my 2000/01 list, substituting your own project definitions for mine.
2. Give each project a code of the form XXX/n, where XXX is your acronym (as in the Students' Handbook, e.g. AJF) and n is a number which identifies the project. Note the `/'.
3. Each suggestion should be at least 100 words in length and must include a few references to provide background reading for interested students.
4. Describe precisely what is required. Open-ended projects are deprecated.
5. Although it's all right to include a few research-level projects to give free rein to first-class students, be very careful that you make it clear in your project description that the project is ``difficult''. Most students will not obtain a first-class degree, and it is unreasonable to expect most students to be capable of completing research-level projects. Most of your projects should be characterizable as ``90% perspiration, 10% inspiration''.
6. It must always be possible for a not-so-good student to get a not-so-good mark for his/her project: projects must not have a binary outcome!
7. Describe any special methods that will be used to meet the objectives. These might include particular programming languages with which the students might not already be familiar. It might also be worth indicating to the student if there is anything else remarkable about the project; for instance it might place more than normal demands on their mathematical abilities.
8. State the category of student for which the project is intended. Distinguish among the following:
• CS (which is taken to include also CS/Maths, MEng PR3, MMath PR3)
• MEng PR4
• MMath PR4
• ITBML
• MSc IP
You might like to distinguish between single-subject CS and the joint Maths courses, although this is not essential.

Note that the Advanced MSc (SCSE, SSE, SWE) will also be covered this year: for advise on these courses, please contact JDM. MRes BI projects are excluded: project selection for this course is handled by JC.

9. This year the ITBML/IP students comprise a large proportion of the total number requiring projects. Therefore it is desirable that members of staff submit projects that are suitable for these two groups. I would particularly urge members of staff who think of themselves as ``CS people'' to submit a few ITBML projects, and vice versa.
10. ITBML projects should ideally contain elements of all of ``IT'', ``BM'' and ``L''. Please exploit opportunities to encompass all three aspects wherever possible. For example, in a project which is essentially ``IT+BM'', you might provide some foreign-language references.
11. Externally supervised projects with local organizations are particularly popular with the IP students and are also likely to attract ITBML students. If you have contacts who can suggest and supervise such projects, please ask them to submit a proposal through you, or prepare a proposal on their behalf. The proposal should give details of the industrial supervisor (name, position in the organization, whether he/she has performed this role before). It is important that the external organization is made aware that the final project must have significant academic content and that the student is not just a source of free effort who can be used to undertake a routine task. In the past it has usually proved most effective if the project suggestion is formulated by an academic from within the Department rather than by the contact in the sponsoring organisation. All students undertaking such projects must formally continue to be supervised by a member of the Department; in effect this corresponds to about a third of a project load and involves monitoring the progress of the work.
12. It is the Department's policy that projects are not ``split'': no project is undertaken by more than one student at a time, whether under the same supervisor or under different supervisors. Also, a project undertaken in a given year should not normally be repeated unless (a) substantial changes have been made to the specification, and (b) a reasonable interval has elapsed since the project was first undertaken. (Projects which are offered but not taken up may of course be offered unchanged in subsequent years.) These rules are necessary to guard against plagiarism and collusion.
13. Your project submissions will be vetted before they are made available to the students.


14. Some students prefer to define their own projects. In my experience, if a student can see as far as the end of a project, as he must in order to be sure in his own mind that it is ``doable'', then the project is too easy. Others might disagree.

You, as supervisor, must take responsibility for the academic quality of a student-defined project. If a student approaches you with a student-defined project, you should put it in your HTML file along with your other (supervisor-defined) projects (see (1) above), and give it a code in the standard format (see (2) above). It will then be vetted in the normal way. Once approved, you may specify the student as your first choice for that project, and he may likewise choose the project. The project will then be allocated to that student.
15. Special provisions apply to MEng projects. See the Guidelines published by the Department Teaching Committee.

 

I shall refer to the members of the Vetting Panel as moderators because ``vet'' sounds silly.

The task of a moderator is similar to that of both a referee of a journal paper and an editor of a journal. As referee, the moderator has to ensure that individual project suggestions are clear and unambiguous, and that they adhere to the Guidelines for Setting Projects given above. As an editor, the moderator has to satisfy himself that projects are not too dissimilar in difficulty; although he should remember that students come in all shapes and sizes, and it is important that the set of projects include a few easier-than-average projects and a few harder-than-average ones.

The Chairman of the Board of Studies writes: ``ITBML projects should ideally be IT+BM+L. But in a careless moment a lecturer might suggest a BM project with no IT and no L even where there are opportunities for including them. Similarly with other permutations. Project vetters are asked to pick out such cases and to request the full IT+BM+L combination wherever possible.''

The procedure for vetting is as follows. Each moderator moderates all of the projects of several members of staff. There are ~35 potential project setters and six moderators. I shall email you with the names of the members of staff whose projects you are asked to moderate. Please do so by the date given under Timetable above, referring also to other people's projects in order to fulfil your editorial role. I shall try to distribute projects to moderators equitably. The current list of projects is available on-line: visit the Projects Web Page and follow the links to ``Project Allocation Database'' then ``Project specifications''.

If you, a moderator, are not entirely satisfied with a project suggestion of a particular member of staff, please talk to him or her and try to agree a compromise. If you reach a compromise, ask the author to make the appropriate changes to the project specification. If you cannot agree, the project will not be made available to students.

When you have completed the moderating process for all the projects I have asked you to moderate, email me to tell me so.