Friese S. Qualitative Data Analysis with ATLAS.ti 3ed 2019

216 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI Modifying an existing relation • Activate one of the entries in the Relations Editor and customize the relation according to your preferences. • For example, edit the relation ‘is associated with’. Change the width of the line and select a different color. • If you want to change the short name or the symbolic name, right-click and select Rename. • After changing some properties, return to your network and link two codes using the ‘is associated with’ relation and see what it looks like. Creating a new relation Let’s create the relation is reason for: • In the Relations Editor ribbon, select the button New Relation. • Enter a name and, optionally, a short and a symbolic name. Click Create. • Select the new relation in the editor and set the properties: • Figure 7.27 Setting relation properties The preferred layout directions only affect the automatic layout algorithm when opening an ad hoc network on an entity. When you do this, you either want to quickly see what is associated with an entity (then the layout is not particularly interesting) or you want to continue working on the ad hoc network, then you either reposition the nodes manually or you use one of the layout options. Therefore, it is not very important to define your preferred layout direction. I usually ignore this option. ON THE USE OF NETWORKS FOR STRUCTURAL PURPOSES After Skills training 5.3, I wrote about the advantages of a well-sorted and structured code list and presented my own dissertation research as an example of how not to do it. Instead

RECOGNIZING AND VISUALIZING RELATIONSHIPS – WORKING WITH NETWORKS 217 of utilizing the Code Manager, I used the network function to put some order into my thoughts. The danger of this is that the code system remains messy. The brainwork is done, but one forfeits transparency. The code list is difficult to handle, remains incomprehensible to an outsider and the different levels of analysis get mixed up. If you use the Code Manager to represent the various levels of your codes instead, the network function is still at your disposal for higher-order conceptual-level analysis. Most packages I know of offer a tree structure for the code list. Thus, you can immediately sort codes into higher- and lower-order categories in the tree. I recommend starting out with a flat code list unless you use a deductive approach to coding. Just by being able to create a tree, it’s tempting to sort the codes into sub trees right from the start. According to Guest et al. (2012: 72), ‘Hierarchical relationships are probably the most common but are not necessarily the best organizational choice for all the elements in a codebook.’ They only work well if codes can be clearly distinguished in several levels of detail (see also Bazeley, 2007; Richards, 2009; Richards and Richards, 1995). With a few exceptions, most qualitative data analysis codes are best summarized in a flat structure as items that are similar or belong together. To appear together in an alphabetical code list, as in ATLAS.ti, codes must begin with a prefix as described. You can use the network function to link higher- and lower-order categories in a hierarchical manner. To get a strictly hierarchical view, you may only use transitive relationships. If you link two codes using a symmetric (undirected) relation, then the codes point reciprocally to each other. If you do so, you can see the hierarchical structure in the Code Forest (Figure 7.28). • To open the Code Forest, click on the Navigator button in the Home ribbon and select Code Forest from the drop-down menu.

218 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI Figure 7.28 Displaying categories in the form of hierarchical trees What you represent with such a structure is first-phase descriptive analysis. The conceptual analysis of the second phase is about linking data across categories (Figure 7.29). This can be achieved by approaching the data with research questions in mind. See Skills training 5.7. Figure 7.29 Linking across categories The aim of using networks for conceptual-level analysis is to illustrate the answers to research questions instead of just displaying the categories. Such networks are likely to contain subcategories of a variety of categories but only those that are relevant in the context of the research question. For a cleaner methodological approach, I suggest that you define and visualize higher- and lower-order codes in the Code Manager as explained – using

RECOGNIZING AND VISUALIZING RELATIONSHIPS – WORKING WITH NETWORKS 219 capital and lower-case letters and prefixes – and reserve the network function for advanced conceptual-level work, when you begin to find relations between codes and across categories. I have shown a few conceptual-level networks as examples at the beginning of this chapter. DEALING WITH CASE-BASED NETWORKS When you link two codes to each other in one network, the link is not just a private link for this one view. It is used for these two codes in the entire project. Thus, if you pull the two codes into another network, the link between these codes immediately becomes visible. But what if you want to link Code A with Code B using the relation ‘is a consequence of’ in a network for Paul, but need to use the label ‘is a prerequisite of’ in the network for Mary? The solution is to add more information to the network. If A is a consequence of B for Paul, there is probably a reason for this that you know from reading the data. If A is a prerequisite for B in the case of Mary, there are likely to be circumstances that explain this relation, too. This information is what you need to add to the network. Thus, it becomes even more meaningful. Figure 7.30 Using abstract codes to express what is going on in your data

220 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI If the reason that applies to Paul and the circumstances relevant to Mary are not yet covered by existing codes, you need to create them. These codes, then, will not contain data; you use them as modifiers to show the kinds of relations that exist in your data. The term for such codes in ATLAS.ti is abstract codes. The frequency is zero and the density is at least one or higher. Creating abstract codes occurs quite regularly when creating networks. You often need to add codes at this stage to let the network visualize the story you want to tell. Codes have the advantage over memos that you can link them via first-class (i.e. named) relations. The network in Figure 7.30 contains one abstract code: ‘comments on blogs’. It stands for a document group. If you go back and review Figure 7.11, it shows the same codes linked to the data sources D3 and D5. Links between documents and codes are, however, second-class and cannot be named. By creating a code node of documents 3 and 5 representing all blog comments, the various emphases that are put on the various sources of happiness can be expressed via the relation names and the width of the lines. HYPERLINKS IN ATLAS.TI As explained above, hyperlinks are relations between quotations. You can create hyperlinks in networks by applying the various techniques as shown for code–code relations. The practice of using hyperlinks, however, is different. Therefore, I have added a further section to this chapter specifically on hyperlinks. I will provide some examples on how to use hyperlinks and show an alternative way of creating them which stays closer to the data than using networks. Examples of using hyperlinks Linking repeated occurrences of the same idea Sometimes an idea or subject is repeated again and again without adding further information. If you code each instance, then the frequency of the code goes up, distorting the code frequency count. The solution is to code only the first segment and connect the repetitive segments via hyperlinks. Linking different aspects within a document Take, for instance, an interview situation. The interviewee tells you something and then halfway through the interview tells you the exact opposite. To easily access the contradictory information, you can link the statements via a hyperlink. Another common issue in interviews is that people don’t always stick to chronological order. Hyperlinks can be used to add a chronological structure to an anecdote or statement. While involved in telling a story, perhaps your interviewee does not start at the beginning of events but fills in important details later. If this makes it difficult to understand the logic

RECOGNIZING AND VISUALIZING RELATIONSHIPS – WORKING WITH NETWORKS 221 of the argument, one option is to code the section that marks the beginning of the train of thought and link the rest of it via hyperlinks. As shown in Figure 7.32, hyperlinks can also be used to link various statements that build on each other and that are typical of a particular speaker or illustrate an important line of reasoning. Linking across documents Linking across documents is likely to occur when you have several documents on one case or when using different media types as your document. Pictures, for example, can be used to break the ice at the start of an interview. Another data-collection procedure may require people to provide visual material themselves, and the interview is set up to talk about this material. Drawing diagrams or concept maps can be used as a way of summarizing the main aspects of an interview in agreement with the interviewee. This results in data that contain images as well as the discussion of these images. Hyperlinks can be used to link the verbal and the pictorial aspects of the data. Furthermore, when working with geo data you may want to create links between a geo quotation and a data segment in a transcript where a person talks about this location. SKILLS TRAINING 7.5 WORKING WITH HYPERLINKS When linking quotations, you begin by setting one quotation as the source link. Then you select a second quotation as the target. As you continue to link more quotations, you can create a star or a chain. Creating a star means using the same quotation as the source and linking more target quotations to it. Figure 7.31 Star hyperlink structures

