How to choose a good BSc or MSc project

Media_httpfarm3static_zggtj

Planning stuff...

A critical part of the success or failure of any thesis project is the initial choice of what to work on. This is a surprisingly difficult part of any project, in some ways the most difficult part, and it's something that we see students struggle with year on year. Nothing is so disappointing than marking a project and coming to the realisation that with some better decisions at the beginning of the year a failing project could have passed. This is a trap to avoid, and by avoiding it you will not only improve your chances of passing your project, you will greatly improve your chances of getting a first. In fact, projects are pretty straight forward to do well in, so long as you fully understand what is expected of you. This post takes you through what you need to focus on and avoid right at the start of your project journey.

 

Do something you are interested in

A final year or MSc project is a six month, single person project and in most Universities students will have to study several other modules concurrently. This is a long time to be working on a single piece of coursework, so it is important to choose a project which will hold your attention for that length of time. Moreover, you will be working on other things at the same time, so ideally you need to choose a project that is compelling enough that you want to work on it, in preference to doing other things. 

 

How to know what you are interested in

This might seem like a rather unnecessary topic -- what is "interesting" is very personal and individual. However, estimating what you might find interesting in several months time, when you are under pressure to meet deadlines is not easy. One trick to weight the odds in your favour is to choose a project which you do not, at the start of the project, entirely know how to complete. Like Einstein said: "If we knew what we were doing, it wouldn't be called research". Obviously, don't choose something that is completely outside your area of expertise. If you have spent two years studying bioinformatics then don't suddenly decide to try a dissertation in ceramics, but equally, if you know exactly how to complete every part of the work that you will need to do for your project then your idea is not "big" enough in scope. This point, really is the key to finding a project and much of the rest of this post expands upon it: a thesis or dissertation is not simply a long piece of coursework, it is an individual, self-contained work which should stand on its own. Think of it as a sort of "first job". When you leave University and apply for further study or a job, then the results of your project will be part of the professional portfolio of work you can use to convince a future employer to take you on.

 

Project difficulty: a difficult project is an easy project

By far and away the biggest mistake that we regularly see from students writing project proposals is choosing a project which is far, far too easy. The train of thought seems to go ... projects are difficult, I want to make the project easier, therefore, I will choose a simple idea to work on. The classic examples of this in Computer Science are "a website with a database" -- usually for a family member or friend who runs a small business -- or occasionally a website or database on their own. What's wrong with this? Well... so many things:

  1. By the time a student has reached the final year of their degree, they will likely already have written several databases, websites and at least a couple of websites-with-a-database. Therefore, the project is something that the student has already been awarded credit for. This means that the student will not be demonstrating that they can learn independently, and go beyond what has been taught in lectures, which is one of the main purposes of the project.
  2. Because the proposal is about the same size and quality as an individual module coursework, it is not large enough in scope to gain many marks.
  3. An individual website, in ASP, PHP, or similar, for an SME is a very old problem for which there exist a large number of "turn-key" solutions -- that is, off the shelf products that can be used to create the product. These include templating systems such as Joomla, cloud-based solutions such as Google Sites, Posterous, Tumblr and so on, wikis, and a number of other technologies. A straightforward website-with-a-database is, therefore, in no way a demonstration of the students ability to work at the cutting edge of their field.
  4. A website-with-a-database is not a problem, it's a solution to a problem. A project proposal should propose an interesting problem, with a suggested strategy for solving that problem during the progress of the project. 

Having said this, I have seen and indeed supervised a number of excellent projects, for which the student implemented some sort of website and some sort of database. So, it's not that websites or databases are inherently bad choices as solutions to the problems posed by a project proposal, but a proposal MUST overcome the four problems outlined above.

The heading for this section said (rather confusingly) that "a difficult project is an easy project". What I mean by this is that the "difficulty" of a project is something that will uppermost in the mind of the staff marking your thesis. A "difficult" project is likely to be looked upon favourably because it will be a bigger step away from what you have already been taught, you will need to be reading more academic literature, you will be showing more independent learning, and so on. These are some of the most important factors in getting a good grade, and far outweigh factors such as finishing every part of your practical work. The up-shot of this is that if you choose a "difficult" project and complete it quite poorly, you are likely to get better marks than a student who chooses an "easy" project and completes all of their practical work. If you did choose to work on a website-with-a-database-for-an-sme then the proposal will be so easy that you will really have to complete every part of the project perfectly just to get a pass. So, choose a small but difficult project.

 

Have a research question

In the last section I said that a project proposal should pose a problem, not a solution to a problem. Ideally, it is best to phrase this as a research question, such as the following:

  • is algorithm X more efficient than algorithm Y?
  • is it possible to implement product Z on the cloud?
  • can feature L be added to programming language P?
  • can theorem T be proven?
  • can algorithm Z be adapted to be used in conditions C?

