Advice for ITU project writers

The web is awash with writing guidelines. And as I’ve mentioned before the Danish book “Den gode opgave” cannot be recommended enough. But here are a few tips which I have found relevant for ITU students in particular:

  • Be more critical. Theories and research cited and used must be evaulated critically. Even the grandest old men/women of whatever field are not above critique. Particularly if coupled to modesty towards your own contribution (and a clear eye for your own problems) such criticism is a good idea (if it’s relevant, of course).
  • Consider the role of theory. Understand the relationship between theory and data in your project. Using theory as a framework for understanding (as opposed to something which is specifically tested etc. in a study) is fine but you risk leaving a gap between a long theory chapter and a much more concrete study.
  • Avoid circular arguments. Be careful of arguments and motivation statements without any content. E.g. “I’ll use X’s theory because I find it relevant”. For Danish writhers this can mean considering carefully each “fordi” and “derfor”.
  • Emphasize important stuff. If you find interesting results or reach surprising conclusions consider placing these at the fore of the project. Avoid placing every observation on the same level without emphasis. Why not put your most important finding in the very title?
  • Novelty is not relevance. You don’t need to write about newly born technologies (although there’s nothing wrong in doing so). And you certainly don’t need to use only recent literature. Don’t believe the hype – check the library. (And it can often be quite impressive to show relationships between classical thinkers and new communication phenomena, it demonstrates a breadth of knowledge).
  • Use examples. Please. It’s so obviously illustrative, so please use screenshots. Also note that by using examples you display your ability to see the abstract in the concrete and vice versa
  • Turn weakness into strength (to be used in small doses). Often students worry about “problems” which may as well be considered advantages. Two leading theoreticians disagree? Well, that’s their problem not yours. And you may well have discovered something crucial
  • Choose a reference style. Unless you have very strong opinions about how to make references use one of the hundreds of existing systematic styles such as the MLA style ( You need not follow their specifications about manuscript formatting (although you may want to ask your supervisor)
  • Never walk the reader through theories. Okay, that may a bit strong. How about: Never spend more than 5 lines describing a theory on its own terms. It’s much better to describe the implications of a theory or to contrast/compare it to other theories. In general, use your time on your results/conclusions and cut down theory chapters (based on the average ITU approach – doesn’t apply to everybody)
  • Don’t overestimate the user perspective. You don’t have to engage in qualitative user studies. There are other, legitimate approaches. Numbers can be fun.
  • Take a stand (and stop worrying). This is closely related to coming up with a sensible problem statement (covered in-depth in “Den gode opgave”). Avoid writing about a topic. Instead try answering specific questions. Examining specific hypotheses/questions means ignoring a multitude of interesting aspects of your topic, but this is generally preferable to lists of observations or characterizations which only stop when you run out of space. Also, don’t worry too much about being too close-minded and not open enough towards the complexities of reality. Spend your energy on sharpening your methodology and describing your approach in detail. If your methodology is strong, you can (as a general rule) be as biased as you want to in your assumptions – the results will prove you wrong. And interesting things might come of it.
  • Mention implications of the seemingly important. Within limits you’re free to base your argument on non-obvious assumptions. Economists are particular good at this, often noting how the argument to come is based on the assumption of Perfect Competition (for instance). When you do so, you must specify the character of the assumption and what’s at stake. For instance, how realistic is the assumption? And what would mean for your argument if you had chosen a different assumption? If you do not, the reader will be left with the feeling that something important is happening, but unable to identify the implications. For instance, if you state that “Phenomenology is based on the assumption that people’s subjective perceptions are interesting in themselves and this thesis is based on that same assumption” you need to explain why and to what extent your argument is invalid to someone who doesn’t share your assumption.
  • Review the literature. All projects must, in some form, discuss previous work. This means using a library to uncover the state of the field. Your review of previous research should focus on results, i.e. what we know at this point.
  • Back up your claims. Any claim which is not protected by clear consensus must be backed up by A) citing literature or by B) arguing/showing why it is correct. There’s no exact recipe for what constitutes “clear consensus” but check research articles within the same topic to see what kind of claims the authors allow to pass without backup. Also, if you’re in doubt, you probable do need a reference.
  • Find a problem. A project or master thesis sets out to answer a research question (“problem statement”). This research question should be thought of as a “problem” – if there is no problem for anybody then there is no reason to conduct the study in question. A topic (“I want to write about political games”) is not a research question. Variations of “I want to apply Model X to Phenomenon Y” may under some circumstances lead to a worthwhile project, but it is a much safer bet to find a genuine problem.

More to come…

Comments are closed.