I started thinking about how NVivo can help with communication because, in the course of training postgraduates in using the software to manage their data, I often heard stories about difficulties with supervisors – laments that ‘my supervisor seems to be supervising a different project from the one I’m doing’.

This made me reflect on my own experiences as a student. I realised that I had been unusually lucky. Communication with my two supervisors, Lyn Richards and David Hickman, was constant and detailed. We met frequently and most of the time I had sent long written notes about my work before the meeting. In terms of the first slide in the presentation, Lyn and David knew the nuances of my project. While I was often unsure of how to collect and work with my data, confused about what it meant and frustrated trying to put the meaning into words, I never felt that my supervisors didn’t understand my project.

Another term for ‘nuances of the project’ that I think is useful to discuss here is ‘headnotes’. I encountered the word in Heaton’s (2004) discussion of re-using qualitative data for research, and it resonated with me. It covers all the contextual matter in a project – the underlying ideas, the inclinations of the researcher, the half-comprehended impressions and fleeting glimpses that shape how a researcher thinks about her question, methods, data and conclusions. The researcher is the only person who has all those notes, and she is not always fully aware of them. The more she can make the notes explicit, the easier it will be for her to reach clarity in her work, and for others to understand the context of her research.

I suspect that it’s relatively easy for students to show headnotes, and supervisors to respond helpfully to them, in the planning stages. Headnotes there are often linked to the literature read while planning. This was certainly my experience When making presentations to seminars, I said I wished to know ‘who are the voluntarily childless couples in Australia and how do they reach their decision’. It was easy to communicate to Lyn and David some of the impressions, fleeting ideas and understanding behind this. I simply said that I wanted to understand those who chose not to have children in the same way that Lyn had discussed decisions about having children in her book, Having Families. I called my thesis Not Having Families and many of the decisions about what my questions meant and the kind of data I needed flowed from looking at what Lyn had done researching decisions about parenthood. Even where the supervisor’s expertise is not closely linked to the student’s topic, the business of writing submissions for candidature, coursework requirements for methods and completing documents for ethics committees can help surface some headnotes about the outlines of the research. Communication problems seem to arise once there is some data to consider. 

Students seem to me to find it harder to communicate their thinking in the early stages of analysis, and some feel very lost at this point. I didn’t, mainly through luck. Both my supervisors went well beyond the formal requirements for meetings and keeping abreast of my progress. Also, Lyn, then in the early stages of co- developing the software that was a predecessor to NVivo, was very interested in coding. So, on Lyn and David’s insistence, I coded a few of the early interviews and wrote an account of my first ideas showing a lot about the categories I was using.  This helped make clear to all of us some further nuances of my needs as a student, and of my research question.

An example about needs: as they talked with me about the coding of the data from several couples on reasons for not wanting children, Lyn and David agreed with me that I had a lot of data about early experiences. But through looking at the evidence I offered in first analytic notes they saw that I had grossly overestimated the idea that unhappy childhoods led people to decide against becoming parents. The early discussion of my coding taught me that I should approach my qualitative data with a more critical spirit. Whenever I thought I saw a significant trend or theme I should posit the ‘null hypothesis’ that I was wrong and check the data for evidence against my original idea. Only when I had critically examined the possibility that I was in error should I make a statement about what my data showed or meant. Looking at how and what I coded very early on enable me to move from a naive account of the link between childhood experiences and later decisions to a more sophisticated argument.

Not only did looking at my first coding rather than waiting for a draft data chapter help Lyn and David see what I needed to learn about qualitative analysis, it also helped them grasp more headnotes of my research question. As an example, they saw that I had put this comment about reasons for not wanting children under  ‘sacrifice – subcategory freedom and spontaneity’: “we’re the sort of people who are quite liable to make love on the loungeroom floor at midnight… and with kids you don’t do that sort of thing”. I could have started a category ‘sexuality’ and possibly moved my research in a psychoanalytic direction, but it wasn’t in my headnotes to go down this avenue and it showed in my coding, so Lyn and David did not suggest it.

