4.6 Research Quality and Rigour
4.6.3 Dependability
Hoepfl (1997) suggests that dependability in qualitative research equals reliability. That view is consistent with Eisenhardt (1989) and Yin (1994) who suggest that both dependability and reliability aim to enable reviewers to examine the consistency of both the procedures and the conclusions of the research. In establishing dependability or reliability, Lincoln and Guba (1985) discuss the need for an inquiry, and Eisenhardt (1989) and Yin (1994) suggest the use of a case study protocol and a case study database. For this reason, a case study protocol was developed for this study and that will be discussed after a brief discussion about the case study database that was also developed for this study.
Case Study Database
The case study database provides an inquiry audit (Hoepfl 1997; Lincoln and Guba 1985; Yin 1994), which consists of raw data, analysis notes, data segmentation and coding products, process and personal notes, and preliminary developmental information. The case study database was implemented using a flatfile system that includes the use of the OpenOffice.org word processor and spreadsheet, to develop tables, matrices and figures. Original transcripts
Chapter 4: Research Methods 94
were developed using transcription software – 'Transcriber' (http://trans.sourceforge.net/en/presentation.php). For compatibility with the transcription software, audio recording from case interviews were converted from 'wav' to 'ogg' audio format using the 'XMMS' (http://www.xmms.org/about.php) audio decoded/encoder. Both formats of the original recordings were retained as part of the case database.
Initially, the data analysis part of the casestudy database was implemented using Nvivo (http://www.qsrinternational.com/products_nvivo.aspx), a computer aided qualitative data analysis system (CAQDAS). However, due to computer failure, and restrictions in portability of the proprietary software license, the use of this software was discontinued. Although Open Source alternatives including Weft QDA (http://www.pressure.to/qda/) and TAMS (http://sourceforge.net/projects/tamsys/) were identified, the lack of adequate software documentation, software complexity, and lack of time for the research to become familiar with the new software led to the use of flat file systems for the case study database.
Case Study Protocol
The case study protocol for this study is important because, first, it keeps the field work focused on the subject of the case study and the research methodology that is set out (Yin 2003). Second, it helps in anticipating several problems such as initial data management and the need to consider the audience for the research prior to report writing. Yin (2003) recommends that the casestudy protocol of a carefully designed research project should have four important elements. These elements are implemented in this study and are discussed below.
The first element was an overview of this study, and includes project objectives and case study issues. Project objectives were first discussed in section 1.4, and also in sections 4.2.2 and 4.2.3, in the justification of qualitative research approach and the choice of a multiplecases study strategy, respectively. Thus, a formal overview of the study has been established.
The second element was to establish field procedures, which give a guideline for conducting field work and dealing with constraints that are associated with the process of data collection (Yin 2003). By considering various field work issues and constraints (Yin 2003), a field procedure for dealing with such constraints is developed as follows.
The first issue was gaining access to key organisations or informants. For this, three documents were created: an information sheet (see, Appendix A.1 – Participant Information K. Mijinyawa
Chapter 4: Research Methods 95
Sheet); consent form (see, Appendix A.2 – Consent Form); and a statement of research ethics approval from the 'Brunel University Research Ethics Committee'. The information sheet was sent to various IT SMEs identified as potential sources of rich information. The IT SMEs were identified mainly through internet directories and by site visits within the local city centre.
Other documents were presented to interview participants for their acknowledgement of research participation.
The second issue was having adequate resources while in the field. Various resources including recording devices, blank tapes, spare batteries, note pad and pen, and logistics arrangements, were organised prior to visiting case sites or arranging interview sessions. The interview participants were also notified of the interview sessions. A digital voice recorder was acquired as a replacement for the tape recorder due to poor quality of audio recording.
The replacement proved effective with clearer recording and better recording editing functions and timing information.
The third issue involved developing a procedure for calling for assistance and guidance. For this, various methods including telephone conversations and email were applied to communicate potential problems to participants or a study supervisor, who could provide assistance, and also discuss progress of the field work.
The fourth issue was providing for unanticipated events, including changes in the availability of interviewees as well as changes in the conditions of the researcher. The scheduling of interviews were made flexible to accommodate changing situations with participants. The research supervisor was also consulted in the event of any constraint or circumstance that hindered the progress of the field work. These issues represent measures for dealing with issues that may constrain the progress of the field work. Therefore, these ensure that adequate contingency plans were considered.
The four issues discussed above establish the field procedures applied in this case study inquiry. Arguably, the procedure established provides a guide for conducting the field work and dealing with constraints, therefore enhancing the validity of the case study design (Yin 2003).
The third element of this case study protocol was to specify field questions which the investigator must keep in mind during data collection. Yin (1994) suggests that case studies need to consider important questions at five different levels. Level one is concerned with
Chapter 4: Research Methods 96
questions asked of interviewees (see, for details, Appendix A3 – Interview Questions), which explore information regarding participants' reactions and feeling; changes in attitudes, perceptions or knowledge; changes in skills, and effectiveness of their use of OSS). Level two is concerned with questions asked of an individual case study (see, research question in section 1.4) and provides an analytical view of OSS adoption within individual case organisations. Level three is concerned with questions asked across multiplecase enquiries (see, also, research question in section 1.4), and provides a crosscase view of OSS adoption by the participant IT SMEs. Level four is concerned with questions asked of this entire study and provides an answer to the research question, research aim and objectives (in section 1.4).
Level five is concerned with questions asked that lead to research recommendations and conclusions beyond the scope of the study, which will be addressed during discussions about the research findings in Chapter 6 and conclusions drawing in Chapter 7.
The fourth element of this casestudy protocol was a guide for the case study. The guide developed for this study includes an outline and format for the case study narrative. This element is addressed in section 4.5.2 and 4.5.3 in the discussions on data displays and conclusions drawing.