online QDA logo - Home Page



Bookmark and Share

NVivo logo A Team Protocol for Planning Work with Merge for NVivo in Mind:

For team members who are working on different parts of dataset.

Author of this page: Ann Lewins

Affiliation: University of Surrey

Date written: 16th Sept 2005




What follows below is not a step by step process in the software. It is designed to help you plan for the use of ‘Merge for NVivo’.  The whole of this protocol below is specifically designed for those team members analysing separate parts of a dataset, and later (or repeatedly with later work) merging those separately worked on projects into one large project with Merge for NVivo. Parts of this protocol will not work for teams who are coding/analysing the same data.  These options do not represent all possible routes to successful data management in a team, they merely offer ideas and warnings in terms of what is possible and what NOT to do.

It is also very important to bear in mind that if after a merge,  the merged project is redistributed for further work by team members, this second merged version more closely resembles a project where team members are now working on the same data, or at least have the same data available to each member. Thus some of the warnings given at EXTREME DANGER below are also relevant to the model of team working where all team members are working on the same data.


Merging projects - Warnings - Being mentally prepared

What to think about - What will be possible - Dangerpoints

Decide whose project will be the 'Master' project in NVivo terms, and then it follows all other projects will be auxiliary projects.

New codes within e.g. the auxiliary project Node trees (hierarchies) or under Free nodes will interleave with existing collections of codes.

To start with you are each going to be working on your own dataset. This presents no problem e.g for editing, coding, using the db (databites-internal annotations). And you will always be able to ADD more coding to your own, or other people’s docs even after the merge within your new merged version of the project. BUT......

EXTREME DANGER: Data/documents that have been part of a previous merge and maybe merged again - must NOT be edited, changed or have links of any kind including databites inserted in them.

If this happens the documents will never again merge together, which means that EITHER coding will be lost (if you have to skip that  auxiliary document in the merge) OR you will  appear to double up on coding  references (if you simply accept the offer to Rename  that document in order to get them into new merged version of project) This means you will have two versions of the same document, and common coding to both of them will be counted twice in any search retrieval. Bad!

YOU MUST BE AWARE OF THIS DANGER NOW -and keep it in mind for later. This is chiefly a problem for primary data that you will code.

Because you will be constantly editing and changing them, you will also hit this problem with ‘writing’ files like the below; the problem isn't so important with regard to supporting memo's like yr project journal and team talk memo...because it is not absolutely necessary to code them and therefore coding does not need to be merged;  you can always get rid of the redundant, extra, similarly named files.

Icon colours for data files, project naming etc

Icon colour

Each researcher can have their own document icon colour, or use icon colours to differentiate on another aspect of the data.

(To do this: Select document while in  Explore Documents... hit Properties (i) icon


Data file (Document) naming

Make a codified protocol for building in as much information as possible into file name. Bear in mind that the documents will be listed in numerical or alphabetic order. So ensure that the files you want listed together, appear together in the Document Explorer, because of the first prefix that you assign to the file name. E.g. all female files might have a prefix  F- .


Coding Frame Agreements

Coder reliability and coding frame agreement:

You will probably code up a couple of same documents each...and then come together to thrash out an agreed coding frame and what you mean by each code, and approximate agreements on the amount of additional context to include while coding  This resultant agreed coding frame will be built into one project which will then be copied and distributed amongst you.

Creating new codes: When working on your own later in your own project with own data, your Newly created codes could be prefixed by initials to identify authorship.

e.g. WP-change  is Wendy Peter’s  new code ‘change’

Then  new codes which accidentally look the same but are totally different won’t merge  when the projects are merged but they can be merged on a piecemeal basis in the Master project later.

Tidy the coding frame

When you have been re-organising codes - i.e. putting them into hierarchies, try not to arrive at the point where you have copies of nodes all over the place. So if you drag a node out of Free into a Tree position... make sure you delete the original. After the first merge at whatever stage this happens, make sure that all relevant tidying up happens in the master project before redistribution of the project for further work on an individual basis.


Document Attributes (Explore Document attributes)

Attributes can be created in the project (or most of them) before original project (with its coding frame) is distributed to team members. This will allow for a level of standardisation and consistency.


Team Talk document

Create this document as the place to write in stuff you need to communicate with the others at next team meeting or by email. (create Blank document)

To render this document into an emailable format after you’ve done some work in it. While you are browsing the Team talk doc:-

Document menu/ Create text report ,

Deselect Show Section nos, Show Para. nos 

(It makes for unnecessary clutter) but keep Show datalink details as end notes

File menu/save as/   ensure you name it adequately and VERY IMPORTANT click on spinner arrow at Save as type box, to select Rich Text Files format.


Internal Annotations (Databytes)

This tool is for first time annotations only -after the first merge of all the existing separate data you won’t be able to re-annotate that same data again..because if you do, ...see EXTREME DANGER note above... the software will see that now the files have become different. Therefore new Databytes or links should not go into docs which have been part of a previous merge. This is particularly the case for primary data files which are being coded: you can work around the problem for your project journal, memo’s, teamtalk docs etc, as long as they are not being coded.


Remembering How Search Tools or Sets May Be Useful Later

Boolean/ UNION /OR search... if you have a large number of codes, and some repetition across hierarchies, you can do such a search to collect them all into one new node (code) to create a broader/higher category or concept. Allows you to rename and collect into a new theme without losing original constituent codes.

Sets of nodes

OR create a set of nodes  (Choose set button, right button menu, create set, name it)  to lay down markers for Renaming a theme, interesting angles, slants, Chapters, drag individual codes into sets ...and use these sets as a way to do Matrix searches or Union searches on the members of a set. Any team member can create a set, follow the rules about initialing the name of the set with your initials …e.g.   WP- Chapter 4 …until you agree amongst you that your set is a useful way of looking at things or a useful means of collecting certain nodes. Remember that sets of anything are completely unproblematic, they can be changed, abandoned, or simply ignored and they do not alter hierarchical structure elsewhere.


Coding On Paper - Using the Paragraph Coder

Initial coding exercises could be done on paper, especially useful for those who do not feel confident with NVivo and do not have the time to learn but wish to be productive in terms of coding.  But first create a report of the document you are going to code, by

Select Document menu while browsing the document

Choose Text report option

Cancel Show Section numbers

Keep Show paragraph numbers

Keep Show datalink details as end notes

When new report file is on screen - Save as ...ensure you choose in Save as type option, Rich text files

Print...then code by paragraph using pencil annotations in the margin... as many codes against each paragraph as you wish.

Then use the Paragraph Coder by selecting this option from the right button menu on that document in Document Explorer, in order to input coding into the data, within the software.

top of page