Working with others in NVivo

01 June 2017 - BY Fiona Wiltshier

Working with others in NVivo

In this blog Fiona Wiltshier explores working in teams in NVivo and shares her tips on making collaboration easy. 

There may be a number of reasons why you would like to include other people’s work into your own NVivo project, however, as a trainer, the one I have come across most is when there is a group of researchers all working on the same research project.

Through working with groups around the world, I have found that no matter which country they are in, or language they are using, these are a number of things to think about that can help make the process smoother and easier. 

Some groups work with the standalone version of NVivo, where team members either have to take turns working on the project or they will have their own version of the project on their computer and then merge their individual projects into one overall project. Others choose to work with NVivo for Teams, where more than one person can work with the same project at the same time. The project is located on their organization’s server.

Working with a “Master” Project

Whichever version you are working with, it can be helpful to start off by creating a project together. Discussing the project structure, nodes, classifications and attributes that would work for everyone can make the process smoother as your project progresses.

Once this has been created, teams working with the standalone version often find it easiest for everyone to then have their own copy of this ‘master’ project to work on individually.  These can then be merged at any stage to combine everyone’s work together. 


Merging Projects

NVivo makes it easy to merge two or more projects together by importing one project into another, however, just because the projects themselves merge, doesn’t always mean that the items in the separate projects also merge together!

In order for items from two projects to merge together, they have to be duplicates, and what NVivo means by duplicate, and what we mean by duplicate, may not always be the same, for instance...

Sources can be only merged if they have exactly the same content, the same name and are in the same folder. By the same content means that even if one extra character has been added to a source in one project, it will not be treated as a duplicate of the ‘same’ source in the second project. So one important rule is that team members must never edit a source. Nodes can be merged if they have the same hierarchical name, and classifications and attributes can be merged if they have the same names. 

This is another reason that creating a ‘master’ project can be helpful.  If everyone has the same project to start off with, and no-one changes the core structure in their own copy, then the merging process should be easy!

Thinking about Sources

Sources can often be organised early on in a project so, when creating your ‘master’ project, consider the sources the group is going to be working with throughout the project and create a folder structure that makes sense to everyone. 

If more than one person is going to code the same source(s), import these, then, to make sure they stay the same, make it a rule that no-one changes them, ever! Code them for sure, just don’t change them! Quality checks for spelling, typos etc. should be done before importing.

Nodes for everyone

Probably one of the most important areas to focus on as a team are your nodes, as, at some stage in your project you will probably need to create a coherent node structure that encompasses everyone’s thinking. 

It may be that it makes sense to do this at the start, or it may happen later on in the process.  Whenever you get to this stage, the node system in your ‘master’ project will need to be one that makes sense to everyone, and that everyone in the team agrees on.  This of course can, at times, take some discussion!

Once you have agreed on the node structure, it can also be useful to agree on what you, as a group, mean by each node and enter this into the node description so that everyone can refer back to this as needed. As different people think differently, and so often code differently, this can be really helpful if you are looking for consistent coding! In the latest version of NVivo 11 for Windows (all editions) you can print out the codebook with nodes and their definitions from the Master project for everyone to use. (In the Ribbon, click on the Data tab, and then click on Codebook.)

Emerging themes

As each person works, it is likely that they may come across new themes that have not yet been captured in the node system.  Rather than everyone adding new nodes to the existing structure, the best option is often to create one ‘named’ node for each team member. 

For instance I would have a node called ‘Fiona’ and under this I can create the new nodes I discover as I work with the data, and code to them.  Once we come back together as a group, and projects merged if needed, we can all see the new nodes each person has created, discuss these and move them to the main node structure. 


More thoughts

Working with others as part of a team can be an enriching and rewarding experience. For more things to think about to make this process as smooth as possible please see the About Teamwork section on the online help or have a look at some of the posts from those working in teams on the QSR Forum