PRIORITIZED RISKS AND TREATMENT STRATEGIES IN GLOBAL SOFTWARE DEVELOPMENT (GSD)

The study conducts a review for the literature in order to compile the risks that are directly related to the GSD strategy. The case study adopts a Delphi methodology that allows the researcher to achieve consensus on the most relevant and critical risks associated with the GSD project. Twenty software development experts from all around the world participated in the study, with a minimum of fifteen expert in each Delphi round. The four rounds of the Delphi method used in this study are designed to gain consensus on the most crucial risks of the GSD strategy, as well as perform a risk assessment for all the risks compiled from the literature and verified by the participating experts. The results show that there are ten main risks that gained consensus by software development experts and need to be addressed as a priority in GSD projects, where all of them have medium to high probability of occurrence and impact on the software project success using a GSD strategy.

 They mainly used in projects of a localized nature, as it does not take into consideration the type of risks that were mentioned earlier, which are mainly emerging from distributing the project over several locations.  They do not provide guidance and access to mitigation strategies that have proven its effectiveness in reducing the risk impacts, rather than calculating risk probabilities and adjusting the project schedule. The significance of this research is emerging from the lack of a tool that provide a standardized risk management guidance for GSD project managers that could save efforts and increase the possibility of reducing the risk impacts in the software project lifecycle. Moreover, this tool contributes into expertise sharing between different specialists in the domain, which could be an important step to unify the strategies used in GSD project management. Furthermore, the current tools used in GSD project managers are reviewed in the literature in order to highlight their advantages and disadvantages in the management process. Additionally, integration possibilities are studied in order to help the current tools' users to benefit from the research results and save any time and effort that could be spent in the implementation process.

Global Software Development (GSD)
In setting up a GSD project, the initial goal is to manage the project in a global context while administrating operations among the different sites. The GSD project managers focus their efforts on defining the team structure and allocating the different tasks according to the skill pool available for them. Moreover, implementing a strong communication strategy is essential in order to ensure a smooth operation between the different sites. In order to ensure that all skills are covered within the team, project managers propose a training program for the team members. During operations, management strategies, procedures, coordination tools, meeting policies, incentive plans and role descriptions are implemented as basic features for the GSD project [13,14].

Risk Management in Software Development
The main aim of risk management in software development is to minimize the impact of unforeseen events that could jeopardize the success of the project through increasing costs, time. Moreover, it is possible to turn risks into opportunities that the project could benefit from through an extensive assessment and knowledge of the possible treatment strategies that can be used [15]. There are three main goals that the risk management strategy shall ensure in software development project: completion of the development according to the time schedule, completion of the development according to the set budget, completion of the development with the required functionality. The ratio of failed software projects increases the urgency to implement risk management strategy, techniques, and tools, as 25% of the software projects fail and more than 40% face risks that could lead to failure [16,17].
Through a literature survey of the studies that addressed risk management in software development in the past thirty years, Neves & da Silva (2016) showed that all of the software projects adopt project management systematics in risk management, while 85% depend on lessons learned in order to identify, assess and control risks. Moreover, the authors confirmed the large number of projects that are either faced with high impact risks or cancelled due to a very high risk factor. Of the 535 publications that addressed risk management in projects, 61% were addressing software in risk development, indicating the significance of the subject for the domain [18,19].
Pimchangthong & Boonjing [20] identified four main practices for risk management, which are followed by information technology projects, and used for project management and risk management worldwide; risk identification, risk analysis, risk response and risk monitoring and control. These practices are set to monitor two main performance factors within the project; process and product. The process performance is measured through the completion of the project within the planned budget and schedule. Noentheless, the product performance is meausred through the reliability of the developed system, its usability, its flexibility, meeting user's requirements, meeting the functional requirements, user satisfaction and overall high quality [20,21].