Looking at how very early data sources are coded using coding stripes (as suggested in the slide Supervisors can help surface the headnotes during coding:1) is one easy way for supervisors and students to surface student headnotes at the stage where first encounters with data bring tentative ideas about theory.

Later, looking at the accumulated data in important nodes (as in the slide Supervisors can help surface the headnotes during coding:2) may enable helpful discussion about what nodes mean. Since Lyn, David and I were communicating prior to NVivo (so far back, indeed, that desktop computers were rare items in offices), my ideas about key concepts grew slowly and required a lot of writing and hours of talk. Not many students have supervisors with time to read lots of student writing or to schedule long meetings; many students are also time-poor, so showing the data in a few nodes for discussion is a good shortcut to clearer understanding.

And as coding proceeds, it is useful to check the structure of categories and subcategories for potential insights and links to theory, as well as further headnotes (This is the point in the slide Supervisors can help surface the headnotes during coding:3)

Discussing my early coding helped me refine and organise it so that later interviews were easier to code. And as we talked about my coding, seeing how much of it concerned people’s ideas about how being a parent would demand commitment and sacrifice, because it was about taking on responsibility, Lyn and I got closer to what became the overarching theoretical framework- the notion of ideology. Both Lyn and I were reading feminist literature on the family, and some of that used the concept of ideology. But it wasn’t until I began to see a pattern in my coding of reasons for not wanting children - strong themes around commitment, responsibility and sacrifice - that my study became an account of voluntarily childless couples negotiating with the ideology of parenthood rather than a study of voluntarily childless couples as a subculture or a deviant group.  (Note that student and supervisor need not agree on the framework, only understand why it is being used. David’s theoretical preferences were not towards ideology. So, I had to ensure that my statements about the data and the theory were cogent and convincing)

These days lots of postgraduate projects are heavily constrained in time and the initial literature review and proposal may set the theoretical framework in concrete. This is not always a good thing; if the first foray into data suggests that a new approach is needed, the more help supervisors can give the better for the student. And the supervisor who can look at how data are being handled in the coding stage may be in a stronger position to help.

I think that displaying early coding using NVivo, as suggested in the three slides on coding, is more likely to appeal to time-poor students and supervisors than is writing notes. I was lucky to be writing in my home language and serenely sure that I wasn’t writing ‘the thesis’, only ‘notes for Lyn and David’. I could just bash on and discover what I thought while I wrote it. Students who hate the idea of writing their way to decisions, and supervisors who don’t want to read anything like a draft until the analysis is more or less complete don’t need to. They can use NVivo to catch the headnotes if they look at some of the coding.

As the data from each round of interviews were coded and analysed, I found a useful device for communicating what they meant to me. I would write a description of what I saw in the data, then create a table that had quotations or summaries for each interviewee. Again, Lyn and David could see how my mind was working, could ask the probing questions that made me clarify ideas and provide the evidence base for statements. Many of these tables made it into the thesis with little alteration, so while I was communicating where my thinking was going, I was drafting parts of the key analysis chapters. The slide As analysis proceeds 2 notes how the framework analysis tool in NVivo can be used for a similar purpose. Once again, a supervisor can grasp what the student makes of the data and why, without demanding long written accounts. And creating a framework matrix in NVivo is a lot quicker than scribbling a table on paper, then typing it by hand!

Of course, there were occasions when I wanted to discuss in detail a point about my data. I would write long accounts which my poor supervisors had to read. How much easier it might be to show thoughts using annotations (pop-up footnotes) or by demonstrating how two bits of material (two items of data or a bit of data and something from literature) connected by using a see-also link. These are suggested in As analysis proceeds 1. And the annotations and see-also links could be displayed in the NVivo project or, if the supervisor does not use NVivo, can be exported and printed out with both annotation and see-also’s shown as footnotes.

