Thicket data repository for the EEG
anil.recoil.org
1{
2 "id": "https://mort.io/blog/part-ii-projects/",
3 "title": "Part II Projects",
4 "link": "https://mort.io/blog/part-ii-projects/",
5 "updated": "2024-09-20T00:00:00",
6 "published": "2024-09-20T00:00:00",
7 "summary": "<p>Undergraduate final-year (\u201cPart II\u201d) project supervision goes in fits and\nstarts. After a couple of years of having almost no interest, this year I\u2019ve had\nseveral enquiries and it seems I might end supervising 3\u20134 projects. So\nherewith a record of the things I\u2019ve found myself repeating!</p>\n<h2><a href=\"https://mort.io/blog/part-ii-projects/#project-structure\">Project structure</a></h2>\n<p>The key thing for the structure of the project is to make sure that there is a\ncore piece that is (essentially) guaranteed to be deliverable. This is the piece\nthat you know you can do, and once done and written up, you know you can get an\nadequate (if not great) mark. Ensuring this takes the risk out of the project.</p>\n<p>On top of this core piece, it\u2019s then usually sensible to build \u201ca few\u201d (2? 3?\n4?) extensions which will make the project spicy if done well. You may wish to\nphrase these extensions as \u201cfor example, extensions might include\u2026\u201d or words\nto that effect, to give some wiggle room in the final dissertation. Getting\nthese done successfully is what should put you in line for a very good mark\nrather than a simply adequate mark.</p>\n<h2><a href=\"https://mort.io/blog/part-ii-projects/#project-framing\">Project framing</a></h2>\n<p>It is also very helpful, particularly if you are aiming for a high mark, to try\nto frame the project in terms of <strong>a research question you will answer</strong> rather\nthan <strong>an artefact you will build</strong>. Often in systems the appropriate way to\nanswer the research questions we pose will be to build an artefact \u2013 but by\nframing it in terms of the question you seek to answer, it makes it easier to\nwrite the dissertation as a piece of research rather than a <a href=\"https://en.wikipedia.org/wiki/Small_matter_of_programming\">small matter of\nprogramming</a>.\nEmpirically, this seems to have an outsize effect on the chances of the\nexaminers thinking the project difficult and marking accordingly.</p>\n<p>It can also be useful to try to be explicit about where your project requires\nyou to go beyond the CST taught material, particularly from Part IA/IB.</p>\n<h2><a href=\"https://mort.io/blog/part-ii-projects/#project-proposal\">Project proposal</a></h2>\n<p>To my mind there are two critical pieces of the proposal around which everything\nelse sits.</p>\n<p>First, the <strong>evaluation plan</strong>: if you can write this well, then you understand\nwhat you\u2019re going to build, and what it means to have done it well (or badly).\nWriting the evaluation plan therefore usually means you have, for the most part,\ngot the rest of the project figured out.</p>\n<p>Second, the <strong>workplan</strong>: this divides time until submission into two week\n(never larger, sometimes smaller) chunks, each of which has attached a <em>calendar\ndate</em> (so there\u2019s no confusion over weeks in term or suchlike) and a\n<em>milestone</em>/<em>deliverable</em> (so that we can immediately tell whether you\u2019ve\ncompleted, or at least are making progress against, that chunk of work in our\nweekly meeting). Don\u2019t forget to take account of any relevant module assessment\ndeadlines in your plan!</p>\n<p>Note that it\u2019s a plan not a contract! You don\u2019t lose marks because you deviate\nfrom the plan\u2013 but if you can\u2019t tell whether you\u2019re ahead or behind, you might\nwell find yourself in a sticky position at the end of Lent term or start of\nEaster term when you find you\u2019ve got module assessments to complete, revision to\nstart, two weeks to go until dissertation submission and still four weeks of\nwork to do on your project\u2026</p>\n<h2><a href=\"https://mort.io/blog/part-ii-projects/#supervision-process\">Supervision process</a></h2>\n<p>I normally supervise projects by scheduling weekly half-hour meetings with each\nstudent. Longer meetings can be arranged on an ad hoc basis as required. The key\npurpose of the meeting is to check progress against the workplan, and to make\nsure that any difficulties and roadblocks are aired and dealt with (whether in\nthe meeting or by scheduling a longer discussion).</p>\n<p>For an example of a reasonable target timeline, consider trying to get\nimplementation completed by the end of Christmas vacation, evaluation completed\nby the division of Lent Term, and the dissertation completed by the end of Lent\nTerm. That then gives you flexibility as to whether you do more project work,\nextensions etc., or focus on exam revision, or whatever.</p>\n\n\n<p>Hopefully that\u2019s helpful. At the very least, I can now point potential project\nstudents at it, so it\u2019s helpful for me :) Some of the above may also be relevant\nwriting research proposals (Part III / MPhil projects, even Ph.D.s) but that\u2019s a\ntopic for another day.</p>",
8 "content": "<p>Undergraduate final-year (\u201cPart II\u201d) project supervision goes in fits and\nstarts. After a couple of years of having almost no interest, this year I\u2019ve had\nseveral enquiries and it seems I might end supervising 3\u20134 projects. So\nherewith a record of the things I\u2019ve found myself repeating!</p>\n<h2><a href=\"https://mort.io/blog/part-ii-projects/#project-structure\">Project structure</a></h2>\n<p>The key thing for the structure of the project is to make sure that there is a\ncore piece that is (essentially) guaranteed to be deliverable. This is the piece\nthat you know you can do, and once done and written up, you know you can get an\nadequate (if not great) mark. Ensuring this takes the risk out of the project.</p>\n<p>On top of this core piece, it\u2019s then usually sensible to build \u201ca few\u201d (2? 3?\n4?) extensions which will make the project spicy if done well. You may wish to\nphrase these extensions as \u201cfor example, extensions might include\u2026\u201d or words\nto that effect, to give some wiggle room in the final dissertation. Getting\nthese done successfully is what should put you in line for a very good mark\nrather than a simply adequate mark.</p>\n<h2><a href=\"https://mort.io/blog/part-ii-projects/#project-framing\">Project framing</a></h2>\n<p>It is also very helpful, particularly if you are aiming for a high mark, to try\nto frame the project in terms of <strong>a research question you will answer</strong> rather\nthan <strong>an artefact you will build</strong>. Often in systems the appropriate way to\nanswer the research questions we pose will be to build an artefact \u2013 but by\nframing it in terms of the question you seek to answer, it makes it easier to\nwrite the dissertation as a piece of research rather than a <a href=\"https://en.wikipedia.org/wiki/Small_matter_of_programming\">small matter of\nprogramming</a>.\nEmpirically, this seems to have an outsize effect on the chances of the\nexaminers thinking the project difficult and marking accordingly.</p>\n<p>It can also be useful to try to be explicit about where your project requires\nyou to go beyond the CST taught material, particularly from Part IA/IB.</p>\n<h2><a href=\"https://mort.io/blog/part-ii-projects/#project-proposal\">Project proposal</a></h2>\n<p>To my mind there are two critical pieces of the proposal around which everything\nelse sits.</p>\n<p>First, the <strong>evaluation plan</strong>: if you can write this well, then you understand\nwhat you\u2019re going to build, and what it means to have done it well (or badly).\nWriting the evaluation plan therefore usually means you have, for the most part,\ngot the rest of the project figured out.</p>\n<p>Second, the <strong>workplan</strong>: this divides time until submission into two week\n(never larger, sometimes smaller) chunks, each of which has attached a <em>calendar\ndate</em> (so there\u2019s no confusion over weeks in term or suchlike) and a\n<em>milestone</em>/<em>deliverable</em> (so that we can immediately tell whether you\u2019ve\ncompleted, or at least are making progress against, that chunk of work in our\nweekly meeting). Don\u2019t forget to take account of any relevant module assessment\ndeadlines in your plan!</p>\n<p>Note that it\u2019s a plan not a contract! You don\u2019t lose marks because you deviate\nfrom the plan\u2013 but if you can\u2019t tell whether you\u2019re ahead or behind, you might\nwell find yourself in a sticky position at the end of Lent term or start of\nEaster term when you find you\u2019ve got module assessments to complete, revision to\nstart, two weeks to go until dissertation submission and still four weeks of\nwork to do on your project\u2026</p>\n<h2><a href=\"https://mort.io/blog/part-ii-projects/#supervision-process\">Supervision process</a></h2>\n<p>I normally supervise projects by scheduling weekly half-hour meetings with each\nstudent. Longer meetings can be arranged on an ad hoc basis as required. The key\npurpose of the meeting is to check progress against the workplan, and to make\nsure that any difficulties and roadblocks are aired and dealt with (whether in\nthe meeting or by scheduling a longer discussion).</p>\n<p>For an example of a reasonable target timeline, consider trying to get\nimplementation completed by the end of Christmas vacation, evaluation completed\nby the division of Lent Term, and the dissertation completed by the end of Lent\nTerm. That then gives you flexibility as to whether you do more project work,\nextensions etc., or focus on exam revision, or whatever.</p>\n\n\n<p>Hopefully that\u2019s helpful. At the very least, I can now point potential project\nstudents at it, so it\u2019s helpful for me :) Some of the above may also be relevant\nwriting research proposals (Part III / MPhil projects, even Ph.D.s) but that\u2019s a\ntopic for another day.</p>",
9 "content_type": "html",
10 "author": {
11 "name": "Unknown",
12 "email": null,
13 "uri": null
14 },
15 "categories": [],
16 "rights": null,
17 "source": "https://mort.io/atom.xml"
18}