222 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI Creating a chain means beginning with one quotation as the source and selecting a quotation as the target; this quotation then becomes the source and you select a new quotation as the target. This is illustrated in Figure 7.32. Figure 7.32 Chain hyperlink structures You already know how to link quotations within a network as shown above. Below, I would like to show you how to create hyperlinks while staying close to the data level. Let’s try this out using text data. Later, you can apply your skills to different types of media. Linking quotations • Select a data segment that already is a quotation (e.g. by clicking on a code in the margin area). Right-click on the highlighted segment. • Select the option Create Link Source from the context menu. ATLAS.ti marks this quotation as the start anchor. Figure 7.33 Starting to create a hyperlink by setting the link source • Select a second quotation as the target. Right-click and select the option Create Link Target. • A selection of relations will open in a new window. Select one of the relations with a left-click.

RECOGNIZING AND VISUALIZING RELATIONSHIPS – WORKING WITH NETWORKS 223 Figure 7.34 Select a link target and a relation to create the hyperlink The newly created hyperlink is displayed in the margin area. In the Quotation Manager you can see before each linked quotation a sign that indicates whether it is a source or target quotation or both (applies only to the Windows version: see Table 7.1). Figure 7.35 Display of hyperlinks in the margin Table 7.1 Explanation of signs in the Quotation Manager Sign Explanation ~ Quotation has a comment < Quotation is source of a hyperlink > Quotation is target of a hyperlink <> Quotation is both start and target – thus, at least two other quotations are linked Linking across tab groups • Load two documents side by side (see Skills training 2.6).

224 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI • Left-click on a quotation bar in the document on the right-hand side, drag the mouse to a quotation bar in the document on the left-hand side (or vice versa), release the left mouse button and select a relation (see Figure 7.36). Figure 7.36 Linking across tab groups Browsing hyperlinks • You can display the contents of a hyperlinked quotation by double-clicking on the hyperlink icon in the margin area. If the quotation is linked to a text quotation, the content of this quotation is shown; if it is linked to a video or audio quotation, the linked quotation is played. • If you want to see the hyperlinked quotation in context, click Go to Quotation. Figure 7.37 View or visit hyperlinked quotations

RECOGNIZING AND VISUALIZING RELATIONSHIPS – WORKING WITH NETWORKS 225 Figure 7.38 Example of a multimedia hyperlink Visualizing hyperlinks • Right-click on a hyperlink and select the option Open Network. The network displays all quotations that are immediately linked and all other neighbors like documents, codes or memos (see Figure 7.39). If you have created a chain, then it is possible to expand the network to show it all: • Right click on a hyperlink node in the network and select the option Add Neighbors / Quotations. Figure 7.39 Ad hoc network on a hyperlinked quotation

226 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI OVERVIEW OF ALL CODE–CODE LINKS AND HYPERLINKS You can get an overview of all created first-class linkages in the Links Manager (Figure 7.40). • To open the Links Manager, select the Home ribbon. Click on the Links button and select Links from the drop-down menu. In the managers, you can search for relations, sort them by the column headers, access them in context, open links in networks, and modify, delete and comment links. Filter settings also apply. This allows you for instance to query the relations of just a set of documents, or for a set of codes. Figure 7.40 Link Manager for hyperlinks REVIEW QUESTIONS 1 What are networks? 2 What can you do with networks? 3 Which entities can be contained in networks? 4 What is meant by first- and second-class relations? 5 Which entities can be linked via first- and second-class relations?

RECOGNIZING AND VISUALIZING RELATIONSHIPS – WORKING WITH NETWORKS 227 6 How can you modify existing relations or create new relations? 7 Think of a suitable way to make use of the three alternative link labels. 8 How can you save a network and when do you need to do so? 9 How can you export networks? 10 In what way and for what analytic purpose can you use the network function? 11 Why should networks not be used for organizing your codes into higher- and lower-order codes? 12 Explain the Code Forest and why it cannot be used in the same way as a hierarchical tree display of codes. 13 What are hyperlinks? 14 How could you use hyperlinks in your own project to enhance data analysis? 15 What are the steps involved in creating hyperlinks? 16 How can you recognize hyperlinks in the margin area and the Quotation Manager? 17 How can you browse hyperlinks? 18 Where can you see and edit all created first-class linkages? FURTHER READING Attride-Stirling, Jennifer (2001). Thematic networks: an analytic tool for qualitative research. Qualitative Research, 1(3), 385–405. Bazeley, Pat (2013). Qualitative Data Analysis: Practical Strategies, chapter 10. London: Sage. Miles, Matthew B., Huberman, A. Michael and Saldaña, Johnny (2014). Qualitative Data Analysis, 3rd edn, chapter 5. Thousand Oaks, CA: Sage. Novak, Josef D. and Cañas, Alberto J. (2006). The theory underlying concept maps and how to construct and use them. Institute for Human and Machine Cognition, http:// en.wikipedia.org/wiki/Concept_map. Silver, Christina and Lewins, Ann (2014). Using Software in Qualitative Research: A Step-by-step Guide, 2nd edn, chapter 10. London: Sage. Slone, Debra J. (2009). Visualizing qualitative information. The Qualitative Report, 14(3), 488–97, www.nova.edu/ssss/QR/QR14-3/slone.pdf.

Compiling the final report – the last phase of the writing process 8 I always find it very exciting to start a project – collecting data, visiting different places, talking to people, observing, taking notes and pictures, recording audio and video data and reading about the topic. Of course, after collecting some data, I am curious to take a closer look and begin the analytic process. The development of the coding system gives you the first exciting insights. This can get boring at times when applying the codes to the entire data set. But once that’s done, another interesting phase follows. Based on the coding, the document groups and the links I created in the first phase of the analysis, I can query the data in various ways and ask all sorts of questions. After finding answers and seeing how everything fits together and how the story unfolds, sometimes I find it hard to sit down and summarize everything in a formal report. Does this sound familiar to you? However, the step from your analysis in ATLAS.ti to a written report is not very large if you have followed the suggestions I have given in the various chapters throughout the book. Writing was an integral part of your previous analytical journey. Many insights that you have gained from and about your data have happened while writing comments and memos. Your ATLAS.ti project already contains many elements that you need for a formal report. You can start with the text that is already there in ATLAS.ti. The task that remains is to weave it all together to form a coherent report. When preparing your project and report in this way, the little extra on top is that a third person can trace your analysis; your ATLAS.ti project is the audio trail. The proof is not

