A Case Study: Coordination Practices in Global Software Development

A Case Study: Coordination Practices in Global Software Development Darja Šmite Riga Information Technology Institute, Kuldigas iela 45b, LV-1083, Riga, Latvia Darja.Smite@riti.lv Abstract. Global Software Development (GSD) is a new challenge for software developers to reach mobility in resources, obtain extra knowledge, speed timeto-market and increase operational efficiency. However, the new trend is followed by specific risks and needs a deeper analysis for successful risk overcoming. This paper gives an insight into a research on GSD project performance improvement in one of the biggest software development companies in Latvia. Project management and coordination in distributed environment is a great challenge, though being not very widely explored. In this paper the author emphasizes the necessity of research in this area and provides an overview of coordination practices used in the organization chosen for the case study. 1. Introduction The question explored in this paper is related to global software development (GSD) project coordination. To start with the term GSD has to be explained. GSD is also known as a type of outsourcing relations. Campbell R. Harvey's Hypertextual Finance Glossary defines outsourcing as purchasing a significant percentage of intermediate components from outside suppliers [6]. There are various forms of outsourcing, e.g. business process outsourcing (BPO), application outsourcing or application service provider (ASP) outsourcing, hardware outsourcing, data centre outsourcing, selective or full software development outsourcing. The area of author s research is devoted to selective and full software development outsourcing also known as global software development. In particular, the author examines relations between geographically distributed End Customer, a Mediating Partner and the Developer aiming to produce software (See Fig. 1). End Customer Purchasing software Mediating Partner Geographical Distribution Purchasing selective or full software development Developer Fig. 1. The Model of Global Software Development Explored by the Author

2 Darja Šmite A review of related literature on the field of global software development shows that the topic of performance is poorly explored, especially from the supplier s point of view. Most of the related research is devoted to questions as decision making whether to outsource or not ([9], [18], [21]), relationship risk management ([1], [3], [4], [8], [17]), contractual problems and advices ([2], [5], [9]), success factors, that will help to survive starting outsourcing relationship ([10], [12], [13], [15], [17]), and case studies from the field ([7], [13], [14], [16]). Working on the research, the author explores an organization chosen as a case study. This organization competes in the global market as a software development supplier, in other words developer. The lack of research that would answer the question How to perform software development in distributed environment? makes practitioners act intuitively and precludes the prognosticated success of global projects. Therefore, the main objectives for the research are as follows: To build a framework for global projects, which would contain guidelines, practices and tools for effective performance in distributed environment. The paper is organized as follows. The following section describes the research structure and methodology, and gives an insight to the case study. Then GSD coordination practices are presented. The practices are followed by a discussion section. And the paper is concluded by a brief summary and an overview of further work. 2. Research overview 2.1. Research structure The analysis of GSD coordination practices described in this paper is a part of a larger research, which aims to develop a framework for GSD projects, containing guidelines for global project management, software engineering methods adapted for global specifics, best practice knowledge base and project management tools for better performance in distributed environment [19]. The current results of the research, in particular GSD project coordination practices, are the output from the previous steps of the research global project questionnaire and experienced project manager interviewing. These practices are further used as an input for GSD knowledge base and examination in ongoing projects. 2.2. Research methodology The overall research approach for the research is active methodology learning by doing, which aims to deepen the understanding of GSD projects and learn how to improve them [11]. According to this methodology the author performs cycles: Observe à Plan à Implement à Evaluate à Improve à Observe à. In this case, the author is Observing global projects à Indicating risks à Planning preventive

