Author
Lyn Richards

Pub Date: 11/2009
Pages: 256

Click here for more information.
Lyn Richards
Stepping into software
In this section, I've provided a fairly straightforward pathway into software use via a set of suggested steps, with a bundle of hints about how to 'think first' before you take the next step in software.

Qualitative research notoriously lacks a clear and fixed order of research processes. So of course does the use of qualitative software. In your project, it's quite likely to make sense to do things in a different order from the order in the chapters of Handling Qualitative Data. Please don't assume that there is any superior method in that order. Click on any of these steps to hop directly there.

Step 1: Start your project
Step 2: Getting your data 'in'
Step 3: Storing information and characteristics of informants
Step 4: Edit and Link - to store what you see
Step 5: Start Coding and Use coding
Step 6: Make and manage the categories you need
Step 7: Say it in a diagram
Step 8: Ask questions about your data
Step 9: Showing patterns
Step 10: Out of software and into reports

Step 1: Start your project
To work in any software package, you create a container that will hold all the necessary items (data records, ideas, information about respondents etc.)

What to ask about your project?
Two questions arise at this first stage:

1. What structure should your project have?

Think about access. If you are a sole researcher working on your own computer, the simple process of setting up a project will work for you. But if you are working in a team, and they will all access this project, so you might want to set different access for members.

Think about your research design, and ways to implement it clearly in your project by identifying project parts for different purposes.

2. Can your research be contained in one project?

Think about the research sites or stages in your design. Does your software allow you to identify these separately?

In a multi-site or team research project, it may be simplest to set up a project for each researcher. If your design requires multiple projects, find how to set them up in the software to make them comparable. Check if you'll be able to combine these projects later.

What needs to be done now?

  • Create a first project! If you want different access for team members, set it up appropriately.
  • Get into your empty project, and take charge. Get comfortable with the software's navigation process and play around to customize appearance.
  • Find something you couldn't have done (or wouldn't have bothered to try to do) without software. (Very motivating!) For example, can you find all the passages where a particular person was mentioned?
  • Learn how to save your precious work - before you put in data - and how to ensure it's safe.
  • Find and learn to use your software's online Help and use it regularly
  • Learn and USE the techniques for saving, closing and backing up the project.
Warning: Backup often and carefully, keeping a record of backups. A horrible proportion of researcher disasters could have been merely good stories had there been a recent backup. Note: a copy of your project on the same hard disk is not a backup! The hard disk is the most likely source of a problem - and it will take the project and the backup down with it.

Step 2: Getting your data 'in'
Most researchers start a project with records of "real" data (interviews, field notes etc.). Actually, that's almost always not the best way to start, since you've done a lot of work before those first records are made, and that earlier work may be wasted if it is not available for analysis in your software.

What to ask about your project?
The questions now are:

  • For your project, what will be the data records? Interviews? Notes? Tapes? What's data and what's not?
  • Where and when can you start with data? (What will be your first data records?)
  • How varied will your data be, and what sorts of data will you want to distinguish? (Interviews and focus groups?) Think variety of data sources. Check that your software will handle each sort. And how will you differentiate them?
  • How structured or free-form are these records going to be and how will you handle their management?
What needs to be done now?
Consider the variety of data sources for this project. Most qualitative projects have varied data, and if they don't, they could be improved by variety. Don't ignore sources that sound unimpressive. In qualitative research, every observation is possibly data - at least until you know it's not relevant. Your first understanding of a problem or impressions of the field are data, memos are data, your literature review is data, your research design or grant proposal are data, as is your desperate letter to your supervisor about what's going wrong.
  • A good start is to make a table with the first column listing data records you already have or intend to make. In the next column, note how each will be stored for your project. Will it be imported into your software project? If not, where?
  • Think content - how to ensure that the data in the project are as rich as possible. In your table, add a third column, with notes about what you need to do to your records for good data preparation. You may wish to add further columns for the following points.
  • Think context: what sorts of questions are you going to want to ask of your data sources? Are they comparative questions? Are they questions about context? Ensure you are storing the relevant information about a record, and not losing detail you'll need later.
  • Think formatting: is there is a consistent structure in any of these records, (e.g. questions always asked in an interview, or speakers contributing in a focus group)? If so, you may be able to gather the relevant data (all the answers to a question, or everything this person said) by using functions in your software for 'autocoding'.