COMPILING THE FINAL REPORT – THE LAST PHASE OF THE WRITING PROCESS 229 only in the pudding (your writing). Properly used, software like ATLAS.ti also improves the validity of your research. LEARNING OBJECTIVES When revising the book for the third edition, I was asked to expand the chapter on writing the research report. As other authors have already written, when analyzing qualitative data, writing is part of the analysis process. This is different from studies based on quantitative data. There, writing the research report is a separate step that follows data collection and data analysis. So, if you’re reading this chapter, you have already written up a lot. Now it’s just about putting everything together. Therefore, this chapter is more about retrieving the information relevant to your report from your ATLAS.ti project. Furthermore, I give some recommendations and examples of where in your report you can use which information. SKILLS TRAININGS Skills training 8.1: exporting memos for reports Skills training 8.2: how to quote data segments in reports Skills training 8.3: exporting networks for reports Skills training 8.4: creating a code book Skills training 8.5: exporting the document with codes in the margin CONTENTS FOR THE METHOD CHAPTER Look at the list of documents in the Document Manager and the document groups. The document comments may contain the interview protocols, information on how you have generated the data or case summaries. This will help you to describe your sampling and will remind you of the data-collection phase. An example is shown in Figure 8.1 based on a study by Friese et al. (2018). The document groups show the five geographic regions where the data was collected and the characteristics of the participants: gender, age, type of profession, education level, professional experience, experience, working hours and type of contract. Next, look at your coding system and describe how you have developed it. Rereading your research diary will help you to remember what you did and how it evolved. If you have saved project bundle files at various stages of your project as indicated throughout the book, you should have:

230 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI Figure 8.1 Illustrating sampling based on information in the Document Manager • a version of your project with the initial coding; • a version that shows the results of your first sorting and organizing efforts; • a third version that shows how you have adjusted the first coding schema after you have applied it; • a fourth version after you have coded all data; • a final version after you completed your analysis. The final version may contain some smart codes and smart groups that you needed for the analysis, additional groups as filters, some new codes as you needed them in networks to visualize the stories that you wanted to tell about your data and, of course, some networks and your analytic memos. Keeping the various versions of your project will help you to describe the development of your project over time. You may, for instance, choose one important category and describe it in detail, including the subcategories and how you have built it up. Here is an example from my grounded theory sample project adapted from Friese (2016b): Before I proceeded with the detailed analysis of the data by axial coding, I tagged interviews two and three. The resulting changes to the code list are shown in Figure 8.2, which illustrates the development of the category ‘dealing with’. The first two lists expand and clarify the open coding process according to Corbin and Strauss (2008). After coding the third interview I introduced a temporal dimension: after and during/after. The temporal dimension indicates when one of the strategies to deal with the war experience was used . Further, I noticed that ‘fade out’ and ‘close out’ were used in different ways by the respondents. So, I split the code. The third list shows the codes after the process of integrating data. You can see that some of the subcategories have been moved elsewhere, as two new categories were developed: ‘Barriers (for homecoming)’ and ‘Aiding (homecoming)’. ‘Dealing with: active’ was moved to the Aiding category and ‘Dealing with: Alcohol’ to the new Barriers category.

COMPILING THE FINAL REPORT – THE LAST PHASE OF THE WRITING PROCESS 231 Figure 8.2 Ongoing changes in building the category DEALING WITH. In the last part of the method section you can describe how you have approached phase 2 of the analysis. This can be done by explaining how you have set up your research-question memos and how quotes from the data are referenced. You may end the chapter with a list of research questions that you are going to answer in the results chapter. It might be interesting to compare this list with the initial list of questions in the project memo. This allows you to see whether it was possible to stay with your original ideas or whether the insights you gained through the process of coding and writing about your data moved your research in a different direction. CONTENTS FOR THE RESULT CHAPTER You can put together the contents for your result chapter from the research-question memos. They contain everything you need: the research question, a description of the query, your summary and interpretation and some quotations that you can use to illustrate your arguments. In the next skills training, you learn how to export your research-question memos, including all linked quotations, so you can use them as building blocks for your report.

232 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI SKILLS TRAINING 8.1 EXPORTING MEMOS FOR REPORTS • If you’re working with the coded version of the sample project from Chapter 2, open the Memo Manager and select the memo ‘RQ1: Effects of parenting’. • Select the Report button in the ribbon. Figure 8.3 Preparing memo output • As options for the report select Content. This is the content of the memo. If you have written a comment for the memo, you can include it in the report, too. Next, select Quotations / Content to export all linked quotations. Add comments if you know that many of your quotations also have comments. • Click on the Create Report button. The report opens in an editor. You can copy and paste the content from there into your Word document or you save it as file first. The memo output includes all the information you need as input for your report (Figure 8.3). It also adds transparency to your analysis. If someone who reads your report asks how you derived your results, you can show your research-question memos. If necessary, you can rerun the query. All linked quotations are listed below the memo content and include meta information like ID, document name and start and end positions. While turning your thoughts and ideas into a more formal writing style for your report, you can select supporting quotations and insert them where fitting. In the next skills training, you learn how you can quote ATLAS.ti quotations in reports.

COMPILING THE FINAL REPORT – THE LAST PHASE OF THE WRITING PROCESS 233 Figure 8.4 Research-question memo as building block for a research report SKILLS TRAINING 8.2 HOW TO QUOTE DATA SEGMENTS IN REPORTS I am often asked how to reference a quotation from an ATLAS.ti project. My suggestion is to use the document number that is indicated by the quotation ID plus the location, i.e. the start and end position. The following is a section from document 3, beginning and ending in paragraph 81. You must also explain this once in your report – for example, in the method section – so that the readers of the report know what the reference means. How about measuring a sense of purpose and fulfillment? Maybe the results would be different. Parenting is the most challenging and rewarding job there is. (D3, 81:81)

234 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI If you want or need to make your coded data accessible for viewing, You can create PDF files of all encoded documents with margin area in which the codes, hyperlinks, memos, etc. are displayed. These are contents for the appendix. See Skills training 8.5. SKILLS TRAINING 8.3 EXPORTING NETWORKS FOR REPORTS Networks that visualize the results of your research questions can be included as images in the report. If you insert them at the beginning of a chapter, they open the discussion. At the end of a chapter, they can serve as a summary. Visualizations are also a welcome change for the reader, as it is sometimes easier to see relationships illustrated rather than just reading about them. If you want to include a network in a presentation or report, the best option is to export is as graphic file: • Open the network that you want to export. • In the Import & Export tab in the Network Editor select the Export Bitmap option. When saving the file, you can choose among the following graphic file formats: png, jpg, gif and tif. To see the different file types, you need to open the File Types drop-down menu below the line where you enter the file name. Figure 8.5 Export formats for networks • Select a folder for saving the network. Enter a name for the network, select the fitting file format and click Save. CONTENTS FOR THE APPENDIX Although it is not compulsory everywhere, if you are writing a Master’s or doctoral thesis, I always recommend including the code book in the appendix. The code book allows the reader to see which aspects of the data you consider relevant and how you understood and interpreted them. See Skills training 8.4.

COMPILING THE FINAL REPORT – THE LAST PHASE OF THE WRITING PROCESS 235 If you want to share your coded data, you can output any document with the margin area showing all linked entities, i.e. all codes, memos and hyperlinks. The document is exported in PDF format. This allows the interested reader to find cited quotations in the context of the original data. See Skills training 8.5. If you often use Code-Document and Code Co-occurrence Tables in your analysis, you might want to include some selected tables in the results section of the report; all others, however, should go in the appendix. The detailed results of an inter-coder agreement analysis (see Chapter 9) are also more appropriate for the appendix. SKILLS TRAINING 8.4 CREATING A CODE BOOK To export the list of codes as you see them in Code Manager: • Open the Code Manager and select Excel Export on the ribbon. • In the following dialog, select All items and activate the options Code, Comment, Grounded, Density and Code Groups. ‘Grounded’ displays the frequency count for each code. ‘Density’ shows the number of links between codes. Figure 8.7 shows an excerpt from a code book. Figure 8.6 Exporting a code book

