Managing Uncertainty in Globally Distributed Software Development Projects

(1)

Managing Uncertainty in Globally Distributed

Software Development Projects

Darja Šmite, Juris Borzovs

University of Latvia Raia bulv. 19, LV-1586, Rga, Latvia

{Darja.Smite, Juris.Borzovs}@lu.lv

Abstract. Global software development is not a phenomenon but a reality

nowadays. However, it is still poorly explored. Lack of awareness of the particular factors inherited in the nature of globally distributed software projects makes practitioners struggle and invent new approaches to survive. It uncovers the necessity to support risk management activities. This paper describes a Knowledge Base and a Risk Barometer developed to support practitioners who lack experience in global projects. Particularities of globally distributed projects and their effect on project performance are formalized in a reusable framework for managing uncertainty. The described tools provide input for risk identification and help to evaluate risks based on the experience from former projects.

1 Introduction

Global Software Development (GSD; also known as Global Software Engineering (GSE), and Globally Distributed Software Development (GDSD)) has become the key trend in the area of software engineering. It is motivated by the opportunities of reaching mobility in resources, obtaining extra knowledge, speeding time-to-market, and increasing operational efficiency. And yet, GSD is accompanied by both opportunities and problems. Many specialists recognize globally distributed software development as more complex than even the most complex project managed entirely in house [8], [6]. Globally distributed software development expands the concept of traditional outsourcing and addresses transition of common in-house manner of software development to more complex software life cycle activities distributed among teams separated by various boundaries, such as contextual, organizational, cultural, temporal, geographical, and political. This type of development environment can therefore be characterized by its heterogeneity, virtualness, and inter-organizational collaboration that are impediments for effective communication and cooperation of the teams involved in completion of a joint project. New unique pressures of project management that appear to have nothing to do with the technical nature of the project and at the same time are reasons that can doom a virtual project is something even capable managers often overlook [8]. Practitioners claim that they have to experiment and quickly adjust their tactical approaches for leveraging global software development risks [2]. Researchers admit that although a body of knowledge

LURaksti733-datorzin.indd 9

(2)

on global software development has been crafted over time, the art and science of organizing and managing globally distributed software development is still evolving [4]. However, despite the fact that global software development is said to be different from common in-house software development projects [11], [9], [8], peculiarities of globally distributed software projects have not been explicitly formalized.

Risk analysis concepts have been applied to identify and evaluate particular negative events that might cause globally distributed software project failure. Threats that endanger globally distributed software project success are found to be quite distinctive from in-house project threats. Global risks are proved as just the part of everyday existence that cannot be avoided [11], [10], and must be confronted on a continuous basis. However, empirical results that would help evaluating the magnitude of consequences of these environmental factors and threats provide contradictious views. In addition, related studies describe [3] that as simple as it sounds, many organizations are unable to manage risks effectively. Accordingly, the research described in this paper (also published in related research papers [12] and [13]) focuses on exploring the unique threats of globally distributed projects, effect of these threats on project performance, and ways to overcome these threats before they lead to project failure.

2 Research Methodology

2.1 Grounded Theorizing

Grounded theory building methodology developed by Glaser and Strauss [5] was chosen as the basis for the study. This methodology introduces a qualitative approach that generates theory from observation [14]. Theory-creating studies are very suitable for exploratory investigations, i.e., when there is no prior knowledge of a part of reality or a phenomenon [7]. Grounded theories, because they are drawn from data, are likely to offer insight, enhance understanding, and provide a meaningful guide to action [15].

Understanding of global factors and threats evolved grounded by systematically gathered and analyzed data about the phenomenon. The data was gathered from a variety of sources, including qualitative interviews and enhanced analysis of related research literature. Data analysis was performed according to principles prescribed by grounded theory through applying open, axial, and selective coding techniques [14], also called as theoretical sampling. A Lotus Notes-based database was used for data maintenance facilitating in easy categorization.

(3)

2.2 Data Sources

Various data sources were used for building the theory, including qualitative interviews with experienced project managers from the investigated software house, research literature (journal articles, papers form conference proceedings), and books on global software development.

We conducted 13 interviews with 9 project managers, who represented all software development departments of the investigated software house running projects with customers from different remote locations and were appointed by the heads of departments as the most experienced ones. The interviews were held by means of semi-structured interviewing and open questions. The interviews were written down for further analysis.

