Copyright is owned by the Author of the thesis. Permission is given for a copy to be downloaded by an individual for the purpose of research and private study only. The thesis may not be reproduced elsewhere without the permission of the Author. i KEY SUCCESS DRIVERS IN OFFSHORE SOFTWARE DEVELOPMENT: NEW ZEALAND AND INDIAN VENDORS’ PERSPECTIVES A thesis presented in partial fulfilment of the requirements for the degree of DOCTOR OF PHILOSOPHY in Information Technology at Massey University, Albany campus, New Zealand Anuradha Mathrani 2009 ii iii KEY SUCCESS DRIVERS IN OFFSHORE SOFTWARE DEVELOPMENT: NEW ZEALAND AND INDIAN VENDORS’ PERSPECTIVES ABSTRACT Offshore software development (OSD) is a leadin g business sector in the present ‘glocal’ IT marketplace, and vendors in different countri es are opening software development centres worldwide to take advantage of the new business opportunities. However, software development is both a technical and a social process as various software modules need to be integrated, which requires ongoing interaction between the stakeholders. The software modules rely upon local knowledge regarding customer wants, project specific features, chosen design methodologies by development team members and synchronisation of activities to confirm the next design iterati on. This study focuses on knowledge sharing processes involving the interplay between acquiring local knowledge and applying the knowledge acquired into the design of the client-specific software builds. New knowledge is created as new processes are applied and new outcomes realised, resulting in re-definition of software development practices. Building on existing theories with empirical case study evidence, this research reveals the socio-technical influences on knowledge management in the OSD process. Ideographic research methods have been applied to bring sensitivity in the everyday organisational activities for knowledge sharing across diverse social and cultural groups within two country contexts (New Zealand and India). Empirical data from ten case studies is used to inductively develop a conceptual framework, whic h has been applied to make within case and cross case comparisons across three levels of analysis (micro, meso and macro) for knowledge sharing. The micro level analysis explores individual key success drivers (behaviours and methodologies), the meso level explores organisational level practices (work processes and structures) and the macr o level gives a holistic evaluation across two country contexts. iv Country contexts reveal that New Zealand vendors share closer cultural proximity with their clients, are engaged in client facing skills and have further outsourced software development tasks to other low cost countries. The Indian vendors are involved in software construction, prefer technical specialist skills and have defined more discipline in their software development processes. The thesis offers new insights on how vendors’ shape their software development styles based upon their beliefs and understanding of the offshore market and is especially relevant to both vendors and clients who intend venturing into the offshore market. v ACKNOWLEDGEMENTS In the period of my PhD study, there have been many people who have contributed with their time, knowledge and support. First and foremost, I would like to thank my supervisor, Dr David Parsons for his time, enthusiasm, constructive feedback and words of encouragement during a long process. I am also very grateful to my co-supervisor Dr Rosemary Stockdale for her helpful and challenging comments which helped me to critique my work. I would also like to thank my second co-supervisor Dr Dennis Viehland for providing clarity in research writing skills. I would also like to thank all interviewees and other employees from outsourcing government consortiums who provided valuable contributions to this dissertation project. Unfortunately I cannot name them for anonymity reasons. Lastly and most importantly, I wish to thank my husband Sanjay and my son Akarsh for their encouragement and constant support. Had it not been for their patience and understanding, this thesis would not have been possible. vi vii TABLE OF CONTENTS ABSTRACT....................................................................................................................... ..........iii ACKNOWL ED G E M E NTS .......................................................................................................... v TABLE OF CONTENTS ............................................................................................................vi i LIST OF TABLES ................................................................................................................. .... xiii TABLE OF FIGUR E S ............................................................................................................... xiv CHAPTER ONE – Introduction.................................................................................................... 1 1. 1 Introduction .............................................................................................................. .............. 1 1.2 Off-shoring – economics or sociology? .................................................................................. 2 1.3 Distributed software development........................................................................................... 4 1.4 Current research on international outsourcing ........................................................................ 5 1.5 Comparison of India and New Zeala nd as outsourcing vendor destinations .......................... 8 1.5.1 I NDIA ...............................................................................................................................................8 1.5.2 N EW Z EALAND ..............................................................................................................................1 0 1.5.3 I NDIA VIS - A- VIS N EW Z EALAND ...................................................................................................11 1.6 Background to the research problem..................................................................................... 12 1.7 Research questions ......................................................................................................... ....... 13 1.8 Contribution of the thesis ................................................................................................. ..... 14 1.9 Roadmap of study........................................................................................................... ....... 16 1.10 Thesis outline ............................................................................................................ .......... 18 CHAPTER TWO – Literature Review........................................................................................ 20 2.1 Introduction ............................................................................................................... ............ 20 2.2 Offshore outsourcing environment........................................................................................ 21 2.2.1 D EFINITION ....................................................................................................................................21 2.2.2 S YNTHES IS OF OUTSOURCING CONCEPTS USE D IN LITERATURE ......................................................22 2.2.2.1 Organisational arrangements in outsourcing .......................................................................22 2.2.2.2 Categories of outsourcing vendors: ......................................................................................24 viii 2.3 Outsourcing stages ......................................................................................................... ....... 25 2.4 Offshore software development processes............................................................................ 30 2.5 Virtual teams.............................................................................................................. ........... 32 2.6 Key drivers in knowledge transfer for offshore software development................................ 34 2.6.1 CULTURE ...................................................................................................................................... 36 2.6.2 COMMU N ICATION ......................................................................................................................... 41 2.6.3 R ELATIONSHIP BUI LDI N G .............................................................................................................. 43 2.6.4 TRUST ........................................................................................................................................... 45 2.6.5 CONTROL AND COORD INATION ..................................................................................................... 48 2.6.6 R EQUIR E MENTS MANAGEME NT ..................................................................................................... 51 2.6.7 PROJECT MANAGEMENT ................................................................................................................ 52 2.6.8 S TAFF ATTRITION .......................................................................................................................... 54 2.6.9 Q UALITY MANAGEMENT ............................................................................................................... 56 2.6.10 TYPES OF CONTRACT ................................................................................................................... 57 2.7 Knowledge management....................................................................................................... 58 2.8 Knowledge management in offs hore software development ................................................ 62 2.9 SECI model................................................................................................................. .......... 64 2.10 Structuration theory ...................................................................................................... ...... 66 2.11 Implications of OSD drivers to this research study ............................................................ 68 2.12 Conclusion ................................................................................................................ .......... 71 CHAPTER THREE – Research Methodology ........................................................................... 72 3.1 Introduction............................................................................................................... ............ 72 3.2 Research questions......................................................................................................... ....... 74 3.3 Researcher ’s role.......................................................................................................... ......... 75 3.4 Rationale for mixed research approach................................................................................. 76 3.5 Rationale for case study method ........................................................................................... 7 7 3.6 Relevance and rigour ....................................................................................................... ..... 79 3.7 Research design ............................................................................................................ ........ 81 3.7.1 U NIT OF ANALYSIS ........................................................................................................................ 83 3.7.2 Q UALITY OF RES EARCH DESI GN .................................................................................................... 84 3.7.2.1 Construct validity ................................................................................................................. 84 3.7.2.2 Internal validity.................................................................................................................... 85 3.7.2.3 External validity ................................................................................................................... 86 3.7.2.4 Reliability ............................................................................................................................. 86 3.7.3 S ELECTION OF CASES .................................................................................................................... 87 ix 3.7.4 TRIANGULATION ............................................................................................................................91 3.7.5 A PRIORI SPECIFICATION OF CONSTRUCTS .....................................................................................92 3.7.6 CONTEXT OF THE CASE STUDY .......................................................................................................93 3.7.7 R ESEARCH DES IGN CHECKLIST .......................................................................................................95 3.8 Data collection process.................................................................................................... ...... 96 3.8.1 E THICAL ISSUE S IN DATA COLLECTION ..........................................................................................97 3.8.2 CASE STUDY PROTOCOL .................................................................................................................98 3.8.3 CASE STUDY DATABASE .................................................................................................................99 3.8.4 PILOT STUDY ...............................................................................................................................100 3.8.5 M AIN STUDY ................................................................................................................................101 3.8.6 D ATA COLLECTION CHECKLIST ....................................................................................................103 3.9 Data analysis .............................................................................................................. ......... 104 3.9.1 D ATA ANALYSIS CHECKLIST ........................................................................................................108 3.10 Case study report ......................................................................................................... ...... 109 3.11 Methodological model of the study................................................................................... 111 3.12 Conclusions ............................................................................................................... ........ 114 CHAPTER FOUR – Conceptual Framework ........................................................................... 116 4.1 Introduction ............................................................................................................... .......... 116 4.2 Research method employed for the pilot study ................................................................... 116 4.3 Background of pilot cases .................................................................................................. . 118 4.3 Background of pilot cases .................................................................................................. . 119 4.3.1 PILOT -NZ-S MALL ........................................................................................................................119 4.3.2 PILOT -NZ-M ED ...........................................................................................................................120 4.3.3 PILOT -IN-M ED ............................................................................................................................122 4.4 Organisation culture and structure of pilot cases ................................................................ 123 4.5 Empirical findings from the pilot study .............................................................................. 124 4.5.1 K EY DRI VERS FOR KN O WL EDG E FLO W .........................................................................................125 4.5.2 K EY DRI VERS IN RELATIONSHIP BUILD I NG ...................................................................................130 x 4.6 Cross case comparis on of pilot cases.................................................................................. 132 4.7 Systematic combining of literature and empirical findings ................................................ 134 4.8 Conclusions................................................................................................................ ......... 137 CHAPTER FIVE – The Case Studies....................................................................................... 139 5.1 Introduction............................................................................................................... .......... 139 5.2 Case repor t format............................................................................................................... 139 5.3 Case vignettes ............................................................................................................. ........ 141 5.3.1 NZ1 ............................................................................................................................ ................ 141 5.3.2 NZ2 ............................................................................................................................ ................ 141 5.3.3 NZ3 ............................................................................................................................ ................ 142 5.3.4 NZ4 ............................................................................................................................ ................ 142 5.3.5 NZ5 ............................................................................................................................ ................ 143 5.3.6 IN1 ............................................................................................................................ ................. 143 5.3.7 IN2 ............................................................................................................................ ................. 144 5.3.8 IN3 ............................................................................................................................ ................. 145 5.3.9 IN4 ............................................................................................................................ ................. 145 5.3.10 IN5 ............................................................................................................................ ............... 146 5.4 Interview settings ......................................................................................................... ....... 146 5.5 Outsourcing arrangements .................................................................................................. 1 47 5.6 Embedded case design ....................................................................................................... . 149 5.7 Organisational or meso level dimensions ........................................................................... 150 5.7.1 O RGANISATIONAL SIZE ............................................................................................................... 151 5.7.2 M ULTI CULTURAL ....................................................................................................................... 152 5.7.3 TYPES OF CONTRACTS ................................................................................................................. 153 5.8 Vendor groups.............................................................................................................. ....... 154 5.9 Chapter summary ............................................................................................................ .... 155 CHAPTER SIX – Micro Level Analysis for Transfer of Tacit Knowledge ............................. 156 6.1 Introduction............................................................................................................... .......... 156 6.2 Knowledge assets: tacit and explicit knowledge................................................................. 157 6.3 Drivers for transfer of tacit knowledge ............................................................................... 158 6.4 Empirical observations on the drivers for transfer of tacit knowledge ............................... 160 6.4.1 COMMU N ICATION STRATEGIES ................................................................................................... 161 6.4.1.1 Case data report on communication strategies.................................................................. 163 6.4.1.2 Summary of communication strategies............................................................................... 175 xi 6.4.2 D OMAIN SKIL LS ...........................................................................................................................177 6.4.2.1 Case data report on preferred domain skills ......................................................................178 6.4.2.2 Domain skills summary.......................................................................................................183 6.4.3 R EQUIR E MENT VOLATILITY MANAGEMENT STRATEGIE S ..............................................................185 6.4.3.1 Case data report on requirement volatility management strategies ...................................186 6.4.3.2 Summary of requirement volatility management strategies ................................................187 6.5 Important drivers for tacit knowledge transfer .................................................................... 187 CHAPTER SEVEN – Micro Level Analysis fo r Management of Explicit Knowledge ........... 191 7.1 Introduction ............................................................................................................... .......... 191 7.2 Drivers for management of explicit knowledge .................................................................. 192 7.3 Empirical observations on the drivers for management of explicit knowledge .................. 194 7.3.1 Q UALITY PROCESS MANAGEMENT ...............................................................................................195 7.3.1.1 Case data report on quality processes ................................................................................196 7.3.1.2 Summary of quality processes.............................................................................................201 7.3.2 S OFTWARE PROJECT MANAGEMENT .............................................................................................203 7.3.2.1 Case data report on software project management ............................................................204 7.3.2.2 Summary of software project management processes.........................................................214 7.3.3 S TAFF ATTRITION MANAGEMENT .................................................................................................215 7.3.3.1 Case data report on staff attrition management .................................................................217 7.3.3.2 Summary of staff attrition management ..............................................................................226 7.4 Important drivers for manage ment of explicit knowledge .................................................. 228 CHAPTER EIGHT – Micro Level Analysis for Relationship Building Strategies .................. 231 8.1 Introduction ............................................................................................................... .......... 231 8.2 Drivers for relationship building strategies ......................................................................... 232 8.3 Empirical observations on the drivers for relationship building strategies ......................... 234 8.3.1 CROSS - CULTURAL INTERACTION .................................................................................................234 8.3.1.1 Case data report on cross-cultural interaction...................................................................236 8.3.1.2 Summary of cross-cultural interaction strategies ...............................................................244 8.3.2 B UILD IN G REPUTATION ................................................................................................................246 8.3.2.1 Case data report on reputation building strategies ............................................................247 8.3.1.2 Summary of reputation building strategies .........................................................................252 8.3.3 S TRATEGIES TO BR ING VISIBI LITY IN INTERRE LATED WORK PROCESSE S ......................................253 8.3.3.1 Case data report on strategies to bring visibility in interrelated tasks ...............................255 8.3.3.2 Summary of preferred strategies to bring visibility in work processes ...............................258 xii 8.4 Important drivers for relationship building strategies ......................................................... 259 CHAPTER NINE – The Evaluation Process ............................................................................ 263 9.1 Introduction............................................................................................................... .......... 263 9.2 Synthesis of knowledge shar ing processes at micro level .................................................. 264 9.3 Three level cell analysis.................................................................................................. .... 270 9.4 Cross case analysis........................................................................................................ ...... 272 9.4.1 H IERARCHY ................................................................................................................................ 273 9.4.2 CROSS - CULTURAL COMMUN ICATION .......................................................................................... 275 9.4.3 E MPLOY E E SK ILL S ...................................................................................................................... 278 9.4.4 CERTIFICATIONS ......................................................................................................................... 279 9.4.5 PROCESS CONTROLS .................................................................................................................... 281 9.4.6 S OCIAL REPRES ENTATION STRATEGIE S ....................................................................................... 283 9.5 Discussion and findings .................................................................................................... .. 285 9.6 Chapter summary ............................................................................................................ .... 290 CHAPTER TEN – Conclusions and Future Research .............................................................. 291 10.1 Introduction.................................................................................................................. 2 91 10.2 Key findings................................................................................................................. 29 1 10.3 Contribution .............................................................................................................. ........ 295 10.4 Implications of the study................................................................................................. .. 297 10.4.1 I MPLICATIONS FOR THEORY ...................................................................................................... 298 10.4.2 I MPLICATIONS FOR PRACTICE .................................................................................................... 299 10.5 Limitations ............................................................................................................... ......... 300 10.6 Future research.................................................................................................................. 301 11. References................................................................................................................. .......... 302 APPENDIX A..................................................................................................................... ...... 318 APPENDIX B ..................................................................................................................... ...... 319 PUBLICATIONS................................................................................................................... ... 320 xiii LIST OF TABLES Table 1 Government outso urcing report by ITANZ...................................................................... 7 Table 2 Government report by NZTE ........................................................................................... 8 Table 3 Types of sourcing arrangements .................................................................................... 23 Table 4 Outsourcing mode ....................................................................................................... ... 24 Table 5 Stages of outsourcing .................................................................................................. ... 26 Table 6 Outsourcing life cycle model ......................................................................................... 28 Table 7 Vendor stages and phases............................................................................................... 30 Table 8 Key drivers in knowledge transfer for offshore software development ......................... 35 Table 9 Hofstede’s culture dimensions (New Zealand and Indian context)................................ 37 Table 10 GLOBE culture dimensions (N ew Zealand and Indian context).................................. 39 Table 11 Trust model ........................................................................................................... ....... 47 Table 12 Temporal, geograhical and sociocultural issues........................................................... 50 Table 13 Tacit and explicit knowledge ....................................................................................... 60 Table 14 Theoretical framework ................................................................................................. 70 Table 15 Levels of embedded units of analysis........................................................................... 84 Table 16 Sampling strategies ................................................................................................... ... 89 Table 17 Sampling clusters used in the research design ............................................................. 90 Table 18 Attributes used to assess resear ch design in positivist case studies ............................. 96 Table 19 Brief description of pilot cases................................................................................... 100 Table 20 Brief description of main cases .................................................................................. 103 Table 21 Attributes used to assess data collection in positivist case studies............................. 104 Table 22 Attributes used to assess data analysis in positivist case studies................................ 109 Table 23 Pilot case interview settings ....................................................................................... 12 4 Table 24 Organisation culture and structure ............................................................................. 124 Table 25 Practices associated with knowledge sharing............................................................. 127 Table 26 Practices associated with relationship building.......................................................... 131 Table 27 Conceptual framework for key success drivers.......................................................... 137 Table 28 Interview settings for the main study ......................................................................... 147 Table 29 Outsourcing arrangements for the vendor cases......................................................... 148 Table 30 Organisational level field data.................................................................................... 150 Table 31 Vendor categories based upon organisational size..................................................... 152 Table 32 Vendor groups based upon cross cultural make up of employees.............................. 153 Table 33 Types of contracts .................................................................................................... .. 154 Table 34 Vendor groups......................................................................................................... ... 154 Table 35 Practices for drivers affecting transfer of tacit knowledge......................................... 160 Table 36 Practices for defining communication strategies........................................................ 162 Table 37 Practices for developing domain skills....................................................................... 178 Table 38 Practices on requirement vol atility management strategies ....................................... 186 Table 39 Drivers affecting manage ment of explicit knowledge................................................ 194 Table 40 Practices for quality process management ................................................................. 196 Table 41 Practices for softwa re project management................................................................ 204 Table 42 Practices for managing staff attrition ......................................................................... 217 Table 43 Staff attrition figures ............................................................................................... ... 218 Table 44 Drivers affecting rela tionship building strategies ...................................................... 234 Table 45 Practices for cross- cultural interaction ....................................................................... 235 Table 46 Practices for building reputation ................................................................................ 247 Table 47 Practices to bring visibility in interrelated work processes ........................................ 254 Table 48 Comparisons between group A and group B vendors ................................................ 269 xiv TABLE OF FIGURES Figure 1 The research questions................................................................................................ .. 13 Figure 2 Roadmap of study...................................................................................................... ... 17 Figure 3 Relationship building model......................................................................................... 44 Figure 4 SECI model ............................................................................................................ ...... 65 Figure 5 Dimensions of the duality of structure ......................................................................... 68 Figure 6 Five components in research design............................................................................. 82 Figure 7 Example of qualitative data analys is used in this research study ............................... 106 Figure 8 Brunswikian lens model ............................................................................................. 107 Figure 9 Methodological model of this research study............................................................. 112 Figure 10 Systematic combining .............................................................................................. 114 Figure 11 Venn diagram for analysing communication strategies............................................ 118 Figure 12 Application of the SECI m odel for relationship building......................................... 261 Figure 13 Knowledge sharing processes infl uencing the key success drivers.......................... 266 Figure 14 Application of Brunswikian Lens Model for this study ........................................... 271 Figure 15 Revised conceptual framework ................................................................................ 287 1 CHAPTER ONE – Introduction 1. 1 Introduction The current offshore outsourcing environment is re-structuring global society as new collaborative business ventures are being forged across international boundaries. Expanded world markets now exist due to integration of the global marketplace with the free flow of knowledge between different nations located at different time zones. The changing flow of knowledge in the field of information technology (IT) due to off-shoring has allowed relatively small software organisations to establish business relationships across diverse economic, spatial, temporal and cultural domains. Such relationships are spread across large and small businesses, and rich and poor economic geographies, as different societies collaborate in the growing international knowledge economy. In the present IT offshore situation, businesses offering software application development and maintenance lead the offshore IT marketplace, followed by data entry and data centre management businesses and lastly by the call centre management sector, though the picture may be changing (Gold, 2005). As reported by Beck (2002, p. 3), “Gartner projects that nearly half of Fortune 1000 global enterprise s will choose not to own their IT assets, but instead will derive business benefits from shared IT utility infrastructures owned and operated by service provider hybrids”. The ubiquity of IT tools available has facilitated a “follow-the-sun” approach in the software application development cycle, whereby team members located in distributed geographical settings collaborate over virtual technology tools (VTT) for common goals. As a result, software development has become a multisite, multicultural and globally distributed undertaking (Herbsleb & Moitra, 2001). The field of offshore software development (OSD) is relatively new and requires understanding of the complexities involved in geographically distributed work across organisational, cultural and other global context boundaries (DeLone, Esponosa, Lee, & Carmel, 200 5). As global software development is starting to gain mainstream attention, organisations are still adopting new strategies to better understand global operations, and these changes will continue to evolve for the next decade (Eppinger & Chitkara, 2006). Offshore software development is complicated as development team members situated at different locations collaborate to build client-specific applications. Their knowledge is 2 fragmented between the various team members involved in the development process as interrelated knowledge based tasks are divide d and assigned to distributed teams. The distributed teams in software development have increased multi-cultural identities, as the ‘space and place’ definitions have changed and are not limited by conditions of ‘nearness’ and ‘remoteness’ (Sahay, Nicholson, & Krishna, 2003). Thus new virtual social spaces (VSS) are emerging as diverse temporal, spatial, cultural and economic spaces come together over the telecommunications network through use of VTT to achieve a common goal. As these new economic spaces dynamically emerge, more theoretical and empirical studies are required to understand clearly the process and to suggest appropriate policy directions for future growth and development (Le Heron & Harrington, 2005). This research undertakes an empirical examination of the current offshore environment to identify the factors influencing the software development processes for knowledge sharing from the vendor perspective. The factors influencing the knowledge sharing processes have evolved as organisations go through a learning curve where they eventually overcome new challenges, and these learning experiences need to be studied empirically (Rottman & Lacity, 2004). Moreover, there is a “dearth of research on the outsourcing processes”, as most extant literature focuses on “less messy ” aspects of outsourcing such as outsourcing levels and outsourcing designs (Mol, 2007, p. 168). Mol further adds “A better understanding of outsourcing processes increases the practical relevance of academic research because practitioners spend much more of their time managing outsourcing processes, in the form of projects, than they do analysing outsourcing levels”. 1.2 Off-shoring – economics or sociology? A dialectical perspective of off-shoring has many researchers questioning whether the association of off-shoring lies more with ec onomics or with sociology. The new virtual market environment is blurring subject distinctions as economic processes are integrated with international federal law, geography, politic s, history and other social sciences in contemporary society. Off-shoring of software development is a lead ing phenomenon in the present virtual market situation. The primary motivation behind off-shoring software development work for clients 3 is cost, since with lower per capita labour costs in other countries, clients can benefit economically from moving as much development work offshore as possible (Gopal, Mukhopadhyay, & Krishnan, 2002). However, Kaiser and Hawk (2004) argue that offshore software development will increase for reasons beyond cost reduction as knowledge transfer cannot be assessed as a purely economic decision. Other benefits include access to skilled personnel across the globe, 24/7 availability of workers, innovation and shared best practices, cross-site modularisation of development work, improved time to market, acceptance of diversity, and compensation for gaps in the internal capabilities within organisations (Agerfalk & Fitzgerald, 2006; Brady, 2003). While customers look towards these benefits, vendors seek to make an acceptable rate of return on outsourcing contracts, acquire industry specific knowledge, build a stro ng reputation in their industry and stabilise their market position (Dibbern, Goles, Hirscheim, & Jayatilaka, 2004; Rottman & Lacity, 2004). Some negative issues associated with offshore outsourcing include costs related to infrastructural problems in developing countries, loss of control over intellectual property, threat of opportunistic behaviour by suppliers at the cost of clients, limited learning and innovation by clients, public relations mishap s and different legal systems of developing countries, amongst others (Mol, 2007; Rai, 2005). Thus Ritzer and Lair (2007, p. 325) have described offshore outsourcing as “a sociology, rather than an economics”. Mol (2007, pp. 167-71) adds that outsourcing designs described through an “economising perspective takes a static point of view”; and a “dynamic pictur e” is needed as practitioners spend more time managing offshore projects, relationships and knowledge transfer, which can be “best explained through a socialising perspective”. Different regional or local groups of knowledge workers or specialists collaborate over telecommunications networks to achieve a common goal; resulting in new social structures across emerging economic spaces. The intensity of global-local knowledge interactions is mediated by advances in technology, as local brands are creating glocal linkages across regions (Guhathakurta, Jacobson, & DelSordi, 2007). The concept of ‘glocalisation’ has become highly relevant in the discussion of the balance between global standardisation versus local flexibility of business practices for knowledge sharing (Svensson, 2001). Friedman (2006, p. 324) asserts that culture matters in offshore outsourcing and describes the “glocal mentality” as a mentality or accepta nce within a culture of absorbing foreign ideas and global best practices and melding them with their local traditions. A similar 4 concept, termed “negotiated culture” (Walsham, 2002, p. 377) identifies a shift in organisations’ attitudes towards knowledge sharing by vendors and clients belonging to different cultures, as both strive to improve their understanding of each other’s social structures. “Offshore can provide an invaluable learning opportunity to underscore the value and importance of acceptance of other cultures within the organisation” (Gold, 2005, p. 13). This research utilises a ‘socialis ing perspective’, and prefers the term ‘virtual social spaces’ to signify the emerging new social structures across different economic spaces. In the VSS, different cultural groups of knowledge professionals collaborate over the telecommunications network to achieve a common goal. By adopting a social perspective, the study aims to identify an evaluation framework for further empirical research into knowledge sharing strategies and relationship building strategies within the glocal environment. 1.3 Distributed software development The field of distributed software development in the offshore domain is relatively new and involves procedures for quality control and project management, which though developing very fast, have yet to evolve fully (Aman & Nicholson, 2003). These procedures refer to the various socio-cultural processes inherent in the transfer of knowledge, including the manner in which offshore partners draw upon and apply different forms of explicit-implicit, formal- informal knowledge (Sahay et al., 2003) into the end deliverable. In virtual environments, the facilitation of knowledge integration and application lies with the enabling information technologies, and organisations need to configure knowledge management systems optimally to help distributed groups sense proactively and respond rapidly to the emerging events (Alavi & Tiwana, 2002). However the application and integration of knowledge processes continues to be a chronic problem for software development (DeSouza, 2003; Ramesh, 2002). Software development is conceptualised as a knowledge intensive process of organising and integrating the specialised expertise, skills and perspectives of various project stakeholders into an appropriate, coherent and practical solution (Constantine & Lockwood, 1993; Faraj & Sproull, 2000) within the “knowledge” or “network” society (Sahay et al., 2003). 5 Knowledge builds with the progression of software development work as software modules go through an iterative process of design, creation, test, distribution, deployment, utilisation and revision. Each project deliverable is evaluated for new value addition by team members situated across different geographical boundaries. The transfer of knowledge does not happen easily in situations where knowledge is inter-organisational, let alone international (Macharzina, Oesterle, & Brodel, 2000). The problem is magnified in OSD due to the technical and knowledge intensive nature of the languages used and the multiplicity of products, technical processes, tools and met hodologies involved, which are distributed at different geographical sites (Sahay et al., 2003). Thus distributed software development combines existing issues associated with onshore projects with new issues related to geographical spread, across different technical , social and cultural boundaries. Moreover recent offshore development of software has changed from being highly structured to less structured with changing requirements, requiring more client contact and process management skills (Jennex & Adelakun, 2003). The processes employed in OSD settings need to account for challenges associated within the VSS as diverse composites of organisational work practices are combined. The challenges associated with OSD are recognition of cultural diversity, efficient use of communication pathways, project scoping and scheduling, status reporting across geographic sites, documentation standards, management reporting and decision making processes, amongst others (Gold, 2005; Jennex & Adelakun, 2003; Rottman & Lacity, 2006; Sahay et al., 200 3). As offshore outsourcing becomes increasingly widespread, understanding the impact of the effectiveness of processes used for knowledge transfer in distributed software development will become increasingly important (Edwards & Sridhar, 2003). These processes employ multi-dimensional practices, since no single practice can tap into the complexities of the OSD settings (DeLone et al., 2005; Endres & Rombach, 2003; Gopal, Krishnan, Mukhopadhyay, & Goldenson, 2002; Heeks, Krishna, Nicholson, & Sahay, 2001; Moore & Barnett, 2004; RajKumar & Dawley, 1998). 1.4 Current research on international outsourcing Researchers and policy makers have had a long fascination with the question of why certain national industries succeed: what led them to success, what factors will keep them 6 successful and what prescriptive factors can be gleaned for other nations (Carmel, 200 3). The United States (US) and Germany have been attracting talented foreign professionals to participate in their growing technology-base d economies. Now countries like Australia, Japan, Canada, New Zealand and even India ar e recruiting foreign IT professionals to sustain their competitiveness in the emerging wealth creating IT industry (West & Bogumil, 2001). In the current outsourcing business environment IT groups in their respective countries and industry associations are vying with each other to promote outsourcing services globally (Sahay et al., 2003). The demand for new technology services is expected to increase, with various predictions on the offshore IT market presenting a healthy picture of growth, attracting new software providers across countries. India and New Zealand are both emerging aspi rant producer nations of global software (Friedman, 2006; Hamilton, 2004; Kearney, 2004; RajKumar & Mani, 2001). India presently leads the offshore software marketplace, offering benefits of low cost, English language compatibility, availability of skilled developers with the latest technical knowledge and the ability to handle large projects and produce quality software (Davey & Allgood, 2002). New Zealand (NZ) also offers a mature IT business environment and is often used as a testing ground for new technologies, for multi-nationals to prototype, trial, prove and test solutions and business models before mass roll-out to the United Kingdom, European or US markets (O'Neil, 2004). Thus India and New Zealand are both exemplars of the emerging global software producer market, but differ in many respects, providing an opportunity for meaningful comparative research. Table 1, from a New Zealand newspaper report ranks variables such as language, government support, labour pool, infrastructure, education system, cost, cultural compatibility and data security across offshore vendor destinations of New Zealand, India, China, South Africa, Northern Ireland and Ireland. The table shows that NZ ranks as excellent in language, cultural compatibility and data/IP security, whereas India ranks as excellent in government support, labour pool and cost. 7 Table 1 Government outsourcing report by ITANZ1 Variables New Zealand India China South Africa Northern Ireland Ireland Language Excellent Very Good Fair Excellent Excellent Excellent Government Support Fair Excellent Good Fair Very Good Very Good Labour Pool Good Excellent Fair Fair Good Good Infrastructure Very Good Fair Good Fair Very Good Very Good Educational System Good Very Good Good Good Very Good Very Good Cost Good Excellent Excellent Very Good Good Fair Cultural Compatibility Excellent Good Poor Excellent Excellent Excellent Data/IP Security Excellent Good Poor Good Excellent Excellent Source: Newspaper report from New Zealand Herald dated 23rd February 2004 Another study by the New Zealand government (NZTE 2 ) compares the cost of hosting a fifty person software development centre in a global representative group of countries which are known to offer world class softwa re development capabilities (refer Table 2). The countries compared are New Zealand, India, Australia, South Africa, US and the UK. On a cost basis New Zealand lies in between Australia and South Africa and is a financially attractive location when compared to culturally similar locations such as the United States, the United Kingdom and Australia. However, India is presently the least expensive of these countries in the current offshore software development environment. 1 Information Technology Association of New Zealand (ITANZ) is the New Zealand national association of firms involved in the development, production, marketing in support of goods and services related to the process of information. 2 New Zealand Trade and Enterprise (NZTE) is the govern ment’s national economic de velopment agency. It is a global organisation and helps connect New Zealand busineses with trade and investment opportunities in the overseas markets. 8 Table 2 Government report by NZTE Cost Category (USD) New Zealand India Australia South Africa United States United Kingdom Salary costs 2,006,77 9 484,77 1 2,368 , 5 8 7 1,401 , 7 4 9 3,816 , 6 2 4 3,284 , 4 6 7 Other employee costs 287,371 77,364 693,286 112,364 833,932 755,427 Property occupancy costs 94, 089 116,64 3 170,31 6 78,637 131,79 4 548,73 9 Electricity costs 16,099 15,528 17,144 8,617 24,905 24,746 Telecommunication costs 97,382 48,643 122,22 5 99,925 53,244 165,88 0 Total development costs 2,501,7 2 0 743,14 9 3,371, 5 5 8 1, 701 , 2 9 2 4,860 , 4 9 9 4,779 , 2 5 9 Source: http://www.investmentnz.govt.nz (on 17th December 2007) Table 1 and Table 2 show a growing interest in OSD as local governments are doing a self- check on their local strengths, opportunities, challenges and risks, and want to take advantage of the offshore software development vendor market. The tables show that both New Zealand and India are actively engaged in offshore application software development although they operate in different social and cultural contexts, and this provides a useful opportunity to compare the micro-level issues which influence their knowledge management processes. 1.5 Comparison of India and New Zealand as outsourcing vendor destinations This section explores the widespread adoption of offshore outsourcing from the Indian and New Zealand industry perspective. It explores the strengths and challenges associated with off-shoring in the two country contexts. Next, it brings together a comparison of the industry trends around the offshore vendor marketplace surrounding these two countries. 1.5.1 India Indian software exporters presently lead the global outsourcing market (Friedman, 200 6; Kearney, 2004; Moore & Martorelli, 2004) and have shaped some of that market’s 9 methodologies and processes. The world is becoming ‘flat’, as countries like India are now competing for global knowledge work along with many developed western economies (Friedman, 2006). The present market shows Indian suppliers are trying to position themselves higher up the value chain and are competing on a par with major corporate organisations like IBM, EDS, CSC and Accenture; while smaller Indian supplier groups too are effectively competing on quality of staff, domain expertise and flexibility (Rottman & Lacity, 2004). Software development represents approximately one-third of India’s service exports (Eppinger & Chitkara, 2006). Indian suppliers have readily adopted the Software Engineering Institute’s Capability Maturity Model (CMM 3 ) and many software organisations are certified at CMM level 4 or 5 (Ramasubbu, Mithas, Krishnan, & Kemerer, 2008; Rottman & Lacity, 2004). However, Moore and Barnett (2004) from Forrester Research argue that Indian software organisations are used to the disciplined processes that have made them so successful, but these processes are antithetical to the dynamic nature of many of today’s IT organisations. The Indian government has introduced Software Technology Parks (STP), which offer benefits of reduced customs regulations and levies. The STPs located in the export zones are geared towards exporting their own products and, to take advantage of these benefits, many software firms have established their own STPs (RajKumar & Dawley, 1998). However, as demand for Indian software professionals is increasing, their wages are also increasing, so profit margins are shrinking and outsourcing in India is now becoming susceptible to global competition (Farrel, 2006; Kiviat, Rajan, Thomas, & Tumulty, 2004). Research shows that attrition rates in Indian IT facilities have jumped to 25 – 30% (Moore & Martorelli, 2004). A recent article in Time mag azine states that in view of the changing domestic labour markets, Indian firms are st rategically opening new software development centres in China, Vietnam and Romania to serve the North Asian and European clients (Baker, 2006). Farrell (2006, p. 92) also warns that although India is a hot spot as a vendor 3 The Capability Maturity Model for Software (also known as the CMM and SW-CMM) has been a model used by many organisations to identify best practices useful in helping them increase the maturity of their processes. The CMM consists of five maturity levels and 18 ke y process areas (KPAs). Each KPA addresses a set of related goals that must be fulfilled by a set of processes within the organisation. 10 location with its skilled pool of knowledge professionals, client countries need to expand their choice of vendor destinations to other less “overheated labour markets”. 1.5.2 New Zealand At the 2004 Gartner Outsourcing and IT Servi ces Summit, New Zealand was described as an “up and coming” overseas business development destination (Kumar, 2004; Pullar- Streker, 2004). Multinational consultancy firm A.T. Kearney ranked NZ the twelfth most attractive country to outsource IT work. This study was done using 39 measures designed to assess countries’ costs, people skills and business environments. The foreign policy globalisation index by A.T. Kearney research ranked NZ as eighth in the global scenario, basing its indexes on key areas of global integration and incorporating measures such as trade and financial flows, movement of people across borders, international telephone traffic and Internet usage (Kearney, 2004). Gartner reports that New Zealand could be a pot ential provider for off-shored jobs in some IT disciplines, but consultancy businesses will have to change their business models to succeed (Greenwood, 2004). New Zealand is still not perceived to be a major destination for global outsourcing, with some companies having had limited success (Kumar, 2004). O’Hara (2005, pp. 16-7) states that New Zeal and software development businesses lack export commercialisation strategies and labels them as “technology–enthusiasts” who “fail to understand the difference between a product and a business”. Another study of 32 New Zealand organisations over a four-year period showed an ad hoc approach to system development practices, with a low emphasis on mature, disciplined processes (Taylor, 2000). Little is known about the role of standard me thods in IS development within New Zealand organisations. Given their age and restricted nature, prior surveys (e.g. Groves, Nickson, Reeves, & Utting, 1999; Urban & Whiddett, 1996) reveal only limited information. However, many of the New Zealand software organisations are ISO 9001 certified, with EDS being the first organisation in New Zealand to have CMM Level 3 certification. EDS 11 also presently dominates the outsourcing marketplace in New Zealand (Longwood, Caminos, & Chon, 2003). 1.5.3 India vis-à-vis New Zealand At the 2004 Gartner Outsourcing and IT Services Summit, India was ranked a leader and New Zealand was ranked as one of eleven in the “up and comers” group in overseas business development destinations (Kumar, 2004; Pullar-Streker, 2004). Gartner also says that although NZ cannot rival India in the outsourcing market because of its small size and higher labour cost, it could find some high-value niche IT disciplines where NZ could be a potential destination for off-shored jobs. Expert commentary at this conference suggested NZ should focus on the higher end of application development, the design and architecture stages, research and development for offshore clients, implementation of enterprise- packaged applications which may need some particular industry expertise, innovation- focused projects and product development support for software companies (Gifford, 2004; Pullar-Streker, 2004). Success is aided by the software provider’s ability to pool some resources into a national association or consortium that serves to promote the nation’s industry abroad and provide services back to its member firms. One such case is the prominent Indian association NASSCOM 4 , which helped the branding (in the marketing sense) of the Indian software industry (Carmel, 2003; Carmel & Eisenberg, 2006). New Zealand too has started many government initiatives through NZTE, ITANZ, NZSA 5 and many other ICT clusters. However, discussions with a government representative of one of these ICT cluster organisations revealed that there may be twenty such points of contact for organisations which means the “small ICT space is rather crowded”. 4 NASSCOM is India’s National Association of Software and Service Companies, the premier trade body and the chamber of commerce of the IT software and servic es industry in India. It consists of 850 member companies which are in the business of software development, software services and IT-related BPO services. 5 NZSA or Software New Zealand is New Zealand’s national software association. 12 1.6 Background to the research problem Dibbern et al. (2004, p. 86) assert that there is a “scarcity of studies that take the vendor perspective into account” and “there is almost a total lack of outsourcing research at the societal level”. They state that analysis has primarily been conducted at the organisational level and has neglected micro level processes (i.e. behaviours, methodologies and preferences) which offer insights on cross-cultural issues and individual perspectives in outsourcing. Research into geographically distributed software teams has increased understanding as to how teams can be more effective when working globally, but most of this work does not address the complexities of working across organisational, cultural and other global context boundaries (DeLone et al., 2005). This study partly fills this gap by examining the micro level issues in offshore software development processes from the vendor perspective in the outsourcing business environment from the New Zealand and Indian contexts. The research study therefore empirically examines the socio-technical influences in knowledge sharing to unders tand how software vendors utilise their organisational assets and share local and dispersed knowledge for software projects. Nonaka and Takeuchi’s SECI (socialisation, externalisation, combination and internalisation) cyclic model for organisational learning and Giddens’ structuration theory have provided the theoretical foundation for the empirical investigation. Takeuchi and Nonaka (2002) view organisa tional knowledge learning as occurring through processes of conversion and assimilation, including the conversion from tacit knowledge to formal knowledge (and vice versa) and the transfer from individual to collective (and vice versa) through spirals moving from socialisation (tacit to tacit), via externalisation (tacit to explicit) and combination (explicit to explicit), to internalisation (explicit to tacit). Team members engage in new social structures, as experiences are described and embedded in technological tools across different countries and cultures. Giddens’ (1990) structuration theory provides a useful theoretical context to understand the dynamic and emergent nature of social structures in the information systems development work practices of distributed member groups (Jones & Karsten, 2008; Walsham, 2002). 13 1.7 Research questions As offshore outsourcing becomes increasingly important to all aspects of industry, there is a need to understand practitioners’ processe s to build and share knowledge across international boundaries. Indian and New Z ealand vendor organisations are actively involved in the application development area and have recently entered the software export market. Government and industry groups requ ire information on vendors’ offshore software development practices. The study therefore addresses how vendor organisations that are participating in offshore software development are assessing their development practices for knowledge transfer across international boundaries. The main research question is as follows: How do vendor organisations use knowledge sharing processes in the offshore software development environment within a glocal society? This research question is influenced by the following subsidiary questions: 1. What processes do vendor organisations consider important for transfer of tacit knowledge in the offshore software development environment? 2. How do vendors manage distributed knowledge-based processes within the software development environment? 3. How does culture affect vendors’ relationship building strategies with offshore clients or partners in the virtual environment across organisations and nations? Figure 1 The research questions MAIN RESEARCH QUESTION Knowledge sharing processes within a glocal society Q 1. Transfer of tacit knowledge Q 2. Management of explicit knowledge Q 3. Relationship building strategies As indicated in Figure 1, the first and second subsidiary questions feed into the main research question and contribute to the many aspects of tacit and explicit knowledge sharing processes involved for software development across glocal boundaries. The third subsidiary 14 question takes account of cultural perspectives, as relationships are built for effective knowledge sharing in the glocal society. A review of published literature identifies the key drivers in the OSD environment. A pilot study explores the vendors’ practices associated with some of these identified drivers. A multiple case study research strategy answers the “how” questions. The study investigates the work processes of ten software vendor organisations from both India and New Zealand, who are doing major application development work for international clients. A logical positivist approach is used to analyse and validate the findings, as discussed in Chapter three. 1.8 Contribution of the thesis This research study empirically examines the area of offshore software development, to increase understanding of the key drivers which influence the offshore software development process. Mol (2007, p. 167) says successful outsourcing designs depends upon understanding “the complexity and requirements of knowledge transfer of what is being outsourced”. He suggests academic studies should address the practical relevance of the outsourcing process and focus on interpreting empirical findings to understand ongoing influences of work processes in outsourcing. This study does this by investigating vendors’ knowledge strategies for software development by comparing theoretical formulations with empirical evidence. Thus existing literature and empirical findings have been used to inductively develop a conceptual framework on the vendors’ knowledge building processes. Next, the framework has been applied to make within-case and cr oss-case comparisons across three levels of analysis, namely micro or individual key success drivers, meso or organisational levels and macro or country contexts. The contribution of this thesis to existing research can be summarised as follows: 1. Recognition of the key success drivers that affect the vendors’ knowledge sharing and relationship building strategies. The thesis uses multiple case study approach to 15 empirically examine the vendors’ strategies. Although literature provides many theoretical insights, empirical assessment of the vendors’ work processes are limited. The study provides an empirical investigation of how vendors manage their knowledge processes to capture local knowledge at offshore sites and the reasons for employing these processes. The study is therefore significant for clients, vendors and offshore partners, who may be participating or making an entry into the offshore software development environment. 2. The study has provided an empirical assessment of Nonaka and Takeuchi’s (1995) SECI (socialisation, externalisation, combination and internalisation) cyclic model for organisational learning. It explores the organisational learning processes in different social and cultural contexts by using in-depth case studies across two country contexts. The research shows the effectiveness of knowledge based processes, as vendors’ link national, organisational and individual work practices to re-define their knowledge assets in their knowledge repository. Giddens’ structuration theory (ST) has been applied to bring sensitivity in the everyday organisational activities of diverse social and cultural agency groups within the two country context. 3. The study plays a significant role in understanding the complexities of knowledge creation and management process from a social perspective in the offshore software environment. The study utilises a logical positivist research approach to understand the social, cultural and organisational viewpoints of the participating vendors. Faced with diversities in social structures, the study utilised ideographic methods to provide rich descriptions of the vendors’ societal structures and activities to give the reader a broader sense of the vendors’ viewpoint. 4. The development of a framework which has the underpinnings of both theory and empirical evidence is a major contribution of this research study. The framework provides a holistic view of the dynamic knowledge sharing process in the offshore software development environment. 16 1.9 Roadmap of study Figure 2 outlines the roadmap of this study undertaken to answer the proposed research questions. More details of the theoretical and methodological models used in the study are included in Chapters two, three and four. 17 Figure 2 Roadmap of study Background of the research problem Software development is a leading business sector in the present IT offshore marketplace and vendors in different countries are opening software development centres worldwide to take advantage of the new business opportunities. However, Dibbern et al. (2004, p. 86) assert th at there is “scarcity of studies that take the vendor perspective into account” and “there is almost a total lack of outsourcing research at the societal level”. They state that analysis has primarily been performed at the organisational level and has neglected micro level processes which offer insights on cross-cultural issues and individual stakeholder perspectives. Academic research should have practical relevance, and increase understanding of how practitioners manage relationships and the outsourcing process in the form of projects (Mol, 2007). It is important for organisations to understand the drivers which affect the global software development effort (Edwards & Sridhar, 2003). These factors have evolved during the learning experiences through practices adopted and can be only studied empirically (Rottman & Lacity, 2004). Research questions How do vendor organisations use knowledge sharing processes in the software development environment within a glocal society? 1. What processes do vendor organisations consider im portant for transfer of tacit knowledge in the offshore software development environment? 2. How do vendors manage distributed knowledge-based processes within the software development environment? 3. How does culture affect vendors’ relationship building strategies with offshore clients or partners in the virtual environment across organisations and nations? Theoretical lens used - Knowledge Management - Social Theories Methodological lens used - Logical positivist research study - Ideographic methods Research design E xploratory pilot study Multiple case study research design Embedded unit of analysis - 1. National (macro) 2. Organisational (meso) 3. Individual (micro) Data analysis Three level cell design structure - Within case analysis - Cross-case analysis - Cross-country analysis Findings – Closure of analysis Conceptual framework Systematic combining of theory and empirical evidence 18 1.10 Thesis outline This thesis is organised as follows: Chapter one has laid the foundation for the thesis. It describes the current offshore situation within the context of New Zealand and India, which are both compelling destinations for software development work. It also introduces the background of the study and the research questions. The roadmap of the study is presented. On these foundations, the thesis proceeds with a detailed review of literature relating to the offshore software industry sector in general and software application development in particular. Chapter two provides a detailed review of relevant published literature with respect to the research questions. The chapter identifies the drivers considered key to knowledge management across international boundaries in the context of OSD. The chapter also discusses how offshore vendors maintain relationships with clients across cross-cultural boundaries. Chapter three discusses in detail the research methodology used to answer the research questions. The chapter explains the relevan ce of using a logical positivist methodological lens with multiple case study research design to interpret the vendors’ knowledge management capabilities during offshore software development processes. Chapter four presents the proposed conceptual framework, as drivers identified from the literature are interpreted with a pilot study of three software vendors (belonging to vendor destinations of India and New Zealand). These key drivers are integrated into a coherent framework, as empirical findings from the exploratory pilot study have been used to support the theoretical framework. The chapter concludes with a conceptual framework which is supported by both theory and practice to answer the research questions. Chapter five presents the ten case studies from New Zealand and India. A brief background of each case is provided and the research settings used during the data collection are described. The three level embedded case design has been explained in the context of this research study. 19 Chapter six explores the ten vendors’ practices associated with the key drivers in the OSD process for gathering and transfer of tacit knowledge. The practices associated with each key driver are described with practitioner’s voices to give a real-life perspective of the data collected. Chapter seven explores the work practices associated with the key drivers for management of explicit knowledge for the ten organisations participating in the study. Again, the chapter uses extensive quotes from interview data to give the reader an understanding from the practitioner’s perspective. Chapter eight explores the relationship building strategies, as vendors try to gain the trust and confidence of their offshore clients and partners. Exact quotations from participants are used to ground the data and inform the reader on vendors’ concerns and processes. Chapter nine extends the analysis to higher levels, using a cross-case analysis, to uncover similarities and differences in knowledge sh aring and relationship building practices. The analysis is extended across the organisational and national levels to apply TE (theory to empirical) and EE (empirical to empirical) generalisability for different social and cultural settings in the OSD environment. The chapter revises the framework, which has underpinnings of both theory and practice. Chapter ten summarises the findings and discusses the implications of the study for offshore outsourcing within the context of New Zealand and India. This study may be extended to understand the software development processes for vendors belonging to other countries. Finally, the limitations of this study are stated. 20 CHAPTER TWO – Literature Review 2.1 Introduction This chapter begins by defining offshore outsourcing in the context of the IT industry. It gives a synthesis of outsourcing concepts, such as outsourcing arrangements with vendors, outsourcing modes and types of service providers. The various stages or phases in an outsourcing life cycle model used by organisations when undertaking an outsourcing initiative are described. However, the stages shown in outsourcing models available in the literature are viewed more as a strategy from the client’s point of view in managing the outsourcing life cycle. The software service provider also plays an important role in the outsourcing partnership as they too learn from past experiences to better manage their business practices. The chapter identifies the stages where the vendor or service provider too can obtain value and proactively manage their knowledge assets using the outsourcing life cycle models available in the literature. The chapter examines existing literature in knowledge management and discusses their application in the current OSD environment. Various organisational and operational contexts in organisational knowledge learning re lating to distributed software development are identified from extant literature. These have helped in delineating key success drivers to provide a theoretical conceptualisation of key concepts and identify scope of the study. Next, results of the literature review inve stigating the key success drivers in the OSD process are presented and organised into ten sub-sections, each focusing on a different facet of the knowledge management process. The structuration theory underlying the relationship between agency and structure in the OSD environment is presented. Then theories on knowledge management utilised in this study are explained. The theoretical framework for the study is deve loped through an analysis of different facets of OSD, as a parsimonious set of key drivers is identified from the literature. Each driver identified from the literature is explained in the context of this research study. The chapter lays the foundation of a theoretical framework, and explains the relevance and implications of the study for theory and practice of offshore software development. The theoretical framework is informed by the pilot study described in Chapter four. 21 2.2 Offshore outsourcing environment Outsourcing trends are changing business practices as both vendors and clients enter into different types of outsourcing arrangements to build business relationships across international boundaries. Moreover, as organisations enter into new knowledge domains in distributed settings, they have realised the need for a strategy to deal with increasing demands and expectations of the stakeholders involved. Thus the current offshore outsourcing environment has led to many classifications in outsourcing arrangements between clients and vendors, as both sides weigh their risks and benefits for knowledge sharing. This section begins with the definition of the term “offshore outsourcing” and then synthesises prior research to highlight the global outlook and show the different trends in the area of offshore outsourcing. It aims to give a broader view of the current offshore environment from both the client and vendor’s point of view. 2.2.1 Definition The term “offshore outsourcing” is comprised of two distinct terms: “offshore” and “outsourcing”. The terms offshoring and outsourcing are often used as synonyms in the literature, but offshore is about location (ons hore or offshore), and outsourcing is about governance (in-house or outsourced) (Agerfalk & Fitzgerald, 2008). These terms are used in the context of many industry domains, but primarily imply the use of an agent or supplier existing outside the client’s country shores, to undertake sourcing of some internal functions. Offshore outsourcing has been defined in IS literature as a strategy where IT functions are out-tasked or transferred or subcontracted to another party. This is evident by some definitions used in IS literatures, which are as follows: ……… is a “buy” strategy or out-tasking to third parties located in a country different from that of the client. Another strategy is the “ build” strategy, which implies ownership of the offshore resources, such as captive centres or subsidiaries (Carmel & Tija, 2005, p. 103). 22 ……… refers to the subcontracting of an activity by a client organisation to an independent provider working from an overseas destination (Vlaar, Fenema, & Tiwari, 2008, p. 228). ……… is the transference of an IT function, from a client company to a supplier organisation located outside the borders of the client company’s country (Jennex & Adelakun, 2003, p. 25). ………refers to a commercial subcontracting a rrangement, where a contractor entrusts a foreign sub contractor with a commission to produce the software products or services (Nahar, Kakola, & Huda, 2002) Thus the terms “outsourcing”, “subcontracting”, “ out-tasking to third parties” or “buy” have been used interchangeably to describe the practice of paying an external party for performing an internal IS function. The term “ outsourcing” is preferred in this literature. 2.2.2 Synthesis of outsourcing concepts used in literature In order to adequately address the diversity of research in outsourcing, this study will first synthesise the outsourcing concepts used in the published literature. 2.2.2.1 Organisational arrangements in outsourcing Dibbern et al. (2004) use a broad term IS sourcing to define an organisational arrangement instituted with an external agent for obtaining IS services and the management of resources and activities required for producing these serv ices. The organisational arrangements refer to the formal structure of the responsibility for delegation of tasks within the IS functions. The IS functions may be characterised as commodities to include software applications development, application maintenance, network management, and similar functions. The functions could be handled either internally (insourcing) or externally (outsourcing). Building on previous literature, Dibbern et al (2004) further define four fundamental parameters in the context of organisational arrangements for outsourcing: 1. degree (total, selective and none); 2. ownership by offshore partner/ purchaser (totally, partially, externally); 3. mode (single vendor/client or multiple vendors/clients); 23 4. time frame (short term/long term). Offshore outsourcing may include any combination of the four parameters (degree, ownership, mode and time-frame). The combination of specific instances of degree and ownership parameters yields different types of outsourcing arrangements: a. Spin-offs are situations when the ownershi p is internal, but the function is either totally or selectively outsourced (Heinzi, 1993; Reponen, 1993). b. Joint ventures are when spin-offs are jo intly owned between the clients and the vendors (Carmel & Tija, 2005; Fitzgerald & Willcocks, 1994; Marcolin & McLellan, 1998). c. Traditional outsourcing is when the function is completely outsourced and there is no joint ownership of resources (Earl, 1996; Gold, 2005). d. Selective outsourcing is when the function is selectively outsourced and there is no joint ownership of resources (Gold, 2 005; Lacity, Willcocks, & Feeney, 1996). Table 3 shows the four outsourcing arrangements – spin-offs, joint ventures, traditional and selective – based upon specific combinations of ownership of resources (i.e. internal, partial or external) and degree of outsourcing (i.e. total or selective) by the client. Table 3 Types of sourcing arrangements Ownership Degree of outsourcing Internal Partial External Total Traditional Selective Spin-offs (wholly owned subsidiary) Joint venture Selective Source: Dibbern et al, 2004 However, at the Gartner Outsourcing Summit in July 2003 in Las Vegas, audience polls revealed that traditional outsourcing firms were building extensive offshore capabilities, resulting in spin-offs and joint venture arrangements in the emerging offshore outsourcing environment. As a consequence business operations are spread across many countries, and offshore centres are becoming strategic centres. These centres are performing work 24 containing intellectual property related to the client’s products or processes and expertise related to the core competency of the client company. However, some clients prefer selective outsourcing arrangements, and keep key strategic functions of project/program management in-house and use outsourced staff only at certain points of control (Eppinger & Chitkara, 2006; Gold, 2005; Kaiser & Hawk, 2004). The choice of outsourcing mode could lead to single client and vendor arrangements or multiple clients and vendors arrangements or any such combination of the two. Use of several vendors gives clients some independence and reduces the risk of having too much work ingrained with a particular vendor (Kaiser & Hawk, 2004). Table 4 displays the different outsourcing modes. Table 4 Outsourcing mode Vendor Client Single vendor Multiple vendors Single client Simple dyadic (1:1) Multi-vendor (1: n) Multiple clients Multi-client (n:1) Complex relationship (n:n) Source: Dibbern et al, 2004 The fourth parameter i.e. timeframe refers to the contractual length of the outsourcing arrangement. This may vary from very short contracts to mid-term or long-term contracts (Lacity & Willcocks, 1998). This study will look at different outsourci ng arrangements involving a combination of ownership and degree of outsourcing (refer Table 3). The outsourcing arrangements used by the ten vendors participating in this research study are described in Chapter five. 2.2.2.2 Categories of outsourcing vendors: The category of vendor involved is an important consideration in an outsourcing arrangement. Mitchell and Fitzgerald (1997) have identified five categories of vendor. In 25 addition, a sixth category, freelancers, has also been identified in the literature (Dibbern et al., 2004; Knolmayer, 2002). The six categories are: a. IS consultancies/ solutions providers – global players providing services in all IS functions b. Systems houses – specialise in system integration c. Hardware vendors – specialise in IT hardware d. Ex-IS departments – focus on industry specific sourcing e. Generic outsourcers – specialise in managing functions, especially infrastructure f. Freelance personnel – provide day to day service provisions This study examines the outsourcing categories of large, medium and small solution providers involved in the IT function of global software application development in a two- country context. 2.3 Outsourcing stages Outsourcing is a powerful management tool and is a major management decision taken by the client (Johnson, 1997). The outsourcing process involves an on-going review process and should be viewed as a strategy with life cycle stages rather than a one-off transaction (Cullen, Seddon, & Willcocks, 2005; Dibbern et al., 2004). Various organisational, business and informational perspectives are considered to make informed decisions and to take remedial actions in the various stages of the outsourcing process. Thus, each stage paves the way for the following phases and helps in providing insights for the next sourcing strategy and its subsequent life cycle. Dibbern et al. (2004) have extended Simon’s four-stage generic model of decision-making into five stages for outsourcing processes. Their proposed model shows two phases where client organisations reflect and make decisions in the outsourcing process. Phase one consists of stages involved in helping clients make decisions on the outsourcing arrangements, while the phase two consists of stages after the decision on outsourcing 26 arrangement has been made and involves implementation and post evaluation of their decisions. Table 5 illustrates the five stages of Dibbern et al.’s (2004) model for the outsourcing process. Table 5 Stages of outsourcing Phases Stages Strategy Intelligence WHY Organisations weigh the risks and rewards, advantages and disadvantages at this stage. They ask: Why should outsourcing be considered? Design WHAT This stage is linked with the first stage, and could also be combined as “why outsource what”? They ask: What functions should the organisation outsource? Ph as e 1 D ec is io n Pr oc es s Choice WHICH Organisations go through some selection criteria and this stage reflects actual decision made on the outsourcing arrangement. They ask: Which is the best selection? What criteria are used? How is the evaluation done? Who makes the final decision? Implementation HOW This stage relates to implementation of best practices – methods and techniques to achieve a higher degree of success. They ask: How to best negotiate contracts with the vendor, and manage the subsequent relationship. Ph as e 2 Im pl em en ta tio n Implementation OUTCOME Organisations review their activities/ tasks to understand what led to successful or failed outcomes. They ask: What was their experience? What lessons have they learned? How could they lead to better results? What implications do these practices have for their future business? Source: Dibbern et al, 2004 The first phase comprises three stages, as clients make informed decisions and evaluate their decision to outsource by asking: ⎯ Why should an organisation consider outsourcing? ⎯ What to outsource? ⎯ Which choice to make? As the client eventually implements the outsourcing arrangement with the provider or vendor they enter into the next phase which comprises of two stages. The questions asked now by the client are: 27 ⎯ How to outsource? ⎯ Were the outcomes successful? A second model describing the different phases of the outsourcing process is the Outsourcing Life Cycle Model (OLCM) (Cullen et al., 2005). The OLCM comprises of four phases namely architect, engage, operate and regenerate, which help clients manage their business strategies. Each phase consists of building blocks which lay the foundation for the following phase and its associated building blocks. Table 6 lists the four phases of the OLCM and the associated building blocks for each phase. Each phase comprises of key activities, which help clients to identify the expected goals or outcomes from these activities. 28 Table 6 Outsourcing life cycle model Life cycle phases Building blocks Key activity Goal Investigate ⎯ Gather insight ⎯ Collect market intelligence ⎯ Peer assessment Understand what can be achieved, and how it can be achieved. Target ⎯ Outsourcing model ⎯ Target service identification ⎯ State profiles: services, cost, asset, staff, stakeholder Targeted and defined scope Strategise ⎯ Rollout ⎯ Determine key rules: governing docs, number of suppliers, asset ownership ⎯ Communications strategy ⎯ Business case rules and base case ⎯ Feasibility and impact analysis Develop informed and holistic strategies Phase 1 Architect Design ⎯ Prepare blueprint ⎯ Develop metrics ⎯ Draft service level agreement ⎯ Draft contract ⎯ Relationship ⎯ Retained functions ⎯ Contract management function Well designed future state Select ⎯ Competitive stages ⎯ Evaluation team ⎯ Selection strategy and criteria ⎯ Bid package ⎯ Bid facilitation Determine the best value for money and select sustainable solution and provider Phase 2 Engage Negotiate ⎯ Negotiation strategy ⎯ Negotiation team Complete contract Transition ⎯ Final plans ⎯ Transition team ⎯ Managed staff ⎯ Knowledge retention and transfer ⎯ Governance structures ⎯ Engineering ⎯ Acceptance Efficient and complete mobilisation Phase 3 Operate Manage ⎯ Relationship ⎯ Reporting, Meetings ⎯ Administration and record keeping ⎯ Risk management ⎯ Issues, variations and disputes ⎯ Continuous improvement ⎯ Evaluations Ongoing results Phase 4 Regenerate Refresh ⎯ Next open options ⎯ Outcomes and lessons ⎯ Knowledge refresh ⎯ Options business case and strategy Refreshed strategy and options Source: Cullen, Seddon and Willcocks, 2005 29 Both models described in Table 5 and Table 6 describe the phases in which client organisations evaluate their outsourcing experiences to identify drivers for achieving success and to avoid undesirable outcomes. This helps the clients to select better strategies and factor in best practices for success (Dibbern et al., 2004; Herbsleb & Moitra, 2001; Rottman & Lacity, 2004). The outsourcing process however, involves both the client and the vendor, where each contributes to the learning experiences through the practices that are adopted. Both client and vendor are partners in the outsourcing relationship once the contract has been signed by both parties. It is also in the interest of the vendor to follow the outsourcing process as a strategy with a life cycle rather than as a one-off transaction. Hence the second phase (implementation) of Dibbern et al.’s (2004) model would apply to the vendor also. Similarly, the third and fourth phases (operate and regenerate) of the Cullen et al. (2005) model would be applicable to the vendor. In short, various researchers and practitione rs have recognised the importance of the outsourcing process, but limited studies have been proposed from the vendor’s point of view. Vendors too can strategise and operate in a cost-effective manner when they proactively manage the entire outsourcing life cycle stages to identify practices for project success. Table 7 has thus been derived from Table 5 and Table 6 to show the stages of Dibbern et al.’s model and phases of Cullen et al.’s model which are relevant from the vendor’s viewpoint. 30 Table 7 Vendor stages and phases Stage model (Dibbern et al. 2004) Outsourcing life cycle model (Cullen et al. 2005) Stages Phases Investigate Target Strategise Intelligence – WHY Design – WHAT ARCHITECT Design Select Stages/ phases for clients only Choice – WHICH ENGAGE Negotiate Transition Implementation – HOW OPERATE Manage Implementation – OUTCOME REGENERATE Refresh Stages/ phases for both clients and vendors Source: Dibbern et al, 2004, Cullen et al. 2005 Table 7 shows that after a client has selected a vendor, then both client and vendor’s relationships are crucial for effective completion of the project. They each implement strategies to negotiate relationships, finalise the project transition plan, manage knowledge transfer and ultimately reflect on outcomes to refresh past practices and re-define better practices for future offshore projects. Thus ve ndors too learn from their past experiences as they evaluate their outcomes to identify successes and failures. 2.4 Offshore software development processes In the last two decades, development of software has moved away from the traditional co- located model, often called on-site development, to the off-shore model. The offshore software development model offers an opportunity to significantly reduce development costs, expand software development capacity, give timely access to highly qualified technical talent, reduce risk of cost overruns and late projects, streamline processes, increase flexibility, accept cultural diversity and improve quality (Gold, 2005; Ramasubbu et al., 2008). Vendors are moving to capitalise on the currently growing outsourcing scene, by trying to capture and emulate offshore development models that have met with success (Herbsleb & Moitra, 2001). Outsourcing success is measured by the operational delivery of 31 the contract, the ability to fairly adapt to ch ange and identify value-added services, within- budget completion and user participation (DeLone et al., 2005; Lacity & Hirscheim, 1994). However, offshore outsourcing for software development work is not without its challenges and may require significant changes to the organisation, processes and culture (Eppinger & Chitkara, 2006). Orlikowski (2002, p. 255) warns of the challenges in globally distributed software production due to many boundaries: temporal (e.g., various time zones), geographic (i.e., multiple global locations), social (many participants engaged in joint development work), cultural (various nationalities and organisational cultures), historical (e.g., different product development practices in the contractor and subcontractor companies) and political (e.g., different interests of the parties involved). The process of offshore software development requires client and vendor teams situated at different geographical locations to work together in virtual settings. These virtual settings rely heavily on information and communication technologies (ICT), through which team members can work together for common goals although separated by cultures and time zones. Much of the literature has dubbed such teams as “virtual teams”. More details on virtual team practice in the OSD environment have been described in the next section (section 2.5). The offshore environment has resulted in hybrid work patterns as practitioners make changes to their organisational models which are spread across multiple sites and nations to establish a collaborative team culture. For instance, deployment of vendor employees at offshore client locations aids in gathering end user requirements, retaining contextual information, reducing task uncertainty and providing quicker feedback on prototypes in the software development cycle (Ramasubbu et al., 2008). Typically for outsourced software development work, 70 to 80 percent of the work is done offshore at the vendor’s site and the other 20 to 30 percent is done onshore at the customer’s site (Gopal, Mukhopadhyay et al., 2002; RajKumar & Mani, 2001). However, th is onshore-offshore mix is not static and shifts over time depending upon peaks and troughs of workload in the software development life cycle (Sahay et al., 2003). Also, specifics of work functions help in 32 deciding the onshore and offshore positioning of vendor teams. Onshore positions at the client’s site maintain the strategic planning or architectural functions, while offshore positions usually require more tactical execution such as application coding, testing maintenance and software upgrades (Gold, 2005). The onshore and offshore teams engage in knowledge sharing and, because of large time and space differences, communicate via collaborative technologies to resolve issues relating to the software project. The project knowledge is embedded into project workspaces and organisational repositories. Groupware tools such as chat rooms, discussion foru ms and mailing lists are used to share the interrelated project knowledge. Hornett (2004b, pp. 197-9) states that explicit information may form the basis of knowledge sharing unl ess and until the members know each other, as tacit knowledge is hard to share if members do not have a common “mental schema” of ideas and so cannot understand how “ideas compete for value and use”. Thus virtual teams face additional challenges for knowledge sharing when team membership crosses boundaries into other businesses, for example clients and vendors, each having different “organisational allegiance” in different social environment. 2.5 Virtual teams This section expands on the previous section which highlighted the importance of virtual teams (VTs) in the OSD environment. It begins with the definition of the term “virtual teams” as has been used in literature. The characteristics of virtual teams that distinguish them from conventional teams are explained to demonstrate the emerging form of work structures in the context of knowledge based industry. Previous literature identifies virtual teams as open systems, because they adapt to and structure themselves in accordance with dynamic environment conditions (Anconna & Caldwell, 1992; Hornett, 2004a). Academic research has defined virtual teams as ….. temporary, geographically dispersed and electronically communicating workgroups. The temporary nature of the virtual team implies that members do not share a past history and may not work together in the future. Geographical dispersion implies that team members are situated across geographical and often organisational boundaries and rarely meet face-to-face. Finally collaboration 33 across time and space is enabled by a heavy reliance on computer mediated communications (Kanawattanachai & Yoo, 2007, p. 784). …… groups of geographically, organisationally and/or time dispersed workers brought together by information and telecommunication technologies to accomplish one or more organisational tasks (Powell, Piccoli, & Ives, 2004, p. 18). In virtual teams, much of the interaction occurs via text-based technology (i.e., email, chat or instant messaging), thus visual cues or voice tones are missing. The OSD environment offers a big challenge to VTs as the software development process involves the use of language that has a highly technical and know ledge-intensive content, and therefore information is more difficult to comprehend and share in a virtual setting than in a face-to- face setting. Knowledge is transferred across the Internet, as different social, technical and cultural experiences are combined. In the presence of such variations organisations have realised “the need to undergo a revision and restructuring of their IT methodology in order to successfully execute offshore” (Gold 2005, p. 49). Pauleen et al. (2001) report that facilitators play an important role in virtual team communication, as they help to build relationships, establish team processes, take responsibility for task completion and develop shared views and trust across cultural and technological boundaries. Electronic communication channels (such as emails, telephone, and desktop video conferencing among others) offer both benefits and barriers to relationship building in a virtual team environments. Facilitators need to adjust th eir work practices and develop “networking skills” over ICTs across diverse organisa tional boundaries (Pauleen & Young, 2001, p. 217). To understanding work practices in cont exts where “time-space distanciation” are emerging such as in “virtual teams where information and communicating technologies are mediating traditionally face-to-face interactions ”, Jones and Karsten (2008, p. 149) assert that Giddens’ structuration theory would help researchers understand temporal and spatial work patterns. Structuration theory (ST) attempts to link agents (team members) with agency (organisational identity) and social structure (work patterns). Organisational identity refers to processes through which team members (agents) develop identification. These processes of agency are defined through actions of agents, which in turn redefine 34 behaviours and rules, leading to new social structures in the work environment (Sahay et al., 2003). This study utilises Giddens’ structuration th eory (1990) as the underlying structure over which the knowledge management strategies used by vendor teams in the OSD environment is superimposed. To get a fuller appreciation of how this study examines the relationship between social structures and virtual team members (agents) within the OSD context, the structuration theory is explained later in the chapter (refer section 2.10). 2.6 Key drivers in knowledge transfer for offshore software development Software development is an iterative process, in which requirements change as development proceeds, thus requiring an interactive environment. The drivers involved in the outsourcing process are very complex, and are further complicated by the non-determinism of most methods as the continually changing business environment means that requirements are fluid. Knowledge is built, extended or transferre d as technical and social influences interact to confirm or give new meaning to existing knowledge, based on experiences. Outsourcing organisations have to manage both social and technical influences to achieve a level of maturity which will lead to improvements in processes and deliverables, and reduce the complexities, anxieties and insecurities that are inherent in software development. A review of the literature revealed the key drivers that have been considered important for successful software development in the offshore environment. These drivers have helped to construct a theoretical platform which formed the basis for the empirical investigation. These drivers are summarised in Table 8 and further discussed in separate subsections below. 35 Table 8 Key drivers in knowledge transfer for offshore software development Drivers Key points Sources Culture ⎯ Cultural and social theories ⎯ National and organisational culture ⎯ Team structures (Carmel & Agarwal, 2001; Davey & Allgood, 2002; Edwards & Sridhar, 2003; Ein Dor, Segev, & Orgad, 1993; Heales, Cockcroft, & Raduescu, 2004; Heeks et al., 2001; Herbsleb & Moitra, 2001; Kaiser & Hawk, 2004; Lurey & Raisinghani, 2001; Mockus & Herbsleb, 2001; Powell et al., 2004; Rottman & Lacity, 2004; Shore & Venkatachalam, 1995) Communication ⎯ Face-to-face ⎯ Groupware tools (synchronous/ asynchronous) ⎯ Common locations (Agerfalk & Fitzgerald, 2006; Crampton, 200 1; Dube & Pare, 2001; Herbsleb, 2007; Herbsleb & Moitra, 2001; Hinds & Weisband, 2003; Hulnik, 2000; Iacovou & Nakatsu, 2008; Lurey & Raisinghani, 2001; Mark, 2001; Powell et al., 2004; Sakthivel, 2005; Vlaar et al., 2008) Trust and relationship building ⎯ Socio-cultural theories ⎯ Risk management ⎯ Centralised offices ⎯ Reputation ⎯ Direct meetings ⎯ Intermediary consulting firms (Davey & Allgood, 2002; Dibbern et al., 2004; Dube & Pare, 2001; Edwards & Sridhar, 2003; Gold, 2005; Heeks et al., 2001; Hurley, 2006; Jarvenpaa, Shaw, & Staples, 2004; Kaiser & Hawk, 2004; Kishore, Rao, Nam, Rajagoplalan, & Chaudhury, 2003; Mockus & Herbsleb, 2001; Moore & Martorelli, 2004; Oza, Hall, Rainer, & Grey, 2004; RajKumar & Mani, 2001; Rottman & Lacity, 2004) Control and coordination mechanisms ⎯ Planning cycles ⎯ Distribution of tasks ⎯ Project schedules/ deadlines ⎯ No. of customer liaisons ⎯ Project status meetings ⎯ Documentation (Agerfalk & Fitzgerald, 2006; Carmel, 1999; Carmel & Agarwal, 2001; Das & Teng, 2001; Dibbern, Winkler, & Heinzl, 2008 ; Dube & Pare, 2001; Gopal, Mukhopadhyay et al., 2002; Kraut & Streeter, 1995; Nurmi, Hallikainen, & Rossi, 2005; Powell et al., 2004; Rottman & Lacity, 2004; Sabherwal, 2003; Vlaar et al., 2008; White & Lui, 2005) Project management practices ⎯ Test environment ⎯ Release stages ⎯ Requirement/ change / scope management, over-engineering ⎯ Interaction protocol (Agarwal, Kumar, Mallick, Bharadwaj, & Anantwar, 2001; Cullen, 2002; Dibbern et al., 2008; Dube & Pare, 2001; Edwards & Sridhar, 2003; Gane, 2001; Gold, 2005; Gopal, Mukhopadhyay et al., 2002; Herbsleb & Moitra, 2001; Iacovou & Nakatsu, 2008; Kirsch, Sambamurthy, Ko, & Purvis, 2002; Leornardi & Bailey, 2008; Livari & Huisman, 2007; Mingus, 2001; RajKumar & Mani, 2001; Rottman & Lacity, 2004; Urquhart, 1999) Staff attrition ⎯ Training ⎯ Prior domain experience ⎯ Incentives/ rewards Hertel, 2004: Gosain, Gopal, & Darcy, 2005; Jennex & Adelakun, 2003; Ouchi, 1978 ;Ravichandran & Rai, 2000; Rao 200 8 ; Sakthivel, 2005) Quality practices ⎯ Certifications ⎯ Audits ⎯ Documentation (Adler, McGarry, Irion-Talbot, & Binney, 2005; Agarwal et al., 2001; Endres & Rombach, 200 3; Gopal, Mukhopadhyay et al., 2002; Jalote, 1999; Oza et al., 2004; Ramasubbu et al., 2008; Sahay et al., 2003) Type of contract ⎯ Fixed/ Time & material ⎯ Risk management ⎯ Contract negotiation (Dibbern et al., 2008; Ethiraj, Kale, Krishnan, & Singh, 2005; Gopal & Sivaramakrishnana, 2008; RajKumar & Mani, 2001; Rottman & Lacity, 2004; Sahay et al., 2003); 36 2.6.1 Culture Culture has often been treated from a social psychology perspective as something that differentiates one social group from another (e.g. Hofstede & Hofstede. 2005; Schein 1984) or conceptualised as a variable that needs to be considered in the system development process (e.g. Ein Dor et al., 1993; Shore & Venkatachalam, 1995). Walsham (2002) views culture to consist of shared symbols, norms and values in a social collective such as a country. Interest in the impact of culture in global businesses is increasingly becoming a feature of IS outsourcing literature (e.g. Heeks et al., 2001; Herbsleb & Moitra, 2001; Kaiser & Hawk, 2004; Sahay et al., 2003; Shore & Venkatachalam, 1995; Walsham, 2002). Hofstede’s (1990) study on national cultures has been applied by some researchers for analysing software development work practices (Heales et al., 2004). In his study, Hofstede analysed the four dimensions of national culture – namely power distance (from small to large), collectivism versus individualism, feminism versus masculinity and uncertainty avoidance (from weak to strong). Hofstede’s four cultural dimension indexes are: 1. Power Distance Index (PDI): The degree to which societies expect and accept that power is distributed unequally; 2. Individualism Index (IDV): the degree to which individual or collective relationships are re-enforced within societies; 3. Masculinity Index (MAS): the degree to which traditional masculine forces are re- enforced; 4. Uncertainty Avoidance Index (UAI): the degree to which societies feel threatened by ambiguous or unknown situations. To understand the impact of Hofstede’s key culture dimensions in the context of New Zealand and India, the study uses an extract of these two countries from the list of 74 countries. Table 9 shows a comparison of these key dimensions. 37 Table 9 Hofstede’s culture dimensions (New Zealand and Indian context) Index score and global rank (GR) Key culture attributes These indexes represent relative, not absolute positions of the countries (done for 74 countries and regions) New Zealand India Power distance index (PDI) World Average of PDI ~ 56.5 Low PDI indicates a smaller power distance (i.e. less hierarchy in relationships across societies, families, organisations). High PDI indicates a higher power distance (i.e. more hierarchy in relationships across societies, families, organisations). PDI = 22 GR = 71 PDI = 77 GR = 17 – 18 Individualism index (IDV) World average of IDV ~ 44 Low IDV indicates a collectivist society (i.e. societies in which people are integrated in strong cohesive in-groups, which protect them in exchange of loyalty). High IDV indicates an individualist society (i.e. societies in which ties between individuals are loose: everyone is expected to look after himself/herself). IDV = 79 GR = 7 IDV = 48 GR = 31 Masculinity index (MAS) World average of MAS ~ 51 Low MAS represents a more feminine society where gender roles overlap. High MAS represents a more masculine society in which gender roles are clearly distinct. MAS = 58 GR = 22 – 24 MAS = 56 GR = 28 – 29 Uncertainty avoidance index (UAI) World average of UAI ~ 65 Low UAI indicates a low level of anxiety for uncertainty and ambiguity. High UAI indicates a high level of anxiety for uncertainty and ambiguity. UAI =49 GR = 58 – 59 UAI = 40 GR = 64 Source: Hofstede and Hofstede, 2004 The Table 9 data indicate New Zealand culture to be fairly decentralised with flat hierarchical pyramids within organisations, having an individualistic approach and with medium to low anxiety levels for uncertain situations. Indian culture, on the other hand shows centralised power with more hierarchical structures within organisations, having a collectivist approach and with lower anxiety levels for unknown situations. Moreover, the table also shows that the gender roles for individuals in both countries do not differ much. Another study called the GL OBE study (Global Leadership and Organisational Behaviour Effectiveness) drawn from organi sational and management science has also adopted a dimensional paradigm and identified cultural scores for 61 countries (House et al., 2004). The GLOBE researchers used constructs for performance orientation, 38 future orientation, gender egalitarianism, a ssertiveness, institutional collectivism, in- group collectivism, humane orientation, pow er distance and uncertainty avoidance across diverse industry types (e.g. food processing, finance services and telecommunication industry). The GLOBE dimensional indices are: 1. Performance Orientation Index (POI): The degree to which societies encourage the practice of rewarding performance improvement and the extent to which respondents value these practices; 2. Future Orientation Index (FOI): the degr ee to which societies plan for future contingencies for meeting future aspirations; 3. Gender Egalitarianism Index (GEI): the degree to which societies prescribe different roles for men and women; 4. Assertiveness Index (AI): the degree to which individuals in society exhibit tough, dominant and aggressive behaviour in social relationships; 5. Institutional Collectivism Index (ICI): the degree to which employees consider themselves independent of their organisation and are willing to leave the organisations if their goals are not met; 6. In-Group Collectivism Index (IGI): the degree to which individuals engage in group activities at the societal level; 7. Power Distance Index (PDI): the degree to which societies accept and endorse power differences and status privileges; 8. Human Orientation Index (HOI): the degree to which societies encourage fair, altruistic, friendly and generous behaviour; 9. Uncertainty Avoidance Index (UAI): the degree to which ambiguous situations are tolerated in a society. Next, using an extract of New Zealand and Indian country contexts from the 61 countries surveyed in GLOBE research, Table 10 shows a comparison of their cultural indices. 39 Table 10 GLOBE culture dimensions (New Zealand and Indian context) Index score and global rank (GR) Key culture attributes These indexes represent relative, not absolute positions of the countries (done for 61 countries and regions) New Zealand India Performance orientation (POI) World average of POI ~ 4.10 High POI indicates societies value and reward individual achievements. Low POI indicates societies value societal relationships and view rewards as inappropriate. POI = 4.72 GR = 5 POI=4.25 GR = 22 – 23 Future orientation (FOI) World average of FOI ~ 3.85 High FOI indicates societies value deferment of gratification for long- term success. Low FOI indicates societies value instant gratification and want instant rewards. FOI = 3.47 GR = 48 FOI = 4.19 GR = 15 Gender egalitarism (GEI) World average of GEI ~ 3.37 High GEI indicates less occupational gender segregation in societies. Low GEI indicates more occupational gender segregation in societies. GEI = 3.22 GR = 38 GEI = 2.90 GR = 55 Assertiveness (AI) World average of AI ~ 4.14 High AI indicates assertive tough behaviour to be acceptable in society. Low AI indicates modesty and tenderness behaviour to be acceptable in society. AI = 3.42 GR = 60 AI = 3.73 GR = 53 Institutional collectivism (ICI) World average of ICI ~ 4.25 High ICI indicates a greater collectivism within organisations Low ICI indicates more individualism within organisations. ICI = 4.81 GR = 5 ICI = 4.38 GR = 26 In-group collectivism (IGI) World average of IGI ~ 5.13 High IGI indicates a collectivist society (i.e. individual goals tend to be compatible with in-group goals). Low IGI indicates an individualist society (i.e. individual goals tend not to be compatible with in-group goals). IGI = 3.67 GR = 59 IGI = 5.92 GR = 4 Power distance (PDI) World Average of PDI ~ 5.17 High PDI indicates more hierarchy in relationships across societies, families, organisations. Low PDI indicates less hierarchy in relationships across societies, families, organisations. PDI = 4.89 GR = 48 PDI = 5.47 GR = 16 Human orientation (HOI) World Average of HOI ~ 4.09 High HOI indicates values of altruism, benevolence, kindness and love have high priority. Low HOI indicates values of pleasure, comfort and self-enjoyment have high priority. HOI = 4.32 GR = 19 HOI = 4.57 GR = 10 Uncertainty avoidance (UAI) World average of UAI ~ 4.16 High UAI indicates higher levels of anxiety for ambiguity. Low UAI indicates lower levels of anxiety for ambiguity. UAI =4.75 GR = 12 UAI = 4.15 GR = 29 Source: House, Hanges, Javidan, Forfman, Gupta, 2004 40 The GLOBE indices in Table 10 identify New Zealand to be very performance oriented, have lower future orientation, less segregation of gender roles in society, less toughness in behaviour, greater institutional collectivism but lower in-group collectivism, medium levels in power distance, high human orientation and high levels of anxiety for uncertain situations. In contrast, India is identified to be less performance oriented, have higher focus for future goals with more segregation of gender roles in society, have more toughness in behavioural characteristics with more individualist behaviour within organisations but less individualism within social groups, have higher levels in power distance and human orientation and finally with lower levels of anxiety for uncertain situations. It is not possible to make a direct comparison between GLOBE cultural indices and Hofstede’s cultural indices for New Zealand and India, however some of the obvious differences are found to be in gender roles within societies and individualism and collectivism behaviours. Finally the gap between levels indicative of power distance is found not to be as large in the GLOBE study as has been found in Hofstede’s study. Literature also reveals that both studies have challenged each other’s construct validity, definition of indices and sampling strategies (Hofstede 2006; House et al. 2004). Cross-cultural issues take on a different form and level of complexity within the offshore IT industry. Hofstede’s research and GLOBE studies on national cultures promote a static formulation of culture and ignore the processes by which cultures are constituted and maintained. While these studies have provided value in understanding of cultural differences, Myers and Tan’s (2002, p. 24) view is that “research in culture and global information systems should adopt a dynamic view of culture – one that sees culture as contested, temporal and emergent”. Therefore this study does not use cultural determinism as implied by Hofstede and GLOBE; instead it uses structuration theory to understand the dynamic nature of cultures in the OSD environment. ST defies Hofstede’s stereotyping of “national culture”, and states that social systems lack internal unity which may be found in physical or biological systems (Sahay et al., 2003). Walsham (2002) argues that ST provides a deeper understanding of cross-cultural work than Hofstede’s study in areas such as global software production where global teams rather than local teams carry out the software development work. Walsham applied ST to the 41 process of software development in a globally distributed environment, and found that national cultures are composed of many different people, each with a complex structure in their minds, none of which can be thought of as fully shared. However Walsham also says that structural properties of cultures display enough common rules to speak about them having some shared norms and values. Sahay et al. (2003, p. 93) also adopt a structurational viewpoint in the context of OSD, and state that “culture provides the context that shapes and is shaped by the articulation of agency through a subtle instantiation of rules linkage”. They further add that “sociological structures from different countries are brought together across time and space, and knowledge in the shape of methodology is dis-embedded and re-embedded” which is displayed in their working practices (p. 172). They warn organisation theorists to be aware of political and cultural implications when they develop methodologies or frameworks for outsourcing of knowledge work by virtual organisations. 2.6.2 Communication The core of any virtual team process is communication (Powell et al., 2004) and communication is necessary in virtual work for the success of OSD. Communication helps VTs to understand the processes of interpretation of documentation, re-definition of methodologies and change agents, cultural expressions, revision of requirements and similar processes. There are constant revisions to communication strategies, as structures of understanding shape the communication process. Research has established the significance of co mmunication issues in shaping the nature of business relations and practices within the offshore IT industry (refer Table 8). However, effective communication is impacted by the choice of the offshore facility, and depends on availability of the right skills and a good communication infrastructure. Choice of certain offshore countries limits the use of synchronous communication media because extended time zone differences between onshore and offsho re countries requires either party to work late hours beyond regular office hours (Sakthivel, 2005). 42 The virtual settings of the OSD environment imply that the teams rely more on ICT- mediated communication rather than on face-to-face (F2F) communication. F2F interaction provides rich social information that cannot be obtained through communication technologies. Technology tends to restrict the communication process because electronic media are intrinsically leaner than F2F communication and convey a limited set of communication cues (Powell et al., 2004; Sproull & Kieser, 1986). Software teams are, by their very nature, interdependent. Members complement each other's skills to achieve a collective way of organising relevant knowledge, learn together, relate activities to one another and develop mutual expectations along dimensions of goals, tasks, processes, requirements and accomplishmen ts (Hinds & Weisband, 2003). This is especially challenging for VTs, which have to overcome the lack of a common frame of reference for all members, different language interpretations, cultural differences, co- ordination problems and technology infrastructure problems (Crampton, 2001; Kobitzsch, Rombach, & Feldman, 2001; Mark, 2001). Moreover, nonverbal communication is another important component of team communication, which is usually missing in VTs. Once participants have met physically, then e-mail can be operated at an informal level. Thus, travel and direct meetings are a continuous and crucial element in outsourcing relationships to help fully synchronise information (Heeks et al., 2001). The presently available technological support systems encompass a wide range of technological applications that allow individuals and teams to communicate, exchange information, interact collaboratively and manage data, within the group and outside the group, synchronously and asynchronously (F erris & Minielli, 2004). VTs now use messaging systems to communicate in real time through asynchronous messaging (e.g., e- mail, discussion forums, bulletin/message boards, Weblogs, short messaging service (SMS)) or through synchronous messaging (e.g., chat or conferencing). Multi-user wiki websites support informal interaction through use of Weblogs or discussion forums using open source software. John Seely Brown, former director of the Xerox Palo Alto Research Centre has said that …..rapid development of social software" like instant messaging, Weblogs (commonly called blogs), wikis (multi-u ser Weblogs) and peer-to-peer tools - 43 make it easier for workers to communicate and collaborate online, almost instantaneously (Lohr, 2004). Blogs can keep a running, time-ordered record of discussions concerning requirements, design trade-offs and decisions, thus making them into a groupware tool for communication and coordination. The asynchronous nature of blogs or wikis makes them ideal for a team spread across different locations and time zones (Herman, 2003). 2.6.3 Relationship building The management of a relationship includes all conscious activities of the parties to impact the relationship in a desired way. Relationships are bi-directional, and may affect both client and vendor at organisational and individual levels, and both parties are vulnerable to risks affecting their business, including legal, political, infrastructure, workforce, social, and logistical risks. Minimising such risks is cr ucial to both the client (buyer) and the vendor (seller), since both are partners in this exchange and need to obtain value from it. Establishing the relationship between vendor and client is a social and political process (Urquhart, 1999). Some characteristics for relationship building include trust, socio-cultural adaptation, shared vision, communication, commitment, fair bargaining, age of relationship, mutual dependency, cultural compatibility, conditional payments, penalty for underperformance and risk sharing amongst others (Aubert, Dussalt, Patry, & Rivard, 1998; Dibbern et al., 2004; Kern, 1997; Lee & Kim, 1999; Willcocks & Kern, 1998). IT professionals have been seen as lacking credibility, not in expertise but in relationship building (Bashein & Markus, 1997). Pauleen (2004) has investigated issues facing VTs when they build relationships across organisational and cultural boundaries and have identified a three step model for virtual team leaders to help build effective relationships. The three steps are assessing conditions, targeting levels of relationship and creating strategies. Figure 3 illustrates the three step mode l for developing virtual relationships. 44 Figure 3 Relationship building model Source: Pauleen 2004 Figure 3 shows that in step one – assessing conditions – virtual team leaders review conditions of the team, team members and ot her organisations involved in the virtual project tasks. In the second step – targeting levels of relationship – virtual team leaders carefully consider the dynamics of the relationship to further nurture and develop the relationship. Finally, based upon the evaluations of step one and step two, organisations create strategies for effective implementation of communication channels to build trust and goodwill amongst the distributed team members. The communication channels may include both computer mediated processes and direct F2F settings during different phases of the project life cycle. Vendors are now adding relationship management and customer advocacy to their portfolio of skills as they deliver customer-intimate enterprise solutions for clients across geographies (Moore & Martorelli, 2004). These in itiatives refer to the various socio-cultural processes inherent in the process of knowledge transfer, including the manner in which Task to be undertaken by virtual team Assessing conditions Targeting levels of relationship Creating Strategies Engaging in task wor k Factors present at the initiation of a virtual team (i.e. team issues, boundary crossing, organisation al policies, technology) Level of personal relationship a leader might choose to develop with a team member (i.e. low, medium, high) Selection and use of appropriate communication channels and messages. Leader undertakes: 45 clients and vendors draw upon and apply different forms of explicit-implicit, formal- informal knowledge (Sahay et al., 2003). Both the client and the vendor contribute to relationship building through practices adopted for reducing ambiguity and uncertainty in each other’s social perceptions (Jarvenpaa et al., 2004). Heeks et al. (2001) identify regular travel and direct meetings as a crucial element in building outsourcing relationships, to help synchronise working patterns between teams. From the client perspective, Rottman and Lacity (2004) emphasise open communication and face-to-face meetings with the supplier’s em ployees to build trust and confidence in the relationship. Once the initial relationship ha s stabilised, it may be extended to include vendor’s employees at the client’s site to promote understanding of the work under development. They also emphasise other practices, such as: a centralised project management office; hiring of an intermediary consulting firm to serve as a broker, guide and legal expert; selection of preferred choice of country sourcing locations; use of pilot projects to mitigate risks; secure information links; understanding one’s own organisational processes with respect to the supplier’s processes and negotiating accordingly. The above mentioned practices affect the vendor too, and the vendor should be aware of the client’s perspective to mitigate risk. Successful relationships are termed “ synching” involving a high degree of congruence between vendor and client; and unsuccessful relationships have been termed “ sinking” , when there is a low degree of congruence between the vendor and client (Heeks et al., 2001). Congruence fosters trust between client and vendor, and this trust can progress the relationship to larger, more demanding projects with more offshore components. For the vendor, sustaining synching relationships will help in building up their reputation, further increasing their business resilience, and eventually enhancing their market position. 2.6.4 Trust There are many suggestions from previous research for establishing and understanding the meaning of trust in a business relationship. Giddens (1990) relates trust to lack of visibility between the parties. He states 46 Trust is related to absence in time and space. There would be no need to trust anyone, neither individuals nor abstract sy stems, if their activities were visible and easy to understand. So the prime condition for lack of trust is lack of full information (p. 33). Choo (2006) identifies trust to be a ….psychological state expressed as the willingness to be vulnerable under conditions of risk and interdependence. Trust is not a behaviour (such as cooperation) or a choice (such as taking a risk), but an underlying psychological condition that can cause or result from such actions (p. 193). In a business environment, Hurley (2006, p. 56) views trust as a relational concept and says trust is a measure of the quality of a relati onship between two parties, as “when people choose to trust, they have gone through a decision-making process – one involving factors that can be identified, analysed, and influenced”. Their decision making is influenced by the fact that individuals are basically tribal and self-centred, and so find it easier to trust those who appear similar to themselves, as they can be counted on to act similarly in a given situation. People tend to tally up similarities and differences such as working style, cultural groups, accents, dress code, or even gender within their local visible spaces, before they begin to trust the other party. This has been termed in an earlier study as trustworthiness , which is a belief that comes before trust and is an intention or willingness to depend on another party (McKnight, Cummings, & Chervany, 1998). Thus, according to Hurley, trust is dependent on both the parties – truster and trustee – in a business relationship, where similarities in their cultural groupings and working styles lead to a feeling of ‘trustworthiness’ and ‘willingne ss to be vulnerable’ under conditions of risk and interdependence. Hurley proposes a trust model in which he identifies ten key factors to guide parties for decision making about who to trust and who not to trust in a business relationship. Three decision maker factors of tr ust are associated with the truster, while seven situational factors are associated with the relationship between truster and trustee (see Table 11). Hurley encourages researchers to apply his decision making trust model to inter- organisational business situations, such as in the context of outsourcing and mergers. 47 Table 11 Trust model D ec is io n- M ak er Fa ct or s Low 1. How risk tolerant is the truster? 2. How well-adjusted is the truster? 3. How much relative power does the truster have? High Si tu at io na l Fa ct or s Low 4. How secure do the parties feel? 5. How similar are the parties? 6. How well aligned are the parties interests? 7. Does the trustee show benevolent concern? 8. Is the trustee capable? 9. Has the trustee shown predictability and integrity? 10. Do the parties have good communication? High Choice DISTRUST TRUST Source: Hurley 2006 Based upon previous definitions of trust available in the literature, this study defines trust in a business environment as “the process of accommodating a shared understanding of socio-cultural differences across client-vendor relationships for a larger professional cause”. The shared understanding is based upon multidimensional conditions such as interdependence, where interests of one party cannot be achieved without reliance on another, perceptions of each other’s cultural and societal structures, and feeling of vulnerability due to lack of visibility of each other’s actions. Though lack of visibility across geographical boundaries cannot be avoided, some transparency in information can be brought about by engagement and relationship philosophy and good relationship management skills (Moore & Martorelli, 2004). Or ganisations try to increase transparency of their geographically dispersed operations by using tools that facilitate sharing of information and artefacts in the shared virtual space. These tools help in building trust among the geographically dispersed members as, over time, these tools transform faceless commitments into scripted tasks or facework commitments (Sharma & Krishna, 2005). Virtual teams that use more social communication achieve higher mutual trust and better social and emotional relationships (Jarvenpaa & Leidner, 1999; Robey, Khoo, & Powers, 2000). Another factor for building trust is the reputation of the parties involved. Reputation promotes cooperation by enhancing the probability of carrying out promises, though 48 reputation, being a publicly held opinion, is more ambiguous than trust and is open to manipulation and stereotyping (Misztal, 1996). Trust has also been described to have “a highly situational context” where levels of trust perception “changes with time and level of communication, and the change may not be necessarily direct and linear. Contextualised views of organisational settings will help to better understand how trust effects operate in IT -enabled relationships” (Jarvenpaa et al., 2004, p. 262). From an IT perspective, Jarvenpaa et al. (2004) emphasise that technology changes the context of trust in human relationships, and, suggest the application of different theoretical models for the study of trust in global virtual teams. For virtual teams, trust is contextual and depends upon both organisational structures and time. Their view is that “time is important because it is a critical pa rt of the context” resulting in different managerial interventions leading to changes in organisational structure (p. 262). They argue that in structured organisational settings, trust has an initially weak direct effect on attitudes as people refer to their own pre-existing psychological dispositions, but as the settings attain more structure, trust has a moderating effect on attitudes and performance, as people revise their understanding of each other’s motives. This is also in agreement with ST, as when situations are re-defined and re-exported in different social contexts, the reflexivity of human opinions brings in a moderating influence on their attitudes. 2.6.5 Control and coordination Offshore software development projects are vulnerable to control, coordination and administration problems that affect project performance, and initiatives to counter the challenges associated with work dispersion remains an open empirical question (Aman & Nicholson, 2003; Ramasubbu et al., 2008). If software projects in the offshore context are not effectively controlled and coordinated, this could result in additional costs for clients in the transfer of client-specific knowledge to the vendor (Dibbern et al., 2008). Control and coordination are two separate contexts, though they are interrelated, as coordination enables control and vice versa (Dibbern et al., 2008; White & Lui, 2005). Control is the process of adhering to goals, policies, standards, or quality levels, through formal or informal methods. This could be measured by output control (e.g., quality of 49 software solution) and behaviour control (e.g., behaviour of vendor personnel at onshore and offshore locations). Coordination is the act of integrating each task with each organisational unit, so that the unit contributes to the overall objective. This includes distribution of tasks, proper procedures and infrastructure for information exchange and coordination requires intense and ongoing communication. (Dibbern et al., 2008; Nurmi et al., 2005). Thus, communication is a mediating factor that affects both coordination and control, but it is a significant challenge for global software development as distance negatively affects communication, which in turn increases efforts for governance of coordination and control measures (Carmel & Agarwal, 2001). Sabherwal (2003) studied coordination in outsourced system development projects and categorised coordination mechanisms as standards, plans, formal mutual adjustments and informal mutual adjustments. Controls that specify milestones, deadlines and deliverables help to improve output and behaviour controls, as they reduce the complacency in the vendor’s development effort and team members adhere to the immediacy of the specified schedules. However, considerable coordination information is required to set up meetings and common schedules, and integrate work outputs across locations. When geographically dispersed members lack interaction to achieve a non-local view of a task, they may assume the worst of their remote team partner’s work progress and may project these negative perceptions to other co-located partners (Sutanato, Kankanhalli, & Tan, 2005; Wooldridge, 2002). However trust too can affect the way people interpret non-responsiveness, as low trust may foster negative attitudes towards the other party, if the other party does not promptly respond to previous communication (Jarvenpaa et al., 2004). Drawing on the work of White and Lui (2005, p. 914), Dibbern et al (2008) relate coordination to the concept of cooperation, which informs on the “social integration” that is “necessary in order for partners to combine resources and integrate their activities in the course of undertaking a joint task”. Clients and vendors need to jointly invest in team building for social integration (Das & Teng, 2001) and work together in a collaborative way. Orchestrating integration often requires intense and ongoing communication, but discussion and team interactions in virtual environments can be lengthy and confusing, leading to poorer comprehension and understanding when compared to traditional physical meetings (Bordia, 1997; Heeks et al., 2001). As a consequence, some researchers see 50 periodic face-to-face meetings amongst team members located at different geographical zones as necessary for successful project de velopment (Saunders, 2000). For distributed software development, documentation of various artefacts is very important, with a continual need for updating and revising the documentation to reflect the currency of processes within the development work, as poor documentation can cause ineffective collaborative development (Herbsleb & Moitra, 2001). Agerfalk et al (2006) add that global software development has to address challenges associated with temporal, geographical and sociocultural (TGS) distances. They identify issues associated with TGS distances and their impact on communication, coordination and control practices in the context of software development processes (refer Table 12). Table 12 Temporal, geograhical and sociocultural issues Temporal distance Geographical distance Sociocultural distance C om m un ic at io n + Improved record of communications - Reduced opportunities for synchronous communication + Closer proximity to market, access to remote skilled work forces - F 2 F meetings difficult + Innovation and sharing best practices - Cultural misunderstandings C oo rd in at io n + Coordination needs can be minimised - Typically increased coordination costs + More flexible coordination planning - Reduced informal contact can lead to lack of critical task awareness + Greater learning and richer skill set - Inconsistent work practices, reduced cooperation arising from misunderstanding C on tr ol + 24 x 7 working hours - Management of project artefacts may be subject to delays + Communication channels can leave an audit trail. - Difficult to convey vision and strategy, perceived threat from training low-cost “rivals” + Proactiveness inherent in certain cultures - Different perceptions of authority can undermine morale, managers must adapt to local regulations + Benefits, - Risks Source: Agerfalk and Fitzergerald 2006 Agerfalk et al (2006, pp. 28-30) suggest a “flexible tailored” approach for combining communication, coordination and control mechanisms in a distributed software development environment to balance process flexibility of agile development methods (e.g. tailoring of development methods to different contexts, collective code ownership, lean structures) with the discipline of traditional development methods (e.g. plan-based 51 approaches, documentations, formalisations). They advocate a hybrid practice for development of software as “one-size-fits-all” is “the wrong solution to new problems” which may arise due to the TGS distances. 2.6.6 Requirements management Requirements define the “what” and “why” rather than the “how” of a system, i.e. they state which functions should be there, but not how they are provided. Requirements management is composed of four major activities: capturing the requirements, organising them, reviewing them and controlling them (Kuver, 2001). This process of requirements gathering is complex, and is embedded in human communication between stakeholders, subject to social, conceptual, organisational and indi vidual factors (Urquhart, 1999). Moreover as Boehm’s 6 first law, which is based on case studies , states “Errors are most frequent during the requirements and design activities and are more expensive the later they are removed” (Endres & Rombach, 2003). Also, requirement errors are more serious than design errors, because if the development team is unaware of the requirements, it can be misled and can move entirely tangentially to the desired direction. The application specific domain knowledge residing with the client needs to be transferred to an external vendor for it to be reflected in the software application. However, the client continually produces new application domain knowledge which reflects its constantly changing business requirements (Dibbern et al., 2008). Both clients and vendors need to invest time, effort and resources for knowledge transfer and related specification costs, particularly if a large amount of client-specific knowledge is involved. This may imply that the vendor personnel stay onshore at the client’s site for a certain period of time, where both client and vendor work out the knowledge transfer strategy in a collaborative way. A study by Dibbern et al. (2008) from the client’s perspective warns that knowledge transfer is limited by the lack of absorptive capacity of the vendor. By lack of absorptive capacity, they imply inexperience of the vendor’s team members, their lack of creativity and low support of technological and project management capabilities to absorb and apply 6 Barry Boehm is a pioneer in the field of software engineering and has set many guidelines on defining work practices for software development. 52 new knowledge. However, the other perspective of having too much absorption capacity may lead to over-engineering or unnecessary refinement of requirements. This area of over- engineering, dubbed “featuritus” by Endres and Rombach (2003) is still considered an open area of study. Featuritus may result from over enthusiastic developers or by over knowledgeable and interfering customers, and in both cases senior management mediation is required. A customer with in-depth technical understanding about the project is more likely to attempt to exert control on the development process and demand additional features and functionality, all of which interfere with the development activities (Kirsch et al., 2002; RajKumar & Mani, 2001). Rajkumar and Mani (2001) warn vendors of customers’ shortcomings in defining the scope, and they suggest adopting a strategy at the start of the relationship to control scope. Incremental releases of the project are helpful in controlling scope, though too many incremental rel eases or status meetings at later stages may generate new ideas further leading to rework due to new requirements. They suggest using fixed contracts for well-defined projects and flexible contracts (e.g. time and material) for R&D projects. Changes in project scope, however, are not always foreseeable and development teams need to define appropriate change management strategies to manage requirement volatility drivers. Some suggestions from the literature are use of precisely defined explicit knowledge documentation depending upon the size of the change rather than too much unnecessary documentation, and socialisation strategies to create shared tacit interpersonal knowledge and team cohesion for rapidly adapting the application to accommodate the change (Agerfalk & Fitzgerald, 2006). 2.6.7 Project management Good project management practices help system developers capture and resolve issues as they appear during the life of the project and are key to improving project control and quality (Murray, 2002). It is critical for offshore software vendors to capably manage their projects. Although projects can be managed without a formal methodology, having a methodology in place is a big help (Mingus, 2001). System development methodologies provide general information about standards and practices; and project management is concerned with budgeting and reporting of project activity cost and time. It is important to 53 unify them into a cohesive single process, to identify collectively the time spent on individual tasks, the effect of these tasks on quality, any gaps in the present methodology, whether realistic estimates were made on effort and delivery schedule, customer satisfaction at various stages, the incentive climate for the project teams, training programs and any other factors that may affect management of the project (Gane, 2001). Karolak (1998) identifies documentation of activities to be essential for management of projects in the virtual OSD environment. He says ……in a virtual project, documentation is the glue that holds the project together – more so than in non-virtual projects. Documentation such as the software development plan outlines roles and responsibilities. Requirements specifications and plans such as quality assurances identify expectations for all team members before issues come up and cause confusion (p. 22). Documentation also helps in reflecting the cu rrency of processes within the development work as the product knowledge evolves in the distributed sites (Herbsleb & Moitra, 2001). But studies have also identified flexibility to documentation and advise that the best practise on documentation is “neither to add more documentation nor to abandon documentation – it is to get better documentation”(Agefalk & Fitzgerald, 2006, p. 29). The software development platform ….needs to be a repository which specifies actual requirements of the software is intended to satisfy, high level design decisions that have been taken about the architecture of the code, and how different components of the software interact though interfaces and eliminate duplication of associated tasks (Rajamani, 2007, p. 9). The interdependent nature of distributed software development means team members must find a collective way of organising relevant knowledge. Organisations need to adjust knowledge about configuration processes, techniques or methods to a common level with their offshore partner. Several tools and devel opment environments are available to support 54 these development and project management activities. Transparent tracking of project data spread over different locations worldwide requires an advanced communication infrastructure (Kobitzsch et al., 2001). Version controls help to reflect the currency of project tasks, and distributed teams can identify the most recent design modules through practices defined for naming of versions during different stages of the development cycle. Teams use varied groupware tools and technologies to facilitate coordination and control of work flows as they synchronise test fixtures and activate change management agents to inform each other of the project status. Proper synchronisation of test procedures (e.g. defined milestones, clear entry and exit criteria) between the teams is essential, especially if the development team is at one site and the test group is at the other site (Herbsleb & Moitra, 2001). File sharing and creating scope-oriented changes to the shared design need to be effectively integrated into the development methodology to resolve conflicts that may arise due to incompatible versions being used at different locations. Moreover, close customer-vendor interactions help to build trust and confidence, besides providing up-front architectural design with more accurate and complete project requirements. Mature software processes (e.g. CMM, ISO 9001) help vendors identify the need for effective communication infrastructure, system development proces ses and management systems for project management activities (Adler et al., 2005; G opal, Mukhopadhyay et al., 2002; RajKumar & Mani, 2001; Ramasubbu et al., 2008; Sahay et al., 2003; Sakthivel, 2005; Tiwana, 2003). 2.6.8 Staff attrition The problem of attrition in the software industry means that the tenure of individuals in organisations is often limited; hence Dibbern et al. (2008) warn clients against off-shoring software projects to vendors who have very high personnel turnover. When experienced professionals with knowledge of prior contex ts leave the projects mid-way, the projects are handed to new members who lack the contextual knowledge for making strategic decisions. The new members often have to go through a steep learning curve to develop the same appreciation of work processes a nd build local contextual knowledge, and this could lead to overruns of project schedules. 55 Vendor organisations have to be prepared to reduce the impact of staff turnover on project schedules. Vendors try to manage this problem by reducing their dependence on individuals. They do this by resorting to different kinds of formalised computer based knowledge management systems to recognise individual knowledge contributions to fit team member’s achievements with organisational goals. These practices include rewards for behaviour-based, performance-based, schedule-based and collaborative clan-based performances (Gosain, Gopal, & Darcy, 2005; Ouchi, 1978). To motivate individual team members to share their work habits and develop shared perceptions, management needs to mandate certain kinds of behaviour for nourishing a collaborative culture; applaud individual and team achievements by rewarding performances, such as awards for knowledge sharing and value addition; and encourage goal-based outcomes for conforming to quality and schedules (Gosain et al., 2005; Sakthivel, 2005). Reward structures emphasise recognition of the individual and team contribution and help in developing teamwork, building collective knowledge and sharing of knowledge assets among the team members (Hertel, 2004; Ravichandran & Rai, 2000; Sakthivel, 2005). Sakthivel warns that “an inappropriate reward structure may kill motivation and contribution” and advises that managers “need to act as mentors, exhibit empathy, be sensitive without being aggressive, build relati onships with trust, and provide detailed and regular communication with team members” (p. 311). Career paths must be established and care taken to ensure that management is meeting the needs of their staff in order to retain staff (Jennex & Adelakun, 2003). Some practices to reduce the impact of staff attrition are establishing backups, mentoring, programming and testing standards, code reviews, documentation standards, and maintenance screens (Cullen, 2002; Sahay et al., 2003). However, Livari and Huisman (2007) observe that organisations which define more standards and formalisations as a means of imposing security, order and routinisation have a more hierarchal cultural orientation. But for vendor organisations to be secure from the high volatility of the IT labour market, some formal discipline in the deployment of system development methodologies may be needed to reduce their dependence on individuals. 56 2.6.9 Quality management “Organisations are systems of interlinked processes and the effectiveness of organisational processes essentially determines the quality of products and services” (Ravichandran & Rai, 2000, p. 390). The interlinked process for establishing quality has a very wide scope, as it involves processes not only for building of robust, reliable and secure software, but also involves processes that enable the groups of people building the software to work more productively and effectively on their tasks. Software quality is influenced by the development process, the design choices, the quality indicators chosen and customer satisfaction (Gold, 2005). An organisation’s co mmitment to quality fosters a process-based learning environment, in which individual processes are understood, tailored, interpreted and applied at an organisational level. For software development processes in the OSD environment, Ramasabbu et al. (2008) identify cycles of contextualisation and institutionalisation as a mechanism to improve project productivity and quality. They suggest mature processes such as the capability maturity model (CMM) to enable contextualisation of organisational processe s from specific project environments into institutionalisation of newly defined routines, as new knowledge enters into the organisational knowledge repository. The repository consists of organisational process assets such as a software process database containing historical data from all organisational units, document libraries and policy documents to prescribe organisation-wide benchmarks for their preferred software processes. Use of the prescribed standardised software processes have a significant payoff in terms of project success (Gopal, Mukhopadhyay et al., 2002) and allow for many reuse opportunities, saving on cost, time and effort (Herbsleb & Moitra, 2001). Standardisation helps to impart structure and predictability to the offshore software development processes. Moreover standards should be seen as a means of simplification and abstraction which are “formal-informal, explicit-tacit, external-internal” and emerge incrementally as domains are interconnected across time, space and cultures (Sahay et al., 2003, p. 85). Keane (2003) notes that the best outsourcers rank quite high on the CMM scale of maturity, and organisations at the lower end of the CMM need years of effort and massive cultural change to achieve the level of process maturity present in a best-in-class outsourcer. 57 Ramasabbu et al. (2008) identify India to have the largest pool of world wide software organisations certified with CMM level 5 assessments. However, once a common quality model is established, maintaining it is a challenging task requiring commitment from the organisation and a proper work culture. Th ese processes are document heavy, with key practices being standardised, measured, tested, and controlled to increase the productivity of software development. Critics argue that under formalised processes used by CMM, developers lose much of their traditional autonomy (Adler et al., 2005); thus causing developers’ motivation to suffer. They suggest that such disciplined processes may have negative consequences on both human and economic scales (Conradi & Fugggetta, 2002). Thus critics advice use of agile development approaches (Agerfalk & Fitzgerald, 2006), rather than structured processes advocated by CMM, which promise process improvements without bureaucracy. However, Ramasabbu et al. (2008, p. 451) are of the view th at “adoption of structured process models have both a direct and a learning-mediated effect in mitigating the negative effect of work dispersion” on productivity and quality in the OSD context. 2.6.10 Types of contract Organisations do not foresee all future contingencies at the initiation of off-shoring. Thus contracts represent risks and opportunities for both parties, and are an important driver for consideration of practices adopted for software development (Gopal, Sivaramakrishnana, & Krishnan, 2003; Lacity & Hirscheim, 1994). Offshore contracts are typically of two type s – fixed price (FP) contracts and time and material (T&M) contracts – with differing risk implications for offshore clients and vendors (Banerjee & Duflo, 2000; Gopal & Sivaramakrishnana, 2008; Gopal et al., 2003). FP contracts include a fixed fee for the software negotiated before the start of the project, and the vendor bears the major part of the risk. In a T&M contract, the vendor contracts out services at a certain rate and the client is responsible for monitoring the progress on the project, and thus the client bears the cost of over-runs. 58 Vendors often assign more trained personnel to FP contracts (Rottman & Lacity, 2004) and also are less likely to accept requirement changes from clients because they usually increase vendor costs (Kalnins & Mayer, 2004). More over, vendors might try to minimise project costs by allocating less expensive resources and/or ensuring efficient utilisation of resources. On the other hand, T&M contracts offer incentives to increase effort (or duration) and/or allocate more resources to the project leading to over-engineering (Kalnins & Mayer, 2004). Also under T&M contracts, clients exercise a greater level of monitoring and control (Ethiraj et al., 2005; Kirsch et al., 2002) and such contracts may offer less profitability potential to vendors as they also cover client’s risk protection. This could result in vendor preference for FP contracts for some projects, especially as these vendors mature from low-risk projects to high-risk development. Thus vendors may prefer mixed or hybrid contracts, such as incentive-based contracts including aspects of both FP and T&M contracts, depending on the type of the project, bargaining process, risk protection and perceived capabilities (Gopal & Sivaramakrishnana, 2008). Moreover, subsequent projects with the same client provide both the client and the vendor with a more accurate idea of each other’s abilities, resulting in increased trust and assurance of each others business obligations. And, as trust is built, both client and vendor view risks associated with contracts differently; however Kaiser et al. (2004) warn of the need for avoiding a “binding relationship” between vendor and client, as situations could change in the future. Finally, other factors such as cultural differe nces between client and vendor organisations also influence the type of contract signed by both of the parties in the offshore outsourcing domain (Gopal & Sivaramakrishnana, 2008). 2.7 Knowledge management This section elaborates on the theoretical foundations of knowledge management (KM) to illustrate how this field has been raised into a distinct and practical body of management theory. It explains the concepts identified in literature pertaining to the field of knowledge management such as tacit and explicit knowledge, knowledge creation, knowledge 59 codification, knowledge transfer, knowledge assets, knowledge repositories and boundary roles. KM has been amalgamated from a cluster of theories from existing research fields of strategic management, organisational culture, artificial intelligence, quality management and organisational performance management amongst many others. However since knowledge is innately human, organisational culture theories have dominated the knowledge-based concepts (Baskerville & Dulipovici, 2006). In this context of individual (personal) and collective (shared) work processes within organisations, KM processes have resulted from two dimensions of knowledge, namely tacit and explicit knowledge. The two dimensions of knowledge have previously been explained and described as: 1. Tacit knowledge is “highly personalised and rooted in individual’s actions and experiences, as well as in the ideals, va lues, or emotions he or she embraces” (Nonaka & Takeuchi, 1995, p. 8). Subjective insights, intuitions and hunches form tacit knowledge. Most of the operational knowledge in organisations exists at the tacit level, embedded in personal skill or organisational routines by actors who execute them without “conscious awareness” (Nelson & Winter 1982, p. 125 as cited in Choo 2006). 2. Explicit knowledge is “knowledge that can be expressed in words and numbers, and easily communicated and shared in the form of hard data, scientific formula, codified procedures, or universal principles” (Nonaka & Takeuchi, 1995, p. 8). Explicit knowledge is “rule based when the knowledge is codified into rules, instructions, specifications, standards, methodologies, classification systems, formulas, and so on” (Choo 2006, p. 141) Nonaka and Takeuchi (1995) have provided some further distinctions between tacit and explicit knowledge as shown in Table 13. 60 Table 13 Tacit and explicit knowledge Tacit knowledge (subjective) Explicit knowledge (objective) Knowledge of experience (body) Simultaneous knowledge (here and now) Analog knowledge (practice) Knowledge of rationality (mind) Sequential knowledge (there and then) Digital knowledge (theory) Source: Nonaka and Takeuchi 1995, p. 61 The process of knowledge creation occurs in organisations when (1) tacit knowledge is converted into explicit knowledge and (2) knowledge is moved from individual level to the group, organisational and inter-organisational levels (Choo, 2006). Nonaka and Takeuchi state that interaction of both the above processes at different ontological levels further creates new knowledge. Knowledge creation is essentially a social process – “a complex set of dynamic skills, know-how, etc. that is constantly changing” (Mason & Pauleen, 2003, p. 39) as organisations reflexively monitor their processes and create new knowledge. Next, the collective knowledge is put in a form that is accessible to those who need it (Davenport & Prusak, 1998) leading to knowledge codification. The newly discovered codified knowledge is articulated into artefacts, such as knowledge maps or as narratives in document management systems. These artefacts are stored in libraries and databases so that they can be absorbed by others in the organisation (Baskerville & Dulipovici, 2006). Organisations need to foster an environment for individual and organisational learning so that the codified knowledge artefacts stored in databases are reused through shared work practices, or by expertise seeking novices and secondary knowledge miners (Markus, 2001). This enables knowledge transfer as individuals reuse the available expertise through dialogue and one-to-one conversations (Hansen, Nohria & Tierney 1999). However, knowledge transfer is also related to an organisation’s absorptive capacity (or its lack of) (Alavi & Leidner, 2001). The absorptive capacity is defined as the “ability to identify, assimilate and exploit knowledge” (Venkatraman & Tanriverdi, 2004, p.56) and its absence can convert the knowledge to be transferred into ‘sticky knowledge’. Thus complexity of knowledge sharing can be traced to attributes of knowledge; its fragmentation, situatedness, contextuality and “stickiness” (i.e. how tacit knowledge is held in the minds of individuals) (Leornardi & Bailey, 2008; Tiwana, 2003). To overcome the 61 issues associated with complex knowledge sharing, organisations are using tools that support human expression, including Knowledge Based Systems (KBS) to capture rule bases and workflow tools to capture tacit pr ocess policies (Baskerville & Dulipovici, 2006). The evolving inputs and outputs of knowledge activities are the knowledge assets which form the knowledge capital of the organisation (Baird & Henderson, 2001). These knowledge assets are “firm-specific resources that are indispensable to create values for the firm” (Nonaka, Toyama & Konno, 2000, p. 20). The knowledge assets further evolve as skills and knowledge are upgraded to build the knowledge capital leading to concepts of knowledge economy and knowledge strategy (Nonaka, et al. 2000; Teece, 2000). Organisations need to preserve their corporate knowledge assets and be resilient to employee turnover, so that there is minimal or limited organisational knowledge loss when employees leave the organisation. Accordingly organisations do not treat individuals as repositories; rather they store their knowledge assets into knowledge clusters or collective knowledge repositories so that work processes are not disrupted with employee turnover. Some organisations designate knowledge suppo rt officers who assist busy employees in creating, editing and translating knowledge assets (Rao, 2008). The knowledge repositories evolve with upgrades of knowledge assets and best practices are defined and added to the organisational knowledge. Moreover the document authoring and management technologies used within repositories further facilitate knowledge sharing as the embedded tools have context-based knowledge retrieval mechanism that retrieve knowledge according to the location of concepts within the document (Woukeu, Carr & Hall, 2004) The system can then automatically generate useful content and deliver it to others, thereby reducing the need to sift through documents for searching and matching (Olivera, Goodman & Tan, 2008). However, when organisations specialise in certain knowledge activities, they evolve “local norms, languages and conceptual frameworks” (Choo, 2006, p. 184). Though specialisation increases the efficiency of internal information processing; but these activities are not easily understood by the external environment. Accordingly, organisations need to recode the information messages at their boundaries to enable knowledge transfer outside their boundaries, and this process is termed as “information boundary spanning”. (Tushman and 62 Scanlan 1981, cited in Choo, 2006). These boundary roles are performed by certain individuals or “technological gatekeeper s” who understand the coding schemes on both sides of the organisational periphery (Allen, 1997 cited in Choo, 2006). These individuals help to develop effective boundary crossing behaviours and reduce misinterpretations of messages caused due to cultural programming of team members (Pauleen & Young, 2001). In order to develop a knowledge-based view of how vendor organisations manage their knowledge strategies and operate in cross cultural environments, this study uses the SECI model as the theoretical foundation to interpret vendors’ practices for knowledge sharing. The next section elaborates on the role of knowledge management in the OSD environment before discussing the SECI model to set the knowledge creation and knowledge transfer strategies in context of this study. 2.8 Knowledge management in offshore software development The previous section has explained the importance of knowledge management which involves ongoing interaction of tacit and explicit knowledge assets to build the knowledge capital of the organisation. Global software development is a “knowledge-intensive activity that involves a large body of knowledge ( know what) with a strong emphasis on practice ( know how)” (Sahay et al., 2003, p. 134). These kn owledge-intensive activities for offshore software development involve continuous interaction between team members situated at distributed sites to identify new process initiatives for coding standards, peer design reviews, change management strategies, quality indicators and other organisational routines, as individuals develop common language, understanding and interests with shared experiences (Slaughter & Kirsch, 2006). The knowledge capital of the software system builds with the progression of development work, and requires an ongoing awareness by the team members of all of the changing definitions and relationships in the development effort. In a distributed environment such as OSD, domain skills relating to technologies, specifications, processes, methodologies, skills , objectives and management systems are spread across virtual teams. All these skills have an informational component consisting of two parts: the explicit knowledge that can be laid out formally and the tacit knowledge regarding customer, design and programming choices and working practices that cannot 63 (Heeks et al., 2001). Proper knowledge interfacing mechanisms need to be in place to ensure that software teams can apply different forms of tacit and explicit knowledge across distributed locations. These interfacing mechanisms allow the local knowledge to be transmitted to offshore client and vendor domains, where it is easily understood and integrated into the offshore knowledge domain by team members, who may have never met each other face to face. The knowledge interfacing mechanisms (or boundary spanning) can be performed by individuals (having boundary roles) or be enabled by ICTs (document management systems and relational database tools) (Alavi & Tiwana, 2002). Leornardi and Bailey (2008) define another aspect of knowledge called implicit knowledge, which lies between explicit and tacit knowledge. The work done by software developers tends towards tacit and implicit knowledge, and requires interpretation by knowledgeable users. However individuals who receive the work offshore may lack the necessary occupational knowledge and judgement to interpret the implicit knowledge embedded in technology artefacts. Thus, knowledge cannot be simply “transferred” to team members at distributed locations as a comprehensive document in the portal; rather the client or offshore team may often have to “translate or transform” the knowledge, as “expertise imbalance” is a strong contributor to problems in knowledge transfer (Leornardi & Bailey, 2008, pp. 430-32). Kanawattanachai et al. (2007) state that to share knowledge across distributed teams, members need to recognise knowledge specialisation among the team members, have beliefs about the other members abilities and responsibilities, and then develop effective representations of how interrelated tasks can be divided and assigned. Some frameworks related to the management of software development process for offshore outsourcing have been developed in previous research studies (Gopal, Mukhopadhyay et al., 2002; Heeks et al., 2001; Mol, 2007; Smith, Mitra, & Narasimhan, 1996). However, once a common model is established, conforming to it is a challenging task requiring commitment from the organisation and a proper teamwork culture. The challenges take on a different form and level of complexity when looked at within the context of the temporal and spatial conditions of separation that are inherent in offshore software development processes, as team members slip in and out of different technical, social and cultural experiences (Sahay 64 et al., 2003). Technology can help to develop “KM-centric behaviour into workflows directly into the development activities” (Rao, 2008, p. 267) in a globally interconnected environment. However, it is the relationship at the operational level, rather than at the executive level, that determines how technology will support the knowledge integration mechanisms across organisational boundaries (Gold, 2005). 2.9 SECI model Nonaka and Takeuchi (1995) assert that organisations need to develop the capacity to continuously create new knowledge to remain in the knowledge industry marketplace. Knowledge creation is achieved through managing the relationship between tacit and explicit knowledge, and through designing social processes that generate new knowledge by converting tacit knowledge into explicit knowledge and vice versa. According to Nonaka and Takeuchi (1995), organisational knowledge is created through the interaction and conversion between tacit and explicit knowledge through processes of socialisation, externalisation, internalisation and conversion. They posit that the creation and transfer of organisational knowledge o ccurs through processes of conversion and assimilation through spirals moving from socialisation (tacit to tacit), via externalisation (tacit to explicit) and combination (explicit to explicit), to internalisation (explicit to tacit). The knowledge spiral emerges with the continuous and dynamic interaction of tacit and explicit knowledge as individual experiences are first articulated, then moved into concepts that are later combined with existing information. Finally the result is new knowledge as team members start ‘learning by doing’ (Nonaka & Takeuchi, 1995, p. 71). Later Nonaka et al. (2001, p. 499) extended the knowledge spiral to a concept called “ba” – roughly meaning “place” – which includes “a context in which knowledge is shared, created and utilised, in recognition of the fact that knowledge needs a context in order to exist”. These concepts of “ba” are then converted into knowledge assets, which are specific to that organisation where they are later transformed into core capabilities. Figure 4 describes Nonaka and Takeuchi’s SECI model for knowledge creation through dialogue, linking, learning and building processes, as tacit and explicit knowledge interact dynamically. 65 Figure 4 SECI model Socialisation sympathising Externalisation articulating Internalisation embodying Combination connecting Source: Nonaka and Takeuchi 1995 The SECI model is widely accepted in academic literature for knowledge creation, application and extension (Baskerville & Dulipovici, 2006; Choo, 2006) and has been used in diverse management studies for assessing knowledge strategies (Joia, 2002; Rice & Rice, 2005; Sumita, Shimazaki, & Matsuyama, 2009). However critics of SECI argue that it is not supported by wide empirical evidence as SE CI was initially derived from purposeful managerial surveys as opposed to surveys being conducted on a broader population across other levels of management and hence some of the knowledge conversion modes are not very coherent (Gourlay, 2003, 2006). Becerra- Fernandez and Sabherwal (2001) have identified that each of the four SECI modes depends on the presence of appropriate task characteristics for contextualisation of related information. This research study addresses these concerns by utilising purposeful sampling methods of knowledge based professionals in software development belonging to middle and higher management groupings. Moreover the task characteristics of software development activities are confined by the organisational preferences on software development methodologies, tools, metrics and associated structures. Thus, the adoption of SECI model for evaluating knowledge processes in OSD is not limited by the critics’ observations for this study, although it has not previously been applied in the OSD context. This study has also utilised structuration theory as a second theory to understand the link between agents (individuals), agency (collective identity) and emerging social structures Learning by Doing Dialogue Field Building by Doing Linking Explicit Knowledge Tacit Tacit Tacit Explicit Explicit Explicit Explicit Tacit 66 (assimilation and conversion practices) in the knowledge creation and sharing process. The next section elaborates on structuration theory. 2.10 Structuration theory Structuration theory (ST) has been widely used in IS research to understand the relationship between social structures and human agency. Giddens (1984, p. 25) defines social structure as “rules and resources, organised as properties of social systems”, while human agency refers to human agents (individuals and groups) living in that society. ST states that structure and agency share a dual relationship, where social structure is not independent of agency, nor is agency independent of structure. Human agents continuously reflect on their practices and, with time, their actions influen ce social structures, while at the same time social structures also influence individual practices. Hence both individual and collective values feed into each other as social sciences is “irretrievably hermeneutic” (Giddens, 1984, p. 345), that is, reliant on interpretation and social settings (Jones & Karsten, 2008). Thus ST does not take a static view of social structure as individuals are capable of transforming structures with everyday social practices. ST states: We should see social life, not just as society out there or just the product of the individual here, but as a series of ongoing activities and practices that people carry on, which at the same time reproduce larger institutions……Society only has form, and that form only has effects on people, in so far as structure is produced and reproduced in what people do (Giddens & Pierson, 1998, pp.76- 7). For analytical purposes, Giddens identifies three dimensions of social structure, that is, signification, domination and legitimation which interact with human agency. Structures of signification communicate and inform groups based upon their interpretations, structures of domination convey information on power, and structures of legitimation help to define social norms and behaviours. Moreover, the structures and their meanings may be transformed over time as agents identify new modalities to challenge existing information, powers and norms to signify new behaviours and patterns (Jones & Karsten, 2008). 67 Following on with these three structures, this study defines meanings related to the three structures for individual actors who are “members of globalised and high-tech organisations”, and who “interpret creativity as a key resource for their membership” Sahay et al (2003, p. 91). The meanings are: 1. Signification – Informs of the person’s role i.e. membership signifies that the person is a knowledge worker. 2. Domination – Convey messages of the power the person holds i.e. members interpret creativity as a key resource for the membership, and based upon the member’s expertise, the member holds a position of some power and authority. 3. Legitimation – Define permitted standards or structural constraints, transgression of which may invoke sanctions i.e. members draw upon these resources to create new rules or reinforcing existing rules, such as members identify informal dress codes and prefer to work late at night. Thus by situating individuals in different social systems of which they are members, the individuals acknowledge the structural constraint s that come as a result. Figure 5 shows the link of structures to meanings through modalities of interpretive schemes, facilities and norms, set by individuals. 68 Figure 5 Dimensions of the duality of structure Source: Jones & Karsten 2008, p. 30 ST has been used in the study of knowledge pr actice and cross cultural literature of globally distributed work in contemporary society (Jones & Karsten, 2008; Orilikowski, 2002; Sahay et al., 2003; Walsham, 2002). Previous research has built upon ST in globally distributed work to take into account the interaction between people (agents) of different organisations and countries, each reflecting di fferent sociological structures. In such distributed settings, agents work with other agents at multiple locations, and thus glocal (i.e. global and local) structures and societal attit udes define new interpretations of rules and resources. Eventually the attitudes are affected by variations in glocal structures and, over time, the glocal structures themselves may be reciprocally affected. Thus the effect of glocalisation on organisational structures is “m utual and bi-directional” (Sahay et al., 2003, p. 172), and structurational analysis enables a more sophisticated and detailed consideration of issues related to global diversity in cross-cultural studies (Walsham, 2002). 2.11 Implications of OSD drivers to this research study The drivers defined earlier in this study (refer section 2.6) have helped to identify the scope of this research and form the theoretical foundation to understand the vendor’s knowledge processes in the offshore software development environment. The knowledge processes Signification Domination Legitimation Structure Interpretive Schemes Facility Norm (Modality) Communication Power Sanction Interaction 69 deal with operational practices associated with OSD for managing relationships, cross- cultural communication, control and co-ordination of project activities, gathering and defining client project’s scope, establishing a collaborative culture among distributed team members and improving overall productivity and quality of project releases across spatial and temporal spaces. This study explores the ve ndors’ work practices in the context of the identified process drivers for successful knowledge integration across geographical boundaries. The SECI model and ST have supported the analysis of empirical data collected across the New Zealand and Indian vendor context. Table 14 encompasses the domain of academic research addressing the phenomenon of offshore software development to formulate the conceptualisation of key success drivers for this research study. The table lays the theoretical framework for the study as it (1) clearly delineates the domain (2) provides a foundation for describing and organising empirical evidence about the domain and (3) hi ghlights application of theory within the research domain (Dibbern et al. 2004). 70 Table 14 Theoretical framework Key driver This study Culture Culture is viewed in structurational terms to understand various social systems of which agents are members as well as to understand the rules they apply in the process of articulating agency. The study looks at offshore vendor groups to understand how they shape their actions in the VSS, as multi-social cue codes are learnt and practiced across diverse social settings of different cultural groups. Communication The study explores the communication processes, technologies and collaborative groupware solutions used by the team members to share knowledge across geographical boundaries. The study examines individual team perceptions and preferences for effective communication styles in distributed team environments. Relationship building and trust Virtual spaces are characterised by cultural divides, diverse structures and working styles, language variations, non-local views and foreign work hour regulations. The study examines how client-vendor relationships are conducted across the emerging spaces to build trust across dissimilarities. Control and coordination Multiple contextual factors and tightly-coupled work designs are characteristic of globally distributed software development work. This study examines how information is exchanged and tasks are coordinated across dispersed sites, and how team members confirm and control the knowledge related to the shared design model (such as software architectural design) as development work proceeds in different time zones. Requirements management Understanding client specific requirements is a major driver for project success. This study examines vendor management strategies to elicit client requirements. It explores when and how vendors gather tacit and explicit specifications of the client’s application domain across diverse knowledge domains. Project management The relevant knowledge is fragm ented amongst various project stakeholders, which makes its embodiment or stickiness in the design of the software a challenge. Project management is important for integration of knowledge tasks into the end- deliverable. This study explores the project management processes vendors use to reduce the complexities, anxieties and insecurities that are inherent in distributed software development environments. Staff attrition management High personnel turnover is a major issue in knowledge teams, and organisations need to define measures to retain talent. This study will explore the vendor’s current attrition status and examine their hiring and retaining practices. Quality management The quality of the deliverable software component depends on the maturity of processes that are used in its development. This study explores the formalisation and discipline of knowledge processes maintained across distributed sites. Moreover, the relevance of international quality certifications to improve quality and productivity is studied from the vendor’s perspective . Types of contracts This research study broadly explor es the types of contracts offered to vendors. Since the contractual details are not shared openly with the software development teams, the information needs to be collected from senior management. The contract choice depends upon the relative bargaining power of the client and vendor, their risk protection and profitability strategies, and hence such information may not be offered in full detail by the vendor. 71 2.12 Conclusion Chapter two has explored and synthesised the available literature on IS outsourcing. It has highlighted the various outsourcing concepts used in the academic literature such as organisational arrangements, categories of vendors, outsourcing stages and life cycle models available. Next it described IS outsourcing in the context of offshore software development, and reviewed the established theoretical models such as SECI (Nonaka & Takeuchi, 1995) and ST (Giddens, 1990). Finally this chapter identified the key drivers for knowledge transfer in the virtual environment of distributed software development work, and explained how these drivers will be used in this research study by defining a theoretical framework. A criticism often made of IS research concer ns “relevance” or rather the lack of it in research studies. IS researchers and IS pr actitioners form independent communities, with little overlap or knowledge transfer between them. The research community needs to address the issues that are confronting organisations, ensure that research results are disseminated and provide leadership to organisations on the effective management and utilisation of information technologies (Moody, 2000; Rosemann & Vessey, 2008). Mol (2007, p. 168) adds that there is a “dearth of research on the outsourcing processes”, as most extant literature focuses on less messy aspects of outsourcing such as outsourcing levels and outsourcing designs. He adds “A better understanding of outsourcing processes increases the practical relevance of academic research because practitioners spend much more of their time managing outsourcing processes, in the form of projects, than they do analysing outsourcing levels”. This study focuses on the outsourcing process to understand theoretically and empirically how vendors manage knowledge based processes across diverse cultural domains. The theoretical framework identified in this chapter has provided the guidelines for establishing key issues associated with the drivers in the OSD process. The framework has been further investigated with a pilot study in Chapter four before launching the main study. The pilot case study findings have helped to bring more focus on the practitioner’s perspectives and have led to identification of a conceptual framework which is informed by both theory and practice. 72 CHAPTER THREE – Research Methodology 3.1 Introduction The previous chapter has discussed the need for both theoretical and empirical justification in the evaluation process. It therefore follows that the research method used must “preserve a considerable degree of openness to the field data, and a willingness to modify initial assumptions and theories” (Walsham 1995, p. 76). But in order to be accepted as legitimate within a field of study, research methods must be both relevant and rigorous, and the theoretical lens used to frame the investigation also has an important influence on the choice of the research method (Trauth, 2001). Based on underlying research epistemology, positiv ist, interpretive and critical lenses can be used to study the phenomenon of interest (Myers, 1997; Orlikowski & Baroudi, 1991). Positivist research includes hypothesis testing, description, exploration and evaluation. The aims of interpretivist studies are exploration, description, analysis and interpretation without prior judgments. Critical studies are used to critique social situations as prior epistemological assumptions and preferences are made by the researcher (Cecez- Kecmanovic, 2001). Even though the three theoretical lenses refer to different research paradigms, Lee (1991, p.363) argues that interpretive findings can provide a basis for future positivist findings, and research approaches “are mutually supportive, not mutually exclusive”. Caldwell (1994, p. 244) confirms the decline of a fixation on one philosophy and calls for “methodological pluralism” as “the positivist fixation on the objective side of science missed half of a beautiful and complex tale” which can only be met in the present “post-positivist environment”. Thus mixed approaches coined by researchers as logical positivism, post- positivism, logical empiricism or realism ha ve evolved as methodologists affirmed the importance of subjectivity in the phenomological society (Miles & Huberman, 2000; Schwandt, 2001; Yin, 1994). Patton (2002, pp. 94-5) uses the term “reality-oriented qualitative inquiry” instead of post-positivism to assert that qualitative inquiry is inherently phenomenological, and the human world is different from the physical world and therefore must be studied differently (Guba & Lincoln, 1990). 73 The field of information systems (IS) is “not just a science but also a profession” (Lee & Baskerville, 2003, p. 221). Orlikowski and Baroudi (1991) encourage researchers to have awareness and understanding of the diversity of philosophical assumptions underlying IS research; so that the voices of the scholar and the practitioner filter into each other, rather than adopting a stance that renders the voices to appear disparate. Recent research on practitioner perspectives indicate that structuration theory (ST) is “one of the most influential…theoretical paradigms influencing IS research in the last decade or more”, and is the “theoretical lens of choice for most scholars” (Poole & DeSanctis, 2004, p. 207). However, ST should be used as a second theory to support the chosen research approach rather than as a unique theory in its own right to gain understanding of a social phenomenon (Gregson, 1989). Also, ST does not advocate a singular “methodological scapel”, however it rejects the use of positivism without an interpretive stance as a means of inquiry for social research, as social situations do not rest on uni versal laws of positivism, but are reliant on interpretation (Giddens, 1984; Jones & Karsten, 2008, p. 131). The form of knowledge generated in the resear ch implies different distinctions to the application of research methods, such as nomothetic and ideographic. Nomothetic is concerned with the discovery of general laws, and implies that the particular research examples are selected to be representative of a wider population (Morrow & Brown, 1994). Ideographic research, on the other hand, is associated with understanding the particular situation or process being researched in depth (Tsoukas, 1989). Nomothetic research is generally associated with positivism, and with research methods that produce statistically generalisable data, while ideographic research is associated with interpretivism and some forms of case study research (Mingers, 2003). A case study research strategy is well suited to capture the knowledge of practitioners, document the experiences of practice and to develop theories from practice (Benbasat, Goldstein, & Mead, 2002). In case study research, field data are gathered in organisational settings to learn about the phenomenon under investigation, and are highly contextualised and based on observational evidence. 74 The aim of this study is to explore the real life processes of knowledge transfer within the contemporary phenomenon of offshore software development (OSD) environments under different cultural settings (New Zealand and India). It further aims to interpret how these processes have influenced the vendors’ or practitioners’ knowledge management capabilities as past organisational experiences are revealed. This research has no control over the phenomenon under study; interpretations are made based on the context of practitioner’s experiences, as individual voices of practitioners are heard. This chapter demonstrates that a multiple case study research design with ideographic methods is most appropriate to explore the chosen research problem. The philosophical stance undertaken during conduct of the study is explained. Quality checks used for establishing a reliable case study protocol are described. Then multi-method approaches used for data collection are explained. Next the chapter describes the data management and analysis strategy used for the study. The chosen format of the case study report is justified, and finally the methodological model of the study is presented. 3.2 Research questions The emphasis of the research is on the relationships between social factors and the application and management of technology-related practices in the offshoring of knowledge-intensive software development ac tivities. As offshore outsourcing becomes widespread, understanding the impact of these practices on the effectiveness of the software development effort will become increasingly important (Edwards & Sridhar, 2003). This research explores the key influences on building and sharing knowledge across distributed software development sites to answer the following question within the offshore software development domain: How do vendor organisations use knowledge sharing processes in the software development environment within a glocal society? This question is influenced by the following subsidiary questions: 75 1. What processes do vendor organisations consider important for transfer of tacit knowledge in the offshore software development environment? 2. How do vendors manage distributed knowledge-based processes within the software development environment? 3. How does culture affect vendors’ relationship building strategies with offshore clients or partners in the virtual environment across organisations and nations? The research objective in answering these questions is to develop an understanding of knowledge management strategies during offsho re software development, building on the theoretical underpinning of previous research into both software development and virtual teams. 3.3 Researcher’s role Before entering a research project, the researcher needs to be self-reflective in terms “of identifying biases, ideology and stance” (Janesick, 2004, p. 106). Janesick suggests researchers undertake a pilot study to get an understanding of their role for the research setting. This is especially relevant in qualitative research where a variety of methods are used, including, but not limited to, observation, participant observation, interviews, document analysis and the researcher’s personal reflections. The researcher may then decide whether the stance is from inside or outside, as participant or observer (Janesick, 2004). Walsham (1995) identifies two roles for a researcher who undertakes interviewing: “outside observer” and the “involved observer”. The merit of being an outside observer is that the respondents are more likely to trust the researcher, as they do not feel threatened by the interpretations or outcomes of the research. However, the demerit of being an outsider is that the researcher has limited access to reports and confidential information that may be too sensitive to share with someone outside of the organisation (Walsham, 1995). In this study, the researcher conducted a pilot study and adopted the position of outside observer. Moreover, the study was certified as low risk by the Massey University Human 76 Ethics Committee, and as such implied that access to confidential data was not required to conduct the study. During the interview process, interviewees spoke quite candidly about their work processes and shared their routine work documents freely. The developers were often interviewed at their work stations, and they showed the technologies used for collaborating across distributed sites on their desktop computers. Some work-in-progress documents of current projects were also shared with the researcher to explain how work flows in the OSD environment. Sensitivity to the research act has thus been maintained in the study by use of multiple methods to help interpret the data correctly. 3.4 Rationale for mixed research approach The phenomenon under study explores the inte raction of technological and behavioural elements, as a variety of social, cultural and technological experiences come into play in the phases of software design and development in the OSD environment. Software work, when carried out in a global setting, magnifies these complexities as it involves relationships of people, teams, organisations and nations with different backgrounds, spoken languages and style of working in conditions of temporal and spatial separation (Sahay et al., 2003, p. 9). It is appropriate this research employs qua litative research methods because it will take place within the practitioners’ organisational sett ings to reveal the “socially constructed reality” of groups (Denzin & Lincoln, 2003, p. 13) in which diverse cultural and social contexts are merged. The virtual environment cr eates the flow of everyday social practices as practitioners (agents) identify actions to be taken within a certain societal context, and these actions are continuously reflected upon under changing social contexts (Giddens, 1990). “Research methods shape the languages we use to describe the world and language shapes how we think about the world” (Benbasat & Weber, 1996, p. 392). The study used multiple interactive methods to interpret the language used in participants’ stories with reference to the existing literature to help build theory as stories emerged and evolved (Marshall & Rossman, 1999). Sahay et al (2003, p. 36) suggest the use of research methods which 77 emphasise the epistemology of practice in distributed software development processes due to the subjective nature of the social, organisational and individual nature of processes adopted, requiring a “shared understanding of each other’s products, processes and work practices” across geographical boundaries. After an initial review of the literature, it was af firmed that the research approach would be exploratory, given that offshore vendors need to be flexible to adjust their working practices and habits to meet the client’s needs. Patton (2002, p.52, p. 55) states that “qualitative inquiry is particularly oriented towards exploration, discovery, and inductive logic” as such naturalistic inquiry gives “the researcher an empirical basis for describing the perspectives of others”. The offshore vendors’ and practitioners’ experiences gave context to the findings and helped to shape understanding of the OSD experiences in the virtual environment. Thus to identify meanings to knowledge strategies used in different sociological, cultural and technical settings in the OSD phenomenon, this study utilises “methodological pluralism” or a mixed approach by adopting a logical positivist lens to measure practical knowledge against theoretical knowledge. The reality of practical knowledge is understood by use of case studies in which vendor’s ‘real-life’ experiences are analysed in context of the identified theoretical framework (refer Table 14) by use of multiple interactive methods. The case study method is discussed in the next section. 3.5 Rationale for case study method The case study method has been adopted for this research. The rationale for this method arises from the exploratory nature of the research. Case study research is useful when a phenomenon is broad and complex, when a holistic, in-depth investigation is needed, and when a phenomenon cannot be studied outside the context in which it occurs (Benbasat, Goldstein, & Mead, 1987; Yin, 2003). Stake (2003, p. 88) describes a case study as “both a process of inquiry about the case and the product of that inquiry”. Yin (2003, p. 9) explains that case study research is appropriate for answering “ how and why questions being asked about a contemporary set of events, over which the investigator has little or no control”. Gubrium and Holstein (2003, p. 229) add that how and what questions are interconnected to 78 reality construction, as “asking how questions without having any integral way of getting an analytic handle on what questions makes concerns with the whats arbitrary”. The research questions for this study are a combination of what and how questions about the OSD process from the vendor’s perspective. The main purposes of this research are to discover what the key influences in OSD processes are and how they influence the software vendors’ knowledge management effort. According to Yin (2003, p. 7), when the research question focuses on what type questions in an exploratory manner, any strategy, including the case study strategy may be used. Moreover, when there is no control over the actual behavioural events, Yin recommends the use of any strategy other than the experimental strategy. Also, the focus of this research is on contemporary events, as offshore development has only recently emerged (DeLone et al., 2005) there is little research available for an historic study. Case study research can be conducted with any philosophical lens, be it positivist, interpretivist, or critical (Dube & Pare, 2003). Cavaye (1996, pp. 227-8) argues that: Case research can be carried out taking a positivist or an interpretive stance, can take a deductive or an inductive approach, can use qualitative and quantitative methods, can investigate one or multiple cases. Case research can be highly structured, positivist, deductive investiga tion of multiple cases; it can also be an unstructured, interpretive, inductive investigation of one case; lastly, it can be anything in between these two extremes in almost any combination. Walsham (1995), after reviewing well-known positivist case study researchers such as Yin, Benbasat, Goldstein and Mead argues that case studies can have both positivist and interpretivist stance. He suggests that Yin’s (1994) view on case studies being the preferred research strategy to answer how and why questions, and Benbasat et al.’s (1987) arguments that case study researchers need to be more explicit about their research goals and methods, are relevant to both positivist and interpretivist schools of research. The multiple case study method is the preferred research design for this study, which seeks to gain an understanding of work practices a nd attitudes within two or more organisational 79 cultural contexts. A multiple case study design provides the opportunity for cross-case comparisons and, according to Benbasat et al . (1987), this strengthens the experimental research findings. When a number of case studies are conducted, it is possible to identify the subtle similarities and differences within a group of cases and also within inter-group similarities and differences, as well as identif y any chance associations (Eisenhardt, 1989; Yin, 2003). Comparisons between cases help demonstrate the variability in context and therefore yield more general research than single cases (Benbasat et al, 1987; Yin 1994). Lee and Baskerville (2003) recognise generalisations can occur in four ways: from empirical statements compared to other empirical statements (EE), from empirical statements to theoretical statements (ET), from theoretical st atements to empirical statements (TE) and from theoretical statements to other theoretical statements (TT). This research compares theory with empirical data and also compares empirical data obtained across ten case studies in different business settings to form TE and EE abstractions which may then be applied to a broader context. 3.6 Relevance and rigour Both relevance and rigour are important in the conduct of any research study. Relevance refers to the need to take account of ‘real-life’ experiences while addressing a significant problem applicable to multiple audiences. Moreover the practice of outsourcing IT functions such a software application development is “a practitioner-driven phenomenon” (Dibbern et al, 2004, p. 14) which can only be studied empirically. Case studies report on real-life IT experiences, which are relevant to both academia and practice, as they inform us about the rapid changes occurring in the IT world as well as in organizations (Benbasat et al., 1987; Dube & Pare, 2003; Yin, 2003). Mol (2007, p, 169) states that “In future research, it would be useful to see more theoretical and empirical work on the outsourcing process”. He says that there is a ……dearth of research on the outsourcing process. Most extant literature focuses on outsourcing level or outsourcing design, a variable that is more 80 easily measured and can be explained in a less messy way than outsourcing process. Process, in general, has not received the attention it deserves in strategy research, so it has been argued. A better understanding of outsourcing processes increases the practical relevance of academic research because practitioners spend more time managing outsourcing processes, in the form of projects, than they do analysing outsourcing levels, although they do of course spend considerable time managing relations with outside suppliers after outsourcing processes have been rounded off (p. 168). This research study uses multiple case studies to provide a ‘real-life IT’ perspective of the offshore vendor organisation’s practices to manage their ‘outsourcing processes, in the form of projects’. It also focuses on how vendors are ‘managing relations with outside clients’. Accordingly, this study has relevance to the current IT outsourcing environment, and adds to the limited available literature on ‘outsourcing processes’. Academic rigour is maintained by an adherence to clearly defined research questions, with clearly defined concepts and using a research method that is appropriate to the questions and the context. However the instruments used to assess the quality of the research method vary with each philosophical tradition and it is important for researchers to provide some information on methodological aspects for the study to pass the tests of scientific rigour (Dube & Pare, 2003). Dube and Pare (2003) have recommended certain guidelines to establish rigour in positivist case study research. They advise researchers undertaking case study research to use their suggested recommendations to help them assess the methodology used in their research for rigour. They have identified three main areas to establish rigour. The first area, research design, refers to the attributes associated with the design of the study, such as the nature of the research questions, the theoretical foundations, as well as the criteria adopted for selecting the cases. The second area, data colle ction, is concerned with the overall quality of the data collection process. It considers the choice of data collection methods, and how they are applied along with the tactics for enhancing reliability and validity (e.g. data triangulation, use of case study protocol and database). Finally, the third area, data analysis, is concerned with the description of the processes as well as with the use of preliminary 81 techniques (e.g. field notes, coding of raw data, data displays), and dominant modes of data analysis (e.g. empirical testing, explanation building). This study has used the recommendations suggested by Dube and Pare to establish rigour in the case research. Tables 18, 21 and 22 described later in the chapter explain how rigour has been established for the three areas in this study. 3.7 Research design A research design is the logic that links the data to be collected to the initial questions of the study (Yin, 2003). Yin identifies five components in a research design, which can be divided into two phases of the research design plan. The first phase dictates what data are to be collected, and is indicated by (a) a study’s research questions, (b) its purpose, scope and propositions, if any, and (c) its units of analys is. The second phase specifies what needs to be done after the data have been collected and is indicated by (d) logically linking the data to the propositions and (e) the criteria for interpreting the findings. Figure 6 illustrates the five components of the research design and the corresponding thesis chapters where they are addressed. 82 Figure 6 Five components in research design Adapted from Yin 2003, p. 21-8 The first component (a) of research design was addressed through formation of clear research questions described in chapter one. The second component (b) has been addressed in Chapters two, three and four with the development of a coherent framework through a critical review of published literature and empirical findings from pilot studies. Moreover, since the study is exploratory, a pilot study also served as a guide for defining the scope and units of analysis in the third component (c). Th e pilot study helped in deliberate selection of cases for the main study and established guidelines for data collection. More detail of component (c) is provided in the next section “unit of analysis”. Data collection and data analysis have been done concurrently. The fourth component (d) addressed the data analysis techniques used, which is discussed in detail in this chapter, and also described in Chapters six, seven and eight. The fifth component (e) is concerned with the closure of analysis to report findings. It has also been described later in this chapter and also discussed in detail in Chapters nine and ten. (a) Identify the research questions (b) Identify purpose & scope of study (c) Define units of data analysis (d) Data analysis of data (10 case studies) Research design – Phase 2 How to analyse data and report findings? Research design – Phase 1 What data is to be collected? (e) Closure of analysis to report findings Identify theoretical concepts Fieldwork analysis (pilot studies) Chapter 1 Chapters 3, 6, 7 & 8 Chapters 3, 9 & 10 Chapters 3 & 4 Chapters 2, 3 & 4 Data collection Chapter 3 & 5 83 3.7.1 Unit of analysis In qualitative studies the unit of analysis refers to the level at which the information is gathered to answer the research question. Thus decisions about sample size and sampling strategy are linked primarily to the unit of analysis. In an exploratory case study, a clear definition of the unit of analysis helps define the boundaries of a theory, which in turn sets the limitations in applying the theory (Dube & Pare, 2003). Moreover, the unit of analysis can be quickly derived if there is clarity be tween the research questions and the identified conceptual framework (Miles & Huberman, 1994). Sometimes, however, new units of analysis emerge during fieldwork or from the analysis after data collection (Patton, 2002). Pratt and Loizos (1992, p. 26) suggest a “special pre-research exercise, a ‘pilot study’, to establish the best unit of analysis” for the phenomenon under study. A study may involve more than one unit of analysis, which may not be mutually exclusive. Patton (2002) advises researchers that for selection and making decisions about the appropriate unit of analysis, one must first decide what one wants to discuss at the end of the study (such as individuals, organisations, or groups who share a common culture). This study focuses on knowledge management strategies of vendor organisations in the offshore outsourcing environment, when vendors in one country service customers in another country. Yin (2003, p. 48) suggests a common research design using “embedded units of analysis” and Patton (2002) describes layered units of analysis, where individual case analysis is followed by a second layer through cross-case pattern analysis, and again along another higher layer. This research study uses three units of analysis in what is called an embedded case (refer Table 15). 84 Table 15 Levels of embedded units of analysis Level 1 National level (social and cross-cultural issues) Level 2 Organisational level (vendor’s knowledge strategies) M ac ro u ni t M es o un it M ic ro un it Level 3 Individual level drivers for knowledge sharing (e.g. transfer of tacit knowledge, management of explicit knowledge, relationship building strategies) The three units are: (1) the macro level which explores the group of organisations that share a common country culture; (2) the meso level which examines each vendor organisation as a whole and (3) the micro level which examines the individual work process drivers for knowledge transfer in vendor organisations. However, it should be noted that Dibbern et al. (2004) have called organisational level as macro level, but in this study the term ‘meso’ level is used for organisational level and the term ‘macro’ is used for national level. 3.7.2 Quality of research design Four tests are used to establish the quality of any empirical social research; these are: construct validity, internal validity, external validity and reliability (Yin, 2003). 3.7.2.1 Construct validity The main concern of construct validity is to establish correct operational measures for the concepts being studied (Yin, 2003). Yin recommends two tests of construct validity: (1) deliberate selection of study objects and relating them to the original objectives of the study and (2) demonstration that the selected study objects reflect the context of the problem. The strategies to achieve construct validity include multiple sources of evidence, getting feedback from informants, and establishing a chain of evidence (Dube & Pare, 2003; Miles & Huberman, 1994; Yin, 2003). The validity of interviews was obtained in four ways: (1) purposeful sampling of cases; (2) use of mul tiple methods, such as interviews, observation, field notes, document analysis, corporate websites, and viewing some physical design artefacts; (3) follow-up interviews after eight to ten months; and (4) feedback and sharing of findings with the study’s informants. 85 Establishing a chain of evidence enables the reader to trace the derivation of any evidence from initial research questions to the conclusions, and improves the reliability and validity of the study (Yin, 2003). In this study, a chain of evidence has been maintained by ensuring that a data collection protocol was followed and maintaining an updated case study database. The use of phenomenological analysis of the interview data helped to align empirical data with relevant contextual cate gories and establish links with the research questions to give the reader a more informed view. 3.7.2.2 Internal validity For case study research, the focus of internal validity is how correct inferences can be made from a phenomenon under study. The researcher makes these inferences based on interview and documentary evidence, rather than as a direct observer. Yin (2003, p. 36) suggests that researchers should question the meaning of the evidence gathered: “Is the inference correct? Have all the rival explanations and possi bilities been considered? Is the evidence convergent?”. Klien and Myers (1999) call for a researcher to be self-reflective and show sensitivity to possible biases in the narratives collected from the participants; and to be analytical of the multiple possible interpretations for the same stories or sequence of events. Yin (2003) suggests use of analytic tactics, such as pattern matching, explanation building, addressing rival explanations and using logic models to counter spurious inferences. Miles and Huberman (1994) further suggest that the verification process is ongoing and concurrent with data collection. In this study, internal validity is establis hed both during data collection and analysis. Interviews were conducted as open-ended conversations with prompts and rival arguments, to better understand the responses for “plausibility, sturdiness and validity” (Miles & Huberman, 1994, p. 24). Later, the cases were analysed for similar patterns of working practices, as categories were coded and refined iteratively. Further details of these processes are included in the data collection and analysis section of this chapter and in the report on the analysis strategy in Chapters five, six, seven, eight and nine. 86 3.7.2.3 External validity External validity is knowing whether a study’s findings are generalisable beyond the immediate case study (Yin, 2003). This may be established through the use of a multiple case study design (Creswell, 2008; Yin, 2003), though such a design undercuts the depth of understanding of individual sites (Schofield, 2002). A detailed description of the research context helps to assess the credibility of the research, to determine its generalisability (Dube & Pare, 2003; Yin, 1994), and to give an informed view about whether conclusions drawn from a particular site are useful in understanding other studies (Schofield, 2002). Patton (2002, p. 242) suggests selection of an appropriate sampling strategy “to fit the purpose of the study, the resources available, the questions being asked, and the constraints being faced” in selecting information-rich cases, to better understand the issues of central importance to the purpose of the inquiry for comparisons across sites. Section 3.7.3 in this chapter addresses the representativeness of information-rich cases for generalisation logic. 3.7.2.4 Reliability Reliability is concerned with the operations of the study, so that conducting the same data collection procedures on a particular case again should yield similar results (Yin, 2003). Patton (2002, p. 93) argues that if the research is being conducted “from a reality-oriented stance” then “realising the absolute objectivity of the pure positivist variety is impossible to attain” within a “phenomenologically messy and methodologically messy world”. He suggests triangulation of data sources and analytic perspectives to increase the accuracy and credibility of findings. Establishing an “audit trail” (p. 93) will also verify the rigour of the fieldwork and confirmability of the data collect ed to minimise bias, maximise accuracy and ensure impartial reporting. The case studies have been conducted in various dynamic organisational settings; hence it is not possible to replicate the exact data collection procedure. Therefore, in this study reliability is achieved through systematic operational steps such as (1) use of a case study protocol, (2) detailed record keeping of each case interview transcript, reflecting the linguistic expressions used during data collection, (3) the use of a conceptual model to 87 demonstrate the analysis strategies and (4) the development and maintenance of a case study database as an audit trail. 3.7.3 Selection of cases A multiple case study approach has been taken to provide a broad understanding of how practitioners manage their knowledge capabilities across distributed settings. There is no agreement in the literature as to the ideal number of cases in a multiple case study design (Patton, 2002). However, it is widely accepted th at the number of cases can be determined in a trade-off between the breadth and depth of the case study inquiry. In-depth information is required for a smaller number of cases while less depth is acceptable when the number of cases increases (Easton, 1995 cited in Dubois & Gadde, 2002). Eisenhardt (1989) recommends four to ten cases for a multiple case study. Because this research is largely exploratory, the aim is to build theory through examination of diverse sets of data and, accordingly, the number of cases selected for this research study is ten, of which five participant organisations are New Zealand software vendor organisations and the other five participants are Indian software vendors. Selection of cases needs to be specific and deliberate (Eisenhardt, 1989; Yin, 1994) so as to maximise what can be learned in the period of time available for the study (Dube & Pare, 2003). Yin (2003) proposes two criteria for selecti ng sites. First, sites where similar results are predicted may be used as literal replications. Second, sites may be chosen for theoretical replication. Moreover, when the research is highly exploratory, a pilot study may help researcher to determine the appropriate unit of analysis, to refine data collection instruments, and/or to become familiar with the instrument (Yin 2003). Accordingly, this study adopted a pilot study approach in its first year and three vendor organisations were selected for this pilot. Two of these organisations were New Zealand organisations and the third was an Indian organisation. In-depth interviews were conducted with these organisations. The pilot study data analysis provided some insights and helped to identify key influences for knowledge sharing across distributed sites for these vendor organisations. These findings were then discussed with government officials in NZTE and NASSCOM for identification of vendors engaged in similar practices in both countries. 88 This helped to determine ten different cases who agreed to participate in the main study. Thus the sampling for the main study was purposeful, as these cases were intentionally sought based on characteristics of the organisation: industry type, company size, offshore partnerships, geographic coverage, and so on (Patton, 2002). Patton (2002) categorises two random sampling strategies and fifteen purposeful sampling strategies, as shown in Table 16. Patton sugge sts using more than one qualitative sampling strategy as these approaches are not mutually exclusive, and serve multiple purposes in selecting information-rich cases. Thus the 16 th sampling strategy in Table 16 uses a combination of these sampling strategies. 89 Table 16 Sampling strategies Type Purpose Random Probability Sampling Representativeness: Sample size a function of population size and desired confidence level. 1. Simple random sample Permit generalisation from sample to the population it represents 2. Stratified random and cluster samples Increase confidence in making generalisations to particular subgroups Purposeful Sampling Representativeness: Select information-rich cases strategically and purposefully. 1. E xtreme or deviant case sampling Learning from unusual manifestations of the phenomenon of interest (for example outstanding successes, notable failures) 2. Intensity case sampling Information-rich cases that manifest the phenomenon intensely, but not extremely (for example above average, below average) 3. Maximum variation sampling Document unique or diverse variations that have emerged in adapting to different conditions. 4. Homogeneous sampling Focus; reduce variation; simplify analysis; facilitate group interviewing 5. Typical case sampling Illustrate or highlight what is typical, normal, average 6. Critical case sampling Permits logical generalisation and maximum application of information to other cases 7. Snowball or chain sampling Identify cases of interest from sampling people who know people who know what cases are information rich 8. Criterion sampling Picking all cases that meet some criterion 9. Theory-based sampling Finding manifestations of a theoretical construct of interest so as to elaborate and examine the construct and its variations 10. Confirming and disconfirming cases Elaborating and deepening initial analysis: seeking exceptions; testing variation 11. Stratified purposeful sampling Illustrate characterist ics of particular subgroups of interest; facilitate comparisons 12. Opportunistic or emergent sampling Following new leads during fieldwork; taking advantage of the unexpected; flexibility 13. Purposeful random sampling (small sample size) Add credibility when potential purposeful sample is larger than one can handle. Reduce bias within a purposeful sample 14. Sampling politically important cases Attract attention to the study (or avoid attracting undesired attention by purposeful eliminating from the sample politically sensitive cases) 15. Convenience sampling Do what’s easy to save time, money and effort. (poorest rationale; lowest credibility; yields information-poor cases) 16. Combination or mixed purposeful sampling Triangulation; flexibility; meet multiple interests and needs. Source: Patton, 2002, p. 243-4 90 The various sampling strategies described in Table 16 have different aims. However, in considering their descriptions, two clusters have been identified based on the sampling strategies used for case study selection during the pilot study and main study phases of this research. Table 17 illustrates the two clusters us ed in this study with the context of their sampling strategies. Table 17 Sampling clusters used in the research design Cluster Type of sampling Type of case study Ad hoc cases Random purposeful Intensity case Criterion Convenience Combination or mixed purposeful sampling Pilot study 3 pilot cases - 2 New Zealand case studies - 1 Indian case study Similar cases Intensity case Typical case Snowball sampling Criterion Theory-based sampling Confirming and disconfirming Stratified purposeful Combination or mixed purposeful sampling Main study 10 case studies - 5 New Zealand case studies - 5 Indian case studies Because this study started as an exploratory study, no prior assumptions were made for selection of the case studies for the pilot study. This resulted in a random purposeful or ad hoc case selection during the pilot study. Specifically, these cases were selected based on two primary criteria: industry type (i.e. software vendor) and having had some previous experience in offshore software development with clients in different countries. These cases were excellent examples of the phenomenon under interest, but were not highly unusual cases. Moreover, these cases were also selected on the basis of convenience. Patton (2002, p. 242) emphasises in bold font that “convenience sampling is neither purposeful nor strategic”. However, convenience sampling was used only in the initial exploration of the pilot study to identify the major aspects of the main study. This pilot study with ad hoc cases was used during the initial exploration process to identify relevant categories and define the units of analysis for the main study. The main study involved ten case studies, which were identified by well-informed officials who could speak with authority on outsourcing organisations within each country. These informed decisions were made based on information-rich cases, which met a certain 91 predetermined criterion, and which were considered typical within the demographic stratified sample size analysis. Two criteria we re defined for the vendor case studies: (1) the vendor should be involved in the business of software development and (2) the vendor should have been involved in some form of outsourcing arrangement (refer Table 3) with an offshore partner or client during the time of the interviews. Each case was evaluated for emerging patterns, as the exploratory processes gave way to confirming or disconfirming the cases. Confirmatory cases are cases that fit into the already emergent patterns, while disconfirming cases do not fit. The disconfirming cases allow rival interpretations and may be “exceptions that disconfirm and alter what appeared to be primary patterns” (Patton, 2002, p. 239). This study employs mixed purpo seful sampling techniques to accomplish in- depth inquiry of relevant and useful information, and strengthens triangulation. 3.7.4 Triangulation Triangulation is the process of “corroborati ng evidence from different individuals (e.g. a principal and a student), types of data (e.g. observational field notes and interviews), or methods of data collection (e.g. documents and observations) in descriptions and themes in qualitative research” (Creswell, 2008, p. 266). Triangulation strengthens a study by employing multiple methods to search for relevant and useful information. The logic of triangulation is based on the premise that “no single method ever adequately solves the problem of rival causal factors. Because each method reveals different aspects of empirical reality, multiple methods of observations must be employed” (Denzin, 1978, p. 28). However, Patton (2002, p. 252) warns researchers to do triangulation that is reasonable and practical, as it depends on budget, time constraints and political constraints (such as stakeholder values) in an evaluation. He suggests “methodological openness” in combining approaches creatively to design meaningful variations to qualitative inquiry into more sophisticated and multifunctional designs. He argues against methodological purity saying that a qualitative design should be sufficiently open and flexible to permit exploration of whatever the phenomenon under study offers for inquiry, even after data collection begins. 92 Yin (1994, p. 7) strongly suggests the use of a pilot protocol as a triangulation tool in exploratory studies to assure “that the exploration is following some exploratory theory” and the researcher is “not merely wandering through the exploratory phase”. However he warns of the pitfall of extending the pilot case screening to the final study, as that would not serve the purpose of theory replication logic. If the purpose of the study is theory generation and replication, the final study should include a different selection of case studies. By using a combination of observations, interviewing, recording and document analysis, the researcher can validate different data sources and cross-check information. Each type and source of data has strengths and weaknesses (Patton, 2002). Use of a combination of data types (triangulation), will increase validity as th e strengths of one approach can compensate for the weaknesses of another approach (Marshall & Rossman, 1999). In this study, triangulations of data, methods and informants have been applied. Multiple data sources and methods included follow-up interviews, observations, casual conversation during fieldwork, and examination of organisational documents and practice publications. Multiple sources of evidence focused on identifying main study informants by using the snowballing technique. More details on these techniques are provided in the data collection section (section 3.8). 3.7.5 A Priori specification of constructs A priori specification of tentative constructs identified from the literature helps to shape the initial design of the research. These constructs can then be explicitly measured in the case study protocol and questionnaires, thus permitting the researcher to measure constructs more accurately (Eisenhardt, 1989). Moreover, if the identified constructs converge with the constructs from the empirical study, they provide strong triangulated measures on which to ground the emergent theory; however, some of the constructs may also be discarded as random findings during the research process (Dube & Pare, 2003; Eisenhardt, 1989). Prior knowledge of essential constructs helps to build theory from case study research. Although Eisenhardt also warns researchers to be caref ul of bias due to preordained theoretical perspectives. 93 Based on the published literature, several constructs have been identified as important for knowledge transfer within the OSD environment (e.g. relationships, trust, contracts, communication, documentation, quality, certifications, meetings, collaboration tools). The details of these constructs are described in Chapter two (refer Table 8). An initial exploration of theoretical constructs was investigated during the pilot study across two distinct cultures. Some of the a priori constr ucts matched the empirical constructs and some did not match across certain cultures. Additionally, some new categories of constructs emerged and have helped in preparation of the interview protocol. 3.7.6 Context of the case study A detailed description of the research context is necessary to assess the credibility of the research results and to determine their generalisability (Benbasat et al., 1987; Schofield, 2002; Yin, 1994). The context relates to the research setting, period of time under investigation, whether there were one or more data collection periods, whether the researcher was able to gain sufficient access and spend enough time to develop an intimate understanding of the phenomenon of interest, and whether the data were collected during the course of events (on-going) or a posteriori (Dube & Pare, 2003). Two key points to gain cooperation from an organisation are confidentiality and benefits to the organisation. Confidentiality means providing assurance to the organisation that the researcher will not disclose the organisational identity. In return the researcher seeks assurance that reasonable candour will be provided and essential data will be made available. Benefits, to the organisations may include getting feedback and insights from the researcher and an opportunity to contribute to knowledge and business research (Benbasat et al., 2002). This study was conducted in five stages of data collection, commencing in March 2004. Prior to collecting data, the Human Ethics Committee of Massey University certified the study as low risk, and ethical approval to conduct the interviews was given in August 2004. The five stages are as follows: 94 Stage one: Three pilot study cases were identified in the first six months of the study. Two of the cases were New Zealand owned software vendor organisations, having offices in Auckland and Wellington. The third case was an Indian software vendor organisation who had an offshore office in Auckland with 20 developers. The researcher visited these organisations and conducted two to three in-depth interviews with senior management and developers from October 2004 to December 2004. Stage two: The study utilised snowballing tech niques to identify information-rich cases. Findings from the pilot study cases were shar ed with a senior government official in NASSCOM in November 2005 to help the researcher identify a sample of similar Indian case studies. Geographical location played a restrictive role, and so five sample cases were selected from Pune in India. Interviews with these cases lasted three months from December 2005 to February 2006. Stage three: Two New Zealand-based organisations were interviewed in August 2006 and September 2006. Again snowballing techniques we re used and findings from the pilot cases were discussed with senior officials from NZTE in October 2006. This resulted in identification of three more similar cases for the final study and these software vendors were interviewed in Auckland from October 2006 to November 2006. Stage four: Follow up interviews were conducted with the five Indian organisations from December 2006 to January 2007. One of these interviews was quite brief, while the others lasted two to four hours each. Stage five: Follow up interviews were conducted with the New Zealand organisations from July 2007 to October 2007. Of these five organisations, three were interviewed briefly, while the remaining two interviews lasted for approximately two hours. Most of the interviews in the ten organisations were tape-recorded, with the exception of a few where some of the participants did not want to be recorded. In these interviews, extensive notes were taken. Later, all of the interviews were transcribed by the researcher and supplemented by a case journal which consisted of notes made during the interviews. Some of the content of the interviews with the five Indian organisations had casual 95 conversation in the local dialect (Hindi and Marathi) which could only be transcribed by the researcher. Transcription also helped to maintain closeness to the data, which improved understanding of the identified constructs during follow up meetings. 3.7.7 Research design checklist This section describes a checklist of the steps taken in the research design, before initiation of the data collection for the main study. An essential process before data collection begins is to acquire appropriate skills in qualitative methods to help achieve a high level of rigour in establishing a chain of evidence in case research. Dube and Pare (2003) have defined three templates of attributes for positivist case studies based on the works of Benbasat et al (1987), Eisenhardt (1989), Lee (1991) and Yin (1994). Table 18 shows the first template to assess a research design, which suggests key attributes for establishing rigour when conducting exploratory case studies. The table also explains how each attribute has been addressed for maintaining rigour in the context of this research study. 96 Table 18 Attributes used to assess research design in positivist case studies Area 1: Research Design Authors* Exploratory This study Clear research questions 1, 2, 3 X X What and how questions were identified early in the study A priori specification of constructs 3 X X List of constructs identified from published literature and pilot study Clean theoretical slate 3 X X No existing hypothesis to test Multiple –case design 2, 3, 4 X X Ten cases studies were selected Nature of single-case design 2 X --NA-- Replication of logic in multiple-case design 3, 4 X X Combined or mixed purposeful sampling Unit of analysis 1, 2 X X Three levels of analysis Pilot case 2 X X Conducted an in-depth pilot study with three offshore vendor organisations Context of the case study 1, 2 X X Site description, case study period, longitudinal design, triangulation, time spent on sites Team-based research 1, 3 X --NA-- Different roles for multiple investigators 1, 3 X --NA-- * 1 = Benbasat et al. (1987); 2 = Yin (1994); 3 = Eisenhardt(1989) ; 4 = Lee(1991) Source: Dube and Pare 2003 3.8 Data collection process An essential process in qualitative research is how the data are recorded. The research design should specify elaborate details of the data recording, as lack of such detail is a serious deficiency in any case study (Dube & Pare, 2003). Benbasat et al. (1987, p. 381) also emphasise that “a clear description of the data sources and the way they contribute to the findings of the research is an important aspect of the reliability and validity of the findings”. Creswell (2008) suggests recording information through research protocols to help to anticipate potential problems in data collection, and bringing sensitivity to ethical issues prior to administering data collection. 97 A major strength of case study data collection is the opportunity to use many different sources of evidence including interviews, documents, archival records, direct observation and physical artefacts. Such multiple methods provide a rich picture of the events compared to use of a single method. This section elaborates on the data collection processes undertaken during the two phases of this study: pilot study and main study. 3.8.1 Ethical issues in data collection Ethical considerations play an important role in qualitative inquiry, and are “something of a contract between the researcher and the researched, a disclosing and protective covenant, usually informal, but best not silent – a moral obligation” (Stake, 2003, p. 99). Patton (2002) offers a checklist of general ethical issues to consider, such as reciprocity, assessment of risk, confidentiality, informed consent and data access and ownership. A brief outline of the purpose of the intended study, method of data collection, a guarantee for protection of participant’s rights (including thei r right to withdraw at any time of study), their voluntary participation to have the interviews tape-recorded or not, and a pre-designed questionnaire was submitted to gain permission from the Human Ethics Committee of Massey University. The study was approved as a low risk study, and accordingly a notification to that effect was issued for proceeding for conducting the research interviews. An important consideration before entering any site to collect data is obtaining prior permission to gather data for research. Permission ensures that participants cooperate in the study and provide data. Besides cooperati on, permission also acknowledges that the participant has understood the purpose of the study and also that the researcher will treat them ethically (Creswell, 2008). Each interview participant was given a written description of the purpose of the research study, along with a list of University officials who could be contacted if the participants were not satisfied with the way the study was being conducted. Each participant signed an informed consent form before the interview process began (refer Appendices A and B). Another ethical consideration addressed in this research is the anonymity of all the organisations and the study informants. The researcher signed a non-disclosure agreement, a copy of which was given to each of the participants prior to the interview. Care has been 98 taken to keep the identities of these organisati ons disguised as much as possible, with the use of pseudonyms to protect the privacy of informants and the organisations. Although anonymity is not considered a desirable condition in qualitative research (Yin, 2003), this anonymity agreement was necessary to gain access to these organisations. 3.8.2 Case study protocol A case study protocol contains procedures and general rules that should be followed in using research instruments prior to commencement of data collection. Use of data recording protocols such as interview protocol and observational protocol help in structuring the interview, and to minimise errors and biases in the study (Creswell, 2008). An interview protocol “contains instructions for the process of the interview, the questions to be asked, and space to take notes of respons es from the interviewees” (Creswell, 2008, p. 233). Designing an interview protocol with use of audiotapes helps in providing a detailed picture of the interview, and minimises loss of eye contact between the interviewer and interviewee; similarly, an observational protocol assists in recording a chronology of events, a detailed portrait of participants, a map of the setting, or verbatim quotes of individuals (Creswell, 2008). Recording such experiences helps the researcher later when reflecting on the data collected during analysis and coding (Benbasat et al., 1987; Dube & Pare, 2003; Yin, 2003). The three main elements of the case study protocol included field procedures, the interview protocol and the observational protocol. In the fi rst year of the study, exploratory interviews were arranged with three pilot cases (referred to as Pilot-NZ-Small, Pilot-NZ-Med, and Pilot-IN-Med). These early interviews were unstructured and open-ended, and aimed to “translate research objectives into specific research questions” (Denzin, 1989, p. 107). They helped in the development of a conceptual framework, formation of semi-structured interview questions and identification of selection criteria for purposeful sampling of cases for the main study. The findings from the pilot study were discussed with participants and government officials in NZTE and NASSCOM, to gain deeper insights into the current offshore situation, and identify similar vendor organisations. Other instruments included in the case study protocol were: use of audiot apes, ethical approval from Massey University, 99 white papers from corporate web sites, and do cuments pertaining to data discovered during interviews (e.g. software tools used for collaboration, project management and other source control tools, public websites of the vendors’ client and offshore partners, and details on certifications preferred by participating vendors, amongst many others). 3.8.3 Case study database A case study database contains the following elements: raw material (including interview transcripts, researcher’s field notes, and documents collected during data collection); coded data; coding scheme; memos and other analytic material; and data displays (Dube & Pare, 2003). Maxwell (2005) emphasises the necessity for an overall methodological approach which will link questions, data and analytic approaches, as the analysis is ongoing throughout the life of the project. The study utilised the NVivo software tool to organise and analyse the vast amount of textual data along three levels: demographically, organisationally and along individual processes. The software tool helped to organise the ten cases in tree structures and folders, to draw visualisation maps as categories emerged and to store queries to achieve within-case and cross-case analysis. This eased the task of interpretive coding as questions were asked of the data, and helped to bring contextual data from disparate sources together in one place. Bazely (2007) clarifies that the task of inte grating the chosen perspective and conceptual framework into the choices of what and how to code is done by the researcher, and not the software. Bazely encourages the use of qualitative software tools such as Nvivo to help in managing the logistics of pieces of interview data, and states that such tools do not hinder the interpretive capacity of the researcher. He compares the researcher using qualitative software tools to an artisan using his tools, “as the good artisan knows how to make his tools sing” to produce a creative piece of work (p. 10). The case data has been coded along the identified embedded units of analysis, and the analysis is explained in detail in Chapters six, seven, eight and nine. 100 3.8.4 Pilot study A pilot study of three offshore software vendor organisations was selected at the initial stage of the study. Selection of the pilot cases involved a combination of sampling strategies (i.e. random purposeful, intensity case, criterion and convenience). Interviews were conducted from October 2004 to December 2004. A brief description of the three vendor organisations is given in Table 19. The organisations are referred as Pilot-NZ-Small, Pilot-NZ-Med and Pilot-IN-Med. Table 19 Brief description of pilot cases Organisation Location of head office Total number of employees (approximate) Functional levels interviewed Pilot-NZ-Small Auckland, New Zealand 15 Owner and director Project manager Pilot-NZ-Med Wellington, New Zealand 230 General manager (Off-shoring) Developers Pilot-IN-Med Vizag, India 20 in Auckland office Vice president (NZ operations) Project manager Developers Because this study is largely exploratory, the initial interviews were open-ended and unstructured. Unstructured interviews have also been used because they allow participants to speak with their own voices and control their responses and yet have the space to introduce and reflect on issues that they perceive as relevant (Mishler, 1986). Interviews also permitted the development of a personal narrative (Cochran, 1990) which gave context to the particular work events, as stories emerged and evolved. Observations took the form of sitting with developers when they were discussing their work with other team members, or examining documentation to understand the reality of the knowledge sharing processes across distributed teams. Field notes were made during the interview process, and immediately after the interviews, and maintain ed in a case journal. These multiple data sources have been combined to achieve triangulation. The audio recordings were later transcribed and sent back to the interviewees for checking. Five of the respondents responded positively to the transcriptions, while two did not respond. It was later found that one of the respondents had left the said organisation, while the other had simply not responded. Sensitivity to individuals and case sites has always 101 been maintained throughout the process. The case study database was updated, and the researcher’s journal maintained to ensure reliable data was available for coding. 3.8.5 Main study Pettigrew (1997) describes the selection of and access to research participants as a mixture of forethought, intention, chance, expediency and environmental acceptability. Accordingly the main study started with a purposeful sampling strategy that matched the intent of the study. The pilot study helped in improving understanding of the central phenomena of the research, as a conceptual framework and units of analysis were identified. The researcher gained enough confidence to extend this study to a larger sample of cases to provide in- depth understanding of the offshore vendors’ knowledge management strategies. Semi- structured and open-ended questions were used during the interview process, though the questions had more focus than in the pilot study. Dubois and Gadde (2002) have made a distinction between two types of interview data, i.e. ‘active’ and ‘passive’. Passive data has no predetermined objective and appears through search by an active interviewer for new findings from unanticipated data, triggering new insights and this helps to generate more focussed questions on which further interviews can be based. Active data on the other hand is associated with discovery and is concerned with a passive interviewer who now has a more informed view of the phenomenon under study. This study was involved with ‘passive interview data’ during the pilot study with unstructured interview questions, and later progressed to more ‘active interview data’ during the main study with semi-structured interview questions. The distance between the two macro level units of analysis (New Zealand and India) meant that time and resources had to be used efficiently. Therefore the first point of contact for the main study was NASSCOM, to identify five Indian vendor organisations. Overall, seven Indian companies were approached to take part in the research. Of these, two organisations declined to be involved in the research. The researcher travelled to India from November 2005 to February 2006 and again from Decembe r 2006 to February 2007 to interview the five cases. 102 Both of the larger Indian organisations refused to have their interviews tape recorded, however the three smaller organisations were open to have their interviews recorded. Extensive notes were written during interviews with the larger organisations. The next stage was to identify some New Zealand owned vendor organisations. Several organisations were identified, of which two organisations finally agreed to be a part of the main study. They were interviewed between August 2006 and September 2006. The lack of progress in obtaining access to more offshore vendors became frustrating for the researcher. Finally NZTE was approached and findings from the earlier pilot study were shared with them. NZTE staff offered a list of six vendor or ganisations, which were each approached in turn. Three of these organisations declined to participate in the study citing privacy issues. Eventually three organisations agreed to take part in the study. These organisations were interviewed from October 2006 until the end of November 2006. Fortunately, all the New Zealand organisations agreed to have their interviews audio recorded. Field notes, observation and documents supplemented the data collected. All of these organisations were re-visited after a year between December 2006 and August 2007, and briefly interviewed to check if anything was recorded inconsistently, or if practices had changed much. Some of the developers who were interviewed earlier had left their previous organisations, so new developers were interviewed. This helped in bringing multiple perspectives to their work processes, thus adding to triangulation. The non-disclosure agreement and low risk notification also helped in gaining vendors’ cooperation and assured the vendor that the researcher would maintain their confidentiality. Ethical considerations such as confidentiality and anonymity of the final cases have been rigorously maintained. These organisations are referred to subsequently as NZ1, NZ2, NZ3, NZ4, NZ5, IN1, IN2, IN3, IN4 and IN5. A brief description of the ten organisations is given in Table 20. 103 Table 20 Brief description of main cases Vendor Location of head office Total employees (approximate) Functional levels interviewed NZ1 Wellington, New Zealand 180 General manager, project manager and developers NZ2 Auckland New Zealand 100 Managing director, project leader and developers NZ3 Auckland, New Zealand 20 Director and developers NZ4 Auckland, New Zealand 40 Project leader and developers NZ5 Auckland New Zealand 30 Managing director and developers IN1 Pune, India 1500 Senior project manager, developers and human resource personnel IN2 Pune, India 1800 Chief technology officer, project managers, developers and quality team IN3 Pacifica, California, US 200 Chief executive officer, senior manager and developers IN4 Toronto, Canada 100 Chief operations officer, project manager, developers and human resources personnel IN5 Minneapolis, Minnesota, US 90 Chief executive officer, project manager and developers 3.8.6 Data collection checklist This section describes the checklist of the steps taken in the data collection phase of the study, before the data analysis was initiated. An essential process before analysing data is to check the validity and reliability of the data collected. Dube and Pare have defined a second template of attributes for data collection in positivist case studies based on the works of Benbasat et al (1987), Eisenhardt (1989), Lee (1991) and Yin (1994). Table 21 shows the checklist with suggested a ttributes for exploratory case studies. The table also shows how each attribute has been addressed in the context of this research study. 104 Table 21 Attributes used to assess data collection in positivist case studies Area 2: Data collection Authors* Exploratory This study Elucidation of data collection process 1 X X Ten organisations were selected based on purposeful sampling, after the pilot study clarified the intent of the study Multiple data collection methods 1, 2, 3 4 X X Interviews, observations, emails, documents and member checking through NZTE and NASSCOM Mix of qualitative and quantitative data 1, 3 X --NA-- The study aims to capture the real life processes of practitioners and used qualitative data only. Data triangulation 1, 2, 3, 4 X X Multiple sources of evidence have been used (e.g. interviews, follow-up interviews, case journals, observations) Case study protocol 1, 2 X X Interview protocol, observational protocol, sensitivity to ethical issues, and purposeful sampling technique identified for main study Case study database 1, 2 X X Interview transcripts, case journals, observations, documents, company websites, company white papers * 1 = Benbasat et al. (1987); 2 = Yin (1994); 3 = Eisenhardt(1989) ; 4 = Lee(1991) Source: Dube and Pare 2003 3.9 Data analysis The data analysis strategy is even more important for an exploratory case study, since the goal of the research is to develop theory (Dube & Pare, 2003). Eisenhardt (1989) stresses that analysing data is “both the most difficult and the least codified part of the process”. Benbasat et al. (2002) emphasise the contextual and data richness of the case study to establish a clear chain of evidence. Frequently for most qualitative methods, data collection and analysis occurs recursively (Eisenhardt, 1989; Miles & Huberman, 1994) as “hypotheses emerge that inform subsequent fieldwork” (Patton, 2002, p. 436). To achieve internal validity, the data collection and anal ysis processes should be tight enough so that final evidence presented in the case report reflects the same evidence that was collected during the data collection process (Dube & Pare, 2003). The analysis began with a data management strategy. Each interview was transcribed verbatim by the researcher, to be as close to the conversation as possible. Transcribing involves translating from an oral language, with its own set of rules, to a written language 105 with another set of rules, and represents inte rpretative constructions within contextualised conversations from a series of choices by the researchers (Kvalve, 1996). The nonverbal elements of conversation missing from transcripts, such as pauses, sarcasm, or nods to convey agreement or disagreement have been combined later, when transcripts were reviewed alongside the field notes. The pilot interview data was coded manually to identify interesting attributes, but as the number of cases increased for the main study, it became difficult to match attributes across these ten cases. Accordingly, the NVivo software tool was employed to track ideas and link them with appropriate interview text to identify common themes. The participants’ stories were analysed across multiple frames of reference, such as knowledge management strategies, vendors’ perspectives on relationshi p strategies across different economic spaces, and perceptions on the effect of distance and cultures on inter-organisational trust levels, amongst others. Contextualisation of various elements of field interview data helped in coding some of the attributes across the organisational spaces to identify vendors’ strategies. The analysis is supported by direct quotations from notes and interviews, as raw field notes and verbatim transcripts reflect “the undigested complexity of reality” (Patton, 2002, p. 463). Analytical descriptions have been used (Yin, 1994) to explain the lessons learned that may be applied in a broader context (Stake, 1995). The composite of stories gathered from each vendor have been used to illustrate important interpretations and experiences of these participants. Each case has been analysed ideographically using a detailed thick description of context, and interview text has been categorised to identify work process themes at the micro unit of analysis. The micro patterns have then been analysed along the middle units or organisational level to form a matrix indicating relationships between categories for any ‘analytic generalisations’ (Yin, 1994) or ‘lessons learned’, which may be applied in a broader context (Stake, 1995) across the macro level. Eisenhardt (1989) and Miles and Huberman (1994) warn researchers to supplement pattern-matching strategies by looking at emergent categories in divergent ways, that is, both within-group similarities coupled with inter-group differences. Yin (1994) describes this data analysis strategy as explanation- building, and is a form of pattern matching where analysis of the case study is carried out by building a textual explanation of the study, and is most useful for exploratory case 106 studies. Summaries of findings from data analysis have been explained through “narrative discussions” for each identifie d category (Creswell 2008, p. 262). The study involved recursive data collection and analysis phases from December 2005 to August 2007. Two sets of interview transcripts were created for the ten organisations; first interview and later follow-up interview transcripts. The use of quotes in a qualitative write- up is a way “to bring in the voice of participants in the study” (Creswell 2008, p. 170). Quotes provide compelling evidence allowing the reader to reach an independent judgment regarding the merits of the analysis (Yin 1994). Creswell (2008, p. 259) calls for rigour in analysis by layering themes or interconnecting the emerging themes, as minor themes are subsumed within major themes, and major themes within broader themes. The layers of “interconnecting themes” help to display a chronology of events to “generate a theoretical and conceptual model”. Janesick (2004, p. 109) suggests the use of exact quotations from participants, as “an interpretive commentary related to the data, because the data cannot speak by itself”, to lead the reader to the themes, and guide them to the proposed model. Figure 7 illustrates an example of how broader themes emerged from data in the current research study. Figure 7 describes a broad category, reputation, which is linked to a variety of themes, such as patents, awards, certifications, references, corporate websites and community service activities as vendors’ narratives and websites were analysed. Figure 7 Example of qualitative data analysis used in this research study Adapted from Creswell, 2008, p. 259 Raw data Socio-psychological - Reputation Description of events Client references Software certifications Patents, awards Corporate websites Layer 1: Database (interview transcripts, observational field notes, reports, documents) Layer 2: Descriptive analysis of the chronology of events Layer 3: Themes identified Layer 4: Broad perspective Community service 107 Moreover, this study uses an embedded case design – micro, meso and macro – whereby data analysis has to be carried out for each level of the case design. However, an embedded case design has potential shortcomings. Rendering the identity of the units as a larger unit or sub-unit may focus the inquiry towards the sub-unit level, and fail to return to the larger unit or context of the phenomenon as a whole (Benbasat et al., 2002; Yin, 2003). To overcome this shortcoming, this study analyses the middle level or organisational level of analysis of the organisations’ knowledge management strategies as an aggregation of their micro level work processes. These micro leve l work processes are also compared across different organisational levels in a matrix structure. Later the meso units or organisational levels have been grouped within their macro contexts or country groups to be analysed with use of Brunswikian Lens Model (BLM). The BLM has been used by many social scientists for knowledge integration in research using embedded case design (Scholz & Tietje, 2002). The BLM is used to evaluate an embedded case structure to integrate multiple pieces of evidence into subunits which are considered salient to the case problem. Figure 8 describes the application of Brunswikian Lens Model in the context of the higher levels of analysis for an embedded case design structure. Figure 8 Brunswikian lens model Source: Scholz and Tietje 2002 New insights Case agents Perceptor Decomposition Synthesis Data acquisiton phase Data interpretation phase Perceptor Perceptor Perceptor Transformational process 108 BLM states that the researcher enters the data acquisition phase after having defined certain perspectives of the case or at a higher level of analysis. The data acquisition phase is followed by a data interpretation phase, a transformational process relying on analysis of empirical data based upon a variety of perceptors to arrive at a new conception, judgement or evaluation. The transformation results in new knowledge or an insight resulting in synthesis of the multifaceted data. Thus BLM id entifies an ‘initial focal point’ (case agents) which are analysed through the higher analytical lens to arrive at the ‘terminal focal point’ (new knowledge or an insight on knowledge sharing practices). 3.9.1 Data analysis checklist This section utilises the third checklist identif ied by Dube and Pare (2003) for the steps taken in the analysis of empirical data, as th emes and sub themes emerge. Selection of the themes within group levels or inter group levels requires the researcher to be flexible, as empirical data may not match the predicted data. Moreover, building textual explanation is an essential part of matching patterns across cases. Table 22 lists the key steps in data analys is for positivist case studies, which helps to establish rigour in the data analysis process for exploratory case studies (Dube & Pare, 2003). The table also explains the steps taken for addressing each of the attributes in this study. 109 Table 22 Attributes used to assess data analysis in positivist case studies Data collection Authors * Exploratory This study Elucidation of data analysis process 1, 2, 3 X X Layering of themes emerging from data, BL M Field Notes 2, 3 X X Field notes made to supplement interview transcripts Coding and reliability check 2 X X Purposeful sampling, follow-up interviews Data displays 2 X X Visual maps & static models in NVivo Flexible & opportunistic process 1, 2, 3 X X Flexibility in data collection and analysis was maintained as evolving themes challenged previous ideas obtained from literature review and pilot study. Logical chain of evidence 1, 2 X X Context of case, supporting quotes from transcripts and observation Explanation building 2 X X Descriptive analysis of processes Searching for cross- case patterns 3, 4 X X Pattern matching, contextual mapping, use of queries with software tool. Quotes (evidence) 1, 2 X X Extensive use of many quotes by participants Project reviews 2 X X Self reviews by reading and re-reading of transcripts and analysis; presentations at international conferences, seminars and journals Comparison with extant literature 3 X X Analysis of published similar literature * 1 = Benbasat et al. (1987); 2 = Yin (1994); 3 = Eisenhardt(1989) ; 4 = Lee(1991) Source: Dube and Pare 2003 3.10 Case study report Qualitative research depends on the presentation of descriptive data, so that the reader is led to an understanding of the meaning of the experience under study (Janesick, 2003). However, there should exist a balance between description and interpretation (Patton, 1990), as “endless description is not useful if the researcher has to present a powerful narrative” (Janesick, 2003, p. 66). Dubois and Ga dde (2002, p. 559) state that a problem with case research relates to the fact that some researchers tend to describe everything and “as a result describe nothing”. Thus they advise researchers to be parsimonious or selective; else too many descriptions will obscure the reader’s understanding. Yin (1994) warns that case studies should maintain a chain of evidence, without burdening the narrative with too 110 many methodological treatises, and such shortcoming can be overcome by use of footnotes, textboxes, tables or figures. Yin (2003) describes four varieties of writte n forms of case studies, namely the classic single-case narrative report, the multi-case version of the single-case narrative report, the composition of single and multiple cases based on structured interview questions and answers format, and lastly a composite report for multiple cases only. In the fourth style of reporting, individual case descriptions are either ignored altogether, or may be presented in abbreviated vignettes. Here individual cases serve as the evidentiary base for the study and may be used only in the cross-case analysis. The case study findings in this study are reported in a composite multi case format. Here, brief case descriptions are presented to inform the reader about their organisational settings. Detailed textual description of ten vendor organisations may render their later description in the report to be given less attention by the reader, thus brevity is preferred for each case introduction. Later, empirical data is queried to identify categories in the first layer of analysis. Patton (1990, p. 122) suggests that to avoid clutter of categories, one should ask oneself “Why am I doing this?” before capturing and coding a cat egory as relevant. Each identified category is mapped with the identified a priori constructs to provide convincing arguments on the relevance of the category. These categories are also mapped with each organisational practice and supported by direct quotations from the study participants, wherever applicable. The study is exploratory, and uses semi-structured interview questions within a socio-technical organisational setting, whereb y respondents could answer in their own voices as they reflected on their past experiences. Janesick (2004, p. 123) advises researchers “to use abundant sections from your transcripts”, as qualitative work is grounded from data; the words of the participants; field notes, reflective journal entries and other written records. The second level of analysis refers to cross-case organisational levels. Therefore the comparisons have been made to consolidate similarities between vendor organisations when 111 the conceptual categories were found to be connected. Similarly divergent categories have been identified if the categories were found to be disconnected. Finally the third or macro level of analysis looks at the variations across the software vendor industries in two different countries. Similarities and differences across cultural dimensions are revealed in knowledge sharing processes in the OSD environment. These comparisons have helped answer the research questions. Tables, textboxes, footnotes and diagrams have been used extensively to illustra te patterns, comparisons and relationships at various levels of analysis. 3.11 Methodological model of the study Janesick (2004) suggests the development of a model of what occurred in the study, to help the reader of the report make sense of the data and follow the researcher’s arguments. Figure 9 presents the methodological model of the study. The model illustrates the major inputs, processes and research outcomes. The figure explains the relationships between the research components, as they are now described. 112 Figure 9 Methodological model of this research study Inputs to research Research outcomes Research processes Relevant academic literature ⎯ Offshore software development (OSD) ⎯ Software engineering ⎯ Offshore outsourcing ⎯ Cultural issues ⎯ Qualitative research methods Selection of multiple cases for main study ( Similar cases) Combination sampling strategy (snowballing technique through government agencies - NZTE and NASSCOM ) • N Z 1 … ….NZ5 • I N 1 … …..IN5 Research design ⎯ Clear research questions ⎯ A priori specification of constructs ⎯ Conceptual framework of OSD ⎯ Multiple case design ⎯ Embedded unit of analysis Refinement of conceptual framework of OSD Case study protocol (ethical approval, interview protocol, observational protocol, field procedures, guide to case report) Case study database (data organisation, data integration and data reduction) Case study reports Findings ( Informed conceptual study, revised framework) Analysis of relevant literature Pilot case study (Ad hoc cases) Conduct multiple case study ⎯ Pilot-NZ-Small ⎯ Pilot-NZ-Med ⎯ Pilot-IN-Med Understanding of OSD environment Data collection and triangulation (interview transcripts, field-notes, observations, documents, follow- up interviews) Comparing theory and data (several iterations) Cross-case comparisons (within case, then across case – using case description, pattern matching, logical chain of evidence, explanation building, narrative discussions, application of Brunswikian Lens Model) During the first year of study, the emphasis was on developing an understanding of the research background of off-shoring within the New Zealand and Indian contexts. The research input (on the left of Figure 9) includes the relevant academic literature concerning offshore software development processes, cultural issues, virtual software development teams, and qualitative research methods. The literature reviews provided the source of 113 definitions of concepts central to this research study, and a priori specification of constructs were identified. Since this study is largely exploratory, a pilot study was initiated to gain a deeper understanding of the phenomenon under study. Vendors with prior experience in offshore software development for clients belonging to different countries were interviewed. This process facilitated the development of the research questions, confirmation of a priori constructs and a conceptual framework linking ideas to the empirical data. This led to further exploration of the academic literature. The combined components of the literature review with findings from the pilot studies formed the basis and motivation for formulation of a conceptual framework. The proposed conceptual framework draws on both previous literature and empirical findings from the pilot study. Dubois and Gadde (2002) state that theory cannot be understood without empirical observation and vice versa. They call the development of a framework where theory complements empirical findings and vice versa as systematic combining. The evolving framework is both a tool and a product, where the framework evolves slowly with systematic combining as empirical observations inspire changes in theory and vice versa and finally evolves into the end product. Next, an examination of the literature centring on software project experiences within the two countries of interest led to identification and description of the components within the diverse cultural environments. This provided the case study protocol to be used with semi-structured interviews for each case study with a consistent basis, but without constraining the freedom of the participants in their responses. Figure 10 shows how systematic combining is done in this research study, and is based upon Dubois and Gadde’s evolving framework in which theory and practice inform each other. 114 Figure 10 Systematic combining Source: Dubois and Gadde 2002, p. 555 The research then moved to the phase of data collection, as vendor sites were identified with government officials belonging to these countries. Multiple methods of data collection were used including interviews, observations, field notes, documents and corporate white papers. From there on, the research process moved iteratively, as stories of participants were described, analysed, compared with publis hed literature, and subjected to cross-case comparisons. In the final component of the research, the multiple case comparisons have been done along three levels, as practitioners’ stories were recounted and contextualised with identified categories. Results of the case study comparisons have been used to refine the framework, as a more informed view was obtained at this time of the study. 3.12 Conclusions This chapter reported the research design for this study. The inquiry of the phenomenon under study is inherently phenomenological and based on exploration of a contemporary society. It is thus influenced by the resear cher’s selection and evaluation processes, the Framework Multiple case studies The empirical world (pilot case study) Theory (published literature) Matching: Direction and Redirection 115 empirical evidence obtained, and the dialogue of inquiry and analysis for each of the phenomena under study. Accordingly the underlying epistemology used is post-positivist or reality oriented qualitative inquiry. The multiple case study approach is a suitable approach for answering this study’s research questions. Case study design included the identification of appropriate measures through use of an in-depth pilot study, investigator triangulation methods, analysis across three levels and contextualisation of empirical field data with theoretical insights. This ensured research quality and reliability, and resulted in detailed case study reports, cross-case analysis and conclusions. The next chapter presents the three pilot case studies used for systematic combining of theory and empirical observation for the development of the conceptual framework before commencement of the main study. 116 CHAPTER FOUR – Conceptual Framework 4.1 Introduction This chapter presents the conceptual framework for the research study. The study utilises concepts concerned with both theory and practice to refine the research design for presentation of the conceptual framework. The conceptual framework evolved along two parallel streams of study (literature review a nd pilot study) which were done concurrently. A review of literature helped in identifying success drivers considered key to knowledge sharing across international boundaries in the context of OSD. Details of the drivers have been synthesised in Chapter two (refer Table 8). During the first year of the study, these drivers were explored with three pilot case studies to understand how software vendors view these drivers and also their business practices associated with the drivers. Thus as prevailing theories were reflected upon with empirical observations; new insights were gained which provided conceptual clarification to inform theoretical propositions for the next phase of the study. This chapter starts with a description of the research method involved in the pilot study. It then gives a brief background to the three pilot cases, and provides some understanding of the organisational structure and cultural settings for each pilot case. This is followed by a detailed account of practitioner’s perspectives on enabling knowledge flow processes across inter-organisational and cultural boundaries in the virtual environment of OSD. The chapter then gives some more insights as the pilot study findings are discussed with the New Zealand government’s personnel working in the field of software exports. The chapter concludes with a coherent conceptual framework by utilising systematic combining of theory and empirical evidence to answer the research questions along three levels of analysis. 4.2 Research method employed for the pilot study The main objective of any research is to confront theory with the empirical world (Dubois & Gadde, 2002). Bryman (1995) also states that a theoretical concept provides the researcher with a set of general guidelines, and enables theory development rather than 117 theory creation, as existing theories are refined rather than invented. Yin (2003) suggests a pilot case study to be used as a prelude to the main study for theory development to assist in the clarification of research design, development of relevant questions and refinement of data collection plans. Moreover, the pilot uses a broader and less focussed inquiry as compared to the ultimate inquiry for final cases used in data collection, and Yin (2003, p. 79) states that “in general, convenience, access and geographical proximity can be the main criteria for selection of the pilot cases”. The main criterion for selection of pilot cases in this study was convenience and geographical proximity, and three pilot cases having offices in New Zealand were chosen. Two of the pilot cases were New Zealand vendor organisations having development centres in Auckland and Wellington, while the third case was an Indian vendor who had an offshore development centre in Auckland. This enabled frequent access to the development sites, and the information gathered through pilot interviews “was used in parallel with an ongoing review of relevant literature, so that th e final research design was informed both by prevailing theories and by a fresh set of empirical observations” (Yin, 2003, p. 80). Moreover, the sample of cases used in the pilot study was quite diverse, which enabled identification of many aspects of the drivers which challenged the previous ideas obtained from literature. Flexibility to data has been maintained in the study, and these diverse perspectives on key drivers were acknowledged and have been used as a formative strategy to inform and refine the research questions and unit of analysis. Examination of the literature focusing on the processes involved in offshore software development laid the foundation for key themes, and the researcher conducted open-ended interviews at the pilot sites between October 2004 and December 2004. Empirical data was collected through in-depth interviews, observations, documents and field notes. Interviews were held with senior managers and developers at each site, and the time spent at each organisation ranged from four to nine hours. This helped the researcher reach a good level of understanding of the work processes involved in knowledge transfer by vendor organisations. The field data gathered from the three pilot cases was analysed with published literature to gain a deeper understanding of the current offshore software development environment. New categories emerged from field data to inform theoretical 118 propositions, as participants spoke about their real life experiences of knowledge transfer and knowledge integration in a distributed software development environment. A rich description of each pilot case was recorded, as ideas were developed and reflected upon with the available literature. Patterns were identified from data, and though no qualitative software tool was used at this stage, modelling though Venn diagrams was used for identifying key and overlapping themes. Figure 11 illustrates an example of how Venn diagrams were used to capture key and overlapping themes when analysing communication strategies. Figure 11 Venn diagram for analysing communication strategies Pilot-NZ-Small Pilot-NZ-Med Pilot-IN-Med Emails, portals, tools Informal practices Semi-formal practices Formal practices Senior management involvement Middle management involvement Development site at vendor location only Development site at both client & vendor locations F2F Portal StarTeam Portal Clux Portal Bynet Special interest groups Video conferences Dedicated phone lines Project team leader Development teans Vice President 119 4.3 Background of pilot cases The three participating organisations are vendors in the field of offshore software application development, and are well recognised in their respective countries for developing quality software systems. The orga nisations are referred as Pilot-NZ-Small, Pilot-NZ-Med and Pilot-IN-Med. A brief description of each case is as follows 4.3.1 Pilot-NZ-Small Pilot-NZ-Small is a small New Zealand IT software provider, having 15 employees based in Auckland. Pilot-NZ-Small already has an established name in the local market and entered the offshore outsourcer market in 2003. It has had some mixed experiences and has used these to guide its current direction. Pilot-NZ-Small had its first offshore outsourcing project experience with a client based in Australia. The client was an intermediary service provider (hereby referred to as ClientSP), who had application development contracts with many clients. ClientSP had isolated a part of one of their project’s business function which was then outsourced to Pilot-NZ-Small. Project deliverables were passed daily from the outsourcer (Pilot-NZ-Small) to the client team (ClientSP) through a virtual private network and the client was required to validate each deliverable. Thus knowledge was meant to be transferred between team members, with ClientSP being responsible for testing each deliverable, tracking new issues and communicating them back to Pilot-NZ-Small. However Pilot-NZ-Small complained that ClientSP’s testing team implemented their own decisions on fixes needed in the source code without informing the developer team at Pilot-NZ-Small, which made the developers feel a loss of ownership for their code. The project lasted for three months, leaving some bitter memories with the Pilot-NZ-Small developers. Though NZ shares a close cultural proximity to Australia, Pilot-NZ-Small felt that eventually it was the organisational cultural disparity which got in the way. A telling comment from the vendor was “ I can discuss rugby with them for hours, but when it comes to company culture – NO WAY”. 120 Moreover the only means of communication between Pilot-NZ-Small and ClientSP was through email. Pilot-NZ-Small complained that if the client did not agree with them, they would simply not respond to their email messages. The project manager of Pilot-NZ-Small commented “you cannot build relationships so well through email – the trust and the liking for the person sitting across is not there, and its hard to judge people if you can’t see them”. Borchers’ (2003, p. 544) experiment acro ss US, Indian and Japanese teams also supports the view that daily build updates announced via email were not considered a “good thing by developers from any culture”. Furthermore, Pilot-NZ-Small did not agree with the source control practices used by the client’s team. The vendor used an automated configuration and change management tool called StarTeam (by Borland) which was not fully exploited by the client. The variation in organisational practices brought the provider a sense of not feeling respected for their efforts and so Pilot-NZ-Small decided not to extend the relationship after the final deliverable. The second offshore development project has been completed with another service provider client based in the United Kingdom (UK). This time both the client and Pilot-NZ-Small used a customised solution of StarTeam, which gave good results. The client had also stationed a project manager in the vendor’s country. Weekly meetings between the vendor’s project manager and the client’s project manager were being held during the time of the interviews and problems were resolved amicably across the table. This job has now been completed, and Pilot-NZ-Small is presently invol ved with a third development project with the same client. 4.3.2 Pilot-NZ-Med Pilot-NZ-Med is a medium New Zealand IT services provider having about 230 employees, with its main software development centre in Wellington, and another centre in Auckland. They are one of the leading IT service providers in New Zealand and have ambitious plans for further offshore software development. They have completed many local and offshore projects, for example in the UK and Singapore, and are major industry participants in outsourcing discussion groups. 121 Pilot-NZ-Med was previously an ISO 9001 certifie d company, but let the certification lapse due to the extensive documentation requirements, as is evident from this remark made by the general manager: “ The more you document, the slower you become at changing, as it is extremely hard to change the documentation – and so you don’t change”. Such resistance to documentation by developers has also been highlighted in previous studies (Herbsleb & Moitra, 2001). The use of internal audits usi ng the Baldridge model is Pilot-NZ-Med’s way of coordinating processes rather than through international audits. The Baldridge criterion has been used by businesses since 1987 to measure the maturity of their organisational performance practices, capabilities and effectiveness in making organisations successful. Pilot-NZ-Med felt that it was twice as good as an average company, having scored more than double the points of an average company on the Baldridge scale, but it was nowhere near world class. However, the general manager of Pilot-NZ-Med agreed that certifications sometimes did help in getting a contract, as is evident from his remark that “ nobody here asks for CMM at the start, but when they get down to a short-list of say three providers, then certifications are used as a differentiator”. Pilot-NZ-Med emphasises the importance of long lasting trusting relationships, so they have one third of their team located at the client’s site. This team handles all the communication with the clients as “ nothing can beat voice” This onsite team, headed by the delivery manager, handles all the communication with the client, and makes sure “ that the interaction between project manager and client’s project team is strong”. Then, any other communication between the offshore team and staff in NZ is an internal communication within the organisation. Onshore and offshore team members interact with each other over an internally developed communication tool called Clux or through open source tools for blogging like discussion forums and wikis. The interactive nature of blogging moves it from a “broadcast publishing mode to something closer to a conversation or a community- building and coordinating tool” (Herman, 2003, p. 20). The management of Pilot-NZ-Med is very appreciative of the use of such tools and they have set up special interest groups (SIGs), which have their own electronic ed itorial boards. These SIGs report some interesting past experiences and also run so me excellent documented parts of the wikis. The project manager also told of some experiences when developer team members situated at the client site had delayed projects because they changed decisions without informing the 122 development team in New Zealand. This resulted in many last minute changes, often leading to missed deadlines. They now emphasised the use of organisational portals using automated tools such as ProjectPlus and Mi crosoft SharePoint as a common frame of reference for sharing documents, tracking of any changes, and overall good software configuration management. However, they did not believe in too much standardisation of policies and procedures for development, testing or change implementation. 4.3.3 Pilot-IN-Med Pilot-IN-Med is a medium sized Indian IT service provider with approximately 170 employees. Their main development centre is in Vizag, India, but they also have smaller offshore development centres located in Auckland, Melbourne and Dallas. Pilot-IN-Med has earned many export performance prizes from the Indian government. They presently have an offshore presence of 20 employees in Auckland which help mediate project management across national and cultural boundaries. The offshore development centre also helps Pilot-IN-Med to bring tax benefits in the home country (India). Team members are brought on a continuous basis on work permits from India to New Zealand, and are replaced by other Indian programmers when their work permits expire. Pilot-IN-Med feels a special need to build las ting relationships with clients who have long term projects and so team members with good in terpersonal skills are assigned to the client. In the words of the vice president of Pilot-IN-Med “ We provide a dedicated resource and he works as an extended arm of the client and so he gets well trained in the customer process and domain knowledge of the customer requirements....... this is both a knowledge strategy as well as a marketing strategy…… and helps to remove the exclusiveness in working styles ”. Bridging national and organisational cultural differences was considered essential by Pilot-IN-Med, and visits of clients to India were also encouraged. This brought in a mutual understanding of each other’s ethnic and corporate cultures, thus nurturing a sense of mutual respect for each other’s social values, with each side enjoying the surprise element of a different society. Further, Pilot-IN-Med has provided two dedicated phone lines to its parent company in India, in addition to other sophisticated project management tools (e.g. Bynet) to integrate 123 datacom and telecom systems within their development environment. The team members are allowed to freely communicate with friends and family in India through the telecommunication media provided, showing an awareness of the family and social structure of the Indian mindset. Meetings are held weekly or fortnightly between the project leader and the clients, which are documented in the form of minutes, so that all participants can receive the same message. Hence, knowledge is understood, codified, dis-embedded and transferred across time and space to be re-embedded in other contexts as also described by Sahay et al. (2003). The vice president admitted that these processes bring in a hierarchical and bureaucratic culture, but felt that they were necessary in order to avoid problems with processes, deliverables, deadlines, and effort that might result from miscommunication. Moreover the uncertainty due to 25% staff attrition meant that explicit documentation of knowledge helped in reducing dependency of individuals who may suddenly leave the organisation. The project manager voiced: “The IT industry is very volatile so project progress has to be monitored properly to survive”. Another strategy to coordinate activities is the standardisation of the project practices domain. Universal templates to define, guide, and evaluate management practices are rigorously maintained. These standardised systems, codified in manuals, serve as points of reference to coordinate activities across time and space. The vendor took pride in these practices and showed the researcher many templates from past projects and current live projects. These documents are also necessary as Pilot-IN-Med is a CMM Level 3 and ISO 9001 certified company and is audited by external international agencies on a regular basis. 4.4 Organisation culture and structure of pilot cases Senior management, project managers and developers were interviewed in the three organisations. Table 23 briefly describes inte rview settings of the three participating organisations. 124 Table 23 Pilot case interview settings Organisation Persons interviewed Location of head office Interview dates Pilot-NZ-Small Director and project manager Auckland, New Zealand October 2004 Pilot-NZ-Med General manager and developers Wellington, New Zealand November 2004 Pilot-IN-Med Vice president, project manager and developers Vizag, India October 2004 December 2004 A brief view of the organisation culture and structure is also listed in Table 24, to provide a larger view of the field settings, as qualitative field study is also “focused on understanding given social settings” (Janesick, 2003, p. 57). Table 24 Organisation culture and structure Pilot-NZ-Small Pilot-NZ-Med Pilot-IN-Med Team - Team members are local New Zealanders. Team - Team members are of multiple nationalities (e.g. New Zealanders, Europeans, Asians and Indians). Team - Team members are Indian nationals only. Levels - Flat organisation, where no one is designated team leader in the project group. Levels - Fewer levels defined, but a small hierarchy exists within the project groups. Levels – Hierarchical organisation, with defined roles and levels defined within the project groups. Developers - Preference for developers with good interpersonal skills. Technical certifications are not considered relevant. Developers - Preference for developers with good project management skills. Technical certifications are not considered relevant. Developers - Preference for developers with good technical skills. Software certifications are considered important, and helped in obtaining a higher level in the organisational hierarchy. 4.5 Empirical findings from the pilot study The study has compared theoretical statements with field data or empirical statements and has also made cross case comparisons of empirical statements from each pilot case to make generalisations which may be applied to a broader context. Thus TE (theory to empirical statements) and EE (empirical to empirical) abst ractions have been applied as inputs in the process of making analytical generalisations (Lee & Baskerville, 2003; Yin, 2003). Trust is identified in the literature as an enabler to knowledge flow. “If people do not trust each other, they do not exchange knowledge and ideas” (Allee, 2003. p. 619). Vendors try 125 to build relationships to enable flow of knowledge across inter-organisational and cultural boundaries. Accordingly each vendor was asked what they considered as key to knowledge flow and relationship building. The vendor responses have been analysed in the context of this research study as has been described in the theoretical framework (refer Table 14) in the following two subsections. The responses have been analysed for interpretation framing and sense making, as vendor experiences were aligned with identified drivers (refer Table 8). This has led to the development of a conceptual framework, as theoretical framework constructs guided the search process to answer the research questions. The pilot studies provided rich insights into the empirical phenomena for knowledge flow and relationship building, and these have been discussed in the following subsections. 4.5.1 Key drivers for knowledge flow Prior literature has identified factors affecting knowledge sharing in OSD as: culture, communication, controls and co-ordination, requirement or change management, project management, quality management and types of contractual agreements (refer Table 8). With these themes laying the foundation of the research study, each interviewee was asked about the influences of these factors, and the practices associated with them. The practitioners view knowledge building as building on past experiences, by asking themselves what lessons have been learned, and what implications they have for defining future best practices. The director of Pilot-NZ-Small commented that knowledge building is “ evolving, as we dabble and gauge what we can stand, what the customer can stand and what we can live with”. The general manager of Pilot-NZ-Med commented that knowledge sharing and building is “having a common dashboard which helps to avoid a mismatch of expectations. We have to match expectation of developer, expectation of client and expectation of other managers. 126 It’s a diplomatic world with lots of room for negotiation. Once the expectation management is done then rest is all administration”. The vice president of Pilot-IN-Med commen ted that knowledge transfer involved an ongoing “ tailoring of individuals, teams, training, tools, designs, technology, and targets which cannot be just FTPed”. Table 25 indicates the vendors’ strategies to transfer of knowledge across international boundaries. 127 Table 25 Practices associated with knowledge sharing Key driver Pilot-NZ-Small Pilot-NZ-Med Pilot-IN-Med Culture ⎯ Views on national and organisational culture (e.g. ethnic and corporate working styles) Feel that organisational culture impacts on knowledge sharing process and not national culture. Their first project ended on a bitter note, and they realise now that a client interface is needed even though there may be similarity in national cultures. The new interface involves F2F interaction and helps to develop shared corporate values and working styles. View similarities of their national cultures with client organisations to be an advantage to knowledge sharing. Consider understanding of organisational culture equally important, and they have one third of their team located at the client’s site. Direct F2F meetings help in making teams aware of each other’s working styles. View bridging of both national and organisational culture for effective knowledge sharing. Indian developers with good interpersonal skills are deployed at the client site to better understand each other’s working styles. Daily F2F interactions at client’s site help in bringing understanding of ethnic and corporate styles. Visits by clients to India are encouraged and their local needs in India are looked after by the HR team. Communication ⎯ Formal/ informal communication styles (e.g. F2F, groupware tools) Informal means of communication mainly used, with email alone being used between the development teams in the first project. However, they now realise the need for a more interactive interface, and have started some regular F2F means of communication between project leaders. Semi-formal means of communication is used. F2F communication held with clients. E-mail, instant messaging, wikis/ discussion forums are created for separate project groups between the developers for transferring knowledge. Video-conference facilities are also used, though such meetings are mainly used by senior management and used for key meetings. Formal means of communication is used. Regular F2F meetings of onshore team with clients are held and feedbacks of these meetings are communicated to senior management. Dedicated telephone lines, email, instant messaging through common tools (e.g. msn messenger, skype) are used between project teams. ⎯ Team structures at location sites (i.e. onshore at client’s country and offshore at vendor’s country) No onshore team at client destination. The first offshore project did not have any client interaction, and the project ended with some bitter feelings. In the second offshore project, the project manager holds weekly meetings with the client representative. Split onshore and offshore team. Project manager at the onshore site interacts regularly and informally with the client. Split onshore and offshore team. One senior experienced vice-president is stationed in the client country (New Zealand), and he interacts with the clients on a regular basis. He explained his presence, due to the “introverted” nature of his programmers. 128 Key driver Pilot-NZ-Small Pilot-NZ-Med Pilot-IN-Med Control and coordination ⎯ Documentation Documentation is not considered necessary. In the words of the director “Our job is programming, not taking minutes” , and “ we don’t want to be document obsessed” Minimal documentation is used. Minutes and related documentation are not made as a regular practice. Taking minutes of meetings depends upon the project team leader – and is project dependent. Extensive documentation is used. Minutes of each project meeting are taken and the minutes are sent to all participants. ⎯ Number of project status meetings No status meetings were held in the first offshore project. Now, weekly or fortnightly F2F meetings are held with the client representative. Status meetings are decided by the project manager. Weekly or fortnightly meetings are held in a formal atmosphere with vice president, project manager, on-site team members and offshore team members. ⎯ Tools used by teams Borland StarTeam Internally developed tool called Clux. Bynet Project management ⎯ Project estimation Combination of ad-hoc estimations and judgement on the client’s capability to pay. Combination of statistical methods, expert judgement and past project experience. Combination of statistical methods, expert and past project experience. ⎯ Prior domain experience Developers develop new skills on the job as the need arises per project. Developers are given training on new skills before being put on the job. Recruitment of developers with science degrees, strong technical skills and certifications. ⎯ Test environment No standardisation of the test cases. The team felt that each project was different, and needed to have its own new tests. No standardisation of test cases. The team do not believe in having too much of standardisation, as this reduced the developer’s fle judgement xibility. Test cases are standardised and placed in a centralised repository for common use by onsite and offsite developers. ⎯ Attrition rates (in past 2 years) The attrition rate was zero between 2003 and 2004. The family like atmosphere was very conducive to the working environment. In 2004, the attrition rate was 5%. However, it rose to 15% in 2006, as per a newspaper report. Attrition rate was 25 % in 2004 Management was very unhappy with the volatile attrition rates and expressed their sentiments in very strong words. 129 Key driver Pilot-NZ-Small Pilot-NZ-Med Pilot-IN-Med Requirement volatility (also referred to as change or scope or expectation management by the vendor teams) No formal procedure, but work is passed on regular basis and changes are generally absorbed. Changes are not documented. Earlier project had encountered problems with ambiguity in source control, resulting in developer overtime and stress. Have encountered problems with expectation management both from client and over enthusiastic developers. Intervention of senior management is often required, if deadlines are not met. All changes are placed in a central data repository – no paper documentation used. No minutes taken, unless essential. This ensures awareness of all changing relationships in the development effort, for smooth knowledge transfer. All changes are done through a formal procedure (with complete authorisation, verification, and documentation). Senior management is always involved. All changes are documented and placed in a central data repository. Each change is assigned a number, has a priority label, due date and lists the name of the person responsible. The senior management keeps track of change numbers if due dates are not met. Quality practices No external certification, no standards for internal quality audits are laid down, but are keen to learn and understand simple measures to control quality. No external quality certifications (earlier an ISO 9001 certified organisation). Use of internal audits and Baldridge criteria to measure their maturity. ISO 9001 and CMM Level 3 certifications. Rigid quality practices are followed through regular audits by international agencies. Types of contracts Fixed Price Contracts (with no penalty clauses) Fixed Price Contracts (with no penalty clauses) Time-and-Material Fixed Price Contracts (with penalty clauses) Time-and-Material 130 4.5.2 Key drivers in relationship building All three vendors emphasise good relationships as core to transferring knowledge in the virtual environment. Lack of visibility of ve ndors’ physical attributes (such as ethnicity, accents, and other tangible physical cues) and non-local views of work structures at distributed sites were recognised as barriers to knowledge transfer. Thus all the vendor organisations have incorporated practices to bring transparency across virtual teams to build positive relationships. Some of the vendor practices were websites displaying certifications and past project successes to highlight their capability and past offshore experiences. Communication strategies used by vendors involved F2F meetings in physical locations at client sites or at centralised vendor offices, and also at virtual locations such as organisational portals. Work methods involving documentation and use of prototypes helped to bring awareness of tasks at distributed sites. These work methods thus bring in visibility of non-local tasks to the distributed team members, as they have to work together on a common knowledge platform. Other practices included mixed cultural make up of vendor teams and involvement of senior management to bring awareness of cultural and organisational structures across sites. Table 26 indicates the three vendors’ strategi es for building positive relationships across international boundaries 131 Table 26 Practices associated with relationship building Key Driver Pilot-NZ-Small Pilot-NZ-Med Pilot-IN-Med Visibility ⎯ Websites and past project references Company website is very modest, and lists the organisation name, director’s name, contact address and telephone numbers. Considered references such as “ word of mouth ” as key to gaining trust. Company website states “ the first thing you build in a project is trust” , and displays a long list of past projects with major clients. Do not consider international certifications essential to building trust. Company website lists export awards and international certificates (CMM level 3, ISO 9001). They also list names and quotes of international clients whose projects they have completed. Consider international certifications help to build their reputation internationally. Communication methods ⎯ Face – to – face meetings Consider weekly F2F meetings with project leaders as essential. Consider daily F2F meetings with project leaders and developers essential. Consider daily F2F meetings with project leaders, developers and senior management essential. ⎯ Formal work methods Do not prefer formal work methods. Daily builds are passed between vendor and client, hence no documentation is preferred. Some level of formality in work methods is preferred based upon past experiences. Prototypes are used and the client is guided through the builds by on-site developers. Documentation is not preferred, and is only done when considered absolutely essential. Very formal methods are in place. Prototypes are shown at fixed milestone meetings to client and these meetings are documented extensively. ⎯ Deployment of employees No employees are deployed at the client’s site. The client has a project manager deployed at vendor’s country. One third of the team comprising of developers and project leaders is located at the client site. The offshore team interacts regularly with the client team. Have developers at the client’s site, where client provides the resources and vendor provides the technical skills. They refer to this model as TLM or Technical Laboratory Model. ⎯ Centralised office/ common meeting places No direct F2F meetings held in the first project, but now they have a common meeting place with the client in NZ. Centralised office at the client country is considered essential. Centralised office at the client country is considered essential. ⎯ Organisational portals E xtensive use of portals (e.g. StarTeam ) Extensive use of portals (e.g. Clux, ProjectPlus, Microsoft Sharepoint) Extensive use of portals (e.g. Bynet) 132 4.6 Cross case comparison of pilot cases The pilot case data revealed that similarities and differences in practices existed across the organisational and country level. Some indicators of practices employed are given below 1. Efforts to understand cultural differences across national and organisational levels is considered important from the Indian organisation’s perspective, while the New Zealand organisation feel that only organisational cultures needed alignment. However, all the three organisations agreed that regular F2F meetings bring a shared understanding of each other’s products, processes and work practices, thus helping to align any differences between client and vendor organisational cultures. But F2F communication is pursued more in the larger organisations (New Zealand and Indian) whereas the smaller organisation (Pilot-NZ-Small) had earlier relied just on email. However, this practice had changed with the second project for the smaller organisation. 2. Deployment of employees at the client sites is pursued in both large organisations (New Zealand and Indian). Common meeti ng places are considered essential due to the tacit nature of knowledge in the software development environment. All three organisations consider usage of integrated collaborative groupware solutions like organisational portals as common meeting places in the virtual environment. Such portals also enhanced visibility of activities across international boundaries and help to build trust. Besides technological tools are also considered essential for source control and configuration management activities. 3. The Indian organisation preferred to recruit technical staff who could easily relate to their standard technical procedures laid by them in lieu of their certifications. Technical skills were not considered essential by the New Zealand vendor organisations, as they believed that the practices adopted by them could be easily learnt on the job. 133 4. Standardisation and formalisation of work methods is considered more by the Indian organisation. However, these form alisations and standardisations also brought about more bureaucratic and hierarchical structure and the Indian vendor (Pilot-IN-Med) agreed that these processes involved managerial reporting thus bringing in hierarchy. The formal process helped to keep track of all project changes and is considered a survival strategy in the said Indian organisation. The NZ developers are given more autonomy while handling the software development activities. Thus procedures to record changes (also known as change or scope or expectation management by pr actitioners), project reporting and status meetings are held in a more informal atmosphere by New Zealand organisations. 5. The Indian organisation uses international accreditations as proof of using disciplined processes and feels they are necessary to manage processes across international boundaries. These certifications are also considered by them to enhance their reputation in the international market. The larger New Zealand organisation initially had ISO accreditations which had now lapsed, and do not consider such international accreditations important or to add value to their processes or reputation. 6. The Indian company emphasise extensive usage of documentation, prior domain experience of developers, formal meetings with the clients, a centralised test case repository, and the use of standardised templates for project management. On the other hand, cases selected from New Zeal and organisations have less rigid or sometimes no practices defined for certain processes. Also, one New Zealand organisation initially had considered documentation a core activity, but later dropped this practice. 7. The small organisation (Pilot-NZ-Small) have fixed contracts only, while the two larger organisations (belonging to New Zealand and India) have both fixed and time and material contracts. Thus risk taking for any future contingencies is felt more in the smaller organisation. However, the Indian organisations have penalty clauses attached to their fixed contracts, and so are also at a considerably high risk. 134 8. The attrition rate is much higher in the Indian organisation, and accordingly more emphasis is given to documentation and other formal methodologies, as compared to New Zealand firms. 4.7 Systematic combining of literature and empirical findings The study used systematic combining for development of a conceptual framework, by moving back and forth between theory and the empirical world (Dubois & Gadde, 2002) The empirical language has been maintained rather than use of theoretical language, during systematic combining, as the conceptual framework evolves and is both a “ tool as well as a product” (p. 558). The key influences on building relationships and sharing knowledge across distributed software development have been examined from the vendors’ perspectives. Next, the empirical findings from pilot cases have been discussed with key government personnel in NZTE and NASSCOM. This helped in sensitising the drivers along two dimensions of organisational knowledge – tacit and explicit knowledge. Interviews with officials from NZTE helped to identify software development as a mix of formal and informal processes to capture ideas and manage the related knowledge. The government personnel commented: “ Software development is not a clay model which can be cemented by fixed processes, and neither is it a primary produce like dairy products are. It consists of ideas which grow and so they require flexibility to adapt. Unfortunately, organisations today are either pure play with no processes or too rigid with too many certified processes. We just need some good processes which are a combination of both”. This research study is based upon contemporary issues, and uses practitioners’ perspectives on knowledge structures as a guide to identify relevant categories in the offshore software development process. Although much has been written about the importance of knowledge, “little attention has been paid to how knowledge is created and how the knowledge creation process is managed” (Takeuchi & Nonaka, 2002, p. 135 142). Utilising published literature and empirical findings, the categories for knowledge management have been identified in this study along two dimensions: tacit knowledge and explicit knowledge. Each category has been analysed for key success drivers by moving ‘back and forth’ between theory and observed empirical phenomena of the vendors’ knowledge management processes. Thus the preliminary analytical framework evolved through data analysis and interpretation as empirical observations resulted in new searches for theoretical constructs, leading to refinement of research questions, formation of a conceptual framework and finally in the identification of units of analysis for the main study. The main research question is: How do vendor organisations use knowledge sharing processes in the software development environment within a glocal society? This question is influenced by the following subsidiary questions: 1. What processes do vendor organisations c onsider important for transfer of tacit knowledge in the offshore software development environment? 2. How do vendors manage distributed knowledge-based processes within the software development environment? 3. How does culture affect vendors’ relationship building strategies with offshore clients or partners in the virtual environment across organisations and nations? Miles and Huberman (1994) state that clear definition of the research question and conceptual framework leads to quick identification of categories or types, and thence the unit of analysis of the study. Yin (2003, p. 24) agrees that “selection of the appropriate unit of analysis will occur when you accurately specify your primary research question”. The proposed conceptual framework is divided into three layers of analysis: national, organisational and individual. The key success drivers (or unit of analysis) are further 136 categorised in each layer leading to “embedded units of analysis” (Yin, 2003) for the three levels (refer Table 15). The highest layer (or macro level) of analysis explores organisations sharing a common country culture i.e. New Zealand and India in the context of this study. It aims to give a holistic view of vendors’ practices across two country contexts. The second layer (or meso level) of analysis explores the organisations as a whole to understand their knowledge sharing strategies in the offshore software development environment. Organisational dimensions related to organisation’s size, cultural mix of employees and types of contracts organisations enter into have been identified at the meso level. Though organisations use ICTs (i.e. emails, bulletin boards, portals, document management systems) to collaborate across each other’s boundaries for knowledge sharing, this study does not consider technology at an organisational level construct. Rather, it looks at ICT related pr actices at the micro level to understand the technological solutions used for supporting knowledge management through integration of distributed knowledge components (tacit and explicit) and for building of relationships across organisational boundaries. The third layer (or micro level) of analysis investigates the practices associated with the key drivers identified from the literature (re fer Table 8). Further, the analysis of the multifaceted data from the three pilot studies utilised existing theories in knowledge management (i.e. the SECI model) and resulted in the formalisation of a conceptual framework. The SECI model has been used to analyse the continuous interplay between acquiring local or tacit knowledge, and applying the knowledge acquired into the design of the client-specific software builds, resulting in re- definition of previously defined best practices as new processes are applied and new outcomes realised. Accordingly, the third layer of analysis has been divided into three sections namely, transfer of tacit knowledge, management of explicit knowledge and relationship building strategies. The conceptual framework identified from theory and empirical evidence is presented in Table 27. The framework identifies three levels of unit of analysis in a three cell 137 matrix structure or “embedded case design” (Yin, 2003). Miles and Huberman (1994) add that the unit of analysis can be quickly derived if there is clarity between the research questions and identified conceptual framework. Table 27 also links the conceptual framework with the research questions to bring more focus on the interrelatedness of the research elements (unit of analysis at micro, meso and macro level) with the research questions. Table 27 Conceptual framework for key success drivers Level 1 – National level ( New Zealand and India) Level 2 - Organisational level 1. Organisation size 2. Cultural mix of employees 3. Types of contracts Main research question How do vendor organisations use knowledge sharing processes in the offshore software development environment within a glocal society? Level 3 - Individual level Subsidiary research questions Transfer of tacit knowledge ƒ Communication ƒ Domain skills ƒ Requirement Volatility RQ1. What processes do vendors consider important for transfer of tacit knowledge in the offshore software development environment? Management of explicit knowledge ƒ Quality process management ƒ Software project management ƒ Staff attrition management RQ2. How do vendors manage distributed knowledge-based processes within the software development environment? M ac ro l ev el M es o le ve l M ic ro l ev el Relationship building strategies ƒ Cross cultural interaction ƒ Reputation ƒ Visibility of work processes RQ3. How does culture affect vendors’ relationship building strategies with offshore clients / partners in the virtual environment? 4.8 Conclusions This study utilises systematic combining, as drivers identified in the literature are combined with findings from the empirical world. The study further identifies a conceptual framework, and has both a strong theoretical and practitioner perspective. The success drivers identified from literature and empirical findings have been divided into three levels of analysis based upon how practitioners break up the complexity of operations in the OSD process. The next chapter describes the ten cases and the interview settings for the main study. The conceptual framework has been used to guide the research process in a 138 cumulative manner along the three levels of analysis. Chapters six, seven and eight have applied the conceptual framework at the micro level of analysis to answer the three subsidiary research questions. Chapter nine uses the findings from micro-level analysis of ten vendor case studies to analyse the meso and macro levels for answering the main research question. Dubois and Gadde (2002) identify two types of data – ‘passive’ and ‘active’ – used in a research process. Passive data is used for an exploratory study, which has no predetermined objectives and involves an active researcher to search for new findings. The pilot study involved an exploration of the OSD environment. Accordingly, the pilot study has used ‘passive’ data and an active research approach as the researcher conducted unstructured interviews to identify scope and unit of analysis for the main study. The search culminated in the identification of the conceptual framework for the main study. The conceptual framework has been used as a guide for the main study, and has given the researcher a more informed view than the initial exploratory phase. The main study involves semi structured questions and utilises ‘active data’ which is aligned with the conceptual framework. However, flexibility to new data has been maintained in the main study and the research approach is open to additional interpretations, where the conceptual framework is both a “ tool as well as a product” in the systematic combining process (p. 558) The thesis now proceeds to examine ten vendor cases for the main study settings by utilising the conceptual framework identified in this chapter (Table 27). 139 CHAPTER FIVE – The Case Studies 5.1 Introduction In evaluating multiple case studies in a research study, parsimony or being selective in describing each case and in reporting key findings is essential to bring a clear understanding of the research process. This chapter presents the format of the multi- case report used for describing the ten cases participating in this study and for synthesising the key findings. The purpose of the multi-case report is not to portray any single vendor case, but to synthesise lessons learnt from all ten vendor organisations on their knowledge sharing processes. The study involves a three level embedded case design in which each vendor case is investigated at micro, meso and macro level to explain vendor strategies fo r knowledge conversion and assimilation in the offshore software development environment. This chapter begins with the proposed format for the embedded case investigation. Next a brief description of each case study or vendor organisation participating in this research is presented. This is followed by an overview of the interview settings and functional groupings of the participants interviewed. The outsourcing arrangements entered into by the vendors with offshore groups are presented to give a broader view of the vendors’ offshore business commitments. The empirical data for the macro and meso level analysis for the ten vendor cases is presented to give a holistic picture of the vendor groups across two country contexts. This chapter lays the foundation for the three strategy groups in the micro-level analysis – transfer of tacit knowledge, management of explicit knowledge and relationship building strategies – which is described in detail in Chapters six, seven and eight. 5.2 Case report format This research uses multiple case research design, where each case plays an equal role to answer the research questions. In multiple case studies; “it is important to show the 140 reader that all of the single cases have been treated fairly and that the cross-case conclusions have not been biased by undue attention to one or few of the entire arrays of cases” (Yin 1994 p. 150). Each case has thus to be presented with equal emphasis to yield an understanding of their role and contribution to the reader. Scholz and Tietje (2002) describe four ba sic formats for case study reports: highly structured cases, short vignettes, unstructured cases and groundbreaking cases. Highly structured cases are written in a condensed mathematical textbook format, short vignettes are “well structured, have little excess information, and covers just a few pages”, unstructured cases are complex cases whereby situational contexts are necessary to bring some understanding of the case, and groundbreaking cases are “totally new, and little, if any knowledge exists” (p. 13). Yin (2003) suggests using Herbert Kaufman’ s (1981) report style for writing of multi case study report. Kaufman’s report is based upon six federal bureau chiefs, where Kaufman does not portray each case as a single case study; rather he synthesises lessons organised around identified topics from all six cases. In using this type of multi case report, Yin (2003) suggests that each individual case should simply serve as an evidentiary base for the study, and be presented in brief vignettes, rather than present the individual cases as chapters in the final manuscript. In such a report format, “each chapter or section is devoted to a separate cross-case issue, and the information from the individual cases would be dispersed throughout each section” (Yin 2003, p. 148). The format of this case report follows Sc holz et al.’s and Yin’s recommendations and describes each individual case in vignettes. Brevity is preferred to describe each individual case, as the inquiry focuses on several subunits or key drivers of each case, also called an embedded case design. Within the embedded case design method, the report organises data from diverse sources (such as study participants, vendors’ websites and whitepapers) into categories to make generalisations for each identified criterion of analysis (refer Chapters six, seven and eight). Next, cross case comparisons are made, as the three level cell design proceeds to the higher levels of analysis involving the organisational and national levels (refer Chapter nine). 141 5.3 Case vignettes The five New Zealand and five Indian cases are briefly described in the following subsections. Each vendor has been disguised with use of pseudonyms (i.e. NZ1, NZ2, NZ3, NZ4, NZ5, IN1, IN2, IN3, IN4 and IN5) to conceal their identity. 5.3.1 NZ1 NZ1 is a leading New Zealand IT service provider established in 1992. The company has offices in Auckland and Wellington, and had 180 employees at the time of the interview. However, at the time of interview, NZ1 was in the process of restructuring, having recently formed a strategic partnership with a large Indian software technology company, which has offices in over 53 countries worldwide. The Indian partner of NZ1 will hereby be referred as PartnerNZ1 in this research study. The partnership with PartnerNZ1 gave NZ1 the opportun ity to maintain representation in New Zealand with the benefits of resource scalability and offshore capability. The capabilities of NZ1 span analysis, design, development, implementation, security and support across their three core service lines: software services, technology services and managed services. 5.3.2 NZ2 NZ2 has been a leading provider of solutions to primary healthcare professionals in New Zealand since 1980. They have opened another division in Australia, and have offices in Auckland, Melbourne, Sydney and Perth. NZ2 had previously engaged Pilot-IN-Med as their vendor. However, now they prefer to have their own offshore development centre in Chennai, India over which they have 10% ownership stake. Their offshore partner at Chennai will be hereby referred as PartnerNZ2. PartnerNZ2 has about 50 developers, while NZ2 have about 100 employees based in Auckland. NZ2 have approximately 16,000 users belonging to various medical health sectors in Australasia. The capabilities of NZ2 include sophisticated connectivity to government 142 and third-party organisations such as laboratories and claims offices, robust networks for information exchange and communications, health assessment and management tools, and geo-coding for demographic information, amongst others. 5.3.3 NZ3 NZ3 is one of the leading IT service providers based in New Zealand, and was started by a group of four friends during the last year of their university study in 1993. In 2005, they set up another development centre in Vietnam which is a wholly owned subsidiary of NZ3. The offshore development centre at Vietnam will hereafter be referred as PartnerNZ3 in this study. NZ3 have approximately 20 developers located in New Zealand and 10 developers located in Vietnam. The two centres collaborate for all development projects by utilising the time difference between the two locations, such that software developed in one country can be tested after hours in the other country. NZ3 specialises in developing software applications and providing consulting and implementation services, such as data warehousing, client server and n-tier environments, web based applications for various business functions in banking, insurance, transport, manufacturing and health care industries. They also offer “not- for-profit” software products to various social groups and trusts for the elderly and disabled. NZ3 are well known for their ingenuity in technology and have won excellence awards for their innovative software products in the SME sector. 5.3.4 NZ4 NZ4 has been a global leader in telecommunication technology applications since 2000, and have their main development centre in Auckland. They have sales and operations offices in New York, Los Angeles, Chicago, Shanghai, Hong Kong and Hyderabad. NZ4 previously had some offshore experience with an Indian vendor (Pilot-IN-Med) based in Auckland. However, they soon realised the cost benefits of opening their own software development centre in India. In 2005, they opened an offshore software development centre in Hyderabad, India which is partially owned by NZ4 to work jointly on client projects with their development centre in Auckland. 143 NZ4’s major client is a large and well known US agency, which has a marketing office in Auckland. NZ4 offers world class interactive mobile marketing solutions and provides connectivity between people and brands and has won several major mobile and marketing awards worldwide. They create, execute and analyse long-term interactive mobile strategies for brands and agencies, and have a vast international clientele and partnerships with many service providers for deployment of their mobile applications. 5.3.5 NZ5 NZ5 is a specialised provider in customer relationship management (CRM) applications and is based in Auckland, New Zealand with about 30 employees. NZ5 are the only software partner within New Zealand for a global CRM software provider, and benefit from their partner’s many sales channels across Europe. Their partner will hereby be referred as PartnerNZ5 in this research study. NZ5 have done many customisations for PartnerNZ5’s clients in Australia, the United Kingdom, Belgium, Singapore, the United States and New Zealand. They have expertise in certain specialised software tools and packages, and offer services remotely to clients in Europe and Australia for CRM customisations. 5.3.6 IN1 IN1 is ranked in the top ten global offshore outsourcing providers in India. They have headquarters in Pune, India, and also have software development centres in China and Poland. IN1 has over 4100 employees, with 1500 employees in India. They are CMMI 7 level 5 and ISO/IEC 27001:2005 8 certified, and have won many awards from 7 CMMI (Capability Maturity Model Integration) is a guide to process improvement across a project, a division, or an entire organization. It helps integr ate traditionally separate organizational functions, set process improvement goals and priorities, provide guida nce for quality processes, and provide a point of reference for appraising current processes. The highest level to be achieved in CMMI is 5. This model is certified by Carnegie Mellon® Software Engineering Institute (SEI). 8 ISO/IEC 27001:2 0 0 5 is a part of the ISO/IEC standards, to define the code of practice for Information Security Management, which lists security control objectives and recommends a range of specific security controls. It is administered by accredit ation and certification bodies such as International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). 144 the Indian government, CNBC, Fortune magazines and other outsourcing groups for their work in the field of software development. IN1 has expertise in key verticals of manufacturing, retail, logistics, financial services, telecom utilities, education media and entertainment. Besides, offering technology solutions worldwide, IN1 have also undertaken several philanthropic initiatives in the state of Maharashtra in India, for which they have been presented awards by the state government of Maharashtra. 5.3.7 IN2 IN2 is a subsidiary of a major business conglomerate group in India since 1945. It is a global engineering outsourcing centre for developing automotive design and systems, and has two development centres in Pune, India. They have recently opened another development centre in Thailand. The customers of IN2 include the world's premier automotive, aerospace and consumer durable ma nufacturers, such as General Electric, General Motors, Ford, Boeing, 3M, Apple and many more. IN2 also has many quality certifications such as ISO 9001:2000 9 quality certification, People Capability Maturity Model (PCMM) 10 level 5, CMMI level 5 and BS7799 1 1 . IN2’s services include product design, analysis and production engineering, product lifecycle management, enterprise resource planning and customer relationship management systems. 9 ISO 9001:200 0 specifies requirements for a quality management system where an organization needs to demonstrate its ability to consistently provide products that meet customer and applicable regulatory requirements, and aims to enhance continual improvement of the processes with the assurance of conformity to customer and applicable regulatory requirements. This is administered by accreditation through the International Organization for Standardization (ISO) certification body. 10 People Capability Maturity Model (People CMM) is a maturity framework that focuses on continuously improving the management and development of the human assets of an organization. This model is administered by accreditation by Carnegie Mellon® Software Engineering Institute (SEI). The highest level in PCMMI that can be achieved is 5. 11 BS 7799 is issued by the British Standards Institute (BSI). It was renamed ISO/IEC 27002 in July 2007 after it was adopted by the ISO. It focuses on how to implement an Information security management system (ISMS), and refers to the information security management structure and controls within organizations. 145 IN2 have recently provided a computer aided design online learning tool to connect software engineers to network, share ideas and contribute to blogs and forums, across the world. Moreover, IN2 ha ve undertaken development of many remote villages in India since its independence in 1947, and are a well recognised name in India for their philanthropic work. 5.3.8 IN3 IN3 is a software and services provider with approximately 200 employees located in Pune, India since 1997. They also have a sales office in California, in the United States. IN3 offers web enabled application integration solutions for finance, media, insurance and retail industry. They have recently completed a major project for a major computer manufacturer in Canada and the United States, by linking their 8,000 retail offices across North America. They are presently working on other similar projects with the same client, and also with new clients. 5.3.9 IN4 IN4 is a software solution provider located in Pune, India. It was founded in 1999 by a vendor organisation located in Toronto, Canada. However, IN4 is a wholly owned subsidiary, and has its head office in Toronto. IN4 have done many projects for their parent group in North America and Canada. Recently their parent group at Toronto have opened another software development centre in Bangalore. During the time of the interviews, IN4 had about 100 employees in Pune, 80 employees in Bangalore and 20 employees in Toronto. IN4 specialises in broadband, telecom, health and the retail sector. They have undertaken software development projects for several Fortune 500 companies. 146 5.3.10 IN5 IN5 was established as a wholly owned subsidiary in Pune, India of an offshore vendor organisation located in Minneapolis, Minnesota. The parent group of IN5 have many patents related to revenue management algorithms. The headquarters of IN5 is at Minneapolis, which also has another smaller development centre. However their main software development centre is based in Pune, India, which houses 50 software developers and 30 service staff. The capabilities of IN5 include revenue optimisation solutions for airlines, automotive rental, freight transportation and hotel companies worldwide. IN5 have also completed many projects for large hotel groups, casinos and budget sector groups in United States and Europe. 5.4 Interview settings Multiple interviews were conducted across the ten vendor organisations from December 2005 to October 2007. It is not possible to give the exact number of interviews conducted, as the researcher had sometimes spent the whole day at the vendor sites. The interviews also involved casual conversation with many members of the software development teams when they explained their working processes. The aim of these interviews was to gain rich insight into how practitioners extend their knowledge base in the distributed software development project environments. An observation made during the interviews was that New Zealand vendors preferred to explain their work practices in formal meeting rooms, and did not show the researcher document artefacts or software tools used by them. On the other hand, interviews with the Indian vendors were often held in the small office cubicles belonging to the individual developers, and hence project documents and related organisational artefacts were shown to the researcher. Therefore more rich insights on vendor practices for knowledge sharing could be gained by the Indian teams, as they were more forthcoming with physical evidence than the New Zealand teams. 147 Interview participants spanned vertical levels and functional groupings, including managing directors (MD); directors; chief executive officers (CEO); chief technology officers (CTO); chief operations officers (COO); general managers (GM), project managers; developers responsible for ongoing projects; and also members from quality assurance and human resources departments. Table 28 describes the interview settings for the ten organisations. The table also describes the functional levels of the interviewees, their head office locations and the dates of the interviews. Table 28 Interview settings for the main study Vendor Location of head office Total employees (approximate)* Functional levels interviewed Interview dates NZ1 Wellington, New Zealand 180 General manager, project manager and developers August 2006 August 2007 NZ2 Auckland, New Zealand 100 Managing director, project leader and developers September 200 6 October 2007 NZ3 Auckland, New Zealand 20 Director and developers November 2006 July 2007 NZ4 Auckland, New Zealand 40 Project leader and developers October 2006 September 200 7 NZ5 Auckland, New Zealand 30 Managing director and developers November 2006 January 2007 IN1 Pune, India 1500 Senior project manager, developers and human resource personnel December 2005 January 2007 IN2 Pune, India 1800 Chief technology officer, project managers, developers and quality team January 2006 January 2007 IN3 Pacifica, California 200 Chief executive officer, senior manager and developers February 2006 December 2006 IN4 Toronto, Canada 100 Chief operations officer, project manager, developers and human resources personnel January 2006 December 2006 IN5 Minneapolis, Minnesota 90 Chief executive officer, project manager and developers December 2005 January 2007 * The employee count is considered only at ve ndor locations where interviews were conducted Semi structured interview questions were used to capture the respondents’ voices when they described their knowledge sharing processes used across distributed geographical locations. 5.5 Outsourcing arrangements This section describes the outsourcing arrangements of the ten participating organisations. The different outsourcing arrangements have already been explained in 148 Chapter two (refer section 2.2.2.1). Drawing directly upon Dibbern et al.’s (2004) descriptions of outsourcing arrangements which is based upon two parameters, namely, degree of outsourcing (i.e. total or selective) and ownership (i.e. internal, partial or external), the Table 29 describe the specifics of outsourcing arrangements for each of the participating vendor. Table 29 Outsourcing arrangements for the vendor cases Ownership Degree of outsourcing Internal Partial External Total Traditional IN1, IN2, NZ2, NZ3 and NZ4 Selective Spin-offs/ Wholly owned subsidiary IN3, IN4 and IN5 (PartnerNZ3) Joint venture (PartnerNZ2 and PartnerNZ4) Selective NZ1 and NZ5 The above table shows four outsourcing arrangements: spin-offs or wholly owned subsidiaries, joint ventures, traditional and selective sourcing arrangements. These four arrangements are now explained in the context of the ten vendor cases participating in the study. a. Spin-offs (wholly owned subsidiary) – IN3, IN4 and IN5 are wholly owned subsidiaries, with offshore parent groups located in the US and Canada. It may also be noted that NZ3 have opened a wholly owned subsidiary in Vietnam (i.e. PartnerNZ3) and is a parent group. b. Joint ventures – NZ2 and NZ3 have started joint venture outsourcing arrangements with offshore vendor groups in India (PartnerNZ2 and PartnerNZ4). c. Traditional – IN1, IN2, NZ2, NZ3 and NZ4 have no external ownership by offshore parent groups, and are involved in traditional outsourcing arrangements. d. Selective – NZ1 has selectively outsourced some work to another vendor in India (i.e. Partner NZ1) while NZ5 gets modular contracts from their global CRM partner (i.e. PartnerNZ5). 149 5.6 Embedded case design The case study presented is an empirical inquiry that investigates a contemporary phenomenon within its real-life context. As discussed in the conceptual framework (refer Table 27), this research employs an embedded case design for analysing the knowledge sharing processes in the OSD environment. The three levels are as follow: Micro level: Individual level (i.e. key success drivers) Meso level: Organisational level (i.e. vendor case organisations) Macro level: National level (i.e. common country groups) Using the conceptual framework which is informed by literature and practice, the micro-level analysis has framed the key success drivers into three strategy groups namely transfer of tacit knowledge, management of explicit knowledge and relationship building strategies, which are presented in Chapters six, seven and eight. The analysis also uses the SECI model and ST to assist in making sense of vendor (agent) perspectives on organisational structures to identify key practices for sharing knowledge through processes of socialisation, externalisation, combination and internalisation. The micro level analysis involved comparisons of theory with empirical evidence by disseminating the empirical field data and re-contextualising the data for each of the identified key success drivers for making TE generalisability. In the early stage of data analysis, the study identified some nodes or ideas relating to vendors’ working practices and captured text relating to these nodes without forcing them into some structure. These nodes were marked as free nodes in the software tool Nvivo. Later some of the free nodes merged into structural compositions or sub groups as common themes emerged with associations between the free nodes, while some of the free nodes were discarded when further analysis revealed that some of the early ideas did not match with the subsequent data. Several re-visits to the subgroups helped in further refining and alignment of the nodes along the identified units of analysis in relation to the research questions. 150 The meso level analysis involved cross case comparisons for making ‘analytical generalisations” as empirical statements (inputs to generalisation) informed other empirical statements (outputs of generalisations) to make EE generalisations (Lee & Baskerville, 2003; Yin, 2003). Finally aggregations of meso level analysis are presented across the two country contexts (or macro level) to offer new insights on their offshore software development environment. The next section presents empirical data on organisational or meso level dimensions – organisation size, cultural mix of employees and types of offshore contracts – for the ten vendor organizations. 5.7 Organisational or meso level dimensions The second level of the conceptual framework (refer Table 27) identifies three organisational dimensions, namely organisation size, cultural mix of employees at local vendor offices and the types of software development contracts. Table 30 summarises the fieldwork data for these th ree dimensions into two sections based upon organisations which share a common country culture (i.e. New Zealand and India). Table 30 Organisational level field data New Zealand Dimension NZ1 NZ2 NZ3 NZ4 NZ5 Organisation size* 180 100 20 40 30 Multi –cultural teams Yes Yes Yes Yes No Types of contracts 1 – Time and Material 2 – Fixed 1 and 2 1 and 2 1 and 2 2 2 India Dimension IN1 IN2 IN3 IN4 IN5 Organisation size* 1500 1800 200 100 90 Multi –cultural teams No No No No No Types of contracts 1 – Time and Material 2 – Fixed 1 and 2 1 and 2 2 2 2 * approximate size during the time of the interviews 151 The following subsections discuss each organisational dimension for the ten vendors to identify vendor groups which may be compared based upon some underlying similarities and differences. 5.7.1 Organisational size This study does not label the vendors as large, medium or small organisations as ….there is no universally used definition of a SME 12 . Internationally, firm size is measured in a variety of ways including by numbers of employees, sales figures assets and industrial classification. However, the diverse structures of economies makes adherence to a single statistical definition unworkable. International comparisons of SME demographics and performance are also difficult to make because of the different methods central statistical agencies use to collect and publish firm-level data. However most countries use an employment measure to define SMEs (Ministry of Economic Development, 2008, p. 50). This was also explained by a government official of NZTE during one of the interviews. The official explained that “the average size of a company is between 5 and 20 in New Zealand. 80% of SME companies in New Zealand have 2 to 20 employees whereas in US, SME means 100 to 400”. Therefore there is no absolute number to define different sectors of organisations across nations, as “the diverse structures of economies makes adherence to a single statistical definition unworkable” (Ministry of Economic Development, 2008, p. 50) The variation in the number of employees for each of the vendor organisations (refer Table 30) has a wide range in the two country contexts. In view of the diverse structures of economies between New Zealand and India, the comparisons between vendor groups belonging to these nations cannot be made against one absolute number of employment measure (Confederation of Indian Industry, 2007; Ministry of 12 Small to medium enterprise 152 Economic Development, 2008). Based on the empirical data, the vendor organisations have been divided by their sizes into three categories in Table 31. Table 31 Vendor categories based upon organisational size Organisation size New Zealand organisations Indian organisations > = 1000 employees IN1 and IN2 (Large) > = 90 employees NZ1 and NZ2 (Large) IN3, IN4 and IN5 (SME) > = 20 employees NZ3, NZ4 and NZ5 (SME) The vendors belonging to different countries have been categorised separately. In the New Zealand context, organisations having employees over 90 have been categorised as large, while organisations having employees less than 90 but more than 20 are categorised as SME. Similarly in the Indian context, organisations having more than 1000 employees are categorised as large, while organisations having less than 1000 but more than 90 are categorised as SME. 5.7.2 Multi cultural Each vendor was queried to understand whether employees belonging to different cultural groups were employed in the main software development centre where the researcher was conducting the interviews. Though each vendor was involved with offshore groups of different nationalities, the study aimed to understand the diversity which existed at the main local development site of the organisations. This dimension is affected by the economic condition of the country and government policies on immigration rather than by organisational preference. New Zealand has a better economic position with an OECD 13 status and this encourages knowledge professionals from other cultures to migrate here. Also the immigration policy of the New Zealand government differs greatly from the Indian government’s immigration policy, as it is more open to inviting other cultural groups to be part of their country culture. 13 Organisation for Economic Cooperation and Development 153 Table 32 shows the cultural mix of employees in the vendor organisations at the local offices, where the interviews had taken place. Table 32 Vendor groups based upon cross cultural make up of employees Cultural make up New Zealand organisations Indian organisations Employees of different nationalities at the local development site of the vendor. NZ1, NZ2, NZ3 and NZ4 Employees of similar nationalities at the local development site of the vendor. NZ5 IN1, IN2, IN3, IN4 and IN5 Table 32 reveals that none of the Indian vendors have a multi-cultural group of employees at their local development centres in India. In contrast, four of the five New Zealand vendors employed diverse cultural groups in their New Zealand centres. This implies that the overall work environment of the New Zealand vendor organisations is more glocal with local understanding among individuals of other cultures’ customs and norms. 5.7.3 Types of contracts This study investigates the activities involved in knowledge exchange in the OSD environment, and considers contract type at the organisational level, rather than at the micro level of analysis which looks at individual drivers. The operational team of knowledge workers including project managers, developers and other team members have no role in the commercial side of the contractual agreement. The teams interviewed in the study were involved in the operational aspect of the project implementation and said they acted according to the commercial agreements of contracts as told to them by their senior management. The participants belonging to the senior management were questioned on the types of contracts they generally entered into, namely time and material (T&M), and fixed contracts. 154 Due to the confidential nature of offshore contractual agreements, the vendors’ management did not divulge much information on their contract details. Therefore not much information was sought on the contractual details of the vendors with their offshore clients or partners. The senior management of the vendor were simply asked about the type of contracts they mostly entered into with their offshore client or partner. These are shown in Table 33. Table 33 Types of contracts Contract types New Zealand organisations Indian organisations Time and material NZ1, NZ2 and NZ3 IN1 and IN2 Fixed NZ1, NZ2, NZ3, NZ4 and NZ 5 IN1, IN2, IN3, IN4 and IN5 The table data reveals that in both the countries the SME vendor organisations bears more risk than their clients with fixed contracts between them, while the larger vendor organisations are involved in risk sharing with clients, as they enter into both fixed and T&M contracts with clients. However the exception is NZ3 who is the only SME vendor involved in risk sharing with their offshore clients, and enters into T&M contracts. 5.8 Vendor groups Based upon the empirical data for the organisational dimensions in the previous section, this study has identified two vendor groups i.e. group A and group B, for making comparisons. The two groups are presented in Table 34. Table 34 Vendor groups Group A vendors – Large Group B vendors - SME Dimension NZ1 NZ2 IN1 IN2 NZ3 NZ4 NZ5 IN3 IN4 IN5 Organisation size* 180 100 1500 1800 20 40 30 200 100 90 Multi –cultural teams in local site offices Yes Yes No No Yes Yes No No No No Types of contracts 1 – Time and Material 2 – Fixed 1 & 2 1 & 2 1 & 2 1 & 2 1 & 2 2 2 2 2 2 * approximate size during the time of the interviews 155 The above table categorises the larger vendors of both countries (i.e. NZ1, NZ2, IN1 and IN2) in group A. Similarly, the six SME vendors belonging to both countries (i.e. .NZ3, NZ4, NZ5, IN3, IN4 and IN5) are in group B. The table shows that all of the vendors belonging to group A enter into both types of contracts, namely fixed contracts and T&M contracts. Thus group A vendors are involved more in risk sharing with their offshore clients. However in group B, with the exception of vendor NZ3, the remaining five vendors managed only fixed contracts and had to bear the major part of the risk in the contract. This section has laid the platform for cross case comparisons to be performed between the two vendor groups – group A and group B – at the second level of analysis (i.e. meso level). 5.9 Chapter summary This chapter has described each of the participating case studies briefly. It also described the interview settings to enable the reader to understand the interview environment. After some basic knowledge about the ten case studies is given, the embedded case design utilised in this study has been described. The study has adopted a theoretical and practical perspective to make generalisations for knowledge sharing strategies in the OSD environment. Further, descriptions on organisational dimensions namely organisation size, cultural mix of employees at local vendor offices and the types of software development contracts have been provided. This has helped in identifying two vendor groups for cross case comparisons to be performed at the higher levels of analysis The chapter has described the background of the participants and the criterion upon which the data analysis will take place. On these guidelines, the thesis proceeds to analyse the empirical findings from the ten case studies. 156 CHAPTER SIX – Micro Level Analysis for Transfer of Tacit Knowledge 6.1 Introduction The integration of dispersed and interrelated knowledge across inter-organisational and inter-cultural boundaries is a major challenge for vendors in building software applications. Software vendors have to interpret tacit and explicit knowledge across diverse cultural domains for developing their technical knowledge and enhancing their skill sets. Tacit knowledge is shared among the local community, as members engage in conversation and make sense of their environment. Members (or agents) belonging to the same social structures inform each other of the local knowledge through socialisation and externalisation, as knowledge is shared and added into the organisational knowledge base. However in distributed software development environment where different social structures exist, the concept of ‘local’ has different meanings to the geographically dispersed team members. Thus, in the absence of co-location team members cannot interact directly, and offshore vendors have to utilise different approaches to enable the transfer of tacit knowledge. This chapter presents the micro-level analysis of drivers identified for the transfer of tacit knowledge to understand vendors’ strategies for knowledge sharing (refer Table 27). Vendor strategies are examined to answer the first subsidiary research question: What processes do vendor organisations consider important for transfer of tacit knowledge in the offshore software development environment? The SECI model is used to examine how team members make use of their knowledge assets to gain tacit understanding of software development activities in a distributed software development environment. The drivers affecting the transfer of tacit knowledge which have been identified as the unit of analysis in the conceptual framework are investigated for understanding how socialisation and externalisation processes are defined for creation of organisational knowledge. Vendor experiences 157 are described as work practices associated with each identified driver are presented. Structuration theory has been used to understand vendor (agent) experiences for transfer of knowledge in the glocal envi ronment where various social, cultural and technical structures are combined. The chapter concludes with a summary of practices associated with the identified drivers (or units of analysis) for the transfer of tacit knowledge to give deeper insights into the non documented aspects of knowledge sharing in software projects. 6.2 Knowledge assets: tacit and explicit knowledge A defining aspect of distributed software development involves understanding how knowledge is exchanged across multiple locati ons, and its integration into a coherent solution, which is aligned to the customer’s needs. The knowledge exchange involves understanding of tacit knowledge, and its subsequent articulation into explicit knowledge, which is then captured into the organisational knowledge repository. Tacit knowledge resides with individuals as they observe and learn from their past experiences, and is transferred to other team members through conversations. In contrast, explicit knowledge deals with codified knowledge that is documented and is in the domain of the structural capital (Srikantiah, 2004). Knowledge professionals have to generate abstractions from the tacit knowledge gathered from disparate sources into its organisational knowledge domain to achieve shared goals. This means that tacit knowledge obtained from various team members needs to be first transferred and later disseminated into explicitly defined task processes at distributed locations. Thus to extend their knowledge bases, organisations promote work structures which encourage knowledge sharing by team members, such as imparting training, offering rewards for individual accomplishments and other incentives for sharing of expertise and insights. Previous literature has identified both tacit and explicit knowledge as vital to extending the organisational knowledge capital base (Choo, 2006; King & Torkzadeh, 2008; Nonaka & Takeuchi, 1995; Nonaka et al., 2001). Organisations create their knowledge capital by organising explicit knowledge (both external and internal), 158 capturing tacit knowledge (people skills, ideas, insights, relevant experiences and motivation) (Srikantiah, 2004), and integrating them into their organisational knowledge domain. Such knowledge domains evolve, as organisations (in this case offshore software vendor organisations) lear n and apply insights gathered from new project experiences, which are mandated into their working practices. Knowledge assets are thus framed into organisational structures and these give new social meanings, as agents discuss, interpret, evaluate and disseminate the knowledge in new projects. The virtual environment also involves the use of technology tools to describe the social and semantic content across the distributed sites when team members at dispersed locations try to make sense of the evolving knowledge assets. 6.3 Drivers for transfer of tacit knowledge This section recapitulates previous literature and provides a summary before moving into the empirical work to set the micro-level analysis in context. In a distributed environment, team members do not work side by side as they collaborate on a common project across different time zones. Consulting group McKinsey found in a global survey of knowledge management practice that more successful companies provide spaces within the organisation for personal collaboration (Kluge, Stein, & Licht, 2001). Such spaces result in socialisa tion leading to a culture of sharing of information among the team members through informal conversations. The informal working environment helps to sense insights, which are then reflected over by team members eventually leading to understanding of differences in working styles across diverse work groups. Offshore vendors too have realised that they need to foster knowledge creation by capturing tacit knowledge and then disseminating the expertise and experience into explicitly defined working practices. Thus tacit knowledge is realised through dialogue, which may be via direct F2F communication or over electronic social networks. Also, it is generally found that developers who have been working on the same problem within a project can exchange tacit knowledge by using Internet-based communication tools (Choo, 2006). The tacit knowledge thus gathered is made explicit via technology tools, such as th rough informal postings made on mailing lists 159 and discussion forums, or formally through organisational governance tools and documents in defined project workspaces. The drivers influencing the capture and delivery of tacit knowledge into the offshore vendor’s knowledge repository have been identified as F2F interactions between the vendor software development teams and also with the client teams, synchronous communication methods (e.g., telephone conversations, videoconferences and real time presentations), asynchronous methods (e.g., emails, blogs, discussion forums) and use of common meeting places (e.g., centralised vendor offices at offshore locations, deployment of employees at offshore client or partner sites, organisational portals). The conceptual framework (refer Table 27) has identified the key drivers or units of analysis considered important for transfer of tacit knowledge. The Table 35 expands the framework by giving a summary of practices associated for each identified driver which influences the transfer of tacit knowledge when virtual teams collaborate to build software solutions across distributed sites. 160 Table 35 Practices for drivers affecting transfer of tacit knowledge Drivers (unit of analysis) Practices associated with the drivers Communication strategies Face-to-Face communication ⎯ between team members belonging to similar/ diverse cultures ⎯ with senior/middle management level team members Through technology tools ⎯ Asynchronous tools (e.g. emails, discussion forums/ blogs) ⎯ Synchronous tools (e.g. online chats, telephone and video conferencing) Common meeting places ⎯ Physical place (e.g. offshore offices, deployment of employees at offshore client sites) ⎯ Virtual place (e.g. organisational portal) Domain skills Preferences during recruitment ⎯ Project management skills ⎯ Technical skills Other practices to enhance learning ⎯ Training (e.g. in-house, hiring of consultants) ⎯ Incentives (e.g. rewards, variable component in pay) Requirement volatility management strategies Formal process Semi-formal process Informal process Table 35 underpins the following empirical work in which vendor experiences are described for each of the key drivers. The next section uses Table 35 to investigate vendors’ work practices for transfer of tacit knowledge in the OSD environment. 6.4 Empirical observations on the drivers for transfer of tacit knowledge The conceptual framework identifies three drivers (or units of analysis) for transfer of tacit knowledge. They are communication strategies, domain skills of development team members and strategies to manage requirement volatility or change management. This section is divided into three sub sections, where each subsection focuses on each driver identified in the conceptual framework to describe individual vendor work experiences for transfer of tacit knowledge. The interview data has been 161 contextualised and presented for each driver separately rather than presenting all the interview data as a complete case study document. Such a presentation gives a stronger sense of each independent category (or driver) (Richards, 2005). The language used to describe each driver across the ten organisations has been taken directly from the interview transcripts to convey the real life social settings of practitioners. Patton (2002) also suggests capturing the actual expression or local terms of participants to understand how participants break up the complexity of reality and this helps to identify attributes or nodes in the units of analysis. Each subsection concludes with a synthesis of key practices for transfer of tacit knowledge as the working practices of the ten vendor organisations are integrated to understand which processes are considered effective in transfer of knowledge in the distributed software development environment. 6.4.1 Communication strategies Effective communication is a challenge for virtual teams, “where F2F communication and impromptu meetings are infrequent, if not impossible” (Staples, Wong, & Cameron, 2004, p.176). Distributed softwa re teams use technology tools to communicate technical and design issues of related software tasks. Moreover, in OSD the interaction over technology tools involves diverse cultural groups from different social settings who may have never met each other. Thus for knowledge organisations to recognise the tacit nature of knowledge in different social environments, they need to have some strategies in place, so that all the team members can communicate and share a common frame of reference. Organisations have refocused their knowledge sharing strategies to include people and establishment of processes for managing and communicating shared perspectives across cross-cultural project teams (H ornett, 2004b). Organisations implement socialisation through collaborative technology tools to establish electronic social networks. Other methods used are face-to-face interactions, deployment of employees in organisations having different cultural and social settings, or having registered 162 offshore offices near client destinations. Once knowledge of diverse environments is gained, it is externalised into the organisational repository for future use in new projects. A summary of the communication strategies preferred by the ten cases is given in Table 36. Table 36 Practices for defining communication strategies Practices New Zealand organisations Indian organisations F2F interaction between vendor team and offshore clients/ partners ⎯ belonging to similar cultures only NZ2 and NZ4 IN3, IN4 and IN5 ⎯ irrespective of similar or diverse cultures NZ1 and NZ3 I N 1 and IN2 ⎯ involving senior management and middle level development team members NZ1 and NZ3 IN1, IN2 and IN3 (though IN3 does not use F2F as a regular practice) ⎯ involving senior management members only NZ4 and NZ5 IN4 and IN5 Through technological tools ⎯ asynchronous (e.g. emails, discussion forums, blogs) NZ1, NZ2, NZ3, NZ4 and NZ5 IN1, IN2, IN3, IN4 and IN5 ⎯ synchronous (e.g. online chats via skype, gmail, msn, conferencing tools) NZ1, NZ2, NZ3, NZ4 and NZ5 IN1, IN2, IN3, IN4 and IN5 Common meeting places ⎯ Physical place o offshore offices o deployment of employees at offshore client sites NZ1,NZ 2 , NZ3 and NZ4 NZ1 and NZ3 IN1 IN2, IN3, IN4 and IN5 IN1 and IN2 ⎯ Virtual place (e.g. organisational portal) NZ1, NZ2, NZ3, NZ4 and NZ5 IN1, IN2, IN3, IN4 and IN5 Next, the responses of the interviewees are synthesised, as each vendor case data is analysed in a separate sub section based upon their chosen communication strategies. The section concludes with a summary of the communication strategies used for exchange of tacit knowledge across the ten vendor cases. 163 6.4.1.1 Case data report on communication strategies Each vendor organisation was queried on their preferred communication patterns across distributed sites during the offshore software development process. NZ1 NZ1 is presently doing business for local clients in New Zealand. However in the past, they have done application development projects for international clients. Presently NZ1 and their Indian business partner (PartnerNZ1) are jointly developing software applications for New Zealand clients. Some developers from PartnerNZ1 have been allotted office spaces in NZ1’s premises, and are working along side NZ1 teams in their Auckland and Wellington centres. This enables both teams to meet on a common ground, share tacit work details and interact with the clients directly. NZ1 earlier interacted with the clients alone, but later realised that with such a practise, the responsibility of the project work was not shared equally between NZ1 and PartnerNZ1. The general manager of NZ1 commented: “Our next project for the client is a very large legacy application in Visual Basic 6, which has to be converted into the DotNet platform, but which has no documentation. So, we’ve given it to PartnerNZ1 to do that. They are directly interacting on the technical front. But we have our sales people and they are responsible for talking to clients on deliverables. So, the client has given the contract to us through our sales and we have PartnerNZ1 working on it. Even the project management is done by PartnerNZ1. It was our observation that unless we push some responsibility to PartnerNZ1, they would take no responsibility. I guess it was like they are being instructed on what to do, and we had to tell them. But now we tell them “This is your problem. Now deliver”. We have them sit down with the customer and understand what they are looking for. So now we find that directly meeting the customer seems like pushing the responsibility to PartnerNZ1 and this seems to be working very well. We are involved in overview of project and meet weekly with the client and PartnerNZ1 to check on satisfaction levels and progress levels”. 164 Thus NZ1 managers also interact with their clients to check if their requirements are being satisfactorily looked after by PartnerNZ1. Also having a common physical meeting place is considered as a means of bringing about shared responsibility and accountability. The project manager commented “The Indian developers now directly interact with the customers and get their requirements, rather than making it our job to talk to the customers. We write some use cases and early programs in our common architectural development framework, and then the Indian developers pick up. Some issues have cropped up in the past when the Indian developers did not ask questions openly. Now that they are here, they can interact directly with the clients, understand the work processes in more detail, and involve us if some further clarification is needed”. Moreover use of secure communication servers between the two development centres in New Zealand and India helps the teams to communicate informally over the network. Weekly formal reviews are undertaken with senior management and developers at both sites to check on the project progress. PartnerNZ1 uses extensive documentation (being internationally certified themselves), and these documents are later added to NZ1’s knowledge repository. Thus NZ1 considers F2F interaction between development team members, and also with the client as a key strategy for socialisation and externalisation for transfer of tacit knowledge. Deployment of their offshore partner’s employees at client sites is considered essential to gain deeper insight into the customer requirements and to bring about shared responsibility and accountability. The common meeting places involve use of physical location and virtual location via secure organisational portals. Moreover weekly review meetings are held, in which tacit knowledge is externalised in code and documents. NZ2 NZ2 works with an offshore Indian business partner (PartnerNZ2) for offshore software projects. NZ2 looks at the higher end of the interaction involving understanding customer needs and building relationships while PartnerNZ2 does 165 the “coding and linear tasks”. The MD commented: “key is communication with face-to-face contact, as people need to interact to form good relationships”. He also added “ Kiwis speaks Kiwi and Australians speak Australian. So it helps to use a local team because our customers are either Australians or Kiwis”. The NZ2 employees interact directly with the customer to gather requirements, which are then transferred onto a common server, so that the development centre in India can assess it. The project managers said that NZ2 used checklists and standard templates and have good configuration management practices in place, so that knowledge flow is smooth between the two centres. Organisation NZ2 prefers to use technology as a common meeting place between the development team members. They reasoned that since the low level tasks are sent offshore to India, there is no need for development team members of PartnerNZ2 to be in their New Zealand and Australian offices. The project manager said: “The project deadlines are set by us. So, all the progress reports are sent to us and we have a team in-house both in Australia and New Zealand”. Moreover, the confidential nature of their medical work content makes the management of NZ2 careful that PartnerNZ2 do not deal directly with their clients’ data. Accordingly, they have set up extensive dummy databases on their development test servers, which are used by PartnerNZ2, rather than using a common server for development (test) data and deployment (client) data. Thus organisation NZ2 uses direct F2F contact with the clients involving local team members but not their offshore development team members. Hence no offshore employees are deployed at client sites. Technology or a virtual platform is preferred as a meeting place between the development team members at distributed locations. Moreover, similarity of cultures is also considered essential to gain the trust of clients and to gain better understanding of the clients’ working practices. NZ3 NZ3 has two development centres, one in New Zealand and another in Vietnam. The director explained that the top management of NZ3 are themselves very 166 multicultural as the four owners or directors of NZ3 each belonged to a different nationality (Korean, German, New Zealander and Vietnamese). The Vietnamese director has set up a subsidiary in Vietnam, and NZ3 considers their offshore partner (PartnerNZ3) a core part of their team. The director of NZ3 said that both teams worked on the same project simultaneously, and they encouraged PartnerNZ3 to work directly for some of their New Zealand client’s sites. He explained a situation where, “one of our clients wanted three developers to work with them for three months. We could offer only two from here in New Zealand which we could pull out from our current team. So we suggested “How about a Vietnamese developer?” in case they had some issues and they said “Lovely”. So it’s been great in this respect that we are one big team of thirty developers and not like twenty of us and ten of them”. The team members in the two centres visit each other as and when required, and share a close relationship. The developers at both sites communicate daily with each other though freely available chat tools and emails. Organisation NZ3 prefers the use of organisational portal and deployment of employees at client sites as key to sharing of tacit knowledge. They have often deployed their developers for periods extending “eight to ten months” at offshore client sites in Australia, Malaysia, Singapore and the United Kingdom. These lengthy deployments of employees at client sites were preferred, because NZ3’s offshore clients were major banks who “did not like setting up a branch in New Zealand, and preferred NZ3 developers at their sites”. However for clients who do not hold sensitive data, NZ3 uses both virtual platforms (organisational portal) and physical locations (involving deployment of employees at client sites) as common meeting places. Meetings with offshore clients and offshore teams in Vietnam are done through a software tool “Go to Meeting”. Now, both teams and client log in during the sessions allotted and make presentations or hold open discussions as if they are all 167 sitting in the same room. NZ3 does not rely on too much documentation of work processes between their development sites. Hence NZ3 use F2F communication, and have regular interactions with clients and with their offshore development teams. They consider both virtual or technological platforms and physical locations as common meeting places. Employees are only deployed at client sites if specific requests are made by the clients. NZ4 NZ4 works on client projects jointly with their offshore partner PartnerNZ4. During the time of interviews, NZ4 had three onsite developers from PartnerNZ4 who had come on work visas to New Zealand. The developers from PartnerNZ4 were working in the IT support area which involved testing connectivity of gateways during the deployment of the client project, rather than interacting with the clients. NZ4 have many sales offices in different countries, which are used by clients to contact them for new projects. Direct interactions with the clients are done by the senior business analyst rather than the development teams. The project manager explained that the “work content is quite straight forward”, however the large volume of work meant that each developer would “quite often be involved in a dozen projects”. For this reason NZ4 have partnered with an offshore vendor. The client projects are quite small and generally last between five days to two weeks. However the project manager admitted that NZ4 do not have any standardisation and also do not use mature software configuration tools for development work between their two development centres. During the first half of each working day at the Auckland development centre, the developers make drawings based upon the client requirements and post the drawings on the organisational portal. The project manager said: “We draw our requirements, scan them and post the pdf on the test server”. Thus NZ4 uses the time difference to their advantage, as Pa rtnerNZ4 team logs into the portal at 2 168 p.m. (New Zealand time) after the drawings have been uploaded on the server. Video telephony tools (such as Skype) are used to explain or clarify the drawings, and this is termed as a “handover”. The developer said: “Handover is basically a phone conversation followed with a document”. Later in the evening (India time) much after NZ4’s office hours, the PartnerNZ4 team members deploy the service on the test server before they leave. The service is now ready for the NZ4 developers to test on the next day. In this manner, both teams communicate informally between the development sites. Organisation NZ4 believes in extensive use of the organisational portal as a common meeting place by their development teams. Lack of standardised templates for work processes means that the organisational portal is used on a minute by minute basis between the two teams (in New Zealand and India) during the common working hours between the two development sites. Thus the development team members have to work with “their headphone attachments most of the time”. The project structure involves explicit knowledge and hence NZ4 does not believe in F2F communication between the development team members and the client. Common meeting places are considered essential at the operational level on a virtual platform through use of organisational portal and open source tools. Moreover the organisational portal is used informally as development teams complemented the roughly drafted documents with one to one telephone conversations. NZ5 NZ5 considers direct F2F interaction essential during the start and end of the project. The MD commented “the two ends of what we do are gathering requirements and deployment. This requires us to interact with the client face-to- face. But 70% of the work which we do is in the middle and we do this offshore”. Moreover these direct F2F meetings with clients are considered essential by NZ5 only at the top management level. One of the top management staff has taken the role of relationship manager, and he visits the client destination alone whenever 169 required. All other team members at the vendor destination communicate by email, telephone and with other formal project management tools. Thus a common meeting place at a physical location is considered essential only at the start and end of the project, rather than throughout the project development life cycle. NZ5 prefers to use organisational portals as common meeting places with clients and their partners. They use a customised portal (through Microsoft SharePoint), with client logins having read only privileges as a common repository for all information. The managing director often referred to the centralised repository on the organisational portal as “one version of the truth” during the interview process. The managing director explained that CRM strategy involved many aspects of the business processes which conflicted across user communities, and as such using explicit documentation at one central place helped them (the vendor) and their client to understand the services being offered. The centralised repository is regularly updated with extensive documentations made by the vendor, and the portal can be remotely accessed through read only logins by client teams. The project manager also commented that since these documents are shared by clients and sub-contractors, the information was “sanitised to a certain extent” , though it still reveals a true picture. NZ5 earlier worked for an Australian client with a large Indian software vendor, in which they had faced some difficulties in the relationship. Project milestones were often delayed due to mismatch of work expectations between NZ5 and the Indian vendor. This was overcome by NZ5 later by defining short term commitments and having weekly telephone conferences between the teams. NZ5 considers F2F meetings to be essential between clients and the senior management only. Organisational portals are used as common meeting places, and they are used to display explicit details of current project tasks, though they are also strictly monitored by the senior management. 170 IN1 IN1 considers that onsite team members at client destinations help in bringing more clarity to the work processes. The project manager stated that “clients feel more comfortable talking face-to-face” and the onsite team “gathers requirements and update the delivery guys in India”. Moreover, these team members before being sent to the client site are given a week’s training program on “what the offshore concepts are in terms of both cultural gaps and working plan”. This helps to make the vendor’s development team members become more aware of cultural differences and worki ng styles across different organisations. Other communication strategies such as, “web meetings, chat space, and knowledge sharing portals are used extensively between sites to work out a knowledge transfer plan”. The onsite developers communicated daily with the development team in Pune about the offshore client’s work processes. Emails, chat forums and virtual private networks are used extensively during these times. Formal meetings are also held fortnightly to discuss all recent aspects of project issues associated with the administration and delivery for knowledge transfer plan. These discussions are documented extensively, and the project manager remarked “If it can’t be documented, it cannot be transferred. We need to explain our actions”. The usage of explicit detailed documents is also considered necessary by IN1 since they are certified at CMMI level 5, and this implies that rigorous software engineering methodology practices have to be in place for external audit compliances. IN1 also has offshore sales offices in the US and Europe. They use F2F communication between clients and the development team members to gather tacit knowledge from the client’s organisation. Standard templates are also used as guidelines to check and understand work issues which help in capturing the tacit knowledge gathered by developers at the client’s site to convert it into more explicit documentation. 171 IN2 Organisation IN2 is involved in the higher end of value services being offered to major offshore business conglomerates. They viewed that a “learned dialogue conducted face to face” enhanced knowledge sharing between development teams. Moreover, sending developers offshore enhanced their learning and responsibility capabilities and increased their development teams’ morale, as “it made them [the developers] feel good being sent overseas for company work”. The project manager also remarked: “Our programmers develop a complex if they are not sent overseas, so we send them after three years. If we don’t, someone else will.” IN2 felt that direct face-to-face interaction gave their team members a first hand view of the customer’s requirements and helped to motivate the individual team members to stay longer with the organisation. IN2 also have offices in major cities across United States and Europe. The teams in these offices communicate regularly with each other in real time over secure communication links. IN2 utilises many specialised technologies, such as CAD 14 / CAM 15 tools for concurrent engineering across distributed sites. Emulators are used to simulate and reconstruct the client’s product design, with very strict policies for security management in place. However, their working hours extended to late evening as development team members may be situated at different time zones. IN2 had recently opened facilities within their office premises to include a swimming pool, gyms with health instructors, badminton courts and other such club facilities to encourage their in-house staff to enjoy late working hours. With such facilities, the project teams are motivated to spend 14 Computer-aided design (CAD) refers to the use of computer tools to assist engineers, architects and other design professionals in their design activities. Related acronyms are CADD, which stands for "computer-aided design and drafting"; CAID, for Computer-aided Industrial Design; and CAAD, for "computer-aided architectural design". 15 Computer-aided manufacturing (C AM) refers to the use of computer systems for the control of robotics and tools during the product manufacture. Integrating CAM with CAD systems provides quicker and more efficient manufacturing processes as design can be modelled in a 3D environment. 172 longer hours at the workplace, and this helps IN2 staff to interact synchronously with their offshore team members outside regular office hours. Having certifications such as ISO 9001:2000, PCMM Level 5, CMMI level 5 and BS 799 also means that IN2 use rigorous practices to convert tacit knowledge to explicit documents. However, the project manager also complained “that productivity is often hampered by the strict documentation requirements of the organisation”. Thus IN2 rely on F2F communication, deployment of employees at client sites and use of secure technological links as platforms to capture tacit knowledge. They are keen to keep the morale of their employees up by ensuring that the office environment is conducive to their socialising needs and also by deploying developers to overseas locations for gathering client requirements. Moreover, international certifications implied strict compliance strategies and IN2 considers externalisation of tacit knowledge into codified documents as an essential (though annoying) part of their work processes. IN3 The head office of IN3 is situated in California, where they have employed two front end personnel to interact directly with their customers. The CEO explained “so as far as customers are concerned they have one point contact for them. They don't have to worry about communicating with people in Pune”. Customers are also provided with 24 hour service through a virtual private network and “so there is no weekly report sent to the customer. He [The customer] can log anytime – day or night – and check the status. He [The customer] can also see what is now available for him to test and he can give us feedback”. However there are certain times when the developers from IN3 need to visit the offshore development centre in California. In such situations, the developers are given training on cultural and language differences to bring them on a more global platform. The project manager commented: “Customers evaluate us and form an opinion about us. So HR person manages this. An example of the training is in English skills. Our English is good but there are some typical words we 173 commonly use like prepone rather than saying bring forward. The US team understands postpone but not prepone. Plus our pronunciations differ. We have people from North India or South India and every one has different accents. So we try to tell everyone to speak in a neutral accent”. IN3 considers F2F communication between development team members of different cultures as their responsibility to remove exclusiveness associated with languages and cultures. They conduct training sessions to make the developers more aware of cultural differences. The developers too enjoy these training sessions which involve recording of their conversations and having language specialists evaluate their speaking skills on a more global platform. IN3 considers common meeting places between team members to be primarily through technology and uses direct F2F meetings if issues need to be further clarified. The direct meetings are held with clients by the local team in the United States, rather than the Indian developers. The onsite and offsite team interact regularly through the virtual private network, blogs, chat rooms and emails. IN4 IN4 considers technological meetings essential to share knowledge across the three development sites in Pune, Bangalore and Toronto. However, the developers situated at IN4 do not communicate with the offshore clients, as is evident by the project manager’s remark” “Indians sometimes find it difficult to break the ice, as the clients do not share their domain knowledge easily. So, our Canadian counterparts manage it for us through regular face-to-face meetings with clients and create some comfort level in them”. A software developer voiced that disagreements often occurred in virtual discussion forums with offshore developers, and senior management intervention was then required. He viewed these discussion meetings as: “This platform is a place of discussion where we gauge the requirements so we put our own thoughts and ideas. But we have to keep also in mind that people there are going to review your design, and they have their own way of looking at it and we have different ways. So we discuss the possible approaches to solve and discuss design from 174 preference and performance perspective”. The organisational portal is used actively by developers to voice their ideas and concerns, as work related issues are shared and reviewed by other team members. However, the developers also felt that sometimes such platforms also led to too much interference by the offshore team members, and then senior management mediation is required. Other communication tools such as online chats, emails and telephone conferences are also used regularly between teams. When the researcher questioned a young developer on whether management is concerned on the amount of time spent by them on discussion forums and chats, a reply by him shows the changing structures in software organisations. The developer immediately replied “ Now it is my mind skills which are required rather than machine skills – so companies cannot be bureaucratic and control us any more”. These discussion forums are viewed favourably by the management teams, and by developers who are eager to learn and share new ideas across sites. These virtual platforms are used as common meeting places extensively between the offshore development sites to share tacit knowledge. IN5 The developers of IN5 interact daily with the parent company, but not with the clients as a regular practice. Their project manager said “the American team provides us with the clients so they are our internal clients. They talk to the client – but they are not technical people so they come back to the team here for a technical solution. So sometimes our team also gets involved with the relationship management dealings with the client but not as a regular practice”. Communication is thus an internal process for them, and daily builds of prototypes are passed to the development team in Minnesota through a virtual private network. Moreover conference calls between the developer teams are held at regular intervals during late evening hours, where documents are shared and prototypes tested. Moreover, on such virtual meeting dates, the Indian team of developers come to work at 11 am, rather than at the regular office time of 8 am. 175 Chatting tools and teleconferencing calls are also used to communicate client requirements and discuss possible solutions. IN5 uses technology as a common meeting place between distributed teams rather than a physical location. Thus the teams situated in US and India work in parallel on different modules, but use the centrally managed database archives. The tool PVCS is used by IN5 for configuration management across the distributed development environment. The developers agreed that the use of the PVCS tool eliminated sending and receiving a “string of emails” , and help in achieving transparency and consistency needed to manage distributed projects. The inbuilt reporting and metrics tools also help them in understanding the quality of each other’s work. Client requirements are gathered by the development team in Minnesota, and explained to the development team in India through use of an organisational portal PVCS. The researcher often encountered the phrase “we just pvcs it” from the development team, when they were asked on how they proceed with the application development if client requi rements were not clearly understood by them. IN5 considers the organisational portal as the main facilitator for knowledge transfer. 6.4.1.2 Summary of communication strategies The case data reveals that five organisations (i.e. NZ1, NZ3, IN1, IN2 and IN3) rely on F2F communication between culturally diverse development team members to bring more accountability for knowledge sharing. However the remaining five organisations (i.e. NZ2, NZ4, NZ5, IN4 and IN5) do not prefer direct F2F communication for different reasons. NZ2 and NZ4 passed the lower end of the software development to their offshore partner, and hence the work content already has an explicit nature. NZ5 have an experienced and technical senior manager who interacts directly with offshore clients and partners to understand their local knowledge and documents this knowledge in to explicit detail. The documents are placed in a central repository and shared with development teams and clients. The Indian vendors IN4 and IN5 have an experienced software team located at their 176 offshore centre, which interacts with clients and explains the client requirements to the development teams in India through the organisational portal. Asynchronous communication tools such as emails, mailing lists and discussion forums, and synchronous communication tools such as chat messaging and telephone conferencing, are used extensively by all the ten organisations. The organisational portal is also used by all ten organisations as a virtual common meetings place across distributed sites. The discussion forums are considered a good platform to bring in more awareness of working styles and processes. The two large Indian organisations (IN1 and IN2) believe that deploying their employees at client destinations helps in capturing free flowing tacit knowledge. It may be reasonable to assume that these organisations have the resources and capital to sustain the costs that may be involved in deploying employees at offshore locations. IN3 also sent developers offshore to client sites but only if the need arose. The larger New Zealand organisation (NZ1) also felt that deploying employees of their partner’s team at client sites brought in direct accountability and responsibility with their offshore partner. However, similar to the three big organisations, one of the smaller NZ organisations NZ3 also deployed employees at offshore client sites. However, the remaining organisations either had offshore offices and development centres at client countries, or had detailed explicit processes in place, so that tacit knowledge gathered at the client’s location could be easily understood and translated into explicit documents to be used by the offshore teams. Thus vendors use a mix of communication strategies to transfer tacit knowledge and build it into explicit knowledge. Socialisation strategies such as F2F communication, common meeting places, discussion forums, telephone conferences, and such like are used to understand each others best practices. Later, the knowledge generated by socialisation is shared between distributed sites and added into the organisational knowledge base through externalisation. The knowledge base is reviewed by the distributed software teams, and experiences are shared over discussion forums and organisational portals, which helps to re-define and extend the knowledge base. 177 Virtual teams working in distributed settings lack explicit organisational structures for socialisation and externalisation for knowledge building. The practices to overcome challenges associated with organisational structures due to isolation and imbalance of virtual teams at dispersed spatial and temporal sites have been identified in literature as use of technology tools for synchronous or asynchronous communication, F2F communication where possible and some common meeting places amongst others (Agerfalk & Fitzgerald, 2006; Jennex & Adelakun, 2003; O'Leary & Cummings, 2007). This section has provided deeper insight into these practices by describing real-life practitioners’ experiences in different cultural and organisational settings. Diverse virtual settings have been explored to understand individual vendor (agent) perspectives and reasons for why certain work structures may or may not be preferred in the OSD environment. 6.4.2 Domain skills Each organisation was queried on the type of skills and experience preferred for their employees situated across distributed sites for carrying out the offshore software development processes. Managers were al so queried to understand how they motivate their employees to gather, utilise and extend the organisational domain knowledge base. “Software development, being primarily a learning activity,” involves new assembly of knowledge when the client requirements are translated into executable form, leading to discovery of new knowledge and fine-tuning of performance of deliverables (Armour, 2006, p. 20). Armour advises software development organisations to provide an environment for learning, where employees feel challenged with new tasks in stressful project situations rather than “shutting down” (p. 22). Accordingly, organisations should create a sharing culture to encourage individuals to share their expertise and add to the organisational knowledge repository. The sharing of expertise is cr itical to support cross-training, as skills are transformed into rules, instructions, specifications, standards, methodologies, classification systems and so on (Choo, 2006) . Moreover, organisations often define new social structures for rewarding team and individual contributions; establishing responsibility and accountability; encouraging cross-cultural dialogue between team members to foster open discussions, amongst others (Staples et al., 2004). Such 178 structures enable smooth flow of tacit knowledge into the organisational knowledge base and make individuals feel respected for their contribution. Motivated employees with the required skill sets further cultiv ate a collaborative and sharing culture, and this is especially relevant to a field such as distributed software development in which interdependent and interrelated software modules developed at dispersed sites have to be brought together into one coherent solution. A summary of the practices preferred by the ten vendor cases to develop the domain skills of their knowledge teams is given in Table 37 and discussed for each vendor. Table 37 Practices for developing domain skills Practices New Zealand organisations Indian organisations Preferences on work experience during recruitment ⎯ Project management skills NZ2, NZ3, NZ4 and NZ5 ⎯ Technical skills NZ3 IN1, IN2, IN3, IN4 and IN5 Other practices to enhance learning ⎯ Training (e.g. in-house, hiring of consultants) NZ5 IN1, IN2, IN3, IN4 and IN5 ⎯ Incentives (e.g. rewards, variable component in pay) NZ3 IN1, IN2, IN3, IN4 and IN5 Each organisation’s practices have been presented, as interviewees described the domain skills of their knowledge workers and the methods employed to facilitate a culture of sharing expertise and individual learning. The section concludes with a summary on how the ten vendor organisations objectify individual skills and experiences to build their capabilities. 6.4.2.1 Case data report on preferred domain skills Individual vendor organisational settings have been examined to understand how individual learning is supported by the vendor’s management to promote a collaborative and knowledge sharing culture. Each vendor was queried on their training programmes, incentive schemes and preferences of employee domain skills 179 and expertise during recruitment. The social settings of each vendor are now described: NZ1 NZ1 had recently undergone a major restructuring move in which they have partnered with an Indian vendor. This partnership had resulted in 50% staff turnover during the time of the second interview in August 2007. The recently appointed general manager viewed that “certain staff members who had left were valuable while some should never have been here in the first place”. The political involvement of restructuring may have influenced the participant’s views, and as such the emphasis of NZ1 management on preferred skills of experienced staff remains inconclusive. NZ2 NZ2 relies on local staff for management of project tasks, and have defined good project practices such as standard templates and test cases for their projects. Moreover, all their “coding” tasks have been off-shored to an Indian development centre. Previously NZ2 had outsourced the coding or implementation related tasks to an Indian vendor (Pilot-IN-Med) who had a development centre in Auckland, but recently they have opened a new development centre in Chennai, India for doing these “coding” tasks. The managing director viewed that staff with “good project management and communication skills are more important than good programming skills”. Accordingly, they prefer to hire employees who have better managerial and project organising skills than technical specialist skills in New Zealand. As regards to the encouragement offered to individuals for their contribution to establishing project procedures, the project manager said employees were encouraged to upgrade their skills. However this was made as a general statement; and not much information was shared on the specifics of how their employees were encouraged, or whether any incentives were offered. 180 NZ3 NZ3 has technically skilled staff at both sites in Auckland and Vietnam. They stated that employees should have both technical and organising skills to complete tasks. Many of their staff in Auckland are trying to get certified in project management with PRINCE2 16 . NZ3 has bought books and training material to support their staff in their accreditation process. Employees belonging to NZ3 and PartnerNZ3 are encouraged to upgrade their skills and are rewarded with “bank points” for extra skills which they may have achieved. Bank points are like “financial rewards or quarter rewards given to employees”. However, the director pointed out that their bank points rewarding scheme has been discontinued for their Vietnamese team members. This is because the Vietnamese teams believed in sharing the reward money by hosting lavish dinner parties for their colleagues. This often resulted in monetary loss than a monetary gain for the concerned employee. Thus, bank points are now offered only to the employees of NZ3, while all the developers at the PartnerNZ3 are offered annual bonuses based upon their technical skills and achievements. NZ4 NZ4 emphasise on project management and so ftware testing skills rather than on programming skills. They are satisfied with the programming skills of their offshore team in India and do not feel th e need for having very specialised skills in the New Zealand office. The project manager of NZ4 said that the intensive work environment had caused many experienced staff to leave the organisation. The high staff turnover rate meant that the remaining staff of NZ4 are often handed new projects which have been left by the departing staff. Moreover, without properly documented processes the employees have to “learn on the job” , which requires them to have 16 PRINCE2 (PRojects IN Controlled Environments) is a process-based method for effective project management. It covers the management, control and organisation of a project. “PRINCE2” is a registered trademark of the U.K.'s Office of Gove rnment Commerce (OGC). Project managers can get accreditation by taking the practitioner’s exam. 181 good project organising and testing skills rather than programming skills for application development. One of the developers added that “managing seven to eight projects” at the same time hardly gave them time to do anything else. NZ5 NZ5 do not believe in hiring very experienced employees for development of their software. The managing director attributes this to three reasons: firstly, such trained people would be very expensive for the company; secondly, NZ5 preferred to train employees with their practices, rather than un-train their earlier “pre-conceived ideas”; and thirdly, they believe that deliverables are solutions based upon business understanding, and are not “gold plated software product developed from a pure developer’s point of view”. This statement also aligns with their communication strategy (refer 6.4.1.1), where the senior management alone interacts with client and offshore partner teams to convert tacit knowledge into explicit documentation. Hence NZ5 prefer to train staff with their defined documented processes rather than recruit very experienced staff members who may do application development work differently from their current style of working and re-define their existing practices. IN1 IN1 are in favour of employing technically skilled developers, as they build large software systems for offshore clients. Employees are encouraged to get certifications from Microsoft, Sun Systems, Oracle, or CISCO 17 . Employees having these skills are considered more valuable, and much effort is made to retain them. IN1 uses many reward schemes to motivate employees to share their knowledge skills and mentor new recruits. They also encourage employees to enrol and complete executive MBA 18 courses from local universities. Employees 17 CISCO provides e-learning programs that provide students with the Internet technology skills essential in a global economy. They have established many institutes in seven states of India and have extended to other countries via the United Nations Development Program, the United States Agency for International Development, and the International Telecommunication Union. Students are examined and certified by CISCO as CCNA (Cisco Certified Ne twork Associate), CCNP (Cisco Certified Network Professional) or CCNE (Cisco Certified Network Expert). 18 Post graduate degree in business (i.e. Master’s in Business Administration) 182 are awarded performance awards for gaining new degrees and certifications, besides offering other incentives such as having a variable component in pay to encourage workers for more active participation in knowledge sharing. IN2 The work content of IN2 involves specialised skills such as complex aircraft modelling through use of CAD/ CAM tools (i.e. Pro-Engineer). IN2 are very selective in their recruitment process, and only consider entrants who have passed some technical university degree. Moreover, they have a policy of not re-hiring any employee back in IN2 or even in any of their sister subsidiaries. This acts as a deterrent for experienced staff to leave, as IN2 is a subsidiary of a major business conglomerate. Moreover, being a PCMM certified organisation; IN2 value people and are keen to empower employees who have spent many years in the organisation. They also encourage senior employees to enrol for technical certificate courses from institutes and offer awards with prize money on completion. They are also well known for offering incentives such as stock options to their employees. IN3 The managing director of IN3 said that they only recruit technical staff, such as engineering graduates, postgraduates in computing and mathematics, who could “understand the project and can relate to the technology and problems”. Employees are encouraged to participate in knowledge sharing, and IN3 also have some personality development courses aimed to improve their employee’s interpersonal skills, as they were wary of “having loners who don’t share their work with others”. The employees are motivated to become more outspoken and share their domain knowledge. Each product has a life cycle manager, and he is responsible to ensure that project management processes are in place. The life cycle manager also helps the management to decide on financial rewards for development teams for tasks such as m eeting deadlines before scheduled dates and low defect rates, among others to motivate the teams. 183 IN4 The management of IN4 is keen to employ developers with experience in their area of expertise, and regularly hold walk-in interviews, where job applicants walk in with their CV in a particular allotted time each week. The researcher’s first interview with the project manager was delayed by an hour due to ongoing walk-in job interviews. The project manger said “experienced programmers are hard to get, and the volume of projects requires us to keep hiring experienced staff, even if sometimes they may have to sit on the bench till a new project is allotted”. Employees have an extra variable component defined in their pay package for upgraded skills or any other value additions to the project environment. IN5 IN5 is keen to employ experienced technically qualified developers, who can get involved in the project with minimal assistance. Such experienced developers help in code reviews and can guide new trainees on good working practices. However, IN5 cautioned that experienced and trained staff are rather eager to move up the career ladder and often leave the organisation in three to four years. They encouraged team members to share their experiences by awarding special recognition prizes for their contributions. In centives such as spot awards are given to teams and individuals for meeting deadlines, low defect rate, new ideas, and such like. This is essential to retain th eir experienced staff, though IN5 still has a high attrition rate of 30-40% per annum for their experienced staff. 6.4.2.2 Domain skills summary The case data reveals that generally New Zealand organisations consider project management experience as core to knowledge sharing and knowledge transfer. The preference on domain skills for one New Zealand organisation NZ1 remains inconclusive, due to their recent restructuring process which had resulted in 50% staff turnover. Moreover NZ3 is the only NZ organisation that offered individual rewards to their employees at both their local and offshore centre. The other three NZ 184 organisations did not offer much insight on how they motivated their employees to upgrade their skills or share their expertise. The five Indian vendors on the other hand have maintained a balance of individual and organisational ambitions, so that a “window of opportunity” exists for both. Some of the practices are executive MBA courses for employees in the large organisations, personality development courses with role playing to bring fun within learning in both large and medium sized organisations, performance awards such as having a variable component in pay to encourage workers for more active participation in knowledge sharing, spot awards for meeting deadlines or low defect rates, and valuable contribution certificates with prize money awards, amongst many others. These findings are also in agreement with Carmel and Eisenberg (2006, p. 864) reporting of Indian software developers who operate in a “more competitive educational environment” for learning software development processes. Software development is a knowledge building exercise and requires a mix of technical and administrative skills. Rottman and Lacity (2004) state that inexperienced employees can increase both client and vendor risks, as they take a longer time to overcome the learning curves. They add that some clients “try to mitigate risk by demanding to see resumes of supplier employees or by setting minimum years of experience” (p. 124). Though none of the vendors mentioned this aspect of the client’s demands, the vendors generally agreed that employee skills and expertise play a major role for timely co mpletion of the project deliverables. The study reveals that Indian vendors lay more emphasis on employee’s technical skills as compared to the New Zealand vendors. Research has established the high employee turnover in Indian software industries (Dibbern et al., 2008) and accordingly this study also finds that Indian vendors have de fined more practices such as training and offering monetary incentives to retain technical staff. With the exception of one New Zealand vendor (NZ3), the other New Zealand vendors did not offer monetary incentives to motivate their employees. Moreover, the New Zealand vendors preferred better administration skills, as they had transferred technical jobs which were loosely referred as “coding” to offshore partners in low cost countries. 185 6.4.3 Requirement volatility management strategies Requirement volatility is an ongoing issue fo r software development, as requirements change with progress of the project requiri ng flexible software processes. Agerfalk and Fitzgerald (2006, p. 29-30) warn of the two extreme swings of the pendulum for managing changes in requirements or project scope in global software development. One extreme is too much explicit formalisation of processes leading to meetings and “huge wordy documentation” which are “vague, poorly organised and difficult to use”. The other extreme is “relying on pure tacit, undocumented knowledge” which considers changes in projects with the view that: “Code is a document and all the document we need”. They advise the position of the pendulum to lie between the two extremes, with precise, lean documentation which is plan-based and not unnecessarily intensive. Each organisation was queried to understand whether they considered explicitly defined formal processes with too many standardisations of documents to support the change, or considered project changes imp licitly with hugely informal and flexible methods having no associated documentation, or considered some place in between the two extremes. The researcher faced the question as to whether requirement volatility and change management strategies should be considered as tacit knowledge in this chapter or as explicit knowledge management in the following chapter. As has been discussed in Chapter four, the pilot cases had revealed that New Zealand vendors (Pilot-NZ-Small and Pilot-NZ-Med) used informal methods for informing and managing changes, while the Indian vendor (Pilot-IN-Med) used formal processes. This section determines whether the practices defined for requirement volatility or change management have been considered as tacit workflow (with no formalisation of processes) or as explicit workflow (with formal processes to record changes) by the vendor management across the ten vendor cases. 186 Table 38 briefly describes the vendors’ strategies to manage requirements volatility in their projects. Table 38 Practices on requirement volatility management strategies Practices New Zealand organisations Indian organisations Requirement volatility management (also referred as change or scope or expectation management) ⎯ Formal processes (i.e. change proposals, change notes) NZ5 IN1 and IN2 ⎯ Semi-formal processes (i.e. precise and lean documentation) N Z 1 , NZ2 and NZ3 (for major changes only) IN3, IN4 and IN5 ⎯ Informal processes (i.e. no related documentation) NZ3 (for small and moderate level changes) and NZ4 6.4.3.1 Case data report on requirement volatility management strategies With the exception of vendor organisations NZ3 and NZ4, all other organisations used formal or semi-formal processes for managing volatility in customer requirements. The two organisations NZ3 and NZ4 manage the changes in project modules more informally. However, NZ3 do not consider major changes in requirements to be done implicitly. They have defined measures to quantify changes at small, moderate and major levels. Small and moderate changes are handled by teams with minimal or sometimes no documentation. But major changes are specified with high seriousness level based upon project schedules and other associated costs. Also, NZ3 believes in minimal documentation, and the director said “We only document the essential, and prefer using spreadsheets”. The project manager said that they discussed changes directly with the client, and if any major changes are requested, they are resolved amicably across the table, rather than send the client a “huge document listing out the seriousness of the change”. The work content for NZ4 is a regular “fire fighting story” , and the project manager admitted that they do not have any standardisations or mature software configuration tools for tracking volatility of changes. Moreover, with a large number of projects spanning a life cycle anywhere between five days to two weeks, the time to document changes formally “is simply not feasible”. The project manager also admitted that they do not have any documents to record any changes that they may have made. 187 Thus decisions on changes are made by the development teams implicitly and no records are maintained. The remaining eight organisations use some sort of software configuration management tool, and maintained details of the change, reason for change, date of change and seriousness level of change in the organisational portal. Moreover since IN1 and IN2 have been certified by international agencies for their work processes, all changes have to compulsorily go through some pre-defined standard documentation before they can be implemented. Both IN1 and IN2 required very minor changes in requirements to also go through explicit documentation processes as it is checked by their auditors for maintaining their process certifications. If any discrepancy in documentations is found, they are issued a “non compliance report during the internal ISO audits which happen quite frequently”. 6.4.3.2 Summary of requirement volatility management strategies The question as to whether practices defined for requirement volatility or change management should be specified in the tacit knowledge base (by using informal processes) or in the explicit knowledge base (by using formally defined processes) has been answered as having an explicit nature in eight of the ten organisations. Requirement volatility (also referred to as change management or scope management by the practitioners) is considered as a part of their project management area where interrelated work activities (e.g. specifics on reason of change, change requested by whom and to be completed by when) are documented in some place in the organisational repository. Thus change management strategy for offshore software projects has been discussed in more detail in the next chapter, where the focus is on management of the organisation’s explicit knowledge base across distributed sites. 6.5 Important drivers for tacit knowledge transfer The vendor experiences have revealed that dynamic and continuous interaction between team members is needed to build software solutions. Vendors use socialisation strategies through direct modes adopted via F2F communication and 188 groupware technology tools. Team members have established common meeting places both on physical ground and on the virtual platform to help each other share their opinions and experiences which are then externalised as explicit documents in the organisational knowledge repository for reuse by others. Common meeting places help to better manage the challenges associated with cultural distances and dispersion of interrelated tasks. The physical meet ing places involve locations such as the vendor’s centralised office or the client’s site, while virtual meeting places involve the telecommunication network such as organisational portals and discussion forums, where knowledge workers can discuss design ideas and preferences. The dynamic patterns for capture and delivery of knowledge across tacit and explicit sectors in the OSD environment can be represented by the knowledge spirals associated with the SECI model. This chapter has offered new insights on knowledge sharing practices cited in literature. Though face-to-face communication has often been cited in literature as having a positive influence on transfer of tacit knowledge (refer Table 8), this research extends the literature by revealing that there are many aspects to implementing F2F communication processes. All the ten vendors agreed that F2F communication is an essential part of tacit knowledge transfer, but they each applied the F2F strategy differently. Some of the vendors said F2F communication between vendor and client should be confined to similar cultures only to help in building trusting relationships between similarities; while others felt that direct F2F interactions between diverse cultures brings more awareness of work processes, sharing of individual responsibility and as such motivated the individual developers to take ownership of the project; and lastly some other vendors consider that F2F communication with clients should be confined to the senior management levels only. Synchronous and asynchronous communication methods are regularly used between virtual teams through emails, mailing lists, discussion forums, telephone and video conferences, online chat tools and organisational portals, amongst others to transfer knowledge. These collaborative tools help in record keeping and provide a written history over which teams can later reflect and create new knowledge. The local knowledge from distributed team members can be externalised into explicit 189 knowledge bases. Moreover with the use of secure organisational portals spread over distributed teams, the developers share a common repository of templates, performance metrics and design preferences, which further helps to extend each other’s work. These tools also make teams aware in real time of currency of work processes across distributed sites, lead to more efficient utilisation of modules through reuse in other projects and avoids duplication in work effort as common standards are used by all the teams. However, such direct visibility can also lead to too much interference by team members located at another site, as was evident in one case. A difference observed across New Zealand and Indian software vendors is the preference on skill sets of their employees. New Zealand organisations emphasise more on the operational team having individual project management skills, while the Indian organisations preferred operational t eam members to have technical skills such as designing and programming to help in development of software applications. However, as has been mentioned earlier in this chapter (refer section 6.4.2.2) a reason why New Zealand vendors lay more empha sis on project management skills is because they have transferred a major part of the coding or programming work to offshore business partners in low cost countries. The study finds that New Zealand vendors are involved in the requirement ga thering and project customisations for clients, than in the actual construction of the software product. Hence the New Zealand vendors need to coordinate activities relating to their offshore partner’s technical skills rather than try to build the projects themselves. The Indian vendors on the other hand lay more emphasis on technical skills, than on project management skills. The Indian development teams have the responsibility of building the software modules, which are then passed to offshore partner teams for testing. Hence, they require that technically skilled developers should be able to translate the project’s details sent by their offshore partner into tangible software modules. Regarding requirement volatility or change management strategies being defined as a tacit knowledge workflow, this case study report concludes that this driver should be considered on the basis of how it is managed in the knowledge base (i.e. through formal or informal processes). Hence change management has been considered in the next chapter for understanding software project management practices. 190 Finally, the chapter has brought awareness of the diversity in social settings across two country contexts. Vendors (agents) have realised the need to adopt a more global work environment in the knowledge society and are redefining work structures to encourage tacit knowledge sharing across distributed sites. Tacit knowledge includes aspects of both social and technical elements. Accordingly, vendors have made adjustments to their communication strategies for socialising with offshore teams, have identified preferences for employee expertise and have adopted practices to manage requirement or scope volatility in the distributed environment. 191 CHAPTER SEVEN – Micro Level Analysis for Management of Explicit Knowledge 7.1 Introduction This chapter follows on the empirical findings from the previous chapter, in which the drivers affecting transfer of tacit knowledge across distributed locations in the OSD were examined for the ten vendors in the study. However, knowledge capital consists of both tacit and explicit components, and integration of the knowledge components into the software deliverables still continues to be a chronic challenge in software development (DeSouza, 2003; Ramesh, 2002). In a distributed software development environment, team members have to integrate data from various artefacts, files and libraries which are spread across different organisational sites into a common coherent solution. The team members collectively interpret the distributed knowledge-based activities for creation of new knowledge assets. Thus vendors organise knowledge-based processes for management of the explicit knowledge which is flowing between distributed teams. This chapter presents the micro level analysis of the embedded case to understand vendors’ strategies for the management of explicit knowledge to answer the second subsidiary research question: How do vendors manage distributed knowledge-based processes within the software development environment? The conceptual framework (refer Table 27) has identified the drivers (or units of analysis) affecting the management of explicit knowledge. The chapter begins with an examination of the drivers which affect the management and control of explicit knowledge assets across distributed vendor locations. The SECI model has been used to examine the empirical data for each driver, and provide understanding of vendor strategies for creation and internalisation of knowledge assets. Use of structuration theory has helped to understand the work structures related to the drivers for the vendor cases. The vendor strategies for each driver have been summarised in separate 192 subsections. The chapter concludes with a summary of key practices associated with each driver for the management of the explicit knowledge component across the ten vendor organisations. 7.2 Drivers for management of explicit knowledge Software development is a complex iterative process; where knowledge based processes have to be managed and controlled by many project groups. This is further complicated in a distributed offshore environment where knowledge based tasks are spread across project groups belonging to different organisational boundaries (the so called ‘silos’), and situated in different temporal and spatial spaces (the so called ‘virtual social spaces’). Thus relevant knowledge tasks are fragmented between team members spread across the virtual spaces, resulting in interdependent decision making by the many knowledge workers in their own silos. These decision making aspects include defining work flows for project scheduling, partitioning of team responsibilities and use of appropriate methods for software configuration control, amongst others, as new or not previously defined knowledge assets emerge (Karolak, 1998). Each team member involved in the software project shares knowledge assets and needs to have awareness of any change in the definitions and relationships in the specific project design. Organisations provide a foundation of common code of practices with defined tracking of interrelated processes to help integrate the flow of changes into the software deliverable. Thus well defined interfaces between teams need to be in place, so that project tasks are clearly defined across distributed teams and team members are aware of their responsibilities to facilitate effective sharing of knowledge. Proper management of these interfaces helps teams to identify expectations and is an essential part for the externalisation of local knowledge within silos, creation of collective knowledge assets and the internalisation of applied knowledge across the VSS. Takeuchi and Nonaka (2002, p. 142) state that although much has been written about the importance of knowledge in management, “little attention has been paid to how 193 knowledge is created and how the knowledge creation process is managed”. The preceding chapter discussed the tacit knowledge creation and its subsequent transfer into explicit knowledge across geographical boundaries by software vendors, through practices adopted for socialisation and externalisation. Herbsleb and Moitra (2001) emphasise the importance of knowledge management in offshore software development, and state that good knowledge management strategies allow for many reuse opportunities, saving on both cost and time in the overall development effort. The interdependent nature of software development further means that team members must find a collective way of organising relevant knowledge, since different groups of people share the project workspace in the common enterprise repository. Offshore vendors have to manage their knowledge repositories to allow software teams to connect, interpret and respond effectively to the collective knowledge. Thus the interfacing and management of distributed processes, technologies, specifications and skills is an essential part of integration of tacit and explicit knowledge assets. The knowledge exchange interface (or boundary spanning) uses formalised processes, standardised templates and other set routines. Table 39 gives a summary of drivers identified as units of analysis for management of explicit knowledge from the conceptual framework (refer Table 27). The practices associated with each driver which influence the management of the vendor’s explicit knowledge repository across distributed sites ar e also summarised in the table. These practices are based upon both published literature and the empirical data collected from the vendor case studies. 194 Table 39 Drivers affecting management of explicit knowledge Drivers (unit of analysis) Practices associated with the drivers Quality process management Formally certified external processes (international certifications e.g. ISO, CMM) Less formal internally defined processes (internal audits) Software project management Document standards (e.g. templates, checklists, reports, code conventions, project history) Project scheduling (e.g. project reviews, project meetings, milestone tracking, status reports) Software configuration controls (e.g. version control, change management, libraries) Collaboration tools (e.g. groupware artefacts for conducting real-time meetings, synchronised code fixtures, access to repository) Staff attrition management Creating project awareness through knowledge repositories (e.g. peer reviews, use of established standards) Developing employee capabilities (e.g. training, mentoring, rewards) Table 39 underpins the empirical work described in this chapter where the vendor’s experiences are contextualised for the identified practices in each driver. The next section uses Table 39 to investigate vendor’s work practices for management of drivers associated with their explicit knowledge-based processes in the OSD environment. 7.3 Empirical observations on the drivers for management of explicit knowledge The conceptual framework identifies three drivers (or units of analysis) for management of explicit knowledge. They ar e quality process management, software project management and staff attrition management. This section is divided into three sub sections, where each subsection focuses on each driver identified in the conceptual framework to describe individual vendor work experiences for management of explicit knowledge. Extensive use of empirical data obtained through interviews, observations and white papers, on the management of organisational artefacts (such as documents, accreditation agencies, groupware tools, training, etc) have been made. The semi 195 structured interview questions helped to identify related practices for each driver, when practitioners described their processes and expressed concerns for management of the distributed knowledge tasks. The social structures influencing each driver are described with use of interview text identified as exemplars for understanding the diversity in social and organisational settings. Each subsection concludes with a synthesis of key practices for management of explicit knowledge for that particular driver in the OSD environment from the vendor perspective. 7.3.1 Quality process management Quality processes encompass many aspects of the software development life cycle phases at various levels of granularity. Organisations define product and project specifications which need to be adhered to by all the stakeholders – individuals, development teams, testing teams, customer support groups, and functional teams for purchasing, infrastructure management and ot hers – as expectations are associated with each stakeholder. Organisations may describe their intent of expectations formally or informally, depending upon the social and cultural structures that exist within the organisation. Formal processes include international accreditations by recognised agencies and include audits by outside experts on a regular basis, while less formal processes may include internal audit checks on the current processes and work progress. Quality processes involve a wide range of activities in the software development effort, which include defining individual developer’s and the project team’s roles and responsibilities, managing tasks associated with each incremental project deliverable, satisfying security processes, reviewing of design documents and architectural constraints, collecting feedback on software functionality, reliability, usability and many more such areas. The list is endless. Hence, this research focuses only on the level of formality of their defined quality processes, to gauge whether vendors consider internal audit or international quality audit processes to meet their quality process requirements. The study looks at the adoption of formally certified external processes or less formal internally defined processes by offshore vendors in two country contexts. 196 A summary of the quality processes preferred by the ten cases is given in Table 40. Table 40 Practices for quality process management Practices New Zealand organisations Indian organisations Formally certified external processes (international certifications) IN1 and IN2 Less formal internally defined processes (internal audits) NZ1, NZ2, NZ3 and NZ5 IN3, IN4 and IN5 Informal processes NZ4 The responses from the ten vendors on their quality processes are synthesised in the following subsections. The section concludes with a summary of the offshore vendors’ methods to manage the quality processes across distributed sites. 7.3.1.1 Case data report on quality processes This section looks at practices associated with their quality processes for the ten offshore vendors participating in this study. The practitioners’ voices have been used extensively to give the reader a deeper understanding of each organisational setting. NZ1 NZ1 does not have internal certifications. The general manager commented that his previous job was in an organisation which was ISO certified, but they had let their certification lapse. The general manager commented “ISO and CMM are just tools to help you improve documentation, but if you just go through the notions of putting them together before the audit then don’t go into these certificates. CMM is a great way to improve your level of maturity but if all you are doing is produce a number of documents to prove that you are doing it then it is useless. The idea is not to prove but to improve – so as a manager of software services what I am trying to do is improve overall. So I have taken information from areas like CMM, Agile and ISO and put that in a box and come with my own recipe. Plus you’ve also got to be making enough money to support the certifications; else you pass the expense to your client. I earlier worked in a 197 company which had ISO accreditation and later they had let go of it. There I realised that these certifications were useless pieces of papers”. However, NZ1 added that their offshore partner PartnerNZ1 have many certifications, such as CMM level 5 and ISO, since PartnerNZ1 feels that certifications benefited their competitive strategy. Moreover PartnerNZ1 are bound by contractual agreements to NZ1 and have to provide NZ1 with detailed design specifications and related project management documents which are also needed by PartnerNZ1 for their own certifications. Hence, though NZ1 does not have such international quality certifications themselves, they benefit from their offshore partner’s international accreditations. NZ2 Organisation NZ2 does not have international quality certifications. Instead, they have documented their own processes and use standardised templates for each design phase. They are involved in the complete software design and project management process, and the software teams are aware of the responsibilities expected from them. The project manager commented “We have a defined project development cycle, with milestones as zero date when the project development commences, and then there are many iterations of development before the final consolidation stage where the design release document is signed. Before this stage we use the test data, as PartnerNZ2 is also involved in coding bits and pieces. Later we have a separate process to test our product design on the actual customer data. All these processes have to go through checklists which are quite rigorous. There is no need to tell any external auditor that we are doing this. The responsibility of our quality processes lies with us”. NZ3 NZ3 do not consider international certifications to add value to their quality processes. They prefer individual responsibility for their technical solution and consider ownership of defining and setting specifications to lie with them, rather than with external agencies. The director of NZ3 said “We have never really felt the need to get certified by international agencies. No one has actually asked us 198 here in New Zealand. Our Vietnamese guys have raised this matter because ISO is quite big there. Lot of companies in Vietnam actually use these certifications and they say companies are looking for quality certificates. But it hasn’t been asked for us here in New Zealand. We look internally at our quality control in areas around our products. We are getting into product development now. I guess our quality needs to be 103 %. We cannot say that our product which goes out is 103% perfect, as bugs need to be fixed now and then – but our developers give it their best. Our developers know the latest technology with quality - because if we do not give quality to our clients, our clients will just disappear. Whether these internal quality checks will bring us certifications I don’t know – it could very well lead to that. Some of our guys are getting certified in Prince 2 for a project management qualification. We’ve got a couple of our project managers who are getting Prince 2 qualification – so, I’ve bought them books and all the training material. I would rather just get our guys to finish their tertiary education and become Microsoft Certified MCAD or become certified with PRINCE, than apply for ISO”. NZ4 Organisation NZ4 do not believe in internal or external audits or other formally defined quality processes. Their “work content is quite straight forward” , and hence they do not use too many defined and documented processes. Their client projects are quite small and generally last between five days to two weeks. However the project manager admitted that NZ4 do not have any standardisation of their processes, and also do not use mature software configuration tools for development work between their two development centres. He used the metaphor “fire fighting” to describe each working day, and said that developers learnt the process details “on the job”. Thus working practices are not explicitly described, and individuals define the project specifications and performance criteria to the best of their ability. NZ5 Previously, NZ5 had formal international certification for their quality processes (i.e. ISO 9001), but they had let the certifications lapse. They feel that having 199 learnt the rigorous practices that went with these certifications, they can now review their quality processes themselves by internal audits. Now NZ5 considers itself to be responsible for auditing their set project specifications and achievement of project targets, rather than be audited by external agencies. The managing director remarked “We did it for the right reasons – that is to improve the process and to start with a baseline of how we do things. Now then this is a baseline for improvement. So we had it and left it for the right reasons as we now had templates and checklists as a baseline for improvement, rather than people ticking a box to say they were ISO certified. Also earlier there was a culture which said that ISO was a good thing. That culture I think has changed now”. IN1 IN1 is a large organisation with 4100 employees’ world wide. The project manager said that “International certifications are considered necessary by all large Indian groups who operate globally”. Their website proudly shows scanned documents of their certificates such as ISO 9001:2000, SEI CMM level 5 and SEI CMMI Level 5 under a section marked as “globally recognised industry standards”. The website also displays a chart of their progression from CMM level 3 in October 1996 to CMM level 5 in May 2004. Similarly, another chart shows progression from ISO certification in March 2002 to ISO 9001:2000 in May 2004. IN1 have identified a Solution BluePrint (SBP) Framework which defines templates and lists out the activities involved in each phase of the development cycle. The project manager said that adhering to the SBP framework ensured that all quality processes are being followed, and each project “diligently” [spoken slowly and with emphasis] followed the guidelines laid out in the SBP framework. IN2 IN2 is certified by many international agencies and have the following certifications: People CMM Level 5, CMMI level 5, BS 7799 and ISO 9001:2000. Their website has a section “Quality” where scanned images of their certificates are displayed. Moreover, IN2 is a subsidiary of a major conglomerate group in 200 India. The parent group owns many small groups of companies, and their parent group have defined their own excellence model based upon Malcolm Baldridge National Quality Awards. IN2 is regularly audited by their parent group to assess their quality capabilities. Anonymous questionnaires are floated to employees by the parent group to gauge their working e nvironments, and each subsidiary is then credited points based upon some set criterion, where each subsidiary has to attain a minimum of 500 points. The workforce of IN2 said that such practices helped to bring in “more sharing of responsibility and a friendlier working environment, as each one has a say”. IN2 prefers to have formal processes defined for each workflow, and their project manager said that minute granular details are required for maintaining international certifications. IN3 IN3 do not consider international quality accreditation to improve their quality processes. Also they have no intention of getting such certifications from international agencies. The CEO of IN3 stated bluntly “Certifications aren’t necessary. They are just overheads”. But IN3 have defined their own quality control processes to ensure that product development standards are maintained. Each project has a life cycle manager who ensures that correct processes are being followed by the development teams. IN3 uses internal audit checks to ensure that set practices are being followed and expectations are being met. IN4 The COO of IN4 said “Certifications are linked to an organisation’s maturity and are OK for big organisations, which have a lot of cushion- lot of support, but are not meant for medium sized organisations like us……. We maintain our knowledge confidentiality, and do not let it spread around.” Thus, IN4 do not view external accreditations as a requirement for them. They have defined some internal processes to maintain their knowledge processes, and project teams are responsible for ensuring that the processes are being followed. 201 IN5 IN5 do not consider international certifica tions as an enabler of quality processes for software development. They view that these quality certifications are essential for industries which are manufacturing items in bulk for consumers, and not for a knowledge industry as theirs. This is evident from the CEO’s remark “We sell expertise and not TVs…. We have found the extraordinary in the ordinary and have been granted a dozen patents. We don’t need these other certifications.” The project manager said that internal audits are held without notice by the middle management of IN5 to ensure that the guidelines are being followed, and also to keep a check on the traceability of project activities. He added that “sometimes we have non compliance reports, as developers are too bored to fill in their checklists and do not give a feedback on their new modules. They just want to continue with building the end product, and forget to write about the issues associated with the development versions. So we tell them the importance of our checklists, and they understand”. IN5 maintains self discipline in their quality processes through internal audits, and they have no intentions of getting external accreditations from international agencies. Previously IN5 was a member of Safe Harbour, a European Union framework for security measures and controls, and IN5 had very strict policies and security guidelines in place. However, they are no longer certified by Safe Harbour and cited the reason for discontinuing as a “management decision”. 7.3.1.2 Summary of quality processes The case data reveals that only the large Indian vendor organisations (i.e. IN1, IN2 and PartnerNZ1) utilise international certifications to manage their quality processes. The other eight vendors (belonging to New Zealand and India) do not consider these certifications as necessary. With the exception of one vendor (i.e. NZ4) the remaining seven vendors have defined project guidelines and outlined the expectations for their development teams, which are audited internally by them. The practices employed for management of the quality processes of the ten vendors are summarised as follows: 202 None of the New Zealand organisations have quality certifications. NZ1 are not internationally certified themselves, but they have an offshore partner who is certified by many international agencies (such as CMMI level 5, CMM level 5, ISO 27001, BS 7799 and AS 9100/EN 9100). Also, previously NZ5 had ISO 9000 certifications and they agreed that the ISO certification brought in strict discipline in managing the quality of work. However, NZ5 have let the certification lapse and have no intention of getting re-accredited. The remaining three New Zealand organisations too have no intention of getting any external accreditations. All these organisations feel that the New Zealand market does not consider such certifications as status symbols or helps to increase their competitive position in the global market. Similarly the three medium sized Indian organisations (IN3, IN4 and IN5) do not consider international accreditations as essential or to add value to their existing work processes. However the two large Indian organisations (IN1 and IN2) have many certifications, of which they are very proud. It may be reasonable to assume that the large organisations have the capital and resources to manage such certifications and have external audits by international agencies. One Indian vendor IN5 earlier had membership of Safe Harbour for security controls. However, IN5 is no longer a member of Safe Harbour, though no reason was offered for discontinuing the membership. Moreover, all large organisations of the size of IN1 and IN2 in the Indian software market have international cer tifications as a general rule, as is also evident by the large offshore Indian partner of NZ1 (i.e. PartnerNZ1). Literature identifies that ‘Indian software organisations have embraced the CMM quality process methodology” and are “the leaders in its use within the software industry” (Carmel & Eisenberg, 2006, p. 863). Ramasubbu et al. (20 08, p. 438) have also identified India to have “the largest pool of world-wide software firms with capability maturity model level-5”. Hence it may be expected by both IN1 and IN2 that being large they too must have international accreditations at high levels of maturity (i.e. CMMI level-5). 203 7.3.2 Software project management In distributed software development, t eams at different locations are working on interrelated software tasks in each project . People with different skill sets ranging from users, domain experts, architects, developers and testers situated at different locations coordinate and align their activities in accordance with the proposed project plan. The project plans define project schedules and aim to give the current status of the project activities. These software teams at distributed locations develop interdependent modular designs which have to be integrated together into a coherent solution. To further add to the complexity, software development involves iterative processes in which the designs are refined iteratively as the development proceeds. The software teams have ongoing interaction with other distributed team members and conduct peer reviews to ensure that their designs conform to the required expectations. This section examines how offshore vendors manage the overall software project process to maximise efficiency and achieve organisational goals. The study has identified use of collaborative tools groupware technologies such as email, web conferencing, telephones and chat, shared file repositories, virtual private networks and organisational portals to provide connectivity across the distributed environments. Tools help to reflect project plans, track project progress of confirmed and pending activities through status reports, define standard documentation templates for ensuring all teams understand each other’s documents and overall use of good configuration controls to help combine the knowledge assets being generated at different sites into the common enterprise repository (refer Table 8). Table 41 illustrates the level of formality used by vendors for coordinating project activities across distributed sites. The table also lists the collaboration tools used by the vendor teams for managing project artefacts (i.e. schedules, libraries, reports, templates) in the OSD environment. 204 Table 41 Practices for software project management Practices New Zealand organisations Indian organisations Standards for document controls, project scheduling and tracking, and software configuration practices ⎯ Very formal NZ2 IN1 and IN2 ⎯ Less Formal NZ1 and NZ5 IN3, IN4 and IN5 ⎯ Informal NZ3 and NZ4 Collaboration tools (e.g., emails, discussion forums, web meetings using freeware and common communication tools, organisational portals) NZ1, NZ2, NZ3, NZ4 and NZ5 Other tracking tools used are Microsoft Sharepoint, Project Web Server, EventTrack and Go to Meeting. IN1, IN2, IN3, IN4 and IN5 Other tracking tools used are proprietary groupware tools, Seapine CM, PVCS TestTrack, and Bugzilla. The vendors were queried to understand how project plans and project status reports were documented in the common enterprise repository. Also, data has been gathered on the collaboration tools used by them to manage issues related to distributed software development. The focus of the interview questions was to get a holistic view of their project management practices, and to understand the level of formal control defined over the standards. The responses of the interviewees covered many areas, and some of the development teams also explained their processes by showing the researcher some details of their project documents which were stored in their organisational portal. The following section describes the case data with use of interview text identified as exemplars for understanding the vendor software configuration management processes. Moreover, the interview text data gives a better understanding of the social settings within these organisations, as vendors described their issues and reasons for change in software project management practices (if any). 7.3.2.1 Case data report on software project management This section describes the work practices associated with the management of distributed project tasks by teams spread at different geographical locations for the ten vendors participating in this study. 205 NZ1 Organisation NZ1 considers groupware tools essential for streamlining the distributed tasks. The project manager commented: “getting the technical development done properly is not that bad particularly the logical ride which is actually quite straight forward and most good intelligent IT people can learn the technology mental path really well but it is about getting the whole process right.” Thus NZ1 views that software projects should not be simply thrown “over the fence to someone in India”, without associated project documentation. Also ongoing correspondence with their Indian partner (PartnerNZ1) is felt necessary to help in clarifying doubts since application requirements have sometimes not been interpreted correctly by their partner. The project manager of NZ1 said “Our experience has been that if we throw the requirements over the fence to someone in India, then they can be interpreted in any number of ways. In some of the models I’ve seen are that they are not well designed. The model has a lot of ambiguity and the potential to go down the wrong path for the software development. We’ve realised that the requirements need to be very well known and discrete from an IT perspective before it is sent offshore”. The general manager also said “Our problem with PartnerNZ1 was that they did not ask questions. Maybe they felt that asking questions would make them look less knowledgeable. But we have added an extra overhead that has now come into play which is basically bringing PartnerNZ1’s people from India into New Zealand to work on our projects as another development resource. This is what we are currently doing for one customer at the moment. We find that with the direct interaction with our team here, PartnerNZ1’s team and the client, we can then put in place the relevant documents, and this helps us all to manage in an efficient and cost effective manner”. However NZ1 use less formal techniques for documentation and reporting standards while working with their local teams (belonging to NZ1) and their local New Zealand clients, and use more formal processes when working with their offshore partner. Virtual technology tools help to bring in visibility and streamline the tasks pertinent to the project life cycle. NZ1 have a virtual private network 206 (VPN) and have deployed servers to distributed tasks appropriately. Key milestones are documented in collaborative tools deployed in the VPN, where team members’ could log in from different geographical sites and jointly discuss the present status and past issues. The discussion forums are used informally by the team members, though their published document workspaces are maintained very formally. NZ1 uses tools such as Microsoft SharePoint and Project Web Server to help coordinate activities across the distributed sites. The servers are managed by designated administrators in NZ1 and Partner NZ1. NZ2 The managing director of NZ2 said that groupware tools helped in “cross – fertilisation of ideas”, and improved communication, tracking and the overall management of the software project. NZ2 has been involved in the management of confidential medical data of clients, and hence they have strictly defined processes on the work that is sent offshore. The work sent offshore is loosely labelled as “coding tasks”. NZ2 have secure polices in place because of “the confidentiality of having health records, dealing with laboratories” and such like. Thus NZ2 have enforced strict documentation and have centralised decision making authority. One developer of NZ2 said that “the environment at NZ2 is extra formal compared to my previous job environment”. The managing director explained “For a project plan we are very transparent. Each one of us knows the project plan for each one of us. We also have a weekly update. There is a daily update in terms of issues and we have a development tracking tool called Event Track which we have bought and have synchronised between each country for our medical applications. EvTrack is a great tool and both teams work out their plans smoothly. The project deadlines are set by us. The progress reports are all sent to us and we have a team in house both in Australia and New Zealand. We do keep a local presence here and do not send all work to be done offshore. The local presence fixes and sees to the release process. They look very seriously at acceptance testing, bug fixing and load balancing, and they communicate with PartnerNZ2. Later our team here will deploy the product on another server, as we do not give PartnerNZ2 access to the other server”. 207 Organisation NZ2 relies on groupware tools to regularly communicate between teams on daily issues and project tracking. They also follow strict documentation processes between distributed teams, and use of standard reports. White papers on the tool used by NZ2 (i.e. EventTrack) have revealed that the tool gives out details such as information access rights, printouts made by which logins of documents labelled as sensitive content, monitoring of replication events on the database, and these results could be monitored separately on different servers placed in the cluster. EventTrack can be used to make detailed monitoring criteria for each server hosting a configuration database, maintain logbooks of accesses made and also to define sensitive events in the database. NZ3 NZ3 does not believe in formal management of project documents or status reporting. As previously stated in Chapter six (refer 6.4.3.1), the director said “We only document the essential, and prefer using spreadsheets”. Changes are discussed directly with the clients, and are resolved amicably across the table, rather than sending the clients a “huge document listing out the seriousness of the change”. The project manager added that they mainly used entity relationship models between the distributed teams, and changes to the model are sent through email and discussed over VOIP tools (e.g. Skype), since they do not believe in documenting each minor update to the models. Project schedules are decided by team members to “have two weekly builds and others are along multi-timed builds”. The project manager added “clients come here and review things quite often when we send them a new release. We make regular builds and if we want them to see something we just apply the requirements locally and invite them through “Go to Meeting”. Now we show them the latest bit of work we’ve done. We show them the screens - so they don’t have to come here”. The project manager explained how they conducted meetings with such tools. “We just log in. We also give the clients the logins and password for a particular session to which they log in to. It is not just us; we also have to keep the Vietnamese team up to date also. All three of us join in the conference meeting. In one of our products that we are trying to sell we did a two hour 208 presentation from here for six people in Australia. We did not have to fly over there. We used Go To Meeting for the entire presentation through Skype. And we had video-conferencing on. We had six people watching us entirely. They got to see the entire thing. It was great great technology”. NZ3 does not believe in too much formal control on the project plans. Team members make decisions on releasing of software builds, and inform clients and offshore teams of their progress. NZ4 The project manager of NZ4 said that they do not have much documentation or status reporting strategies in place. The project manager said: “We draw our requirements, scan them and post the pdf on the test server”. Thus NZ4 uses minimal documentation process definitions for reporting on the project status, changes implemented and other configuration management practices. NZ4 uses a VPN to connect the two teams between Auckland and Hyderabad. Both the teams use the portal’s discussion forums or commonly used tools such as Skype to communicate with each other. The study finds NZ4 to have the least standardised processes amongst all the cases, and with no formal processes for retaining the evolving knowledge into a common enterprise repository, which could be reused by similar projects. NZ5 NZ5 management places a lot of emphasis on maintenance of a centralised repository for document management and control. The centralised repository is also made available to clients, contractors and subcontractors with read only privileges to keep them in the loop over a customised portal (implemented through Microsoft SharePoint). The document control in the repository is managed by the project manager alone, where the design scope is elaborated and frequently updated. This helps to remove ambiguity and brings about more awareness of the project status to all the team members. NZ5 told of earlier situations where client requirements were not met, because of lack of 209 documentation control over the portal. Now, they have a centralised formal control over the portal, and document upgrades are managed with strict discipline. Project management was described as “understanding people’s expectations and managing those expectations”. NZ5 uses virtual technology or groupware tools very formally, and the documents are “sanitised to a certain extent”, as they are also shared by clients and partners. Visibility in work processes is br ought about by hosting a prototyping environment, in combination with documentation to bring a deeper understanding of the project. They used a combination approach, i.e. documentation followed by prototype and a telephone conference to reach a common understanding between distributed teams. The project manager remarked “In all honesty, the requirements of documents can be quite lengthy and daunting for our clients and so the prototype approach which follows is a better way because it more tangible. Clients login into the prototype environment with their username and password and we quite often supplement the prototype interaction with a phone call so that we can talk them through”. IN1 and IN2 Both the organisations IN1 and IN2 have many international certifications, and thus maintaining strict documentation of all their activities is an essential part of their certification process. The senior project manager of IN1 observed: “If it can’t be documented, it cannot be transferred. We need to explain our actions.” The project manager of IN1 also said that documenting brought in a “sense of ownership” amongst developers, as they could add relevant experiences to their knowledge capital. Moreover, it also brought a “sense of knowing the next correct step as it is listed in IN1’s document checklist”. The project manager of organisation IN2 explained the documentation of their activities: “If a decision is made on a system, we need to clarify the rules – the whats and the whys – because we have so many things to worry about before we can bring the system into the maintenance mode. The whats and whys provide us 210 with an opportunity for improvement. You can only do what you know, so validation of the new process is important. This also involves rigorous methods of paper and pencil where we need to test on confirmed data rather than on just test data. So validation process is rolled out for a pilot, and this is also confirmed by paper and pencil and this may take 7 days. Very often the customer’s engineer is also involved, and we also pool in our resources…..After a while we document the whole process, mentioning the tests which passed and failed. What steps have been closed as OK and what steps are still open. How we are addressing the open steps, as there is no generic solution. We fill in a FMEA19 template jointly, and this is a part of the work in progress document. The FMEA is a ranking on reliability and other test compliance issues. All this is audited internally and could also be checked by the external auditors. So, yes documentation of all our work is done in detail but our work is quite complex and requires such detail.” Another remark by the chief technology officer of IN2 to explain their heavily documented processes to capture knowledge both in paper and electronic form was: “We are still in the signature raj20. So, paper work cannot be ruled out” Both IN1 and IN2 extensively utilise VP Ns as a communication medium between offshore groups. Moreover, they each enforced strict discipline and have predefined rules and procedures for software configuration and control practices. Servers and backup servers are kept under strict physical control, and privileges on project tasks are identified and specified by their network administrators. They had archival policies and procedures, and IN2 displayed bar charts of their network management practices such as quarterly measurements of server uptime, LAN uptime, VPN uptime and Internet bandwidth utilisation in their network administrator’s office. Both the large Indian organisations emphasised the use of virtual technology tools and said that they used many such tools which were both proprietary and also bought off the shelf. These tools helped to coordinate activities both formally and 19 FMEA stands for Failure Mode Effect Analysis 20 “raj” means “rule” in the local dialect (Hindi). This is derived from the word “Raja” which means “King” or “Ruler”. 211 informally. Developers used the discussion forums extensively, and helped each other to understand the various software modules which had to be integrated together. Later, at each defined milestone in the product life cycle, a formal report is made to show the progress of work in the related clauses of their ISO documents. These documents are printed and stamped as “True Copy” to be placed in the ISO document library as proof of their activities for auditing purposes. These documents are then kept under the librarian’s supervision, and have to be re-issued through a request note if changes are to be made. Both organisations IN1 and IN2 need to comply with such strict policies, as part of their ISO accreditation processes. IN3 IN3 uses many virtual technology tool s over the VPN, such as MSN messenger and Skype to conduct meetings and schedule discussions between distributed teams. Besides, IN3 have some standardised documentation processes in place, which are uploaded in the organisational portal, and can be accessed by distributed teams and also by the customers. They prefer to show the work status through the organisational portal, rather than sending weekly reports to the customer. The CEO commented: “We don’t worry too much on documentation – it is inbuilt within the software development process”. The project manager added “Quality is embedded in process, code is written accordingly and documentation done along side. Your systems manual and related documentations need to be clear……… We have direct connectivity with our customers through a VPN. So they are 24/7 online and can check what is going on. Now they come and tell us at the right moment that what we are doing is wrong and needs to be corrected. The impact of that mistake is immediately taken care of. So with our customers we have realised the best thing to do is have a VPN. We also don't have to provide weekly or fortnightly reports because they are available online. The conventional system of generating reports is meaningless because we can flavour the reports nicely by saying that though we are slightly back we have taken action to make sure it happens. This is not preferred anymore. Let the customer see for himself what is 212 happening where the development process is stuck. And let me tell you - the customers appreciates this. We also discuss on MSN, and if voice communication is required then we use Skype. The communications costs has come down so life is easy. I agree that one to one direct meetings are the best way to move forward but not possible, so the next best thing is one to one meetings through Skype. We have established rapport with our offshore teams and know what they are trying to tell us. Most important because they have been provided VPN connectivity, they write down their ideas – so there is no loss of communication due to misunderstanding. So we believe in very precise communication and not unnecessary documentation”. The project document often referred to during the interview was the Service Release Agreement (SRA) to monitor deliverables. The SRA is prepared after a thorough review, and is kept in the centralised enterprise repository to keep the customers up to date on the work status. However, some overruns have occurred in the past due to changes made by the developer, requests made by the client, or sometimes simply due to wrong planning. Now IN3 has initiated control measures, and have defined a new managerial role called the life cycle manager for project management and control in the knowledge repository, and the life cycle manager is now responsible for any major changes in the project progress. IN4 The management of IN4 considers documentation and formal project reports to assist in the status tracking of project s and ensures smooth flow of knowledge across organisational boundaries. The COO stated that written documentation helped in bringing awareness to all sides on what is expected from them. He added: “We have other measurements to track the project and measure percent completion. And we drill down tasks very very finely. The more we drill down the more accurate the estimate. So we go through a lot of detail in planning. We don’t gloss over big tasks but the more granular and elementary the task, the better are the chances of our estimates being right. This is done at start of project and is also reviewed constantly. I am very careful and may be very rigid about measuring where we are.” 213 The developer explained that they had formally defined processes even through the organisational portal between the distributed teams. He said “Enhancements and defects all go through a proper channel. Because today everything is fine and all goes well doesn’t mean that we won’t document it. We later have meetings where we discuss the total number of defects that we came across, or why certain changes were made – to understand what boosted our performance and what the problem areas were”. The organisational portal is also used for discussion forums, and as already mentioned in Chapter six (refer section 6.4.1.1), sometimes disagreements have occurred during the discussions, and then senior management intervention is required. The tools used by IN4 to track project status are Seapine CM and TestTrack. The project manager explained that these tools “have tracking methods that can capture all the test cases of all the projects from build to build and module to module………We have also created a functional validation matrix which refers to all the test cases and see how it varies from build to build, so it gives us better productivity”. IN5 IN5 believe in project documentation to ensure the smooth flow of knowledge and have specified many document templates. Some of the documents which were mentioned during the interviews are MRD (Market Requirement Document), TRD (Technical Requirement Document), ISD (Implementation Specification Document) and LD (Learning Document). Developers too have an acceptance of the documentation required, as is evident by the comment made by a software team member of IN5: “The documentation is essential for the company – so we have to do it. We don’t mind it… the good and the not so good go together.” IN5 also uses a communication tool (i.e . PVCS) to communicate with the offshore team members. One developer also showed the researcher how, on querying the PVCS tool, the files and the segments which have been changed are displayed along with the reasons for this change. 214 IN5 follows a formal method in which a “maintenance request (MR)” is proposed for any change, which is entered in the PVCS tool. The project manager explained that the MR helps to ensure traceability throughout the software development process. The MR request number and details are signed into the portal by the project manager and not by the developers to prevent any inadvertent changes. The allocated developer can now make changes on the software. Also, there is a practice to put in a comment as follows “This change has been done by [developer name]”, so that the developer feels more accountable for the change. The tool Bugzilla is also used to capture errors made during the development process. 7.3.2.2 Summary of software project management processes The case data reveals that groupware tools are used extensively by all the ten vendors for management of project tasks across offshore groups. These tools have been installed with defined process roles and individual responsibilities to be used by teams to share their local knowledge. However, the formalisation of structures described within these portals varies with different vendor groups. But the general observation is that the Indian vendor organisations used more formalised network structures to coordinate project tasks across distributed development centres than the New Zealand vendor organisations. This is explained in more detail as follows: Three vendor organisations (NZ2, IN1 and IN2) have employed stricter control on the project management practices as compared to the other offshore vendor organisations. However, the reason for strict control varies for these three vendor organisations. NZ2 have defined strict access controls to their organisational portal as they deal with confidential medical data of clients, and need to be careful that the client data is not used inappropriately by their offshore partner. Hence formalisation at NZ2 is associated with the nature of their program tasks (Adler et al., 2005). On the other hand the two large Indian vendor organisations have many international certifications (e.g. CMMI) for measuring their process maturity, and are audited by external agencies on the process controls employed by them. Accordingly, these formal practices form an essential part of their certification process. Critics of CMM have 215 also identified too much formalisation and standardisation associated with these certifications (Adler et al., 2005). Next, the case data reveals that the two New Zealand vendors NZ3 and NZ4 have defined the least formalisation in defining controls for their processes. The strategies to manage volatility of requirements in soft ware designs for the case of NZ3 and NZ4 has also been discussed in detail in the previous chapter (refer section 6.4.3). These vendors do not feel the need to impose controls on documents, groupware tools or other configuration practices for management of project tasks. Moreover in both these cases, individual team members are themselves responsible for realising their project schedules and releasing software builds, rather than having to adhere to a formal project work plan. The other five vendor organisations (i.e. NZ1, NZ5, IN3, IN4 and IN5) have defined some formal control over their processes, though they are less rigid in their implementation. They all consider project management practices to have some reporting systems to eliminate hidden surprises, which may impact the project schedules negatively. Accordingly, they utilise a central repository for sharing related project documents and this repository is managed centrally by senior managers or administrators. The common repository ensures that all team members have access to same designs, standards and other related project documents, which helps to identify interrelated activities and align expectations across distributed teams. Agerfalk and Fitzergerald (2006) have put together commentaries from practitioners involved in global software development. Many of the practitioners cited in the commentary have identified flexible processes with less formalisation in project management practices, similar to the practices adopted by five vendors in this study, namely, NZ1, NZ5, IN3, IN4 and IN5. 7.3.3 Staff attrition management Software development is a knowledge intensive task, and the developers’ skills are becoming increasingly specialised in their particular area of discipline. Enhancement of developer skills and expertise are based on their past experiences and the 216 complexity of the software projects they have been involved with. Experienced employees are aware of the organisational knowledge assets and the processes associated with the application of these knowledge assets efficiently in software projects. Organisations have realised the importance of skilled and committed workforce in a knowledge based industry such as software development. The knowledge based organisations are at a great risk of losing their professional advantage, in the event of skilled employees leaving their organisations. They offset this risk by gathering the specialised knowledge from individuals (or knowledge agents) into some explicit work structure, so that the knowledge could then be abstracted from the expert into some form of organisational artefact. The artefact is then embedded in the organisation’s work practice as an explicit knowledge asset for reuse in other projects. In software development, knowledge building starts with recognition of the importance of the human capital, and its links to organisational tools and artefacts. An analogy to the importance of humans versus organisational artefacts was described by the chief technology officer of IN2 as being like a horse and a cart. He said that putting artefact/technology/support tools ahead of people was like putting the cart (artefact) ahead of the horse (people), and asking the cart to pull the horse. However, he also emphasised that the importance of the cart cannot be ignored, as it carries the load (knowledge) to be transferred. Thus, both the horse and cart support each other, and maintaining a balance between both is crucial. The section examines how vendor organisations (agencies) cope with management of their human knowledge assets (agents). Staff attrition has a huge impact on organisational structures and processes as new teams are formed when some individuals leave and others join the organisation. The new staff have to be trained, while the leaving staff’s expertise has to be retained in some form in the organisational knowledge repository. Staff turnover is an unavoidable part of knowledge-based agencies, and vendors were queried to understand the practices to institutionalise individual knowledge into the organisational knowledge domain settings. 217 A summary of practices employed by software vendors to internalise knowledge acquired by individuals into their organisational domain is given in Table 42. Table 42 Practices for managing staff attrition Practices New Zealand organisations Indian organisations Knowledge repositories (e.g. peer reviews, use of established templates, libraries) NZ1, NZ2 and NZ5 IN1, IN2, IN3, IN4 and IN5 Developing employee capabilities ⎯ In-house training, induction NZ2 and NZ5 IN1, IN2, IN3, IN4 and IN5 ⎯ Training from external agencies (tertiary sector, consultants, certifications) NZ3 IN1, IN2 and IN3 ⎯ Rewards NZ3 IN1, IN2,IN 3 , IN4 and IN5 The vendor practices have been described with extensive use of interviewee data from interview transcripts and have been contextualised with knowledge processes associated with the SECI model in the next section. 7.3.3.1 Case data report on staff attrition management This section describes the practices associated by the vendor management to encourage their developers (or human assets) to share their experiences and skills to create new knowledge assets (or artefacts) . The vendors were queried on incentives offered to establish a collaborative culture, which involved conducting training, gathering of insights from peer reviews, and awarding rewards for sharing insights, amongst others. The Table 43 gives a brief overview of the staff attrition during the time of the interviews. The percentages given in the table are as expressed by the vendor’s senior management. However, the study realises that the figures may not be exact, and could be subject to interviewee biases. 218 Table 43 Staff attrition figures New Zealand organisation Indian organisation Average attrition = 21% NZ1 - 50% NZ2 - 20-30% NZ3 - -- NZ4 - 30% NZ5 - -- Average attrition = 27% IN1 - 25% IN2 - 15% IN3 - 25% IN4 and IN5 - 30-40% Table 43 shows that the average attrition rate in New Zealand software organisations is 21% while in Indian software organisa tions, it is 27%. Interestingly New Zealand vendor organisations have the largest variation in percentage range for attrition value ranging anywhere between zero to fifty percent. The vendors’ practices to manage staff attrition are now discussed. NZ1 As mentioned in Chapter six, NZ1 has recently undergone a major restructuring move in which they have partnered with PartnerNZ1. This move had resulted in 50% staff turnover during the time of the second interview in August 2007. However, during the first interview, the project manager had explained that NZ1 encouraged its staff to enrol and add professional skills to their qualifications, by paying the course fees if an employee passed some professional exam. They also maintained a library of books which could be used by the developers for further study. However, during the second interview, the recently appointed general manager said that restructuring and other management changes has been the reason for the large attrition rate at NZ1. He commented “certain staff members who have left were valuable while some should never have been here in the first place”. The politics of downsizing and restructuring may have resulted in low morale during the interview period. Hence, the emphasis on motivating employees remains inconclusive for NZ1. 219 Also, as mentioned in the previous section (refer 7.3.2.1), NZ1 conducted peer reviews and have established some standards – though not very formalised – to bring about project awareness to the development teams. NZ2 NZ2 are in the business of maintaining the confidential medical records of thousands of users in Australia and New Zealand, and hence they have very secure organisational artefacts and policies in place. They use standard checklists and templates over separate server configurations for customers and development teams. This practice creates awareness of project details into a common shared repository with explicitly defined organisational artefacts, and makes them less reliant on individuals. NZ2 also said they offer initial training to new employees on their work practices. The managing director confirmed “Our clients are doctors in Australia and New Zealand, and we deal with their confidential data. So we must have a plan before we can delegate work at the operational level……When a person joins us, we train him on our PDP [product development process], and he works with a senior team and learns about our processes. We believe in having strict policies in place mainly because of the confidential nature of our data”. The project manager confirmed that employee turnover rate at NZ2 has been quite high, and was appreciative of additional employees working with their offshore Indian partner PartnerNZ2. This is evident from the following statement: “One of the reasons to have a partner in India is that they provide us the ability to stay on competitively, and secondly they enable us to increase or reduce as we see fit – which you cannot do in Australia or in New Zealand. So that flexibility of increasing staff or reducing staff is a very big benefit there. At the same time we can recruit a much wider skill set than you might get here purely because of the IT exposure. Attrition is not too big a problem there. Even here the attrition rate is 20% - 30% in some areas. Human beings in this day and age want to move … When people move off we manage our work by proper documentation, by knowledge transfer, and by having an appropriate induction program – and in 220 this way you have much a more rigorous knowledge continuity progress like knowledge bases. We plan properly so that looking at knowledge bases is now a routine job. When people understand them as a routine, then they are able to use them”. The project manager made a general statement that employees are encouraged to upgrade their skills, though not much information was shared on the specifics of how employees are encouraged by NZ2. NZ3 The project manager of NZ3 said their staff are very motivated and eager to learn new technologies “Adding a new technology such as adding text message to or from mobile devices……so our staff gets very excited on using new technologies. The biggest change which is happening now is changing VB6 to Dotnet. It was a different framework then but coding is the same in VB.Net. The market changes one language to next – so we learn as we move. And the client is not paying for the learning on the job”. He added that software development includes “both practical and theory”, and if a developer has done “500 to 600 hours of managing projects, they themselves get trained – so we are planning to just get our guys finish tertiary education and be Microsoft Certified MCAD”. Moreover, as mentioned in Chapter six (refer section 6.4.2.1), NZ3 also offered financial rewards or “bank points” to their staff in New Zealand and annual bonuses to their staff in Vietnam. NZ4 NZ4 do not train employees before being put on the job, and said that their developers learnt on the job. The project manager said that their “owner-cum- shareholder also believes in having a bit of a dabble with code, and he helps out if someone gets really stuck up”. The owner of NZ4 is considered as the repository of knowledge by the development teams. 221 The project manager of NZ4 also confirmed that their staff turnover is rather high, and the strict deadlines with many projects running simultaneously could be a factor for the high turnover. Moreover, a developer stated that the time difference with their offshore partner in India meant that sometimes the PartnerNZ4’s developers would call them after hours. This was not looked at favourably by the team members situated in Auckland. The developers also expressed annoyance at the staff attrition of PartnerNZ4, which meant that they often have to explain the project “handover” to the newly arrived staff of PartnerNZ4. NZ5 Organisation NZ5 considers explicit documentation and training as a core part of the development process. They prefer to train staff with their defined documented processes rather than hire very experienced staff members who would work differently from their current style of working and re-define their practices. The director explained: “We do not just start hacking things into a solution without a proper document. Also we do not expect the client to really understand what he wants and so it is difficult for a service provider to insist on clear requirements from the client. Fortunately, we make solutions for large organisations which are quite mature and understand the need for a structured requirement capture process and a formal record of that process, which ends up being a requirement document. This document clarifies that we have understood what the clients have been telling us. Now our development team picks up from there……Our developers have processes and set ways of doing things. …We also measure in our own way. Every project we do has a post-implementation review and we feed that into the process. We still make mistakes, but we learn from them. It is people, process and technology that make up the solution, and we value all three of them equally”. The management of NZ5 does not have a staff attrition issue. The director considered that “professional training” and “having clearly defined processes help to lay out expectations” resulted in a motivated and empowered staff. 222 IN1 IN1 is certified by many international agencies, and hence maintaining explicit documentation of their business rules, work flows and processes is an essential part of these certifications. They have built an organisational artefact called Solution BluePrint (SBP) which forms the basis of all their software development activities. The SBP is regularly updated, and has pre-defined templates of processes to be followed for design of any product. The project manager of IN1 said that SBP is the “crux” of all their software development tasks, and training on SBP is given first before developers are put on the job. The SBP outlines each small task required for various iterations of the deliverable, and guides developers on how to comply with relevant certifications. The SBP has many associated documents for each functional area, and these documents are regularly reviewed by management and operational teams for further improvements. IN1 have also formed an academic alliance with a recognised tertiary sector from Pune and overseas institutes, and offer a Post Graduate Diploma in Business Transformation. The SBP also plays an important role in the diploma study and developers are keen to enrol. Other financial rewards too are offered to developers based upon their individual and team achievements. IN1 have posters displaying their 5F culture “Fast, Focused, Friendly, Flexible and Fun”, at many places in their office premises. The human resources manager showed the researcher one of these posters and told of an interesting aspect of their 5F culture, which included informal social gatherings of senior and junior management, termed as “Pizza and Coke Meetings” where senior management have informal discussions with their development teams. These gatherings are meant to encourage developers and helped the senior management to recognise each developer’s expertise, thus fostering a sense of professional worth for the individuals involved. IN2 IN2 has People CMM level 5 certification amongst other certifications. PCMM deals with the best current practices in fields such as human resources, knowledge 223 management, and organisational development. It provides guidance to organisations to improve their processes for managing and developing their workforces through maturity of their workforce practices, establish a program of continuous workforce development, set priorities for improvement actions, integrate workforce development with process improvement, and establish a culture of satisfied and empowered employees. IN2 has a very low attrition rate, which th ey said was 10% less than the prevailing national figures of 25 – 30%, and had numbers on score cards to show their employee retention figure based upon the number of job applications received, and other employee satisfaction metrics (which were accumulated through anonymous surveys). Moreover, IN2 also has a “blanket rule” policy of not recruiting people who have previously left employment from IN2 or any of its sister group of companies. This could also be a deterrent for employees not to leave IN2, as IN2 is a small part of a hugely respected conglomerate group of industries in India. However, IN2 also takes care to keep their employees motivated, as is evident by the project manager’s remark “Our programmers develop a complex if they are not sent overseas, so we send them after three years. If we don’t, someone else will”. Besides being PCMM certified, IN2 ha s many other quality certifications, and hence processes are documented in explicit detail. Moreover, the project manager explained that project reviews are held soon after the completion of projects when memories are still fresh. These reviews helps all stakeholders to understand the lessons learned from the project, and sometimes resulted in redefinition of best practices, or identification of fuzzy areas where some of the processes either did not work, or could be improved. Moreover, organisation IN2 had named their review group team “K-Next”, implying the continuation of, or “the next”, knowledge. IN3 The project manager of IN3 stated that “anyone who is a new hire goes through the training. The first things we start with about is our culture, our HR policy and 224 later we take him into technology and business areas”. He also added that developers often lacked interpersonal skills rather than technical skills, so IN3 gave developers training on interpersonal skills. IN3 regularly contracted such training sessions to local consultants who gave in house training on the non technical skill sets. Interactive training sessions are held with voice recording of presentations and discussions on non technical issues. These recorded conversations are then played back to the groups, and the group analyses the tone, accent, pronunciations and such like. The project manager commented “The programmers quite enjoy when they can themselves see the difference”. Friendly cricket matches are also held between local software organisations, where family members of employees are also welcome. The CEO explained that employees are rewarded financially based on their past achievements, contributions and meeting of deadlines, amongst others. He explained: “Suppose he [the developer] gets Rs.100 as salary. The Rs.70 is fixed and Rs.30 is based on certain performance parameters which we have defined. We have a very transparent system, and so he [the developer] can see his performance himself. This is a computer based system which we have developed ourselves and if he does more than 100% then we give him that amount also. So sometimes people here get as high as 120%, though generally a maximum a person draws is about 90%. This is of course confidential and only goes into the payroll”. However the attrition rate of IN3 is quite high and hence explicit documentation of work processes is maintained in a centralised repository. The CEO explained: “If you develop a system which is person dependent then you are not managing. So focus has now shifted to HR management, and this is not something to be taken for granted anymore. Now organisations should have good HR management in place. Software industry has now moved to this gear. So if a person leaves an organisation, we may have a problem for five to eight days but it is not a catastrophe so that everything comes to a halt. But there is a delay. Now we have planned our work for 18% attrition and we try to structure our processes so that a process would be executed independent of that person. So internal systems 225 available have standardised processes, and we build in buffers within our development work so that the target dates are not missed. Our policies are not shock proof but they help us to recover fast from such shocks. This is important, and this is what I call project management.” IN4 IN4 lays emphasis on maintaining explicit documentation of tasks and also on training their employees. This is felt necessary due to their high turnover ratio and intelligent youthful workforce. The chief operations officer of IN4 explained: “Software industry does not have a paradigm for comparison. The technology I started with 20 years back is very different. Every two years technology changes so all yardsticks in terms of estimates and work done is never the same. In an automobile industry if a job earlier took one hour - then at most it will come down to 40-50 minutes because of technology improvements. Here the paradigm changes completely. Then the people who are working with you are young and each person is different and then again their measurement yardstick is different. You generally don’t have people with too much of work experience working with you all the time. So we track projects very carefully, and measure everything. There are three measures we use to track project delivery and obviously the biggest thing is customer feedback. I am very very strong on customer feedback. Other measures we have is a measure of employee turnover ratio and the third measure is training. Training is very critical and important for each employee. We have started now measuring training time which is spent per employee. We still have a long way to go but we have begun such measurements”. This statement was confirmed by a young developer who commented “This is my time to learn and learn new things – I will go wherever the learning is, and of course where the money is”. Other methods to motivate employees are through financial rewards, such as having a fixed and variable component in pay, and other spot awards for low defect rates, meeting of deadlines, and other value addition exercises. 226 IN5 The management of IN5 is very proud of their product, as is evident by this comment “Our strength is not the software of that but the core algorithm behind our product”. The managing director explained “IN5 is a product company and not a project company. For a product company there is a department called product management and they talk to client - then they give information to teams here. It is not a project that you have to talk directly with the client. We do both customisation and development of new models here. For product development, continuous enhancements are required”. The project manager also explained “Standardisation is a part of our repository. So with the repository we use content management tools and we store everything there. This is accessible to all users”. On the question as to how IN5 empowered their employees, the project manager said “Attrition is an industry wide problem because there is a lot of demand for trained man power. After two three years when the experienced people become useful, then we have to always work on retaining these people. That retention is always such that competition has to be in line with the market. So we do a market study, find out what salaries are going on. You have to provide people with meaningful and interesting work and you have to sometimes rotate the work, so that they see new things and are not bored”. Recently IN5 had sent their development teams along with their families to Goa (a beach resort in India) for a holiday to have a team building exercise. Besides social interaction, IN5 also believes in financial rewards and they too have a fixed and variable component in their employee salary structure. 7.3.3.2 Summary of staff attrition management The section has mostly considered nine cases, since NZ1 was going through a massive re-structuring process after having just forged a new relationship with an Indian partner during the time of the interview. NZ1 had been affected by 50% attrition, since the new management had taken over the organisation. However overall, the staff attrition percentages have been found to be higher for the Indian vendors as compared to the New Zealand vendors. The high attrition rate of Indian 227 software development organisations has been reported as a major issue in literature (Dibbern et al., 2008). Two New Zealand vendors NZ3 and NZ5 reported zero attrition for the previous two years. However, one Indian vendor (IN2) has low attrition figures and they have used strategies such as not re-hiring individuals who had earlier left their organisation and using people capability maturity certifications (PCMM) to promote a culture of satisfied employees. Previous research identifies the implementation of PCMM in organisations helps the software professionals to better manage workplace stresses and brings about a shared understanding of knowledge- based processes involved in software development activities (Rajeswari & Anantharaman, 2003). The other six vendors comprising of two New Zealand and four Indian vendors (i.e. NZ2, NZ4, IN1, IN3, IN4 and IN5) have high attritions rates, which ranged anywhere between 20% and 40%. The case data further revealed that employee training is considered essential by all of the vendors with the exception of NZ4. Organisation NZ4 considers their software development work to be rather straightforward, and hence said that no specialised training is required by their employees. However, the remaining organisations (with the exception of NZ1 for which data has not been collected) have relied on some form of training to introduce employees to new technologies, development methodologies and processes and also to their work culture. Two Indian organisations (i.e. IN2 and IN3) also laid emphasis on training by external agencies such as tertiary educators and consultants for improving their employee’s technical, English speaking and other social skills. Rajeswari and Anantharaman (2003) have identified developer’s stress during client interactions when the client belongs to an English speaking nation and the vendor belongs to a non English speaking nation. The case data also reveals that all the five Indian organisations and one of the New Zealand organisations (i.e. NZ3) offered financial rewards and other incentives to motivate employees and foster long term commitments. These organisations rewarded their employees for any value addition to the organisation’s knowledge capital. In this 228 manner, organisations extract the tacit knowledge of their employees and try to reduce the impact of staff turnover on their project commitments. Rewards encourage employees to share their contex tual knowledge which is then codified into artefacts (knowledge asse ts) in their repositories fo r reuse in other projects. However, despite the incentives offered to employees, the attrition rate of the Indian organisations is still high. The senior management have identified social meanings to the attitudes of their knowledge workers and are making efforts to control staff turnover. They have started to offer incentives such as overseas assignments, training of social skills, or tertiary qualifications to provide motivation and increase their employee confidence. The vendors believe that these practices result in a satisfied, content and committed workforce, which eventually leads to low staff attrition. Review of standardised processes is also considered essential by all the organisations with the exception of NZ4, and post implementation meetings are held to identify and document new practices. These knowledge sharing practices are encouraged so that individual experiences can be recorded to enhance organisational routines and processes, and reuse of knowledge capital to further revise their best practices. Use of standardised processes and routines also reduces the reliance on individuals who may suddenly leave the organisation. Dibbern et al. (2008) warns clients of additional costs associated with offshore projects due to knowledge asymmetry between vendor and clients, or due to high staff turnover resulting in lack of “absorptive capacity” by vendor teams. The vendors are also aware of these issues and are adopting strategies to externalise, create and internalise knowle dge into a centralised repository for reuse and increase their “absorptive capacity”. 7.4 Important drivers for management of explicit knowledge This chapter has explained how offshore software vendor organisations are actively involved in externalising, creating and internalising explicit knowledge into organisational repositories. They have realised the interdependent and participative nature of software development work, and are actively involved in defining processes 229 for management of tangible artefacts (such as using quality certifications, controlling project scope, meeting of schedules, setting access rights on portals, implementation of project reviews, giving incentives to employees). Detailed descriptions of practices have been provided to offer new insights on vendor perceptions towards certifications, project management and staff attrition management within the two country contexts. Estimates on attrition figures in software development firms have also been provided for both the countries. Regarding certifications for quality processes by international agencies, the chapter shows that the large Indian organisations cons ider certifications to be useful. None of the New Zealand software vendors have cer tifications. One New Zealand organisation (NZ5) initially had ISO accreditation which has now lapsed, since they do not consider such accreditations to be important any more. Another New Zealand organisation (NZ1) also considers these certifications as “useless pieces of paper”, which do not add value to their software development processes. However, some of the offshore partners of New Zealand or ganisations (such as PartnerNZ1 and PartnerNZ3) think these certifications are helpful and should be used to highlight their professionalism. On the other hand, the two large Indian organisations consider certifications bring in organisational maturity, and help to build their reputation in the international market. One Indian organisation (IN5) has many patents, which they consider to be more useful than obtaining process certifications. Thus three of the five Indian vendor organisations use some form of external measure to highlight their success stories, as opposed to none of the New Zealand vendor organisations. Groupware tools or virtual technology tools such as virtual private networks between distributed locations to host groupware packages, discussion forums and organisational documentation are considered essential by all the ten cases who participated in the study. However, with the exception of two New Zealand organisations (NZ3 and NZ4), the other eight organisations considered that the groupware tools should be maintained with some centralised formal control with standardisation in project management related activities. Moreover, the two large Indian organisations (IN1 and IN2) used very strict controls over their project 230 management processes (e.g. documentation) which is also a requirement for maintaining certifications. Empowering employees in order to foster long term commitments and knowledge sharing is actively pursued by eight organisations. All of the five Indian organisations and one New Zealand organisation (i.e. NZ3) offered financial rewards to employees for value addition to the organisation’s knowledge base. However, staff attrition has been high for almost all of the organisations. Overall, the attrition in the Indian organisations is found to be more than the New Zealand organisations. One Indian vendor (IN2) used guidance from its People CMM level 5 certification, and also used strategies like refusal of re-employment to persons who may have left their employment or any of its sister group of companies previously. The chapter has thus established the knowledge sharing concepts in the SECI model for offshore development practices in two country contexts. Vendors have defined a mix of socialisation, externalisation, combination and internalisation processes to manage their explicit knowledge artefacts. Further, rich descriptions of vendors (agents) work structures have been provided to give a better understanding of practitioner’s real world settings. 231 CHAPTER EIGHT – Micro Level Analysis for Relationship Building Strategies 8.1 Introduction Offshore software development involves realisation of knowledge intensive tasks across cultural boundaries over the telecommunication network. Diverse cultural groups of vendors and clients make efforts to establish collaborative business relationships and fully leverage each other’s capabilities. This implies that both sides have to jointly implement a relationship building strategy and be aware of the other side’s apprehensions towards knowledge sharing with each other. However, Dibbern et al. (2004) assert that there is a “relative lack of research directed towards an examination of the relationship between the outsourcer and the customer ” and future studies should extend “the examination and analysis of that relationship” (p. 88, italics in original). This chapter describes the work practices associated with the relationship building strategies in the OSD environment to answer the third subsidiary research question: How does culture affect vendors’ relationship building strategies with offshore clients or partners in the virtual environment across organisations and nations? The chapter begins with an overview of the key success drivers identified as the unit of analysis in the conceptual framework (refer Table 27), which affect the relationship building strategies across distributed locations. Empirical data collected from each vendor has been described for the identified drivers in separate subsections. The practices associated with each driver for the ten cases are analysed to give an overall picture of the vendors’ relationship building strategies. The chapter concludes with a summary of work practices associated with the key drivers for building effective business relationships across diverse cultural groups in the virtual social spaces (VSS) for the ten vendor organisations. 232 8.2 Drivers for relationship building strategies Relationships are bi-directional, and affect both parties – client (buyer) and vendor (seller) – but in the absence of co-location such as in the VSS, both the parties try to mitigate their risks by adopting practices for building effective relationships. The virtual environment of off-shoring demands that both parties carry out their work commitments over virtual technology tools (VTT) which lack the visual cues inherent in direct face-to-face meetings. The visu al cues of traditional meetings between business parties involving physical appearance (including gender, age, race and overall looks), body language (including faci al expressions, gestures, posture and nods), and seating arrangement between the parties is replaced by computer mediated interactions of the VTT. The visual cues help to re-assure parties of each other’s concerns on shared business risks; however this type of re-assurance is missing in the VSS. Relationships between parties (clients, bu siness partners and vendors) depends upon situational factors such as sense of security, similarity between parties and concern for each other, and these factors are key to building trust in relationships (Hurley, 2006). Vendors have realised that clients are more likely to continue with vendors whom they can trust and depend upon, and they are now adding relationship management, organisational change management, and customer advocacy to their portfolio of skills (Moore & Martorelli, 2004) skills to build trusting relationships. In OSD, the interdependent and iterative nature of software development tasks are spread over different technical, social a nd temporal spaces and these modular tasks are shared by knowledge workers who may have never met each other. To minimise the risks associated with VTT communication, organisations have defined new structures for interaction. Some structures to build meaningful interaction involve direct dialogue on common locations such as centralised project management offices; hiring of an intermediary consulting firm as a broker, guide or legal expert; travel to offshore vendor or client locations to enable understanding of each other’s organisational processes; and negotiating appropriately (Gold, 2005; Heeks et al., 2001; Jennex & Adelakun, 2003; Rottman & L acity, 2006). Successful relationships 233 (synching) creates trust between the parties involved leading to long term business relationships while unsuccessful relationships ( sinking) leads to lack of trust and uncertainty in the length of the relationship (Heeks et al., 2001). For the vendor, sustaining synching relationships will help in building up their reputation and increase their business resilience, to eventually bring about shared understanding of interrelated tasks despite the virtual relationship. Vendors have recognised that interaction at operational level between team members of different cultural groups helps to create a mutual understanding of their joint commitments. This helps to change attitudes towards knowledge sharing between local and offshore team members and also helps to remove the exclusiveness and stereotyping associated with different cultural and organisational groups. This study finds that vendors highlight their past experiences and project success stories to bring about a positive perception of their competence, work accountability and professionalism to the offshore teams. This also helps in building their reputation in the international offshore market. Moreover, vendors have realised the need to identify the organisational context in which different cultures operate to form stronger social bonds so that the virtual environment embodies the interactions associated with co-located parties. Vendors use many strategies to bring visibility in their work processes to make the offshore clients/ partners less anxious about issues associated with geographical distances. Practices such as direct face-to-face meeti ngs, documentation, centralised offices near the client/ partner’s destination, deployment of employees amongst others help to bring visibility in work processes. Such pr actices help in creating transparency of associated tasks to build trust and this makes the client feel less vulnerable in their business dealings with offshore vendors. Table 44 gives a summary of drivers identified as units of analysis from the conceptual framework (refer Table 27). The table also summarises the vendor practices associated with each identified driver which influence their relationship building strategies across distributed teams and diverse cultures. 234 Table 44 Drivers affecting relationship building strategies Drivers (unit of analysis) Practices associated with drivers Cross cultural interaction Bring about a common glocal (global + local) context (e.g. training on language nuances, online social networks, whitepapers on cultural aspects) Have direct interaction to share social identities across diverse cultural groups (e.g. direct meetings, deploy employees at offshore locations ) Building reputation Websites displaying lists of customers or past project successes International accreditations, patents, etc. to show organisation’s maturity Social service activities to show responsibility to their community Visibility in interrelated work processes Documentation and use of organisational portals Centralised project office near the client’s destination Deployment of employees at business partner or client locations Table 44 has been used to guide the empirica l investigation in the next section. Three units of analysis (or drivers) have been identified in the table, based upon which the next section contextualises vendor experiences to reveal vendor perceptions and concerns in the VSS. 8.3 Empirical observations on the drivers for relationship building strategies The conceptual framework (refer Table 27) identifies three drivers – cross cultural interaction, building reputation and visibility in interrelated work processes – for relationship building strategies. The section is divided into three subsections, where each subsection focuses on practices for each driver or unit of analysis for relationship building (refer Table 44). Empirical data obtained through interviews, observations and organisational websites have been described for each driver to understand which practices influence their relationship building strategies. Extensive use of interview quotes has been used in the analysis of relationship building strategies to provide rich insights of the diverse social settings and work structures. Each subsection concludes with a synthesis of key practices implemented by the ten vendors for that particular driver. 8.3.1 Cross-cultural interaction This study utilises a dynamic view of culture as “contested, temporal and emergent” (Myers & Tan, 2002, p. 24), as knowledge workers belonging to different cultural 235 groups interact with each other to share a common goal. Structuration theory has been used to understand how glocal (global and local) cultures have changed vendor attitudes and sociological structures to embrace the emergent glocal knowledge. Recent research defines glocal culture as emerging cultures or negotiating cultures, where different cultural groups share ideas and best practices to help improve understanding of each other’s local work practices (Friedman, 2006; Gold, 2005; Svensson, 2001; Walsham, 2002). Each case has been analysed to understand how cross cultural interaction takes place within distributed settings across different cultural settings. The study finds that vendors are aware of their offshore client/partner’s apprehensions in sharing knowledge, and make efforts to build a social connection across organisational domains. Vendors stated that identification of their partner’s social structural compositions helps to shape new attitudes and establish positive relationships, leading to effective transfer of local knowledge in the virtual environment. Interactions within dissimilar cultural groups help to inform each other on common values and working norms, and make them reciprocate in a manner which increases trust and builds confidence in their offshore relationships. A summary of the practices associated with the driver affecting cross cultural interactions for the ten cases is given in Table 45. Table 45 Practices for cross-cultural interaction Practices New Zealand organisations Indian organisations Bring about a common glocal context (e.g. training on language nuances, online social networks, whitepapers on cultural aspects) NZ3 IN1, IN2 and IN3 Define interactions to share social identities across diverse cultural groups (e.g. direct meetings, deploy employees at offshore locations) NZ1 and NZ3 IN1, IN2 and IN3 236 8.3.1.1 Case data report on cross-cultural interaction This section looks at the practices associ ated with cross cultural interactions, as vendors adapt to the work environments of different social and cultural spaces to build effective business relationships. Ve ndors are making changes to their work processes, as they try to overcome the cultural gaps inherent in the OSD environment. Some observations on how the ten vendors have tried to improve their understanding of knowledge flows between teams belonging to different cultural groups are as follows: NZ1 NZ1 stated that cultural difference is “the biggest challenge” in OSD. However, they said this with reference to their offshore business partner PartnerNZ1. PartnerNZ1 is jointly involved with NZ1 to deliver customised software solutions to their local clients. Their general manager explained: “I went over to India to meet the team members. A project manager who is also a team leader had also come with me and he spent three weeks with developers training them and we gave them a view of our capabilities here in NZ. We would have daily informal communication and also a weekly formal review. Later we communicated through conference calls and so we got communication servers set up with secure information messaging. Then the cultural differences came up. It would definitely be a lot easier to do development by a New Zealand team here. People there don’t ask questions openly across cultures – ‘Why are you doing this?”. I have come across many good developers but they hesitate to ask. This is a very big issue because requirements can go wrong. Another thing I’ve noticed is that they are very hierarchical - so it is expected that team leader will talk to team leader and developer could talk to developer. So I was supposed to talk to team leader and he spoke to developer. We ended up eventually talking to developer but getting there that was one issue. So the biggest challenge I feel is the cultural difference. In our case – it was hierarchy and not asking questions. So we had to do our bit”. NZ1 presently have a team of developers from PartnerNZ1 situated at their Wellington and Auckland offices. The PartnerNZ1’s team interacts directly with the local clients, and this helps to define their role and responsibility. The general 237 manager added “ It was our observation that unless we push some responsibility to PartnerNZ1, they would take no responsibility. I guess it was like they are being instructed on what to do, and we had to tell them. But now we tell them “This is your problem. Now deliver”. We have them sit down with the customer and understand what they are looking for. So now we find that directly meeting the customer seems like pushing the responsibility to PartnerNZ1 and this seems to be working very well”. NZ2 The managing director of NZ2 said that their offshore partner is doing the “coding and linear tasks”, and hence NZ2 does not feel the need to deal with associated social issues. NZ2 have earlier worked with another offshore partner who has an office in Auckland (referred to as Pilot-IN-Med in this study), and this partnership has helped NZ2 define work processes and also become aware of cross cultural differences. An interesting comment made by the managing director of NZ2 on cultural differences is: “I have lived in many parts of the world. I was born in Singapore, lived in UK and US and I understand that every country has its own issues – cultural issues. So if you try to think like a Kiwi in Australia it won’t work – because IQ, EQ, CQ21 differ. So you need to understand what works here and what will work elsewhere. If that understanding is there, then all is OK”. NZ2 management said that processes should be stated clearly and conveyed across distributed teams. The project manager said: “Once you have the methodology clear and process is clear then the margin for misunderstandings across cultures is small”. Also, NZ2 have off-shored operational tasks involving development of code and they do not have any intention to offshore “high end tasks such as customer relationship tasks” to their offshore partner in India. The director explained “We do not intend to migrate our helpdesk to India for example, but we want to have routine maintenance staff there in India. Our local staff is better trained at doing much more quality work with the customer. No 21 Intelligence quotient, emotional quotient, communication quotient 238 point taking Indians out of India and putting them here to deal with the customers here. We need to be local to have good customer relationships”. NZ3 The website of NZ3 has displayed the following message “[NZ3] people come from more than 17 countries, bringing a vast range of experience and diverse backgrounds enriching the work we undertake for our clients”. This message was again reiterated during the interview process by the director who is himself a New Zealander (Kiwi), as is evident from the comment: “We have a multicultural nationality and this firm has four owners who are – Korean, German, Vietnamese and Kiwi”. The management of NZ3 have set up a blog for their two teams in New Zealand and Vietnam which helps to project both the New Zealand and Vietnamese perspectives. The blog has white papers on cultural aspects such as “how to interact, how to minute, what to say and what not to say, when is the best time to call, what went well, what did not, which new people have been inducted into the company –so we also have set up a blog where both NZ and Vietnamese perspectives are shared”. The director of NZ3 explained how their offshore partners (Vietnamese team) “also have a snooze time. They actually asked us six months ago that they wanted to extend their lunch to an hour and half and we were like – “Why?” So they said that in the middle of the day they like to rest. So they put their heads down on the desk and just chill out for an hour. And then they are more productive in the afternoon because then it gets cooler and they had their hour of rest. Again it’s a cultural thing. If it is hot and this is their way of dealing with weather conditions then why not. So we ensure that we don’t ring them up during the snooze time”. NZ3 do not have any issues with their offshore team members interacting with their local or overseas clients. The director explained “Our clients who are having work done by our Vietnamese teams love it. In fact, one of our clients ClientA* have won the small and, medium web service excellence award this year. The * a pseudonym 239 Vietnamese team has re-written two to three of their products. I guess the Vietnamese team is working perfectly for him. ClientA loves it”. NZ4 Organisation NZ4 is headquartered in Auckland, and they also have sales offices in Los Angeles, Chicago, Shanghai, Hong Kong and Hyderabad. The management of NZ4 said that liasoning with their offshore customers is done by senior sales teams. They added that their work is rather “straightforward”, and therefore their clients do not need to interact with the development teams. The development teams are split between two locations, Auckland and Hyderabad, and they interact with each other over the organisational portal and other open source communication tools. Also, NZ4 are involved in software projects which have short development life cycle durations. The development team in Auckland said that they are handed new projects from their senior management, which are quite similar to some of the previously undertaken projects. Therefore, they do not need to interact with clients themselves. Moreover, the work is then passed over to the offshore team in Hyderabad, and the project details are explained through a conversation using Skype. Therefore, NZ4 team members said that they have no reason to be more socially acquainted with their offshore clients or partners, as “things work out fine with the drawing, pdf and Skype”. NZ5 NZ5 shares a good relationship with a global CRM software provider (referred to as PartnerNZ5 in this study), and they are the only software partner of PartnerNZ5 in New Zealand. PartnerNZ5 has many global clients such as General Motors, Amex, Microsoft and many others. Moreover, PartnerNZ5 initiates a project by responding to a Request for Proposal (RFP) from prospective clients, in which they involve NZ5’s services in certain technical areas. NZ5 thus benefit from their partner’s global position. 240 PartnerNZ5 also have other partners who help in other related technical areas. This means that NZ5 have to work with these other offshore partners of PartnerNZ5 on global projects. NZ5 said that they have no issues working with Australian or other European partners of PartnerNZ5. However, the director of NZ5 stated that they have faced issues with partners from India and the United States. He stated that in a recent project with an Indian partner, who also happens to be one of the big Indian software organisations, the Indian partner “did not give their team members authority with responsibility”. The Indian teams gave them no deadlines or commitments, and this led to the developers taking extra time to complete certain interrelated tasks. NZ5 finally overcame this issue by rigorously following up with the Indian partner on the interrelated tasks and also sending them daily reminders. Moreover with their American partner, the director of NZ5 complained that no one belonging to their American partner’s team took responsibility for their work. He added “no one took responsibility because no one wanted to take charge for a failure. To be associated with failure is a very bad thing – so people end up not taking responsibility”. NZ5 overcame this issue by giving the American team “short commitments, which were easy for them to manage”. The director commented that based upon their experiences with offshore vendor partners, he now made his own “interpretations about how they would honour these commitments”. IN1 IN1 is a large organisation which is involved in offshore software development and has offices in twelve countries including India. The offshore offices have been registered with these particular countries as separate companies to take advantage of the tax benefits of that country and also to provide clients a “near- shore presence” and not an “offshore presence”. Their website states that near shore centres help to address “data security concerns of European customers”. The project manager of IN1 said that near-shore offices play a vital role in customer relationship management, as their office staff interact with clients and later send software contracts to the main development centre in Pune. Thus, customer relationships are managed by separate offices in different countries. 241 Later developers from India are deployed for six to twelve months at the client sites to understand and document customer requirements in greater detail. The project manager stated that “clients feel more comfortable talking face-to-face” and the onsite team “gathers requirements and update the delivery guys in India”. Moreover, these team members before being sent to the client site are given a week’s training program on “what the offshore concepts are in terms of both cultural gaps and working plan”. IN1 have formed an academic alliance with local tertiary institutions which help to train their developers and make the developers aware of social and cultural aspects in the client countries. IN2 IN2 is a subsidiary of a respected conglomerate in India. Their parent group was a major industrial group before India acquired independence, and is well known for their philanthropic work. The COO of IN2 said that their “brand name helped cross all cultural boundaries”. The project manager also added with pride that their technical knowledge and expertise in specialised technologies has gained them respect amongst their offshore clients and partners alike. He commented: “We are also doing work for the big industrial groups like Boeing, Ford, etcetera. I don’t think they think of us as another cultural group, or we think of them as another culture. We are just different companies doing business together. Technical knowledge supersedes cultural differences. Our ideas and drawings with 3D tools talk and this is what customers want to hear. Our engineers often go overseas to get client requirements and it is all purely professional work”. IN2 have many offices worldwide, which provide a near-shore centre to their overseas clients. However the IN2 staff are presently more concerned with the local culture as another subsidiary of their parent group have also entered the same market segment as theirs and this has often caused confusion amongst the clients between the two vendor organisations. 242 IN3 The chief executive officer of IN3 explained their marketing strategy: “We always have per customer a representative staff over there. It depends upon the size of the project. Sometimes we may also have two or three representatives, but one person [i.e. account manager] is overall responsible over there. The reps are in charge of customer accounts and they also know the projects very well. They also control the team here. So the team here is reporting to two people: the accounts executive there and the life cycle manager here. Administratively the reps are reporting to me to see that all controls are there, but for schedules, etcetera he is reporting to the accounts manager. This is always better because the accounts manager is customer facing so he is the boss. The account representatives have two responsibilities. One, for an existing product he does the complete liasoning and so the customer does not feel that he is dealing with no one. The customer sees us there so it is not out of sight out of mind. Two, he is also on the look out to see what other projects are there with the customer. He talks to the customer and he also does a considerable amount of marketing. We have very experienced people who are trained to do technical pre-sale work. They understand the project and can relate to the technology and problems”. The CEO added that their overseas customers are “very straight jacketed” with “very structured working styles”. IN3 also imparts training on English speaking and other social skills to their developers (refer section 6.4.1.1). IN4 The COO of IN4 commented: “The challenge we had with the Canadian teams was that they were very very silo-ish. They are not very open to move to off- shoring as their US counterpart. US is very quick. But these guys were more careful to processes and less easy. Even though this is the same company here we had barriers to sharing information and them trying to let us flourish here. But maybe it is like that anywhere. They are good people who are very professional. They just need to be sure that they are not at risk. Differences are not in culture, but perception of individuals on their own job security which needs to be 243 understood. So I expect offshore development is to make sure that your customer whether internal or external perceives those risks and gets the comfort. So as far as the technical side is concerned, India is as competent as anyone else. The problems we had was when we had to work with a new product. You see I am from automobile manufacturing background and now I had to work in broadband space that is cable broadband which is very high technology communications. So it was a very different line and nobody in India had that expertise. We had to learn the expertise to get their confidence. So we did things one step at time. So in software very important thing is to identify and go with the customer. Success breeds on success. You cannot fail because if you fail once you go back a lot. Failures are not because of technology. Failures are because of relationships, methodologies and processes. That means that I need to be able to work effectively. We were all used to working in the same office – so if we needed something we just walked across. So suddenly you have to talk to someone who is miles away and you don’t know what the guy is thinking because you have never seen his face. The challenge is for them and us is to be able to articulate requirements effectively. How comfortable are they that the delivery will come out the way they want it. That was a major challenge where we had to put in a lot of effort. So that is where the senior management’s role comes in creating comfort level in acquiring the product knowledge, and that was not an easy task. But now I know offshore development is about 90% psychology and 10% technology. There are certain things which people do not say – but you have to understand them”. The project leader said during the interview that relationships with the clients were managed by the Canadian team members. He said “Indians sometimes find it difficult to break the ice, as the clients do not share their domain knowledge easily. So, our Canadian counterpart manages it for us through regular face-to- face meetings.” IN5 IN5 do not interact directly with their clients. Their project manager explained “the American team provides us with the clients so they are our internal clients. 244 They talk to the client – but they are not technical people so they come back to the team here for a technical solution. So sometimes our team also gets involved with the relationship management dealings with the client but not as a regular practice”. Moreover, being a product company, IN5 do not need to interact much with clients, as they develop an off-the -shelf product rather than a customised software solution. Therefore, they do not feel the need to identify the social and cultural contexts between the teams in Pune and Minnesota as interactions take place via the telecommunication network. However the project manager added: “People have to be culturally sensitive. How you communicate has to be very good otherwise people start misunderstanding and that causes some issues. So communication and cultural sensitivity is one of the most important things for outsourcing. An example is - sometimes here we have festivals and all those other sort of things. Then the US guys feel that we have too many holidays here. Then people here have to make up the time by working on weekends. And then they are normally not there on weekends – so we both have to be culturally sensitive during the holiday weeks. They should understand our side like we understand theirs – about our Ganpati or Diwali festivals and their Christmas and New Years time”. 8.3.1.2 Summary of cross-cultural interaction strategies The case data reveals that vendors are making efforts to bring about a more glocal context across organisational and cultural boundaries, and this has had some implications on their work practices. Vendors are seeking to gain understanding of offshore clients/partners social structures , to build positive relationships based upon mutual understanding. However, they have also identified some challenges that are yet not resolved fully. Some challenges faced by the vendors are hierarchy in offshore team structures, mismatch in expectations of interrelated work responsibilities, differences in holiday seasons and other language nuances. However, they have each tried to overcome these challenges, and are operating in a manner to promote knowledge sharing and to build trust and confidence in their business relationships. 245 One New Zealand vendor (NZ1) found the hierarchy and “not asking questions” aspect of their offshore partners a challenge. This has been overcome by direct face to face meetings, and deployment of their offshore partner’s employees at their client sites. Heeks et al. (2001) have found in their study that Indian development teams do not openly confront their offshore partner even during problem solving discussions. Another New Zealand vendor (NZ5) found a mismatch in work related expectations with missed deadlines, due to differences in organisational structures for defining authority and responsibility. The interrelated and iterative nature of software development means that offshore teams needed to adhere to deadlines for sending their deliverables to other members of the distributed team so that the work can proceed to the next stage of development. Vendors consider having frequent follow up meetings with shorter commitments defined between distributed teams so that teams are aware of each other’s expectations. Heeks et al (2001) have identified project slippage by Indian development teams in terms of time spent on the project for meeting deadlines as a factor for sinking relationships. Two of the New Zealand vendors (NZ2 and NZ4) believe in off-shoring very structured work to their offshore teams, so that work structures are clearly defined across cultures leaving little room for misinterpretation. Interestingly, one vendor (NZ3) did not consider their local and their offshore partner’s team to operate with different mindsets based upon cultural differences, and they operate in a more glocal environment than the other nine vendors. The case data of the Indian organisations revealed that four of the five organisations have felt the need to share a common social and cultural context. Differences in spoken English have been felt to have an impact on highlighting cultural differences. Agerfalk et al (2006, p. 28) have also found that “when people from different countries and with different backgrounds collaborate, their frames of reference, work habits, and language may differ, which can often lead to great frustration – an example of socio-cultural distance”. Thus some vendors trained their teams to change their local language nuances and adopt a neutral tone of speech. Two Indian vendors (IN1 and IN3) also gave training to employees before sending them overseas on client projects, to make them more aware of other side’s social and cultural nuances. 246 Moreover, one vendor (IN5) said that more mutual understanding of each other’s cultures is needed, such as during festival periods and holiday seasons. Sometimes, the lack of understanding of holidays had resulted in extra working time during the weekends, and this was not appreciated by either of the teams. However one Indian vendor (IN2) said that knowledge skills rather than cultural differences is important in a business relationship. They said that they consider each project as a business transaction with defined rules in place, and they are just organisations who are “doing business together”. 8.3.2 Building reputation This study uses Hurley’s (2006) viewpoint that trust in business relationships is situational and depends upon how secure the parties feel, and how much concern the parties have for each other. The situational factors for building trust as identified by Hurley are capability, integrity and predictability of parties concerned. This study finds that vendors highlight their core capabilities and past project successes on their websites to inform prospective new clients of their core capabilities. This helps to bring some visibility of the vendors’ business standing and also builds the vendors’ reputation in the international offshore market. Vendors and clients take entrepreneurial risk when they first utilise information technology and pursue offshore outsourcing of their organisational activities. Websites help to create visibility of the vendor even before the vendor first approaches the client with an offer of a service. The client is made aware of the vendor’s past achievements through background research from corporate websites, references from partners or other clients on earlier work undertaken. Thus websites are used by vendors to advertise their capability, integrity and predictability to prospective clients. Analysis of the websites of the vendors revealed that some vendors used scanned images to display international certificates on their quality and process maturity. Others highlighted their global infrastructures by showing their distributed offices and development centres on a world map. Also, websites listed past projects undertaken a nd references from clients whose projects 247 have been completed. Many whitepapers are also available on vendor websites describing their software development activities. Three vendors pursued community service activities, and these activities have been described on their websites to represent their societal values and responsibility towards the underprivileged members of society. This section aims to understand which factors offshore vendors consider key to building their reputation in the offshore marketplace. A summary of the key drivers which are considered to influence the vendors’ international reputation is given in Table 46. Table 46 Practices for building reputation Practices New Zealand organisations Indian organisations Websites displaying lists of customers or past project successes NZ1, NZ2, NZ3 and NZ4 IN1, IN2, IN3, IN4 and IN5 International accreditations, patents, etc. to show organisation’s maturity IN1, IN2 and IN5 Social service activities to show responsibility to their community NZ3 IN1 and IN2 8.3.2.1 Case data report on reputation building strategies Each vendor was asked on what they considered as their strength in the current offshore software development market. Their websites have also been analysed to understand how vendors describe their technical capabilities and organisational values to bring in a sense of security in their clients and further build confidence in the client to pursue a business relationship with them. NZ1 On their corporate website, NZ1 have provided lists of some of their past projects and customer references of completed projects in Australia and New Zealand. Their customers include leading banks, government offices, airline corporations, insurance groups and many other reputed organisations. 248 The project manager said that their strength is that they “are a very well known New Zealand company”. He added that NZ1 believed in “right-shoring and not off-shoring. This means design and customer management and project management is basically done directly with the customer here in New Zealand by the New Zealand people. So that means that actually the design of the application - the technological design part of it, the customer interaction and the project planning is done by the people in New Zealand and then it is handed to a project manager in the offshore company. The project manager there takes the design and the plan and basically just manages a set of development people to actually produce the code. So what you are doing is you are not actually off-shoring the entire project. All you’re doing is off-shoring the build aspect of the project”. NZ2 Organisation NZ2 has listed some of their customers “testimonials” on their website. They have also listed their history of how they started as a small retail business in 1980 and have grown to capture 75% of the national user base involving various medical health sectors in New Zealand. Further details of their share registry listings are also given on their website to declare their legitimacy and registered status. The managing director of NZ2 said that their strengths are their “users, staff and processes”. Holding a 75% customer base meant that they “are already an established name”. Moreover, the director explained that their staff are not “micro-managed” as their “quality standards and definitions are clear”. NZ3 NZ3 have listed on their website details on their history, past achievements and any other recognition received from local and international agencies. The director of NZ3 stated that their main strength in the offshore industry is being a “multi cultural” organisation. Their internal portals have many white papers on “hybrid culture” , where knowledge flow between the two sites also 249 took into account the different social and cultural contexts. NZ3 keenly embraces the cultural differences and considers being multicultural as their core strength. Also, NZ3 have also been involved in many social and community services, such as offering “not for profit” products for the elderly and disabled. They are advisors on ICT education in Vietnam, and have undertaken other progressive initiatives in Asia. These community service activities are listed on their websites. NZ4 The project manager said the strength of NZ4 is their “early entry and expertise in mobile technologies and online gaming”. NZ4 entered the mobile telecommunication market in 2000, and have sales and operations offices in many countries. They have captured a significant global market share and are involved in advertisement campaigns with international clients like Vodafone, Coca Cola, and popular TV shows which involve text voting by mobile phones (e.g. American Idol, Vodafone). NZ4 have listed many customer projects from reputed organisations on their website with case studies and also have video clips to explain the background, project objectives, solution and results. Thei r websites have listed fifteen pages of news from various magazines and industry groups who have used NZ4’s expertise in the past. NZ5 The managing director said their main strength is their “technical knowledge to integrate Siebel** with a proper customer relationship strategy for clients”. However, NZ5 is the only organisation which does not have a website. But NZ5 are the preferred partner for a global CRM service provider in New Zealand, and so benefit from their partner’s sales channel. Moreover, their partner mostly provides them with client projects, and so NZ5 does not feel the need to advertise itself separately from their partner. ** CRM application software 250 IN1 IN1 has listed its international certifica tions (SEI CMMI level 5, SEI CMM level 5, ISO 9001: 2000 and ISO/ IEC 27001:2005) along with scanned images of these certificates on their websites. It has also listed the many awards received from the Indian government and other industry groups for their offshore capabilities. Websites also described case studies of various client projects undertaken, and have subsections within each case study such as challenges, solutions and advantages to inform readers on their work commitments. Moreover IN1 is also involved in community service and have listed these details in a section marked “Corporate Social Responsibility”. IN2 have opened schools for the underprivileged, taken responsibility of 120 students affected by the Tsunami in India, amongst many other similar community service activities. The project manager stated that their main strengths is “technology expertise” and their “eager development teams”. IN2 IN2 have listed their international certifi cations with scanned images of these certificates (viz. ISO 9001:2000, SEI PCMM level 5, SEI CMMI level 5 and BS7799) on their websites. IN2 is a subsidiary of a respected business conglomerate which was founded in the mid 19 th century, and which has combined revenue of 18 billion USD. Moreover the parent group of IN2 have been involved in many philanthropic activities, and are a respected name in India and abroad. The chief technology officer if IN2 stated that their strength was their “parent group’s brand name” and the “technical know how” of their employees. IN3 IN3 have displayed a list of prominent clients on their website. They have recently developed their own platform to enable remixing of web services for the 251 “ Facebook” social networking website of which the IN3 management is very proud. The chief executive officer of IN3 said their strength was “entering into web services technology”, and the “right marketing strategy at the right time”. IN4 IN4 have listed some case studies of past projects on their website. Their corporate profile lists the history, offices and preferred technology platforms amongst many other facts about themselves. The chief operating officer of IN4 said that having operations defined in Canada since 1996, meant that “the Pune division would be an extension of an established software business in Toronto”. He explained: “in 1996 as the world was moving they too thought of moving offshore. They had some ideas earlier to work with some Indian companies here but that did not work out too well for them. Because this is a product company, they did not want that knowledge to go out. So they wanted someone whom they could trust. And to work with someone like Satyam* or Infosys* we really don’t know how long the knowledge will be retained by the people. How long will they work for us. Also we did not want our work to be so spread across. So it is critical that we maintain that confidentiality. So these people came to India and looked at different locations where they could set up their office and then they approached me to help them out”. Thus IN4’s offshore partner is well established name in Canada and they manage both client relationships and also provide IN4 with new projects. IN4 considers itself to be an extension of the Toronto division, and so are not too concerned about building their reputation separate to the Toronto division. IN4 considers their software product and knowledge base as their strengths, and said their offshore division appreciated and capitalised on these strengths. * Satyam and Infosys are two large Indian software organisations 252 IN5 IN5 considers that its core algorithms and patents differentiate it from other offshore vendors. Their website displays the message: “IN5 was founded in 1989 by [Dr XXXX**] and a group of scientists who, together, hold more than one dozen patents for groundbreaking technology innovation. They pioneered solutions that have become the foundation of what is known today as supply chain management. IN5 founders possess broad experience across multiple industries and have developed innovative revenue optimisation solutions for US Airways, Northwest Airlines, National Car Rental and United Van Lines, among other companies” IN5 is very proud of their patents and considers patents have labelled IN5 as an expertise firm, and differentiated it from other novice medium-sized firms, and also enhanced their reputation. This is evident also by a remark made by their senior management “We sell expertise and not TVs…We have found the extraordinary in the ordinary and have been granted a dozen patents”. Thus IN5 considers its technical skills and knowledge base as their key strengths. 8.3.1.2 Summary of reputation building strategies Vendor organisations use websites to highlight their technical capabilities and social responsibilities. These help to bring some visibility of the vendor’s achievements and social commitments to the clients and are considered to reduce the client’s perception of entrepreneurial risk. With some visibility of their achievements, technical capabilities and social responsibilities, the vendors try to build their reputation and gain the trust of the client. The case data reveals that with the exception of NZ5 all the other nine organisations used websites to advertise their past successes. Each organisation had listed their areas of expertise, past projects with case studies and client testimonials to give a more detailed picture of their technological capabilities and skill sets to prospective clients. However, one organisation (i.e. NZ5) does not feel the need to advertise their ** a pseudonym 253 skills through websites as they take advantage of their global partner’s sales channel, and do not have to go out to seek offshore clients themselves. Their partner provided them with international clients and contacted them for their skill sets. However, the other nine organisations have no such global partners and used separate sales divisions to identify prospective clients. The two larger Indian organisations (IN1 and IN2) and one New Zealand organisation (NZ3) are also involved in various community service activities, which are mentioned on their websites. These activities show that these vendors consider social services as an essential element of their business responsibilities, and are also used by them to inform the peer business community about their social commitments. This section also reveals that some of the strengths considered by vendors are having well known reputed organisational names, offshore offices, specialised knowledge base, cultural understanding, international certifications and patents, marketing strategies and product knowledge. 8.3.3 Strategies to bring visibility in interrelated work processes Once the initial business relationship between vendors and clients has been established across the virtual space, efforts ha ve to be made by both sides to build the relationship to higher levels of trust and reduce the perception of risk. Virtual spaces are characterised by differences in locations, time zones, cultures, work habits and organisational settings, which is further complicated in OSD where distributed and complex interrelated software tasks have to be combined into a coherent tangible solution. Distributed teams working on interrelated software tasks try to reduce ambiguity by increasing visibility of work processes for the offshore components to render shared meaning and define accountability in work structures. This helps to create trust among the team members, as teams are aware of what is going on in the virtual environment. Thus team members take calculated risk on the basis of the face value of the offshore teams, and this in turn enhances mutual trust and the level of risk reduces. 254 Group software solutions like portals provide common technological spaces and further increase the visibility of offshore components Interactions based on common access to project documents and source code on organisational portals, allied with some personal contact, increase trust levels to the risk-return trade-off stage in which both sides identify glocal situations. These common technological spaces help in reducing the client/ partner’s apprehensions in sharing their knowledge portfolio with vendors of other nationalities. Teams become immediately aware of any inadvertent change made at distributed sites and this further raises the trust level. Moreover if the working hours overlap across distributed sites, then the technological tools allow the teams to communicate and share ideas synchronously. Agerfalk et al. (2006, p. 28) also identify difference in working hours to amplify problems associated with temporal distance as distributed teams have to then “rely on asynchronous communication channels such as email, and when working in different time zones, they cannot expect to find the right person at the right time”. Also deployment of vendor’s employees at the client or partner’s site brings teams together in the same social settings. This enables teams to interact on common physical spaces as opposed to common technological spaces, bringing forth new sociological structures. Thus as new structures emerge, vendors and clients gain better understanding of each other to identify shared meaning and build positive relationships. A summary of the strategies used by the ten organisations to bring about some visibility in their interrelated work processes is given in Table 47. Table 47 Practices to bring visibility in interrelated work processes Practices New Zealand organisations Indian organisations Documentation and use of organisational portals NZ1, NZ2, NZ3, NZ4 and NZ5 IN1, IN2, IN3, IN4 and IN5 Overlapping office work hours NZ1, NZ2, NZ3, NZ4 and NZ5 IN1, IN2, IN3, IN4 and IN5 Centralised office near offshore client’s destination NZ2 and NZ4 IN1, IN2, IN3, IN4 and IN5 Deployment of employees at offshore client locations NZ1 and NZ3 IN1, IN2 and IN3 255 8.3.3.1 Case data report on strategies to bring visibility in interrelated tasks The case data has been analysed to understand the vendor strategies to mitigate risk by bringing about visibility of software tasks. In distributed software development, all stakeholders need to be aware of any changes in project definitions for alignment of expectations and responsibilities as the development proceeds. The visibility of tasks helps to bring in accountability and this further builds trust and confidence in distributed teams, as teams come to a shared consensus. Vendors have been found to use a mix of strategies to bring about visibility and inform groups of project status and related issues. They use common physical spaces to help interpret visual cues during knowledge exchange and also use common technological spaces to help clients, partners and vendors access explicit knowledge stored in the repository. The shared spaces – physical and technological – bring offshore groups on a common platform where teams can share ideas on interrelated tasks, further resulting in some form of social networking. Some strategies employed by vendors to bring visibility in these platforms are identified as documentation, integrated groupware portal between sites, overlapping office hours to enable synchronous communication, vendor offices near client sites and deployment of employees at offshore sites to facilitate F2F communication. More details on individual vendor practices are described in the following subsections. NZ1 During the time of the interviews, NZ1 was involved in software application development for clients belonging to New Zealand only, and had no offshore clients. However NZ1 has an offshore partner (PartnerNZ1), who is involved in software development alongside NZ1 for these clients. NZ1 therefore do not need any offshore offices, and their two local development centres at Auckland and Wellington are suitable for their local client needs. Earlier NZ1 faced some issues with PartnerNZ1 due to lack of direct F2F interaction as requirements and work commitments were not clearly understood 256 across the virtual spaces. Now NZ1 have team members belonging to their offshore partner deployed at their New Zeal and client sites. The direct interaction between the client and offshore partner of the vendor team help to bring more visibility in the work processes and this is considered to bring in more accountability and responsibility in related work processes. Documentation controls on an integrated organisational portal are also used to communicate work related issues and bring visibility of interrelated project tasks. NZ2 Because NZ2 deals with confidential medical records of clients, they feel that having offices in client destinations of Australia and New Zealand help to make their clients feel more confident and secure. NZ2 also have plans to extend their clientele to Europe, and accordingly have set up a small office in Ireland, where they are presently implementing a pilot project. NZ2 have not deployed any offshore team members at client sites. They prefer the Australian clients to deal with local Australian staff, and similarly the New Zealand clients to deal with their local New Zealand staff. NZ3 NZ3 have two offices, one in New Zeala nd and the other in Vietnam. However, they have clients in New Zealand, Australia, Hong Kong, Singapore, Malaysia, and many other countries. They do not have offices in all these locations; rather they prefer to deploy their team members at the offshore sites. NZ1 uses organisational portals synchronously with their clients and partners, and has been very appreciative of the common technological spaces, calling it “great great technology”. NZ4 NZ4 has many offices worldwide, and consider these essential in gaining customer contracts. However, these offices are managed by local sales staff members, and no offshore team members are deployed at these offices. Organisational portals are extensively used to inform development teams of interrelated software tasks. Moreover NZ4 and their offshore partner have about four hours of overlapping office time between them, and during this time direct conversations over VOIP tools are mostly held between teams. 257 NZ5 NZ5 has only one office in Auckland. They do not feel the need to open offices in client destinations, as they have partnered with a global service provider, who provides them with offshore clients. NZ5 considers direct interaction useful during the requirements gathering phase when the project starts and then later when the project has to be finally deployed. One senior manager has taken the role of a relationship manager, and he alone interacts with the client and also with their offshore global partner. Also, NZ5 does not deploy employees at the client sites, as they believe that a combination of organisational portal with strict documentation control over the telecommunication network brings complete transparency of work progress. All stakeholders referred to this single source of information on the portal hosting the centralised repository (also referred as “one version of the truth” ). These common technological spaces are used actively to bring all stakeholders on a common platform and bring visibility in work processes. IN1 and IN2 IN1 and IN2 have many offices worldwide, which are registered separately in the client countries. These offices help to relieve client’s apprehensions about sharing their knowledge base with vendors of another culture. However, the development work is still done at the centres in Indi a, and both organisations (IN1 and IN2) often need to deploy their local employees at the offshore client sites. This is done for two reasons: to make the client more aware of the vendor’s capabilities and work processes, and also to boost the morale of their own development teams. IN1 and IN2 prefer to have synchronous communication between their development teams spread at distributed locations. However, this implies that team members in India have to often extend their working hours to late evenings to overlap their office time with the time at the distributed sites. Therefore these organisations have set up many recreational facilities in their office premises to encourage employees to stay back for late hours. IN3 IN3 has a sales office in California, wh ich manages the clientele in the United States. The sales representatives manage th e client relationships and gather client 258 requirements, which are then communicated to the development team in India through organisational portals. In some situations where some technical expertise is required on-site, a developer from India may travel to the client’s site to help resolve the technical issues. However, generally the organisational portal is used to bring visibility in project related issues to both their offshore client and partner. IN4 IN4 have development teams located in Pune, Bangalore and Toronto. The team located at Toronto interacts directly with the customers, and informs the teams in India on new issues or updates via their organisational portal. Thus the team located in India has no direct contact w ith the offshore customer or partner, and uses only organisational portal with some formal document control to communicate with each other. IN5 IN5 is a product company and do not directly deal with application development tasks for customers. Customisation of the product is done by the development team in Minnesota, who directly interact with the customers. The Indian team members have no contact with any of their overseas clients. They interact with the offshore development teams in Minnesota via the organisational portal. Moreover, the organisational portal is used with strict discipline to ensure that standard procedures are being followed in the project workspaces. 8.3.3.2 Summary of preferred strategies to bring visibility in work processes The case data has revealed that all the ten vendor organisations consider usage of groupware portals with some form of documentation control essential to bring visibility in their work processes. The Indian vendor organisations consider having centralised offices at client countries helps to make the client feel less apprehensive than they would have felt if they had to deal with a vendor located in India. Thus they all had registered offices in other countries. Also deployment of employees at client destinations is more actively 259 pursued by the Indian vendor organisations. Moreover, NZ1 have also deployed their Indian partner’s (PartnerNZ1) employees at their local client sites. This again shows that the Indian vendors prefer to deploy their employees at offshore locations, so that requirements are understood directly. Only one New Zealand organisation (NZ3) deployed their development team members and also their offshore partner’s team members at local and offshore client sites. Another preferred strategy by all the ten vendors is to have some overlap in office hours across the distributed sites. This ensures that team members can utilise synchronous communication tools (such as phone and chat) to make each other immediately aware of project tasks and updates. This is especially demanding for the Indian organisations, due to the twelve hour difference between them and their offshore teams situated in the United States and Canada. Due to temporal dispersion, the Indian developers have to come to work in the afternoon, and leave late in the evenings to enable synchronous communication (O'Leary & Cummings, 2007). The New Zealand organisations also consider overlap of office hours essential to clarify interrelated tasks. However, New Zealand or ganisations did not have to make too big an adjustment in office times, due to lesser differences in geographical time zones with their offshore teams. 8.4 Important drivers for relationship building strategies The chapter shows that vendors belonging to diverse cultures have taken measures to build trust in relationships with their offshore clients and partners. Expanded world markets due to off-shoring have resulted in growing virtual social spaces, and vendor organisations are making efforts to improve their understanding of their offshore client or partner’s social spaces. Vendors agree that global businesses need to change their work structures to account for understanding and acceptance of cultural differences, bring awareness of their orga nisational capabilities and values to offshore groups, and to have visibility in work processes for smoother flow of knowledge across the organisational silos. Thus relationship building strategies are now being 260 added to the vendor’s enterprise solutions to help build trust and confidence across different economic spaces. Vendors have made efforts to understand their offshore partner’s cultural structures and their implications on their working styles and structures. Each vendor is sensitised to client’s concerns for sharing knowledge with offshore vendors and they have defined new work practices to ensure that cultural differences are not felt as a barrier to sharing knowledge. Vendors build client confidence by displaying their strengths, such as international certifications and patents, past project successes, client testimonials and community service activities on their websites to bring some visibility of their capabilities and organisational values. Other practices to bring more visibility are organisational portals with shared web access across sites, overlap in office hours to enable synchronous communication, centralised project offices in offshore destinations and deployment of offshore employees at client or partner sites. An interesting observation by an Indian group (IN4) stated that the barrier to a glocal platform is not cultural differences but job losses in offshore client/ partner destinations. Whatever the reason, the practices show an awareness of changes in organisational working patterns in view of the emerging virtual spaces. The study identifies individual agents or vendors’ social contexts being influenced by client’s social structures in accordance with Giddens’ structuration theory. The vendors understand that a client is more likely to continue with the vendor whom the client trusts; hence it is in the interests of vendors to make every effort to build trust across the virtual spaces. The vendor’s social systems are being enabled by client’s social spaces, as new rules are being defi ned and re-defined. Vendors have defined hybrid work patterns for managing knowledge intensive tasks in software development across diverse cultures and organisations. These hybrid working patterns help to build trust and mutual respect across the prevailing dissimilarities in cultures and organisations in the virtual spaces. Thus vendors operating in the knowledge society such as software development are not confined by Hofstede’s (1990) stereotyped version of culture indices, but their organisational identity is also influenced by the offshore work structures. Hence glocal contexts are emerging with 261 hybrid cultures, as organisations are embracing and adapting to be embraced by other cultures (Walsham, 2002). The four actions associated with the SECI model are: sympathising (with socialisation), articulating (with externalisation), connecting (with combination) and embodying (with internalisation). Figure 12 illustrates these four actions which vendors use for building synching relationships. Figure 12 Application of the SECI model for relationship building The chapter has revealed that vendors are sympathetic to client apprehensions and are socialising through direct interactions to bring cultural compatibility (i.e. language nuanaces, accents) and to bring awarenes s of each other’s work habits and organisational practices. This leads to more meaningful interactions where knowledge is articulated and expressed to remove ambiguity by involving F2F meetings, deployment of employees at client destinations, centralised project offices and also by using synchronous tools during overlapping work hours to be eventually externalised in organisational portals and documents. Vendors reflect, connect and combine their externalised knowledge to define their capabilities which are then highlighted on their corporate websites to build their reputation in the international market. They use websites to display their achievements (i.e. white papers, past project successes, client testimonials, certifications) to make offshor e clients and business partners feel more confident of their capabilities. Finally the vendors extend their knowledge gained by embodying the practices learnt into their day-to-day work structures by training their employees on the social, cultural and technical aspects learnt. Thus local work Sympathising (socialisation) Articulating (externalisation) Connecting (combination) Embodying (internalisation) Relationship building 262 structures are influenced by other social spaces, resulting in internalisation of glocal structural practices. In this manner vendors define knowledge sharing processes in the virtual environment across organisations and nations. The next chapter extends the micro level analysis (Chapters six, seven and eight) to the meso and macro levels of the embedded case design (i.e. organisational and national levels). The organisational groupings identified in Chapter five are used to make cross case comparisons across two country contexts. 263 CHAPTER NINE – The Evaluation Process 9.1 Introduction In evaluating the key success drivers for offshore software development, this research study uses an embedded case design by utilising three levels of “embedded units of analysis” (Yin, 2003, p. 48). Following the conceptual framework (refer Table 27), the preceding three chapters have analysed case data of the ten vendors for knowledge sharing processes at the micro level of the three level cell design structure. This chapter extends the evaluation process to the meso and macro level to explore the range of influences affecting the vendors’ practices for knowledge sharing for the identified key success drivers. The conceptual framework identified from the pilot study is re-examined and modified based on the empirical evidence gained from the ten vendor cases participating in the main study. Eisenhardt (1989) says that there is no standard format for case data analysis, and the number of analytical approaches may equal the number of researchers. However, she advices treating each case as a “stand alone entity”, with selection of categories within the cases to identify recurring patterns across multiple cases (p. 540). This research study has considered each key success driver as a category within each ‘stand alone entity’ (or vendor organisation) as their work practices were aligned along the identified three knowledge sharing strategies. Extending the analysis to the meso level and macro level of the three level cell design structure, this chapter answers the main research question. The main research question asked in the study is: How do vendor organisations use knowledge sharing processes in the offshore software development environment within a glocal society? The main question has been guided by three subsidiary questions which have been answered in the preceding three chapters. The answers have revealed knowledge sharing processes involve co-operative learning as offshore vendors (agents) interpret 264 and learn to apply tacit and explicit knowle dge through processes of assimilation and conversion to create new knowledge. The new knowledge created further informs and influences work structures as vendors make effort to understand diverse social and cultural spaces to build trusting ( synching) relationships in the virtual environment. The higher level analysis considers the national and organisational influences which affect the vendors work structures for the identified key drivers in the OSD environment. The Brunswikian Lens Model (Brunswik 1935, 1950 cited in Scholz & Tietje, 2002) has been used to interpret vendor data and classify organisational perceptions and work practices for knowledge sharing. The second thematic analysis has identified six organisational constructs (also called perceptors) which influence the key success drivers namely hierarchy, cross cultural communication, employee skills, certifications, process controls and social representation strategies. Finally, the chapter extends the analysis to the macro level to explain the key drivers for a group of vendor organisations that share a common national culture (i.e. New Zealand and India in this study) before presenting a revised conceptual framework. 9.2 Synthesis of knowledge sharing processes at micro level This research study started as an explorat ory study where three pilot case studies were used to inform the main study on key success drivers through a conceptual framework. The initial conceptual framework shown in Table 27 was used as a starting point and it helped to identify the scope of the study. Investigation of key success drivers at the micro level has revealed many aspects of the vendors’ knowledge sharing processes in the OSD environment. This section synthesises the micro level revelations on knowledge sharing processes to give a more holistic picture of the vendors’ work structures. The key success drivers identified along three strategy groups namely, transfer of tacit knowledge, management of explicit knowledge and relationship building strategy, have been identified both from outsourcing literature (refer Table 8) and informed by existing theories (SECI and ST). Further empirical evidence (ten case studies and pilot studies) has confirmed that the three strategy groups interact with each other as 265 vendors build synching relationships across diverse social and cultural domains to extend their knowledge repositories as the tacit and explicit knowledge assets are integrated together. Moreover evaluation of the evidence found that certain drivers which were identified for one strategy also complemented other work processes in another strategy. Thus, the three strategy groups are not mutually exclusive; rather they interact and support each other’s key success drivers. This study provides an empirical assessment of existing theories in knowledge management in a ‘real-world setting’ related to the context of offshore software development within two country contexts. It has synthesised theoretical propositions with empirical evidence to help in making TE (theory to empirical) generalisations. TE generalisations are “closely related to empirical testing”, and helps researchers use existing academic theory in new settings – i.e., a setting other than the one(s) where the theory was empirically tested and confirmed – and is the “most important form of generalisability in business-school research” (Lee & Baskerville, 2003, p. 237). TE generalisations reveal that vendors are building synching (trusting) relationships to create global-local linkages with more meaningful interactions. Vendors are sympathetic to the offshore client apprehensions and are making efforts to connect diverse social and cultural domains. New structures are emerging as glocal knowledge is articulated and embodied into the vendors’ local work structures. The vendors’ (agents) local work structures are influenced by clients’ social structures through ongoing interactions resulting in stronger relationships between them. The new structures help to expand the vendors’ knowledge repository as distributed team members are involved in dialogue for linking, learning and building of tacit and explicit knowledge assets. The key success drivers associated with three strategy groups identified at the micro level analysis (i.e. transfer of tacit knowledge, management of explicit knowledge and relationship building strategies) have been broken down into the four quadrants of the SECI model (i.e. socialisation, externalisation, combination and internalisation) in Figure 13 to understand the vendors’ knowledge sharing processes discussed in Chapters six, seven and eight. The positioning of these drivers indicate how the 266 vendors’ knowledge spiral emerges when distributed team members engage in dialogue, linking, learning and building processes to integrate their tacit and explicit knowledge assets. Figure 13 has been derived from existing theories (SECI, ST, and offshore outsourcing literature) and empirical data (ten case studies) to make TE generalisations on the vendors’ knowledge sharing practices at the micro level analysis. It illustrates how the driver elem ents of the three strategy groups interact with each other to support extension of th e organisational knowledge repository in the virtual social spaces. Figure 13 Knowledge sharing processes influencing the key success drivers (Adapted from Nonaka and Takeuchi, 1995) Furthermore, the cross case searching tactics revealed that the implementation strategies for the key success drivers identified from literature are different for the vendors operating in different societal contexts. The cross case searching tactics involved pattern matching as the mode of inquiry to identify similarities and differences between the vendors. Pattern matching involves “second level of coding Combination (learn/ connect) Socialisation (dialogue/ sympathise) Internalisation (build/ embody) Externalisation (link/ articulate) Tacit Tacit Tacit Explicit Explicit Explicit Explicit Tacit F2F F2F Rewards VTT White papers Informal social spaces Mentoring Peer reviews Common meeting places Deployment of employees Online social networks English language nuances VTT Domain skills Informal change management practices Incentives Portals Documentation Project management Quality management Audits ( internal/ international ) Formal methods (version control) 267 which is more inferential and explanatory” to compare sets of field data with each other to identify general notions across the two identified groups (Bazely, 2007, p. 110). Patterns are evident later in the analysis process when the significance of particular comments and observational notes are more noticeable to the researcher (Miles & Huberman, 1994). The pattern matching has not been devoid of conflicting patterns and unexpected revelations; however the underlying similarity has been essentially captured during the analysis process. The pattern matching has revealed that the vendors’ implementation strategies for the key success drivers are influenced by national and organisational environment such as culture and organisational size. Looking at the national (cultural) environment, the research has revealed that New Zealand vendors are mostly intermediary vendors who have further outsourced their software construction activities to low cost countries (e.g., India and Vietnam) and are involved more in project management and administration. In contrast the Indian vendors are involved in software construction activities. These differences affect their knowledge sharing processes. Next, the organisational context has revealed that the large sized vendors (group A) operate at lower contractual risk than the SME sized vendors (group B). Also the large vendors use more formal and disciplined processes for managing offshore projects than the SME vendors. The attrition figures are also higher for the larger organisations. But the study also finds that the Indian organisations are more susceptible to staff turnover, and they ha ve established more processes to motivate and retain their staff. The organisational size also influences the degree of ownership as none of the large organisations have external ownership by offshore parent groups. However, the SME Indian organisations are wholly owned subsidiaries of offshore parent groups, though this was not the case for New Zealand vendors who have no external ownership. The New Zealand vendors have opened wholly owned subsidiaries and started joint venture partnerships with vendors in low cost countries. Thus the comparisons have revealed that both culture and organisational size influence the vendors’ work structures which in turn influence the practices associated with their key success drivers. However, organisational size has a more direct 268 influence on their associated work practices (such as formalisation of work processes, contractual risk, attrition and ownership) and based upon these influences, the comparisons of empirical data has next been presented from the organisational size point of view for the two vendor group sets (i.e. group A and group B) in Table 48. Table 48 highlights the key points which influence the vendor’s work structures and these are discussed in the next section. 269 Table 48 Comparisons between group A and group B vendors Organisational Factors Group A: N Z 1 , NZ2, IN1 and IN2 Group B: NZ3, NZ4, NZ5, IN3, IN4 and IN5 Contractual risks ⎯ Less risk with both fixed and T&M contracts. ⎯ More risk with fixed contracts. Ownership ⎯ No external ownership by offshore parent groups. ⎯ No external ownership for New Zealand vendors, but all the Indian vendors are wholly owned subsidiaries of offshore parent groups. Attrition ⎯ Attrition rate in the last two years is 29%. One New Zealand vendor had 50% attrition during the time of the interviews. ⎯ Attrition rate in the last two years is 20%. Two New Zealand vendors reported zero attrition; hence these attrition rates are mainly calculated from the Indian vendors. Individual Practices Group A: N Z 1 , NZ2, IN1 and IN2 Group B: NZ3, NZ4, NZ5, IN3, IN4 and IN5 Communication with client ⎯ Senior management and development team are involved in F2F communication. ⎯ Are open to cross cultural teams being involved in F2F communication (except NZ2). ⎯ Employees are deployed at client locations. ⎯ Only senior management is involved in F2F communication (except NZ3). ⎯ Mostly prefer that F2F communication should occur between similar cultural groups (except NZ3). ⎯ Employees are not deployed at client locations (except NZ3). Quality processes/ certifications ⎯ VTT and documentation controls are used formally. ⎯ Large Indian vendor organisations are expected to have international quality certifications. But the New Zealand vendors prefer internal processes (internal audits). ⎯ VTT and documentation controls are used less formally. ⎯ No international certifications. Vendors prefer internal processes (internal audits) to manage their quality processes. Project management processes ⎯ Use strict processes for project management. The Indian vendors have more formal processes. ⎯ Use flexible and less disciplined processes. The Indian vendors have more formal processes. Employee skills ⎯ New Zealand vendors prefer project management skills, while Indian vendors prefer technical skills. ⎯ New Zealand vendors prefer project management skills, while Indian vendors prefer technical skills. Social Representation ⎯ Have offshore development offices near client destinations. ⎯ Use websites to display past successes. Indian vendors also highlight their community service activities on websites. ⎯ Have offshore sales offices near client destinations. ⎯ Use websites to display past successes (except NZ5). One vendor also highlights community service activities. 270 9.3 Three level cell analysis This section analyses the higher levels of the three level cell design at the organisational and national level to get a holistic understanding of the vendor practices for defining knowledge creation and relationship building strategies. As the study extended into higher levels of analysis, new themes were identified from empirical fieldwork to give new insights for making EE generalisations on the vendors’ work structures. The rich descriptions of micro level practices have helped in making ideographic analysis as questions were asked of the data to understand reasons for vendors’ work structures for the identified key success drivers. Creswell (2008, p. 259) calls such analysis techniques “layering the analysis (also called first- and second-order abstractions)”, where the “researcher connects the themes to display a chronology or sequence of events, such as when qualitative researchers generate a theoretical or conceptual model”. Urquhart (2001) points out that resolution of empirical field data involves philosophical considerations which consists of the researcher’s belief about nature of physical and social reality, and the inquiry can be conferred from positions of interpretivism or positivism. This study used a mixed approach of inquiry by adopting “methodological pluralism” with a logical positivist stance to interpret and construct meaning of the empirical data in different social and cultural contexts. Furthermore, Gregson (1989) encourages researchers to use structuration theory as a second theory to support the chosen research inquiry for interpreting social situations and their impact on human agency. ST has been applied in this study to diverse social settings to find meanings assigned by individual vendors (agencies) and the impact on their work structures. The three level cell analysis has used the Brunswikian Lens Model to understand the impact of different national and organisational contexts and associate some categories with these contexts. The data interpretation phase has identified five facets of the societal structures which impact the national and organisational lens, namely size, culture, contractual risk, ownership and attrition. The societal structures are the external influences outside the control of the vendor, and which are the environmental conditions under which the offshore vendor operates. These conditions have been found to influence the vendors’ perceptions and implementation strategies for their key success drivers. Vendors’ identify work 271 structures in accordance with their environmental conditions to build knowledge processes in the glocal environment. The higher level analysis has been explained with the use of the Brunswikian Lens Model. The national and organisational lens led to identification of six organisational perceptors – hierarchy, cross cultural communication, empl oyee skills, certifications, process controls, and social representation strategies – to give new insights on the vendors’ knowledge sharing processes. Figure 14 describes the application of Brunswikian Lens Model in the context of this research study. Figure 14 Application of Brunswikian Lens Model for this study Adapted from Scholz & Tieje, 2002 N A T I O N A L & O R G A N I S A T I O N A L Culture Size Risk Ownership Attrition Vendor cases rs Knowledge sharing processes Hierarchy ( Management reporting, formalisations) Cross cultural communication ( F 2 F , meeting places) Case agents Perceptors Practices affecting key success drivers in the offshore software development environment Decomposition Synthesis Employee skills (Technical, project management skills) Process controls (Access rights on portals, audits, documentation) Certifications (ISO , CMM, patents) Social representation (Websites, offshore offices, overlap in time) External influences 272 Figure 14 explains the analysis strategy used to understand the vendors’ perceptions for the way they apply their knowledge sharing processe s. The external influences which affect the vendors’ perceptors are also listed. The next section analyses each organisational perceptor by applying ST to understand how vendors (agent s) associate significance, domination and legitimation of work structures in different societal contexts to define their knowledge sharing practices. 9.4 Cross case analysis The first lens identifies external influences of the national and organisational contexts such as size, culture, risk, ownership and attrition which impact the vendors’ work structures for identified key success drivers. As has been discussed in section 9.2, these contexts further influence the vendors’ knowledge sharing practices and their related work structures. The five mentioned external influences affecting vendors’ work structures are now explained within the context of this study. Th e two cultural settings investigated in this study are New Zealand and India. Next, the organisational sizes have been divided into two groups, which are large (group A) and SME (group B). The vendors’ risk depends upon the type of contracts they generally enter into with offshore clients/ business partners. These have been identified as high for fixed contracts and low for T&M contracts. The degree of ownership has been categorised into three types, namely internal or wholly owned subsidiaries, partial as joint ventures and ex ternal ownership. Finally attrition values have been measured from 2005 to 2007, and have been taken directly by the vendors during the time of the interviews. The lens investigates the vendor cases through the national and organisational contexts to identify six organisational themes or perceptors which influence the vendors’ work structures for knowledge sharing. Focussing on the six identified organisational perceptors – hierarchy, cross cultural communication, employee skills, certifications, process controls, and social representation strategies – this s ection extends the cross case analysis to the higher levels of the three level cell design. 273 The empirical findings from higher level analysis have been reported by use of narrative discussions. The presentation of the narrative discussion used for each organisational perceptor follows Yin’s (2003, Preface p. xiii) style of presenting “illustrative case studies cited as examples” in “numbered boxes”. Case data illustrating specifics of vendor practices in support of the organisational perceptors have been described in vignettes in boxes. In this style, references to the case studies are high lighted separate to the main discussion and therefore this style does not obscure readability when explanations and alternative explanations need to be provided for the ten diverse social settings. Based upon the identified organisational perceptors, the following subsections explain the practices associated with the key success drivers for each preceptor. That said, the study extends the TE (theory to empirical) generalis ations to make EE (empirical to empirical) generalisations (Lee & Baskerville, 2003) as ope rational data is compared across multiple cases to give new insights on why some of the vendors practices differ for the identified key success drivers. 9.4.1 Hierarchy The representation of hierarchy in the vendor organisations has been identified by the role of management reporting and formalisation of methods used for software development processes. Investigation of vendors’ social settings have revealed that factors such as size, culture, risk associated with contracts and attrition of knowledge workers influence the hierarchal dictates within the organisations. However vendors have defined processes to overcome the negative impact associated with hierarchal work structures in their organisational networks to create a collaborative work environment for knowledge sharing. Vendors have realised the importance of their human assets (knowledge teams) in software development tasks and have implemented forums for creative dialogue to externalise individual experiences and insights into their organisational repository. However creative dialogue is restricted by too much formalisation of project tasks and documentation, as this leads to bureaucratic processes where project tasks are monitored and centrally controlled by managers. Such strict processes for knowledge-based jobs restrict the individual’s style of working and may lead to a dissatisfied a nd disgruntled workforce, who will eventually 274 leave the organisation. Thus vendors are making efforts to retain their knowledge professionals by choosing flatter hierarchies for knowledge-based jobs and are defining new work and compensation packages to encourage their knowledge workers. This study has shown that knowledge based organisations (agencies) have identified new meanings to hierarchy and though they need to have some formalisations to manage distributed tasks in the OSD environment, thes e organisations have defined structures to encourage collaboration and knowledge sharing between team members. Informal spaces are being created within organisations to enable smooth flow of knowledge from individual experiences of knowledge workers into collective knowledge domains to identify best practices for future project software deve lopment tasks. Knowledge professionals are informed about the preferred practices through training, peer reviews and open discussions. In this manner, knowledge workers are made to feel less constrained by the bureaucratic dictates associated with formalisations. Vendors with lower contractual risk encourage knowledge workers to interact directly with offshore clients and business partners without too much senior management intervention. But vendors with higher contractual risk generally involve senior management for direct interaction with offshore clients. The vendor practices which are considered to influence hierarchy structures are presented through narrative discussion for group A and group B separately (see Box 9.1 and Box 9.2). 275 Box 9.1 Group A vendors – Hierarchy The vendors have realised the need for a supportive environment to encourage workers to understand and apply their knowledge into the client’s software design. Each vendor said that they do not consider themselves to be hierarchal. However New Zealand vendors considered the Indian vendors to have hierarchal structural issues involving rank and status. The Indian vendors said that they could no longer afford to be hierarchical in a knowledge intensive activity like software development, as they could in manufacturing businesses. But international certifications used by Indian vendors required centralised control of distributed work processes thus bringing in some hierarchy. Accordingly Indian vendors are making efforts to dilute the hierarchical dictates of international certifications, by making the work place of knowledge workers more relaxed and friendly with open communication. Recreational facilities are provided and employees are encouraged with monetary incentives for goal based outcomes. The New Zealand vendors do not have to deal with the hierarchal and bureaucratic dictates of international certifications. Thus, they have flatter hi erarchal structures with more flexibility in their software development processes. Also rewards are not offered for individual achievements by the New Zealand vendors as is the case for the Indian vendors. Box 9.2 Group B vendors – Hierarchy The vendor attitudes towards hierarchy are changing as is evident by the following remark made by a young developer “ Now it is my mind skills which are required rather than machine skills – so companies cannot be bureaucratic and control us any more”. The vendors have realised the importance of their knowledge workers and have started to motivate individual team members to share their work habits and develop shared work perceptions. Thus bottom-up practices are followed in which individual contributions is recognised and awarded. The social settings indicate that vendors are mostly involved in fixed contracts with offshore clients, and therefore are not sharing risk with their cl ients. Hence these vendors are careful in their communication with offshore clients and prefer centralised control by senior management members of the vendors. The study finds that although centralised controls are used to manage processes in view of the high risks, these controls are not impl emented in a hierarchal or bureaucratic manner. 9.4.2 Cross-cultural communication Software development involves exchange of interrelated software tasks, and thus cross cultural communication plays a major role as distributed teams interact via technology to discuss interrelated project tasks or make extensions in the project development activities. Communication in the virtual spaces involves interaction by members belonging to different cultural groups spread across diverse geographical locations and time zones. Each 276 group is confined by the cultural and structural norms in their country contexts, and this is reflected in their work habits, dialogue delivery and language nuances when they socialise with each other. Thus communication across cultural groups involves mutual understanding of different structural norms as members socialise over technological tools to make sense of each other’s actions and bring about a shared frame of reference for achieving common goals. Vendors have defined new work practices to ove rcome issues associated with the virtual environment. The study has revealed that vendors consider communication over virtual technology tools need to be complemented with some direct F2F interactions at common physical locations to bring about more awareness of each other. Direct interactions help to bring in a shared glocal context for work and social well being between individuals and organisations, and this helps to remove the exclusiveness associated with different cultural and organisational groups. Thus the information exchange is influenced not just by technological environment but also by the social and cultural environment. However the nature of work sent offshore also plays an important role for deciding the practices associated with cross cultural communication. For instance, if the work deals with confidential data it may not be conducive to have direct interactions between diverse cultural groups. In such cases, vendors use se parate communication channels to achieve both client confidentiality and provide technical task details to development teams located in other nations. This research also reveals that vendors with fixed contracts (or higher contractual risk) are more careful with the processes employed for cross cultural communication. These vendors prefer to have F2F communication between similar cultural groups and have also set up centres near client locations to make client feel that the vendors belong to similar demographic cultures. Other practices to overcome challenges asso ciated with cross-cultural communication are having overlap in working hours across different time zones to enable synchronous communication over VTT. This enables “simultaneous processing” of “here and now” knowledge to clarify specific practical contexts (Nonaka and Takeuchi, 1995, p. 60), as 277 team members can work together on interrelated project tasks. Vendor also consider training of their teams in soft skills such as English language, neutral accents and presentation skills, to help in removing exclusiveness and stereotyping associated with different cultural groups. Case illustrations on cross cultural aspect of the vendors belonging to group A and group B vendors are described with narrative discussions (see Box 9.3 and Box 9.4). Box 9.3 Group A vendors – Cross-cultural communication F2 F communication is preferred across diverse cultural groups, to enable understanding of the non documented and informal tacit details of client requirements, which can then be passed to the offshore development teams over VTT. However one vendor deals with confidential medical details of offshore clients and is aware of their clients’ apprehensions of sensitive data being se nt offshore. This vendor (NZ2) prefers direct communication with clients to occur with similar cultural groups. With the exception of NZ1, who only had local clients during the time of the interviews, the other three vendors also have offices in offshore client locations. Offices at client locations make clients think locally, and this brought in a sense of doing business with a local vendor, as opposed to doing business with an offshore vendor. Box 9.4 Group B vendors – Cross cultural communication The study shows that vendors have identified some meanings to their global and local contexts. A general agreement is that cultural differences have some impact on the work environment, and each vendor has identified strategies for communicating across cultural groups. Some strategies used are clear defined project tasks leaving little room for misinterpretation, frequent meetings over VTT for follow up on work commitments, ov erlap in office time to enable communication in real time, offices near client sites to bring local visibility and training in local and global usage of language nuances to build closer rapport. The vendors belonging to group B operate at higher risk in projects with fixed contracts. The study finds that these vendors do not prefer direct interaction of different cultural groups involving vendor teams and client teams. One vendor (i.e. NZ3) who is involved in risk sharing with the client does not consider cross-cultural communication conducted F2F to be an issue and they encourage direct communication between their development teams and client teams. 278 9.4.3 Employee skills The virtual environment of OSD is influenced by both social and technical practices as individuals (agents) link project specific knowle dge acquired from diverse social structures into a coherent tangible solution. Vendors have identified practices for achieving a balance between agent’s expertise and the social struct ures existing within the organisations. This section focuses on vendors preferences for employee (agent) skills to help in the knowledge creation and transformation process across diverse societal structures. It also investigates the vendors’ practices to retain and motivate their employees to share their experiences and insights with other team members. The research study finds that overall the New Zealand organisations prefer employees with better management skills rather than with technical specialist skills for software projects. On the other hand the Indian vendors prefer employees with technical qualifications and other specialised skills in programming and construction of software. One reason for this preference as the study has found is that most of the New Zealand vendors have contracted out technical tasks to offshore development centres in low cost countries, and therefore their work environment involves management and scheduling of project tasks developed at offshore partner sites. The New Zealand vendors are mainly intermediaries who have further contracted software development work to vendors belonging to low cost countries. On the other hand, the work environment at the Indian vendor locations require more technical skills, as they have to build software modules and report project tasks to their offshore partners. Accordingly, based upon the existing global labour market conditions and nature of their work, vendors have identified their work content in the knowledge based industry. Regarding measures taken by vendors to retain their knowledge professionals with preferred skill sets, the study has identified the following strategies: employee training, offering incentive packages, not re-hiring employees who have previously left employment of the said vendor organisation and certifications to manage processes on developing human assets. The study also revealed that Indian vendors are more susceptible to staff turnover and have defined more measures than New Zealand vendors to retain their staff. 279 The vendor preferences for employee skill sets fo r software development activities by group A and group B vendors are found to be similar. Thus they are described together in one box (Box 9.5). Box 9.5 Group A and B vendors – Employee skills The New Zealand vendor organisation prefers employees to have customer relationship management skills which they refer to as “high end tasks”, rather than technical skills. The high end tasks imply project administration, project management and client facing skills. On the other hand, the Indian vendors lay more emphasis on developers having technical skills rather than people skills. The Indian development teams are invo lved in construction and implementation of the client projects; while the New Zealand vendors are involved in project management and administration tasks, as the New Zealand vendors have mostly outsourced the t echnical project construction details to offshore partners in low cost countries. The Indian vendors have higher attrition as compar ed to New Zealand vendor s, and they take extra measures to retain staff. They have implemented many reward schemes to recognise individual achievements and motivate individuals to share their expertise with others. 9.4.4 Certifications Offshore software development is becoming pervasive in the software industry and organisations are adopting global delivery business models such as CMM, for improving their productivity and quality (Ramasubbu et al., 2008). These global models require a huge investment of organisation’s time, processes and resources for full realisation of benefits in their software quality and learning initiatives. However to achieve high process maturity in global models, organisations need to establish a proper work culture for encouraging organisational learning (Keane, 2003). Each model identifies separate KPAs 22 based on a framework which serves as a guide for rating software processes of individual organisations. Organisations applying for such global models (or certifications) are audited by reputed international agencies, which measure and rank the organisation’s processes for productivity and quality improvements against the KPAs in the framework. The study has investigated the significance attached to global delivery models (e.g. CMMI, ISO) by the ten case studies. The case data has revealed that the significance of accreditation by global agencies is felt by the large Indian vendors only. The large Indian 22 Key process area 280 vendors consider international certifications necessary to inform offshore clients of their capabilities and help in building their reputation. Interestingly none of the New Zealand vendors or the medium sized Indian vendor considers such certifications necessary to enter the international market. They neither have any certification, and nor do they have any intention to get themselves certified. One of the New Zealand vendors commented that the reason organisations use certifications is to prove rather than to improve their work processes. The smaller sized vendors also said that in ternational certifications are expensive to maintain, and having certifications can affect the vendors’ pricing strategy with costs being passed on to the clients. It is also reasonable to assume that international accreditation may not be preferred also because the accreditation process is a recurring expense, and may not be financially viable for the small and medium sized vendors. The vendor perceptions on significance of international certifications and their impact on their organisational structures are described in Box 9.6 and Box 9.7. Box 9.6 Group A vendors – Certifications Certifications are considered necessary by large Indian vendors to enter the international offshore software market and make the offshore client more aware of their professional capabilities. Moreover, certifications are also considered help ful to bring more maturity in vendor’s work processes, as each task needs to be documented in explicit detail. This in turn safeguards vendors from project disruption if any of the knowledge workers suddenly leave employment. An interesting comment made by an interviewee of the Indian pilo t case study was that certifications were similar to “vaccinations” for entering in the offshore market. Indian vendors have displayed scanned images of their international certificates on their websites. In contrast, none of the New Zealand vendor organisati ons have international certifications or consider them to be relevant. 281 Box 9.7 Group B vendors – Certifications None of the group B vendors have international cer tifications. All the vendors consider certifications as expensive overheads, and are not keen on having the bagg age that came with certifications. One vendor (NZ5) who previously had ISO 9000 certificatio n said that they have no intention of getting re-certified. However, one of the vendors (IN5) has some patents, which they consider more important than certifications and which has distinguished them from other vendors. The patents have been mentioned with great pride on their websites and were also mentioned to the researcher during the interviews. Initially IN5 was also member of Safe Harbour, which certified them as having secure processes and policies in place for client privacy and client confidentiality. However, IN5 is no longer certified by Safe Harbour, though not much explanation was offered on why the membership has been discontinued. 9.4.5 Process controls To deal with the complexities of knowledge in a distributed environment, organisations identify some control mechanisms to cross check on project progress through use of standardised procedures, checklists and templates. Other controls involve conducting audits to ensure that proper processes are being followed in the development activity, use of structured software development methodologies specifying project schedules and milestones, definition of privileges (i.e. read only, read and write, delete logs) in organisational portals and management reporting processes. However the level of formalisation in applying the process controls can be attributed to the influences by the constructs of size, quality certifications and attrition. The process controls involve defined rules, use of standard templates and checklists, and conducting of audits (internal or international) to ensure proper processes ar e being followed. Together all these bring in strict reporting norms and these lead to implementation of formal process controls. Thus process controlling structures are created as formal processes signify meanings of legitimacy and dominate work flows in the knowledge sharing cycle. The group A Indian vendors (IN1 and IN2) having certifications from international agencies and use very strict process controls for their development processes. One New Zealand vendor (NZ5) who was earlier certified by international agencies has also defined strict discipline in the use of standard templates, checklists and updates on organisational portals. 282 But the case data analysis also reveals that the other Indian vendor organisations (belonging to group B) though not being internationally certified but have high attrition levels, have implemented more strict process controls in their software project management and scheduling activities than the New Zealand vendors. The process controls used by vendors is explained via narrative discussions in Box 9.8 and Box 9.9. Box 9.8 Group A vendors – Process controls The large Indian vendors have certifications and use very strict and disciplined process controls which are formally monitored by their management. One Indian vendor clearly stated: “ If it can’t be documented, it cannot be transferred”. Similarly the other vendor said their organisation is under the “ signature raj” , as all documents have to be signed by senior managers. The Indian vendors have defined checklists such as FMEA, internet traffic checks, and other formal reports which are kept under centr alised control by a separate department. Paper copies of these documents are stamped as “True Copy ” before they can be used by the development teams. Surprise internal audits are held by other departmental teams, and “NCR” [non compliance reports] are issued if any member of the team has filed photocopies or printouts of project documents without the stamping of “True Copy”, or has filed “true copies of older versions” of project documents. Teams are encouraged to access the read only digital data files from the shared project workspaces, rather than keep hard paper copies. A project manager commented that some of these formal practices “often hampered” the smooth working processes. But the controls established by the New Zealand vendors on their software development processes are not as strict and formal as those established by the Indian vendors. The New Zealand vendors have established a support environment with rules and checklists, which serves more as guidelines, rather than as fixed rules and procedures. 283 Box 9.9 Group B vendors – Process controls Most of the vendor organisations in group B have defined process controls to manage their explicit knowledge repository. The process controls an d related measurements of project tasks are maintained by senior management; however these controls and estimations are not very rigid. Vendors said that too many measurements and controls are not needed as they are an “over kill” of processes. One New Zealand vendor (NZ5) which earlier had ISO certification used formal methods such as pre-defined templates and document control for monitoring and tracking process activities. However, the other New Zealand vendor organisations used less stringent process controls for their software development processes. The Indian vendors though not certified by international agencies have also been found to use formal process controls (i.e. templates, checklists, ve rsion control measures). These vendors have high attrition and are wary of using non standard processes for project tasks, which may be difficult to comprehend if the developer responsible for the project suddenly leaves the organisation. 9.4.6 Social representation strategies Offshore outsourcing has triggered a new social structure in the way organisations operate as clients and vendors belonging to diverse cultures take measures to build trust in relationships. Vendors are sensitised to client apprehensions in sharing knowledge across dissimilar social spaces. Based upon their interpretations of the offshore social environment, vendors have defined measures to bring about awareness of their work and social commitments to offshore groups. They used many social representation strategies, like having international certifications and also highlighting their past successes, social commitments and displaying their infrastructural assets on their corporate websites to inform prospective clients on their integrity, capability and predictability. Informing offshore clients and partners of th eir technical and social commitments through websites is felt necessary to bring visibility in the virtual environment, where physical interaction is often limited. The large vendors also have offshore offices near client locations to bring more visibility of themselves to the offshore groups. References from previous clients whose projects have been comp leted are provided to prospective clients to give the prospective client confidence on the vendor’s capabilities and commitments. 284 Moreover virtual private networks hosting organisational portals are also used to display work commitments across distant locations. Thes e portals help in building trust as they facilitate faceless commitments into scripted tasks or facework commitments among distributed team members (Sharma & Krishna, 2005). The various social representation strategies used by vendors to bring about awareness of themselves to local and offshore groups is now described (see Box 9.10 and Box 9.11). Box 9.10 Group A vendors – Social representation strategies Vendors use websites and offshore offices near client locations to make their clients more appreciative of their social, economic and cultural values. These vendors display past project successes and client testimonials on their websites. Details of their infrastructural assets such as locations of registered offices in different countries are also displayed on the websites. The offices at client locations make the client feel as if they are interacting with a vendor sharing the same demographic culture, and help to eliminate barrier s for trade of software services across nations. Organisational portals are also used to bring visibility in work processes and make the distributed team members aware of each other. The Indian vendors have also displayed scanned images of their many international certificates, as proof of their organisation’s matur ity and secure processes. The Indi an vendors are also involved in community service activities, and have displayed these activities on websites to show their corporate responsibility to the underprivileged members of society. Box 9.11 Group B vendors – Social representation strategies Vendor organisations use websites to highlight their knowledge capital, brand name and past project experiences to prospective clients. However one vendor (NZ5) does not have a website but they are offered many high profile projects by their offshore partner who operates more globally. The Indian vendors have offshore offices near client countries. These offices help to represent them as local vendors in that country, and are considered to help in eliminating the negative perceptions felt by clients for offshore and culturally diverse vendors. One New Zealand vendor (NZ4) also has offices in client countries, but they consider offshore offices as a commercial strategy of being near clients, rather than sharing of local cultures. Organisational portals are also used to bring visibility in work processes and make the distributed team members aware of each other. Only one New Zealand vendor (NZ3) is involved in community service activities, which have been mentioned explicitly on their website. 285 9.5 Discussion and findings This study has brought together empirical data from the ten case studies across two country contexts to provide insights on the vendors’ work structures for the six organisational perceptors. The six organisational perceptors – hierarchy, cross cultural communication, employee skills, certifications, process controls, and social representation strategies – have been found to influence vendors’ knowledge sharing practices for the three strategy groups. Though literature has identified the drivers influencing vendors’ knowledge sharing practices (refer Table 8), there has been little study to investigate the how these practices vary in different national and organisational contexts. This research has used a logical positivist lens to offer insights through rich descriptions on vendor perspectives for knowledge sharing across multiple case environments. The empirical statements’ describing different aspects has helped in providing EE generalisability across the ten case studies. However Lee and Baskerville (2003, p. 235) warn that “EE generalisations involving descrip tive statements are not generalisable beyond the domain that the researcher has actually observed”. This research study does not claim to make EE generalisations beyond the sample size or beyond the two country contexts to a wider population; however it offers new insi ghts which may require further research involving quantitative study such as surveys to make more general propositions for ET (empirical to theory) generalisability. Thus in the present study, these insights may be treated as EE generalisations which are “well-founded but as yet untested hypothesis” (Lee & Baskerville, 2003, p. 224). The study extends the vendors’ knowledge sharing processes across the three levels to re- define the conceptual framework (refer Table 27). TE generalisations have confirmed the knowledge management theories for vendors in the OSD environment (refer Figure 13) and EE generalisations have used BLM to explain the analytical process for the six organisational perceptors – hierarchy, cross cultural communication, employee skills, certifications, process controls, and other social representation strategies – which influence vendors’ implementation strategies for knowledge sharing. 286 Next, the TE and EE generalisations have been combined to extend the literature on offshore outsourcing knowledge sharing processes. The initial conceptual framework (refer Table 27) has been informed by new findings across the three levels of analysis. Figure 13 shows that the drivers of the three strategy groups – transfer of tacit knowledge, management of explicit knowledge and relati onship building strategies – support each other in the knowledge sharing process. The three strategy groups interact with each other to convert individual knowledge which is in tacit form into new explicit collective knowledge held in organisational repositories across temporal, spatial and cultural spaces. Upgrades to the knowledge repositories are made as the newly created knowledge is applied and new insights are gained from them. Moreover in the virtual environment knowledge developed somewhere else has to be applied at another place. Teams engage in synching relationships as they share experiences and build shared contextual knowledge across the diverse spaces. The vendor organisation provides the necessary platform for the knowledge creation process. They define work structures for knowl edge exchange, but these work structures are in turn influenced by their perceptions of the national and organisational contexts in which they operate. The national and organisational contexts (i.e. culture, size, risk, ownership and attrition) are external influences over which the vendor has no control. Accordingly, these vendors identify rules and procedures based upon their perceptions and this in turn affects their work structures. The work structures are defined for hierarchy, cross cultural communication, employee skills, certifications, process controls and social representation strategies. The study finds that practices defined for key success drivers to enable knowledge sharing are different in different societal contexts, and this has helped in refining the conceptual framework. The revised conceptual framework is presented in Figure 15. 287 Figure 15 Revised conceptual framework . External influences Perceptors Knowledge Sharing Processes Process Controls (e.g., access rights, audits) Certifications (e.g., ISO, CMM) Employee Skills (e.g., technical, project management) Hierarchy (e.g., management reporting, centralised structures) Cross cultural communication (e.g., F2F, online social spaces) Social representation (e.g., websites, offshore offices) Relationship building strategies Transfer of tacit knowledge Management of explicit knowledge Size Ownership Culture Risk Attrition 288 The effects of the external influences (i.e. culture, size, risk, ownership and attrition) on the vendors’ organisational perceptors for defining their knowledge sharing practices within the macro contexts (i.e. New Zealand and India) are now discussed. The study finds that a country’s economic history influences the type of work activities offshore vendors enter into. The economic aspects of outsourcing favours India as a vendor destination and accordingly more software application development and services are produced there. Moreover, many New Zealand organisations too have outsourced their technical activities to low cost countries such as India. This has influenced the labour market needs and accordingly New Zealand vendor s prefer their employees to have better project management skills. On the other hand, Indian vendors are involved in the technical aspects of project construction and they prefer employees with computing skills. The Indian organisations have been found to have more formal management reporting structures leading to more hierarchal processes. Moreover, the large Indian organisations have certifications, which mandate very formal work structures within organisations. New Zealand organisations do not consider international certifications important and they operate in a more informal and flexible environment with flatter hierarchal structures. Certifications bring in many standards and templates which impose formal processes, leading to bureaucracy and hierarchy. Sahay et al (2003, p. 40) also found that “the methodologies and processes used in software development process themselves serve as instruments of power and control”, as they dictate enforcements in work structures. These large Indian organisations said that they could no longer afford to be bureaucratic with the change in market conditions and the growth of knowledge organisations, and are making efforts to flatten their hierarchal work stru ctures. However the other organisations (from both cultural groups) do not have certifications and they have more flexible work structures. Overall, the study finds Indian cultures to have higher power distance structures than New Zealand vendors which is in accordance with both Hofstede and GLOBE studies. The study also finds that Indian organisations place more emphasis more on financial rewards for employees than the New Zealand organisations. Accordingly, Indian organisations have a higher performance orientation than New Zealand organisations which is in disagreement with the GLOBE study. 289 Organisational size also influences the types of contracts vendors enter into, and this study has revealed that large organisations enter into both fixed and time and material contracts. Thus larger organisations in both countries (New Zealand and India) operate in a risk sharing environment with the client, while the smaller vendors operate with higher risk. This has a direct influence on the vendors’ work structures relating to cross-cultural communication. Vendors operating at higher risk are more cautious in their F2F communication strategies, and have identified practices involving F2F communication to occur with senior management only or between similar cultural groups. Also to minimise risk of project delays, the vendors use centralised controls to check on project progress and that project schedules are being met by their development teams. The degree of ownership has been found to be influenced by both size and culture. The large organisations from both New Zealand and India have no external ownership by offshore parent groups. But the smaller Indian organisations are wholly owned subsidiaries of offshore parent groups. These large Indian organisations market themselves on websites by listing their certifications and offices in offshore locations, and have direct interaction with clients for obtaining new contracts. However the smaller Indian organisations consider their offshore parent group as internal clients and they do not interact directly with external clients. On the other hand the New Zealand vendor organisations are not owned by offshore groups; rather they have opened wholly owned subsidiaries or started joint venture partnerships in low cost countries. These Ne w Zealand vendor organisations have sales offices near offshore client countries and they mostly interact with clients themselves for getting new contracts. Finally with regard to the attrition figures, the study reveals that attrition is generally high for knowledge based organisations. However, the attrition rates are higher for Indian vendors than for the New Zealand vendors. Accordingly, Indian vendors have to use more process controls to capture the complete work flows for each project, which in turn helps to reduce the impact of staff attrition. They use explicit documentation to make the management aware of project milestones or of targets which are yet not completed and management is aware of the developers’ present status of responsibilities. This also helps in transferring work to a new member, if a developer suddenly leaves the organisation. 290 9.6 Chapter summary The chapter has described the evaluation process along a three level design using within case and cross case comparisons. The evaluation has resulted in making TE generalisations as existing theories have been applied to empirical evidence to reveal vendor strategies for knowledge sharing. The TE generalisations have helped to describe the knowledge sharing processes which is informed by both theory and practice in the field of offshore software development. Next explanation building has been applied for identifying relationships between the different levels, and has been supported by narratives to help interpret the findings of the study. This has resulted in EE generalisations as rich insights have been offered on vendor perspectives for defining their knowledge sh aring strategies. The study identified six organisational perceptors – hierarchy, cross cultural communication, employee skills, certifications, process controls, and social representation strategies – which influence the practices associated with the key success drivers. These perceptors are in turn influenced by societal structures operating in the national and organisational environment contexts. These contexts are culture, size, risk, ownership and attrition. Next the analysis has been extended to macro level to shed some light on how these societal structures influence the offshore software development vendor environment in different country contexts (that is New Zealand and India in this study). The next chapter concludes this research study, summarising both the contributions and limitations and providing suggestions for further research. 291 CHAPTER TEN – Conclusions and Future Research 10.1 Introduction This study has examined offshore vendors’ knowledge sharing processes in the field of offshore software application development. The study has used logical positivist research methods to evaluate the practices associated with key success drivers identified from the literature to identify a conceptual framework. Qualitative data from ten case studies has been analysed in a three level cell design structure to further revise the conceptual framework. Existing theories have been confr onted with empirical statements (TE) and empirical statements have been compared with other empirical statements (EE) in diverse social settings to reveal new insights on knowledge sharing practices. The revised framework (refer Figure 15) has evolved with ‘systematic combining’ as existing theories informed empirical fieldwork to make TE generalisations and this led to deep probing into the ten case studies to bring together issues relating to social, cultural, technical and organisational factors for making EE generalisations. The principal inquiry of the research question asked how vendor organisations use their knowledge sharing processes in the offshore software development environment within a glocal society. The study investigated vendors’ work structures for integrating their tacit and explicit knowledge assets across diverse temporal, spatial and cultural spaces. The key drivers for knowledge integration identified from outsourcing literature on offshore software development were examined with kno wledge management theories and through a structurational lens. The key findings are reported in the next section, which include high level discussions summarising vendors’ socio-technical strategies for knowledge sharing in the current outsourcing environments of New Zealand and India. 10.2 Key findings Analysis from theoretical and empirical perspective led to identification of a conceptual framework to answer the research questions. Utilising Nonaka and Takeuchi’s (1995) SECI (Socialisation, Externalisation, Creation and Internalisation) cyclic model, knowledge 292 sharing processes of ten vendor organisations were examined at three levels, namely micro, meso and macro. Offshore software vendors use socialisation strategies to transfer tacit to tacit knowledge across distributed locations, externalisation strategies to extend their knowledge base by converting tacit to explicit knowledge base, creation strategies to refine best practices as the new explicit knowledge is combined with previously defined practices, and further internalisation of the new knowledge by application of the refined practices during the OSD process. The study has also examined the cultural perspectives of vendors to offer insights on diverse social structures which influence relationship building strategies across organisational and national boundaries. The first subsidiary question ‘what processes do vendor organisations consider important for transfer of tacit knowledge in the o ffshore software development environment?’ provided a focus on knowledge sharing involvi ng the bottom up activities within teams. Knowledge needs to be assimilated from individuals for better understanding of the software problem domain; next the assimilated knowledge is embedded into the organisational knowledge domain, which eventually leads to new practices being defined and documented. Powell (2004, p. 231) defines tacit knowledge as knowledge “residing outside the boundaries of documents and databases”, which is gathered from the “human asset” of organisations. The study identified socialisation and externalisation strategies involving face-to-face communication, asynchronous and synchronous tools (such as emails, discussion forums, chat rooms, blogs, amongst others), building employee capabilities (through training and reward incentives) and use of common meeting places (such as organisational portals for virtual meeting places, and offshore located offices or deployment of employees at offshore locations as physical meeting places) to gather tacit knowledge from the “human assets”. Qualitative data about these drivers further revealed that some vendors considered direct communication between vendor and client should be confined to similar cultures and also with senior management only. The second question ‘how do vendors manage distributed knowledge-based processes within the software development environment?’ provided a holistic view on the tangible elements used by organisations to manage and retain the knowledge acquired. Organisations have defined processes to benefit from the individual learning of knowledge workers by converting them into core organisational capabilities. Individual expertise is sought after to 293 identify new knowledge which is then stored in the organisational repository for further use. The study identified processes such as quality control, documentation, project reviews and status meetings, frequent updates on organisa tional portals and configuration control practices. Other practices to internalise knowledge are training, peer reviews and rewards to knowledge workers for new insights gained through knowledge sharing. These practices are felt necessary by knowledge based organisations , as they need to balance ‘human assets’ with ‘organisational assets’ to be able to apply the formal-informal, explicit-tacit knowledge at distributed sites. Giddens’ structuration theory has been applied to understand changing attitudes and social structural composition, as dissimilar cultural groups inform each other on common values and working behaviours in the virtual environment. This dynamic view of emerging social structures has helped to bring focus to the third research question and understand how offshore groups interact with each other. The third question ‘how does culture affect vendors’ relationship building strategies with offshore clients or partners in the virtual environment across organisations and nations?’ is answered by providing descriptions of various relationship building strategies. Vendors are taking measures to bring a glocal context, as local processes are influencing and being influenced by global events. The vendors are trying to represent themselves as belonging to similar demographic cultures to bring in more trust and confidence in their business relationships across cultural spaces. Vendors have added many relationship building st rategies to the software solutions being offered. Some strategies are cross cultural interaction between team members such as having vendor offices at client destinations, de ployment of employees at offshore sites, use of organisational portals with logins for offshore clients and partners and overlap in office time to enable synchronous communication. These help to bring visibility of work processes across virtual social spaces. Othe r social representation strategies involve websites displaying international accreditations, client testimonials and showing their corporate responsibilities with community service activities. The above three subsidiary questions feed into the main question ‘how do vendor organisations use knowledge sharing processes in the offshore software development environment within a glocal society?’. The thes is finds that vendor practices for knowledge sharing processes depends upon the national and organisational contexts, which in turn 294 influence the vendor perceptions and work structures, and are influenced by six organisational perceptors. The national and organisational contexts are culture, size, risk, ownership and attrition over which the vendor has no control. These contexts influences the six organisational perceptors, namely hierarchy, cross cultural communication, employee skills, certifications, process controls, and social representation strategies. The influence of each preceptor at the organisational and national level has been explained as follows: 1. Vendors have realised the need of flatter hierarchal structures in knowledge based organisations. However to manage the distributed and interdependent knowledge tasks, vendors have defined centralised controls to combine interrelated tasks on a common organisational knowledge repository. But the us e of centralised controls on knowledge sharing processes leads to hierarchal structures in organisations. Thus vendors are making efforts to reduce the hierarchal dictates of work structures by providing informal social spaces within organisations. The study finds Indian vendors have defined more centralised management controls and have more hierarchal structures than New Zealand organisations. 2. Cross cultural communication is key to knowledge sharing, bringing accountability in associated tasks, understanding of client and vendor working styles, eliminating exclusiveness of different cultures and fostering stronger relationships. The study reveals that practices for cross cultural communication are linked with the perception of risk felt by vendors. Small and medium sized vendors from both countries – New Zealand and India – undertake more risk with fixed contracts and are more cautious when communicating with offshore clients than the larger organisations. 3. Vendors have identified a mix of commercial, administrative, technical and social skills for construction and management of off-shored software projects. The study finds that New Zealand vendors further outsource the software development tasks to offshore partners in low cost countries. Hence, New Zealand vendors prefer to recruit employees with better commercial, administrative and social skills. Indian vendors are involved in the actual implementation of projects, and they prefer recruiting employees with more technical specialist skills. 295 4. Accreditation from international agencies for managing quality and maturity of software processes is considered essential by the large Indian vendors only. These vendors use international certifications to build their reputation in the global marketplace and streamline work process models. 5. Use of process controls (e.g. checklists, templates, archival policies, configuration management tools) is considered essential by all the vendor organisations for managing knowledge across distributed sites. The controls are needed for providing seamless integration of the interrelated modules from distributed teams into one coherent solution. Process controls also help to reduce the impact of attrition as project tasks are formally maintained which helps tasks to be more easily transferred to another team member if a team member leaves the project mid way. Overall the Indian vendors exercise more discipline and formalisation in their process controls as compared to the New Zealand vendors. 6. Vendors are aware of the risks clients undertake in offshore outsourcing, where they contract out development of software projects to third parties belonging to another country. Hence, vendors utilise social representation strategies such as branding their social, commercial and technical capabilities to make the clients feel more confident of investments they have made with offshore vendors. The social representation strategies used are building reputation through websites which display past project successes, client lists and community service activities; travel and direct meetings, and having offices at offshore locations. 10.3 Contribution Offshore software development is the leading business sector in the present IT offshore market (Gold, 2005), and vendors in different countries are opening software development centres worldwide to take advantage of the ne w business opportunities. However, there is a “dearth of research on the outsourcing processes” , as most extant literature focuses on “less messy” aspect of outsourcing such as outsour cing levels and outsourcing designs (Mol, 2007, p. 168). Mol adds “A better understanding of outsourcing processes increase the 296 practical relevance of academic research because practitioners spend much more of their time managing outsourcing processes, in the fo rm of projects, than they do analysing outsourcing levels”. Dibbern, et al. (2004, p. 86), are of the view that “research to date has been confined to a single-country perspective” and there is “scarcity of studies that take the vendor perspective into account”. They recommend that a deeper investigation with focus on individual IS functions of outsourcing will offer a more informed picture on micro level issues such as cross-cultural aspects and individual vendor perspectives. To the author’s knowledge, this research study is the first attempt to understand the individual vendor perspectives associated with the outsourcing processes in the field of software application development processes from multiple countries. This research is based on ten case studies, a nd uses empirical data from the ten cases. The ten organisational settings have helped to bring a broader relevance to professional practice, leading to a certain level of EE generalisability as opposed to providing simple anecdotal evidence from a single case study. Empirical evidence from multiple cases with use of multiple sources of evidence from different organisational settings provided detailed descriptions of the vendors’ practices to give rich insights on organisational preferences in offshore software development processes. This study has utilised both within case and cross case comparisons across three levels of analysis to make the following contributions: 1. This research used a multiple case study approach to compare the micro level issues or key success drivers for offshore software de velopment from the vendors’ perspective. Empirical evidence for each driver has revealed that differences in social and cultural contexts influence the knowledge based processes for the key drivers in the offshore outsourcing environment for software development. Vendors have identified varying social structures for managing tacit-explicit, formal-informal knowledge based upon their perception of clients’ apprehensions and trust levels towards diverse cultural vendor groups. 297 2. The research study has provided an empirical assessment of Nonaka and Takeuchi’s (1995) SECI model in the offshore software development environment by examining vendors’ knowledge management strategies to assimilate organisational learning into an explicit knowledge repository. Takeuchi and Nonaka (2002, p. 142) have also stated that although much has been written about the importance of knowledge in management, “little attention has been paid to how knowledge is created and how the knowledge creation process is managed”. The empirical assessment method used in this study adopted a mixed mode of inquiry to provide insights on the operational processes for knowledge creation and knowledge management in different country contexts. In- depth analysis of the case studies revealed New Zealand vendors are intermediaries and have off-shored some portion of their so ftware development activities to low cost countries. The study also finds that knowl edge based organisations are changing to flatter hierarchal structures despite application of centralised controls which restrict individual working styles. Vendors have each also realised the need for a more glocal context and have each defined strategies for representing themselves locally across diverse cultures. 3. Existing theories and empirical evidence have been applied to make TE and EE generalisations across three levels of analysis on multiple case studies. The generalisations have helped to develop a framework for evaluation of the operational aspects of vendors’ knowledge based processes in the offshore software development environment. 10.4 Implications of the study The research study has synthesised the complex processes involved with knowledge sharing in the offshore software development environment and has implications for both theory and practice. These are discussed in the following subsections: 298 10.4.1 Implications for theory An analysis of outsourcing literature helped to identify the key success drivers. This study investigated each success driver within two country contexts, to provide insights into the implementation aspects of these drivers. Next, utilising SECI model for organisational knowledge, this study explained the knowledge creation and assimilation processes in detail for ten vendor organisations. Also, Giddens’ structuration theory has been used to understand the changing work structures of knowledge based organisations as they are influenced by diverse social and cultural settings. Hence, this thesis has confronted real-world application and provided generalisations from theoretical statements to empirical statements in different settings, where the theory had not been previously empirically tested (Lee & Baskerville, 2003). The research has administered academic theories to a specific organisational setting to test and confirm the theories in that particular setting. Accordingly this research study has legitimised existing academic theories on offshore outsourcing and knowledge management to the practitioner world. This thesis reflects the outsourcing theory and extends the published literature to: 1. Propose a taxonomy of success drivers from the vendors’ perspective. These drivers give a micro level view on the operational aspect of the outsourcing process. The meso level view identifies organisational conditions (perceptors) which influence the work structures for the key success drivers. Finally, the macro level view identifies the local, social and cross cultural influences surrounding knowledge workers at the national level in the offshore software development environment. 2. Provide a framework (refer Figure 15) for identifying vendor strategies based upon which the key success drivers are categorised into different vendor strategies (refer Figure 13), such as tacit knowledge transfer, management of explicit knowledge and relationship building. The framework recognises that these vendor strategies are not exclusive and together influence the organisation’s knowledge creation process. The knowledge creation process is an open and dynamic system in which knowledge is 299 continually exchanged when members make sense of their work structures to eventually assimilate and transform the knowledge from individual level to the collective level (i.e. organisational knowledge repository). 10.4.2 Implications for practice The study brings to light the real world settings of vendors’ knowledge sharing processes in different social settings. Empirical statements providing descriptions of ten diverse case settings have helped to make EE generalisations across vendor groups. Though literature has identified key success drivers in the OSD environment, the EE generalisations have revealed that vendors’ implementation practices for the identified drivers are also influenced by organisational and national structures. The generalisability of EE statements has thus provided rich insights on practitioner perspectives and exposed subtle differences in the knowledge sharing processes in diverse social and cultural settings. The thesis reflects practitioner perspectives and has implications for practice. The benefits for practitioners are as follows: 1. The software development experiences of ten vendor organisations in two country contexts has been reported with use of par ticipant voices to give the reader a better understanding of the real world settings. The report has provided rich insights on practitioners’ operational processes for organisational learning in a glocal environment. 2. The research has provided an understanding of vendors’ relationship building strategies with offshore clients and partners belonging to different demographic cultures. It has reported some of the vendor concerns and presented their strategies to build trusting relationships across temporal, cultural and social spaces. 3. The study has compared offshore software development vendors across two country contexts to reveal the technical, social and cultural work structures within these country environments. 300 10.5 Limitations As with any research there are identifiable limitations to this study. The identifiable limitations call for further research to be conducted that will extend the current study. This section identifies the limitations of the research and then gives suggestions for future research in this area. The limitations of the research have been identified as follows: 1. This research has provided a snapshot view of vendors’ practices for offshore software development as opposed to longitudinal inquiry. Although, follow up interviews were conducted at vendor sites, the study was confined to two visits within a span of one and a half years. Each visit involved interviews with senior and middle management employees of the vendor. A longitudinal inquiry with frequent interviews over shorter intervals of time would give a better understanding of the vendors’ operational tasks over time. It would help answer questions – Do vendors’ change their processes with local and offshore clients? How often do they have repeat contracts from clients? How misunderstandings are resolved between distributed teams involved in common projects? – and provide new insights into operational practices and also minimise any distortions of past events by the interviewees. 2. The case study has been conducted from the vendor organisations’ perspective. Although both senior and middle management employees of the vendor were interviewed, a better understanding of client or business partner’s relationship with the vendor would have been possible if interviews were conducted with the client or business partner also. 3. The two countries investigated in this study are very diverse in economy, size, language and cultural settings. This may have an impact on organisational practices though the types of industry cases are the same in both countries. However, the choice of countries is restricted by the researcher’s contacts such as entry to local organisations and available resources. Although, the two countries New Zealand and India are vastly 301 different, the study has provided a fresh and broader perspective of software processes of different cultures and economies. Also, the researcher is familiar with cultures pertaining to both countries, which has helped gain better access to the vendor organisations. 10.6 Future research This study provides a framework for future research in the area of offshore software development processes. The future directions of research lie in using the proposed framework as a support tool for understanding micro, meso and macro level processes for vendors engaged in offshore outsourcing. Future study can encompass vendors involved in other software areas besides software development such as software application maintenance, call centres or other service activ ities. Further research can utilise case studies from other countries which are popular choices for off-shoring software work to understand how the vendors belonging to these countries manage their knowledge transfer and organisational learning processes. This will help to validate the framework and provide further refinements of the key success drivers. Using the operational processes identified in the proposed framework, further research can be conducted on analysing outsourcing relationships from the client’s perspective. Client experiences will help in understanding whether these processes really bring about a technical, social and cultural understanding, as is thought by the vendor teams. The EE generalisations made across the multiple case studies have provides some “well- founded but as yet untested hypothesis” (Lee & Baskerville, 2003, p. 224). Future research may involve testing of the proposed hypothesis with quantitative studies involving surveys and statistical sampling techniques. Finally, this research employs a logical positiv ist stance with multiple case studies. Further research may also include longitudinal in depth study of fewer cases to gain insights on the changing structures and processes of the offshore software vendors. Longitudinal study will provide a continuous link of activities or events which are undertaken during software development to provide rich descriptions on operational processes of individual and group goals. 302 11. References Adler, P. S., McGarry, F. E., Iri on-Talbot, W. B., & Binney, D. J. (2005 ). Enabling Process Discipline: Lessons from the Journey to CMM Level 5. MIS Quarterly Executive, 4( 1 ) , 215- 2 27. Agarwal, R., Kumar, M., Mallick, Y., Bharadwa j, R. M., & Anantwar, D. (2001). Estimating Software Projects. SIGSOFT Software Engineering Notes, 26 ( 4 ) , 60-67. Agerfalk, P. J., & Fitzgerald, B. (2006). Flexible and Distributed Software Processes: Old Petunias in New Bowl? Communications of the ACM, 49 ( 1 0 ) , 27-34. Agerfalk, P. J., & Fitzgerald, B. (2008 ). Outsourcing to an Unknown Workforce: Exploring Opensourcing as a Global Sourcing Strategy. MIS Quarterly, 32(2 ), 385 -4 09. Alavi, M. & Leidner, D.E. (200 1 ). Review: Knowledge Management and Knowledge Management Systems: Conceptula Foundations and Rsearch Issues, MIS Quarterly, 25(1), 107-136 Alavi, M., & Tiwana, A. (2002 ). Knowledge Integration in Virtual Teams: The Potential Role of KMS. Journal of the American Society for Information Science and Technology, 53(12), 1 02 9 - 10 37. Allee, V. (2003 ). Evolving Business Forms for the Knowledge Economy. In Handbook on Knowledge Management (Vol. 2): Knowledge Directions, Springer-Verlag, Berlin, 605-62 2. Aman, A., & Nicholson, N. (2003 ). The Process of Offshore Software Development: Preliminary Studies of UK Companies in Malaysia. In M. Korpela, R. Montealegre & A. Poulymenakou (Eds.), Information Systems Perspectives and Challenges in the Context of Globalization (Vol. 254): Kluwer. Anconna, D. G., & Caldwell, D. F. (1992 ). Bridging the Boundary: External Activity and Performance in Organisational Teams. Administrative Science Quarterly, 37, 634- 66 5. Armour, P. (2006). The Business of Software: The Learning Edge. Communications of the ACM, 49 ( 6 ) , 19-2 2. Aubert, B. A., Dussalt, S., Patr y, M., & Rivard, S. (199 8). Managing the Risk of IT Outsourcing. Paper presented at the 32nd Annual Hawaii In ternational Conference on System Sciences. Baird, L., & Henderson, J.C.(2001). The Knowledge Engine: How to Create Fast Cycles of Knowledge-to-Performance and Performance-to-Knowledge. Berrett-Koehler Publishers, San Francisco, CA. Baker, A. (2006). In Search of the Next Bangalore. Time (June 26, 2006), 22-23. Banerjee, A. V., & Duflo, E. (2000 ). Reputation Effects and Limits of Contracting: A Study of the Indian Software Industry. Quarterly Journal of Economics, 115(3), 989-1017. Bashein, B., & Markus, M. L. (1997). A Credibility Equation for IT Specialists. Sloan Management Review, Summer, 35-4 4. Baskerville, R., Dulipovici, A. (2006 ). The Theoretical Foundations of Knowledge Management. Knowledge Management Research & Practice 4. pp. 83-10 5 303 Bazeley, P. (2007). Qualitative Data Analysis with NVivo (1st ed.). London: Sage. Beck, J. S. (2002). IT Services Sourcing Goes Strategic (No. AV-16-2 10 9 ) : Gartner. Becerra-Fernandez, I. and Sabherwal, R. (2001 ). ‘Organisational knowledge management: a contingency perspective’. Journal of Management Information Systems, Vol 18, No.1, pp 23- 55. Benbasat, I., Goldstein, D. K., & Mead, M. (198 7 ). The Case Research Strategy in Studies of Information Systems. MIS Quarterly, 11 (3 ), 369 -38 6. Benbasat, I., Goldstein, D. K., & Mead, M. (200 2 ). The Case Research Strategy in Studies of Information Systems. In M. D. Myers & D. E. Avison (Eds.), Qualitative Research in Information Systems, (pp.79-113 ). Thousand Oaks: Sage. Benbasat, I., & Weber, R. (1996 ). Research Commentary: Rethinking Diversity in Information Systems Research. Information Systems Research, 7 ( 4 ) , 389- 3 99. Borchers, G. (2003). The Software Engineering Impacts of Cultural Factors on Multi-cultural Software Development Teams. Paper presented at the 25th International Conference on Software Engineering, Portland, Oregon. Bordia, P. (1997). Face-to-Face versus Computer-Mediated Communication. The Journal of Business Communication, 34 ( 1 ) , 99-120. Brady, D. (2003). All the World's a Call Center. Business Week. Bryman, A. (1995 ). Quantity and Quality in Social Research. London: Unwin Hyman. Caldwell, B. J. (1994 ). Beyond Positivism: Economic Methodology in the Twentieth Century. London: Routledge. Carmel, E. (1999 ). Global Software Teams. New Jersey: Prentice-Hall. Carmel, E. (2003 ). The New Software Exporting Nations: Success Factors. The Electronic Journal on Information Systems in Developing Countries, 13 ( 4 ) , 1-12. Carmel, E., & Agarwal, R. (2001 ). Tactical Approaches for Alleviating Distance in Global Software Development. IEEE Software (March/April, 2001 ), 22-2 9. Carmel, E., & Eisenberg, J. (2006). Narratives that Software Nations Tell Themselves: An Exploration and Taxonomy. Communications of the Association for Information Systems, 17 , 851 -87 2. Carmel, E., & Tija, P. (2005). Offshoring Information Technology: Sourcing and Outsourcing to a Global Workforce. New York: Cambridge University Press. Cavaye, A. (1996). Case Study Research: A Multifaceted Research Approach for IS. Information Systems Journal, 6 , 227- 24 2. Cecez-Kecmanovic, D. (2001). Doing Critical IS Research: The Question of Methodology. In Qualitative Research in IS: issues and trends (pp. 141-1 62 ). Hershey PA: Ideas Group Publishing. 304 Choo, C. W. (2006). The Knowing Organisation: How Organisations use Information to Construct Meaning, Create Knowledge, and Make Decisions. New York: Oxford University Press. Cochran, L. R. (1990 ). Narrative as a Paradigm for Career Research. In R. A. Young & W. A. Borgen (Eds.), Methodological Approaches to the Study of Career. New York: Praeger. Confederation of Indian Industry. (200 7 ). Definition of Micro, Small and Medium Enterprises w.e.f 2 October 2006 (MSMED Act 2006). Retrieved 21 October 2008, from http://cii.in/menu_content.php?menu_id=597 Conradi, R., & Fugggetta, A. (2002). Im proving Software Process Improvement. IEEE Software, 92- 9 9. Constantine, L., & Lockwood, L. (1993 ). Orchestrating Project Organisation and Management. Communications of the ACM, 36 ( 1 0 ) , 31-43. Crampton, C. (2001 ). The Mutual Knowledge Problem and its Consequences for Dispersed Collaboration. Organisation Science, 12(3 ), 346 -37 1. Creswell, J. W. (2008). Educational Research: Planning, Conducting, and Evaluating Quantitative and Qualitative Research (3rd ed.): Upper Saddle River, N.J. Cullen, P. (2002). The Pitfalls of Client/ Server Development Projects. In P. C. Tinnirello (Ed.), New Directions in Project Management (pp. 373-38 2 ). Boca Raton: Auberach. Cullen, S., Seddon, P., & Willcocks, L. P. (2005). Managing Outsourcing: The Life Cycle Imperative. MIS Quarterly Executive, 4 ( 1) , 229- 2 46. Das, T. K., & Teng, B. S. (2001 ). Trust, Control and Risk in Strategic Alliances: An Integrated Framework. Organisation Studies, 22( 2 ) , 251-28 3. Davenport, T.H. & Prusak, L. (1998 ) Working Knowledge: How Organisations Manage What They Know. Harvard Business School Press, Cambridge, MA Davey, H., & Allgood, B. (2002 ). Offshore Development, Building Relationships across International Boundaries: A Case Study. Information Strategy: The Executive's Journal. DeLone, W., Esponosa, J. A., L ee, G., & Carmel, E. (2005 ). Bridging Global Boundaries for IS Project Success. Paper presented at the 38th Annual Hawaii International Conference on System Sciences, Big Island, Hawaii. Denzin, N. K. (1978 ). The Research Act: A Theoretical Introduction to Sociological Methods (2nd ed.). New York: McGraw-Hill. Denzin, N. K. (1989 ). The Sociological Interview. In N. K. Denzin (Ed.), The Research Act: A Theoretical Introduction to Sociological Methods (pp. 102-1 20 ). Englewood Cliffs, N.J.: Prentice Hall. Denzin, N. K., & Lincoln, Y. S. (2003 ). Introduction: The Discipline and Practice of Qualitative Research. In N. K. Denzin & Y. S. Lincoln (Eds.), Handbook of Qualitative Research (2nd ed., pp. 1-45). California: Sage. 305 DeSouza, K. (2003 ). Barriers to Effective Use of Knowledge Management Systems in Software Engineering. Communications of the ACM, 46 ( 1 ) , 99-10 1. Dibbern, J., Goles, T., Hirscheim, R., & Jayatilaka , B. (2004). Information Systems Outsourcing: A Survey and Analysis of the Literature. DATABASE for Advances in Information Systems, 35 ( 4 ) , 6-102. Dibbern, J., Winkler, J., & Heinzl, A. (2008 ). Explaining Variations in Client Extra Costs between Software Projects O ffshored to India. MIS Quarterly, 32 ( 2 ) , 333-3 66. Dube, L., & Pare, G. (2001). Global Virtual Teams. Communications of the ACM, 44 (12), 71-73. Dube, L., & Pare, G. (2003). Rigor in Information Systems Positivist Case Research: Current Practices, Trends, and Recommendations. MIS Quarterly, 27 ( 4 ) , 597-6 35. Dubois, A., & Gadde, L.-E. (2002 ). Systematic Combining: An Abductive Approach to Case Research. Journal of Business Research, 55 , 553- 5 60. Earl, M. J. (1996 ). The Risks of Outsourcing IT. Sloan Management Review, 37( 3 ) , 26-32. Edwards, H. K., & Sridhar, V. (2003). Analysis of the Effectiveness of Global Virtual Teams in Software Engineering Projects. Paper presented at the 38th Hawaii International Conference on System Sciences. Ein Dor, P., Segev, E., & Orgad, M. (199 3). The Effect of National Culture on IS: Implications for International Information Systems. Journal of Global Information Management, 1 ( 1 ) , 33- 4 4. Eisenhardt, K. M. (1989 ). Building Theories from Case Study Research. Academy of Management Review, 14 ( 4 ) , 532- 5 50. Endres, A., & Rombach, D. (2003 ). A Handbook of Software and Systems Engineering - Empirical Observations, Laws and Theories (1st ed.). Essex, England: Pearson Education Limited. Eppinger, S. D., & Chitkara, A. R. (200 6). The New Practice of Global Product Development. MIT Sloan Management Review, 47 ( 4 ) , 22-3 0. Ethiraj, S. K., Kale, M. S., Krishnan, M., & Singh, J. V. (2005 ). Where do Capabilities Come From and How do they Matter? A Study in the Software Services Industry. Strategic Management Journal, 26 ( 1 ), 25-45. Faraj, S., & Sproull, L. (2000 ). Coordinating Expertise in Software Development Teams. Management Science, 46(12 ), 1554 -1 56 8. Farrel, D. (2006). Smarter Offshoring. Harvard Business Review, 84(6 ) , 84-92. Ferris, S. P., & Minielli, M. (2004). Technology an d Virtual Teams. In S. H. Godar & S. P. Ferris (Eds.), Virtual and Collaborative Teams: Process, Technologies and Practice (pp. 193- 2 11 ). Hershley, PA: Idea Group Publishing. Fitzgerald, G., & Willcocks, L. P. (1994). Contracts and Partnerships in the Outsourcing of IT. Paper presented at the 15th International Conference on Information Systems, Vancouver, Canada. 306 Friedman, T. L. (2006 ). The World is Flat. New York: Farar, Straus and Giroux. Gane, C. (2001 ). Process Management: Integrating Project Management and Development. In P. C. Tinnirello (Ed.), New Directions in Project Management (pp. 67-82 ). Boca Raton: Auberach. Giddens, A. (1984 ). The Constitution of Society. Cambridge: UK Polity Press. Giddens, A. (1990 ). The Consequences of Modernity: Stanford University Press. Giddens, A., & Pierson, C. (1998). Conversation with Anthony Giddens: Making Sense of Modernity. California: Stanford University Press. Gifford, A. (2004 ). US $15 billion pie vanishing fast . New Zealand Herald (March 2, 2004). Gold, T. (2005). Outsourcing Software Development Offshore: Making it Work. Washington, D.C.: Auberach Publications. Gopal, A., Krishnan, M. S., Mukhopadhyay, T., & Goldenson, D. R. (2002 ). Measurement Programs in Software Development: Determinants of Success. IEEE Transactions on Software Engineering,, 28( 9 ) , 863 - 875. Gopal, A., Mukhopadhyay, T., & Krishnan, M. (2002 ). Virtual Extension: The Role of Software Processes and Communication in Offshore Software Development. Communications of the ACM, 45 ( 4 ) , 193-20 0. Gopal, A., & Sivaramakrishnana, K. (2008 ). On Ve ndor Preferences for Contract Types in Offshore Software Projects: The Case of Fixed Price vs. Time and Material Contracts. Information Systems Research, 19 (2), 202-220. Gopal, A., Sivaramakrishnana, K., & Krishnan, M. (2003 ). Contracts in Offshore Software Development: An Empirical Analysis. Management Science, 49 (1 2 ), 1671 -1 68 3. Gosain, S., Gopal, A., & Darcy, D. P. (2005). Examining the Effectiveness of Organisational Control Modes in Offshore software Development Projects. Paper presented at the Management of Globally Distributed Work, Bangalore, India. Gourlay, S. (2003 ). The SECI Model of Knowledge Creation: Some Empirical Shortcomings. In Proceedings of the Fourth European Conference on Knowledge Management, 18 -19 September 2003, Oriel College, Oxford, pp. 337-3 86. Gourlay, S. (2006 ) Conceptualising Knowledge Crea tion: A Critique of Nonaka’s Theory. Journal of Management Studies 43:7 Greenwood, D. (2004 ). 'BPO Boom a boon for Kiwis - Gartner'. Retrieved 26/08 /04 , 2004 , from www.pcworld.co.nz/news.nsf Gregson, N. (1989). On the Ir(relevance) of Structuration Theory to Empirical Research . Social Theory of Modern Societies: Anthony Giddens and His Critics, pp. 235-2 48. Groves, L., Nickson, R., Reeves, G., & Utting, M. (1999). A Survey of Software Requirements Specification Practices in New Zealand Software Industry. Working Paper 08/99 Hamilton; University of Waikato. 307 Guba, G., & Lincoln, Y. S. (1990 ). Can There Be a Human Science? Person Centred Review, 5 ( 2 ) , 130- 1 54. Gubrium, J. F., & Holstein, J. A. (200 3 ). Analyzing Interpretive Practice. In N. K. Denzin & Y. S. Lincoln (Eds.), Strategies of Qualitative Inquiry (2nd ed.). Thousand Oaks, CA: Sage. Guhathakurta, S., Jacobson, D., & DelSordi, N. C. (2007 ). The End of Globalisation? The Implications of Migration for State, Society and Economy. In G. Ritzer (Ed.), The Blackwell Companion to Globalisation (pp. 201-21 5 ). Oxford: Blackwell. Hamilton, G. (2004 ). The "Outsource2NewZealand" Initiative. Paper presented at the Software Development Conference 2004, Wellington, New Zealand. Hansen, M.T., Nohria, N.& Tierney, T. (1999). What’s your Strategy for Managing Knowledge?, Harvard Business Review 77(2), 1 0 6 -1 18. Harvey, L., & Myers, M. D. (1995 ). Scholarship and Practice: The Contribution of Ethnographic Research Methods to Bridging the Gap. Information Technology & People, 8 ( 3 ) , 13-2 7. Heales, J., Cockcroft, S., & Radu escu, C. (2004 ). The Influence of National Culture on the Level and Outcome of IS Development Decisions. Journal of Global Information Technology Management, 7 (4), 3 - 28. Heeks, R., Krishna, S., Nicholson, N., & Sahay, S. (200 1). 'Synching' or 'Sinking': Trajectories and Strategies in Global Software Outsourcing Relationships. IEEE Software, 18( 2 ) , 54-62. Heinzi, A. (1993). Outsourcing the Information Systems Function within the Company: An Empirical Survey. Paper presented at the International Conference of Outsourcing of Information Science, University of Twente, The Netherlands. Herbsleb, J. (2007 ). Global Software Engineering: The Future of Socio-technical Coordination. IEEE Computer Society. Herbsleb, J., & Moitra, D. (2001) . Global Software Development. IEEE Transactions on Software Engineering, 18(2), 16 - 20. Herman, J. (2003 ). Blogs for Business. Business Communications Review, 33 ( 4 ) , 20-23. Hertel, T. D. (2004). Effective Virtua l Teams. In D. J. Pauleen (Ed.), Virtual Teams: Projects, Protocols and Processes (pp. 209-23 0 ). Hershey, PA: Idea Group Publishing. Hinds, P. J., & Weisband, S. P. (2003). Knowledge Sharing and Shared Understanding in Virtual Teams. In J. W. Sons (Ed.), Virtual Teams that Work: Creating Conditions for Virtual team Effectiveness (First ed., Vol. 1, pp. 21-36 ) . San Francisco, CA: Jossey-Bass. Hofstede, G. (1990 ). Culture's Consequences: International Differences in Work Related Values. Beverly Hills: Sage. Hofstede, G. (200 6 ). What did GLOBE really meas ure? Researchers’ Mind s versus Respondents’ Minds. Journal of International Business Studies 37(6), 897 – 931. Hofstede, G. & Hofstede G.J. (200 5 ). Cultures and Organisations: Software of the Mind. New York: McGraw Hill 308 Hornett, A. (2004a). The Impact of External Factors on Virtual Teams: Comparative Cases. In D. J. Pauleen (Ed.), Virtual Teams: Projects, Protocols and Processes (pp. 352). Hershley: Idea Group Publishing. Hornett, A. (2004b). Varieties of Virtual Organisations and their Knowledge Sharing Systems. In D. J. Pauleen (Ed.), Virtual Teams: Projects, protocols and Processes (pp. 186-2 08 ). Hershey, PA: Idea Group Publishing. House, R.J., Hanges, P.J., Javidan, M., Dorfman, P.W. & Gupta, V. (2004 ). Culture, Leadership, and Organisations: The GLOBE Study of 62 Societies. Thousand Oaks CA: Sage. Hulnik, G. (2000 ). Doing Business Virtually. Communication World, 17( 3 ) , 33-3 6. Hurley, R. F. (2006 ). Managing Yourself: The Decision to Trust. Harvard Business Review, 28 (36), 55-62. Iacovou, C. L., & Nakatsu, R. (2008 ). A Risk Pr ofile of Offshore-Outsource d Development Projects. Communications of ACM, 51 ( 6 ) , 89-9 4. Jalote, P. (1999). CMM in Practice: Processes for Executing Software Projects at Infosys. Massachusetts: Addiso n Wesley Longman. Janesick, V. J. (2003 ). The Choreography of Qua litative Research Design: Minuets, Improvisations and Crystallisation. In N. K. Denzin & Y. S. Lincoln (Eds.), Strategies of Qualitative Inquiry (Vol. 2, pp. 46-79 ). California: Sage Publications. Janesick, V. J. (2004 ). "Stretching" Exercises for Qualitative Researchers (2nd ed.). Thousand Oaks, CA: Sage. Jarvenpaa, S. L., & Leidner, D. (1999 ). Communication and Trust in Global Virtual Teams. Organization Science, 10 (6 ), 791 -81 5. Jarvenpaa, S. L., Shaw, T. R., & Staples, D. S. (2004). Towards Contextualised Theories of Trust: The Role of Trust in Global Virtual Teams. Information Systems Research, 15 (3), 250-267. Jennex, M. E., & Adelakun, O. (2003 ). Success Factors for Offshore Information System Development. Journal of Information Technology Case and Applications, 5 ( 3 ) , 12-3 1. Johnson, M. (1997 ). Outsourcing in brief, Butterworth-Heinemann, Oxford. Joia, L.A. (2002) Assessing Unqualified In-Service Teacher Training in Brazil using Knowledge Management Theory: A Case Study. Journal of Knowledge Management, Volume 6(1). Pp. 74-86 Jones, M. R., & Karsten, H. (2008 ). Giddens’s Structuration Theory and Information Systems Research. MIS Quarterly, 32( 1 ) , 127- 15 7. Kaiser, K., & Hawk, S. (2004 ). Evolution of Offshore Software Development: From Outsourcing to Cosourcing. MIS Quarterly Executive, 3( 2 ) , 69 - 81. Kalnins, A., & Mayer, J. K. (2004 ). Relationships and Hybrid Contracts: An Analysis of Contract Choice in Information Technology. Journal of Law and Economic Organisations, 20 ( 1 ) , 207- 2 29. 309 Kanawattanachai, P., & Yoo, Y. (2007 ). The Impact of Knowledge Coordination on Virtual Team Performance over Time. MIS Quarterly, 31 ( 4 ) , 783-8 08. Karolak, D. W. (1998 ). Global Software Development: Managing Virtual Teams and Environments. In (pp. 158). Los Alamitos, Cali fornia: IEEE Computer Society. Kaufman, H. (1981 ). The Administrative Behaviour of Federal Bureau Chiefs. Washington D.C.: Brookings Institution. Keane, B. (2003 ). Outsourcing as a Means of Impr oving Process Maturity: An Approach for More Rapidly Moving up the Capability Maturity Model. In P. C. Tinnirello (Ed.), New Directions in Project Management (pp. 331-33 9 ). Boca Raton: Auberach. Kearney, A. T. (2004 ). Measuring Globalization: Economic Reversals, Forward Momentum. Foreign Policy. Kern, T. (1997). The Gestalt of an Information Technology Outsourcing Relationship: An Exploratory Analysis. Paper presented at the 18th Inte rnational Conference on Information Systems, Atlanta, Georgia. King, W. R., & Torkzadeh, G. (2008 ). Information Systems Offshoring: Research Status and Issues. MIS Quarterly, 32 ( 2 ) , 205-2 25. Kirsch, L., Sambamurthy, V., Ko, D., & Purvis , R. (2002). Controlling Information Systems Development Projects: The View from the Client. Management Science, 48 ( 4 ) , 484 - 498. Kishore, R., Rao, H. R., Nam, K., Rajagoplalan, S., & Chaudhury, A. (2003 ). A Relationship Perspective on IT Outsourcing. Communications of the ACM, 46 ( 12 ) , 87-92. Kiviat, B., Rajan, S., Thomas, C. B., & Tu multy, K. (2004 ). The Great Jobs Debate. TIME (March 1, 2004), 18-27. Klien, H. K., & Myers, M. D. (1999 ). A Set of Principles for Conducting and Evaluating Interpretive Field Studies in In formation Systems. MIS Quarterly, 23 (1 ) , 67-94. Kluge, J., Stein, W., & Licht, T. (2001). Knowledge Unplugged: The McKinsey and Company Global Survey on Knowledge Management. NY: Palgrave: Sr. Martin's Press. Knolmayer, G. (2002 ). Cybermediaries Supporting the Management of Independent Vendors: A Case Study of Extended Outsourcing Relationships. In R. Hirscheim, A. Heinzi & J. Dibbern (Eds.), Information Systems Outsourcing: Enduring Themes, Emergent Patterns and Future Directions (pp. 432-44 8 ). Berlin, Heidelberg, New York: Springer-Verlag. Kobitzsch, W., Rombach, D., & Feldman, R. (2001 ). Outsourcing in India. IEEE Software , 54-6 0. Kraut, R. E., & Streeter, L. A. (1995). Coordination in Large Scale Software Development. Communications of the ACM, 38 ( 7 ) , 69-81. Kumar, S. (2004). New Zealand Trade and Enterprise - Strategic Capabilities Assessment. Paper presented at the Software Development Conference 2004, Wellington, New Zealand. Kuver, P. P. (2001). Managing System Requirements. In P. C. Tinnirello (Ed.), New Directions in Project Management (pp. 91-100). Boca Raton: Auberach. 310 Kvalve, S. (1996). Inter Views: An Introduction to Qualitative interviewing. Thousand Oaks, CA: Sage. Lacity, M., & Hirscheim, R. (1994). Information Systems Outsourcing: Myths Metaphors and Realities: John Wiley & Sons. Lacity, M., & Willcocks, L. P. (1998 ). An Empirical Investigation of Information Technology Sourcing Practices: Lessons from Experience. MIS Quarterly Executive. Lacity, M., Willcocks, L. P., & Feeney, D. F. (1996 ). The Value of Selective IT Sourcing. Sloan Management Review, 37 ( 3 ) , 13-25. Le Heron, R., & Harrington, J. W. (2005 ). Describing, Studying and Creating New Economic Spaces. In R. Le Heron & J. W. Harrington (Eds.), New Economic Spaces: New Economic Geographies (pp. 1-5). Hampshire: Ashgate Publishing Limited. Lee, A. S. (1991). Integrating Positivist and Interp retivist Approaches to Organisational Research. Organization Science, 2 ( 4 ) , 342- 3 65. Lee, A. S., & Baskerville, R. L. (2003 ). Generalising Generalisability in Information Systems Research. Information Systems Research, 14 (3), 221-243. Lee, J. N., & Kim, Y. G. (1999). Effect of Partnership Quality on IS Outsourcing Success: Conceptual Framework an d Empirical Validation. Journal of Management Information Systems, 15 (4 ) , 29-61. Leornardi, P. M., & Bailey, D. E. (2008 ). Transformational Technologies and the Creation of New Work Practices: Making Implicit Knowledge Explicit in Task-Base Offshoring. MIS Quartely, 32 (2 ), 411 -43 6. Livari, J., & Huisman, M. (2007 ). The Relationship between Organisational Culture and the Deployment of Systems Development Methodologies. MIS Quarterly, 31( 1 ) , 35-3 8. Lohr, S. (200 4). Technolo gy and Worker Efficiency . The New York Times (February 2, 2004). Longwood, J., Caminos, M., & Chon, M. (2003 ). Survey/Overview: New Zealand IT Services Provider Market (No. M-19-5 4 74 ) : Gartner. Lurey, J., & Raisinghani, M. (2001). An Empiri cal Study of Best Practices in Virtual Teams. Information & Management, 38, 523 -5 44. Macharzina, K., Oesterle, M. J., & Brodel, D. (2000) . Learning in Multinationals. In M. Dierkes, A. Antal, J. Child & I. Nonaka (Eds.), Handbook of Organizational Learning and Knowledge (pp. 631-656 ). London: Oxford University press. Marcolin, B., & McLellan, K. L. (1998). Effective IT Outsourcing Arrangements. Paper presented at the 31st Annual Hawaii Internationa l Conference on System Sciences. Mark, G. (2001). Meeting Current Challenges for Virtually Collocated Teams: Participation, Culture, and Integration. In L. Chidambaram & I. Zigures (Eds.), Our Virtual Worlds: the Transformation of Work, Play and Life via Technology (pp. 74-93 ). Hershley, PA: Idea Group Publishing. 311 Markus, M.L. (2001 ). Toward a Theory of Knowledge Reuse: Types of Knowledge Reuse Situations and Factors in Reuse Success. Journal of Management Information Systems 18(1), 57-9 3. Marshall, C., & Rossman, G. B. (1999). Designing Qualitative Research. Thousand Oaks, California: Sage. Mason, D., & Pauleen, D. J. (2003 ). Perceptions of Knowledge Management: A Qualitative Analysis. Journal of Knowledge Management, 7 (4), 38-48. Maxwell, J. A. (2005 ). Qualitative Research Design. Thousand Oaks, CA: Sage. McKnight, D. H., Cummings, L. L., & Chervany, N. L. (1998 ). Initial Trust Formation in New Organizational Relationships. The Academy of Management Review, 23 (3), 473-490. Michell, R., & Fitzgerald, G. (1997). The IT Outsourcing Market-Pla ce: Vendors and their Selection. Journal of Information Technology Cases and Applications, 12 , 223 -23 7. Miles, M. B., & Huberman, A. M. (1994). Qualitative Data Analysis: An Expanded Sourcebook. Thousand Oaks, CA: Sage. Miles, M. B., & Huberman, A. M. (2000). The Qualitative Researcher's Companion: Sage Publication. Mingers, J. (2003 ). The Paucity of Multimethod Research: A Review of the Information Systems Literature. Information Systems Journal, 13 , 233 -24 9. Mingus, N. B. (2001 ). Managing Project Management. In T. P.C. (Ed.), New Direction in Project Management (pp. 25-32 ). Boca Raton: Auberach. Ministry of Economic Development. (200 8). SMEs in New Zealand: Structure and Dynamics 2008 (No. ISSN 1178-28 11 ). Mishler, E. G. (1986 ). Research Interviewing: Context and Narrative. MA: Cambridge: University Press. Misztal, B. A. (1996 ). Trust in Modern Societies. The Search for the Basis of Social Order. Cambridge: Polity Press. Mockus, A., & Herbsleb, J. (2001 ). Challenges of Global Software Development. IEEE Software, 182- 1 84. Mol, M. J. (2007). Outsourcing: Design, Process, and Performance. Cambridge: Cambridge University Press. Moody, D. L. (2000 ). Building Links between IS Research and Professional Practice: Improving the Relevance and Impact of IS Research. Paper presented at the Twenty First International Conference on Information Systems, Brisbane, Queensland, Australia. Moore, S., & Barnett, L. (2004 ). Offshore Outsourcing and Agile Development: Forrester Research Inc. Moore, S., & Martorelli, W. (2004 ). Indian Offshore Suppliers: The Market Leaders: Forrester Research Inc. 312 Morrow, R., & Brown, D. (1994). Critical Theory and Methodology. London: Sage Publications. Murray, J. P. (2002 ). The Project Management Office: A Strategy for Improvement and Success. In P. C. Tinnirello (Ed.), New Directions in Project Management. Boca Raton: Auberach. Myers, M. D. (1997 ). Critical Ethnography in Information Systems. In A. S. Lee (Ed.), Information Systems and Qualitative Research (pp. 276-3 00 ). London: Chapman and Hall. Myers, M. D., & Tan, F. (200 2 ). Beyond Models of National Culture in Information Systems Research. Journal of Global Information Management, 10( 1 ) , 24-3 2. Nahar, A. N., Kakola, T., & Huda, N. (2002 ). Diffusion of Software Technology Innovation in the Global Context. Paper presented at the 35th Annual Hawaii International Conference on System Sciences (HICSS'0 2). Nonaka, I., & Takeuchi, H. (1995 ). The Knowledge Creating Company: How Japanese Companies Create the Dynamics of Innovation. New York: Oxford University Press. Nonaka, I., Toyama, R., & Konno, N. (2001 ). SECI, Ba and Leadership: A Unified Model of Dynamic Knowledge Creation. In I. Nonaka & D. J. Teece (Eds.), Managing Industrial Knowledge: Creation, Transfer and Utilisation (pp. 13-39 ). London: Sage. Nonaka, I., Toyama, R., & Konno, N. (2000 ). SECI, ba and Leadership: A Unified Model of Dynamic Knowledge Creation. Long Range Planning. 33(1) , 5-34 Nurmi, A., Hallikainen, P., & Rossi, M. (2005). Coordination of Outsourced Information System Development in Multiple Customer Environment - A Case Study of a Joint Information System Development Project. Paper presented at the 38th Ha waii International Conference on System Sciences. O'Hara, J. (2005). Commercialising Innovation (1st ed.). Auckland: John O'Hara Limited. O'Leary, M. B., & Cummings, J. (2007 ). The Spatial, Temporal and Configurational Characteristics of Geopgraphical Dispersion in Teams. MIS Quarterly, 31 ( 3 ) , 433-4 52. O'Neil, J. (2004). Gartner Conference. Retrieved 2-September-2004, from http://outsource2newzealand.com Olivera, F., Goodman, P.S., & Tan, S.S. (2008 ). Contribution Behaviours in Distributed Environments. MIS Quarterly, 32(1), 23-42. Orilikowski, W. J. (2002 ). Knowing in Practice: Enacting a Collective Capacity in Distributed Organising. Organisation Science, 13(3 ) , 249- 27 3. Orlikowski, W. J., & Baroudi, J. J. (1991 ). Studying Information Technology in Organizations: Research Approaches and Assumptions. Information Systems Research, 2 ( 1 ) , 1-28. Ouchi, W. G. (1978 ). The Transmission of Control through Organisational Hierarchy. Academy of Management Journal, 21 (2 ), 173 -19 2. Oza, N., Hall, T., Rainer , A., & Grey, S. (2004). Critical Factors in Software Outsourcing: A Pilot Study. Paper presented at the 2004 ACM workshop on Interdisciplinary software engineering research, Ne wport Beach, CA, USA. 313 Patton, M. Q. (2002 ). Qualitative Research and Evaluation Methods (3 ed.). Thousand Oaks, California: Sage Publications. Pauleen, D. J., (2004). An Induc tively Derived Model of Leader-In itiated Rela tionship Buil ding with Virtual Team Members, Journal of Management Information System, 20(2), 227- 256 Pauleen, D. J., & Yoong, P. (2001 ). Relationship Building and the Use of ICT in Boundary-Crossing Virtual Teams: a Facilitator's Perspective. Journal of Information Technology Cases and Applications, 16 , 205 -22 0. Pettigrew, A. (1997). What is Processual Analysis? Scandinavian Journal of Information Systems, 13 (4), 337-348. Poole, M. S., & DeSanctis, G. (2004 ). Structuration Theory in Information Systems Research: Methods and Controversies. In M. E. Whitman & A. B. Woszczynski (Eds.), Handbook of Information Systems Research (pp. 206-24 9 ). Hershey, PA: Idea Group. Powell, A., Piccoli, G., & Ives, B. (2004). Virtua l Teams: A Review of Current Literature and Directions for Future Research. SIGMIS Database, 35 ( 1 ), 6-36. Powell, T. (2004). The Knoweldge Matrix: A Proposed Taxonomy for Enterprise Knowledge. In M. E. Koenig & T. K. Srikantaiah (Eds.), Knowledge Management Lessons Learned: What Works and What Doesn't (pp. 225-238 ). New Jersey: American Society for Information Science and Technology. Pratt, B., & Loizos, P. (1992). Choosing Research Methods: Data Collection for Development Workers. Oxford: Oxfam. Pullar-Streker, T. (2004). Window of Opportunity Short. Retrieved 5 April, 2005, from http://www.itanz.org.nz/docs/OutSource2/W indow%20of%20opportunity%20short.doc Rai, S. (2005). Gridlock on India's New Paths to Prosperity . The New York Times (February, 12, 2005). Rajamani, S. K. (2007). Software is More than Code. CSI Communications, 31 , 8-9. Rajeswari, K. S., & Anantharaman, R. N. (2003). Development of an Instrument to Measure Stress among Software Professionals: Factor Analytic Study. ACM Software Engineering Notes, 34-43. RajKumar, T. M., & Dawley, D. L. (1998 ). Problems and Issues in Offshore Development of Software. In Strategic Sourcing of IS - Perspectives and Practices (pp. 369-3 86 ) : John Wiley and Sons. RajKumar, T. M., & Mani, R. V. S. (2001). Offs hore Software Development: The View from Indian Suppliers. Information Systems Management, 18 ( 1 2 ) , 62-72. Ramasubbu, N., Mithas, S., Krishnan, M. S., & Kemerer, C. F. (2008 ). Work Dispersion, Process- Based Learning, and Offshore Soft ware Development Performance. MIS Quarterly, 32 ( 2 ) , 437- 4 58. Ramesh, B. (2002 ). Process Knowledge Management with Traceability. IEEE Software , 50-55. 314 Rao, M. (200 8). Knowledge Management: Best Practices in the InfoTech Sector. In Srikantaiah, T.K. & Koeinig, E.D. (Eds.) (257- 27 2 ) , Knowledge Management in Practice: Connections and Context. American Society for Inform ation Science and Technology, New Jersey. Ravichandran, T., & Rai, A. (2000 ). Quality Management in Systems Development: An Organisational System Perspective. MIS Quarterly, 24 (3 ), 381 -41 5. Reponen, T. (1993 ). Outsourcing or Insourcing? Paper presented at the 14th International Conference on Information Systems, Orlando, Florida. Rice, J.H. & Rice, B.S. (2005 ). The Applicability of the Seci model to Multi-Organisational Endeavours: An integrative review. International Journal of Organisational Behaviour 9(8): 6 7 1 -6 82 Richards, L. (2005 ). Handling Qualitative Data. London: Sage. Ritzer, G., & Lair, C. (2007). Outsourcing: Gl obalization and Beyond. In G. Ritzer (Ed.), The Blackwell Companion to Globalization (pp. 307-3 29 ). Oxford: Blackwell Publishing. Robey, D., Khoo, H., & Powers, C. (2000). Situated Learning in Cross-functional Virtual Teams. IEEE Transactions on Professional Communications, 43( 1 ) , 51-6 6. Rosemann, M., & Vessey, I. (2008 ). Toward Improving the Relevance of Information Systems Research to Practice: The Role of Applicability Checks. MIS Quarterly, 32 (1), 1-22. Rottman, J., & Lacity, M. (2004). Tw enty Practices for Offshore Sourcing. MIS Quarterly Executive, 3 (3), 117 - 130. Rottman, J., & Lacity, M. (2006). Proven Pr actices for Effectively Offshoring IT Work. MIT Sloan Management Review, 47 ( 3 ) , 56-63. Sabherwal, R. (2003 ). The Evolution of Coordination in Outsourced Software Development Projects: A Comparison in Client and Vendor Perspectives. Information and Organization, 13 (3), 153-202. Sahay, S., Nicholson, B., & Krishna, S. (2003 ). Global IT Outsourcing - Software Development across Borders (First ed.). United Kingdom: Cambridge University Press. Sakthivel, S. (2005 ). Virtual Workgroups in Offshore Systems Development. Information and Software Technology, 47, 305 -3 18. Saunders, C. S. (2000 ). Virtual teams: Piecing Together the Puzzle. In R. W. Zmud (Ed.), Framing the Domain of IT Management: Projecting the Future Through the Past. Cincinnati, OH: Pinnaflex. Schien, E.H. (1984 ). Coming to a New Awareness of Organisational Culture, Sloan Management Review, 25(2), 3-16. Schofield, J. W. (2002 ). Increasing Generalisability of Qualitative Research. In A. M. Huberman & M. B. Miles (Eds.), The Qualitative Researcher's Companion (pp. 171-20 3 ). Thousand Oaks: Sage. 315 Scholz, R. W., & Tietje, O. (2002 ). Embedded Case Study Methods: Integrating Quantitative and Qualitative Knowledge. Thousand Oaks, California: Sage Publications. Schwandt, T. A. (2001 ). Dictionary of Qualitative Inquiry (2nd rev. ed ed.). Thousand Oaks, CA: Sage. Sharma, R., & Krishna, S. (2005). Structuring Coordination and Communication in Global Software Work: An Empirical Study. Paper presented at the First International Conference on Management of Globally Distributed Work, Bangalore, India. Shore, B., & Venkatachalam, A. R. (1995). The Ro le of National Culture in System Analysis and Design. Journal of Global Information Management, 3 (3 ) , 5-14. Slaughter, S. A., & Kirsch, L. (2006). The Effectiveness of Knowledge Transfer Portfolios in Software Process Improvement. Information Systems Research, 17 ( 3 ) , 301- 3 20. Smith, M. A., Mitra, S., & Narasimhan, S. (199 6 ). Offshore Outsourcing of Software Development and Maintenance: A Framework and Issues. Information and Management, 31, 165 -1 75. Sproull, L., & Kieser, S. (1986 ). Reducing Social Context Cues: Electronic Mail in Organisational Communication. Management Science, 32 ( 1 1 ) , 1492 -15 12. Srikantiah, T. K. (2004 ). Historical and Cont emporary Perspectives on Knowledge Management - and a Look at the Knowledge Sharing Initiative at the World Bank. In M. E. Koenig, Srikantaiah, T.K. (Ed.), Knowledge Management Lessons Learned: What Works and What Doesn't (pp. 361-37 8 ). Medford, New Jersey: American Society for Information Science and Technology. Stake, R. E. (1995). The Art of Case Study Research: Thousand Oaks: Sage Publications. Stake, R. E. (2003). Case Studies. In N. K. Denzin & Y. S. Lincoln (Eds.), Strategies of Qualitative Inquiry (2nd ed., pp. 460). Thousand Oaks, CA: Sage. Staples, D. S., Wong, I. K., & Came ron, A. F. (2004 ). Best Practices fir Virtual Team Effectiveness. In D. J. Pauleen (Ed.), Virtual Teams: Projects, Protocols and Processes (pp. 160-185 ). Hershey, PA: Idea Group Publishing. Sumita, T.Shimazaki, M., Matsuyama, K.(2009 ). A Proposal for Inventory Adjustment using “Multiple Layers SEC-CIS model”. International Journal for Production Economics, 208-21 6 Sutanato, J., Kankanhalli, A., & Tan, B. C. Y. (2005). Assessing Suboptimal Outcomes in Global Virtual Team Task Co-ordination. Paper presented at the 1st international Conference on Management of Globally Distributed Work, Bangalore. Svensson, G. (2001 ). "Glocalisation" of Business Activities: A Glocal Strategy Approach. Management Decision, 39 (1 ) , 6-18. Takeuchi, H., & Nonaka, I. (2002 ). Classic Work: Theory of Organizational Knowledge Creation. In D. Morey, M. Maybury & B. Thuraisingham (Eds.), Knowledge Management Classic and Contemporary Works (pp. 139-18 2 ). London: MIT Press, Cambridge, Massachusetts. 316 Taylor, H. (2000, ). Information Systems Development Practice in New Zealand. Paper presented at the 13th Annual Conference of the National Advisory Committee on Computing Qualifications, Wellington, New Zealand. Teece, D.J. (2000) Strategies for Managing Know ledge Assets: The Role of Firm Structure and Industrial Context. Long Range Planning 33(1) , 35-5 4. Tiwana, A. (2003, ). Knowledge Partitioning in Outsourced Software Development: A Field Study. Paper presented at the International Conference on Information Systems, Seattle, Washington. Trauth, E. M. (2001 ). The Choice of Qualitative Me thods in IS Research. In E. M. Trauth (Ed.), Qualitative Research in IS: Issues and Trends (pp. 298). Hershley PA: Idea Group Publishing. Tsoukas, H. (1989 ). The Validity of Ideographic Research Explanations. Academic Management Review, 14, 551- 56 1. Urban, J. L. P., & Whiddett, R. J. (1996). The Relationship between Systems Development Methodologies and Organisational: A Survey of New Zealand Organizations. Paper presented at the Information Syst ems Conference of New Zealand. Urquhart, C. (1999 ). Themes in Early Requirements Gathering. Information Technology and People, 12 ( 1 ) , 44-7 0. Urquhart, C. (2001 ). An Encounter with Grounded Theory: Tackling the Practical and Philosophical Issues. In E. M. Trauth (Ed.), Qualitative Research in IS: Issues and Trends (pp. 104-1 4 0 ) : Idea Group Publishing. Vlaar, P. W. L., Fenema, P. C., & Tiwari, V. (2008 ). Cocreating Understanding and Value in Distributed Work: How Members of Onsite and Offshore Vendor Teams Give, Make, Demand and Break Sense. MIS Quarterly, 32 ( 2 ) , 227-2 55. Venkatraman, N. & Tanriverdi, H. (2004 ) Reflecting “Knowledge” in Strategy Research: Conceptual Issues and Methodological Challenges. In Ketchen, D.J. & Bergh, D.D. (Eds.) Research Methodology in Strategy and Management (33-6 6 ) , Vol 1, Elsevier Ltd, Boston, MA Walsham, G. (1995 ). Interpretive Case Studies in IS Research: Nature and Method. European Journal of Information Systems, 4 , 74-8 1. Walsham, G. (2002). Cross-Cultural Software Production and Use: A Structurational Analysis. MIS Quarterly, 26 (4 ), 359 -38 0. West, L. A., & Bogumil, W. A. (2001). Im migration and the Global IT Work Force. Communications of ACM, 44 ( 7 ). White, S., & Lui, S. (2005 ). Distinguishing Costs of Cooperation and Control in Alliances. Strategic Management Journal, 26 , 913- 93 2. Willcocks, L. P., & Kern, T. (1998). IT Outsourcing as Strategic Partnering: The Case of UK Inland Revenue. European Journal of Information Systems, 7 ( 1) , 143- 1 60. 317 Wooldridge, M. (2002 ). An Introduction to Multi-Agent Systems. Baffins Lane: John Wiley and Sons. Woukeu, A., Carr, L. & Hall, W. (2004 ). WiCKEd: A Tool for Writing in the Context of Knoweldge”. In Proceedings of the 15 th ACM Conference on Hypertext and Hypermedia, Santa Cruz, CA. Yin, R. K. (1994 ). Case Study Research: Design and Methods. London: Sage Publication. Yin, R. K. (2003 ). Case Study Research: Design and Methods (3rd ed. Vol. 5). Thousand Oaks, CA: Sage. 318 APPENDIX A A Study on Development Practices for Offshore Software Applications Development INFORMATION SHEET This project has been reviewed, judged to be low risk, and approved by the researcher and supervisors under delegated authority from the Massey University Human Ethics Committee. If you have any concerns about the conduct of this research, please contact Professor Sylvia Rumball, Assistant to the Vice-Chancellor (Ethics & Equity), telephone 0064 – 6 – 350 5249 or email at humanethicspn@massey.ac.nz Researcher : Anuradha Mathrani Lecturer (Information Systems) Institute of Information and Mathematical Sciences, Massey University, Albany, Auckland Supervisor: Dr. David Parsons, Senior Lecturer, IIMS, Massey University Participant’s Rights: You are under no obligation to accept this invitation. If you decide to participate, you have the right to: 1. Decline to answer any particular question; 2. Withdraw from the study; 3. Ask any questions about the study at any time during participation; 4. Provide information on the understanding that your name will not be used unless you give permission to the researcher; 5. Be given access to a summary of the project findings when it is concluded; 6. Ask for the audio tape to be turned off at any time during the interview. 319 APPENDIX B A Study on Development Practices for Offshore Software Applications Development PARTICIPANT CONSENT FORM This project has been reviewed, judged to be low risk, and approved by the researcher and supervisors under delegated authority from the Massey University Human Ethics Committee. If you have any concerns about the conduct of this research, please contact Professor Sylvia Rumball, Assistant to the Vice-Chancellor (Ethics & Equity), telephone 0064 -6 350 5249 or email at humanethicspn@massey.ac.nz I have read the Information Sheet and have had the details of the study explained to me. My questions have been answered to my satisfaction, and I understand that I may ask further questions at any time. I agree/ do not agree to the interview being audio taped. I agree to participate in this study under the conditions set out in the Information Sheet. Signature: _______________________________ Date: ____________________ Full Name – printed __________________________________________________ 320 PUBLICATIONS The publications that have generated from this project so far are: Mathrani A, Parsons, D. (2007). Management of Knowledge Transfer in Distributed Software Organizations: The Outsourcers’ Perspective. In Kulkarni U., Power, D. Sharda R. (Eds.) Decision Support for Global Enterprises, Annals of Information Systems, Vol. 2, Springer Publication, pp. 75-89, ISBN: 13: 978-0-387-48136-4. Mathrani, A., Goel, G. and Parsons. D. (2007) Building Trust Across Virtual Social Spaces: the Software Vendors' Perspectives. 18th Australasian Conference on Information Systems , Toowoomba, Australia, December 5-7 2007. Mathrani, A, Viehland, D. Parsons, D. (2007). Dynamics of Offshore Software Development Success: The Outsourcers’ Perspective. In Verma V. (Eds.) Managing Offshore Software Projects, Icfai Univer sity Press, pp. 58-80, ISBN 81-314-1178-2. Mathrani, A, Parsons, D., Viehland, D. (2006). Offshore Software Development Strategies of an Indian Vendor: A Study. Icfaian Journal of Management Research, May 2006, vol. V, no. 5, pp. 71-81. Mathrani, A, Viehland, D. Parsons, D. (2005). Dynamics of Offshore Software Development Success: The Outsourcers’ Perspective. In Pauleen, D. and Husted, K. (Eds.), Proceedings of the International Conference in Knowledge Management in Asia Pacific, November 28 -29, Victoria University, Wellington, New Zealand. ISBN: 0-475-122774. Mathrani, A, Parsons, D., Viehland, D. (2005). Virtual Team Issues: Culture, Communication, Coordination and Control - The New Zealand and Indian Perspective. In Kumar, K. and Krishna, S. (Eds.), Proceedings of the International Conference on Management of Globally Distributed Wo rk, pp. 291-301, December 28 – 30, Indian Institute of Management Bangalore, India. ISBN: 81-7525-684-2. Mathrani, A. (2005). Key Success Drivers in O ffshore Software Development Processes: A Perspective from New Zealand and Indian Suppliers. In Anne de Bruin and Nitha Palakshappa (Eds.), Proceedings of the Qu alitative Research in Business Symposium, October 28, Massey University, Auckland, New Zealand. ISBN: 0-473-10396-6. Mathrani, A., Parsons, D. (2005). Dynamics of Offshore Software Development Success: An Indian Vendor Perspective. Proceedings of the Fifth Global Conference on Flexible Systems Management, pp 817-825, Decembe r 27-30, Rajiv Gandhi Proudyogiki Vishwavidyalay, University of Technology of Madhya Pradesh, Bhopal, India, ISBN: 81- 903397-0- 2. (also available at http://www.indianjournals.com/ijor.aspx?target=ijor:glogift2k5&volume=1&issue=1&articl e=chap103&type=pdf) 321 Mathrani, A. (2005) Poster titled “Virtual Team Issues: Culture, Communication, Coordination and Control: The New Zealand and Indian Perspective”. Proceedings of the IIMS Postgraduate Conference, pp. 12, October 27, Massey University, Auckland. Mathrani, A. (2004). A Study on Developm ent Strategies for Offshore Software Applications in New Zealand and India- Paper presented at the Doctoral Consortium for the 15 th Australasian Conference on Information Systems in Hobart, Australia, 29 th - 30 th November 2004. Mathrani, A. (2004). A Study on Developm ent Strategies for Offshore Software Applications in New Zealand and India. Pro ceedings of the IIMS Postgraduate Conference, pp. 44-53, October 4, Massey University, Auckland. (Best paper award).