236 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI Figure 8.7 Excerpt from a code book SKILLS TRAINING 8.5 EXPORTING THE DOCUMENT WITH CODES IN THE MARGIN To export the coded document as you see it on your screen: • Open the Document Manager and select a document. • Select the Tools tab in the contextual ribbon of documents and, on there, the Print with Margin button. • You have some options, such as printing in portrait or landscape format. You can also scale the margin area to make it narrower or wider depending on how many codings you have. Figure 8.8 Print with margin

COMPILING THE FINAL REPORT – THE LAST PHASE OF THE WRITING PROCESS 237 At the time of writing, this option had not yet been implemented in the Windows version. Figure 8.8 shows a screenshot of the Mac version. As soon as text editing is implemented, this option will become available again. REVIEW QUESTIONS Here are the questions for you to work through: 1 When do you start writing your analysis? 2 Which parts of your ATLAS.ti project can you use for the method chapter of your report? 3 Which parts of your ATLAS.ti project can you use for the results chapter of your report? 4 How do you export the relevant parts of your report? 5 Which parts of your ATLAS.ti project can you use for the appendix? 6 How do you prepare a codebook? FURTHER READING Burnard, Philip (2004). Writing a qualitative research report. Nurse Education Today, 24(3), 174–9, http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.474.5462&rep=rep1& type=pdf. Corden, Anne and Sainsbury, Roy (2006). Using verbatim quotations in reporting qualitative social research: Researchers’ views. ESRC 2136, March 2006, https://www.york.ac.uk/ inst/spru/pubs/pdf/verbquotresearch.pdf. Dickie, Virginia A. (2003). Data analysis in qualitative research. A plea for sharing the magic and the effort. American Journal of Occupational Therapy, 57(1), 49–56, https://ajot.aota. org/pdfaccess.ashx?url=/data/journals/ajot/930147/49.pdf. Guest, Greg, MacQueen, Kathleen M. and Namey, Emily E. (2012). Applied Thematic Analysis, chapter 10. Thousand Oaks, CA: Sage. Richards, Lyn (2009). Handling Qualitative Data: A Practical Guide, 2nd edn, chapter 10. London: Sage. Richards, Lyn and Morse, Janice M. (2013). Readme First for a User’s Guide to Qualitative Methods, chapter 10. Thousand Oaks, CA: Sage. Wolcott, Harry F. (2009). Writing Up Qualitative Research, 3rd edn. London: Sage.

Teamwork 9 The aim of this chapter is to help you with team projects. There are a few important things to consider when compared to single-user projects. I have developed a few common team project scenarios. Just select the one that is most relevant to your situation. The first three scenarios describe the ‘classical’ team situation, where several researchers work on the same project. This could mean that they code the same documents (Scenario 1), that they all code different documents using a common coding schema (Scenario 2) or they do both, first developing a code system together and then splitting the encoding work (Scenario 3). Scenario 4 gives several options for how you can work with students in the classroom. Scenario 5 describes how to set up a project if you want to analyze inter-coder agreement. For Scenarios 1–4, I mainly give technical instructions, as the methodological aspects have been described elsewhere in the book. As Scenario 5 introduces a new topic, intercoder agreement, I first discuss the requirements that are placed on a project in order to perform an inter-coder agreement analysis and further methodological aspects. This is followed by the technical instructions for ATLAS.ti. There are a few things that are common to all team projects: you need to designate one person as the project manager, and each person in the team should be logged in with a different name so that you can distinguish the work of individual team members. I discuss these two topics first. The tasks of project managers and team members are similar. To avoid repetition in the description of the scenarios, I describe the general tasks of project managers and the general tasks of team members before I describe each scenario.

TEAMWORK 239 LEARNING OBJECTIVES In this chapter you will learn how to set up different types of team projects, what you need to do and know in the roles of project manager and team member and how to organize the continuous project workflow. You will also learn how to merge projects. This can also be useful when you are working alone – for example, if you want to combine different sub projects. A second topic is the analysis of inter-coder agreement. You will learn why it may be useful to calculate inter-coder agreement, when to use it, how to interpret the results and what you need to know about project creation and coding for inter-coder agreement analysis with ATLAS.ti. SKILLS TRAINING Skills training 9.1: merging projects Skills training 9.2: analyzing inter-coder agreement DECIDE WHO IS GOING TO BE THE PROJECT MANAGER When working in a team, it is best to nominate one person to be the project manager. I recommend choosing the person with the greatest knowledge of ATLAS.ti and the highest degree of computer literacy. The job of the project manager is to set up the project, to distribute it to team members, to instruct team members and to collect the sub projects from time to time and merge them. The project manager will in most cases also work on the project, so she or he has two roles. She could create a sub project for herself as a team member, but this is not necessary. The project manager may also work in the Master project. If you work on your own and want to share your project to analyze inter-coder agreement, you are also a project manager. In a classroom setting, there are two options. The teacher can take on the role of the project manager, or if students work in groups, they must designate one person in their group to take on this role. CHECKING USER ACCOUNTS ATLAS.ti automatically creates a user account based on the name that you use on your computer. If you want to check under which name you are logged in: • Select the Tools & Support tab and then User Manager.

240 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI Figure 9.1 User Management tab in ATLAS.ti 8 If two persons on a team have the same user name, you may want to consider renaming one of them or creating a new user account. When merging projects that come from different computers and that use the same user name, the duplicate name will automatically be renamed to <user name> (2). This means you can still distinguish the two users. However, it may be a bit cumbersome to always remember who is who. • If you want to change the user name, you can right-click on the name in the User Manager and select Rename. Or you can create a new user account: • Select User Manager. Click on the button New User at the left-hand side on the ribbon. After creating a new account, select Switch User to log in using the new user name. Before I give you a step-by-step instruction explaining the tasks of the project manager and the team members in setting up the project, distributing it and proceeding with the continuous work, I would like to invoke an image of an artistic performance like the one shown in Figure 9.2. Such a performance only works if all members of the team work together, can rely on each other and know what the other team members are doing now and in the next step. Even if you are not the project manager, you should know what the project manager is doing and why, so that you do not accidentally mess up the project. As project manager, you should also know what the tasks of your co-workers are, so no misunderstandings can arise. When you start a team project in ATLAS.ti, you should be aware of the following: • Each team member works within her/his own environment of ATLAS.ti. • The location where ATLAS.ti stores project-related data can be determined by each user. See Skills training 3.6: changing the default location for ATLAS.ti project data. • Document libraries CANNOT be shared. Each person works with her/his own copy of the data set. • The kind of teamwork supported is shared coding and analyzing. To avoid repetition, you will find instructions below that are common to all scenarios. In the scenarios, the tasks are only short-listed.

TEAMWORK 241 COMMON TASKS OF PROJECT MANAGERS • Creating a new project (see Skills training 3.1). • Adding documents to the project (see Skills training 3.1). • Organizing data into document groups (see Skills training 3.2). As explained in Chapter 3, groups usually reflect sample characteristics like demographic variables, locations or time of data collection. They can also be used to support teamwork. For instance, you may want to create a document group for each team member and assign the documents they are supposed to code. Figure 9.2 Team members need to rely on each other Figure 9.3 Example of the use of document groups in team projects

