A Case Study on Risk Management Practice in Outsourced Software Migration Projects

While there are many studies conducted on software risk during the last two decades, very few have been published on software risk management practice in IT industry. In this paper we explore industry practice in the management of software development risks in outsourced software migration projects. We take the vendor perspective, post contract finalization. We conducted an online survey of 145 software projects executed by global IT vendors with process maturity of CMM Level 5. Based on this we built a statistical model relating software risk management factors with project outcome. An embedded case study of a large software migration project executed for a fortune 500 company was undertaken to check whether the model agrees with actual industry practice. The best practices and experiences from the project are also shared.


Senior IT professionals
A group of practising IT professionals having more than 15 years of offshore project management experience, and who supported the study throughout by reviewing the survey / interview questionnaires, providing explanations and sharing lessons learned / Industry best practices.

The Research Question & Its Relevance
Today, the global software spending is estimated at USD $1 Trillion (Nasscom, 2013), where multiple IT organizations spread across different geographies & cultures are working in collaboration (Alberts, 2009) (Vlaar, Fenema, & Tiwari, 2008). Managing simple in-house projects has given way to new business models such as offshoring and outsourcing (Mclvor, 2005), which has created new risks and magnified the existing ones (Aspray, Mayadas, & Vardi, 2006) (Charalambos, Iacovou, & Nakatsu, 2008).However, there are very few reports on software risk management practices in IT industry (Kajko-Mattsson, 2008); or IT offshoring / outsourcing (Charalambos, Iacovou, & Nakatsu, 2008). According to researchers, prior studies are focussed on risks in in-house projects; offshored-outsourced context need thorough investigation. In this context, we investigated the following:-1. Is there a unique set of software development risk factors associated with offshored-outsourced software migration projects? 2. How are these risks managed? Fig.1 illustrates the area of interest in this study and it is represented by the top right quadrant. Along with devolution of ownership and geo-spread, risks also increase. In the rest of this paper, the term risk applies to "software development risk in the context of offshored-outsourced software projects".

Literature Survey
A number of research studies have been conducted in the area of software risk identification. However, the risks identified by various researchers are found to change over the time and context of study. Therefore, researchers encourage a broad view of risk (Keil, Cule, Lyytinen, & Schmidt, 1998) (Peteraf, 1993) rather than developing one single framework that is applicable to all contexts, given the complexity of software development. This view is endorsed by many researchers who look at risk management as a continuous process where additional information and risk status are utilized to refine the risk list and the risk management plans (Smith, Eastcroft, Mahmood, & Rode, 2006). A summary of major software risk research work done is provided in

Migration Projects
For the purpose of this study, software projects are broadly classified into three categories -development, maintenance, and migration. These categories point to inception; sustenance; and transformational phases of a software application. According to Senior IT professionals this is one of the schemes adopted in industry to classify software projects broadly across technology platforms. Migration projects are transformational services, where software underlying a business O c t 2 5 , 2 0 1 3 application is changed, without impacting the existing business functionality -e.g., transformation of a business application from COBOL to Java, or from Mainframe to Windows (Microsoft Corporation, 2012) (Micro Focus, 2013).