We performed an extensive literature analysis using input from 33 research articles on global software development published in the related conference proceedings and journals such as IEEE Software, and Communications of ACM.

Literature analysis and interviews with experienced project managers provided a representative input regarding the phenomenon under study.

2.3 Data Analysis

We created a Lotus Notes based database to maintain the gathered data items and support data analysis. Sources of information and each data analysis iteration results were kept within the certain item’s history for traceability opportunities.

Data analysis started with an open coding for data breaking down, examining, comparing, conceptualizing, and categorizing. While examining data sources, expressions related to particular project characteristics, different negative events, consequences or practices were identified and labelled. Data analysis resulted in total of 253 GSD related issues, which were then stored into the database. Open coding then continued with categorizing. Each issue at the beginning represented a single category, the existing labels then were analyzed in order to identify issues that are similar in meaning. Those were then grouped under more general concepts called "categories". E.g., the labels “Cultural barriers”, “Cultural distance”, and “Poor cultural fit” were coded under a joint category “Poor cultural fit”.

This reduced the number of GSD related categories to 163.

Examination of the existing categories showed that many issues were interrelated and formed cause-effect interconnections. Axial coding was used for deriving connections between the existing categories and the risk management concepts, during which the identified GSD related issues from open coding were categorized into a hierarchy of sub-categories as follows:

x Global factors – root of global threats, that distinguish global projects;

x Global threats – items or activities that have potential for negative consequences and result from one or a combination of global factors;

x Consequences – negative outcome of a threat; x Practices – recommendations for leveraging the risks.

Selective coding was used for systematically validating relationships and filling in categories that needed further refinement and development. Axial coding showed that

(4)

some of the existing categories had to be reconsidered. For some categories identified during open coding this meant dividing into two or even more categories.

E.g., the category “E-mail communication causes time delays and misunderstandings” was divided into “E-mail communication” – a threat, and “Time delays” and “Misunderstandings” – consequences. “E-mail communication” was then united with one of the more general existing categories – “Asynchronous communication”. The relations between the three categories were then produced.

Refining the dependences between the new issues and tagging the categories with the sources were performed through selective coding.

To strengthen the results of this study regarding global factors and threats, only items that appeared more than once were selected, i.e. the threats that are strongly dependent on particular environment were omitted. Due to the industrial background of the research, customer related issues were also omitted after data analysis. New versions of records were processed, saving the history and notes reflecting the decisions within the database.

2.4 Results

Grounded theorizing resulted in 7 global factors, 32 supplier related threats, 7 supplier related major consequences, and 32 supplier related practices (for more detail see the following chapters). As the theory has been built, we conclude that the most valuable results refer to global factors and threats. In its turn consequences and relationships between the global factors, threats, and consequences are weak and inconsistent. Therefore, we conducted a survey on 38 globally distributed projects to validate these considerations empirically and improve the theory.

3 Particularities of GSD Projects

The nature of global software development brings forward new areas of concern that require careful attention from project managers. Practitioners that have for a long time successfully managed in-house projects, now face new challenges that make them struggle to bring the projects to the end within the budget, time schedule, and with the satisfied customers. One may think that the influence of globalization on software development remains limited by distributing end customers from their software development suppliers and at the same time having no effect on the life cycle processes. However, the concept of globally distributed software development prescribes separated teams from different organizations and/or locations work together on a joint project execution. These organizations form supply chains of different complexity thus increasing the complexity of software process distribution.

(5)

3.1 Global Factors

The major distinguishing factors of globally distributed software projects identified by this research are the following [12]:

x Multisourcing – multiple distributed member involvement in a virtual team that develops software by joint effort, characterized by a number of collaboration partners;

x Geographic distribution – distance between the partners involved in the project;

x Temporal diversity – the level of working hours overlay, which most frequently differs from exact time zone differences;

x Socio-cultural diversity – level of social, ethnic, and cultural fit that can differ even between the teams from one national location;

x Linguistic diversity – language difference, characterized by the level of language skills of the project members;

x Contextual diversity – the level of organizational fit or heterogeneity, characterized by diversity in process maturity and inconsistency in work practices;

x Political and legislative diversity – level of legislative consistency and sources of political threat.

Inter-organizational projects involve joint inter-organizational resources and are developed by global software teams also referred to as virtual teams. Accordingly, software processes are distributed between the remote team members and are affected by organizational work practices and habits. The differences between in-house and globally distributed projects can be also illustrated as follows (see Fig.1 and Fig.2).

