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.

1. 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.

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’.

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:

1. What are you asking about? It may be people, businesses, schools, what cases do you want to gather material about?
2. 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.

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?

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.

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. 

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.

And all researchers use some sorts of visual tools when they report on their work, to convey patterns or processes and display their results.

There is a wide range of tools to help with these goals. All qualitative software provides some of these tools, and other software products complement these with displays that are usually slicker and sometimes quicker. Go to Data Visualization to read about the options in qualitative software and explore data displays elsewhere. 

With qualitative software, modelling can often do more than display what you have discovered. 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.

At this step, the most useful way to explore the software is to use it to sketch what you are asking and what you think is going on in the situation to be studied. Can the software provide a diagram that’s more useful than one you scribble on paper?

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.

As the project grows, how will the software help you keep an overview? More diagrams and models to explore.

And how will it help you seek and explain patterns? Think matrix. 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. Now make the matrix work for you, showing a pattern and taking you back to the data.

Research reports vary from scribbled notes to impressive presentations. If you are just stepping in to software, you are probably making more of the former than the latter. But you will need many different ways of making reports, and it helps to find out early how to do this.

Think into the future of this project. At the simplest level, you will want access to all those data records in your software, to get data out of the qualitative software and into all the different ways you communicate, from emails to formal presentations.  Can you copy  data into word processors or other software for papers or presentation? Can you find how to get editable reports of all the material you might want for a paper? 

Telling it to your supervisor outlines how to use reports on your coding categories in communicating your research to others, especially supervisors.

From early in the project, you will also want not only to export text reports but to show the project as it develops. Now, thinking ahead, explore your software to see how you might use it to display what you are doing and what you are finding. Every software product for qualitative research offers some forms of display.  Go to the Data Visualization to read about the options.  

What needs to be done now?

List any 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! Go to Chapter 10 of Handling Qualitative Data  for the tasks of getting together all that writing and to Chapter 11 for bringing it together in a full report.

Now to get a handle on the ways your software can provide displays for illustrating reports, explaining patterns and impressing audiences. These are tools to be used from the start of your project. (Go to the Data Visualization to read about the options.)

The final chapter in Handling Qualitative Data (Chapter 12) gives you a feel for the range of presentations and reports you may be providing, to all the different audiences eager to know what you achieved, at every stage, and particularly at the glorious end of your project.