Secrets of a healthy NVivo project
28 February 2017 - BY Kath McNiff
We bring you tips and tricks to help your NVIvo project succeed.
We know that our physical health relies on good food, plenty of sleep and regular exercise.
While it's not always easy to stay on track (because chocolate and Netflix exist), at least the goals are clear.
But what about your NVivo project? How do you safeguard its health and keep it on the path to success?
After peeking inside quite a few NVivo projects – I'm getting a clearer picture of what 'health' looks like and the steps it takes to get there. Here’s what I’ll be suggesting in this post:
- Make a plan
- Develop a journaling habit
- Keep node names simple
- Use unique node names
- Include node descriptions
- Use a codebook.
Make a plan
Healthy projects have a plan.
It can be tempting to import all your data and jump straight into coding – and this might be ok in a ‘practice’ project - but when it comes to the real thing, it’s best to take a considered approach.
Whether it’s a detailed research design or brief one-pager, be sure to:
- Define your research question - shout it from the roof tops!
- List the types of sources you’ll be working with.
- Describe your units of analysis.
- Outline your approach to coding - include timeframes.
- Explain what you expect to see (assumptions and biases).
- Lay the ground rules for team work.
This is not an exhaustive list, but you get the idea.
You can then bring your plan into NVivo and refer to it regularly as your analysis progresses.
Keep a project journal
Continuous reflection is crucial to the health of your project. Think of it as the ‘regular exercise’ of qualitative research.
It is useful to create a project log or journal straight away, to note the day-to-day tasks you perform and the questions occurring in your mind (Lewins & Silver, 2007: 34).
It doesn’t matter what stage you’re at - it’s never too late to get started with a project journal:
- Create a memo in NVivo and call it ‘Project Journal’.
- At the end of every NVivo session insert a timestamp and record your progress. What did you learn? Any road blocks or surprises you need to follow-up? Where did you leave off?
- Link to the queries, maps or nodes that illustrate your thoughts.
- At the start of your next session, open the journal to see where you left off.
Researchers with a good journaling practice find it easier to explain their methods and justify their findings.
Plus, they keep match-fit for when it comes time to write-up that dissertation or report.
Keep node names simple
Your coding framework says a lot about the health of your project. Is it bloated and lethargic or streamlined and flexible?
Start by looking at your node names. Are they concise? Do they represent a single concept?
The kinds of codes you create, reflected in the labels you give them, impacts on the subsequent accessibility of evidence needed to support an argument (Bazeley, 2013: 158).
It may sound trivial, but easy-to-read (and specific) node names can relieve your cognitive load – freeing you up to make connections and see patterns.
Also, it’s much easier to explain your project to a teammate, supervisor or client when your codes make sense and are scanable.
For example, repetitive long-winded nodes like:
- Expressions of employee disengagement and mistrust.
- Expressions of client disengagement and mistrust.
Could be simplified like this:
Looks cleaner, but these nodes are more flexible too.
You could run a coding query to gather all the content coded at ‘client’ AND ‘disengagement’ or at ‘employee’ AND ‘mistrust’ or at ‘employee’ AND ‘disengagement’.
Put the puzzle pieces together in ways that address your research question.
For this to work, you’ll need to code your material at multiple relevant nodes – so that you can use queries to gather the fragments in revealing ways.
Use unique node names
When you repeat nodes throughout your coding hierarchy, you expose yourself to what my colleague, Training and Research Consultancy Manager APAC, Sue Bullen, calls ‘the node virus’. A situation where your coding framework becomes unwieldy and you struggle to use queries effectively.
Doesn’t sound too healthy, does it?
Consider these nodes:
- Negative attitudes
- Positive attitudes
- Negative attitudes
- Positive attitudes
See the repetition? A virus is beginning to take hold.
Instead, aim for this type of structure:
Again, code your material at all the relevant nodes and then use coding queries to gather the data in useful ways.
Include node descriptions
When you create a new node (or edit node properties), you can include a description:
Node Properties in NVivo
Don’t dismiss this step as window-dressing or ‘a-nice-to-have’ - carefully described nodes are integral to a project’s wellbeing.
Well, if you can’t explain why a node exists or how it addresses your research question, then maybe it’s just clutter - distracting you from what’s really important.
There’s a caveat here.
If you’re in the initial stages of coding (working with emergent codes) then it’s common to create nodes ‘on the fly’ without dwelling too much on how useful they’ll be. But beware of ‘the coding trap’ – where you end-up with an unmanageable list of indecipherable nodes.
Take regular breaks to review, prune and describe.
Use a codebook
When Dr Jenine Beekhuyzen, founder of the Tech Girls Movement (TGM) and NVivo trainer, consults on NVivo projects, her first question is:
“Where is your codebook?”
The codebook lists all your nodes and their descriptions – a bit like the spine or central nervous system of a healthy body.
You can export your codebook from NVivo into Excel or Word.
Share it with teammates so that everyone takes a consistent approach to coding.
Or, if you’re working on your own, use the codebook to track progress and to remind yourself which node to use and when.
The latest update to NVivo, makes this ‘fitness fundamental’ more accessible than ever.
The Codebook option on the Data ribbon in NVivo
Share your secrets
If the legion of books, blogs and unused gym memberships is anything to go by – health is a complex issue.
And the same might be true for NVivo projects. Perhaps I've just scratched the surface.
What are your secrets? I’d love to hear about them in the comments below.
Bazeley, P. (2013) Qualitative Data Analysis Practical Strategies. London: SAGE Publications Ltd
Lewins, A & Silver, C (2007) Using Software in Qualitative Research. London: SAGE Publications Ltd