After having evaluated submitted research plans in the course of several years we have tried to collect some of the most common issues that show up. We hope these can be useful for you who submitted the plans, and for future students.
- You describe a programming or design task, without being able to provide motivating for your 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.
- You want to do research on a computer science topic (e.g. AI) but write most of the purpose section about one application of that topic (e.g. healthcare). You have several research references within the application domain (e.g. how many people have cancer and how much it costs) but the underlying research topic itself (e.g. AI) is not discussed in detail and you don't say how you want to contribute to that. To solve this problem, identify and introduce the underlying topic first, clarify your contribution to this topic, and provide relevant references about this topic, and only then use the application area as an example to describe the topic.
- You focus too much on your own results, and fail to put these in the context of other researchers’ contributions–i.e. state of of the art . In this way you fail to show the relevance of your own research for others, and what contribution you make to the research field beyond state of the art.
- You fail to focus and go in depth, and stay at a very generic level. This kind of generic discussion is a sign that you have not read the literature and have a limited understanding of the problem area. 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.
- You are too ambitious and plan a research project 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.
- You use 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.
- You plan 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). Your plan should describe one research project.
- You formulate 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-based" 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.
- You overuse the concept of “case study”: Case studies need real-world cases (e.g. studying the participants of a course, studying an organization going through a change) 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.” Read about challenges related to recruiting users in research, and see which challenges might be relevant for your project.
- 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.