by Sarah L Bulloch. Teaching Fellow at the CAQDAS Networking Project
At the CAQDAS Networking Project we have worked with lots of different teams of researchers over the years, supporting them with how they can operationalise their objectives and research questions using computer assisted qualitative data analysis (CAQDAS) packages.
This blog post highlights some of the key challenges that we tend to find researchers grapple with when collaborating and sets out some ideas to help address those challenges. These were also discussed in more detail in one of our webinars.
Technical aspects of teamworking are fairly easily addressed using CAQDAS packages
It is worth knowing that across all major CAQDAS packages, we find it is relatively easy, technically, to combine work done by different team members, either by merging separate projects, or by working with versions of the software that specifically enable synchronous cloud-based or server-based working on a single project. To explore which option is best for you in your chosen package, have a look at our independent software reviews.
So, if researchers working in teams using CAQDAS packages typically don’t find the technical aspects too challenging, where does the real challenge lie? Our own experience, and that of others, is that the main challenge of teamworking in CAQDAS packages lies in the human aspects. These dimensions of teamworking are discussed in more detail by Woolf & Silver 2018 Qualitative Analysis using ATLAS.ti/MAXQDA/NVivo: The Five Level QDA Method Routledge.
Human aspects of teamworking are more complicated and require careful planning
The following human aspects are critical to consider for successful teamworking:
Clarity on objectives, methodology and method: Setting out a shared goal in relation to objectives, methodology and method can help minimise diversity in ways of working. Clearly in very deductive projects it is easier to plan far ahead, whilst you may need to be more open to allowing for emergent direction when you are trying to be open to working as inductively as possible. Early and explicit planning is key. CAQDAS packages contain many writing spaces in which to set these out these plans in advance, and in which to record concerns and questions that arise over time.
Clarity on roles: There many different analytic stages and activities in any given project. And it is likely not every team member will be involved in every analytic task. Try to set out a clear list of tasks and decide who will do which of them. If more than one individual is responsible for any of the tasks you identify, it is worth, as default, aiming for consistency in the way these are being done across the team. For example, setting up clear code definitions to help you reach shared understanding of how to use each code can really help.
Data preparation: You can save yourselves a lot of heartache later down the line if you consider preparing data in a standardised way. Basic things like deciding on a file naming protocol which anonymises participants and retains essential information can be useful.
Dividing up coding work: Coding is typically one of the lengthiest analytic phases of a project so it pays to think carefully about how to achieve it effectively for your project. There are several ways of dividing up the coding across several researchers.
- By transcripts: each researcher codes a sub-set of the transcripts to all the codes. In our experience, this is the most common approach, especially in projects that employ deductive coding approaches. But it is worth thinking about the alternatives, below.
- By coding: each researcher codes all the transcripts but is assigned a sub-set of the codes to use. This approach can work particularly well if certain researchers have expertise in particular areas of the coding scheme whilst other have expertise in others, and it can improve coding reliability.
- A hybrid of the above: in the first phase of the work, the transcripts are divided across the team and every team member codes to all the deductive codes and generates some inductive codes, if relevant. But you try to keep the codes fairly general. In phase two, you assign areas of the coding schema to each researcher, and they then drill down in more depth and nuance around those areas across ALL transcripts
Clarity around deductive coding: If your research question and approach mean that there are topics you already know you will code to, it makes good sense to set up these “deductive” codes at the outset of the project, in a sort of initial “master” version, in order to ensure all team members are using the same deductive codes. CAQDAS packages provide spaces in which these codes can be defined, which helps researchers to use them in similar ways.
Working inductively (without utter chaos ensuing): This is an area of teamworking that can potentially become very messy very quickly if not managed carefully. The main reason is that inductive working requires iteration. As researcher A creates a code inductively on their 5th transcript, not only do they need to work back through the first 4 transcripts to incorporate it, but their team members also need to do the same. Regular team meetings are required to cope with this. Most CAQDAS packages allow for some way of identifying which researcher made which code. This can be tracked by the system if each researcher has set up their own username at the start of the project. It can also be manually indicated – either in the name of a code using initials, or, and most cleanly, if you can group any inductive codes made by a researcher in a space designed for only that researcher.
Organising data: Many research questions contain some element of comparison across groups e.g. comparing student satisfaction of a) home students and b) international students. Sometimes these characteristics are known by the team up-front, other times they emerge from the analysis. Most CAQDAS packages have features for assigning characteristics such as socio-demographics, to data. Yet, just like coding and other analytic tasks, you want to ensure that this organizing is done in a consistent way for the whole dataset. We would advise setting up agreed characteristics and their possible values at the start of the project and for a project manager to add to these as needed.
Finishing on time: If the methodological approach and the method chosen for the project allow for it, it may be fruitful to consider beginning with codes that are fairly general, and that are thus easy and fast to apply; acting like buckets for material that has something fairly general in common. Once all the data have been coded to these general codes, the team can then drill down into more nuance within the general codes for as long as there is time. If inductive working is required, you might consider “locking” the codebook after a certain number of transcripts have been worked through inductively.
In the webinar “Teamwork makes the dream work: Avoiding nightmares when collaborating with others in qualitative data analysis using software” I discuss and illustrate these issues in more depth.
AI use: The author used an AI-generated transcript of the webinar and edited this as well as adding her own thoughts to it.