Fig. 1. Intra-organizational projects

Fig. 2. Inter-organizational globally distributed projects

(6)

Global factors inherited in the nature of GSD projects are recognized as roots of global threats that can endanger the success of a global project. They indeed demonstrate the peculiar nature of globally distributed software development and indicate the forces that act as impediments during a project. Each of the global factors and their combination causes various threats and conditions for negative outcomes.

Therefore we emphasize the uniqueness of globally distributed environment and mark that awareness of global factors that are inherited in the nature of globally distributed project environment can help practitioners either reduce the probability or the magnitude of unexpected negative outcomes. However, if the global factors exist, they often cannot be avoided.

3.2 Global Threats

Global factors characterize different impediments for joint collaboration grounded in different types of diversity existent between the remote partners. These factors have considerable impact on the software life cycle processes. To limit or avoid the impact of global factors, project managers require knowledge on what to be aware of. Accordingly, in order to support project managers in timely risk management, we have collected information on global threats that endanger global projects. Global threats discovered within the research are as follows [12]:

x Customer has complex hierarchy and/or several problem escalation levels x Supplier has complex hierarchy and/or several problem escalation levels x Diversity in process maturity and/or inconsistency in work practices x Lack of understanding of each other’s context of decision making

x The customer believes that the work cannot be done from a far off location x Lack of trust and commitment

x Increased cost of logistics of holding face to face meetings x Increased level of reporting on project progress to the customer x Increased virtualness

x Lack of language skills by supplier x Terminology differences

x Customer’s employees unwillingness to collaborate caused by threat of being fired due to switching to outsourcing mode

x Faulty effort estimates

x Increased level of complexity of project management x Increased level of unstructured poorly-defined tasks

x Increased complexity of spreading awareness and knowledge x Lack of common goals

x Lack of experience and expertise of the customer with outsourcing projects x Lack of experience and expertise of the supplier with outsourcing projects x Lack of joint risk management

x Lack of team spirit

x Poor or disadvantageous distribution of software development activities x Relatedness with other suppliers

(7)

x Poor cultural fit

x Dominant use of asynchronous communication with the customer x Time zone difference

x Lack of clarity about responsibility share x Poor or complex project measurement

x Increased complexity of project, activity, human resources, and delivery planning

x Poorly defined or inconsistent SRSs

x Poorly defined or inconsistent software design and/or architecture x Poor artefact version control

The identified global threats are not categorized according to their root factors, because a threat can be caused by a combination of global factors. These threats also tend to be general. We aimed to avoid too detailed categorization of the threats to eliminate the complexity of correlated threat hierarchy. It also relieves the process of threat identification – too long checklists with odd issues are rarely used.

Accordingly, this list of threats does not comprise all possible negative events that can endanger a global project. However, it is a useful guide to risk management that is based on previous experiences.

4 Outcome Predictions in Global Projects

As previously emphasized, awareness of global factors and threats is essential for global project success. However, knowing about possible threats does not mean that organizations can evaluate the extent of each factor and threat. Limited experience and expertise in globally distributed software development often drives organizations to sudden problems due to underestimation of the hidden threats. Accordingly, awareness of the negative outcome of each factor plays an important role in estimating its severity.

We therefore offer an experience-based risk-oriented approach to leverage global threats [13]. Traditional risk management concepts in this approach are introduced by components that characterize the effect of global threats on project performance. These are: probability of a threat to endanger a certain project success criteria and the magnitude of the negative outcome of a threat. We additionally calculate the probability of negative outcome for each threat based on global project survey data, which extends traditional risk analysis concepts and introduces an approach to calculate future outcome predictions.

Experience data for effect evaluation were collected through a survey of global software projects run by Latvian software houses. We have gathered data from 38 globally distributed software projects that provide a representative insight in what and how endanger global projects considering specifics of Latvia.

(8)

4.1 Basic Concepts

Software risk management can be defined as an attempt to formalize risk oriented correlates of development success into a readily applicable set of principles and practices [1]. However, practitioners often misuse risk terminology. Therefore the basic concepts and rules are defined as follows:

1) Term threat is used to describe possible negative events that can lead a project to its failure. E.g. Lack of experience with outsourcing projects.