A Case Study: Coordination Practices in Global Software Development 3 actions and developing guidelines à Implementing the guidelines in the ongoing projects à Evaluating the results, identifying areas for further improvement [20]. The author examines GSD projects by means of a case study. The GSD risks and practices have been explored carrying out global project questionnaire and the interviews with experienced project managers from the organization used for the case study. The questionnaire served as a preliminary step of the research aiming to deepen the understanding of GSD project performance and risks; and gathered information on 19 global projects [17]. The interviews with experienced project managers used the output of the questionnaire and addressed issues on GSD practices for performance improvement. The author conducted 13 interviews with 9 project managers. The interviews were held by means of semi-structured interviewing and open questions. The interviewing uncovered a set of defined practices, which can be divided into two main groups communication practices and coordination practices. Unfortunately, due to shortness of this paper the author addresses only coordination practices here. The practices related to communication issues are described in a related paper [20]. 2.2. Case description The author performs her research in a company used for the case study, given a pseudonym XYZ. XYZ is one of the biggest software development company in Latvia. It is an ISO certified company with approximately 350 employees in total. The company is participating in global software development projects with partners from Western and Eastern Europe, and Scandinavia since early 90s [20]. Recently, XYZ became a part of a large international software development enterprise. Accordingly, the necessity to improve GSD project performance has increased. Even though XYZ follows a certified quality system, it doesn t provide particular regulations and practices taking into account global specifics. Following the results of audit observations and project measurements, the author concludes that the global risks make difference in project performance and have to be addressed notably. 2.3. GSD Project Knowledge Base The interviews with experienced GSD project managers from XYZ resulted in a set of practices for further examination in ongoing projects. For efficient GSD practice implementation the author developed a Knowledge Base. XYZ project managers repeatedly pointed out a lack of knowledge share between project managers in the same organization. Therefore, implementing the GSD Knowledge Base, the author prescribes it will serve as a framework for accumulating XYZ best practices, tools and templates for better performance. The Knowledge Base provides the users several functions as follows: Experience generalization; New issue proposal;

4 Darja Šmite Quality document templates addressing global specifics; Discussions; Notifications; Wide searching opportunities. All the practices in the Knowledge Base are recorded using risk based analysis, describing threats, vulnerabilities, resulting risks, frequency and impact [20]. So far, the practices address such issues as communication between the remote participants, the role of trust, project starting guidelines, advisable organizational structures, GSD risk management issues and checklists, process distribution and personnel allocation practices. Currently, the Knowledge Base is accessible by experienced GSD project managers who participated at the preliminary survey and interviewing. The further steps of the research prescribe gathering feedback from project managers; enlarge the content of the Knowledge Base and assess the current practices considering the following factors: Threat frequency of occurrence; Possible impact on project results; Additional preventive actions for risk mitigation. Considering the risk that knowledge bases are rarely used by the practitioners, author plans to integrate it into the Risk Management process. The further steps of the research will aim to use GSD Knowledge Base practices and related information in the process of risk management in global projects as shown in Fig. 2. Risk Management Risk Identification Risk Evaluation Risk Mitigation New Risks Checklists Ratings Risk Mitigation Practices New Practices GSD Knowledge Base Fig. 2. GSD Knowledge Base information usage in the process of Risk Management Using Knowledge Base practices during the Risk Management process will provide practice sharing and continues information accumulation at first hand.

A Case Study: Coordination Practices in Global Software Development 5 3. Coordination Practices Addressing Global Project Specifics In this chapter you will find an overview of the key practices and risks which deal with coordination of global projects. Practice #1: Organizational Changes. Engagement in cooperation between the remote partners brings changes in both organizations. The processes which were held in-house before need different level of management by the partner s organization. Nevertheless, four of nine project managers independently reported that customer organizations are never willing to change. This causes risks related to both communication and coordination issues. First of all, complex organizational structures and many problem escalation levels cause time delays in problem solution (Project Organizational Structures are discussed in the author s related paper [20]). Secondly, remote supplier involvement in software development needs a new approach in software engineering. This means that distance brings differences in relations between the partners developing software. Questions which have been discussed next door now require powerful infrastructure for intercommunication. Besides, risk factors as language skills, cultural differences, terminology differences, etc. need to be taken into account. All these risks influence various processes as the degree of detailed elaboration for requirement specification, complicated planning and work amount evaluation, the level of management and control over project progress, etc. Lastly, the partners have to build shared goals for successful cooperation. The partners need an approach for sharing responsibility for project results and activities. According to Jae-Nam Lee, partnership between the clients and the service providers is considered as a key predictor of outsourcing success [14]. This will make the parties work more effectively on improving mutual relationship. Practice #2: Joint Repository. Outsourcing some of software development functions to a remote developer is always a matter of trust. Therefore, process transparency is given an important role in global projects. Gaining control over developer s activities can be achieved by developing a joint repository. The following functions provided by a joint repository can be used for global project management improvement: Access from the developer s and the partner s sides; Project documentation repository (project scope, calendar plans, risk overview, meeting minutes and carried decisions, etc.); Document approval; Reports on project progress; Work tasks and time recording; Problem tracking. Joint repository provides effective configuration management, reducing misunderstandings related to different document version usage by the parties. It also provides a tool for better progress control for the remote partner. Reporting on work task completion provides timely risk identification.