Step 3: Storing information and characteristics of informants
So far, the data for your project may still look shapeless, imported or created in individual data records. The next step is to think about useful shapes for your purpose. Start with asking what you have other information about? Institutions? Individuals? School classes?

What to ask about your project?

  • In any study, your research design will give you the answer to: what is a case?. The case is the object of your focus. You'll want to gather together all important material about each case. Find out how your software handles this stuff. Qualitative research is usually about cases - and draws on what's known about those cases. Most researchers wish to store information about people, sites, events, and other phenomena - social science usually refers to these as cases - to inform the questions they ask about their qualitative data. How will you store that so you can use it later?
  • What other ways would you like to gather data together? Cases are just one way, and you will need others. What sorts of comparisons will you want to do? Between schools, not just classes? Or comparing political groupings, not just individual politicians? What shapes of the data will you want to focus on?
What needs to be done now?
  • Decide what are the cases for your study. Two questions are relevant.
    • Firstly, what are you asking about? It may be people, businesses, schools, what cases do you want to gather material about?
    • Secondly, what do you want to store information about? It may be demographics of interviewees, business profile data, school characteristics.
  • Decide what information you will have about the characteristics of cases in your study, and importantly, how much of that information will be needed for your qualitative analysis.
  • Decide on other groupings of data that would be usefully held and find a way to group your data records.
  • If you are planning on combining quantitative and qualitative data, find out now how the quantitative program you are using can exchange data with your qualitative program. Most can.
Warning: software has huge capacity for information and your brain doesn't. So consider carefully what information will be needed and don't overload your brain by loading in irrelevant detail.

Step 4: Edit and Link - to store what you see
If you've been following the steps in order, this is an exciting first stage when your own project is coming alive. The goal wasn't just getting data into a program, but using that program to get somewhere else.

What to ask about your project?

  • Does your research design anticipate that the data sources will be unchanged during your project? If not, how can you use editing and annotating to record your growing understanding of them?
  • What are you aiming for and how will you get there? How will you store your own ideas and (changing) interpretations, and the story of your analysis? This may be the most important early decision. You need now an easy and reliable way of keeping and logging the growth of your ideas and insights, about sources, concepts and theories of what's going on in the data. Can this information be kept in your software's project database?
  • Will the data sources be interconnected? If so, how will you record those connections? Qualitative research projects normally have connected data - that is each data record won't be handled as a unique item. As you see connections, they should be recorded - this is a task that shouldn't be put off; next time, you might not see the connection. Is your software any good at tracking connections?
What needs to be done now?
If you don't have training in qualitative research, this is the stage where you are most at danger of just doing what software will do, rather than making it do what your method requires. Editing, annotating, linking are all ways of drawing the webs of ideas and interpretation from which you'll create your conclusion. So don't rush past this stage. Here's where you start getting "up" from the data to interpretation. So this is also the stage at which you should start a quiet process of recording your journey, what you saw, where it sent you, why you altered your interpretation, how you became confident you were understanding.
  • Get familiar with the editor in your software, so you can easily create, alter or annotate a data record - including a memo.
  • Design and record the system you are going to use to log your project and ensure that ideas don't get wasted. This also should go into your project database.
  • Optionally, try drawing a first model of what you are seeing in the field and expect to find in the data. Store it - to meet later. Can your software help you draw useful models?
Step 5: Start Coding and Use coding
Qualitative coding gathers all the material about a topic or category so you can read, assess and use it. When you code in software, one way or another, it places pointers to the extracts you select to be coded. So you can do as much coding, at as many categories, as you wish.

Warning: Coding can be a serious trap if it is not done purposively. If you are not familiar with qualitative coding, first find what role coding should have in your project.

What to ask about your project?
Before you start coding, ask what coding your project needs:

  • Do you need to code your data? If so, why? What do you want to achieve by coding? Coding must be purposive, never just a ritual.
  • Do you need to code all or only some data? If only some, which? Can some be just broadly categorized, so you can later return to explore finer meanings?
  • Where will the categories for thinking about your research come from? Do you aim to discover categories from the data? If so, how will you do this?
  • Will you be doing the coding yourself, or giving the task to others?
  • Can some of your coding be done automatically by your software?