2) Each threat has its probability of occurrence evaluated through the frequency of occurrence within the surveyed projects.

3) Each threat is evaluated for its negative outcome. The following criteria are used in negative outcome evaluation for this research 1_:

x Budget overrun;

x Unexpected management costs; x Customer cost escalation; x Time delays;

x Late product delivery; x Customer dissatisfaction;

x Supplier team’s undermined morale; x Disputes and litigations.

4) A threat can cause different levels of negative outcome. E.g. dominant asynchronous communication may cause considerable time delays, but insignificant temporal distance only minor delays.

5) Evaluation of the level of negative outcome of the threat is called magnitude of the negative outcome. To conform to traditional risk management concepts, magnitude of the negative outcome is calculated for each pair [threat; consequence]. In other words, the threat of poor cultural fit can cause e.g. minor time delays, considerable customer dissatisfaction, disastrous undermined morale of the supplier team and none effect on other success criteria.

6) Magnitude of the negative outcome and frequency of occurrence are evaluated according to a quantitative scale with an equivalent qualitative scale for interpretation as seen in Table 1.

1_{Project compliance with budget and schedule, customer satisfaction and software product}

quality are the major success criteria for the project according to related literature. However, software product quality was not included in the list of indicators due to high risk of bias of the given evaluation. On the other hand, the list of project success criteria was extended due to the following reasons:

x Differentiation of causes of budget overrun;

x Time delays have been emphasized as a source of downtime, which does not obligatory drive to late product delivery;

x Supplier team’s undermined morale is an important success criteria considering the industrial research background (supplier side of the project);

x Disputes and litigations are also possible negative outcomes that were additionally explored as possible causes of project cancellation.

(9)

Table 1. Rating scales Magnitude of the negative

outcome 0 1 2 3 4 5 None Negligible Minor Moderate Significant Disastrous Frequency of occurrence Probability 0 (0-10%] (10-20%] (20-40%] (40-80%] (80-100%] Improbable Doubtful Unlikely Possible Probable Certain

7) The combination of Magnitude of the negative outcome and frequency of its occurrence (for each pair [threat; consequence]) form risk exposure [1] that is widely used in traditional risk comparison and prioritization. Multiplication can be used for quantitative evaluation, and matrixes for qualitative evaluation. Accordingly it helps to identify threats that have the most severe effect on the project performance separately for budget overrun, time delays, customer dissatisfaction, etc.

4.2 Approach to Calculate Outcome Predictions

In order to support risk management activities for practitioners, Probability of negative outcome is evaluated using frequency of occurrence of the negative outcome of the threat on the certain level by computing frequencies of lower effect levels with those of higher effect levels, in other words cumulative values, according to the following equation [13]:

5

Prob (t, ci,j) =

Freq (t, ci,k) k=j

(1) Variables and functions:

t – threat;

ci,j – outcome, where first index indicates the certain negative outcome (budget overrun, time delays, etc.) and the second – its level (1, 2, 3, 4 or 5)

Freq (t, ci,j) – frequency of occurrence of the negative outcome of the certain level of the certain threat;

Prob (t, ci,j) – probability of the negative outcome of the certain level of a threat.

(10)

4.3 Survey Overview

The previously compiled list of threats was offered to various project managers and team leads for evaluation. Representative data set was collected using a survey instrument by mailing the developed questionnaire to a selected sample of employees in the investigated company, whose job title was project manager or equivalent, e.g., development manager or development team leader. In addition, the questionnaire was made accessible in other 4 small software houses, where the project managers could participate in the survey if interested.

The complexity of lifecycle distribution in the investigated projects varied from direct subcontracting to a complex chain of 10 subcontractors involved in completion of a joint project. Respondents‘ experience varied from 3 to 30 years. Other characteristics considering the investigated projects under study are given in Table 2.

Table 2. Characteristics of the Surveyed Projects

Characteristics Survey results

Collaboration type

Describes entities involved in the joint project, e.g. customerÆ supplier (1Æ1), or customer Æ multiple suppliers (1ÆN)

1Æ1Æ1 13 projects

1Æ1 10 projects

1ÆN 7 projects 1Æ1ÆN 6 projects 1ÆNÆN 2 projects

Number of partners 2 11 projects

3 16 projects

4 3 projects

more than 4 5 projects Successful: 15,8% 10 9 4 projects 2 projects Somewhat successful: 50,0% 8 7 7 projects 12 projects Project success