6 Darja Šmite Practice #3: Work Breakdown. A very important issue addressing software development in global projects is work breakdown. The smaller steps you make, the better you can control them. It is also important to gain an agreement between the developer and the partner on each requirement and each divided task. The work breakdown will further provide an opportunity to manage progress and risks related to task completion on time. Practice #4: Process Breakdown. Process breakdown between the remote participants defines responsibility share and the way of further collaboration. The common process breakdown reported by XYZ project managers is shown on Fig. 3. Partner Activities Communication with the End Customer Project Management and Developer Coordination Requirement Analysis Testing Implementation Developer Activities Design Coding Unit Testing Internal Project Management Maintenance Fig. 3. Usual project process breakdown by XYZ and its partners. The interviews with project managers have shown that there are several approaches used by different partners in process breakdown. There are variations in planning activities allocation. Some partners strictly establish the deadlines and person-day evaluation. In other projects the developer is responsible for work amount evaluations and planning activities. In some cases projects are held under partner s management. In other cases the developer is responsible for overall project management. Considering the gathered practices and experienced risks, the author proposes the following model of cooperation (See Fig.4).

A Case Study: Coordination Practices in Global Software Development 7 Shared Activities Project Planning and Coordination Partner Activities On-site team Communication with the End Customer Off-site team Requirement Analysis Testing Implementation Developer Activities Regular Project Planning Meetings Developer Activities Requirement Analysis On-site Developer Activities Off-site Design Coding Unit Testing Maintenance Internal Project Management Fig. 4. Proposed project process breakdown. The proposed process breakdown for global projects emphasizes the necessity of shared planning and coordination activities and regular on-site project meetings. Personal contact during the meetings and joint work on project coordination provides effective resource utilization and minimizes risks related to complications in project management brought by distance between the partner and the developer. It will also provide the distributed teams with the feeling of togetherness and deepen trust between the participants. An XYZ project manager reported, Since we established joined meetings once in 2-3 months, we got rid of many misunderstandings related to task prioritization and goal achievement. Besides, we gained a deeper trust from the partner. Another recommendation from the proposed project breakdown addresses Requirement Analysis process share (described in Practice #5 below). Practice #5: System Requirement Analysis. Project managers point out that remote partners from different countries have different traditions for requirement analysis. Latvian software industry is used to detailed system requirement specifications which are clear and complete. Nevertheless XYZ partners from different countries offer low degree of detailed elaboration. Unfortunately, the distance brings difficulties in solving the problems and misunderstandings. Therefore, project managers advise to perform joint on-site requirement analysis involving both the customer and developer parties. XYZ project managers report that

8 Darja Šmite there it is useful to send at least one or two systems analysts to the remote partner s side in order to participate in requirement analysis. Usually, the developer analysts are given a second role in this process without a chance to meet and communicate with the end customer. Nevertheless, it provides a opportunity to prepare the specification according to developer s needs. After the analysts come back one of them usually leads the development project. The development team receives the knowledge about the project scope and tasks from first hand, reducing the risk of misunderstandings. Practice #6: Terminology. Project managers from XYZ reported on frequent misunderstandings interpreting the requirements in the beginning of the project. These problems are sometimes caused by local language peculiarities, sometimes by lack of language skills in particular business field by the developer organization. As a result this causes delays in time for task confirmation. Therefore, it is useful to create a special terminology dictionary aiming to agree upon the used terms for the entire project. This dictionary can be used by different developer representatives (analysis, developers, testers, documentation writers, etc.) in different project activities (designing, coding, testing, documenting, etc.). This also precludes the risk of loosing knowledge in case of loosing the analysts involved in the project. Practice #7: Product Quality. Low personnel costs are not the only uppermost factor for developing countries to compete in software development market. Low productivity or product quality is often the reasons for searching another software development service provider. Answering this risk, the process of software testing has to be adequately addressed by the developer. Although, system testing is usually performed by the partner, the developer is responsible for proper debugging, unit testing and integration tests before any delivery. Practice #8: Process Quality. Process quality is as important as product quality. In many causes, project and process management is as mature as it is required by the partner s side. Although XYZ quality guidelines prescribe following quality procedures, process quality is often viewed as an issue for cutting costs. But how does it influence cooperation between the partner and the remote developer? If the partner s quality processes are not defined and managed according to quality procedures, then by providing a minimum the developer can receive partner s appreciation and satisfaction what is asked is done. But if the partner has a quality system, they wish to count on an appropriate service level. In this case, the developer can adopt the partner s procedures or use its own. However, despite partner s maturity level, providing high quality configuration management, systems analysis, design and testing documentation, problem tracking, requirement traceability, planning and reporting on project results increases trust in the developer activities and competence. One project manager reported, Our partner doesn t follow defined quality processes. Therefore, many activities as e.g. requirement specification and problem tracking are complicated. We came with our initiative to participate in systems analysis by drawing process diagrams and established a problem tracking database.

A Case Study: Coordination Practices in Global Software Development 9 This resulted partner s respect and trust in our competence and desire to cooperate as a unified team. 4. Discussion The major question which seeks for the answer is If the GSD projects can be coordinated as in-house software development projects? To start with, the author offers to look though different risks which are brought by the global appearance. Such issues as distance, cultural and organizational differences between the partners involved in software development mark out the factors that make the global and in-house projects different (see Table 1) and additional risks, that are not relevant for in-house projects (see Table 2). Table 1. The differences between global and in-house projects brought by global appearance Global Projects Lack of personal contact Communication via electronic means or phone N remote teams need N local managers Possible time zone differences In-house Projects Next door closeness Personal communication, as well as electronic and phone communication One team = one manager No time zone differences The list of differences could be extended with such factors as lack of common goals, lack of trust, different contractual relations, project documentation kept in different places at each participant s side, misunderstandings on cultural ground, different approaches in software development methodology, low language skills and other factors. Nevertheless, all these risks can be possibly minimized. There are practices for better global project sourcing, infrastructure improvement, language skills problem overcoming, agreement on software development methodology and sharing goals for mutual cooperation, etc. In its turn the factors given in the Table 1 are brought by distance and can t be avoided. These factors influence coordination and communication throughout the project and make global projects distinctive from the in-house projects. So, how practitioners will address these factors? The author emphasizes the necessity of guidelines addressing the following areas: New practices for work amount evaluation, taking into account differences brought by the distance and several team management; High level infrastructure establishment for better communication between the participants; New coordination practices taking into account lack of personal contact, several team involvement, time zone differences and other risks, which are brought by global appearance.

10 Darja Šmite 6. Conclusions and further research Summarizing the discussion the following conclusions can me made. The factors brought by global appearance make GSD projects different from inhouse software development projects. Addressing these factors the new approaches for project coordination should be established. Global projects vary depending on the situation. XYZ is participating in many projects with different customers/partners from various countries. In some cases the practices used for project coordination can be shared between the projects. But there are also practices which are applicable only for particular situations (e.g. there are projects with and without time zone differences). Therefore, there is a necessity in classifying the global projects and characterizing the situations for practice usage. Analyzing the information gathered from the interviews the author concludes that experience is not being shared in the organization. Practices put in the Knowledge Base forms the ground for knowledge share between the projects. This will also help to accumulate more practices according to the appropriate situations for their usage. As the current quality regulations are not extended for managing global specifics, the guidelines for better performance in GSD projects have to be developed and implemented. The practices presented in this paper are only a part of possible solutions to the problems faced in global project coordination. The author plans to continue her research by interviewing more project managers, accumulating the practices in GSD Knowledge Base, participating as a consultant in new global projects in order to test the practices and receive a feedback for further improvement. Acknowledgement The author appreciates many valuable discussions with professor Juris Borzovs and professor Uldis Sukovskis, as well as the research input received from the experienced project managers. This research is partly supported by the Latvian Council of Science project Nr. 02.2002 Latvian Informatics Production Unit Support Program in the Area of Engineering, Computer Networks and Signal Processing and European Social Foundation. References 1. Aubert, B.A.; Dussault, S.; Patry, H.; Rivard, S. Managing the Risk of IT Outsourcing. CIRANO Working Papers, Montreal, June 1998

A Case Study: Coordination Practices in Global Software Development 11 2. Aubert, B.A.; Houde, J.F.; Patry, H. and Rivard, S. Characteristics of IT Outsourcing Contracts. Proceedings of the 36th Hawaii International Conference on System Sciences, HICSS 03 3. Aubert, B.A.; Patry, H.; Rivard, S. and Smith, H. IT Outsourcing Risk Management at British Petroleum. Proceedings of the 34th Hawaii International Conference on System Sciences, 2001 4. Bahli, B.; Rivard, S. A Validation of Measures Associated with the Risk Factors in Information Technology Outsourcing. Proceedings of the 36th Hawaii International Conference on System Sciences, HICSS 03 5. Bodker, K., Is Development in an Outsourcing Context Revisiting the IS Outsourcing Bandwagon. 6. Campbell R. Harvey's Hypertextual Finance Glossary, 2004, http://www.duke.edu/~charvey/classes/wpg/bfgloso.htm (03.01.2005) 7. Carmel, E.; Agarwal, R. Tactical Approaches for Alleviating Distance in Global Software Development. IEEE Software, March/April 2001 8. Clemons, E.K.; Hitt, L.M. and Snir, E.M. A Risk Analysis Framework for IT Outsourcing. Draft, 2000 9. Department of Information Resources, Austin, Texas. Outsourcing Strategies: Guidelines for Evaluating Internal and External Resources for Major Information Technology Projects. June, 1998 10.Grover, V.; Cheon, M.J.; and Teng, J.T.C. The Effect of Service Quality and Partnership on the Outsourcing of Information Systems Functions. Journal of Management Information System, 12 (4), 1996, pp.89-116 11.Jarvinen P; On Research Methods. Opinpajan Kirja, Tampere, Finland, 2001 12.Lacity, M. Lessons in Global Information Technology Sourcing. IEEE Computer, August 2002, pp.26-33 13.Lacity, M.C.; Willcocks, L.O.; and Feeny, D.F. IT Outsourcing: Maximize Flexibility and Control. Harvard Business Review, May-June 1995, pp.84-93 14.Lee, J.N.; Huynh, M.Q.; Kwok, C.W. and Pi S.M. The Evolution of Outsourcing Research: What is the Next Issue?. Proceeding of the 33rd Hawaii International Conference on Systems Sciences, Maui in Hawaii, January 2000, pp.1-10. 15.Light, M. Matlus, R. Berg, T. Strategic Analysis Report Application Development Contracting: Lifeline or Noose? R-14-38791, 28 September 2001 16.Loh, L. and Venkatraman, N. An Empirical Study of Information Technology Outsourcing: Benefits, Risks, and Performance Implications. Proceeding of the 16th International Conference on Information Systems, Amsterdam, the Netherlands, December 10-13, 1995, pp. 277-288. 17.Report of Latvian Ministry of Economics, June 2002 18.Roy, V.; Aubert, B.A. A Resource Based View of the Information Systems Sourcing Mode. CIRANO Working Papers, Montreal, October 1999 19.Smite, D.; Global Software Development Project Management Distance Overcoming. Software Process Improvement, The Proceedings of the 11 th European Conference, EuroSPI, Trondheim, Norway, 2004 20.Smite D.; Sukovskis U. A Case Study: Coordination Practices in Global Software Development. Submitted to SPICE Conference, 2004. 21.Willcocks, L.; Fitzgerald, G. Guide to Outsourcing Information Technology. Business Intelligence, 1994