• No results found

Computer Assisted Qualitative Data Analysis Software (CAQDAS) – Nvivo

CHAPTER FOUR

4 Research Method

4.6 Qualitative data analysis/Mode of analysis

4.6.3 Computer Assisted Qualitative Data Analysis Software (CAQDAS) – Nvivo

The application of CAQDAS in IS research has improved over the years. The advantages of CAQDAS have successfully drawn in researchers to apply such software. The application of CAQDAS enhances the quality of the analysis (Fielding and Lee, 1991). The improvement of the quality of analysis mainly resulted from the capability of being able to manage efficiently vast amounts of data using CAQDAS (Moseley et al., 1997; Kelle and Laurie, 1995). Since less time is taken to deal with the data, more time is redirected to substantive analysis of the derived codes and emerging categories (Morison and Moir, 1998; Moseley et al., 1997). The application of CAQDAS has also improved the transparency of the coding process (Allan, 2003) and audit-trailing of the codes to the data. Thus, the capability of CAQDAS to retain the original documents enhances its visual aspect and maintains its context (Bazeley, 2007). Details of the discussion on CAQDAS can be found in Ahmad and Newman (2010). The researcher attended a two-day training to gain an in-depth knowledge and skills of the software. This hands-on training provided greater depth in understanding the data collected and the various techniques that could be used during the analysis. During this research, the manual coding process of applying a GT technique was conducted prior to the application of the CAQDAS. Thus, it enabled a comparison between both techniques and the benefits and drawbacks of each surfaced. The table below (Table 13) provides details for the comparison between manual GT technique and CAQDAS.

Grounded Theory (GT) technique Manual CAQDAS Open coding

Creation of codes based by paragraph – description/summary of paragraph

Creation of codes as free nodes by sentence or paragraph – description/summary of sentences or paragraph – highlight and code Axial

coding

Re-reading of codes generated and re-arrangement according to theme/category – cutting and pasting

Re-reading of codes/free nodes and re- arrangement according to theme/categories/tree nodes – Creation of hierarchies by “drag” and “drop”

Selective coding

Re-reading of codes and categories and selection of category that most represent the cumulated categories.

Re-reading of codes and categories and selection of category that most represent the cumulated categories. Higher hierarchies of the tree nodes are established to show the selected codes.

Table 13: Comparison between a manual process and the application of CAQDAS for coding.

As discussed earlier, one of the most important benefit of CAQDAS is its capability to manage efficiently the vast data sets during the coding process. In applying CAQDAS during the open coding process, extracts of interviews were highlighted and coded into free nodes. This contrasts sharply with manual processes, which require cutting and pasting the interview transcript to different codes, thus potentially causing the researcher to lose context with the original transcript. By applying CAQDAS, the original copy of the transcript is still available in the database.

Compared with the manual coding process, life was much easier with the preceding process of GT – rearranging codes into themes. Themes (tree nodes) were created through reading and re-reading of the initial codes (free nodes). Themes emerged from the data based on researchers own interpretation and sensitivity. All codes (free nodes) that represent the theme (tree node) were transferred to their dedicated tree through a “drag” and “drop” process. With the manual process, this activity was a nightmare, since the small pieces of paper of the codes with the interview extracts needed to be repositioned to the dedicated themes. This iterative process continued until the selective coding was achieved.

1st level category 2nd level category 3rd level category Concept Data Business requirement session Project Level

Communication Users‟ limited communication with developers

We communicated with them during sessions and after sessions. But the only thing was that they are located so far away; we even asked them to locate themselves in our office so that anything unclear can be discussed. But they rejected that. U5 phase 2

Limited channel of

communication

At the user level it is more difficult; we can only contact them during sessions, since they are busy with their daily operations. There‟s no time to have an informal gathering. Plus there‟s no other channel of communication. V1 phase 2 Control and power Process requirement according to superiors preference

In Case 3, they are not sure what they do. The direction from their bosses keeps changing day to day. They live by the moment, they don‟t have a target. And their staff are not enthusiastic about their work. It should not happen during requirement sessions, but it was being transmitted to us. We see that this thing happens and they acknowledge that it is happening. V7 phase 2

Control over requirement session

…for me, sometimes it is difficult for them to accept my expression, so in the end… it is better for a less people in the sessions. Less people less problems, it will not be a problem since there are less people to convince. U1 phase 1

Knowledge Users‟ knowledge on accounting process

If they are comparing a report from the same subsystem of course they will get a same figure. But now they are trying to compare one from transaction details (subsystem) and with customer ledger (GL) (requires posting). Of course there will be a timing difference between these two reports. But they want it to be