242 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI If a common set of codes and code groups is to be used, they also must be added by the project manager. If each team member were to add codes and code groups individually to each sub project, codes and groups would be multiplied during the merge process because codes are stamped with a unique ID when they are created. • Adding codes and code groups. See Skills training 4.11 on how to import an already existing list of codes. • Saving the project (see Skills training 3.1). • Exporting the project and creating a project bundle file (see Skills training 3.4). • Distributing the project bundle file to all team members – for example, via email, a folder on a server that everyone can access or via a cloud link or cloud folder. If you share data via email, the cloud or a server, please check the regulations for data security of your home institutions and make sure that you comply with the General Data Protection Regulation (GDPR). • Merging projects (see ‘Housekeeping’, below). • Merging duplicate codes (see below). SKILLS TRAINING 9.1 MERGING PROJECTS The Merge Tool reunites projects that were originally divided for analytical or economic reasons. It brings together the contributions of different members of a research team. The following explains a few general principles about merging: Master and Imported projects. The Master project is the project into which another project, called the Import project, is merged. The Master project must be loaded first before invoking the Merge Project option. Merge strategy. The default option is to unify all objects that are identical and to add all objects that do not yet exist in the Master project. Identical entities explained. When an entity is created in ATLAS.ti – regardless of whether it is a document, a code, a quotation, a memo, a network, a group or a comment – this entity receives a unique ID, comparable to a fingerprint. When merging projects, ATLAS.ti compares the IDs of the various entities. If they have the same ID (fingerprint), they are unified. If the fingerprint is different, they are added. Thus, the name of an entity is not the decisive factor. If Tom has created a code with the name ‘sunshine’ and Anne also has created a code with this name in her project, these two codes are not identical as they have different IDs. If you merge Tom’s and Anne’s projects, the merged project will contain two codes: ‘sunshine’ and ‘sunshine (2)’. If the meaning of both codes is the same and you want to keep one sunshine code only, you can merge the two codes manually (see ‘Merging Duplicate Codes‘). Identical entities are unified, all others are added.

TEAMWORK 243 Groups are additive. ‘Group B’ with documents {1, 2, 3} in the Master project merged with ‘Group B’ with documents {3, 4} in the Import project will result in ‘Group B’ with documents {1, 2, 3, 4}) in the merged project. Figure 9.4 Merge example 1: merging groups Entities with and without comments: If there is a code C in the Master project that has no comment and a code C in the Import project that has a comment, the merged procedure will add this comment to the merged project. Figure 9.5 Merge example 2: entities with comments, no conflict In the case of an unsolvable conflict (e.g. code C in the Master project has a comment, and code C in the Import project also has a comment), the user can define which of the two conflicting entities will win. If the comment of the Master project should be kept, you need to select the option ‘Keep’. If the comment of the Import project should be kept, you need to select the option ‘Override’, as shown in Figure 9.6.

244 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI Figure 9.6 Merge example 3: entities with conflicting comments How deleted entities are handled. It is not possible to ‘subtract’ entities. If one team member has deleted a code or some codings and these entities still exist in another project, the merged project will contain those codes and codings again. Therefore, if something needs to be deleted from the project, it should be done in the Master project. Figure 9.7 Merge example 4: merging always adds entities, never subtracts If you want to clean up a project, this is best done in a ‘fresh’ Master project after merging and before distributing the new Master file to all team members. Before you merge, I recommend that you import all project bundle files first and look at the projects. If a conflict arises during the process of merging, you need to decide whether to keep all changes in the Master project or whether to override them. If you do not know what is contained in the projects to be imported, you cannot make an informed decision. Principally, it is possible to merge project bundle files without importing them prior to merging.

TEAMWORK 245 To begin the merge process, open the Master project. • Select File/Merge. • You have the option to select either a project or a project bundle file. If you have previously imported the bundle files of all team members, select Merge Project, otherwise Merge Project Bundle. • Select a project from the list offered by ATLAS.ti or load a project bundle file. If you have a long list of projects, just enter the first few letters of the project name into the search field. In both cases, you have the option to create a snapshot of the current project before merging. There may be times when you want or need to go back to an older version of your project. Therefore, to be on the safe side, keep the default and allow ATLAS.ti to create a snapshot. The name for snapshot project is project name (snapshot–date-time). Figure 9.8 Select either a project file or a project bundle to merge Figure 9.9 Check the Pre-Merge Summary for conflicts

246 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI • After selecting a project or project bundle, click on the Merge button. ATLAS.ti checks the two projects for identical and different items. As explained above, all identical items will be merged; all different items will be added. After this process is completed, you see a Pre-Merge Summary (Figure 9.9). • If there are no conflicts, you can proceed with merging the two projects by clicking Merge. If there are conflicts between the Master project and the project that you import, you can solve the conflict in two ways: Keep means the Master project ‘wins’, and the changes made in the project that you import will be ignored. This applies to all conflicts. You cannot currently make a decision for each conflict separately. Override means that all changes made in the project to be imported ‘win’, and the entries in the Master project are overridden. • After merging, check the final merge report and the merged project for plausibility. If you are satisfied with the results, save the project. If not, you can always select Undo. • If applicable, continue with merging the next sub project or project bundle file. If all team members have been coding different documents, merge conflicts are unlikely to occur. A conflict could arise, for instance, if someone has modified a document or code group, or modified a comment. As project administrator, you will have to decide whether to accept this change or not. Housekeeping After merging all sub projects, the project administrator may need to perform some housekeeping work, such as cleaning up the code list, adding or modifying code groups, adding a memo with information for the team or adding new documents and document groups. You need to do some housekeeping if you find duplicate codes in the merged project. This can happen, for instance, if team members independently have added codes that have the same name. As these codes have been created in different projects, they have different IDs and, therefore, they are added, not merged. Duplicate codes can be merged as follows: • Open the Code Manager. Highlight the codes that you want to merge, right click and select the Merge Codes option from the context menu or click on the Merge Codes button in the ribbon (see Skills training 4.10).

TEAMWORK 247 COMMON TASKS OF TEAM MEMBERS • Saving the project bundle file, which they receive from the project manager in a designated folder on their computer/personal space on a server. • Importing the Master project bundle file and renaming it. See Skills training 2.1 and below. • Working on the project as instructed (see Chapters 4 and 5). IMPORTANT. If the project manager has added codes and code definitions to the Master project, team members should NOT change the code definition in the code comment field. This is because comments for the same entity written by different users cannot be merged. If you disagree with the definition or you do not understand it because it is unclear and have ideas on how to improve it, write your ideas in a memo. • Exporting the project and sending it back to the project manager (see Skills training 3.4). Importing project bundle files When you import the project bundle file that you receive from your project manager, you need to rename it by adding your name or initials to the project name. This is important for the project manager later when he or she merges the projects of all team members. Figure 9.10 Renaming the project during the process of importing the Master project bundle file