Risk Identification
An informal approach can also be used through a discussion between the project stakeholders in order to list the possible sources of risk in the project through their past experiences. The periodic approach is performed through deploying certain tools to check for risk potentials in the different aspects of the project. The formal approach is carried out as risk management specialists are employed in order to produce a report of the current risks that are faced by the project, as well as potential risks that may arise in the future [15]. Furthermore, in studies that addressed risk in software projects adopting the extreme models, the authors confirmed that the most efficient method in order to identify risks in software projects is by either surveying the literature in order to find out the risks from the past experiences and lessons learned, or through identifying a full set of the software development operations and performing brainstorming sessions to identify the potential risks that are associated with each process or operation [22]. Moreover, there are recommendations to implement brainstorming and surveying methodologies, such as risk breakdown structure, event and defect trees, as well as using external consultants by the Delphi technique, which is the methodology followed in this research [23].

Risk Analysis and Assessment
de Wet & Visser [16] presented a model for risk assessment through a risk analysis using several tools, including performance models, cost models, network analysis, decision analysis, and quality factor analysis. Based on the perfomed analyses, the risks can be prioritized according to their positive or negative impacts on the project. Therefore, risks are ordered according to treatment and importance priority based on risk leverage and risk exposure, as well as applying a compound risk reduction to each one of them. The most important criteria to identify during the risk analysis is the occurrence probability of the risk and the expected impact of the risk on the time and cost factors of the project. If the risk has a chance of more than 70% to occur, the probability is marked as high, while a score between 30% to 70% is given to risks with medium occurrence probability, and low occurrence risks are assigned to scores below 30%. Moreover, the impact of the risk is evaluated according to the impact on the project's budget. If the risk is expected to cause the failure of the project through missing the launching date of the software or increasing the project cost by more than 50%, the risk is considered high and catastrophic. If the impact of the risk would cause issues in the project in term of recoverable time schedule impact and cost increase between 10% to 50%, then the risk impact is considered medium and critical. If the risk would cause minor issues to the project with time impact not affecting the launch date and cost impact of less than 10% of the project budget, then the risk is considered low and marginal [24]. Based on that, risk score is calculated on the risk analysis matrix, shown in Figure 1, and through the following equation:  Figure 2 shows the four quadrants and their representation. The assignment of the risks to the quadrant can be accomplished through the assessment of field experts [25], which is a methodology adopted in this research.

Risk Treatment and Response
There are basic treatment and response strategies that are used in risk management, which are applied to software development projects. Moreover, the choice of the treatment strategy mainly depends on the type of the risk, its probability, its impacts, its occurrence closeness, its frequency and the possibility of the treatment strategy implementation. Once the treatment strategy is selected, along with the specific measures to be taken, the risk is assigned to one of the team members in order to follow its implementation [26]. The treatment strategies that are standardized in risk management practices are as the following [27,28]:  Risk avoidance: a strategy that eliminates the risk by eliminating the related activity that is associated with it. The selection of this strategy is attributed to very high impacts or losses that are expected to be imposed on the project. It is also possible to change the method that is used for the activity execution, if the analysis shows that it is the source of the risk. Since adopting an avoidance response would possibly affect the scope or the course of the project, it is crucial that proper and sufficient communications are established between the project stakeholders in order to reach a common understanding of the risk and the necessity of the measure.  Risk transfer: in case the risk had a low probability of occurrence and a high impact on the project, this strategy is preferred by the project managers. In this case, the risk is transferred to a third party that can manage the risk due to its specialty in it. Furthermore, the risk can be transferred to another phase of the project, where it can be handled with less impact.  Risk mitigation: this measure includes reducing the risk to an acceptable level, which can be achieved by different approaches such as escalating the matter to a higher management level for a strategic decision, performing a sensitivity analysis, or finding an engineering solution for the issue causing the risk.  Risk acceptance: this measure occurs when the impact of the risk is accounted for by allocating the required contingency or accepting the losses due to the low impact expected to be imposed on the project.

Risk Control and Monitoring
In the risk control and monitoring phase the actions and treatment strategies that were set for the existing risks are followed through. While the effectiveness of the taken measures is evaluated, new risks are identified and added to the tracking logs for analysis, assessment and treatment [29]. Different types of data are collected about the different risks in order to update their status on a periodical manner. The data include financial, schedule, technical, managerial and supply chain information that could assist the project manager to take further decisions regarding the risk status [30,31].