Subjective evaluation given by the project managers considering budget and calendar compliance, and customer satisfaction,

using the scale 1-10. Unsuccessful:

34,2% 6 5 4 3 1 5 projects 4 projects 2 projects 1 project 1 project The following data were gathered during the survey:

x Project characteristics (collaboration model, project activity distribution, location of partners, project type, project status, success evaluation, etc.); x Report of frequency of occurrence of the listed threats in the projects; x Evaluation of the impact of each experienced threat on the project results.

(11)

4.4 Survey Data Analysis

Survey data were kept in and analyzed using SPSS ® 14.0 tool2_{, which provided a} broad range of capabilities for the entire analytical process, including easy data search and categorization, powerful statistics, tabular and graphical representation of the results. Data was recorded within 316 variables.

Quantitative analysis of 38 globally distributed project survey data was performed to evaluate the effect of global factors and threats on GSD project performance. Survey responses have been statistically analyzed to compute the following values for each threat:

x Frequency of occurrence; x Average outcome;

x Probability of certain level of the certain negative outcome.

Frequency of occurrence is based on the historic information from the survey. Average outcomes of a threat are minimum conditions that practitioners have to take into account while collaborating in the globally distributed project environment. Survey data contain evaluation of the magnitude of the negative outcome of each threat. Magnitude of the negative outcome of each threat is evaluated using a linear scale: [0, 1, 2, 3, 4, 5] or its equivalent [None, Negligible, Minor, Moderate, Significant, Disastrous] as described earlier.

Probability of certain level of the negative outcome or negative outcome predictions are evaluated as cumulative values using frequency of occurrence of each threat to cause negative outcome of a certain level by computing frequencies of lower levels of impact with those of higher according to the definition given above.

4.5 Risk Barometer

Considering the length of the list of global threats and complexity of risk analysis, we developed a tool that computerizes project outcome predictions correspondingly labelled as “Risk Barometer” [13].

Risk Barometer is developed as a Lotus Notes based function aiming to support outcome predictions in global projects especially for project managers who lack awareness of possible negative events and their consequences in globally distributed environment. Risk Barometer performs its predictions on the basis of historical data from post-project risk evaluation reports. Risk Barometer and historical data is integrated in the Knowledge Base that serves as a central repository for organizational learning support. The survey provided the first input for outcome predictions from anonymous survey data gathered during the research and kept within the Knowledge Base. New project experiences can be added to continuously support Risk Barometer prediction improvements.

Risk Barometer is intended for project managers to evaluate global project threats, considering the probability of occurrence and possible negative impact that can be compared with historical data from other projects. We foresee that hidden threats and their outcomes, such as hidden costs, unobvious sources of time delays and customer

