Archive

Posts Tagged ‘QIG’

QIG: March 2010

March 2, 2010 Leave a comment

Today’s QIG topic continued the theme of “rapid qualitative research” from last month: how can you perform “good” qualitative research quickly, instead of immersing yourself in your data for months (or years) as themes and theories emerge from the mass of data.

There were some interesting stories shared, from people with experience working on project timelines unheard of in a typical academic setting: market research consultancies with two-week turnarounds; international aid assessments that generate reports a month after hitting the ground in a new country. This is a quick braindump of things I found interesting during the meeting:

‘Quick’ projects aren’t always as quick as they look. Consultancies that take two weeks to go from project brief to final report don’t always start cold: the brief will usually be written by someone who knows exactly what they are looking for (and how to find it), and the researchers may well be spending years working in that space. These reports can generate some fascinating insights into behaviours and motivations, but those insights may be shaped by a career of research in related areas.

If you want quick data analysis, you need to design your research to accommodate this. Work out what types of data you need to answer the research questions. Are they opinions? Behaviours? Reactions? The more you can structure your research during the experiment design phase, the less time is needed to untangle it during the analysis phase.

Analyse during data collection. While conducting an interview, be aware of the major themes that you want to address – it helps you know when to ask more detailed questions, and you can link together important themes. It also makes it much easier to find related items in a transcript. “Tell me about X” might be a great way of generating a heap of data. “Tell me about how X was affected by A, B and C” may be much more effective at answering your research questions.

Some types of research are going to be slower than others. If you’re testing a hypothesis: great! Previous work should let you know what to look for, and what to ask about. It’ll either pass or fail. If you want to develop grounded theory, you’ll need time.

Quick work is rarely done alone. Academic qualitative studies are usually done solo. The relationship between these is no coincidence… Generally, quick research involves data analysis by a group of researchers, often immediately before and after gathering data in the field. Doing the whole lot solo is unlikely to let you work through things quickly.

Advertisements

Qualitative Inquiry Group @ RMIT

August 4, 2009 Leave a comment

The Qualitative Inquiry Group meets on the first Tuesday of each month, in the Accounting and Law boardroom – right next to my office. I’ve decided to start attending their meetings, though it’s causing a bit of trouble with desk space… I originally said I’d be in the uni on Wednesdays and Fridays, and my desk has been claimed during the rest of the week.

Today’s workshop was on coding qualitative data (using software like NVivo). A few people described their experiences during past or current projects, and the discussion evolved from there. It seems that there are only two real rules, as far as data coding goes:

1. You need to have (and know!) a reason for coding up the data – it’s a technique that can help to solve a problem. Otherwise it’s a rather masochistic exercise, and a great way of never finishing a thesis…

2. No two people follow the same methods, though hopefully two researchers would both use similar codes for the same bit of data.

Essentially, NVivo is designed to help analyse large amounts of qualitative data. In my case, that takes the form of interview transcripts: by the end of the research phase, I’ll hopefully have about forty interviews to analyse.

Codes are categories, topics or themes that you are interested in exploring. They aren’t always directly stated (so can’t be searched for using the transcript text) – they might be nebulous things like an interviewee’s attitudes towards management, or their motivation for making a decision.

Developing codes is an arcane art. Ideally, they “emerge” from the data – when reviewing the interviews, new themes and elements of interest are discovered. Many people start by assigning codes based on existing theories that (hopefully) explain your observations. That’s fine if you’re testing a theory, but it doesn’t work if you want to develop grounded theory of your own…

Multiple codes can be applied to any given bit of data, which is a good reason for doing this with software instead of coloured pens and post-it notes. Actually, a good interviewer should be getting statements that have multiple meanings: a statement about use of a specific technology might also allude to innovation, risk, etc.