What needs to be done now?
  • Clearly establish whether you are planning coding and if so, the purpose of coding in your project - and write about it, in your research design.
  • Make a record (on paper, a white board or in a word processor or qualitative software) of any categories you know you will need to code at. Having this record will help later as you assess how your ideas changed.
  • If you are not the only coder, discuss with your colleagues how you will ensure that you communicate on category creation and coding style.
  • If you have some structure to your data that enables autocoding, set in place processes to ensure that documents are consistently formatted.
Warning: Start coding as soon as you have data to code. For qualitative work, delaying coding can be seriously problematic. The data records build up, and the task looks more formidable as each is added. Not only is it harder to get started, but your codes don't grow with the data coming in, and the coding can't inform what you do next. When you do start, what should be a very reflective process presents as a bulk job. Coding becomes more like data disposal than data interpretation.

Step 6: Make and manage the categories you need
Here is a step that many researchers may want to avoid, seeing management of ideas as inimical to creativity. My experience is that the opposite is the case - creativity turns out to require organisation. As I argue in Chapter 6 of Handling Qualitative Data, a major risk stage of qualitative research is when categories proliferate and researchers start losing them, finding them unevenly, or worst, get overwhelmed by their complexity.
All software has some way of holding categories, and most software offers ways of managing them so you will know where they are and use them consistently. A management system will help you discover patterns and clusters of ideas, as well as see those that are missing.
Managing the categories is a first step to managing the coding that gathers data about an idea. So your project's backbone will be its categories. If a colleague looks at your project, they should be able to 'read' the categories created to tell what you are studying and asking and finding out.

What to ask about your project?
You can create categories both in advance of coding and as a result of coding. This is usual - most projects will have some categories when they start, "down" from prior knowledge or theory, and will create many "up" from the data. Now the question is, can they be brought together? And then, as the categories proliferate, the question will be, can they be organized logically?

What needs to be done now?
It depends on your method. The shape of a useful catalog of your ideas emerges in very different ways from projects using different methods. If you are starting without any idea of prior categories, don't worry - let them happen, and then catch and shape them.

  • From your literature review and project design, sketch the beginning of a catalog of the topics you will need to cover in this project. A simple start is to tell a friend about your project and get them to make such a sketch.
  • Do some ordering of prior categories. At Step 5 I suggested that you make a record (on paper, a white board or in a word processor or software) of any categories you know you need to code at. Examine that list, shape it into a catalog. Do some represent the same sort of categories as others? ("Mother", "teacher" and "policeman" are all sorts of people; "altruism", "travel" and "social contacts" may all be sorts of reasons for volunteering.)
  • Now, visit the categories you created in Step 5, and see if they are showing that some are "sorts of" a more general category. Don't ever force it. If a category doesn't logically belong with others in a tree structure, don't shove it in somewhere. Keep a place for free floating ideas, and go visit them from time to time to see what's gathering there.
  • And finally, sketch any relationships between your categories - relationships you are expecting to find or ones appearing in the data. (As before, use paper, white board, a word processor or software). These sketches of catalogs and relationships should start to look like a picture of your growing project.
Step 7: Say it in a diagram
Some qualitative researchers rely significantly on diagrams or models to express and visualize what they are seeing in their data, and the theories they are developing. Others just doodle when they are trying to make sense of things. With software, modelling can do more, since the software can also show you associations that you might not have seen for yourself. Software products differ greatly in the ways they support visualisation and the usefulness of the tools. Don't feel you should use your qualitative software's model offering if it constrains you - that's probably because it is a pretty primitive tool! Use more sophisticated modelling software, or simply paper.
Some researchers don't use a modelling tool. As with all software tools, it is important not to feel you should use it because it's there. But take the time now to assess what may be a very new addition to your methods techniques.

What to ask about your project?

  • Would you be helped by visual representations of your work? Explore the possible uses of models for your analysis processes. Check your process for logging the project: would models assist clarity of record of where you get to at each stage?
  • Are you working in a team, and needing ways to show and compare your work? Try drawing on paper flip charts, during one team session. Now transfer the pictures of the different projects to online models, and discuss how you can use the live-to-data modeling.