248 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI If you want to rename a project after it is imported, you can do it on the opening screen when starting ATLAS.ti. If the project is already open, you need to close it to return to the opening screen. • On the opening screen, right-click on the project that you want to rename and select Rename Project. When repeatedly importing newer versions of the Master project bundle file, the project name with the added coder name or initials already exists. ATLAS.ti will recognize this and will offer the following two choices: ‘Keep current project as a snapshot’ or ‘Overwrite existing project’’. Figure 9.11 Renaming a project on the opening screen Figure 9.12 Importing the Master project bundle file after merging When you see this message, you have previously worked on the project and exported it to send it to the project administrator. Thus, you already have a backup of your project. Therefore, it is OK in most cases to overwrite the existing project. • Make the appropriate choice and click Import.

TEAMWORK 249 OVERVIEW OF TEAM PROJECT TASKS Below you will find an overview of all tasks that need to be performed by either the project manager or the team members for Scenarios 1–3. Table 9.1 Tasks of the project manager Project manager 1 – same set of documents after a code list is developed 2 – different set of documents 3 – joint development of code system Creates new project Adds documents and document comments Organizes data in document groups Adds codes, code comments and code groups Saves and exports the Master project Distributes project bundle file to team members Collects all sub projects from team members Merges projects Housekeeping: merges codes that have the same label Modifies code comments Organizes codes in code groups as a preparation for discussing the code list in the team Saves, exports and distributes the new Master project Regularly creates project bundles files of the Master project as backups Table 9.2 Tasks of the team members Team members 1 – same set of documents 2 – different set of documents 3 – joint development of code system Create a project Add documents Organize data into document groups (Continued)

250 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI Team members 1 – same set of documents 2 – different set of documents 3 – joint development of code system Import Master project bundle file and rename the project Add codes and code groups Apply existing codes Add additional codes Write code comments Only if you add additional codes Only if you add additional codes Modify existing codes and document comments Write quotation comments Write memos Work on the project as instructed Regularly save and create project bundles files as backups Export your own project as a project bundle file for the project manager Merge projects Distribute Master project files Look at the merged project to get an overview of how other team members have coded Think about how the list of codes could be sorted and organized Table 9.2 (Continued) SCENARIO 1 – ANALYZING A COMMON SET OF DOCUMENTS The project manager creates a new project; adds documents; organizes data into document groups; as discussed with the team, adds codes and code groups; saves the project; exports the project; and distributes the project bundle file to all team members. Figure 9.13 Analyzing a common set of documents – project set-up

TEAMWORK 251 All team members import the Master project bundle file, rename it, work on their project as instructed and, when they are done, export their project and send the project bundle file back to the project manager. Figure 9.14 Overview of step 2 and 3 The project manager merges all sub projects and checks whether some housekeeping work needs to be done, like merging codes, saves the Master project and exports it for distribution to the team members. Figure 9.15 The project manager merges all sub projects and distributes a bundle file again The team members import the updated Master project and, as previously, rename the project file by adding their name or initials. This cycle continues. If new documents need to be added to the project, this is best done by the project administrator. A good time for this is after merging and before sending the

252 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI updated project bundle file. Individual team members can also add documents to their sub projects, but this must be coordinated well. Keep in mind that every document, when added to an ATLAS.ti project, will have a unique ID (see Chapter 3). For your team not to end up with sets of documents that cannot be unified due to different IDs, individual team members can add documents only if nobody else adds them as well. SCENARIO 2 – ANALYZING DIFFERENT SETS OF DOCUMENTS For this scenario to work, you must start with a common code list. If everyone develops their own codes, after merging you will have a very long code list and few overlaps between the projects. Several of the codes probably have the same meaning or even the same label, but because they were created in separate projects, they are duplicated when the projects are merged. It will then take a lot of effort to clean up the code system. If there is no code system available at the onset of the project, look at Scenario 3, where I explain how to develop a coding frame together in a team. The project manager creates a new project and imports the list of codes with code definitions and code groups, saves the project. exports it and distributes the project bundle file to all team members. Figure 9.16 Project set-up when analyzing different documents and using a common code list The team members import the project bundle file that contains the coding frame and rename it during the process of importing. Discuss with your team how you want to name each project. If the data are from different regions, you could agree on a naming convention as follows: project X_region north, project X_region south, project X_region east. Instead of regions, it could be different school districts, different groups of respondents, different types of data (interview, focus groups, surveys, etc.). Next, each person adds their own set of documents, organizes the data into document groups, codes the data, saves the project, exports it and returns the project bundle file to the project manager. See Figure 9.17.

TEAMWORK 253 Figure 9.17 Team members add documents and work on their projects The project manager merges all sub projects, saves the result as a new Master project, checks whether some housekeeping work needs to be done, like merging duplicate codes, saves the Master project and exports it for distribution to all team members. The project bundle file contains the combined work of all team members. The team members import the Master project. Figure 9.18 The project manager merges all projects and distributes the Master project bundle SCENARIO 3 – JOINT DEVELOPMENT OF A CODING FRAME If you want to develop a coding frame from scratch, I suggest that you set up a team project with two to three documents only. Choose documents that are as different as possible and that cover a variety of issues. The sole purpose of this project is to develop the coding frame. It is very likely that you will have to recode the documents after you decide which codes to use. Please note that the focus of the instructions is on the technical rather than the methodological aspects. I assume that as a team you discuss your research goals and that not everyone codes just for the sake of coding. Also, for team projects it is important that the

254 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI thoughts and considerations for creating and applying a code are documented in code comments. These serve as the basis for further discussions in the team when jointly developing the coding frame. The project manager creates a new project, adds documents, saves the project, exports the project and distributes the project bundle file to all team members, The team members import the Master project bundle file, rename the project by adding their name or initials to the project name, code the documents and write a comment for each code that they create as basis for later discussion with the team. After coding, they export their project and send it back to the project manager. The project manager merges all sub projects and saves the result as a new Master project; scans the list of codes and groups all codes into code groups that either have the same label, a similar label or a similar meaning; saves the project; exports it; and distributes the project bundle file to all team members for inspection. Organizing the codes in code groups serves as preparation for the team meeting to make it easier to discuss the codes. The project manager arranges a team meeting to discuss the results of the first round of coding. I suggest that you look at the project together by projecting it with a beamer onto a wall; or if you meet online, use the Share Screen feature of your meeting software. All team members take some time to look at the merged project so that everyone gets an overview of how others have coded the data and develops ideas on how to sort and structure the code list. During the team meeting, one person (= the facilitator) is responsible for making changes to the Master project. I suggest that the facilitator creates a snapshot of the original Master project before making changes. Figure 9.19 Discussing the codes of the merged project Facilitator. Opens the Code Manager and moves the author column next to the code label, so everybody can easily see who created which code. This will facilitate the discussion. Team. Go through each code group that contains similar codes and decide which codes to keep. Codes that have the same meaning can be merged. Codes with similar meanings might be subcategories of the same higher-order theme. Begin to add structure to the code list by prefixing those codes that belong to the same category (see Skills trainings 5.3 and 5.4). Discuss

TEAMWORK 255 how to define each code. The facilitator merges, renames and writes code definitions as you proceed. Check for codes with high quotation frequency and discuss whether they need to be split. Split the codes as appropriate (see Skills training 5.3). Discuss all other codes that have not already been grouped into code groups and continue as above. Another helpful option is to display the name of the coders in the margin area: • Open the Document Manager. From the View tab of the contextual Document ribbon select Show User. Figure 9.20 View settings to display name of coders in the margin Figure 9.21 Display of the codings of different users