Survey of GSD Risks, Challenges, and Issues
As risks are usually caused by challenges to the projects, it is significant to understand them in order to be able to understand the risk root causes. Furthermore, challenges and issues can be used to conclude indirect risks in GSD projects, which can be included in the risk lists of the current study. Aranda, Vizcaino, & Piattini [32] identified four main factors that cause the challenges and issues in GSD projects, which are:  Timetable challenges.  Cultural challenges.  Knowledge management challenges. Jimemez et al. [33] have identified nine main challenges that faces software projects adopting a GSD strategy as the following:  Communication challenges.  Configuration management challenges.  Knowledge management challenges.  Quality management challenges.  Project management challenges.  Process support challenges.  Coordination challenges.  Collaboration challenges. A critical review for the global software development strategy surveyed the literature for the main issues that face projects that adopt the strategy. As shown in Table 1, while the GSD strategy provides several advantages on all of the studied elements, new risks are imposed on ‫العلوم‬ ‫األسمرية:‬ ‫الجامعة‬ ‫مجلة‬ ‫والتطبيقية‬ ‫األساسية‬ Journal of Alasmarya University: Basic and Applied Sciences them [34]. The presented risks are attributed according to their discipline for classification purposes beneficial for the current study. In a study that focused on the communication issues that face software development projects with GSD strategy, the authors provided two main strategies to resolve the related risks; introduction of several communication tools through scrum and usage of version one software [1].On GSD challenges types, Tihinen [35] classified the risks into five main categories:  Culture. Conchuir, et al. [36] identified three distances and three project elements that are resulting and affected by using the GSD strategy. Moreover, the authors developed a matrix showing the opportunities and challenges that are imposed by each of the distances on the software development project element. The first distance is identified as the temporal distance, which is the time distance that separates the different locations within the project. The socio-cultural distance is the differences between the team members in different locations in language, working habits, professional conduct and business manners, which could cause misunderstandings and miscoordination between the team members. The geographic distance is the most physical distance, which is pursued due to certain advantages; however, this distance is main cause for the temporal and socio-cultural distances. Table 2 shows the positive and negative impacts of the three distances on three main project elements: communication, coordination, and control.  Prikladnicki, et al. [37] identified four main issues that face software projects with GSD strategy: strategic, cultural, knowledge and technical. There are risks associated with software development that emerge from the core and subsidiary operations of the project. It was found that low user involvement and unrealistic time schedule and budget estimations are the most common reasons behind risks in software development projects. Moreover, ambiguous or misunderstood project scope and objectives, understaffing, and lack of senior management commitment and technical knowledge are important factors in causing risks. Therefore, such issues can be resolved by adopting risk management techniques that could alleviate their impacts, as well as eliminate any possible risks that are associated with them [38].
Lamersdorf & Munch [39] provided a study on the main goals from adopting a global software development strategy, which are affected by a set of factors the accompany the adoption of such a strategy. As shown in Figure A, fifteen factors are the direct and indirect cause for four main risks impacting the goals of GSD projects. Furthermore, the main risks that are found in this study are as the following [39]:  Communication, coordination, and control. Widiyatmoko [40] identified seven main risks associated with adopting the GSD strategy in software engineering. The first risk is having insufficient direct communication between the different parts of the team, which mainly affects the problem-solving time and efficiency. Moreover, as tasks within software development projects may depend on each other, delays imposed by certain part of the team can affect the progress of the work for other teams. The overlapping of working hours is also one of the issues that face GSD projects, which its lack can results into inadequate collaboration and subsequent delays. Knowledge differences between the different teams imposes a high risk of distorted information, which can result into quality and rectification processes. Furthermore, the failure of the project management team to provide face-to-face communication tools can add necessary but extra travelling costs. As the GSD teams can be located in different countries, a lack of common understanding can be caused by different expertise and knowledge among the team. The last identified GSD risk within the study is the weakness in control over the project as conventional monitoring tools need to be modified to account for the geographical distance [41].