and so on. There are several advantages to this. One is that this is a standard form of writing in academia, and your project will be marked against academic criteria. Secondly, if the aim of your project is to answer a question then you leave the issue of how to answer that question reasonably open ended. It may be that you have a very clear idea, at the start of the project, what you are going to do. That's fine, but as you progress through the project you may well find literature that enlightens your views on how your question can be answered. Thirdly, your answer to the question may not be what you expect. That's fine, it's OK to find out that actually, your algorithm isn't as efficient as you thought, or the theorem cannot be proved, so long as you give solid, convincing evidence for your answer. 

 

Do something practical

If you are working in the sciences, it really is important that you do something practical as part of your work. For these purposes "practical" can mean experimental work or mathematical work -- it's OK to prove a theorem, for example, as the main part of the "practical" content of your work. What you should avoid though, is vague, nebulous, thought-pieces, which have no clear results and cannot be evaluated. Avoid anything with a title like "an investigation into X" or "a dissertation on Y". These sorts of writing are well accepted in the humanities, but for a scientific piece of work you need to propose a question and find some answer to it. Equally, a literature review is not really a project in itself, it needs some research question and evaluation with it to form a complete project.

 

Focus on evaluation from the start

Evaluating your work will likely be the last practical work you complete before finishing your dissertation writing. However, you should know from the start of your project how you plan to do this. As with unit-testing, it is best to have designed you evaluation in as much detail as possible before you start you practical work. That way, you know that what you are aiming for is something that can be evaluated in the manner in which you have planned. Remember, the purpose here is to determine whether your project has answered your original research question.

In general, your evaluation will fall into one of the following categories:

  • Performance evaluation: either testing the speed, memory footprint, scalability, load-balancing, or other aspect of the performance of a program or system. This is often the easiest form of evaluation -- it can be performed by a program and so automated, the results can be analysed and presented using a statistics and you will not be reliant on users. Work in programming languages, networking, operating systems, databases, and hardware tend to suit this sort of evaluation well.
  • User-acceptance testing and usability: if your project involves creating a product for end-users to test, especially if you have an industrial client, then it is essential that you perform some sort of user acceptance testing. Good options for this are the talk-aloud protocol or semi-structured interviews. NEVER, EVER, EVER think that a "heuristic" evaluation is sufficient. Heuristic methods only catch basic errors, they tell you nothing about how your users will actually experience your product.
  • Formal or semi-formal methods: such as proving a theorem, using a model checker (such as SPIN), using a formal method such as B or Z to show that your work is free of particular types of errors.

 

Take (academic) advantage of your supervisor

Every student will have at least one supervisor, who will usually be actively involved in research, consultancy or something similar. This sort of work can provide a wealth of good ideas for projects and has several advantages. Firstly, your supervisor will propose projects that have the right scope and difficulty for your degree course. Secondly, if your supervisor has an interest in what you are doing, they will have a vested interest in seeing you succeed and of course will have a lot of relevant expertise with which they can advise you. Lastly, it is likely that your work will be used by other members of a research group which will give you access to feedback on what you have done.

Be flexible (within reason)

Remember that a project is a marathon, not a sprint. It may well be that you get part way along the journey and find out that what you had first set out to do is actually impossible, or impossible within the scope of the project. Or it may be that you find some other way of answering your research question, or you uncover some literature which shows that the question can actually be answered very simply. In this case, you should speak with your supervisor and find a way to reword or even completely change your original research question. This is quite a reasonable thing to do and happens often in "real" research projects, so you should not be worried about it. Your final project does not have to match the original proposal exactly, but you should be able to explain why the changes you made were necessary.

 

Summary

  • DO choose a project that will hold your interest for the duration of the project.
  • DO NOT choose a project that is the same size or scope as a coursework, or something that is very similar to work you have been set in a module.
  • DO propose a "difficult" problem -- it is easier to pass a challenging project than an "easy" one!
  • DO propose a research question, and an idea for solving it.
  • DO propose a project with some sort of practical or mathematical component, DO NOT set out to write a commentary on a topic.
  • DO have a very clear plan for how you will evaluate your project. This should clearly state how you will determine whether or not you have answered your research question.
  • DO NOT evaluate an end-user product with only heuristic methods.
  • DO test end-user products with real users.
  • DO take advantage of the expertise of your project supervisor and their research interests.
  • DO be flexible, if you find that your original research question cannot be answered, or if you find that a more "interesting" research question emerges during your project.
Tagged choosing_a_project complexity difficulty evaluation planning preparation research_question

How to pass your final year thesis project

I've been thinking for a while that it would be good to distill some of the advice that colleagues and I give to students doing final year thesis project, so here it is -- enjoy!

Think of yourself as an academic.