256 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI You may decide to arrange more than one meeting as it will probably take many hours to go through all codes. The time between meetings can be used by all team members to develop ideas on how to structure codes that are not yet associated with a category. While you discuss the code system, you also need to make decisions about the typical length of the quotations (see Skills training 5.1: the ‘right’ length for quotations). A strategy could be to add all matching codes to a paragraph as a unit for coding. Note, however, that this makes the coding less accurate. When retrieving data about a code, you may need to read a lot that is not part of the topic. If a quotation is too short, there might be too little context to understand its meaning, especially if you plan to split the coding work among team members. If you have transcripts of interview data, grammatical structures such as sentences as coding units are also rather unsuitable. Sentences can be incomplete, or multiple thoughts are nested and run in parallel strands. Therefore, I recommend that you decide on quotation length based on the meaning of the quotation content. Ask yourself: can we still understand what it is all about if we or one of us retrieves the quotation without the context? After agreeing on units of meaning, codes and their structure, the project manager prepares a new Master project that contains the agreed-upon coding frame. If you were not the facilitator of the team meeting, ask the facilitator to give you a project bundle file. Rename the project when importing it. If you have been the facilitator yourself, create a snapshot of the project that you used for discussing the codes (see Skills training 3.5). Continue to work on the original project. Proceed as follows: Option A. If you decide that the first documents need to be recoded from scratch and not just checked, the project manager needs to do the following: • Open the Quotation Manager, select all quotations and click on the Delete Quotation(s) button. • Add the next set of documents to be coded. • Create a document group for each coder and add the documents that each coder should code. • Save the project, export it and distribute the project bundle file to all team members. Option B. If you decide that the first documents should only be double-checked, the project manager needs to do the following: • Add the next set of documents to be coded. • Create a document group for each coder and add the documents that each coder should code. • Save the project, export it and distribute the project bundle file to all team members. The team members import the new Master project and rename it during the process of importing by adding their name or initials, code the documents that have been assigned to them, export the project and send it to the project manager once they are done. As the coding frame is probably not yet 100% stable, I suggest that each person codes another two or three documents in the next round of coding. Allow each coder to add new codes if topics come up that are not yet covered by the coding system.

TEAMWORK 257 Overview of the tasks for classroom projects Remember that you should now no longer change code definitions of existing codes. The project manager merges all sub projects and prepares the project for the next team meeting, as described above. At each subsequent meeting, there will be less discussion and the coding frame will become more complete. For your own assurance, or because funding agencies or journals where you want to publish your research require it, you can analyze inter-coder agreement during this process. See Scenario 5 for further detail. SCENARIO 4 – TEAM PROJECTS FOR THE CLASSROOM There are several options of how to work with groups of students and teach them how to analyze qualitative data using ATLAS.ti. Below, I offer a few examples and a step-by-step instruction for Scenario 4a. The instructions for the other two examples are covered by Scenarios 3 and 5a. Table 9.3 Tasks of the teacher Teacher 4a – teacherguided 4b – more student autonomy 4c – twosemester course Creates new project optional Adds documents optional Organizes data in document groups optional Adds codes and code groups optional Saves the Master project optional Creates a Master project bundle file and distributes it to the students optional Prepares a project bundle for each group based on the same Master project Gives group specific project bundle files to each group Collects all sub projects from students Merges projects Housekeeping: merges codes that have the same label should not occur Saves, exports and distributes the new Master project Regularly creates project bundles files from the Master project as backups

258 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI Table 9.4 Tasks of the student project manager Student project manager 4a – teacher-guided 4b – more student autonomy 4c – two-semester course Creates a project optional Adds documents optional Organizes data into document groups optional Imports code list with comments and code groups optional Adds codes and code groups optional Saves the Master project, exports it and gives the Master project bundle file to the other students in the group optional Enables and disables intercoder agreement mode Collects all sub projects from team members Merges student projects Housekeeping: merges codes that have the same label should not occur should not occur Creates a snapshot of the merged project Performs the inter-coder agreement analysis Organizes codes in code groups as preparation for discussing the code list in the team Adjusts the codings in discussion with the group Modifies existing code and document comments Saves merged project, creates a project bundle file and gives it to the students in the group (Continued)

TEAMWORK 259 Student project manager 4a – teacher-guided 4b – more student autonomy 4c – two-semester course Saves merged project with adjusted codings, creates a project bundle file and returns it to the teacher Regularly saves and creates project bundles file as backups Table 9.5 Tasks of the students as team members Students 4a – teacher-guided 4b – more student autonomy 4c – two-semester course Create a project Add documents Organize data into document groups Import Master project bundle file and rename the project Add codes and code groups Apply existing codes after agreeing on a code system Add additional codes Write code comments Modify existing code and document comments Write quotation comments Write memos Work on the project as instructed Regularly save and create project bundles file as backups Export their own project as a project bundle file for the project manager Look at the merged project to get an overview of how other team members have coded Think about how the list of codes could be sorted and organized Table 9.4 (Continued)

260 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI Scenario 4a – the teacher-guided classroom project TEACHING GOALS Students learn how to code, how important it is to work on a common understanding of the codes in the coding schema and about the usefulness of inter-coder agreement in qualitative data analysis. By using ATLAS.ti for coding, for analyzing inter-coder agreement and by trying out some of the analytical features, they will learn the technical application of ATLAS.ti as a tool. Description. The teacher sets up the projects and adds documents and a list of codes including code definitions and code groups. As the students will compare their codings, the code system needs to comply to the requirements for an inter-coder agreement analysis (see Scenario 5). The students work in groups of three and the project for each group contains two or three documents. Each group codes a set of different documents. Initially independent of each other, each of the three students within a group codes the documents in the project. Then they merge their projects and check for inter-coder agreement. Based on the results, they discuss their coding, adapt it and submit the project to the teacher. The teacher merges the projects of all groups to one Master project that has all documents. If applicable, document groups can be added. If you have 24 students in a class, the Master project holds sixteen or more documents. Based on the Master project, students can, for instance, practice the advanced analysis tools and work with networks. This is how you implement it: The teacher creates a Master project, adds all documents to this project, creates document groups (one for each student group), adds the documents each group should code, adds the code list including comments and groups to the Master project by importing an Excel table and saves the Master project. You could give all groups a copy of the Master project and tell each group which document they should work on. This, however, could be the first source of errors. Students may misunderstand which are ‘their’ documents, and you may end up with a document coded by three groups and some not being coded at all. Therefore, I suggest that you create a sub project for each group based on the same Master file: Figure 9.22 Project set-up for teacher-guided classroom project

TEAMWORK 261 • If you have five groups in the class, create five snapshots from the Master project (File/ Snapshot). When creating each snapshot, change the default name that is suggested by ATLAS.ti to something like: Project X_group 1, Project X_group 2 and so on. • Open each snapshot and remove all documents that the group should not analyze. The created document groups facilitate this process. Once each project is prepared, only one document group in each project has documents; the others are empty. See Figure 9.22 • Save each snapshot and prepare a project bundle file for each group. • Distribute the project bundle files to each student group (see Figure 9.23). Figure 9.23 Project distribution to student groups If you are wondering why you cannot create individual projects that contain the documents for each group, this is due to the unique ID with which codes are stamped when importing. If you add the Excel file with the code list to each individual project, the codes in each project will have a different ID, and, in the end, when all projects are merged, each code will occur as many times as there are projects. Teamwork within each student group The students copy the project bundle file to their computer, import the project bundle file and rename the project by adding their name or initials to the project name. Next, they code the documents in the project by applying the codes that are already in the project. When they are done coding, they export the project. Further instructions for the students: • Designate one person in your group to be the project manager. Give your project bundle file to the project manager. • The designated project manager merges all sub projects in inter-coder agreement mode (see Skills trainings 9.1 and 9.2) and creates a snapshot of the merged project as backup. • Conduct an inter-coder agreement analysis and discuss the results with your group (Skills training 9.2).

