How will you integrate NVivo into your research process?

One thing that's been on my mind during recent NVivo training sessions is the extent to which the technical capabilities offered by the software can sometimes inadvertently obscure underlying questions of research process and analytical purpose.

The software can seem so all encompassing, particularly as one becomes acquainted with it for the first time, that it's easy to lose sight of the fact that using the software is only part of a broader research process. For those taking advantage of NVivo's more advanced features, this can sometimes constitute a large part but it is, nonetheless, only a part.

Be clear about what, why and how

When using NVivo in a research project, it's important to be clear about precisely why and how the software will be used, as well as the strategy adopted not just for the software itself but also for how the software is to be integrated into the team's research process and workflow. This encompasses things like naming protocols and maintaining a codebook but it also entails much more fundamental questions about what 'analysis' is, what is being analysed and how this will be done.

It's not so much that researchers fail to recognise these questions but simply that the complexity of the software can sometimes push them to one side.

Software is just a set of tools

Discussions of theory, methodology and analytic strategy within a project are more not less important when NVivo is being used. The software can often 'suck in' people so as to make it more difficult for them to keep in mind that the software is simply a set of tools to be used as part of a project.

Further misconceptions can quickly flow from this:

For example, the misconception that the software does something (a notion of some automated process of analysis) is not uncommon. The question of who is in charge, the software or the researcher, is tellingly reflected in enquiries such as ‘Will it let me. . . ?’

It is sometimes forgotten by those new to qualitative software that any lack in its ability to do something in particular certainly does not preclude them from including such strategies in their research. It is always possible to leave the software to one side and use other means as well—to get out of the car and perhaps walk, cycle or a take a boat for parts of the journey, as it were. It must be emphasized that, although the limitations it imposes continue to decrease, the researcher is not a hostage to qualitative software. (Crowley, Harre, & Tagg 2002)

Ask broader questions and make informed decisions

One way I've tried to counter this tendency in my own training practice is through the repeated use of analogies to physical stationary e.g. memo links as paper clipping notes to an interview transcripts or nodes as file folders containing clipped extracts of printed transcripts. However, I think it's often helpful to go further than this, particularly when working with research teams.

The question of how NVivo is to be used is intricately bound up with broader questions of project aims, methods, methodology and workflow. Elaine Walsh uses a nice analogy to convey how NVivo is embedded in a broader practical context:

At this point it is useful to think of the qualitative research project as a rich tapestry. The software is the loom that facilitates the knitting together of the tapestry, but the loom cannot determine the final picture on the tapestry. It can though, through its advanced technology, speed up the process of producing the tapestry and it may also limit the weaver's errors, but for the weaver to succeed in making the tapestry she or he needs to have an overview of what she or he is trying to produce. (Walsh 2012)

By framing the explanation of the software in terms of a much more expansive discussion of how the project will proceed once the data collection phase has concluded, it becomes easier for teams to make informed decisions about which features of NVivo they wish to use and which they don't.

Back to blog listing