What needs to be done now?
Nothing has to be done to prepare for visual presentations. Play. You can use models at any stage.
But if you expect to use them, learn the basics now so you can use them early, and keep a record of the stages of your project. Assess carefully when you get analytic or presentation advantage from modeling, and concentrate your skills on developing these sorts of models.

Warning: Perhaps more than any software tool for qualitative analysts, modelling can become a means of avoiding analysis! If you find you're spending too much time colouring and moving items around, test the power of your model. A very good test is to ask a colleague to read it to you - what is it telling you? Was this something you did not know before, perhaps, even, something already recorded in a memo?

Step 8: Ask questions about your data
So far, most of the tasks were not unlike tasks we at least attempted without software - storing data records and information, linking and coding them and managing our ideas and drawing diagrams. Software allows you to do much more in each of these areas, searches of either the text of your data records or of your own (or the software's) coding of those records. Most software will combine these very different functions so you can ask very subtle questions you couldn't have asked before - ('give me what the women said on this topic'.).

This step is the first where most obviously you are using techniques not possible by manual methods. Software offers entirely new ways of asking questions about your project. These are highly useful and a breakthrough for much qualitative research, but also highly dangerous if used carelessly, and very seductive! (Go to Chapter 8 of Handling Qualitative Data for warnings about searches of text and coding.)
Start out by getting to know these tools as means of access to data from the beginning of a project, and start using them early - they bring you much closer to your data and allow you to search more rigorously and conclude more confidently.

What to ask about your project?
These tools are for most questions you want to ask about! You will need and use them - they are appropriate for any type of project.
Try the tools out by asking questions that are troubling or interesting you. (Who has these concerns? Are management and staff ideas really different? Is this word really a 'theme' of the data or did I invent that?)

What needs to be done now?

  • Start using search tools as soon as there are any project items to look for - whenever you wonder what's there, or want to check a hunch.
  • Get in the habit of searching to check the content of your data records. (Was this really a pervasive theme or did I just keep noticing it?) Use text searches from the start of your project, simply to check whether anyone else uses this word, or who mentioned this person.
Warning: Qualitative researchers question data throughout the project. Don't relegate searches to the end of the project, as hypothesis testers, or conclusion justifiers.

Step 9: Showing patterns
Tables are a very familiar way of showing the relation of one lot of features to another. We use cross-tabulations to show patterns of numbers. And tables of results to show patterns of products or student grades. But qualitative tables are different - you want not just to see how many people talked about this topic, but what they said. Most modern qualitative software can do that - and researchers can do a lot more with the data as a result.

What to ask about your project?
Think tables. Don't assume that tables are for surveys, rather than qualitative work. Much of your work may be seeking and exploring patterns. Frame a question for your project that would be well answered in a table. For example, you may be looking for a pattern of how people's ideas about one issue differ according to their attitude on another, or how the values of a characteristic like gender might pattern responses to a question.

What needs to be done now?
Start asking exploratory questions that might help you shape your data. Such questions as 'Does everybody say this or only some - if so, which respondents?' It's a very new ability to ask software to check out whether there's a pattern here that you might have missed. Exploit it and feed it with challenges to too-easy conclusions. ('Hold on, do we have any younger women in this group?') Your analysis will be far more robust for such questioning.

Step 10: Out of software and into reports
The project has begun, and your final report is not on the horizon. But you have completed the first major stage of getting up in software. And from now, you will need to know how to get data "out" of your project for papers and presentations.

What to ask about your project?
Research reports vary from scribbled notes to impressive presentations. At this stage, you are probably making more of the former than the latter. But you will need many different ways of making reports, showing patterns, illustrating conclusions, copying data into word processors or other software for papers or presentation.

What needs to be done now?
It may assist to make a list of the different questions you have about getting data out. Then check the reporting tools to find how to do these tasks. The goal is to ensure that you can at any stage very easily provide the evidence or output required to present your work. Good specialist software will provide you with editable reports from which you can write early drafts and preliminary reports. Don't wait till the final deadline to learn how to do this! And go back to Chapter 10 of Handling Qualitative Data to help you use the software to provide the best possible account of your wonderful project!