Whatever you want to do when you leave University, your work will be written for academics and marked by them. A thesis project is like a small research project and to get the best marks available you should run your project with that in mind. So, you need to perform a thorough literature survey, follow a sound methodology, critically analyse your results and so on.

Have a hypothesis (or a thesis statement or a research question).

A lot of students approach their projects by saying "I want to do this", like "I want to invent a Foo, written in VB". This is not the best way to get good marks. Your project needs to have some sort of clear purpose and in the academic world it's best to state that purpose as a hypothesis, thesis statement or research question. These three are really just different ways of stating the same thing and which you choose is just a matter of taste. So, if your project is a study on the ratio of smokers which develop cancer (e.g. "I want to do some statistical analysis on smoking") then you might phrase that in one of these ways:

  • Smoking is correlated with cancer -- hypothesis
  • Smoking is correlated with cancer -- thesis statement
  • Is smoking correlated with cancer? -- research question

Or, perhaps you want to design a new GUI widget to replace list boxes:

  • Users will find WidgetFoo easier to use than ListBoxes -- hypothesis
  • Users will find WidgetFoo easier to use than ListBoxes -- thesis statement
  • Is WidgetFoo easier to use than a ListBox? -- research question

Part of the point of phrasing your work like this is that it should change the way you think about the work. You now have a very clear goal to reach -- to prove your hypothesis / thesis statement or to answer your research question. Everything you do in your project should now be directed towards this one goal.

Also, you have reduced your risk of failure. What if WidgetFoo turns out to be rubbish? Well, then you have still answered the research question or disproved the hypothesis -- you've got a result. In your write-up you can probably say a lot about why WidgetFoo wasn't as good as you thought, how you achieved your results and how other researchers can use your work to invent even better widgets.

Produce something useful to others.

So, you've got a hypothesis to answer. Great. But your teachers will still want to be convinced that the hypothesis you've chosen is worth six months of your time and lots of hours of their time. How do you know if your work is useful? Firstly, make sure you've read the relevant literature. Use Google, go to the library, talk to potential users. There should be a group of people in the world who have a clear reason to be interested in what you're doing. That might be a section of the research community, a user group, a company, whoever -- but there must be someone who wants your hypothesis validated or disproved. You should convince whoever's marking your thesis that this group of people exists by explaining in your thesis what the current literature says about the area you are working in and how your work contributes to this area.

Do something (a bit) novel.

You're not expected to win a Nobel Prize on the back of your undergraduate work. However, there's no point in doing something that everyone has done a million times before. The worst example of this in Computer Science is a project which is basically "I'm going to write a website with a database". Usually the website is for a friend or relative and the database keeps track of users. There's nothing wrong with that if there's some real novelty in it (e.g. you've just invented a new sort of database and this is a demonstrator for it). But often this is something that most first years could complete for a coursework (so, it isn't stretching you) there are simple, free tools that can do the job for you (it's not novel) and the user is bogus (noone's interested in it). Choose wisely!
 
Have clear success / failure criteria.

This should be taken care of when you write your hypothesis (or thesis statement or research question). However, it's important to know what will constitute a "successful" project for you. What results do you want to end up with? Once you know that, you can choose the appropriate methods to use in your work (e.g. will you be running a focus group? Writing a questionnaire? Writing some programs -- and testing them somehow?). You can also think about reducing the risks in your project. What if you don't finish part of your work on time? Is there some catch-up time in your schedule? What if early tests go badly? Is there time to repeat them?

Don't change the world.

Don't choose a project which is just far too big. If you're going to invent a new computer, writing an OS from scratch and a windowing environment for it is not a one-person, six-month, part-time job. Keep it small and give yourself some scope for extending the project if it goes better than you thought.

Even if you've chosen something small with a clear hypothesis, once you've written out a project schedule it will still feel like far too much to do. You will feel overwhelmed. The trick to reducing your fear early on (and making sure you work to schedule) is to break down your work into small tasks. Each task should have it's own goal and deliverables with it's own success criteria and a deadline. So, if your hypothesis is "WidgetFoo is easier to use than ListBoxes", your sub-goals might be:

  • Produce a literature survey on list widgets.
  • Write comprehensive unit tests for WidgetFoo in the Gtk widget set.
  • Implement a WidgetFoo in the Gtk widget set.
  • Debug (goal is to pass all unit tests).
  • Devise usability experiments (deliverable: methodology document).
  • Write application software for testing in the experiments.
  • Perform experiments.
  • Analyse data.
  • Write-up thesis.

Note that these tasks are dependent on one another. WidgetFoo cannot be written before you know how to test it. The experiments cannot be run until you have designed them and decided how to analyse the data they will produce.

