In this blog I describe how I cooperate with master and project students that I supervise. I have collected these points based on my own experience supervising more than 50 master and project students. My goal is to get grade A for my students, and it helps to learn from the past! Read this blog before you choose me as your supervisor.
This blog post is under continuous development. Please provide your feedback and suggestions in the comment field below or directly to me. Thanks!
I am happy you are considering to or have selected one of my project proposals for your master/diploma/project. I am looking forward to working with you during the coming months. Here I want to share with you some expectations I have to our collaboration, and tell you a bit about what you can expect from me. This blog is developed through a co-creation and identification of best practices. My goal is that you will get an A at the end! This page includes both high-level topics–such as style of supervision– but also some detailed stuff– like how we organize supervision meetings. Please read all of it!
- My project proposals are all all about research. The end result is a research report. You might develop a technology concept and a prototype, or focus on creating new knowledge and insight. But contribution to knowledge is the main goal.
- I will not give you a specification/script and ask you to implement it. You will use research-based methods to develop the task in a dialog with me. This means there will be a big demand on your self-organization and rigor. But it is also a unique opportunity to learn research methods in practice and to use your creativity to create some useful knowledge or product! I am your supervisor but I will also learn a lot from your work.
- Often, depending on the task, most of the supervision you will get from me will be related to your methods and not to your ideas and concepts. Of course I will provide feedback on your ideas when I can–for instance, I might know what kind of digital concepts will or will not work with a specific user group. But mostly I will give you method-related feedback of the type: “be clear about your data collection methods”, “document your literature search process”, “define your user group clearly” etc.
- You will hear a lot about the terms research question and research problem. I will push you all the time to define your research problem and your research questions. Sometimes you will feel you have had enough. But I will not give up. I want us to avoid working on tasks that do not address important research problems.
- I will also ask you to read a lot of research literature, and summarize. We are not going to make a product or create knowledge that someone else has already made. We are not going to do anything without knowing (almost) everything there is to know about that thing.
- I will create a Trello board for coordinating the supervision process between you and me. The Trello board will define the agenda for our weekly meetings.
- I will start by asking you to define a research plan for your project using this template. I will also ask you to take one of my courses IT3010 or TDT39 if you have not done so already. The research plan will be a central document for our collaboration, and we will update it as we move on. The text you prepare for the research plan will go into various chapters in your final report. I recommend you create an online version of your research plan and invite me to comment on it. Use for instance Google docs or a similar tool.
- For those of you with separate autumn project and diploma (engineering students): Although the autumn project is a separate subject than your diploma task, I strongly recommend that you plan to continue with the same subject. You should change topic only if you realize you hate your current topic or your supervisor! Continuity allows you to spend the autumn semester on reading literature and collect initial data and get to know your research topic. Then you can use the spring semester to do your main research study. An example can be:
- Autumn semester: Literature study, initial interviews with users, sketches and product ideas.
- Spring semester: Prototyping, recruiting users, evaluation, writing up.
- I expect that we have regular meetings. We will agree on a fixed time slot for meetings on this week day. We don’t need to have meetings every week but we should meet more often than once a month. We will normally go though your research plan in these meetings. Procedure for our meeting schedule:
- We agree on a time slot, say 10:00 on Wednesdays.
- I will wait for a call-for-meeting email–with agenda and documents to read–from you the day before, say by Tuesday 12:00. If I don’t get one I assume there will be no meeting that week.
- If you have sent me a call-for-meeting, we meet at Wednesday 10:00 that week.
- If I don’t receive anything from you for a month, I will call for a meeting:-)
- When you start writing your report you will ask me to read it. When you send me drafts of your report–or research plan– to comment please make sure you give me enough information about what feedback you need. You can read some of my tips here.
- The tasks I supervise normally don’t need to be protected and can be published openly after you have submitted. Therefore I will ask you not to close your MSc thesis when you submit it (unless you agree with me on something else).
- If you develop code as part of your task, I want the code to be licensed under Apache 2.0. This is a flexible open source license that gives you and me a fair chance to build on and further develop the code in the future. Apache 2.0 allows you to commercialize your product if you wish, and it allows me and my future students to have access to the code for the years to come.
- In case you develop code: We have earlier used github as a repository for code and all its documentation in the past. Please use github, or a similar service if you are going to code something as part of your research. Your github repository should at the end be a self-contained repository for all your code and all the relevant documentation. It should also show the history of the development. So you should use the “issues” function in github a lot.
- I expect that we publish your report as a research article in an international conference or journal. This means the rigor of your research needs to be high.
- I recommend that you submit an abstract of your final thesis to our own research blog Smidig.org, and to Masterbloggen.no.
- For some hints and tips see my blog posts on technical writing and research methodology. Here you will find some very practical tips on different aspects of writing a good report, and some pointers to Internet resources.
More to come.