Year The Researcher(s) Risk Factors
1991 Boehm (Boehm, 1991) Top ten risks that can be categorized into understanding of requirements, lack of skills, change in scope of work, computer capability, product performance and external components/externally performed work 1993 Barki (Barki, Rivard, & Talbot, 1993) Technological newness, Application size, Lack of expertise, Application complexity, Organizational environment 1995 Nidumolu (Nidumolu, 1995) Project Coordination 1999 Wallace (Wallace, 1999  . Based on the above, phases and activities generally applicable to migration projects were compiled and classified as shown in Fig.2, after O c t 2 5 , 2 0 1 3 subjecting to reviews by Senior IT professionals. A migration project in general, comprises of the phases, assessment, design of migration solution, build, test, and implementation. The activities in assessment phase include the followingunderstand the objectives of migration, take stock of the application inventory, and learn the application. The factor solution include the aspectsdesign of target architecture, development of technical processes to map the source software stack to target, development of tools & techniques, development of test strategy, and definition of customervendor stakeholder responsibilities in implementing the solution. In migration projects, the software and data are transformed using tools and manual procedures. The transformation part is called the build -tools are developed to do most of the build activities. The remaining code is converted by adhering to simple manual procedures that are elementary, mechanical and repetitive in nature, unlike other categories of projects. The migrated application is tested and implemented in production, replacing the existing live version, in phases or all at once (big bang). Once the migrated application stabilizes, old application is decommissioned.

THE SURVEY BASED STUDY
Prior studies on software development risks have used information obtained from Survey of IT professionals, Delphi study, Case studies, Action research, Personal experience in the industry, and Secondary sources of information, among others. This study was conducted in two phasesa survey followed by a case study. The objective of this study was to understand the software development risks and risk management in information systems offshoring and outsourcing, from vendor perspective. In order to achieve the objective, the following hypothesis was framed.

[Hypothesis -H1]
Software migration projects have a unique risk management profile, in the context of offshored-outsourced projects, from vendor perspective.
The population of our study was offshore-outsourced software projects, highlighted by quadrant 1 of Fig.1. The unit of observation was software project. We used survey method for data collection. We prepared a questionnaire by compiling risk items from the studies listed in literature survey. We also included some more risk items from CMM processes for organizational capability & maturity. The questionnaire was reviewed by a panel of senior IT professionals for content validity. Through a pilot survey, the questionnaire was further refined. The final questionnaire consisted of 44 on risk management, among other categories of questions. Each respondent was requested to rate the risk management items applicable to a project that they completed and delivered recently. Project outcome was measured in terms of percentage of effort variance, which indicated the difference in estimated effort versus actual effort at the time of completion of the project delivery. Snowballing method was used for data collection. Using an online survey, we obtained 179 responses. After data validation, 145 responses were selected for analysis. The respondents brought us a total of 1740 years of IT offshore-outsource experience. The respondents belonged to Global IT companies that included Accenture, CSC, CTS, HCL Technologies Ltd., IBM Global Services, Infosys, L&T Infotech, MphasiS, TCS, and Wipro, from among others. These companies had achieved process maturity of CMM Level 5. The average experience of the respondents was 12 years, out of which 53% were Project Managers, 28% Team Leads and 19% Architects. The average team size was 19. The average project duration was 18 months. Observations from development, maintenance, and migration projects were obtained. The responses covered technology platforms such as iSeries, Java-J2EE, Linux, Mainframe, Microsoft, UNIX, and COTS. In about 13% of the projects, the entire project team was stationed at customer site; about 12% were pure offshore projects; and 75% of the projects were carried out with hybrid teams.  Risk management items were subjected to Factor Analysis. Prerequisites for factor analysis were ascertained as follows.
The reliability of the questionnaire indicated by Cronbach"s alpha, was above the acceptable level of 0.6. Sampling O c t 2 5 , 2 0 1 3 adequacy indicated by KMO value within the acceptable range of 0.6 to 0.9. Sufficiency of correlations indicated by Bartlett Test of Sphericity was significant at 0.00 levels. A risk management structure consisting of eight factors emerged from factor analysis -understanding of requirements, solution, project planning, knowledge management, employee motivation, quality of build, quality of testing, and change management (See Table- 2). Please refer to Appendix-A for detailed results and (Sundararajan, Bhasi, & Pramod, 2013) for more detailed discussion on the factor analysis performed.
Effort variance is one of the commonly used measures for project success (Nidumolu, 1995), (Wallace & Keil, 2004). The influences of risk management factors (independent variables) on effort variance (dependent variable) were investigated using regression analysis. The prerequisites for regression analysis were checked. Statistics for univariate normality of the outcome variable (effort variance) were checked and found good -skewness was found to be -0.522, which is within the acceptable limits of +/-2.58; kurtosis was found to be 1.327, which is within the acceptable limits of +/-1.96. Multi collinearity of the independent variables was validated using VIF (variance inflation factor). All VIF values were acceptable with value <5. Independence of observations was measured using Durbin-Watson coefficient. The values were found to be within 1.9 to 2.2, which is acceptable. Partial regression plots (each factor versus outcome) were visually checked to validate homoscedasticity, by using SPSS plots.
The survey responses were divided into three sets, based on the project categoriesdevelopment, maintenance, and migration. Regression analysis was conducted on cases belonging to each project category, to relate risk management factors to project outcome (effort variance). The percentage of variance of dependent variable explained by a regression model is considered a measure of overall model fit. In human behavioural studies, a value between 10% and 40% is acceptable, given the complex nature of human character (Evans & Simkin, 1989). This rule holds good in software development, as it is human centric. For categorizing the model fit, the following thumb rules were adopted in this study. A score below 10% was considered indicative, 10% to 20% moderate, 20% -30% high, and above 30% very high model fit.
The result of regression analysis on development, maintenance and migration projects is shown in Appendix-B. From Appendix-B, it can be noticed that the salient risk management factors and the model fit exhibited clearly varies from one project category to another. The model for migration project cases is summarised in Table-3. This model comprising of four risk management factors with emphasis on solution and knowledge management, represents the risk management profile unique to software migration projects, in the context of offshore-outsourced projects from vendor perspective. Therefore, Hypothesis -H1 is true.

THE CASE STUDY PROTOCOL
Empirical research includes quantitative and qualitative methods (Runeson P. , Host, Rainer, & Regnell, 2012). Quantitative methods provide evidence for the statistical significance of a hypothesis; but are difficult to apply in a real world context. Various factors affect the outcome of software engineering activities. Hence, replication of a study is challenging (Shull, et al., 2002). In case studies, phenomena in their real world context are investigated, especially when boundary between the phenomenon and its context is unclear. Case studies are commonly used to increase knowledge about individuals, groups, and organizations related phenomena (Yin, 2003). Therefore, software engineering is an area that is best suited for case studies (Runeson & Host, 2008).

The Case Study Design
The objective of this case study was to check whether the risk management model for migration projects that emerged from the survey-based study agrees with industry practices. In order to achieve the objective, the following hypothesis was framed.

[Hypothesis -H2]
Migration projects have a unique risk management profile, in the context of offshored-outsourced projects, from vendor perspective, as observed from the survey based study.
This was a single embedded case study. The units of observation were risk factors. This project under consideration was initiated for the migration of a large legacy application, since support to the underlying legacy product and services were scheduled to be withdrawn by the product vendor. The code was expected to be delivered after performance test and regression test. User acceptance testing was done under the supervision of the customer for four weeks. This was followed by two calendar months of post implementation warranty support. The selected project exhibited a wide variety of characteristics, some of which are listed below.


Prior relationship with the customer in terms of executing small projects  Anticipated strategic initiative, benefitting both customer and vendoran annual maintenance contract for the migrated application being plannedensuring top management commitment to the project"s success  The team that used or supported the application was distributed globally  Multiple technology platforms were present-mainframe, client server and open systems  The total number of source programs was very large -1500 modules (500 online and 1000 batch modules)


The duration of the migration project was nine months, long enough for the PM to understand and influence the project risks  The team size was 22, a size good enough to study the influence team management related risks. O c t 2 5 , 2 0 1 3  The IT company that executed had matured quality processes (CMMi Level 5), that provided relatively predictable outcomes (therefore, the influence of random errors due to inadequacy of processes were minimum)  Part of the skill set requirements belonged to niche skill category ("4GL"legacy software)  Technology expectations -performance improvement by 25% and improvement in agility The ethical considerations were clearly informed to the participants in writing, along with name, email-id and contact information of the researcher. The case study did not have any sponsor. It was a non-profit, academic study. It was assured that no references would be made in the case study report that might point to the identity of any individual, client or project. Further, figures indicative of the real project environment (project and product data) obtained were modified to avoid direct indication of the project, while preserving the relevant characteristics intact (e.g., ratios, generalizations etc). Participation in the study was voluntary, and anonymous. The final report from the case study was shared with the participants and their approval was obtained.

Data Collection
In case studies, three different types of data sources may be used ( . In first-degree data collection, the researcher is in direct contact with the subjects and collect data in real time, e.g., Interviews, and Delphi surveys. In this study, we used semi structured interviews. The first author, leveraging his network, obtained senior management approval for conducting the case study. An email stating the objectives of the study, and providing assurance for maintaining confidentiality of information, was sent to the management and approval for interviews was obtained. In second-degree data collection, the researcher directly collects raw data without interacting with the subjects during the data collection, e.g., video recording. In this study this method was not used. Third degree data source was historical data from documents & records which included, statement of work, project plan, minutes of meetings, risk management plan, project overview presentations, quarterly project review reports, project closure reports, lessons learned reports, and best practices. The data that collected included cost performance (the ratio of work completed versus plan), adherence to schedule, adherence to service level agreements, best practices and lessons learned from experience. The case study used formal template based approach for data analysis, which is best suited for software engineering case studies (Runeson & Host, 2008).

Interviews Figure 3: Pyramid Model for Semi Structured Interview
The first author and two senior technical architects with more than 15 years of IT experience together constituted the interview team. The team had long time association with similar IT projects. The team first studied and prepared notes on industry practices in migration projects from solution providers in the market, company specific process hand books, best practices and lessons learned. This information along with the survey findings was used to build a checklist for semi structured interview. The checklist was reviewed by Senior IT professionals. The team discussed the checklist to develop a good understanding of migration project processes and associated risks. The checklist acted as a guideline to maintain the focus of the discussion. At the same time, flexibility of exploration offered by semi structured interview was utilized. O c t 2 5 , 2 0 1 3 Confidentiality of information was assured to the interviewees through an email. Telephone, email, chat, and skype (for video conference) were used to conduct the discussions. The interviews started with a brief explanation of the background, purpose, outcome/ reports, as well as confidentiality of the information shared. The interviews were conducted in an informal atmosphere, which took an elapsed time of two hours for each session. A pyramid model was used for discussions, beginning with specific questions, and opening up during the course of interview (See Fig.3). Relevant information from project records and metrics were noted. The notes were summarized and information that may breach the confidentiality agreement was removed. Relevant portions of the case report were circulated to the respective interviewees for feedback. Based on the feedback, the report was revised. The final report was shared with the PM.

Validity
Validity is usually described using the following measures ( A number of measures were taken to improve the validity. The case exhibited wide variations. Data triangulation was achieved through the following. To achieve observer triangulation, more than one personnel from each project under consideration were interviewed. Also, personnel with different roles were selected for interview. To achieve source triangulation, notes were taken from the project and process records / documents. To achieve methodological triangulation, quantitative techniques and qualitative techniques were used. Quantitative technique involved a survey of 145 software projects, the findings of which formed the basis for the case study. Quantitative techniques also included analysis of project metrics and project performance. The qualitative techniques included semi structured interviews. The interview questions were built based on survey findings, and literature survey on industry practices in the project category under consideration. Senior IT professionals reviewed the questionnaires. The interviewers were associated with similar IT projects for a prolonged time. Therefore, the interviewee"s observations were well understood.

Data Analysis & Reporting
Project and process metrics were subjected to quantitative analysis. The findings from semi structured interview were subjected to qualitative analysis. According to (Runeson & Host, 2008), structured analysis of qualitative data in case studies can be done in the following ways.
 Immersion approaches: Least structured, relying on intuition and interpretive skills of the researcher.


Editing approaches: These are less structured approaches and include the use of codes defined based on findings of the researcher during the analysis.


Template approaches: These are more formal approaches, and based on defined research questions.
 Quasi-statistical approaches: These are most formal approaches, and include statistical analysis of the interview transcript.
It is hard to obtain a clear chain of evidence in informal immersion approaches and on the other hand, it is hard to interpret the result of statistical analysis of words in documents and interviews. Therefore according to (Runeson & Host, 2008), editing approaches and template approaches are most suitable in software engineering case studies. The characteristic aspects of this case study included questions built on survey based study and industry practice; the interviewer"s long term association with similar projects; and review / guidance by Senior IT professionals. Hence the approach used was formal. The case study used formal template based approach. In order to ensure that the cases do not point to the identity of the project, customer, or vendor, some changes were made to the numbers and description, while preserving the characteristics. Original records of interview were destroyed after finalizing the report. To demonstrate evidence for conformance to qualitative data analysis, the following are provided -citations from interviewees; figures indicative of the real project environment; quantitative analysis of project and process metrics; as well as data classification and summarization from observation to findings with respect to the core theme of the study, viz., risks and risk management factors. O c t 2 5 , 2 0 1 3

Risk Factors Reported by the Interviewees
The risk factors reported by the interviewees and those stated in the project"s risk control plan are compiled into the list shown below:-

Classification of the Risk Factors Reported
The risks identified in the case study and corresponding risk management factors that emerged from the survey-based study were reclassified (Runeson P. , Host, Rainer, & Regnell, 2012) as shown in Table-4, as a part of data analysis. A description of these risks and how these risks were managed are described in the sections shown in column 1.

Description of the Project Risks & Risk Management Plan
Each risk and risk management strategy adopted are described and explained in subsequent sections. The observations from the interviewees are expressed in quotes (Runeson & Host, 2008) to provide a chain of evidence, in some sections, where relevant.

(RD-SA) Solution and Approach
Since application knowledge was limited, accuracy of initial customer estimates was a suspect. In order to overcome this, the following measures were taken. Before initiating the ODC project, two technical architects were sent to customer site for a period of three weeks, in order to understand the migration requirements, and to assess the application. This resulted in identifying "more components and complexities". The customer agreed to revise the estimates by 150%. A second revision was made after the proof of concept program (discussed below), where other technical challenges was unearthed. This resulted in another upward revision of estimates.
The customer expected 25% performance improvement through migration. In order to validate the migration strategy and assess the efficiencies from migration, a pilot exercise was undertaken. This was called proof of concept program. Here, it was observed that without making modifications to the software logic, performance improvement is not possible. It was recommended that performance or agility improvement must be taken up as a separate project. Other issues "brought to light" included, technological complexities such as, presence of third party software with intellectual property rights, gaps in mapping legacy technology features to target technology etc. Based on customer concurrence, the schedule was revised to provide a longer duration to develop tools / solution to address the technology gaps.
Solution design was given the top priority. It was subjected to multiple rounds of reviews with the technology architects internal to the vendor organization, and customer SMEs. Possibilities of tool usage were identified. A proof of concept program was undertaken (as remarked above) to validate the migration strategy. Twenty representative program modules, representing the complexities in the application were selected for migration. The delivery was subjected to rigorous review by the customer as well as the vendor personnel. Based on the observations, technology issues were identified and resolved. Tools & techniques for software / data translation, and testing were designed with the objective of achieving the highest degree of automation, possible within the budget and time constraints. During the first delivery, the tool provided 20% automation. By the last delivery, the automation achieved was about 80%. The vendor made successful use of support from innovation labs (internal technology centers of excellence), organizational business domain expertise, and partnership with solution providers.

(RD-KM) Knowledge Management
The ODC did not have prior knowledge about the software application. Being a legacy system, the documentation available was "very poor" (inadequate). The mitigation strategy included some of the following actions. Two senior technical architects were assigned to work from customer site. One of them was assigned the role of onsite coordinator, who acted as "bridge between the customer SMEs and offshore team. The team studied the objectives of migration; interacted with the customer SMEs to gain insight into the business processes & application. The company engaged business analysts from organizational business ("vertical") support groups, to train the offshore team, and support the offshore testing team in generating test cases and executing the tests. A detailed induction program was prepared by the team of onsite assignees, offshore technical architects, and offshore business analyst, with guidance from customer SMEs. Knowledge transition / training sessions were organized for the offshore PM, offshore architects, team leads and business analysts. The sessions were conducted by the principal architect from customer side (using video conference facility), and the SMEs from the company"s offshore captive unit. Available application documents and training documents were obtained from the customer team. Self study complemented the knowledge enhancement efforts.

(RD-PP) Project Planning
Risks related to project planning included the following -network connectivity & communication issues, dependency on customer personnel, concurrent work by multiple teams, manpower with the right skills, resource utilization, and project governance, among others. These risks and their plans adopted for their mitigation are discussed below.
Network connectivity & communication: For maintaining the security and confidentiality of the software application & data, the customer directed the ODC team to work on customer system using "remote login". Connectivity was established to the system through the local captive unit of customer. Only a set of designated team members were given access rights. Therefore, a shift roster with two shifts a day was planned. The activities that could be done outside the customer system were planned.
Dependency on customer personnel: A governance plan was prepared defining the organizational structure, roles and responsibilities of the stakeholders to enable them to work together. Provisions were made "to escalate the impact of delays" due to dependency on customer personnel on the schedule and cost; these issues were discussed in project status meetings.
Concurrent work by multiple teams: Separate work area was provided for the migration project team, in order to maintain integrity of software and data that they are using and isolate their work environment from that of other projects teams.
Manpower with the right skills: Being a migration project, "skill requirements were complex". This included, but not limited to, niche skills on mainframe, expertise in the intricate technology details "at systems programming level" to transform legacy system to open systems, prior experience in similar projects to develop test cases and conduct test. The resource O c t 2 5 , 2 0 1 3 requirements were planned three months ahead and the team was allocated ahead of time from the organizational resource pool. The team was ramped up in time, which included acquiring the required competencies through training, self study and mutual sharing.
Resource utilization: The team size was big. Activity planning and scheduling were done early in order to utilize the team effectively. Fast tracking (doing activities before the planned time); Crashing (compressing schedule) etc were planned to reduce idle time. The customer was requested to plan their activities for review / implementation accordingly. Idle time was utilized for improving competency in the project activities through well defined training programs. Project governance: A detailed governance plan was prepared to ensure communication, monitoring, control, scope management, risk management, configuration management, and change control. Project visibility at a level appropriate to various stake holders was ensured. A technical steering committee was formed, including architects from customer and vendor side (as well as the respective project managers). This steering committee driven by the senior technical architect from customer side and technical architects from vendor side formed the back bone of the project governance structure. Utilizing video conferencing facility, the committee met weekly once during the pilot phase, and bi-weekly during the rest of the project duration. A meeting schedule was prepared to ensure communication and control (See Table-5).

(RD-EM) Employee Morale
The team did not have prior experience in the application being migrated. The uncertainties in the project were higher, compared to other categories of projects, due to factors such as inadequate knowledge, inadequate testing and technology gaps between source and target software. This along with "tight" schedule necessitated multiple shifts and working extra hours. At the same time, the manual procedures involved were elementary, mechanical and repetitive in nature (See Section 1.3). All these factors together had a negative influence on employee morale. Therefore, appropriate rewards, recognition and entertainment at work programs were undertaken. Pick-up & drop facilities for those who worked outside office hours were in place. Every Friday, a fun at work program was organized for entertainment and team building. After making the delivery of a batch of program modules (by around every quarter), a daylong outing for the team was organized. Six team members were sent onsite on rotation at various stages, including for pre-delivery test. An unspecified number of people obtained "very good" salary hike. Two persons got fast track promotion. Five members were sent abroad for long term foreign assignments of their choice, at the end of the project.

(RD-X) Other Risk Management Factors
Understanding of requirements: A team of two architects was sent for initial study as discussed in Section RD-SA. During the entire course of the project, a high level of collaboration was maintained with the application experts in order to deliver the expected requirements, as discussed in Section RD-SA, Section RD-KM, and Section RD-PP.
Quality of build: Automated solution and detailed procedures helped to achieve quality of build, as discussed in Section RD-SA. The build was subjected to peer-review within vendor team.
Quality of Test: Building and executing exhaustive test scripts for the large, complex and inadequately documented software application was neither feasible nor practical. Testing to ensure that existing functionality was not impaired (regression test) was performed in consultation with the customer. The testing was subjected to formal review process by vendor"s quality assurance team, prior to delivery. Remediation of defects found during customer acceptance test took a O c t 2 5 , 2 0 1 3 month"s time, after which the migrated code was implemented in production, meeting the twelve months deadline. Defects found in the production implementation were fixed during the warranty period of two months.
Change management: Requirements did not change during the project execution. The changes made to the application by other project teams during the progress of the migration project, were incorporated in the delivery at the end of the project.

Discussion of Case Study Findings
The case study was conducted to check whether the risk factor structure and risk management model for software migration projects that emerged from the survey based study (See Table-2 and Table-3) agree with industry practices.

[Hypothesis -H2]
Migration projects have a unique risk management profile, in the context of offshored-outsourced projects, from vendor perspective, as observed from the survey based study.
The risk management factor structure that emerged from survey based study included eight factors -understanding of requirements, solution, project planning, change management, quality of build, quality of testing, knowledge management and employee motivation (See Table-2). The risks identified in the project were mapped to corresponding risk management factors that emerged from survey based study (see Table- 4). From Table-3 In summary, all the eight risk management factors that emerged from survey based study were identified in the case study. The risk management factors, project planning, knowledge management, solution, and employee motivation were found to have received relatively high importance than other factors. The case study findings conform to the risk management model proposed for migration projects (See Table-3). Therefore the apriori assumptions that migration projects have a unique risk management profile in the context of offshored-outsourced projects from vendor perspective, agree with industry practices.

RECOMMENDATIONS, LIMITATIONS, CONCLUSION, AND DIRECTIONS FOR FUTURE RESEARCH
The study was conducted in two phases. Through a survey based study, a hypothesis was formulated on software risk management in offshore-outsourced migration projects, from vendor perspective. Thereafter, a case study was conducted to check whether the hypothesis agrees with industry practice. In this section, we briefly discuss the recommendations to IT industry, limitations of the study, conclusion and directions for future research.

Recommendations
According to Senior IT professionals, the industry does not use formal models for risk management. The software risk management plan is ad-hoc and is prepared based on expert opinion, analogy, or intuition. A major outcome of this study is the development of a formal model for the management of software development risks in the context of migration projects. The study recommends that, the risk management factors identified and the benchmark levels observed in this research be used to prepare risk management process handbooks for the specific project category of migration projects. Migration projects are one-time projects, where a team that is usually new to an application equips itself for a one time project to transform the application to a new software technology. The individual team members in general may not have prior expertise on older technologies on which the application is built. By the time the team learns the basics of the application and develops expertise in the technologies used, the project is completed and closed. The challenges in migration projects start with estimating an application whose technical complexities are not known. Usually these projects are under estimated. Estimates "become accurate when the project unfolds". Inventory assessment and proof of concept (POC) of migration approach helps in making the estimates more accurate. Estimates, POC and approach (mainly, the development and use of tools for automating the software processes) are all part of "solution", which is "the most critical success factor". A vendor is most competitive with "the possession of best tools" and techniques. Customer expectations from migration can be very highconsiderable performance improvement, refactoring and agility. "Performance improvement in migration is usually a myth". Performance improvement is a separate project by itself, involving redesign and code changes. By involving SMEs from customer team in a systematic way (project governance) risks related to lack of knowledge can be mitigated to a considerable extent. Morale building activities need to be planned to improve employee motivation, since migration projects are abundant with mechanical activities. In summary, it is recommended that the project manager must attach paramount importance to solution design, knowledge management, and project governance, in addition to setting realistic expectations with respect to cost, schedule, and software performance. O c t 2 5 , 2 0 1 3

Limitations
This study has limitations applicable to all survey based studies and case studies. In the survey based study, vendor perspective of risk, post contract finalization, is considered. Factors such as offshore-outsource strategy, vendor selection and customer perspective of risk, are not considered. Samples were drawn only from global IT companies with process maturity of CMM Level-5. When companies with lesser process maturity are considered, the uncertainties in multiple key process areas are bound to have an influence on the model. One response was received from each project; in spite of best efforts, it was not possible to locate more than one team member who worked for a specific project. Hence triangulation of observation was not possible. However, the study was conducted according to the guidelines for surveybased research laid down by Hair et al (Hair, Black, Babin, & Anderson, 2006). The questionnaire was valid and reliable; the respondents had rich experience bringing a total of 1740 years of IT experience; the sampling was found adequate and the findings were explained using industry best practices compiled from insights obtained through discussions with Senior IT professionals. Therefore, it is expected that the findings from the survey-based study add value to the body of knowledge in software risk management.
Case study is a suitable research methodology for software engineering research since it studies contemporary phenomena in its natural context and therefore, researchers are increasingly using this method. But it cannot be considered as empirical data to validate a theory. Case study method was used here to check whether the hypothesis generated from survey based study agree with actual industry practices. Though representative cases showing wide variation of risk management features were selected, it may be noted that there are numerous features associated with software risk management that need separate studies. The study was conducted according to the guidelines laid down by (Runeson P. , Host, Rainer, & Regnell, 2012), including aspects such as case study design, case selection, data triangulation, and data analysis. The interviewers were associated with similar IT projects for a prolonged time so that the interviewee"s observations were well understood. Therefore, it is expected that the findings from the survey-based study add value to the body of knowledge in software risk management.

Conclusion
The risk item, risk rankings, and risk management, in the context of offshored-outsourced software projects differ from firm owned, or in-sourced model. Though generalization of risk management is a very valuable area of research, research on current IT models, such as offshoring, outsourcing and distributed project management would add value to IT practice in a significant way. There are only a few studies reported on the actual industry practice and in particular the offshoreoutsourced model. Charalambos (Charalambos, Iacovou, & Nakatsu, 2008) conducted a detailed study of risk profile in offshored-outsourced projects, from customer perspective. This study takes vendor perspective and thereby providing a more holistic picture of risk management in offshored-outsourced projects. Regression analysis established evidence for linear relationship of risk management factors with project outcome. The models that emerged from regression analysis identified the following key focus areas (risk management factors) for software risk management -project planning, knowledge management, solution, and employee motivation. In order to check whether the above findings agree with Industry practice, we undertook an in-depth case study of a large offshored-outsourced migration project. The case study highlighted the characteristic features of risk management in software migration projects. Migration solution and knowledge management emerged as the top risk management focus areas. Automation of the migration process through tools and techniques was the foremost factor that decided the project performance. In a context where the team lacked knowledge about the application, the tools started by providing 20% automation in the first delivery, and steadily improved to provide an impressive 80% automation by the final delivery. Diligent approach to knowledge management, especially, getting the involvement of SMEs; and having a technical steering committee oversee the project activities regularly, helped to mitigate the risks related to quality. The complex project, comprising of multi-functional teams working over geographies, required high level of coordination. This was achieved through an appropriate organizational structure, and well defined communication plan.

Directions for Future Research
The study established the relationship of risk management factors with the project outcome. If risk factors and risk management factors are measured with a more accurate scale e.g., 10 point rating, the variance in the project outcome could be better explained. However, the challenge for a researcher lies in getting experienced respondents to spend adequate time on providing the responses. One way of exploring this possibility is through availing industry sponsorship. The risk management model proposed here needs further detailing, through in depth case studies on industry practices. The influence of project constraints on outcome also needs investigation. O c t 2 5 , 2 0 1 3 APPENDIX