Common issues with the research plans in TDT39

After having evaluated the submitted research plans I have tried to collect some of the most common issues that show up. I hope these can be useful for you who submitted the plans, and for future students.

  • The candidate describes a programming or design task, without being able to provide motivating research questions, and without being able to relate to existing theory and literature in any particular research field. If you are planning to do a pure programming or design task for your project and thesis, you should not take this course because you will get a low grade.
  • The candidate wants to do research on a computer science topic (e.g. very large databases) but writes most of the purpose section about one application of that topic (e.g. online social networks). Numerous research references are provided for the application domain (e.g. numbers of social network users in different countries) but the underlying research topic itself (e.g. large scale databases) is not discussed in detail. To solve this problem, identify and introduce the underlying topic first, provide references to this topic, and only then use the application area as an example to describe the topic.
  • The candidate focuses too much on own results, and fails to put these in the context of other researchers’ contributions–i.e. state of of the art . In this way the candidate fails to show the relevance of own research for others, and what contribution he/she makes to the research field beyond state of the art.
  • The candidate fails to focus, and stays at a very generic level. This kind of generic discussion is a sign that the candidate has not read the literature and has a limited understanding of the problem. It helps to read some core analytical and theoretical papers related to the problem. Your supervisor should have a list of such papers to start with.
  • The candidate is too ambitious and plans research that can only be done in a large research team and not in a thesis project. E.g. any realistic user recruitment work will take some weeks to accomplish, including applications to NSD, REK etc. The same does the actual writing of 50+ pages of text that will be your final report. It helps if you try to become specific about what you will do in a step by step manner. It helps to double-check your ambition level with your supervisor.
  • The candidate uses a totally different methodological framework than the one we teach in the course. It is not a negative thing per se to use other frameworks that are well-documented (e.g. design science). But you have to relate it to what we teach in the course, and to the concepts we use in the course such as research strategy, data generation methods, conceptual framework etc.
  • The candidate plans for multiple strategies, which is related to being too ambitious–see above. It is almost impossible to run a case study and an experiment and a design within a master’s thesis. Cut down to maximum one strategy for your autumn project (e.g. a literature survey) and maximum one strategy for your thesis (e.g. an experiment).
  • The candidate formulates research questions that can be answered with yes/no. These are not interesting at all because 1) they are often made because you already have decided the answer is yes, but you want some research backing, and 2) you can often find the answer by running a Google query, you don’t need to spend one year of your life answering them (example research question: “is there any open source software for calculating X?”). Instead try to formulate research questions that use “how”, “why” and “what”.
  • The purpose chapter does not have references to scientific literature, and is based on news and magazine articles and consultancy literature. This is good if you want to build an app to sell. But not for empirical research. Find some good research papers and read them. Your supervisor should have some references to start with.
  • The candidate overuses the concept of “case study”: Case studies need real-world cases (e.g. studying the participants of a course, studying an organization) and in-depth analysis of that case using multiple sources of data. Please read the case study chapter in the book better, and make sure you have a specific case before you say you will do a case study. Evaluating a prototype you just developed with five users is not a case study!
  • It is not useful to list a number of participants without having a plan for how you think to recruit them. You are not writing a wish list, you are writing a plan that needs to be realistic. If you say you will recruit 50 students you need to write how. E.g. “I will put an advertisement in the student magazine and will promise to buy pizza for the participants.”
  • It is not enough to write that the users will be anonymous. They cannot possibly be anonymous for you as the researcher. You need to describe who will have contact with the users, what data you will collect, how you will process the data, what you will do with data, how you will recruit the users, who your population and samples are, and how you will get consent. See e.g. NSD web pages. Talk to your supervisor.
  • It is not enough to say: “there is not much related work”. Writing this sentence means you have not searched well enough. One million research articles are published each year. If you claim you could not find one related to your research question, then you either 1) have not understood the problem you want to solve, or 2) have not looked properly for literature, or 3) you are right. In the last case, you need to convince the reader that your research question is really worth pursuing. In any case, document what you searched for and how. E.g. write down where you searched for literature, what search queries you used, etc. so that the reader can verify your claim.