NVivo offers tools for visual display that would have saved Lyn and David time. I interviewed eleven couples - twenty-two people - in depth and the majority of the couples were interviewed three times. I had no trouble recalling details like who was the librarian married to the academic, and which was the oldest couple. To help Lyn and David and to draft a few pages of the thesis that I knew would stay pretty much unchanged, I wrote short biographies of each couple and Lyn and David had them to refer to if needed. But charts could have done a similar job, required less reading and writing, and saved words in the final document.

I didn’t feel a need to diagram my ideas, not being a very visual learner. But any time I run training, I find some postgraduates who leap with glee on the array of tools for mapping ideas and project items as something they can use both for refining their own thinking and for showing others that thinking. So, the visualising tools also can help students and supervisor. (See the slide At any stage students can make visual displays of ideas.)

As the penultimate slide suggests, there is a trap to using qualitative software. Now that coding is quick and does not occupy physical space, the temptations to code first and think later and to do nothing but code are strong. I think it’s a supervisor’s job to help their student avoid getting stuck in coding and that the best way to do this is to keep talking about the whole project. Understanding how the student is seeing the project is crucial and this is easier when the project is encapsulated in a single NVivo file where coding can be examined as it occurs, and there are many devices for uncovering and displaying patterns in data and evolving ideas. Students can be encouraged to code one part of the data set (as I did with looking at reasons for not having children) then think about what this means for the whole project. (In my case it meant a completely novel set of questions in the final interview round, exploring negotiations with ideology and with people.)

Encouraging writing about ideas (even if it is kept private) in reflective memos or a project diary is another way for supervisors to help students avoid the coding trap. After all, diaries and memos kept in an NVivo project can be text searched later to pull together all the thoughts about a topic. They can even be coded – once it is clear what needs to be pulled out of memos and diaries to be worked on. Then the coded material can be used in a thesis draft.

This has been written as though the supervisor took the initiative, but there are plenty of students whose supervisors need some steering. A student who thought her project would benefit from showing early coding can always ask if at the next meeting she could bring in the NVivo project and show how she has coded the first interview (or if she could drop off a printed interview with coding stripes shown). And as I have noted in places, even the students whose supervisor does not use NVivo can find ways to show aspects of the project. Making headnotes visible might lead to arguments with supervisors about whether your key concept really is useful or whether the data justify its use. But those arguments are fruitful ones, and don’t leave you feeling that you and your supervisor are working on different projects.

Heaton, J (2004) Reworking Qualitative Data. London: SAGE.

Marshall, H. Not Having Children. Melbourne: Oxford University Press.

Richards, L (1978, 1985) Having Families: Marriage, Parenthood and Social Pressure in Australia. Melbourne: Penguin Australia.

Dr Helen Marshall studied sociology and history at Monash University, and worked as a teacher in secondary schools and a post-secondary college before becoming an academic at RMIT University in Melbourne Australia. Her PhD thesis on voluntary childlessness introduced her to qualitative research and to Lyn Richards. That qualitative study, described in ‘Using NVivo to improve supervision’, was published in 1993 as Not Having Children (Oxford University Press). Seeing the evolution of NVivo led to her interest in qualitative research methods that involve using computers in analysis and to teaching qualitative research methods using an early version of NVivo.

After nearly thirty years as a teacher, she moved in 2006 to an associate position in RMIT’s Social and Global Studies Centre where she specialises in providing support to researchers who use NVivo. One project in which she participated is described in ‘Harassment Complaints’ [LINK]. 

She is a certified expert user of NVivo who has worked with the software in projects on coding, teaching sociology and on the postgraduate experience of choosing software. She has taught it to researchers in hospitals, charities and state government commissions as well as in universities and has seen it used in projects from disciplines as diverse as forestry and history. Recently, she has contributed notes on using NVivo to the Better Evaluation website.

Helen also coordinates the Qualitative Interest Group - a network of researchers from many disciplines and several locations who meet monthly at RMIT to discuss research methods.