Jump to content


Rebuilding Christchurch: Tips from Two Large Scale NVivo Server Projects

  • Please log in to reply
No replies to this topic

#1 Lyn Lavery

Lyn Lavery

    Advanced Member

  • Trainers
  • PipPipPip
  • 112 posts
  • Gender:Female
  • Location:Auckland, New Zealand

Posted 08 February 2012 - 04:22 AM

Academic Consulting staff were recently involved in two large-scale public submission projects, that related to the planning required after the devastating earthquakes in Christchurch, New Zealand. The first project addressed the rebuilding of the central city, and was facilitated by Christchurch City Council (CCC). The second project focussed on the wider recovery strategy that the Canterbury Earthquake Recovery Authority (CERA) were responsible for. Further details on the projects can be found on the Academic Consulting website (http://www.academic-consulting.co.nz) or the QSR website (http://www.qsrintern...l.aspx?view=443).

As both projects had firm deadlines due to their far-reaching implications, working effectively with NVivo as a team was crucial in order for us to achieve the required outputs. We learned a lot throughout the process, and thought we’d compile some tips for other researchers working in teams.

Using NVivo Server

While the standalone version of NVivo allows for the merging of individual projects, this can be time consuming and fraught with difficulties if team members do not follow required protocols. Given the limited timeframe we had for analysis, it was crucial that each member of the team was able to work on the project concurrently. NVivo Server provided us with the capability to do this, and was fundamental to our ability to manage a project of this magnitude. Based on our experience, we’d highly recommend the use of NVivo Server (rather than the standalone version) for team projects.

Coding as a Team
  • Throughout both projects, regular team meetings were essential to ensure that all researchers were using the coding structure correctly, and to check the interpretation of the different themes. Meetings were held each day to go over any amendments to the project, to discuss any issues raised, and to track progress and assign tasks. Memos were used to record meeting minutes, so project-related information was stored in one location. Each team member also had a memo of their own, where they recorded their progress each day. This became particularly useful when a team member fell ill; in this instance, we could use their memo to ascertain exactly where they were up to with their assigned data.
  • Joint coding of data at the start of the project was helpful in checking team members' interpretation of the nodes. The 'Coding Stripes' [by user] function was a great tool for this.
  • We found it useful to have one researcher take on a leadership role with regards to coding decisions. This reduced the potential for drawn out debates, and provided consistency with the analysis process.
  • We created an 'unsure' node for coding all data that team members were uncertain about. Reviewing this regularly helped to identify potential problems, and reduce coding errors, whilst also providing ideas for emerging themes. All references coded at this node were eventually re-coded to a more appropriate node.
Dealing With a Large Node Hierarchy
  • A clear node structure (with descriptions) was a crucial aspect of the success of both projects. The descriptions for each node were made as specific as possible before the projects began. Subsequent clarifications were sought immediately, and were then added into the node definitions. An up-to-date node structure was distributed as a Microsoft Word document to team members each morning, with any additions/alterations clearly marked up in a different colour so changes could be seen at a glance.
  • Within the project itself, we had an unusually large number of hierarchical nodes. In order for us to be able to reference these quickly, these were numbered as 1.1, 1.2 etc. While we were reluctant at first to use numbers, our team meetings halved in time once this numbering was introduced, as we were able to quickly find the themes that fellow team members were referring to.
Using Queries
  • Coding queries were a big time saver for the odd occasion when coding mistakes occurred. For example, we had a theme that related to bringing people back to the central business district post-earthquake. One of our coders was accidentally coding references to bringing business back at this theme. Our team leader was able to do a Compound query – searching for the word ‘business’, but only if it occurred at the ‘bringing people back’ node, and only if it was coded by that particular team member. As the project had over 40,000 pieces of data in it at that stage, you can imagine how much time was saved!
  • Text Search queries were utilised in order to speed up the coding process. The visualisation tools associated with the Word Frequency and Text Search queries (Word Trees, Tag Clouds etc.) were also an excellent way for us to quickly become familiar with the data.
We found the teamwork aspect of these projects both exhilarating and challenging - it would be great to hear how others have approached their team projects in NVivo.

Lyn Lavery and Rachael Butler, Academic Consulting
Lyn Lavery
Director, Academic Consulting
Auckland, New Zealand
Email: lyn.lavery@academic-consulting.co.nz
URL: http://www.academic-consulting.co.nz/

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users