Six ways to take the stress out of team-based research

I’ve been reflecting on successful team collaboration recently, as I’m presenting a QSR eSeminar on this topic next week (more on that later!). Our office has also been buzzing, as we’re in the midst of a large team project using NVivo Server, and it’s given me a perfect opportunity to reflect on the procedures we’ve developed to ensure our team projects run as smoothly as possible.

We have really enjoyed the NVivo team projects we’ve been involved in, but I’ve worked with a number of teams on a consulting basis where team members have been close to meltdown, and are fast moving backwards instead of forwards in terms of their analysis.

Why do some team projects become so difficult?

One thing that strikes me about qualitative projects is that they are by their very nature “messy”. We are often dealing with large amounts of data in a wide range of formats, with procedures that aren’t set in stone and have a tendency to change as the project evolves. If you add multiple team members to this scenario, possibly with different epistemological views, skills/strengths, and time availabilities, it’s easy to see how difficulties can arise!

6 simple strategies

A number of these issues can be resolved by clear, open communication amongst team members, so I’ve listed a few simple strategies below that may help. These are framed in the context of using NVivo, but they can be applied to other projects.

1. Make a plan

A common mistake I observe with teams is that they jump straight into using NVivo without considering the best way to proceed. I suspect this tends to happen when tight timeframes are involved. This is a bit of a false economy—if you stop and plan carefully at the outset of a project, it can save an enormous amount of time later on. Having to fix errors on a team project can be very expensive—let’s say you start a project with five team members coding for four hours a day, and realise at the end of the first week that they all have a different understanding of the nodes. That’s 100 hours of coding that will either need to be re-done or have a complicated fix-up job conducted on it!

2. Develop a codebook

Not surprisingly, having used the example above, the next thing I’m going to suggest is that you develop a clear codebook from the outset, and ensure that all team members have a similar understanding of it. Jenine Beekhuyzen has recently written an excellent blog post on this, so make a point of reading this before your next team project.

3. Hold an initial team meeting

Take as long as you need for this and ensure that clear records are kept of decisions made. Some suggestions for things to cover at the first meeting include:

Team roles and how to deal with changing roles as the project develops;

The best means for communication amongst team members (particularly important for geographically dispersed teams). Don’t forget to discuss frequency of communication and meetings;

How records will be kept, including protocols for working with data and the NVivo project itself (e.g., can team members correct typographical errors in transcripts, can new nodes be added to a project by individual team members, who is responsible for backing up data?);

How to deal with coding dilemmas (e.g., how to code data if you’re not sure where it fits, dealing with new nodes that emerge, how much context should be coded for each coding reference).

Keep in mind that it’s important to make these decisions up-front and record them, but don’t stay too attached to them—the processes you need will likely evolve with the project, and some of these decisions may need to be revisited. This of course needs to be done as a team, so that everyone remains on the same page—there’s nothing worse than a “lone ranger” in a research team!

4. Train together and run a pilot

If your team is not experienced with NVivo, spend at least a couple of days training together as a team. It would also be worth conducting a “pilot” NVivo project with a few pieces of data, so that team members can feel more confident with the software when the actual project starts. A pilot project is actually a good idea even for experienced teams. For each different data type, format one or two files and import them into a test project to check that you’re able to code and work with them the way you hope to.

5. Test and review

Once coding begins, it’s worth spending some time checking that NVivo will produce the outputs that you were hoping for based on your coding framework (impossible to do upfront, but essential to find out before it’s too late!). If you’re using the standalone version of NVivo and need to merge team projects, you might also like to have a trial run of the merging process sooner rather than later. If problems arise, you can develop new procedures and feed these back to the team.

The above are just suggestions, and there are plenty of other things that may need to be tested and reviewed along the way—depending on the nature of your project. The moral of the story is that you should be regularly testing and reviewing anything you need to, before you end up taking a path that will require backtracking.

6. Document everything

Even if you think you’ll recall all decisions made (chances are you won’t by the way!), then what about your fellow team members? Or, what if a team member has to be replaced—how will the new team member get up to speed with your project? What if there’s a disagreement between team members over a prior decision?

We use the memos area of NVivo to contain all documentation for our projects. Some ideas for documentation include:

Minutes of team meetings that record decisions made, roles assigned, next steps, deadlines etc.;

The codebook for the project, along with on-going changes;

Conventions used in transcripts (you can view an example here), including any style sheets if applicable, and any other formatting “rules” for data;

Copies of interview schedules and other data collection protocols;

Procedures for merging standalone projects (if this is required);

Protocols for making changes to the project, importation of data, backing up etc.

Document everything in memos

Note that having this type of documentation is incredibly useful if you are collecting data in multiple stages—rather than re-inventing the wheel, you can simply refer to your earlier procedures.

It’s also a great idea for each individual team member to have a memo where they can keep records of tasks completed, questions they want to raise, new ideas, reflections etc. This can then be easily accessed at the next team meeting, and is also extremely handy if a team member is unexpectedly unavailable.

What else?

There are lots of other suggestions I could make here—the importance of having a lead researcher for the team, why on-going team meetings are essential, and the value of being flexible just to name a few. Are you working in a team? I’d love to hear your strategies and war stories!

If you want to learn more, please join me in my upcoming QSR eSeminar. There are two dates to suit different time zones – June 11th, 2013 for New Zealand/Australia and June 25th, 2013 for UK/Europe. To register or find out more go to the QSR website.

In the meantime, best wishes for any upcoming team NVivo projects you have!