2_{SPSS Software Solutions Online – http://www.spss.com/}

(12)

dissatisfaction, will help inexperienced project managers prepare against impediments inherited in the nature of globally distributed projects.

An example of Risk Barometer predictions for a threat of lacking experience and expertise in outsourcing projects can be seen in Fig.3.

Fig. 3. Example of predictions by the Risk Barometer: for a threat

5 Discussion

5.1 Particularities of Global Projects

The derived lists of global factors and threats make the peculiarity and complexity of globally distributed software development obvious. Global software development puts new demands on the software processes stressed by an increased complexity of project coordination (through temporal and geographical distances), communication (lacking proximity and cultural diversity), cooperation (lacking trust and

(13)

commitment), infrastructure management (uniting heterogeneous contexts) and other aspects of distributed software development. The global factors characterize the distinguishing nature of globally distributed software development projects by emphasizing unavoidable elements that are inherited in this kind of work environment and shall be analyzed throughout the project.

The list of global threats provides guidance for effective risk identification and demonstrates the various ways that global factors may act. This knowledge is especially demanded by practitioners that lack previous experiences in developing software with globally distributed partners.

Furthermore, practices applied for global risk mitigation shall act as a counterforce against global threats and reduce the effect of global factors and threats on project results (see Fig.4).

Fig. 4. Project practices as a counterforce for global threats

The extent of the effect of global factors and threats on project results shows that they indeed may drive projects to failure if not managed on time. Global threats may lead to a considerable negative outcome on project budget, cause calendar deviations and customer dissatisfaction.

5.2 Application of Risk Barometer

Risk Barometer provides a general overview of the outcome of each threat and probability of its occurrence. Since global projects are so different and the extent of global factors may influence occurrence of global threats in particular circumstances, project managers may not ground their risk predictions only on personal experience. It is therefore recommended to use an experience-based approach to analyse global risks and monitor them on a regular basis among different projects in an organization.

Application of Risk Barometer is feasible in any global project despite its size and complexity. Global factors and threats inherited in the nature of globally distributed environment will not vanish if the project will last only a month or consider a well-known task that shall be performed by well-trained developers. Project managers shall use outcome predictions to see what kind of effect they may cause and report on real situation after the end of the project.

Risk Barometer can also be used to evaluate the sources of necessary investments in globally distributed projects by analyzing sources of budget overrun, unexpected management costs, and customer cost escalation. It can be also useful to point out sources of time delays for better effort estimation.

(14)

Conclusions

The results of the research reported in this paper support conclusion that globally distributed software development significantly differs from in-house software development [12]. Global factors and threats provide a valuable ground for effective risk identification supplemented by project outcome predictions that support further risk analysis for practitioners. In contradiction to many studies conducted from the customer perspective, this study investigates and includes global project problems from supplier perspective thus providing a useful support for Latvian and other software houses that operate as outsourcing service providers.

GSD project case studies range from announcements of tremendous success to total failure. No research so far has provided a clear vision of the true amount of investments necessary to make global software projects work. Risk Barometer forms a ground for an experience-based risk-oriented approach for GSD project outcome evaluation [13]. The results of Risk Barometer performance include observations of budget, schedule, and customer satisfaction threats – their significance and historical frequency of occurrence. Risk Barometer extends the traditional risk analysis approach and provides automatic prediction calculations on the basis of previous project data.

Acknowledgments: The authors appreciate valuable research input received from the project managers within the investigated software house. This research is partly supported by the European Social Fund and the Latvian Council of Science project No. 02.2002 “Latvian Informatics Production Unit Support Program in the Area of Engineering, Computer Networks, and Signal Processing”.

References

[1] Boehm B.W., “Software Risk Management: Principles and Practices”, IEEE Software, Vol. 8, No.1, 1991, pp. 32-41

[2] Carmel, E., Agarwal, R. “Tactical Approaches for Alleviating Distance in Global Software Development”, IEEE Software, Vol. 18, No. 2, 2001, pp.22-29 [3] Carr M.J., “Counterpoint: Risk Management May Not Be for Everyone”, IEEE

Software, Vol.30 No.5, 1997, pp. 21-24

[4] Damian D. and Moitra D., “Global Software Development: How Far Have We Come?”, IEEE Software, Vol. 23, No.5 2006, pp.17-19

[5] Glaser B., Strauss A. “The discovery of grounded theory: Strategies of qualitative research”, Wiedenfeld and Nicholson, London, 1967

[6] Iesalnieks J., Gulbe B. “Old and New Europe as IT Partners”, Baltic IT&T Review, Nr.2 (33), 2004, pp.38-40

[7] Jarvinen P. “On Research Methods”, Opinpajan Kirja, Tampere, 2001

[8] Karolak D.W., “Global Software Development: Managing Virtual Teams and Environments”, IEEE Computer Society, 1998

[9] Merriam-Webster Online Dictionary. Available online www.m-w.com

(15)

[10] Pavlovs S., “ , ” Baltic daily / 25.04.2005, Nr.78, pp.5

[11] Sahay S., Nicholson B., Krishna S., “Global IT Outsourcing: Software Development across Borders”. Cambridge University Press, 2003

[12] Smite D., Borzovs J., „A Framework for Overcoming Supplier Related Threats in Global Projects”, In Proceedings of the Int. Conf. on European Software Process Improvement (EuroSPI), published in LNCS by Springer Verlag, October 2006, Finland, pp. 49-60

[13] Smite D., “Project Outcome Predictions: Risk Barometer Based on Historical Data”, In proceedings of the Int. Conf. on Global Software Engineering (ICGSE) by IEEE Computer Society, August 2007, Germany, pp.103-112

[14] Strauss A., Corbin J. “Basics of Qualitative Research – Grounded Theory Procedures and Techniques”, Sage Publications, Newbury Park Ca, 1990

[15] Strauss, A., Corbin, J., “Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory”. Thousand Oaks, CA: Sage Publications, 1998