MATERIALS AND METHODS 2.1 Delphi Technique
The Delphi method or technique is defined as a process to gain consensus through a collective judgement about an event or a phenomenon by a group of experts. The results shall be empowered by a structured knowledge, experience and creativity from a group of experts [42]. Moreover, this method has been well-utilized as a stand-alone or a combined method for studies that are related to risk management in different industries [43]. The process of the Delphi methodology may vary from a study to another; however, there studies that standardized the process for usage facilitation and understanding. Hsu et al. [44] explained the process as the following:  Round one: a part of the study, where usually open-ended questions are used in order to develop the knowledge gathered from the theoretical review. This round is often referred as the data collection round, which can be performed through single or multiple questionnaires until the researcher is certain that the provided items represent the topic of research.  Round two: this round includes testing the results of the first round with the experts' panel through sharing the finalized items with them. This round can be performed through asking the experts to indicate the correctness of the items, to rank-order them, or to provide comments on them.  Round three: the results of the second round are shared with the experts, similar to the first round, where the opinions of the experts are taken into consideration to reach a certain level of consensus.  Round four: the final items and their ratings that achieved the consensus are shared with the experts for final comments. During the development and the carrying out of the Delphi method, the experts' quality is very critical to choose the experts to be from top management who are willing to use the results of the study, professional employees who have field experience or selecting experts based on their achievement in the field of the research [44]. The majority of the studies look for conducting the Delphi study through one to three rounds, and with a number of experts that is ranging from three to more than hundred. Nonetheless, Skulmoski et al. [45] shows the strength of the Delphi study results can be increased by performing a wide literature review along with a pilot study to ensure that the items initially included are the best representing items. The first round's questionnaire is mainly developed through two processes, which are the literature review and the brainstorming based on the researcher's experience. Thereafter, the pilot study is performed on a trial sample in order to ensure that the questions are wellunderstood and to eliminate any confusions. Subsequently, the different rounds are performed similar to the process reviewed in [44].

Research Design
The application of the Delphi methodology is adopted according to the different sources reviewed in the previous section. While the main Delphi structure is maintained, the main aim of the design is to simulate brainstorming between the participating experts as recommended by Tavares, et al. [22] and Didraga [23] as an essential activity in risk management, as well as measuring consensus between experts in software development provided by the method. The rounds are designed to verify the compiled risks that are reviewed in the literature, test the relevance of the risks to global software development projects, assess the extents of the risks, and provide the best treatment strategy for each risk. The study includes four main rounds that aim to achieve the objectives through four rounds, as the following:  Data collection round (Round 1): the compiled risks are provided to the participating experts for verification. The experts are able to retain, delete and modify risk descriptions according to their experience in the field. The opinions of the experts are collected through a narrative form, in addition to action selection. The researcher judges the feedback of the experts in order to determine whether an item should stay or be removed from the risk list. Moreover, items may be modified to describe the risks in a better way.  Relevance round (Round 2): the qualified risk list from the first round is provided for experts for voting based on the relevance of each item to GSD projects. The risks are categorized and judged by the participating experts on a 5-point Likert relevance scale from very relevant to very irrelevant. No elimination is used in any of the subsequent round in order to calculate the consensus for each item and apply a risk assessment on them based on the experts' expertise.  Impact assessment round (Round 3): the experts are asked in this round to indicate the probability of occurrence and the severity of the risks, similar to the risk assessment models reviewed in Lopez and Salmeron (2012) and Vahidnia, et al. (2017). Based on the results further discussions are provided for the two models. The risk probability of occurrence is evaluated on four percentage scale options; 0% to 25%, 25% to 50%,

Journal of Alasmarya University: Basic and Applied Sciences
50% to 75% and 75% to 100%. The severity of the risk impact is judged on a threeoption scale; low, medium and high.  Risk treatment round (Round 4): this round aims to indicate the most suitable risk treatment strategy for each risk item based on the expert's field experience. Four main risk treatment strategies were identified in the literature: reduction, transference, acceptance and avoidance. The reduction of the risk corresponds to other detailed mitigation strategies that are specific for the risk and the project's environment. The four rounds that form the case study in this research are an efficient tool that uses the brainstorming technique to collect experts' opinions, while performing a risk assessment session that is based on consensus. Therefore, it is expected at the end of this research to provide a full list of the risks with their assessments, as well as a final list of the most items that should be prioritized in GSD projects.