262 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI Figure 9.24 Student groups merge their coding and discuss the results of the inter-coder agreement analysis • While you discuss your codings, the project manager adjusts the codings in the merged project file, so that in the end you have two or more coded documents that you all agree on. • The project manager disables inter-coder agreement mode, saves the project and creates a project bundle file. This version will be returned to the teacher. Figure 9.25 Cleaning up the coding and returning a project bundle file to the teacher The teacher merges all project bundle files from each student group into a new Master project. I recommend that you first import all projects and take a quick look at them. If the students followed the instructions, there should be no merge conflicts. If there are, you need to choose what to keep and what to override. Having looked at each project beforehand will help you to decide which choice to make. • Double-check whether all documents are indeed coded and that there are no code duplicates or new codes or code groups. Clean up the project as necessary. • Save the new Master project and export it for distribution to your students. See Figure 9.26. Note: when disabling inter-coder agreement mode, only the name of the currently loggedin user remains in the project. Note: discuss with the students the pros and cons of adjusting the codings based on the inter-coder agreement analysis and the pitfalls of consensual agreement.

TEAMWORK 263 Figure 9.26 The teacher combines all student work and distributes the new Master project Scenario 4b – the teacher-guided project with more student autonomy TEACHING GOALS These are the same as Scenario 4a plus an extension to the methodological aspects of the analysis and more autonomous teamwork. Students work in groups of 3–5 students, and each group analyzes the same set of documents provided by the teacher. The teacher gives the research context, formulates the research questions and suggests a method of analysis. A code list is provided that each group can adjust. As above, if the students analyze inter-coder agreement, the code list must meet certain requirements, and there are a few rules for coding. See ‘Requirements for coding’ below. The teacher can either give each group a project bundle file that holds all documents, document groups and codes or give each group a folder with the documents and an Excel file with the codes, code definition and code groups. Based on the group size, I suggest giving each group two documents per person plus the number of documents necessary for the inter-coder agreement exercise (see ‘Decision rules’ in Scenario 5). The task of each group is to code all documents. A starting point is, as in Scenario 4a, that each student in each group codes the same document(s). Based on this, they compare their coding using the inter-coder agreement tool and discuss and adjust the coding, possibly making some changes to the code list. This does not quite conform to the requirements for inter-coder agreement (see ‘Common mistakes in Scenario 5’). Take this as an opportunity to discuss it in class. After this phase, the students divide the remaining coding work among themselves. Based on the fully coded project, they can continue the analysis with the aim of finding answers to the research questions given to them by the teacher.

264 QUALITATIVE DATA ANALYSIS WITH ATLAS.TI Scenario 4c – for a two-semester qualitative method course TEACHING GOAL This scenario can best be implemented if you teach a two-semester course on qualitative methods that includes methodology, data collection and data analysis. The students learn how to conduct a qualitative research project as a team and use ATLAS.ti as an analysis tool. Students work in groups and collect their own data. Each group can select a topic they want to work on. Depending on the aim and length of the course, they may conduct their own interviews or collect some data from online sources. Each group, thus, is a team and can proceed as described in Scenario 3. SCENARIO 5 – INTER-CODER AGREEMENT Inter-coder agreement refers to the extent to which two or more independent coders agree when coding the same content by applying the same coding scheme. It has its origin in quantitative content analysis (Krippendorff, 2004; Schreier, 2012), and more and more researchers analyzing qualitative data also want to apply it, often because their supervisor asks them or a journal requires it for publication. Based on my experience, qualitative researchers often have not thought about the requirements this has for coding the data. It means crossing the line between qualitative and quantitative methods, and if you want to apply it, you must follow some coding rules that are much stricter than those for qualitative coding. Figure 9.27 is a typical dialog with a user who asks how to calculate ‘inter-coder reliability’ with ATLAS.ti: Therefore, before I explain the ‘how to’, I would like to raise awareness of the things that you need to consider when you want or need to calculate a metric for inter-coder agreement. You probably know the adage: garbage in, garbage out. If you click on one of the options that ATLAS.ti offers to calculate an inter-coder agreement coefficient, ATLAS.ti calculates something in most cases. Whether the value you receive makes sense depends on how you set up your project and your coding. ATLAS.ti can only provide the functionality. You as the user are responsible for the reasonable use, especially if you intend to use an inter-coder agreement coefficient to claim that your research can be relied upon by readers of a publication. As described in Scenario 3, you can start by jointly developing a code system in a team. At this stage, you cannot yet measure inter-coder agreement. To compare the codings of the different coders, you can proceed as described in Scenario 3 or you can use the qualitative component of the inter-coder agreement tool (see ‘Qualitative comparison of codings’ at

TEAMWORK 265 the end of this chapter). Analyzing inter-coder agreement requires a structured code system in which each code is clearly defined. In addition, the data must be coded by two or more independent coders. In other words, if you want to measure inter-coder agreement, you need at least three people: one person who develops the coding system and two others that apply the codes (Krippendorff, 2018). To the critics I am aware that inter-coder agreement analysis is a controversial issue. Not all qualitative researchers embrace it, and some argue that we don’t have to adapt to standards that are imposed by quantitative research traditions. Instead they argue that for qualitative research other reliability measures are more important, like credibility, transferability, dependability and confirmability (Guba and Lincoln, 2005). As there is an extensive literature about it, I would like to refer you to this rather than repeat it here: see, for example, Cameron (2011) for a summary, or Seale (1999), Golafshani (2003), Rolfe (2006), Tracy (2010), Bergman and Coxon (2005), Poortman and Schildkamp (2012), Barbour (2001). I agree with Rolfe (2006), who argues for regarding qualitative studies on a continuum rather than insisting on a qualitative–quantitative dichotomy. If we do, then we also need a continuum of quality criteria rather than a generic framework for assessing the quality of all qualitative studies. Richards (2009) also adds a pragmatic perspective and reminds us that Figure 9.27 Dialog about calculating ‘inter-coder reliability’ User: ‘How can I calculate inter-coder reliability? I have coded two interviews and my colleague also has coded two interviews. Now we want to merge our projects and calculate inter-coder reliability.’ I: ‘Let’s start at the beginning: How have you set up the project?’ User: ‘I have added two documents to my project and my colleague has added the same two documents to her project.’ I: ‘Mmh. This means, if you merge, you end up with duplicate documents, as each document is stamped with a unique ID when adding it to a project. This is not what you want. The correct way of doing this is that one person sets up the project, adds the documents, saves them, creates a project bundle file and gives the project bundle file to the second coder. However, with a bit of manual work, this can be fixed. May I ask how you have approached coding?’ User: ‘We both read the documents and coded them, creating our own codes.’ I: ‘So, there was no coding system? You did not talk about which codes to apply? There were no code definitions?’ User: ‘No, we just coded and now we want to measure inter-coder reliability’. I: ‘(sigh) ………. I think we have to talk about method first.’