the same. Since their old system can give same figures. V1 phase 2

Users‟ limited knowledge on IT

I do not blame them but I think their IT knowledge is still limited. Since this is a new thing for them. I do not see anyone who knows how the system is being integrated. They should have an idea on how the systems should look like in the first place. They just want to see everything that was being done manually in the screen. Since our system is a bit up to date, we have to customise to follow their requirement. V4 phase 2

Table 14: A sample of the coding process

Figure 14: Sample screen capture for CAQDAS after coding process – events identification

In this research, the open coding process was carried out by creating free nodes in CAQDAS. Reading and re-reading of these codes and the attached extract from the interviews further generated concepts and categories (axial coding). In order to accommodate the PSIC model, these concepts and categories were structured according to the occurrence of the derived categories either at project, vendor or work level. At the selective coding process, these categories were further identified or structured into events (please refer to Table 14 and Figure 14).

During the study and for different purposes, the same data was coded twice. While the first coding exercise was for the events identification, the second coding exercise was conducted to assist in identifying stakeholders‟ interest and expectation towards the project and other stakeholders. The following (Figure 15) depicts the extract of the coding outcomes.

Figure 15: Sample screen capture for CAQDAS after coding process – stakeholders’ interest and expectation

Table 15 illustrates the process of events identification carried out during the study. We use an event (P13) at Case 1 as an example. Interview transcripts were analysed and coded either line by line or by paragraph depending on the issues emerging from the data. Codes were attached to each line or paragraph based on the interpretations of the researcher of the case understudy. Through iterations between data and codes, categories emerged. In this illustration, the category is the appointment of a new VC (VC2) which was ultimately regarded as the event. Once a general identification of events was established, the researcher revisited the data, the codes and the categories in order to identify specific events elements (people, technology, task and structure), and which is applicable for the specific events and following the stakeholder analysis approach, the interest, expectation or action for each identified elements were also

identified. Further analysis of the data, codes and categories resulted in the identification of conflicts or coalitions. As a point to note, each process of coding and event identification was in parallel with the overall story line in order to make sense of the data and codes.

Events

Appointment of new VC (VC2)

Interviews extracts Coding Events analysis Gaps (conflict) “He (VC1) wanted the

system that can improve the operations.”

Vendor developer, July 2008

“During the 2nd era, the VC2 is more on being comfortable and good well being in the workplace where everything should be on paper.”

IT developer 3, February 2009 “As you know our system is integrated. When the top

management rejects the use of system which integrated with others, it gives a signal that they are not trying to build or maintain the IMS culture.” User 5, February 2009 VC1 expectation on new system VC2 management styles VC2 expectation on new system Expectation towards project: New system (Technology): to support operations New VC (VC2) (people): preference towards manual process. Use of system creates tension. Conflict 1: New VC (VC2) (people) – New system (technology) results in no intention to support or use new system. Hence, gap between people and technology

“During the top management changes, there were also changes in my department, my boss was being

transferred to the faculty and I was being

ICT restructuring Steering committee (structure): Change in project team. Head of ICT transferred to faculty by VC2.

Conflict 2: New VC (VC2) (people) – steering committee (structure) results in change in project team – transfer of Head of ICT. Hence, gap between people and structure.

P13 Technology Structure Tas k P e o p le

transferred from development team to a more customer

support… the development of the system are being given to newer staff and the senior staff previously doing the development are transferred to the management post.” IT developer 2, February 2009

“As to date we have 3 directors of ICT… between the years there are also temporary substitutes.”

IT developer 3, February 2009

“During the 3 years period, there were several changes to the head of ICT post.” IT developer 2, February 2009 Frequent changes in Head of ICT post Frequent changes in Head of ICT post “Based on my

observation, during the tenure of the 2nd VC (VC2), there was a problem in the modification and enhancement of the system.”

Ex-head of IT, July 2008

“Due to the change in management, the development was halted.” IT developer 2, February 2009 Lack of system modification and enhancement No new development of systems Development, modification & enhancement of new system (Task) – to improve existing system, did not occur

Conflict 3: New VC (VC2) (people) – system development & modification (task) results in no new development and modification of systems. Hence, gap between people and task.

Table 15: An illustration of critical events identification (Case 1 - P13)

In conclusion, although applying manual processes and CAQDAS provided similar results of analysis, the benefits of applying CAQDAS provided the capability to

improve the overall analysis of the data through detailed analysis and transparency of the data.