Participating Experts
In order to gather the opinions of GSD experts, more than a thousand software development experts were invited to the study through LinkedIn. The final participating experts are shortlisted based on their experience in software development, experience in global software development, number of GSD projects participated in and the level of commitment to the study. A total of twenty experts were gathered, as shown in Table 3 along with their profiles. At the beginning of each round, an email is sent to the experts notifying them of the aim of the round, the link to the survey and providing them with a deadline to complete the task. Once the opinions of fifteen experts were collected past the deadline date, the data collection was closed, and a new round was initiated. The study has been conducted between the months of June and October 2018, where experts were given one to two weeks for each round.

List of Initial GSD Risks
Based on a literature research, fifty-nine risks have been collected and distributed into five main categories, as follows below. The categories had been divided and named according to project management categorization. One category has been added, the fourth category in line with the literature endorsement of the importance of communication, coordination and collaboration in the GSD project. The other categories contain risks that are viewed by the researcher as important risks to be considered from a software project management point-ofview.  Table A1 in the appendix. The categorization ensures the coverage of several aspects that are considered influential on the success and failure of the software project. The financial aspect of the project is essential as it impacts the continuity of the project. Operations, planning, management, and human resources are project management aspects that affects running the software project in a smooth manner. The communication, coordination and collaboration risks have their own dedicated category due to its significant impacts on global software development projects. Finally, technical risks are gathered in a separate category to reflect the issues that can face GSD projects during the development from a technical point of view. The risk identification codes are unique codes according to the grounded theory method, which allows easy referencing and tracing risk items throughout the study.

RESULTS AND DISCUSSION 3.1 Results
the compiled fifty-nine risks were presented before the software development experts participating in the study. By the majority vote of the experts, sixteen risk items were deleted from the initial list of GSD risks, which led into reducing the risks qualifying for the second Delphi round into forty-three risk items. In the second round of the Delphi study, the risks were judged based on their relevance to GSD projects by the participating experts. The cluster mode method (CM) is used to evaluate the consensus on each item in this round, which requires a single rating out of the five Likert scale ratings to achieve a minimum of 50% in order to gain consensus.
Nineteen risk items have gained consensus using cluster mode; however, no elimination was made from the GSD risk list as further consensus is required, in addition for the value added of the risk assessment process that is carried out in the third round. In the third round of the Delphi study, each of the risk items have been assessed according to risk management practices based on their probability of occurrence and impact by the participating experts. The final consensus evaluation is conditioned for items that have achieved consensus based on the cluster mode method in the second round, as well as achieving consensus in both criteria in the third round through the same method.
The results of third round shows that ten GSD risks have gained consensus in the relevance, probability of occurrence and impact criteria. The full list is moved for a fourth round, where the forty-three risk items are voted for the best fit treatment strategy. The participating software development experts were asked to choose one of four main risk treatment strategies for each risk based on their expertise. A summary of the results of the four Delphi rounds is presented in Table A2 in the Appendix. The ten GSD risks that achieved consensus through the Delphi methodology are shown in Table 4 along with their best fit treatment strategies, as per the participating software experts. The final prioritized GSD risks includes one financial risk (A1), two operational and planning risks (B6 and B11), three management and human resource risks (C3, C9 and C14), two communication, collaboration and coordination risks (D1 and D11), and two technical risks (E2 and E3).

Discussion
The probability of risk occurrence for the shortlisted risk items range between a high medium and high (50% to 100%) with medium and high impacts on GSD projects. Therefore, the risk scores are illustrated in accordance with the model provided by Vahidnia, et al. [24] in Figure  3. The risk scores for the shortlisted items range between I2P2 (second degree impact and second-degree probability of occurrence) and I3P3 (third degree impact and third-degree probability of occurrence).

