Content uploaded by M. Bhasi
Author content
All content in this area was uploaded by M. Bhasi on Mar 30, 2014
Content may be subject to copyright.
ISSN 2277-3061
2601 | Page Oct 25, 2013
A Case Study on Risk Management Practice in Outsourced Software
Migration Projects
1Srikrishnan Sundararajan, 2Bhasi, M., 3Pramod K.V.
1Department of Computer Applications, Cochin University of Science & Technology, Kochi - 682022, India
sskrishnan02@yahoo.com
2School of Management Studies, Cochin University of Science & Technology, Kochi - 682022, India
drbhasi@yahoo.com
3Department of Computer Applications, Cochin University of Science & Technology, Kochi - 682022, India
pramodkv4@gmail.com
ABSTRACT
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.
Indexing Terms/Keywords
Software Risk; Software Migration; Software Engineering; Case Study; Outsourcing; Project Management; Information
Systems; Life cycle; Legacy Modernization; Offshoring.
Academic Discipline and Sub-Disciplines
Computers: Software Risk; Information Technology: Outsourcing, Offshoring; Software Life Cycle: Migration
SUBJECT CLASSIFICATION
Software Management: Software development, Software process; Project and People Management: Life cycle
TYPE
Survey; Interview; Case Study
INTRODUCTION
Council for Innovative Research
Peer Review Research Publishing System
Journal: International Journal Of Computers & Technology
Vol. 11, No. 5
editor@cirworld.com
www.cirworld.com, member.cirworld.com
ISSN 2277-3061
2602 | Page Oct 25, 2013
INTRODUCTION
Abbreviations Used
CMM Capability Maturity Model
IT Information Technology
ODC Offshore Development Center
PM Project Manager
Risk The term implies Risks in Software Development, in the absence of other qualifications
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.
SME Subject Matter Expert
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‟.
Devolution of
ownership
→
Onshore Outsourced
Offshore Outsourced
Insourced
Captive Offshored
In-House
Geo/ Cultural Spread →
Figure 1: Variation of Risk Vs Ownership & Geo Spread
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 Table-1. Please refer to (Sundararajan, Bhasi, & Pramod, 2013) for more details on
literature survey.
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
ISSN 2277-3061
2603 | Page Oct 25, 2013
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).
Table 1: Summary of Some of the Important Risk Research Studies
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)
User, Development team, Organizational environment, Project complexity, Project
management Requirements
2000
Oz (Oz & Sosik, 2000)
Lack of corporate leadership, poorly communicated goals/deliverables, inadequate
skills and means, poor project management, and deviation from timetable/budget
2005
Schmidt (Schmidt,
Lyytinen, Keil, & Cule,
2001)
Corporate Environment, Sponsorship/Ownership, Relationship Management,
Project Management, Scope, Requirements, Funding, Scheduling, Development
Process, Personnel, Staffing, Technology, External Dependencies, Planning
2007
Tesch (Tesch,
Kloppenborg, & Erolick,
2007)
Sponsorship/Ownership, Funding and Scheduling, Personnel and staffing, Scope,
Requirements, and Relationship Management
2008
Thomas (Thomas & Bhasi,
2008)
Team risk, Planning & execution, External risk, User risk, Complexity risk
2008
Charalambos
(Charalambos, Iacovou, &
Nakatsu, 2008)
Risk profile of offshored-outsourced projects – 25 risk items, mainly representing
customer concerns. Refer another work done by us (Sundararajan, Bhasi, &
Pramod, 2013) for details
Figure 2: Software Development Phases in a migration Project
The researchers conducted a thorough study of practices in migration projects (Galinium & Shahbaz, 2012) (Geet, 2010),
(Micro Focus, 2013) (Dell, 2013) (Tata Consultancy Services, 2013) (HCL Technologies Ltd., 2011). Based on the above,
phases and activities generally applicable to migration projects were compiled and classified as shown in Fig.2, after
ISSN 2277-3061
2604 | Page Oct 25, 2013
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 following –
understand the objectives of migration, take stock of the application inventory, and learn the application. The factor
solution include the aspects – design 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 customer-
vendor 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 phases – a 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.
Table 2: Risk Management Factor Structure
Understanding
of requirements
Solution
Project
Planning
Knowledge
Management
Employee
Motivation
Quality
of Build
Quality of
Testing
Change
Management
Table 3: Regression Analysis of Risk Management Factors - Migration Projects
Model
Risk Management
Factors
Fit
Unstandardized
Coefficients
Sig.
Collinearity
Statistics
adj. R
Square
Durbin-
Watson
B
Std. Err
Tolerance
VIF
M1
(Constant)
-127.120
33.400
0.000
0.409
1.978
Knowledge
Management
Very High
3.197
1.573
0.060
0.943
1.060
Solution
Very High
6.575
2.853
0.040
0.943
1.060
M2
(Constant)
-63.360
24.771
0.022
0.199
2.360
Employee Motivation
Moderate
2.642
1.186
0.042
1.000
1.000
M3
(Constant)
-59.163
26.478
0.041
0.144
2.192
Project Planning
Moderate
3.131
1.632
0.074
1.000
1.000
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
ISSN 2277-3061
2605 | Page Oct 25, 2013
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 categories – development, 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 vendor – an annual maintenance contract for the
migrated application being planned – ensuring 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.
ISSN 2277-3061
2606 | Page Oct 25, 2013
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 (Runeson P. , Host, Rainer, & Regnell, 2012) (Johnson,
Kou, Paulding, Zhang, Kagawa, & Yamashita, 2005). 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.
ISSN 2277-3061
2607 | Page Oct 25, 2013
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 (Runeson P. , Host, Rainer, & Regnell, 2012) (Hair, Black,
Babin, & Anderson, 2006). Construct validity refers to the ability of a measurement tool (e.g., a survey, case study) to
actually measure the concepts underlying the research questions. For example, if the interviewee does not correctly
understand the interview questions, there is a threat to construct validity. Internal validity refers to the extent to which it is
possible to make an inference that an independent variable influences the dependent (investigated) variable. For example,
if the researcher is not aware of the extent to which other factors may influence the investigated factor, there is a threat to
the internal validity. External validity refers to analytical generalization of research findings, so that it is relevant to other
settings or samples; i.e., defining a theory. Internal consistency is a measure based on the correlations between different
items on the same test (or the same subscale on a larger test). It measures whether several items that propose to
measure the same construct produce similar scores. Reliability indicates the overall consistency of a measure. A measure
is said to have a high reliability if it produces similar results under consistent conditions. There are several general classes
of reliability estimates. Inter-rater reliability assesses the degree of agreement between two or more raters in their
appraisals. Test-retest reliability assesses the degree to which test scores are consistent from one test administration to
the next. (Runeson P. , Host, Rainer, & Regnell, 2012) (Hair, Black, Babin, & Anderson, 2006). Inter-method reliability
assesses the degree to which test scores are consistent when there is a variation in the methods or instruments used.
Internal consistency reliability assesses the consistency of results across items within a test. It measures whether several
items that propose to measure the same general construct produce similar scores.
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.
ISSN 2277-3061
2608 | Page Oct 25, 2013
THE CASE STUDY FINDINGS
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:-
1. Issues related to Network Connectivity & Communication
2. Adequacy of Estimates
3. Adequacy of Application Knowledge
4. Adequacy of Documentation
5. Technology Issues
6. Availability of Manpower with the right skills
7. Dependency on customer personnel
8. Environment Configuration for concurrent operation by multiple project teams
9. Adequacy of Quality Control
10. Team Utilization
11. Managing Customer Expectations
12. Managing Employee Morale
13. Communication & Control
14. Change Control
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.
Table 4: Reclassification of Risk Mgmt. Factors
Refer
Section
Risk
Item#
Description of Risks in the vendor’s
Risk Control Plan
Corresponding Risk Management Factor
from the Survey Based Study
(RD-SA)
2
Adequacy of Estimates
Solution
(and Approach)
5
Technology issues
9
Adequacy of Quality Control
11
Managing Customer Expectations
(RD-KM)
3
Adequacy of Application Knowledge
Knowledge Management
4
Adequacy of Documentation
(RD-PP)
1
Communication / network / connectivity
Project Planning
6
Availability of Manpower with the right skills
7
Dependency on customer personnel
8
Environment configuration
10
Team utilization
13
Communication & Control (Project
governance)
(RD-EM)
12
Employee morale
Employee Motivation
(RD-X)
9
Adequacy of Quality Control
Quality of Build
Quality of Test
(RD-X)
14
Change Control
Change Management
ISSN 2277-3061
2609 | Page Oct 25, 2013
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
ISSN 2277-3061
2610 | Page Oct 25, 2013
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.
Table 5: Meeting Schedule
Meeting Description
Participants
Frequency
Operational Review
(Onsite/ Offshore Audio
Conference)
Customer: Senior Management and Project Manager
Vendor: Senior Management and Project Manager
Monthly
Technical Steering Committee
(Onsite/ Offshore Video
Conference)
Customer: Project Manager, and Senior Architect
Vendor: Project Manager and Architects
Initiation: Twice a
week
Pilot: Weekly
Other phases: Bi-
weekly
Project Review
(Onsite/ Offshore Audio
Conference)
Customer Project Manager and Vendor Project
Manager
Weekly
Project Progress
(Onsite)
Vendor: Onsite Coordinator
Customer: Project Manager (with optional presence of
SMEs)
Daily
Project Progress
(Offshore)
Vendor: Project Manager, Onsite Coordinator and
Team Leads (BA and Testing team lead, optional)
Daily
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
ISSN 2277-3061
2611 | Page Oct 25, 2013
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, regression Model M1, it is
observed that the risk management factors, solution and knowledge management together exhibited high model fit. The
case study findings were in agreement with this observation (See Section RD-SA and RD-KM). The factor solution
addressed challenges such as estimating an unknown application, and devising a migration solution that automates
project work to the best extent. The interviewees rated solution as „the top risk management factor‟ in migration projects.
From Table-3, regression Model M2, and M3, it is observed that the risk management factors, employee motivation and
project planning exhibited moderate model fit. The case study findings agreed with this observation, as is evident from the
discussions under Sections RD-EM, and RD-PP. The other risk management factors - understanding of requirements,
quality of build, quality of testing, and change management seem to have received only limited attention, and their
description is limited to one section – Section RD-X. The factor understanding of requirements seemed to have received
better attention at the beginning of the project.
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 high – considerable 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.
ISSN 2277-3061
2612 | Page Oct 25, 2013
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 survey-
based 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 offshore-
outsourced 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.
ISSN 2277-3061
2613 | Page Oct 25, 2013
APPENDIX
1. APPENDIX – A Results from Factor Analysis of Risk Management Items
2. APPENDIX – B Results from Regression Analysis of Risk Management Factors with Effort Variance
APPENDIX – A Results from Factor Analysis of Risk Management Items
Risk Management Factor
Risk Management Item
Item-Factor Loading
Understanding of Requirements
Planning for SME Time
0.46
Requirements Discussion/ Elicitation
0.65
PM Involvement in Estimation
0.39
Solution
Tool Usage
0.79
Solution & Approach
0.74
Stake holder R&R Identification
0.42
Project Planning
Estimation Method
0.69
Requirements Traceability
0.58
Metrics & Continuous Improvement
0.7
Governance Plan
0.63
Knowledge Dissemination Plan
0.48
Fast Tracking & Crashing
0.44
Change Management
Impact Analysis (of software change)
0.78
Negotiation of Scope & Schedule
0.7
Scheduling Changes Together
0.7
Quality of Build
Due Diligence in Requirements Analysis
0.81
Due Diligence in Design
0.77
Due Diligence in Construction
0.74
Quality of Testing
Due Diligence in System Test
0.65
Due Diligence in Regression Test
0.85
Due Diligence in Performance Test
0.75
Due Diligence in Retrofit Test
0.79
Knowledge Management
Training on Application Functionality
0.56
Project Induction Program
0.78
On the job training
0.85
Trainee Ramp up
0.73
Mitigation of Employee Unavailability
0.51
Employee Motivation
Employee Profile Mapping
0.6
Employee Goal Setting
0.74
Employee Appraisal
0.79
Employee Rewards & Recognition
0.79
Employee Onsite Assignment
0.63
Individual Initiatives
0.49
Employee Work Life Balance
0.52
ISSN 2277-3061
2614 | Page Oct 25, 2013
APPENDIX – B Regression Analysis of Risk Management Factors with Effort Variance
Model Id.
Risk Management Factors
Model Fit
Significance
Adjusted R Square
Projects in General - Risk Management Based Model
G1
(Constant)
0.000
0.236
Change Management
High
0.011
Knowledge Management
High
0.001
Quality of Build
High
0.031
G2
(Constant)
0.000
0.244
Knowledge Management
High
0.000
Quality of Build
High
0.031
Solution
High
0.013
G3
(Constant)
0.000
0.309
Change Management
Very High
0.008
Project Planning
Very High
0.000
Solution
Very High
0.057
G4
(Constant)
0.000
0.248
Change Management
High
0.002
Employee Motivation
High
0.008
Solution
High
0.006
G5
(Constant)
0.000
0.065
Quality of Test
Indicative
0.001
G6
(Constant)
0.000
0.072
Understand. Requirements
Indicative
0.001
Development Projects
D1
(Constant)
0.000
0.351
Knowledge Management
Very High
0.031
Project Planning
Very High
0.050
Solution
Very High
0.071
D2
(Constant)
0.000
0.159
Employee Motivation
Moderate
0.001
D3
(Constant)
0.009
0.078
Change Management
Indicative
0.014
D4
(Constant)
0.003
0.107
Quality of Build
Moderate
0.005
D5
(Constant)
0.010
0.073
Quality of Test
Indicative
0.018
D6
(Constant)
0.004
0.1
Understand. Requirements
Moderate
0.007
Maintenance Projects
O1
(Constant)
0.017
0.202
Change Management
High
0.021
O2
(Constant)
0.000
0.444
Project Planning
Very High
0.000
O3
(Constant)
0.003
0.326
ISSN 2277-3061
2615 | Page Oct 25, 2013
Quality of Build
Very High
0.003
O4
(Constant)
0.054
0.114
Quality of Test
Moderate
0.068
O5
(Constant)
0.017
0.202
Change Management
High
0.021
O8
(Constant)
0.054
0.114
Quality of Test
Moderate
0.068
Migration Projects
M1
(Constant)
0.000
0.409
Knowledge Management
Very High
0.060
Solution
Very High
0.040
M2
(Constant)
0.022
0.199
Employee Motivation
Moderate
0.042
M3
(Constant)
0.041
0.144
Project Planning
Moderate
0.074
REFERENCES
[1] Alberts, C. a. (2009). A Framework for Categorizing Key Drivers of Risk, CMU/SEI-2009-TR-007, ESC-TR-2009-007.
Technical Report, Software Engineering Institute, Carnegie Mellon University.
[2] Aspray, W., Mayadas, F., & Vardi, M. (2006). Globalization and Offshoring of Software: A Report of the ACM Job
migration Task Force. NY: ACM.
[3] Barki, H., Rivard, S., & Talbot, J. (1993). Toward an Assessment of Software Development Risk. Journal of
Management Information Systems , 10 (2), 203-225.
[4] Boehm, B. (1991). Software risk management: Principles and practices. IEEE Software , 8 (1).
[5] Charalambos, L., Iacovou, & Nakatsu, R. (2008). A Risk Profile Of Offshore-Outsourced Development Projects.
Communications of the ACM , 51 (6).
[6] Dell. (2013). Proven Mainframe migration, Modernization and Optimization Solutions. Retrieved April 01, 2013, from
Dell: http://www.clerity.com/services/mainframe-migration-and-modernization.php
[7] Evans, G., & Simkin, M. (1989). What Best Predicts Computer Proficiency? Communications of the ACM , 32 (11).
[8] Galinium, M., & Shahbaz, N. (2012). Success Factors Model: Case Studies in the migration of Legacy Systems to
Service Oriented Architecture. 2012 Ninth International Joint Conference on Computer Science and Software
Engineering (JCSSE). IEEE.
[9] Geet, J. D. (2010). Reverse Engineering on the Mainframe:Lessons Learned from “In Vivo” Research. IEEE
Computer Society.
[10] Hair, J., Black, W., Babin, B., & Anderson, R. (2006). Mutivariate Data Analysis. Pearson.
[11] HCL Technologies Ltd. (2011, April). Virtual Mainframe - Legacy Application Rehosting. Retrieved April 01, 2013,
from HCL: http://www.hcltech.com/white-papers/mainframe-and-midrange-services/virtual-mainframe-legacy-
application-rehosting
[12] Johnson, P., Kou, H., Paulding, M., Zhang, Q., Kagawa, A., & Yamashita, T. (2005). Improving software development
management through software project telemetry. IEEE Software , 22 (4).
[13] Kajko-Mattsson, M. N. (2008). State of Software Risk Management Practice. IAENG, International Journal of
Computer Science , 35:4.
[14] Keil, M., Cule, P., Lyytinen, K., & Schmidt, R. (1998). A framework for identifying software project risks.
Communications of the ACM , 41 (11), 76-83.
[15] Mclvor, R. (2005). In The Outsourcing Process (pp. 188-190). Cambridge University Press.
[16] Micro Focus. (2013). Micro Focus mainframe migration reference architecture - White Paper. Retrieved April 01,
2013, from Micro Focus: http://www.microfocus.com/downloads/micro-focus-mainframe-migration-reference-arc-
200574.aspx
ISSN 2277-3061
2616 | Page Oct 25, 2013
[17] Microsoft Corporation. (2012). Alliance Members. Retrieved March 21, 2013, from
http://www.platformmodernization.org/Pages/directory.aspx
[18] Nasscom. (2013). Indian IT-BPM Industry – FY2013 Performance Review, FY2014 Outlook. Mumbai: Nasscom.
[19] Nidumolu, S. (1995). The Effect of Coordination and Uncertainty on Software Project Performance: Residual
Performance Risk as an Intervening Variable. Information Systems Research , 191-219.
[20] Oz, E., & Sosik, J. (2000). Why information systems projects are abandoned: a leadership and communication theory
and exploratory study. Journal of Computer Information Systems , 41 (1).
[21] Peteraf, M. (1993). The cornerstones of competitive advantage: a resource based view. Strategic Management
Journal , 14, 179-91.
[22] Runeson, P., & Host, M. (2008, December 19). Guidelines for conducting and reporting case study research in
software engineering. (D. Sjoberg, Ed.)
[23] Runeson, P., Host, H., Rainer, A., & Regnell, B. (2012). Case Study Research in Software Engineering - Guidelines
and Examples. Wiley.
[24] Schmidt, R., Lyytinen, K., Keil, M., & Cule, P. (2001). Identifying software project risks: An international Delphi study.
Journal of Management Information Systems , Vol.17, No.4, pp.5-36.
[25] Shull, F., Basili, V., Carver, J., Maldonado, J., Travassos, G., Mendonca, M., et al. (2002). Replicating software
engineering experiments: addressing the tacit knowledge problem. Proceedings on International Symposium
Empirical Software Engineering.
[26] Smith, D., Eastcroft, M., Mahmood, N., & Rode, H. (2006). Risk factors affecting software projects in South Africa.
South African Journal of Business Management , 37(2).
[27] Sundararajan, S., Bhasi, M., & Pramod, K. (2013). An Empirical Study of industry practices in Software Development
Risk Management. International Journal of Scientific and Research Publications , 3 (6).
[28] Tata Consultancy Services. (2013). Application Modernization. Retrieved April 01, 2013, from Tata Consultancy
Services: http://www.tcs.com/offerings/it-services/application-modernization/Pages/default.aspx
[29] Tesch, D., Kloppenborg, T., & Erolick, M. (2007). IT Project Risk Factors: The Project Management Professionals
Perspective. Journal Of Computer Information Systems .
[30] Thomas, S., & Bhasi, M. (2008). A Study on Software Development Project Risk, Risk Management, Project
Outcomes and their Inter-Relationship. Retrieved March 25, 2013, from Dyuthi: http://dyuthi.cusat.ac.in/
[31] Vlaar, P., Fenema, P., & Tiwari, V. (2008). Cocreating Understanding and Value In Distributed Work: How Members
of Onsite and Offshore Vendor Teams Give, Make, Demand, and Break Sense. MIS Quarterly , 32 (2), 227-255.
[32] Wallace, L. (1999). The development of an instrument to measure software project risk. Doctoral Dissertation,
Georgia State University.
[33] Wallace, L., & Keil, M. (2004). Software project risks and their effect on outcomes. 47 (4).
[34] Yin, R. (2003). Case study research. Design and methods (3 ed.). Sage.
ISSN 2277-3061
2617 | Page Oct 25, 2013
ABOUT THE AUTHORS
First Author – Srikrishnan Sundararajan, Master of Technology (Computer Science & data
Processing), Department of Computer Applications, Cochin University of Science &
Technology, Kochi, India, sskrishnan02@yahoo.com
Srikrishnan Sundararajan received Bachelor of Science degree in Electrical Engineering, in
1983; and Master of Technology in Computer Science and Data Processing in 1993 from
Indian Institute Technology, Kharagpur. He is currently a Research Scholar in the Cochin
University of Science & Technology, Kochi, India. He was employed as Group Project Manager
in HCL Technologies; Professor of IT in SCMS-Cochin; Principal Architect in UST-Global;
Delivery Manager in CSC; Associate Consultant in TCS. He is certified ITIL2012, PMP2003, and
CQA1998. . He is a member of PMI, ACM, and IEEE. He is currently pursuing research in
Software Risk. His area of interest includes Software Risk and Project Management.
Second Author – PhD. Bhasi, M., School of Management Studies, Cochin University of
Science & Technology, Kochi, India, drbhasi@yahoo.com
M Bhasi received Bachelor of Technology degree in Production in 1986; and Master of
Technology in Industrial Engineering in1988 and Ph.D. (Industrial Management) in 1997 from
Indian Institute Technology, Kharagpur. He was employed in ICIM as marketing executive for
over a year and then has taught at Cochin University for the last 23 years. He has also served
as the Managing Director of CONSUMERFED, Kerala for nearly three years. He is currently the
Director of the School of Management Studies of Cochin University. He is a member of IEEE
and a life member of the IIIE and Kerala Management Association. He has 14 international and
47 National Journal publications. His research interests are in the areas of Operations
Management, Information systems and Project Management. He has guided 10 Ph.D. Thesis.
Third Author – PhD., Pramod K.V., Department of Computer Applications, Cochin University of
Science & Technology, Kochi, India, pramodkv4@gmail.com
Pramod is presently working as Associate Professor of the Department of Computer
Applications, Cochin University of Science and Technology. He received Master of Science in
Mathematics from University of Kerala, in 1981 and Ph.D. in Simulation & Modeling from Cochin
University of Science and Technology in 1989. He has more than 20 years of teaching and
research experience. He is a member of IEEE. He has published about 25 research papers in
National and International Journals. Two of his research students have been awarded PhD
degree, one in Cryptography and other in Mathematical Morphology. His areas of research
interests are Simulations & Modeling, Cryptography, Coding theory, Mathematical Morphology
and Data Mining.