Your new list will make life a lot easier, but you will probably still feel that it's too much to handle. To feel better about your work and motivate yourself, it's a good idea to take each of your sub-goals and write out the next physical action you need to perform to carry out that task. So, for the literature survey the next action might be "Google for 'list widget'". For the unit testing your next action might be "Find documentation about the UnitFoo testing framework". And so on. Most people find action lists much more motivating than task lists. Scroll down to see more stuff on productivity and where to keep your lists!

Choose a project that will maintain your interest.

Six months is a long time. If you choose a boring project (maybe you think it'll be "easy") then you'll quickly lose interest, get bored, stop working and possibly fail. In some ways, it's good to choose a project with a lot of scope (so you can change direction a bit and still address your hypothesis) in an active area of research (so there's lots of work to build on). On the other hand, some people would find that sort of project unfocused and confusing.

When you plan your project, think hard about what motivates you. Is it reaching towards a really interesting goal, or the fear of failing really badly? Either way (or both) you need to keep that motivation in mind whenever you're working. So, choose something interesting to do, give yourself at least a little scope for changing the details of the project over the year and keep in mind why you want to succeed (or not fail!).

Don't be too dependent on clients.

If you have a client to work for, especially one from industry, be careful about how you plan your project. If you are expecting resources from your client what will you do if they don't turn up on time? If you want the client to test your work, what do you do if they get a major order in when you're ready to test and noone has the time to help you out? What if the client goes out of business? What if you have to sign a non-disclosure agreement -- can the University still mark your work?

Having a "real" industrial client can be a big bonus. For one thing it's very easy to say that someone is really interested in what you're doing for the project. However, you need to make sure that if the client pulls out or doesn't cooperate you'll still have a viable project. Plan well and you won't have any problems.
 
Understand that research is not reading and a thesis is not a report.

Most undergraduates (at least in Computer Science) seem to be pretty confused about what research really is. It certainly isn'tabout using Google or reading in the library. Research means adding something new to the body of knowledge on a particular subject. This is why it's so important to know what work has already been done (so you know your work is novel), to have a clear hypothesis (so you know what new understanding you're adding) and to write up your work well (so other researchers can use it).

Also, understand the place of your thesis. You are not writing a report which tells people what you did. You are writing a thesiswhich tells people about the research you have done. This can be structured in whatever sensible way you prefer, but it needs to have the following parts:

  • An introduction. What's your hypothesis? Why is your work interesting? What are your trying to achieve?
  • A literature survey. What have other people done? What new knowledge will your work add? What is the current state of the art missing and how are you going to address that?
  • Your methodology. How did you go about validating / disproving your hypothesis? Why is your method sound? Why should anyone trust your results?
  • Your results. What did you do? How?
  • Your analysis of your results. What do your results mean? Why are they interesting? Did you validate your hypothesis or disprove it?
  • Conclusions. What did your work contribute and how could it be continued by others?


Eat well, sleep well, get some exercise and take a day off every week.

Basically, look after yourself. To work productively you need to be in good physical and mental condition. If you feel ill or your not coping well with life, slow down a bit and take a break. Don't eat junk food all the time or you'll feel sleepy and miserable. Cut down on caffeine and alcohol or you'll get stressed and sleep badly. Sleep a sensible number of hours every night -- consistency is important. Get some exercise because you need endorphins to keep you happy and some oxygen getting to your brain. Omega-3 and the sorts of minerals that aren't found in hot dogs will keep your brain working sensibly.

Most of all, take a whole day off University work every single week. It doesn't matter what you do with that day (have fun, earn money, write a novel, whatever) but working every day will limit your creativity massively. Most very creative (and productive) people find that their best ideas come after a day off. This gives your mind a chance to consolidate all the material you have learned, synthesise it and solve some of the problems you've been considering. In fact, to revise for an exam or solve an interesting problem, it's a good idea to spend a few days working really hard at reading everything you need to know and taking notes, then take a day off directly before the exam or the day before you're going to write the solution to your problem. This will give you the best chance to properly understand everything you're working and be creative about it.

Be productive but don't spend time on productivity.

You need to organise yourself well, which is a difficult problem in itself. However, if you spend even five per cent of your time on productivity management (e.g. using Microsoft Project!) then that is far, far too much and a massive waste of your most important resource -- your time.

Good productivity strategies are effortless, effective and fun to use -- and take almost no time at all. I can recommend David Allen's Getting Things Done strategy and RememberTheMilk for managing lists of action items.

One thing you can do to really give yourself a head-start in the workplace is to estimate how much time it'll take you to do every single task in your project. You'll start out finding that your estimates are stupidly far out, but as your project progresses you'll get better and better at correctly estimating your tasks. Joel Spolsky has a nice essay on how to do this simply, which you can use with RememberTheMilk

 

Tagged dissertation hypothesis novelty productivity research_question thesis
​