Impact Low
Medium High Figure 3. Position of key GSD risks within the risk analysis matrix as presented by Vahidnia, et al. [24] Moreover, a risk assessment model recommended by Lopez and Salmeron [25], which represents risks on four quadrants based on their probability of occurrence and impact on the project success. Therefore, the key GSD risks are represented in Figure 4 based on that model. It can be observed that all of the key GSD risks that are concluded in this research lay in the first quadrant (Q1), where high probability and high impacts are illustrated. Nonetheless, risk items B6, D1 and D11 have the highest probabilities of occurrence and highest impacts. Moreover, risk items B11, C9, C14, E2 and E3 have a medium high probability of occurrence and high impact. Risk item A1 has both medium probability of occurrence and impact on GSD project, while risk item C3 has a higher probability of occurrence with a medium impact.
Although global software development is meant to benefit from the follow-the-sun development and the larger pool of talents that are provided by several regions, as shown by Agerfalk, et al. [46] and Khan and Subhan [47], there are risks that directly related to the possibility of not finding such talent or the hindrance of the software development caused by time overlapping and holiday differences. However, there risks are found to be treatable through setting the proper processes and procedures to be followed by the project team, as well as hiring and empowering key personnel that can coordinate productivity with other development regions.   [25] There are several benefits that can be accomplished by performing a sound risk management practice in GSD projects in order to allow the strategy to fulfil its goals as presented by Prikladnicki, et al. [2]. Creating trust between the developers and the clients is a key goal of the GSD strategy; however, clients can have lack of trust in development teams that are located in different geographic regions. Therefore, it is one of the essential tasks following the risk assessment in GSD projects to assure clients that quality, budget and time schedule are not compromised through adopting such a strategy. On the contrary, clients can be shown that adopting such a strategy would eventually save their time and money.
As the four risk management practices are identified by Pimchangthong and Boonjing [20]; identification, analysis and assessment, treatment and respose, and monitoring and control. Three of these practices were perfomed in this reseach, where GSD risks were identified through the literature. In the first and second rounds, the compiled risks are analysed for comprehensivity and relevance. In the third round, the risks were assessed based on recommended models by Vahidnia, et al [24] and Lopez and Salmeron [25]. Finally, risk treatment strategies were selected and solutions were suggested through the fourth round. Risk monitoring and control can be achieved through creating a log, where all identified risks are entered, analyzed, assessed and assigned to treatment strategies and solution. Thereafter, the items can be reviewed on a periodic basis to ensure that they attended with the required measures.

CONCLUSIONS
The main problem addressed by this research is the new risks emerging primarily from the geographic distance that is created between the different segments of the development team, which imposed new risks that need to be addressed. Therefore, the main aim of this study was to to develop standardized top common risks in Geographic Software Development (GSD), associate the proven risk treatment strategies, and develop a priority within each list according to the impact of the risk and the effectiveness of the risk treatment strategy. Through an extensive literature review of more than forty studies on GSD risks, fifty-nine risk items were identified and categorized under five main categories:  Financial risks.  Operational and planning risks.  Management and human resource risks.  Communication, coordination, and collaboration risks.  Technical risks. The risks were categorized based on their source or impact on the software project that is developed in a globalized manner. The research adopted a grounded theory methodology to assign a unique identification number for each risk item. Furthermore, the Delphi methodology is utilized in order to gain consensus on the most important and relevant risk items for the GSD project. Subsequently, a panel of twenty software experts is created to perform the assessment of the Delphi rounds. The design of the Delphi rounds consisted on four main rounds to achieve consensus and to assess the risks and suggest treatment strategies for them.
The results of the study showed consensus on ten risk items, which are presented in Table 4. It is recommended based on the research findings to understand that global software development risks are unique for projects that uses the strategy; therefore, it is recommended to perform a separate risk management process for risks associated with the GSD strategy. Hence, risks that are concluded in this study are recommended to be prioritized in all projects adopting the GSD strategy. Furthermore, a special care should be given to the communication, collaboration, and coordination risks as they mainly emerge from the geographic, temporal, and socio-cultural distances created by the GSD strategy. It is also recommended to create partnerships within the software development domain, where trust, coordination and cooperation can be achieved over time. Moreover, this allows the teams to align their knowledge, expectations, and quality perceptions. In future research, this study can be repeated in a periodical basis using the Delphi methodology, as new challenges may raise in software projects adopting GSD strategy and for comparison purposes.