A Conceptual Framework of Challenges and Solutions For Managing Global Software Maintenance

JOURNAL OF SOFTWARE: EVOLUTION AND PROCESS
J. Softw. Evol. and Proc. 2015; 27:763–792

Published online 21 June 2015 in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/smr.1720
A conceptual framework of challenges and solutions for managing

global software maintenance
Bayarbuyan Ulziit1, Zeeshan Akhtar Warraich2, Cigdem Gencel3,4 and Kai Petersen5,*,†
1
In-Process AB, Sweden
2
Nasdaq OMX, Sweden
3
Free University of Bolzano/Bozen, Italy
4
DEISER, Spain
5
Blekinge Institute of Technology, Sweden
ABSTRACT
Context: Software maintenance process in globally distributed settings brings significant management
challenges to software organizations.
Objectives: Investigate the factors specific to managing software maintenance process in globally distrib-
uted settings and best practices in software organizations.
Method: A systematic literature review and interviews with industry practitioners were conducted. For
analysis and synthesis, the grounded theory method was used.
Results: We identified a number of management challenges and mitigation strategies and then classified
them under people, process, product, and technology factors. Overall, a structure of challenges and solu-
tions, the conceptual framework, has been developed that may be used to understand and classify global
maintenance challenges.
Conclusions: Distributed software maintenance process has specific management challenges in relation to
process, people, product, and technology. Therefore, companies performing maintenance in distributed set-
tings should consider these factors, which are not present in the general global software development liter-
ature, although many lessons apply to both. Copyright © 2015 John Wiley & Sons, Ltd.
Received 28 August 2014; Revised 23 February 2015; Accepted 29 April 2015
KEY WORDS: global software engineering; software maintenance; distributed development; outsourcing;
management
1. INTRODUCTION
Global software engineering (GSE) has become a common practice of IT business. Currently, more
than 50 different countries are actively being involved in collaboration for any activity or task in the
software lifecycle [1, 2]. Among the many motivations behind this trend, the mostly mentioned ones
are economic savings through cheaper cost for labor, around-the-clock development, time-to-market
pressure, and the lack of proficient labor in the local market of developed countries [3].
In the global market, packaged software product, bespoke software, commercial off-the-shelf
(COTS), and enterprise resource planning (ERP) systems are prevalently sold [4]. Because
customers of those products are from anywhere in the globe, vendor organizations mostly move or
distribute their product support and maintenance to the locations closer to the customers or to larger
markets [5]. In distributed settings, maintenance operations are mostly carried out in two ways. One
*Correspondence to: Kai Petersen, Blekinge Institute of Technology, Karlskrona, Sweden.

†
E-mail: [email protected]
Copyright © 2015 John Wiley & Sons, Ltd.

764 BAYARBUYAN ULZIIT ET AL.
way is where software vendors control and carry out maintenance and support service through their
own staff in remote sites. Another way is to outsource maintenance to different legal entities on a
contractual base [6]. In either case, a maintenance team may consist of members from locations
distributed globally.
The maintenance phase is the longest part of software lifecycle and, in most cases, also the most
expensive [7–9]. For the last several decades, the cost of software maintenance is continuously
growing [10]. In the 1970s, the costs were around 60% [11], while in the 1990s and 2000s, the
reported costs increased to about 90% and more [12, 13]. Therefore, software organizations have
seen shifting the maintenance work as an opportunity to ease management from many of the daily
burdens of maintenance activities and saving costs. This would leave room for the management to
focus more on organizational strategic activities such as new product research and development
activities. Furthermore, the savings of maintenance costs also would allow increased investment on
other strategic development activities [7, 14].
However, in reality, many organizations fail to gain the expected benefits of GSE and the desired
quality of service and product [15]. Many empirical studies [16–19] confirmed that GSE is a
formidable task and revealed that common major difficulties were caused by organizational, time
zone and cultural differences, coordination and communication barriers, and loss of trust between
collaborators. Although software maintenance is regarded as one of the lifecycle processes that are
more suitable for distributed environment, software maintenance activities typically require
extensive contact with customer, short- iterative cycles, and quick response times, which are
interfered with the communication delays, misinterpretations of requirements, and indirect
responsibilities often prevalent in distributed team collaboration [6, 20].
Hence, there is an urgent need to explore and understand the challenges of managing software
maintenance process in GSE contexts, the sources of these challenges, and mitigation strategies of
companies if they use any [21, 7, 22, 23]. These require also revealing the relationships between
challenges, as different challenges, when they occur, might result in other challenges as well. To the
best of our knowledge, even though there are a few studies that focused on the challenges of GSE in
general, there is no comprehensive study carried out in the context of management of global
software maintenance work. This is important as there are clear distinctions between software
development and maintenance, as well as global and local maintenance. It is important to highlight
that the focus of this study is on offshoring. That is, all contexts considered in this study face
cultural, temporal, and geographic distances.
Our contributions are to provide a conceptual framework (Wieringa and Daneva [24]) to explain
challenges and solutions in global software maintenance. To create the conceptual framework, we
make the following sub-contributions:
• The identification of challenges in relation to managing global software maintenance and their cat-
egorization with the help of the grounded theory method.
• The identification and categorization of solutions for managing global software maintenance.
• A mapping between the challenges and the solutions.
From a practical point, the information is valuable in two ways. First, practitioners can conduct a
risk assessment determining which challenges they may face when going global with maintenance.
Second, they can find solutions addressing the challenges they are facing. To achieve these
contributions, we conducted a systematic literature review [25] to identify challenges and
solutions. The systematic literature review was used to devise an interview instrument. The
literature study and interviews were analyzed using the grounded theory method [26] to devise a
conceptual framework to explain and structure challenges and solutions in the context of global
software maintenance.
The remainder of the paper is structured as follows: Section 2 provides background on the
concepts of global software development (GSD) and software maintenance. Section 3 explains
the research methodology and details of how the systematic literature review and the interviews
were conducted. Section 4 presents the results. In the discussion (Section 5), we reflect on the
findings with respect to the research questions. Section 6 concludes the paper with implications
for research and practice.
Copyright © 2015 John Wiley & Sons, Ltd. J. Softw. Evol. and Proc. 2015; 27:763–792
DOI: 10.1002/smr
CHALLENGES AND SOLUTIONS FOR MANAGING GLOBAL SOFTWARE MAINTENANCE 765
2. BACKGROUND
2.1. Global software development

Different collaboration modes exist for collaborating work in distributed software development, for
example, inter-organizational outsourcing, intra-organizational offshoring, and intra-national
nearshoring [27]. These collaboration modes are sometimes named differently in the literature. For
example, inter-organizational outsourcing is mentioned as offshore outsourcing in [7] and
nearshoring and farshoring in [28, 29]. The focus of this study is to investigate settings where
maintenance is conducted in different countries (offshore), either in the form of insourcing or
outsourcing.
According to [30], offshore software development outsourcing activities have been going on for
more than a decade. However, software development outsourcing companies are still facing many
problems. In addition, different risks (e.g., cost and time over-run and cultural differences) have also
been identified for software development outsourcing. Some studies [17, 31–33] show that this
development methodology comes with a large set of challenges as well. These challenges are
summarized in a matrix shown in Table I.
In GSD, four synthesis studies [34–37] have a similar goal as our study, with the difference that
they are focused on general/new software development, namely, to identify challenges and
mitigation strategies. Verner et al. [34] classified existing synthesis studies in a tertiary study,
where none had a particular focus on software maintenance. The studies tabulate existing
challenges and solutions to GSD problems. As this study focuses on maintenance specific
challenges, we utilized the previous studies [34–37] to reflect on whether a challenge identified
in our study is maintenance specific or generic. For example, it was apparent that in the area of
people-related challenges, only few unique or amplified factors related to global maintenance
have been identified.
2.2. Global software maintenance

In popular linguistic dictionaries [38, 39], maintenance is defined as work of preserving things in
proper order or in good condition. IEEE [40] defines software maintenance as ‘The process of
modifying a software system or component after delivery to correct faults, improve performances or
other attributes, or adapt to a changed environment’. On the other hand, Pigoski [13] claimed that
maintenance is a complete extent of post and pre-delivery activities. This definition reflects a
meaning that software project planning, designing, and implementation activities also affect cost of
maintenance process. Boehm [41] stated that maintenance is a process of changing the existent
operating software without altering its fundamental functions. In this study, we chose the IEEE
definition due to the fact that the focus of this study lays on post-delivery activities.
Different types of maintenance are considered. Under Boehm’s definition [41], the following types
of activities are covered in the scope of maintenance: design and development of minor parts into
existing software; redesign and redevelopment of minor parts of existing software; and modification
of the existing software code, parts of documentation, or structure of database. Swanson [42]
classified maintenance activities into corrective, adaptive, and perfective maintenance. Later, the
taxonomy is revised in ISO/IEC 14764 as follows:
Table I. General challenges of a globally distributed setting.
Geographical distance Cultural distance Temporal distance

Communication Trust, team cohesiveness and Cultural diversity Synchronous
communication overhead communication
Coordination Task distribution Knowledge sharing Interaction within
different time zones
Control Keeping track of progress Deciding on the management Time consumption
style to be used
DOI: 10.1002/smr
• Corrective activities: modifications to diagnose the scenario and remove discovered defects.
• Adaptive activities: modifications to make software suitable to new environment.
• Perfective activities: modifications to enhance system functionalities or documentations, im-
prove performance, maintainability, or other quality attributes.
• Preventive activities: actions to detect and remove dormant defects before they lead to potential
failures.
• Emergency maintenance: special case of maintenance in case of unexpected failure of software, also
known as ‘unscheduled corrective maintenance performed to keep a system operational’ [43].
\In general, multiple challenges are observed in software maintenance. Many studies emphasized
that one of the most critical challenges confronting software engineers is to handle software
maintenance and manage change control [44, 45, 9, 46]. Furthermore, software maintenance is
the least explored and, at the same time, the mostly underestimated and troublesome phase [45,
47]. Chen and Huang noticed that, despite the high cost, less attention is paid to issues
encountered in maintenance activities than to other development activities [44]. It potentially
impacts on unreasonable staffing or the devalued effort allocation which could become risk
factors of low-quality maintenance.
It is also important to understand the distinction between software maintenance in globally
distributed context and in traditional in-house contexts. Globally distributed projects are more
difficult than in-house projects to manage [1]. Generally, it is due to diversification and isolation in
project team members due to distance (geographical, temporal, and socio-cultural), which has an
impact on communication, coordination, and control (see e.g., [17, 31–33]).
Global software development and global software maintenance are different processes [P25], and
globally distributed settings bring both some common sources of challenges as well as major
differences. In the preceding discussion, Table I provides an overview of new challenge categories
in the GSD context. These also apply to global maintenance process. Table II, on the other hand,
shows some main differences between global software development and maintenance.
3. RESEARCH METHODOLOGY
To achieve the research aims of this study, we formulated the following research questions:
• RQ1: What are the challenges of managing software maintenance in globally distributed settings?
• RQ2: How do software organizations mitigate these challenges?
In order to answer our research questions, we first performed a systematic literature review (SLR)
following Kitchenham’s guideline [48] followed by interviews [49] with industrial practitioners.
Thereby, we identified the challenges and mitigation strategies and analyzed the collected data using
Table II. Main differences between global software development and maintenance.
Maintenance process Development process
Staffing Underestimate and assign new or Assign experienced personnel [P1]

inexperienced personnel [P1]
Required technical Requirement analysis, development Often individual experts for each
skills technologies, testing, implementation, skill [72]
and customer interaction [72]
Domain knowledge Knowledge of whole software product Knowledge of responsible
and its business flow [P11,P15] software units [P11,P15]
Knowledge source Source code, documentation, and Mostly source code [72]
where to find responsible expertise [72]
Major work effort 70% of work is understanding the Mostly writing code [P16]
existing code and debugging [P16]
Lifecycle Activities outside the general lifecycle [73] Activities within the lifecycle [73]
DOI: 10.1002/smr
the grounded theory (GT) [50] method. In the following two sections, we present the details of data
collection during the literature review and the interviews. After, we present the data analysis and
results.
3.1. Data collection

In the subsequent discussion, we present the details of the data collection process we followed during
the SLR and the interviews.
3.1.1. Systematic Literature Review study. We first conducted an SLR [25], which focused on
synthesizing the findings on challenges and solutions on global software maintenance. An in-depth
and systematic synthesis was performed based on the extracted data, which distinguishes systematic
reviews from other types of literature studies (e.g., mapping studies [51]). In order to make the
search process obvious and reproducible, all the search results were recorded. Thus, we maintained
the SLR log based on all activities conducted.
3.1.1.1. Search. Our research questions determined the keywords to be used. We also checked the
synonyms and alternative terms by referring to linguistic dictionaries and limiting them within the
context of software engineering. For example, according to the unabridged dictionaries [52, 53],
the synonyms for the entries ‘maintenance’ or ‘maintain’ were ‘support’, ‘preserve’, ‘keep’, ‘sustain’,
and ‘assert’. But considering the context of software engineering, we chose only ‘support’ as an
alternative search keyword. On the other hand, according to our selected definition of maintenance
by IEEE [40], the maintenance implicitly refers to software ‘change’, ‘upgrade’, ‘update’,
‘modification’, or ‘adaptation’. After identification of the keywords, we tried them out in the
databases, and specific terms, such as ‘sustain’, ‘keep’, and ‘assert’, did return irrelevant hits from
other fields, hence, they have been discarded, while the terms ‘maintenance’, ‘change’, and ‘support’
were much better suited to point to maintenance-related ones. The keywords used to design the
search string are presented in Table III.
Alternative search terms for ‘global software development’ are offshore, outsource, or distributed
software development. As ERP is one of the major software products which require extensive
maintenance mostly with a collaboration of distributed teams [54], we also included the terms
‘enterprise resource planning’ or ‘ERP’ to gather the articles which may not be included on search
under other search terms.
Finally, the search string is formed using Boolean operators AND and OR to intersect or incorporate
the search results of different keywords. The search string combining the search terms is structured as
follows: (A1 OR A2 OR A3 OR A4 OR A5 OR A6 OR A7 OR A8 OR A9 OR A10) AND (B1 OR B2 OR
B3 OR B4 OR B5).
Table III. Main keywords used in the search string.

ID Search
A1 global software development

A2 global software engineering
A3 global software project
A4 distributed software development
A5 distributed software engineering
A6 distributed software project
A7 software offshore
A8 software outsource
A9 global enterprise resource planning software
A10 global enterprise resource planning (ERP) software
B1 maintenance
B2 maintain
B3 support
B4 change
B5 upgrade
DOI: 10.1002/smr
The databases used for the search were index databases (Compendex/Inspec, ISI Web of Science,
and Scopus) and publisher databases (IEEE xplore, Science Direct, ACM Digital Library, Springer
Link, and Wiley Inter Science). Then, specifically adjusted search strings were applied in each
database, and a total of 9050 articles were retrieved. The retrieval of the articles was performed in
November 2010.
Eight scientific publication libraries were queried, and a large number of studies were retrieved.
Formulation and tuning search strings were made with the help of the librarians of Blekinge Institute
of Technology to improve the reliability of the search.
3.1.1.2. Study selection. The literature selection criteria consist of inclusion and exclusion criteria.
Svahnberg et al. [55] used a basic and detailed inclusion/exclusion criterion. We adopted these double
criteria processes to select primary studies. Our basic inclusion/exclusion criteria were to select the
studies which were published in English language and no duplicates. We utilized each database’s
built-in option to limit results by publication languages. Furthermore, to remove the duplicates, we
exported all the citations of articles (including their abstract) from each library by help of Zotero‡ and
then imported them in database of EndNote§ desktop application and used its duplicate detector
function. When the duplicates or multiplications of same articles were found, we selected a later
version. After those basic selection criteria were applied, a total of 8254 articles were left.
The detailed inclusion criteria were as follows:
• The study is available for accessing in full text form
• The study was peer reviewed
• The study was published in a book, journal, conference, or technical report
• The study presents a research study
• The study mentions software maintenance within globally distributed settings
The detailed exclusion criteria were as follows:
• Article is related to only general software maintenance
• Article mentions only about issues encountered before establishing distributed software maintenance
work
• Article discusses distributed software maintenance work not in technical or managerial point
of views
After undergoing the selection criteria, the included primary studies were assessed against a quality
criteria defined as a checklist. The quality assessment criteria were as the following:
• Does the research paper clearly explain the research methods and details of data collection and
data analysis?
• Are validity threats of the study noted?
The answers to the questions were noted down using a 5-point measurement scale (very low, low,
fair, good, and very good). Based on the answers to all criteria, the studies were given a rank.
Following the aforementioned systematic review process, the number of studies included at different
stages of the review is shown in Table IV. From the 8254 articles, 392 articles were selected by
examining their titles. Studies were excluded based on title if they were clearly out of scope (e.g., it
is clear that they were not in software engineering, or they were clearly not related to maintenance).
An example where the relevance of the article is already clear from the title is ‘P11, an empirical
study of factors and their relationships in outsourced software maintenance’. In cases where there
was a doubt, the paper went to the next inclusion/exclusion stage and the abstract was read. By
reading the titles and abstracts of the remaining articles on the basis of the detailed
inclusion/exclusion criteria, 119 articles were included in full text evaluation. Through perusing
those articles in full text, finally, 44 articles were found to be the most relevant to be included in the
following data extraction step.
‡
Free and open-source add-on for Firefox web browser
§
Commercial reference management software package
DOI: 10.1002/smr
Table IV. Number of studies with respect to review stages.

Without After title After abstract After full
Databases Total duplicates review review review
Compendex/Inspec 2342 1564 163 28 11
IEEE Xplore 363 363 69 23 9
Science Direct 2248 2242 51 8 8
ACM Digital Library 913 909 26 14 5
ISI WOS 414 414 26 15 2
Springer Link 894 894 19 10 4
Wiley Inter Science 955 951 13 7 2
Scopus 921 917 25 14 3
Total 9050 8254 392 119 44
3.1.1.3. Data extraction. We designed a data collection form for extracting the relevant information
to this study from the selected primary studies. In the systematic review process, a pilot study is
necessary to assure consistent understanding and mutual agreement of the reviewers on the review
process before embarking on the complete extent of systematic review [48]. It helps to avoid the
potential bias and to mitigate the risk of following the inconsistent processes and concepts by the
reviewers. Therefore, first, we concurrently reviewed three papers, drafted the form based on
findings from those papers, and validated the drafted version of the extraction form to assure its
applicability for further use. The data were recorded using Google Survey for data extraction.
Whenever an uncertainty occurred, or there was a disagreement, it was instantly discussed/resolved
before recording the information in the final data record.
The extracted data were basically divided into general and specific information. The general
information of the articles was recorded as follows:
• Article title
• Authors
• Article type
• Published date
• Library source
Specific information of the articles is classified in empirical background and specific attributes as
described subsequently:
• Main empirical method
• Subject of study
• Empirical focus
• Maintenance collaboration mode
• Number of distributed sites
• Challenges highlighted
• Mitigation strategies or practices
• Validity threats
The next section presents how we performed the data collection during the interview study. After,
we discuss how we made the analysis in this study using the data collected during the SLR and the
interviews.
3.1.2. Interview study. The course of the interview was designed to follow the seven-stage interview
guideline by Kvale [49], where the interview investigation is routed through thematizing, designing,
interviewing, transcribing, analyzing, verifying, and reporting stages. The purpose of the interview
was to explore beyond the knowledge from the state of the art.
3.1.2.1. Interview design and conduct. We designed the qualitative interview in the semi-structured
way, where the closed-end questions were to be inquired and open-ended questions were to be
discussed. The literature review allowed us to conduct a more focused interview to add knowledge
to the results found in the SLR. We, for example, found that the use of COTS components was
DOI: 10.1002/smr
identified as a challenge, and we asked the interviewees whether they are using these, and what
challenges they face are related to them. Utilizing the SLR as an input to interviews allowed us to
obtain additional information to what has been found in the literature review. The complete
interview guide is shown in Appendix B.
We contacted prospective interviewees by email in advance and introduced the research. They were
provided with the purpose, design, and the expected outcome of the study in order to familiarize them
with the research. In total, we interviewed five persons working in five different companies. One
interview was conducted face-to-face while other interviews were conducted through the Internet
using Skype. According to [49], the interviewee should be provided with a briefing about the
context of the interview before interview. We did this by a brief introduction of interviewees,
purpose of the study, format of the questions to be asked, and asking interviewee’s permission to
use tape recorder for recording. At the end of the interview, we debriefed each interviewee with
possible outcome of the study and its potential benefits. Briefing interviewees at the start of
interviews helped in building communication.
Every interview was conducted by two authors of this study between January and February 2011. It
is suggested to conduct interviews by a group of two people, because it has several advantages such as
more follow-up questions, increased understanding of the subjects, time saving, and simultaneous
efficient work [56]. The role of one interviewer was to lead the interview, while another interviewer
was responsible for taking notes and asking additional questions. The length of each interview was
set to 1 h but extended in case the interviewee would like to continue.
We used two methods to record interviews: tape recording and taking notes. The first two authors
transcribed immediately after the completion of each interview individually and then consolidated
the results into one comprehensive transcript. The purpose of transcribing individually was to reduce
potential threats of conflicts in understanding. In case of ambiguous statements, the authors
discussed that statement and referred back to original question, notes, and audiotape for clarification.
3.1.2.2. Consent. Before the interview, the interviewees were also given a consent form, informing
them that the interview is voluntary, they may always stop the interview or refuse to answer, and
may decline that the interview is recorded. They were also informed about the intent to publish the
aggregated results. Informed consent is an agreement intended to assure that the individuals give the
consent to voluntary participation in research once they are informed of the activities involved and
risks associated with them [57]. According to the suggested ethical codes by IEEE and ACM
society, ‘Software engineering shall, in their professional role, act only in ways consistent with the
public safety, health, and welfare’. So as to comply with it, we obtained the participants’ consent
after informing of the consequences of the research. In particular, the informed consent helped to
appease participants’ worries about their presence in the interview and made them feel secure and
cooperative in the interview.
3.1.2.3. Interviewees. We used the purposeful sampling strategy [58] to select the interviewees.
Interviewees working in offshore insourcing and outsourcing were selected from large-scale
companies, where we were likely to find a rich set of challenges and solutions related to global
maintenance. Table V provides an overview of the interviewees’ experience. Table VI shows the
maintenance stakeholder distribution (vendor, supplier, and customer) and where the interviewees
are located in relation to them. Furthermore, the collaboration mode as introduced in Section 2 is
stated.
3.2. Data analysis

The data collected from the studies (systematic literature review and interviews) were both analyzed
using the GT method. The aim of the GT method is to arrive at a theory. Three types of theories are
highlighted by Wieringa and Daneva [24], namely, conceptual frameworks providing a set of
concepts explaining a phenomena, generalizations to determine to what degree findings apply for a
larger set of companies, and inference models. The outcome of this study is a conceptual
framework, explaining concepts related to challenges and solutions in managing global software
development.
DOI: 10.1002/smr
Table V. Interviewees.
ID Company Background
1 Ericsson AB: Ericsson is a large organization Interviewee 1 has 10 years of experience of

that provides telecommunication services and software development in global environment
solutions worldwide. Ericsson is ISO 9001:2000 and 2 years of experience in software
certified and has operations in more than 175 maintenance in UIQ and Ericsson. His team
countries that indicates its experience with global collaboratively maintained applications, as
software engineering. The interviewee from vendor, for messaging and email support in
Ericsson works in Karlskrona, Sweden. mobile phones.
2 IBM: International Business Machines Interviewee 2 has a working experience of
Corporation (IBM) provides IT services and 6 years out of which he has been working
products worldwide. IBM Pakistan implements in IBM Pakistan for the last 4 years. He is
and supports SAP systems (Systems Applications a certified ITIL professional and also an
and Products), works as an integrator, and is an AML (Anti Money Laundering) certified
implementation partner for Oracle, US. specialist. He is involved in maintenance
and support as supplier for the last 4 years.
3 Alcatel Lucent: Alcatel Lucent (ALU) is a Interviewee 3 from ALU works in Saint
large multinational organization with over Petersburg, Russia and has been working
70 thousand employees throughout the world. It as maintenance developer for almost
provides telecommunication products and services. 10 years. He is involved in maintenance
ALU is an ISO 9001 and TL 9000 certified and support, as a supplier, for
company that develops and maintains innovative telecommunication systems sold to
applications, telecommunication, and software customers in post-Soviet countries.
products worldwide.
4 Alcatel Lucent (ALU) is a large multinational Interviewee 4 has been working with
organization with over 70 thousand employees software engineering since 2001. He
throughout the world. It provides worked in Alcatel Lucent until 2010 and
telecommunication products and services. ALU is was involved in maintenance. He was
an ISO 9001 and TL 9000 certified company that working from Moscow, Russia to support
develops and maintains innovative applications, maintenance of telecommunication
telecommunication and software products worldwide. systems sold in Scandinavian countries
as a supplier. Besides software
maintenance experience, he has worked
as system analyst.
5 Horizon Medical World (HMW): Horizon Medical Interviewee 5 has worked for 3 years
World (HMW) is relatively a small company as in HMW and involved in maintenance
compared with other participant organizations. HMW and support for last 2 years. He is
develops, maintains and provides services to maintaining a product Electronic
customers for many medical related products. Medical Record (EMR), which provides
HMW has operations in USA, Australia, customers with different functions like
Malaysia, and Pakistan. The products and services scheduling, documenting and billing
include Electronic Medical in health organizations. Interviewee
Record (EMR), billing transcription, and accounting 5 is involved in maintenance as
management systems. a supplier.
Grounded theory begins with open coding and followed by axial and selective coding. Open coding
is an initial coding process in which codes are provisional and best grounded in the data. Those codes
were selected to have as much as close meaning to the raw data so that further coding processes can
openly exploit them [50]. In axial coding, the open codes are interrelated and linked to each other to
construct a conceptual structure which can explain the phenomena more precisely and completely [26].
Subsequently, selective coding process applies to integrate the concepts to build more general
categories to explain theory about a phenomenon and to validate the concept relationships by
comparing with the raw data and refine the relationship if necessary [26].
Concrete samples of coding process are exemplified in two slightly different forms of data of the
systematic literature review and the interviews.
Two pieces of data were extracted from the literature, namely, X and Y.
• Data X: ‘… In the era of global outsourcing, maintenance and enhancement activities are per-
formed in distributed locations. In most cases, the domain expertise is not available which
DOI: 10.1002/smr
Table VI. Summary of organizations.

Collaboration
Companies Vendor (R&D) Supplier Customer mode
Ericsson AB Ericsson and UIQ Ericsson in China, Mobile phone Offshore
Technology, Sweden India, Poland, Russia manufacturers, insourcing
(Interviewee 1) and the UK Scandinavian countries
IBM Oracle, USA IBM in Pakistan and Banks and Financial Offshore
the USA (Interviewee 2) organizations in Pakistan outsourcing
Alcatel-Lucent ALU, Belgium ALU in Russia Mobile operators in Offshore
(Interviewee 3 & 4) post-Soviet countries insourcing
Horizon HMW, USA HMW in Australia, Health organizations in Offshore
Medical World Pakistan, and the USA Australia, Malaysia, and insourcing
(Interviewee 5) the USA
increases the complexity to manifold. A critical success factor in such a scenario is to have a col-
laborative platform for managing and sharing the domain specific knowledge across distributed
locations…’ [59].
• Data Y: ‘… if maintenance personnel has prior development experience, it becomes good advan-
tage for him to work successfully in maintenance activities …’.
The data X is an excerpt extracted from literature as it was written. From this excerpt, it can be
inferred that a lack of the personnel with domain knowledge creates a challenging situation for a
distributed maintenance team. Based on this inference, we coded it as a challenge ‘A lack of domain
expertise’. The data Y is a note taken from several articles. From this note, one may deduce that
poor technical and software development knowledge can be a barricade for effectiveness of
maintenance task resolution. We coded it ‘Poor technical and development skill’. Furthermore, those
two challenges were grouped into more general concept ‘Technical Knowledge’. This concept was
again grouped to general category ‘People’, because knowledge is epistemologically explained as
people’s properties according to Sosa [60] and Greco [61].
On the other hand, from excerpt 1, it can be drawn that creating a collaborative system for
knowledge sharing can be adopted to fill the gap of domain knowledge in a distributed team. Thus,
we identified it as a strategy ‘Collaborative knowledge sharing system’. This strategy was grouped
into more general concept ‘Knowledge Management’, which was classified to category ‘Process’
because knowledge management is a process of systematically collecting, organizing, and sharing
experiences and practices of individuals or groups within an organization [39].
Similarly, the interview data were analyzed using GT. An example is given subsequently.
• Interview transcript 1: ‘Some teams were very good in communication because English was
their first language while others were not.’
• Interview transcript 2: ‘I face difficulties in understanding what others are trying to say. This
happens very frequently in email correspondence.’
Both excerpts from the two interview transcripts, mentioned earlier, discuss challenges associated
with communication. Interviewee 1 discussed a challenge in communication due to differences in
language, so we coded this as ‘language difference’. In the second case, an interviewee discussed
the same challenge, that is, ‘language difference’, but he also mentioned a mode in which it creates
a problem, which is ‘email’. Therefore, we coded this as ‘ambiguities in email correspondence’.
This code was then added to a more generalized code ‘written communication’. Then, both these
codes were grouped into a concept ‘language difference’. Finally, this concept was added to
‘People’ category.
The results of GT coding for the SLR and the interviews are shown in Table VII.
3.3. Validity threats

Validity threats may affect the reliability of the results; the relevant threats are discussed here.
DOI: 10.1002/smr
Table VII. Results of grounded theory coding.

Coding stage Number of codes (literature) Number of codes (interviews)
Open coding 134 79

Axial coding 38 35
Selective coding 4 4
3.3.1. Data collection in SLR. The aim of the systematic literature review is to find as many empirical
studies as possible, which are relevant to the context of the target topic. The following open threats
may affect the conclusions of the study:
• Exclusion of gray literature: Exclusion of gray literature may lead us to miss some interesting findings.
• Inclusion of articles until the end of 2010: We did not include gray literature. Furthermore, we
included studies up till the end of 2010, which formed the basis for our interviews conducted in
2011. Hence, 3 years were missed. We contemplated on whether to include the remaining years;
however, this would prolong the study further given that the qualitative analysis using GT is
very time consuming, leading to missing papers of the coming years. Furthermore, a high num-
ber of relevant studies have been included, and interviews have been conducted complementary.
Even though this does not mitigate the threat, it is reduced.
• Missing search terms: There is a risk that relevant search terms have been missed. What adds
confidence to the sample of articles obtained is that studies in the context of all maintenance ac-
tivities (corrective, adaptive, perfective, preventive, and emergency) have been identified. This
indicates that the search was not biased.
• Risk of bias in extraction: To avoid potential threat of researcher bias and consequently selecting
irrelevant data, we used a data extraction form. Both authors based on their mutual consensus
developed the data extraction form. We used this data extraction form during the piloting of
the systematic literature review. The results of both authors were discussed in terms of consis-
tency, and changes were made to the data extraction form. Finally, the updated data extraction
form was used to extract data from selected primary studies in order to overcome this threat.
However, a risk of bias in extraction remains, and consistency was not measured over the whole
set extracted. Thus, bias is a confounding factor.
3.3.2. Data collection in interviews. Threats relevant to the study, but reduced through control
actions, were the following:
• Selection of interviewees: Another threat related to interviewee selection was that some of the
interviewees were colleagues of the authors who were working together in enterprise software
maintenance projects. Thus, it was easier to access and obtain consent from them because of
close contact. Although, at the same time, they fulfilled the purposeful sampling criterion as they
provided were working in a context highly relevant for this study.
• Misunderstandings: During the data collection, another threat could be misunderstanding the in-
formation extracted during the interviews. In order to minimize this threat, we transcribed each
interview and sent the transcripts to respective interviewees for validation. Moreover, each inter-
view was recorded for avoiding any loss of information.
• Privacy: Collecting limited information due to company privacy was another threat. The right of
disclosing organizational processes and knowledge associated with every day business pro-
cesses lie with organization. For overcoming this risk, we obtained their formal consent in which
we assured the confidentiality of the information.
• Generalizability: Another potential threat was validity of the interview population for generaliz-
ability. We conducted interviews with people from different geographical locations that are
Asia, Europe, and the USA. The idea was to gather feedback from industrial practitioners with
different backgrounds, cultures, and organizational structures. This can support the generaliza-
tion of the results. However, the number of interviews was limited, although very deep and de-
tailed information was gathered. The threat is reduced as the interviews were analyzed together
with the information obtained from literature.
DOI: 10.1002/smr
The following threats are open threats affecting the interviews:

• Completeness of feedback: The differences in roles, responsibilities, organizational culture, and
nature of contract may pose a threat on the feedback from interviewees.
• Lack of customer maintenance personnel: Another potential threat can be the fact that we
interviewed from either software vendors or suppliers, but did not included customer mainte-
nance personnel who are involved on behalf of customer organization.
3.3.3. Data analysis in SLR and interviews. For data analysis, we used the same method during the
SLR and interviews. A major threat to validity during the analysis of data concerns with whether the
inferences follow from the data and not biased by the researchers during the analysis. This requires
analysis methods that have a systematic approach, that is, if another researcher later on conducts the
same study using the same data, the results should be the same. Therefore, we used Strauss’ variant
of GT. This method involves three levels of coding on data because it provides clearly structured
procedures [62] which are more understandable, whereas Glaser paradigm is less structured and
more theoretically sensitive [63]. However, Strauss’s divergence of GT bears a threat of force by
adhering fixed coding procedures which can limit emergence of theory [64].
4. RESULTS
We first present an overview of the context of the literature and the research methods used by the
studies. Thereafter, we discuss the challenges and solutions identified. After having provided the
structure of challenges and solutions, they are mapped to each other. The results only include
the findings specific to managing global software maintenance. The complete set of challenges
and solutions can be obtained from the complementary material provided with this article on
the publisher’s website.
4.1. Overview of the literature

4.1.1. Context of studies. The distribution of studies with regard to different maintenance activities is
shown in Table VIII. It is visible that corrective and perfective maintenance have the highest coverage,
while fewer studies investigated adaptive, preventive, and emergency maintenance. A number of
studies did not specify the specific maintenance activity, rather, they report on maintenance in
general. It is also noteworthy that studies provided a single solution covering multiple dimensions of
maintenance, in particular, corrective and perfective maintenance were treated together (e.g., [P2,
P9, P11, P12]), which indicates that findings in the scope of this study apply to multiple
maintenance activities.
Collaboration modes of distributed maintenance are shown in Table IX. Outsourced maintenance
(inter-organizational) was greater in number than insourced maintenance (intra-organizational). It
was due to the fact that insourced maintenance requires much higher investment to build up remote
sites and few bigger organizations are financially capable for that, whereas outsourced maintenance
is established on contractual base between vendor and supplier sides [65, 66]. Due to this better
Table VIII. Distribution of articles with regard to maintenance activities.

Maintenance activities References to studies
Corrective [P1, P2, P3, P4, P9, P11, P12, P15, P16, P19, P21, P23, P24, P25, P26, P27,
P28, P29, P31, P32, P33, P37, P39, P41, P43]
Adaptive [P2, P26, P29, P37]
Perfective [P2, P9, P11, P12, P23, P25, P26, P27, P28, P29, P31, P36, P37, P42, P43]
Preventive [P11, P25, P29, P37]
Emergency [P19, P24, P29, P38]
General [P5, P6, P7, P8, P10, P13, P14, P18, P20, P22, P30, P34, P35, P40, P44]
DOI: 10.1002/smr
Table IX. Distribution of articles with regard to maintenance activities.

Mode of collaboration References to studies
Intra [P4, P5, P11, P13, P18, P19, P20, P21, P23, P24, P25, P28, P32, P33, P39]
Inter [P1, P2, P3, P7, P9, P10, P12, P15, P22, P26, P29, P30, P31, P34, P37, P40, P41, P43]
Unclear [P6, P8, P16, P17, P27, P35, P38, P42, P44]
possibility, the outsourced maintenance mode was more commonly discussed in the selected primary
studies than insourced maintenance.
4.1.2. Research methods and study quality. The methods used in the studies identified are shown in
Table X. It is visible that the majority of studies utilized case study research. The research context of
the 35 selected studies was in industry, 5 in academia, and 4 did not mention the contextual
information either explicitly or implicitly. A few studies proposed conceptual frameworks and
evaluated them by classifying existing literature.
Based on the quality assessment criterion defined in Section 3, the primary studies were assessed in
terms of quality. The results of the quality assessment are presented to illustrate the level of trust that
we can put into the results, which will affect the reliability of the conceptual framework presented in
this study. The summary of the quality assessment is presented in Figure 1. It shows that three-
fourth of the selected studies were ‘Fair’ or above in quality.
4.2. Challenges
Through qualitative analysis, we observed that challenges and strategies in global software
maintenance are being influenced by some factors with common patterns. Those patterns are
synthesized in major categories considering main entities of software projects: people, process,
product and technology (3PT), which emerged from the data analysis. The categories are defined as
follows:
Table X. Research methods used.
Methods References to studies

Experiment [P1, P4, P5, P10, P11, P12]
Case Study [P2, P3, P7, P8, P15, P16, P18, P21, P22, P23, P28,
P29, P30, P31, P32, P33, P34, P39, P40, P41, P42, P43]
Prototyping [P6,P36]
Experience report [P9, P13, P27, P35]
Framework proposal and classification of literature [P14, P17, P20, P38]
Survey/interview [P7, P19, P25, P26, P37, P44]
Project postmortem [P24]
12
12 11
10
10
8
6
6 5
0
Very good Good Fair Low Very low
Figure 1. Quality assessment.
DOI: 10.1002/smr
Table XI. Challenges (selective code – people).

Axial code Open code SLR Interview
Personal attitude Degraded perception about maintenance [P1] √ ●

Neglected value of documentation [P2,P3] √ √
Unwillingness to travel [P4,P5,P6,P7] √ ●
Neglecting value of maintenance ● √
Conflicting interests Transient change requests ● √
Customers’ resistance to update ● √
Interpersonal skill Low morale of a team [P11] √ ●
Language differences Difficulty in understanding the exact context of emails ● √
Staffing Unavailability of domain expert [P10,P20] √ ●
Lack of on-site testing staff [P23,P24] √ ●
Many different teams’ involvement in few tasks [P7,P9,P23,P25] √ ●
●, not found in source; √, found in source; SLR, systematic literature review.
• People: fundamental element operating and maintaining a product. We placed human-related

factors such as professional skills and experience in this category. Also, personal abilities and
behavioral issues are comprised as well.
• Process: a course of activities followed by peoples’ intention to produce a desired outcome. In
this category, we covered activities involved in project management and software maintenance.
• Product: an outcome of a set of processes. Here, product means software system which is being
maintained. Product factors are characteristics of the system.
• Technology: By technology, we mean software or hardware tool which sustains or improves ef-
ficiency of people, process, and product.
Several researchers explained issues of software project management from people, process, and
product perspectives [67–69]. But, technology factors should be separately taken into consideration,
because it has a significant influence on effectiveness of project management and routine
maintenance activities. Therefore, a maintenance project manager should focus on technological
factors equally with people, process, and product factors.
We elaborate on the identified challenges and their structure in relation to these four categories. Thereby,
we focus on these aspects that are specific or amplified in the context of global software maintenance.
As will be noticed in the following sections, there is a high amount of challenges that are not only
specific to global software maintenance; insights about these challenges and their relations can be
obtained from [34–37]. Hence, in the scope of this study, we only discuss challenges and mitigation
strategies of software maintenance in globally distributed contexts.¶
4.2.1. People factor. Table XI illustrates the structure of challenges related to the people factor based
on the SLR and interviews. Only 11 of 37 challenges are more strongly related to maintenance work in
particular, that is, 26 challenges were generic and also found in [34–37]. Within the categories of
cultural differences, trust, staff turnover, and technical knowledge, no codes unique to maintenance
were identified. As is visible from the table, five new challenges related to the people factor were
identified in the interviews, while only one challenge was found in both sources of data. It is also
apparent that many challenges are related to a negative attitude towards maintenance and
documentation.
4.2.2. Process factor. Challenges by process factors are conceptualized into major project
management processes such as change management, quality management, communication
management, scope management, knowledge management, and risk management. Table XII
provides an overview of the challenges associated with the process factors. Six categories of
¶
The complementary material also presents the findings not specific to maintenance, as those challenges will also be rel-
evant in decision making from a practical point of view
DOI: 10.1002/smr
Table XII. Challenges (selective code – process).

Change management Poor impact analysis of change request ● √

Large number of CRs ● √
Volatile change requests ● √
Unclear change request [P2, P18, P20, P23] √ ●
Unclear issue report [P3] √ ●
Poor change request management [P27] √ ●
Quality management Lack of regression test suites [P11] √ ●
Lack of quality assurance procedures in maintenance √ ●
process [P16]
Lack of check on hardware [P23] √ ●
Integration problems ● √
Infrequent testing before deploying patches ● √
Much effort due to double test and inspection work ● √
Inconsistent metrics between organizations [P16] √ ●
No documentation standard [P19,P30] √ ●
No coding standard [P9,P19] √ ●
No uniform design pattern [P19,P31] √ ●
Communication management Limited view and involvement of customer during software √ ●
change [P2]
No contact with an original developer [P10] √ ●
Scope management Unclear task distribution [P28] √ ●
Wrong task distribution [P15,P22,P32] √ ●
Lack of task control [P7,P10,P28] √ ●
Overhead on task control [P15,P32] √ ●
High work pressure [P11,P19] √ ●
Prolonged working hours due to emergency maintenance ● √
Unavailability of personal in case of emergency ● √
Knowledge management Lack of documentation for design and source code √ ●
[P1,P2,P9,P10,P11]
Tacit knowledge of technical domain [P9,P10] √ ●
Tacit knowledge of business domain [P9,P10] √ ●
Lack of knowledge repository [P11,P35] √ ●
Limited time to learn [P10,P11] √ ●
Risk management Lack of impact analysis [P36] √ ●
Ignorance of keep up with update of third party solutions [P23] √ ●
Unexpectedness in emergency maintenance [P38] √ ●
Disclosure of data security during transfer [P24] √ ●
challenges were identified, namely, change management, quality management, communication

management, scope management, knowledge management, and risk management. The clear majority
of challenges is only reported in the literature and not that much emphasized in the interviews.
4.2.3. Product factor. Challenges by product factors are conceptualized into major areas as software
size and complexity, and third-party dependency (Table XIII).
4.2.4. Technology factor. Challenges by technology factors are conceptualized into major areas such
as hardware support, software support, and testing environment (Table XIV).
4.3. Solutions
Similar to the challenges, based on the structure of 3PT derived through the application of grounded
theory, we present the inventory of solutions.
4.3.1. People factor. Table XV provides an overview of the identified solutions. The solutions were
primarily obtained from the literature, with only one solution being added through interviews. Social
DOI: 10.1002/smr
Table XIII. Challenges (selective code – product).

Third-party independence Use of COTS components [P13,P40] √ ●

Frequent updates in technologies used in development [P34] √ ●
Vulnerability of business confidential information disclosure ● √
Changes in third party components ● √
Software size and complexity A number of change requests [P36] √ ●
Complex change request [P15] √ ●
A need for extensive documentation [P15,P40] √ ●
●, not found in source; √, found in source; SLR, systematic literature review; COTS, commercial off-the-shelf.
Table XIV. Challenges (selective code – technology).

Hardware support Unqualified hardware environment [P42] √ ●
Software failures due to inadequate/faulty hardware ● √
Software support Lack of supporting tools [P21,P7] √ ●
Testing environment Limitation on reproducing anomalous scenario [P19,P23] √ ●
Difference between development and production environment [P19] √ ●
Table XV. Solutions (selective code – people).

Customer involvement Increase customer involvement in perfective maintenance [P2] √ ●
Involving customers into test case specification to explore √ ●
new bugs [P23]
Social enrichment Proactive in communicating with colleagues ● √
Staffing Building a small team to be effective [P9] √ ●
Deploying a cross-functional support team with software √ ●
and hardware knowledge [P39]
Having at least one skilled person help to share knowledge [P22] √ ●
Having an on-site representative with knowledge of different √ ●
technical specialists [P43]
Involving job exchange between maintainer and developer [P11] √ ●
Staffing remote site helpdesk as much as a native speaker [P43] √ ●
aspects were emphasized with respect to customer interaction, social enrichment, and the facilitation of
social interaction through staffing-related actions.
4.3.2. Process factor. With regard to processes, the highest number of solution proposals was
identified. In total, we identified 54 proposals, of which 33 were identified as specific or amplified in
the maintenance context. Six categories of solutions have been identified, namely, quality
management, scope management, change management, communication management, and risk
management (Table XVI).
4.3.3. Product factor. The solutions for the product factor are stated in Table XVII. The solutions
related to the product dimension highlight the need for documentation of different kinds. Also, clear
service level agreements and contractual concerns in the form of non-disclosure agreements should
be considered.
4.3.4. Technology factor. Two categories were identified for the technology factor, namely,
automation, and communication and collaboration. Automation was emphasized for global
maintenance, with five solution proposals of what to automate (Table XVIII).
DOI: 10.1002/smr
Table XVI. Solutions (selective code – process).

Quality management Having shared or same testing system environment in all sites [P19] √ ●
Introducing gate review and process metrics [P39] √ ●
Automating test cases [P23] √ ●
Peer review on code inspection ● √
Rigorous testing of patches ● √
Use of customer acceptance testing ● √
Double-check on testing and inspection by different members ● √
Developers and testers working together ● √
Adhering to best practices and standards [P43] √ ●
Focus on higher maintainable design from early on ● √
Defining success and failure of maintenance in the presence √ ●
of all stakeholders [P8]
Measuring quality of maintenance process [P16] √ ●
Scope management Assigning a certain software module to a certain staff for √ ●
any change [P39]
Keeping related tasks in a single site [P10] √ ●
Keeping a balance between task specialization and task √ ●
diversity [P22]
Exposing new staff to task variety for effective √ ●
learning [P22,P24]
Task distribution based on team specialization ● √
Task distribution based on ITIL and COBIT standards ● √
Personnel assigned to specific versions of the product ● √
Change management Having central management of change requests [P30,P39,P43] √ ●
Software reliability metrics on source code touched [P39] √ ●
Defined processes for sending a change request ● √
Analyzing change requests on regular basis ● √
Communication Introducing malign lists [P23] √ ●
management
Building virtual customers community (forum) [P2] √ ●
Providing remote support possibility through a mobile terminal √ ●
or agent [P4,P5,P6]
Meeting minutes to support conferencing ● √
Single point of communication in teams ● √
Priority based communication methods ● √
Risk management Considering nationals specific dates in plan [P8,P24] √ ●
Planning emergency maintenance procedure earlier [P19] √ ●
Having a risk checklist [P37] √ ●
Serving notice prior to leaving job ● √
4.4. Mapping of challenges and solutions

After presenting the inventory of challenges and solutions, we mapped the solutions to the challenges.
This was performed based on the data and our own interpretation. We indicate whether the linkage was
performed based on interpretation (i.e., across different sources, such as different articles) or whether
there was an explicit link (challenge and related solution come from the same source). It was
apparent that only few solutions were explicitly linked to challenges. As the linkage in most cases
was performed based on interpretation, the results of this section could be interpreted as propositions
to be evaluated. They may be incomplete or proven wrong in the course of further empirical
investigations.
4.4.1. People factor. The solutions in relation to the people factor challenges are shown in
Table XIX. Five challenges remain unaddressable in the literature related to global software
maintenance. Two challenges (unwillingness to travel) could be addressed through good leadership,
although it is not clear how good leadership may be generalized, and what it may mean in different
contexts.
DOI: 10.1002/smr
Table XVII. Solutions (selective code – product).

Axial Code Open Code SLR Interview
Documentation Preparing documentation in different languages [P3] √ ●

Having clear guidelines and manuals for all maintenance processes [P8] √ √
Contractually agreeing on NDA ● √
Up to date documentation about in third party components used ● √
Documentation of any changes design and coding ● √
Clear document of SLA ● √
●, not found in source; √, found in source; SLR, systematic literature review; SLA, service level agreements.
Table XVIII. Solutions (selective code – technology).

Axial Code Open Code SLR Interview
Automation Automatizing manual routine tasks [P9,P21,P39] √ ●
Detecting automatizable tasks [P9,P21,P43] √ ●
Developing automatic update tool to save cost [P36] √ ●
Using technology to automate tasks [P9,P10] √ ●
Mix of manual and automated testing ● √
Table XIX. Mapping of challenges to solutions (selective code – people).

Challenges Solutions SLR Interview
Personal attitude
Degraded perception about maintenance [P1] ● ● ●
Neglected value of documentation [P2,P3] Having clear guidelines and manuals √ √
for all maintenance processes [P8]
Unwillingness to travel [P4,P5,P6,P7] Highly motivated team members by √ ●
good leadership [P9,P39]
Neglecting value of maintenance ● ● ●
Conflicting interests
Transient change requests ● ● ●
Customers’ resistance to update ● ● ●
Interpersonal skill
Low morale of a team [P11] Highly motivated team members by √ ●
good leadership [P9,P39]
Language differences
Difficulty in understanding the exact ● ● ●
context of emails
Staffing
Unavailability of domain expert [P10,P20] Deploying a cross-functional support √ ●
team with software and hardware
knowledge [P39]
Having at least one skilled person √ ●
help to share knowledge [P22]
Wiki based collaborative platform √ ●
for managing and sharing domain
knowledge [P9,P10,P24,P30]
Lack of on-site testing staff [P23,P24] Having an on-site representative √ ●
with knowledge of different technical
specialists [P43]
Many different teams’ involvement in Task distribution based on team ● √
few tasks [P7,P9,P23,P25] specialization
Task distribution based on ITIL and ● √
COBIT standards
●, not found in source; √, found in source; SLR, systematic literature review; ITIL, Information Technology In-
frastructure Library; COBIT, Control Objectives for Information and related Technology.
DOI: 10.1002/smr
To increase the value of documentation our proposition is that clear guidelines and manuals [P8] are
needed to motivate why and what to document. Another concern is the unwillingness to travel, which
we believe should not be enforced, but rather, the team members need to be motivated to have an
increased commitment, which requires good leadership [P9, P39]. This is also important to address
the concern of low morale of a team.
Multiple proposals may help in addressing the lack of domain knowledge and skill (e.g., in the area
of testing). This includes the use of cross-functional teams [P39], which may not always be possible.
An alternative could be to have at least one skilled person to share knowledge [P22]. Wiki-based
collaboration platforms also help in sharing knowledge [P9, P10, P24, P30]. To cope with the
challenge of unavailability of domain experts in maintenance teams, different alternatives of
solutions were proposed. Also, multiple solutions are proposed to deal with the challenge of having
too many teams involved in a few tasks. One solution requires additional explanation (task
distribution based on ITIL and COBIT standards). Information Technology Infrastructure Library
(ITIL) is a comprehensive and publicly available standard that discusses best practices in
information and technology service management [70]. Control Objectives for Information and
related Technology (COBIT) is also a framework for assisting managers and information technology
users for Information Technology management [71].
4.4.2. Process factor. The solutions in relation to the process factor are shown in Table XX.
Abstracting from the detailed recommendations for the challenges, the general recommendations are
to define processes and centralize management, to follow standards and agree on defined
measurements for the maintenance process, and to assure training and competence development.
In regard to change management, a stability metric can be adopted for change management process
to use it for assessing impact of change and estimating effort [P39]. It can be based on size of source
files updated and size of source code changed. Well-defined processes and central management may
assure that a defined process should be set for sending change requests. It is about restricting
customers for sending informal Change Request (CR). Change requests should be stored so that
different results could be inferred from the trends on incoming change requests.
To address challenges of quality management, it is important to introduce testing routines. Many
challenges articulated can be related to that (e.g., lack of regression testing, integration problems,
and double effort spent on quality assurance). Rigorous customer acceptance testing should be
performed to avoid rework. The gate review technique can be adopted on maintenance processes. It
can help to iteratively ensure whether quality of current maintenance process meets the defined
criteria and identifies anomalous process earlier [P39]. It is crucial to automate as many tasks as
possible in order to save cost, because most of maintenance tasks are more repetitive than software
development tasks. Many of maintenance tasks can be automated such as impact analysis, regression
testing, change management processes, and self-updating features [P9, P21, P36]. A maintenance
team always should try to detect tasks possible to automate and assess the risk and feasibility [P21,
P43]. Further challenges are inconsistent metrics, the lack of documentation, and the lack of
standards. That is, it is important to define clear boundaries of success and failure of maintenance
service, its quality measures, roles, and responsibility in the service level agreement before
implementing a system. A project manager should ensure that each distributed site adheres to
collaborative best practices and same quality standards which help to avoid misunderstanding and
increase team dynamics [P7, P23–P24, P49]. This includes, for example, quality assurance
standards, the same coding and documenting pattern for software change, identical environment for
development and testing, and consistent hardware tools [P9, P19].
Communication management challenges were related to lack of customer involvement and the lack
of contact of customers to the developers. In perfective maintenance where functionality addition and
adjustment in software are made, higher customer involvement eases the requirement elicitation,
specification, and design process [P2]. Also for corrective maintenance, this was highlighted as
important. Customer involvement in corrective maintenance activities and test case specification
may improve the defect-detection rate of testing processes in acceptance and regression testing [P23].
Unclear and wrong task distributions have been highlighted as challenges, including lack or
overhead in task control. Two strategies have been suggested related to managing task distribution,
DOI: 10.1002/smr
Table XX. Mapping of challenges to solutions (selective code – process).

Change management
Poor impact analysis of Software stability metrics on source code √ ●
change request touched [P39]
Large number of CRs ● ● ●
Volatile change requests ● ● ●
Unclear change request [P2, P18, Defined processes for sending a change request ● √
P20, P23]
Unclear issue report [P3] Defined processes for sending a change request ● √
Poor change request Having central management of change √ ●
management [P27] requests [P30,P39,P43]
Quality management
Lack of regression test suites [P11] Use of customer acceptance testing ● √
Lack of quality assurance procedures Introducing gate review and process metrics [P30] √ ●
in maintenance process [P16]
Lack of check on hardware [P23] ● ● ●
Integration problems Developers and testers working together ● √
Infrequent testing before deploying Developers and testers working together ● √
patches
Much effort due to double test/ Automating test cases [P23] √ ●
inspection work
Automatizing manual routine tasks [P9,P21,P39] √ ●
Using technology to automate tasks [P9,P10] √ ●
Inconsistent metrics between Defining success and failure of maintenance √ ●
organizations [P16] in the presence of all stakeholders [P8]
Measuring quality of maintenance process [P16] √ ●
Realistic measure of progress giving unbiased √ ●
unambiguous visibility on their progress [P9]
Clear document of SLA ● √
No documentation Focusing on standardization [P7,P23,P24,P44] √ ●
standard [P19,P30]
No coding standard [P9,P19] Adhering to best practices and standards [P43] √ ●
Using consistent processes and tools in all √ ●
sites [P9,P19,P21]
No uniform design Focusing on standardization [P7,P23,P24,P44] √ ●
pattern [P19,P31]
Focus on higher maintainable design from early on ● √
Communication management
Limited view and involvement Increasing customer involvement in perfective √ ●
of customer during software maintenance [P2]
change [P2]
No contact with an original Involving customers into test case specification √ ●
developer [P10] to explore new bugs [P23]
Scope management
Unclear task distribution [P28] Assigning a certain software module to a certain √ ●
staff for any change [P39]
Using web-based workflow management software ● √
Wrong task distribution Keeping a balance between task specialization √ ●
[P15,P22,P32] and task diversity [P22]
Using web-based workflow management √ ●
software [P28]
Lack of task control [P7,P10,P28] Using web-based workflow management √ ●
software [P28]
Overhead on task control [P15,P32] Using web-based workflow management √ ●
software [P28]
High work pressure [P11,P19] Having problem management [P43] √ ●
Planning emergency maintenance procedure √ ●
earlier [P19]
Prolonged working hours ● ● ●
due to emergency maintenance
Continues
DOI: 10.1002/smr
Table XX. Continued

Unavailability of personal in Planning emergency maintenance procedure √ ●

case of emergency earlier [P19]
Knowledge management
Lack of documentation for design Having clear guidelines and manuals for √ √
and source code all maintenance processes [P8]
[P1,P2,P9,P10,P11]
Tacit knowledge of technical and Formal training or informal knowledge √ √
business domain [P9,P10] exchange activities [P11,P43]
Regular on-site visit [P19,P23] √ ●
Lack of knowledge repository Wiki based collaborative platform for √ ●
[P11,P35] managing and sharing domain knowledge
[P9,P10,P24,P39]
Limited time to learn [P10,P11] Formal training or informal knowledge √ √
exchange activities [P11,P43]
Mentoring system for staff entry to a √ ●
project [P22]
Risk management
Lack of impact analysis [P36] Focus on higher maintainable design from ● √
early on
Ignorance of keep up with Up to date documentation about third party ● √
update of third party components used
solutions [P23]
Unexpectedness in emergency Providing remote support possibility √ ●
maintenance [P38] through a mobile terminal or agent [P4,P5,P6]
Planning emergency maintenance procedure √ ●
earlier [P19]
Disclosure of data security ● ● ●
during transfer [P24]
namely, having a stable assignment of software modules for software changes [P39] and having a
balance between task specialization and diversity [P22]. Furthermore, the use of web-based
workflow management software was suggested to facilitate task control. Another important aspect is
good planning and problem management, which may reduce work pressure and also assures the
availability of resources in case of emergency maintenance.
Knowledge management challenges are lack of documentation, tacit knowledge, and the lack of
knowledge repositories and time to learn. These challenges may be addressed through Wiki-based
collaboration platforms [P9, P10, P24, P39], formal training and informal knowledge exchange
activities [P11, P43], and a mentoring system [P22].
Multiple risk factors are important in maintenance, in particular, impact analysis, evolution of third-
party components, and unexpected emergency maintenance. Impact analysis could be supported
through maintainable designs. A product that is designed in modules with less coupling and high
cohesion is easier to maintain. Due to the temporal distance, support personnel cannot be available
in the office at the same time as when a customer is in need for an emergent request or critical
problem solution. For such cases, business critical applications can lose the vast amount of profit in
a matter of minutes. To mitigate this impact, remote support personnel should be provided with
mobile communication possibility to access to system network from outside of the office [P4–P6].
4.4.3. Product factor. The mapping of solutions to challenges in relation to the product factor is
shown in Table XXI. The table shows that the challenge of third-party independence is mainly
addressed through being aware of the status of external components through up-to-date
documentation. To avoid leakage of confidential business information, a contractually agreed non-
disclosure agreement could be signed. Some documentation and information about the system could
be obtained in an automated way [P9,P21,P39].
DOI: 10.1002/smr
Table XXI. Mapping of challenges to solutions (selective code – product).

Third-party independence
Use of COTS components [P13,P40] Up to date documentation about third party ● √
components used
Frequent updates in technologies Up to date documentation about third party ● √
used in development [P34] components used
Vulnerability of business confidential Contractually agreeing on NDA ● √
information disclosure
Changes in third-party components Up to date documentation about third party ● √
components used
Software size and complexity
A number of change requests [P36] ● ● ●
Complex change request [P15] ● ● ●
A need for extensive documentation Automatizing manual routine tasks [P9,P21,P39] √ ●
[P15,P40]
●,not found in source; √, found in source; SLR, systematic literature review; COBIT, Control Objectives for In-
formation and related Technology.
4.4.4. Technology factor. The mapping of challenges to solutions in relation to the technology factor
is shown in Table XXII. To address unqualified hardware environments, standardization [P7,P23,P24,
P44] may help to clarify what is required. Also, the same environment for testing should be shared to
avoid difference between development and production environments (cf. [P19]). It was acknowledged
that supporting tools are missing, even though some solutions are present [P9, P10].
5. DISCUSSION
The outcome of our study is a conceptual framework categorizing challenges and solutions of global
software maintenance.
5.1. RQ1: What are the challenges of managing software maintenance in globally distributed settings?
We classified the challenges into people, process, product, and technology factors, which we called
3PT factors. Challenges with respect to people factors are already well covered by the general GSE
literature. These include challenges focusing on cultural differences, trust, language differences,
turnover of project members, and technical knowledge. Relatively, more maintenance-specific
challenges have been obtained for the remaining factors. For processes, the specific
factors are related to change management (e.g., poor impact analysis), quality management
Table XXII. Mapping of challenges to solutions (selective code – technology).

Hardware support
Unqualified hardware environment [P42] Focusing on standardization [P7,P23,P24,P44] √ ●
Software failures due to inadequate/ ● ● ●
faulty hardware
Software support
Lack of supporting tools [P7,P21] Using technology to automate tasks [P9,P10] √ ●
Testing environment
Limitation on reproducing anomalous Software stability metrics on source code √ ●
scenario [P19,P23] touched [P39]
Difference between development and Having shared or same testing system √ ●
production environment [P19] environment in all sites [P19]
DOI: 10.1002/smr
(e.g., inconsistent metrics between organizations, and no uniform design pattern, double effort in
testing and inspection work, and lack of regression testing). The product factor has two
categories not considered in general GSD, namely, third-party independence, and issues related to
size and maintenance-specific challenges linked to size and complexity of the software. Regarding
technology factors, the importance of challenges related to the testing environment is emphasized.
The categories subsumed the findings form all studies and our interviews. As the studies presented
in literature have been conducted in different contexts, and complemented by interviews, we are
confident that the structure of the framework is stable. Thus, future findings can be easily added to
the existing structure.
5.2. RQ2: How do software organizations mitigate these challenges?

Even though the people factor did not have many challenges specific to global maintenance, we found
that staffing solutions were specific to that context. For example, it was highlighted to have small,
cross-functional support teams where at least one skilled person should be available to share
knowledge. In addition, maintainers should also work as developers and vice versa. This addresses
several (also general) challenges in staffing, for example, to avoid excessive number of members in
a team, and helping inexperienced or new members assigned to maintenance tasks. The highest
number of solutions was identified for the process factor. In particular, the majority of global
maintenance-specific solutions were proposed in the context of quality management, scope
management, and change management. From the product perspective, the importance of different
types of documentation (documentation in different languages, guidelines, and manuals for the
maintenance processes, documentation about third-party components, and legal documentation)
specific to maintenance in the global context has been identified. Furthermore, from the technology
perspective, automation has been emphasized, with a focus on automating manual routine tasks and
assuring a mix of automated and manual testing.
After having structured the solutions, we mapped the challenges and solutions to each other. In many
cases, the linkage between challenges and solutions could be deduced, but was made explicit very rarely
in the investigations themselves. Thus, the linkage is based on interpretation and may serve as input to
the formulation of propositions and theories. A high number of propositions may be derived from the
tables. For example, from the mapping in Table XIX, multiple solutions were presented to deal with the
unavailability of domain experts. An open question is, which one is preferred over the other, and should
they be combined? Hypotheses could be formulated, such as ‘Having at least one skilled person help to
share knowledge is less effective in mitigating the effect of unavailability of domain experts than a Wiki
based collaboration platform’. For each of the mappings, we may also question whether there is actually
a link between a challenge and a solution, such as ‘Does having a higher maintainability of the design
early mitigate the challenge of lack of impact analysis’?
5.3. Further observations and reflections

We first conducted the literature review and based the interview design on the findings. This allowed us
to gather information beyond the results; in particular, new insights have been obtained. Tables XI–
XXII show which challenges and solutions were newly identified. Thus, we believe it is useful to
combine systematic literature reviews with other methodologies, such as building interviews and
surveys based on their results. Although, it was interesting that the literature subsumed the content
of the interviews on the level of axial and selective codes. This indicates that the conceptual
framework appears to be stable and may also subsume future studies.
The framework was derived using the GT method. The GT method, in our experience, helped to
conduct a very thorough and structured analysis of qualitative data. In particular, traceability to the
raw data is given and explicit (that is codes and their relation to categories are traceable down to
text fragments). The drawback is that the coding may be influenced by the interpretation and views
of the individual doing the coding. With regard to this study, a conceptual framework has been
proposed with concepts related to challenges and solutions. In future work, the knowledge base
could be further extended based on additional studies and interviews.
DOI: 10.1002/smr
6. CONCLUSION
In this study, we explored challenges and solutions specific to, or amplified in, global software
maintenance. For that purpose, we first conducted a systematic literature review and conducted a GT
analysis. Thereafter, five interviews with industry practitioners were conducted and also analyzed
using GT.
6.1. Implications for practitioners

Global software maintenance and GSD provide an intersection of challenges and solutions between
GSD and maintenance. That is, practitioners looking at the literature of GSD to gain
recommendations will find many useful recommendations for their challenges, although there are
also many distinctive challenges and solutions not covered. During selective coding, challenges and
solutions were categorized into people, process, product, and technology factors. People factors had
the lowest number of maintenance-specific challenges. As can be recognized from the literature in
GSD, a major focus has been placed on communication and collaboration, which is perceived as
one of the major GSD challenges. For process, product, and technology factors, the ratio of
maintenance-specific challenges is much higher. In the case of solutions, around half of all
challenges identified were maintenance specific. As a consequence, organizations who would like to
learn form research what challenges they may face and the solutions available, there is a need to
look beyond existing synthesis studies in software engineering. In this paper, we provide an
overview of the specific challenges to complement the existing literature.
Furthermore, practitioners may use this study as a checklist to conduct their risk assessment when
making outsourcing decisions in GSD. The challenges are categorized (e.g., process factors are
categorized under change management, quality management, etc.). This allows to map the
challenges to potential solutions through the categorization, which is supported by the descriptions
provided on the challenges and solutions.
6.2. Implications for researchers

For researchers, this study provides the opportunity to derive a number of hypotheses. Comparative
hypotheses for common findings between global software maintenance and GSD can be formulated,
for example, ‘lack of informal communication’ is amplified in the context of global maintenance in
comparison to general GSE. We argue that this is very important, as we only know about the
presence of the challenges, although we have too little information about their relative magnitude.
Hence, more comparative and experimental studies (in an industrial, but also academic context in
student projects) are needed. As was noticeable in the literature review, only very few studies were
of experimental nature.
Furthermore, given that we categorized solutions, we have alternative and complementary solutions
to address challenges related to a specific category and factor. This may also help in formulating
hypotheses where alternatives are directly compared (e.g., small vs. large teams in software
maintenance) in the context of staffing within the people factor. Another example is to compare
different alternatives of task management, for example, specialization versus diversity or assigning
people to versions versus assigning them to specific parts/modules.
It was also evident that many specific challenges were unique to either the interviews or the
literature. This shows that the topic merits further investigation, as with few interviews, a rich set of
additional challenges and solution ideas could be obtained. Additional studies, in particular
population-based studies, such as surveys, may be used to further expand the findings of our study.
6.3. Suggestions for future directions

Enterprise software maintenance is carried out in several support levels. In each support level,
maintainers are involved in different types of maintenance activities and face different kinds of
challenges. For example, support personnel in the lower level performs mainly preventive
maintenance, middle levels carry out corrective, while higher level perform perfective and adaptive
DOI: 10.1002/smr
maintenance. Hence, future study can focus on identifying challenges and strategies specific to each
support level of maintenance for exploring more precise results.
In addition, future investigation can continue exploring maintenance of open-source software
projects supported by worldwide developers’ community. In such scenario, members’ locations are
highly scattered, and most of the time, even they do not know each other. Presumably, it is a
complicated collaboration mode in global scenario. However lots of open-source software projects
are successfully undergoing, and its product quality is competitive with commercial products.
Last, but not least, comparative studies of experimental nature are needed to explore the magnitude
of impact of different challenges in relation to GSD versus global maintenance and general
maintenance versus maintenance in the GSD context.
APPENDIX
A. Selected primary studies

[P1] Robillard P, Kerzazi N, Tapp M, Hmima H. Outsourcing software maintenance: processes, standards critical prac-
tices, in 2007 Canadian Conference on Electrical and Computer Engineering, CCECD, 2007; 682–685.
[P2] Holmström H, Fitzgerald B. Virtual community use for packaged software maintenance. Journal of organizational
computing and electronic commerce 2006; 16(3):345–365 â€“.
[P3] Rao BS, Sarda N. Execution model for outsourced corrective maintenance, in Fifth International Conference on
Computer and Information Technology, CIT 2005, 2005; vol. 2005:944–948.
[P4] Friedrich M, Nusser G, Kuchlin W. Maintenance of distributed systems with mobile agents, in software mainte-
nance, 2002. Proceedings. International Conference on, 2002; 659–665.
[P5] Kusek M, et al. Mobile agent based software operation and maintenance, in telecommunications, 2003. ConTEL
2003. Proceedings of the 7th International Conference on, 2003; vol. 2:601–608.
[P6] Hands B, Capretz MAM. Maintenance and monitoring of remote software using an agent platform, in 2005 Inter-
national Conference on Integration of Knowledge Intensive Multi-Agent Systems, KIMAS’05: Modeling, Exploration,
and Engineering, 2005; vol. 2005; 543–548.
[P7] French A, Layzell P. A study of communication and cooperation in distributed software project teams, in software
maintenance. IEEE International Conference on, 1998; vol. 0; 146.
[P8] Ghosh S. Challenges on a Global Implementation of ERP Software. 2002; 101–106.
[P9] Jain N. Offshore agile maintenance, in Agile Conference, 2006; 7–336.
[P10] Sarkar S, Sindhgatta R, Pooloth K. A collaborative platform for application knowledge management in software
maintenance projects, in 1st ACM Bangalore Annual Conference, COMPUTE 2008, January 18, 2008 - January 20,
2008, p. ACM Bangalore chapter, 2008.
[P11] Bhatt P, Shroff G, Williams K, Misra AK. An empirical study of factors and their relationships in outsourced soft-
ware maintenance, in APSEC 2006: Asia-Pacific Software Engineering Conference, December 6, 2006 - December 8,
2006; 301–308.
[P12] Rao BS, Sarda N. Effort drivers in maintenance outsourcing - an experiment using Taguchi’s methodology, in soft-
ware maintenance and reengineering, European Conference on, vol. 0, p. 271, 2003.
[P13] Ahmed R. Software maintenance outsourcing: issues and strategies. Computers and Electrical Engineering 2006;
32(6):449–53.
[P14] Tjortjis C, Dafoulas G, Layzell P, Macaulay L. A model for selecting CSCW technologies for distributed software
maintenance teams in virtual organisations, in Proceedings of 26th Annual International Computer Software and Appli-
cations, 26-29, 2002; 1104–8.
[P15] Bianchi A, Caivano D, Lanubile F, Rago F, Visaggio G. An empirical study of distributed software maintenance
2002; 103–109.
[P16] Baldassarre MT. Caivano D, Visaggio G. Non invasive monitoring of a distributed maintenance process, 2006; 1098–1103.
[P17] Redmiles D et al. A new paradigm to support globally distributed software development projects.
Wirtschaftsinformatik 2007; 49:28–38.
[P18] Ramos C, Oliveira K, Anquetil N. Legacy software evaluation model for outsourced maintainer, in Eighth Euro-
pean Conference on Software Maintenance and Reengineering, 2004; 24-26; 48-57.
[P19] Yan Z. Efficient maintenance support in offshore software development: a case study on a global e-commerce pro-
ject, in "Third International Workshop on Global Software Development (GSD 2004)" W12S Workshop - 26th Interna-
tional Conference on Software Engineering, 2004; 12–17.
[P20] Smith M, Mitra S, Narasimhan S. Offshore outsourcing of software development and maintenance: a framework
for issues. Information and Management 1996; 31(3):165–75.
[P21] Tiako P. Maintenance in joint software development, in Computer Software and Applications Conference, 2002.
COMPSAC 2002. Proceedings. 26th Annual International, 2002; 1077-1080.
DOI: 10.1002/smr
[P22] Narayanan S, Balasubramanian S, Swaminathan JM. A matter of balance: specialization, task variety, and individ-
ual learning in a software maintenance environment. Management Science 2009; 55(11):1861–1876.
[P23] Seybold C, Keller RK. Aligning software maintenance to the offshore reality, in CSMR 2008 - 12th European Con-
ference on Software Maintenance and Reengineering, April 1, 2008 - April 4, 2008; 33–42, 2008.
[P24] Cusick J, Prasad A. A practical management and engineering approach to offshore collaboration, software. IEEE
2006; 23(5):20–29.
[P25] Bhatt P, Shroff G, Anantaram C, Misra AK. An influence model for factors in outsourced software maintenance.
Journal of Software Maintenance and Evolution 2006; 18(6):385–423.
[P26] Park J, Kim JS. The impact of IS sourcing type on service quality and maintenance efforts. Information and Man-
agement 2005; 42(2):261–274.
[P27] Bin X, Yujuan D, Xiaohu Y, Xiejun L. Albert M. : Experience of collaborative requirement management in dual-
shore software maintenance projects, 2008.
[P28] Aversano L, Betti S, De Lucia A, Stefanucci S. Introducing workflow management in software maintenance pro-
cesses, in software maintenance, 2001. Proceedings. IEEE International Conference on,2001; 441–450.
[P29] Gable G, Chan T, Tan W. Large packaged application software maintenance: a research framework. Journal of
Software Maintenance and Evolution: Research and Practice 2001; 13(6):351–371.
[P30] Bhat JM, Gupta M. Enhancing requirement stakeholder satisfaction during far-shore maintenance of custom devel-
oped software using shift-pattern model, 2007.
[P31] Herbsleb JD, Mockus A, Finholt TA, Grinter RE. Distance, dependencies, and delay in a global collaboration, Phil-
adelphia, Pennsylvania, United States, 2000; 319–328.
[P32] Antoniol G, Cimitile A, Di Lucca G, Di Penta M. Assessing staffing needs for a software maintenance project
through queuing simulation. IEEE Transactions on Software Engineering 2004; 30(1):43–58.
[P33] Bassin K, Santhanam P. Managing the maintenance of ported, outsourced, and legacy software via orthogonal de-
fect classification, in Proceedings IEEE International Conference on Software Maintenance. ICSM 2001, 7-9 Nov. 2001;
726–34.
[P34] Gao JZ, Itaru F, Toyoshima Y. Managing problems for global software production experience and lessons. Infor-
mation Technology and Management 2002; 3(1):85–112.
[P35] Desouza K, Awazu Y, Baloh P. Managing knowledge in global software development efforts: issues and practices.
IEEE SOFTWARE 2006; 23(5):30-+.
[P36] Nguyen T. Component-based software update process in collaborative software development, in 2008 15th Asia-
Pacific Software Engineering Conference, 2008; 437–44.
[P37] Polo M, Piattini M, Ruiz F. Integrating outsourcing in the maintenance process. Information Technology & Man-
agement 2002; 3(3):247–69.
[P38] Wang L, Wang P, Zheng Y. Emergency software maintenance for individual industrial equipments, in frontier of
computer science and technology, 2009. FCST’09. Fourth International Conference on, 2009; 161–167.
[P39] Leszak M, Meier M. Successful global development of a large-scale embedded telecommunications product, in In-
ternational Conference on Global Software Engineering, ICGSE 2007, August 27, 2007 - August 30, 2007; 23–32.
[P40] Fisher J, Hirschheim R, Jacobs R. Understanding the outsourcing learning curve: a longitudinal analysis of a large
Australian company. Information Systems Frontiers 2008; 10(2):165–178.
[P41] Rao B, Sarda N. Applicability of IEEE maintenance process for corrective maintenance outsourcing-an empirical
study, in Proceedings International Conference on Software Maintenance, 3-6 Oct. 2002; 74–83.
[P42] Ghosh S, Ghosh S. Global implementation of ERP software - critical success factors on upgrading technical infra-
structure, in IEMC’03 Proceedings, Managing Technologically Driven Organizations:’The Human Side of Innovation
and Change’, November 2, 2003 - November 4, 2003; 320–324.
[P43] Sneed H. Offering software maintenance as an offshore service, in 2008 IEEE International Conference on Soft-
ware Maintenance, 28 Sept.-4 Oct. 2008; 1–5.
[P44] Yeo AW. Global-software Development Lifecycle: An Exploratory Study. Seattle, Washington, United States,
2001; 104–111.
B. Interview guide
The interview started with the background of the interviewee and his or her company.
• How long have you been working in any software organization?

• How long have you been involved software maintenance in distributed environment?
• Could you tell me about brief history of the company or project?
• Introduction of product maintained?
People-related questions: These questions are to reveal difficulties due to the factors by maintenance
personnel and their mitigative practices.
DOI: 10.1002/smr
• Who are involved in the entire maintenance work? Please describe their roles and influences on
the project.
• Do you agree or disagree with people who say that maintenance work is very difficult, boring, or
a less innovative job? If yes, why? If no, why not?
• Have you ever had disputes or misunderstanding with other stakeholders (language or culture)?
If yes, how did you resolve the conflict? If no, how do you manage different stakeholders’
involvement?
• How much difficult is it to keep a normal working pace when a new member joins the project or
an old member leaves the work? If much, how can its impact be mitigated? If not much, how do
you keep up with a normal pace in such case?
• How often do you need to work for extra hours? If often or more, how do you feel? Why does it
happen, regularly or unexpectedly? If rare, which technique do you use to avoid potential work
overload?
Product-related questions: Those questions are to explore challenges caused by the factors specific
to the software product being maintained and their mitigation practices.
• Is any third-party solution (COTS component) included in your maintaining software? If yes,
how often do you need to deal with changes related to them? How much effort is spent?
• What kind of documentation do you update as software changes? How does documentation help
in daily activities?
• In your opinion, what are the important things to keep distributed team’s communication live and
effective? Why?
Process-related questions: Those questions are to explore challenges caused by process related
factors on maintenance activity and their mitigation practices.
• What are the methods you use to communicate with remote team? Why?
• How often do you have a face-to-face meeting?
• What are the difficulties you encounter in communication?
• Do you feel challenges on handling customer change request? If yes, what are they? How do you
overcome them? If no, how did you resolve it? Which mechanisms?
• Who are involved in assessing risk and impact of software change?
• Who were involved in testing process? How?
• How do you maintain and keep track of software changes? Which mechanism do you use?
• What are the difficulties when you deploy software patch or update? How can they be solved or
mitigated?
• Do you measure level of success or failure of maintenance? If yes, which attributes do you in-
clude? Why? If no, how do you ensure whether maintenance process is acceptable? Why?
• What are the difficulties encountered during emergency maintenance? How do you overcome?
• Do you think your current maintenance task distribution works well in your project? If yes, how
is the task triggered and is the progress tracked? If no, how could be improved or reorganized?
• Do you maintain any repository of system documentation, user guide, or other documents? If
yes, how does it work? Why is it needed? If no, how do you manage project’s important
artifacts?
• Do you hold any regular training to share knowledge between members? If yes, how do you hold
it? How does it help in maintenance activities? If no, how do you share or exchange skills and
experience within the team? Why?
• Have you ever been concerned with information security during training or sharing knowledge in
other stakeholders? If yes, how do you handle security concern?
Technology-related questions: Those questions are to explore challenges brought by technology
support on maintenance activity and their mitigation practices.
• How do lack of or poor hardware and software support impact in maintenance activities? How
did you resolve them?
DOI: 10.1002/smr
• Do all team members use the same software tools in maintenance? If yes, how does it help in
your maintenance activities?
• How often do you face software failure due to hardware fault? If often, what are the main causes?
How do you resolve them? If less, how do you support hardware maintenance?
• If you want to add issues which are not asked, please feel free.
REFERENCES
1. Bianchi A, Caivano D, Lanubile F, Visaggio G. Defect detection in a distributed software maintenance project. In
Proc. of the International Workshop on Global Software Development (GSD 2003), Portland, Oregon, USA, pages
48–52, 2003.
2. Gonzalez R, Gasco J, Llopis J. Information systems outsourcing: a literature analysis. Information and Management
2006; 43(7):821–834.
3. Sengupta B, Chandra S, Sinha V. A research agenda for distributed software development. In Proceedings of the 28th
international conference on Software engineering, pages 731–740. ACM, 2006.
4. Ng CSP, Chan T, Gable GG. A client-benefits oriented taxonomy of ERP maintenance. In Proceedings of the IEEE
International Conference on Software Maintenance (ICSM’01), page 528. IEEE Computer Society, 2001.
5. Yan Z g. Efficient Maintenance Support in Offshore Software Development: A Case Study on a Global E-commerce
Project. IEEE Computer Science Press: New York, 2004.
6. Tiwana A. Beyond the black box: knowledge overlaps in software outsourcing. Software, IEEE 2004; 21(5):51–58.
7. Ahmed RE. Software maintenance outsourcing: issues and strategies. Computers & Electrical Engineering 2006;
32(6):449–453.
8. Canfora G, Cimitile A, Lucarelli PB. Software maintenance. Handbook of Software Engineering and Knowledge En-
gineering 2000; 1:91–120.
9. Hunt B, Turner B, McRitchie K. Software maintenance implications on cost and schedule. In aerospace conference,
2008 IEEE, pages 1–6. IEEE, 2008.
10. Polo M, Piattini M, Ruiz F. Advances in software maintenance management: technologies and solutions. IGI Global:
Hershey, PA, 2003.
11. Lientz BP, Swanson EB. Software Maintenance Management: A Study of the Maintenance of Computer Applica-
tions Software in 487 Data Processing Organizations. Addison Wesley: Boston, 1980.
12. Erlikh L. Leveraging legacy system dollars for e-business. IT professional 2000; 2(3):17–23.
13. Pigoski TM. Practical Software Maintenance: Best Practices for Managing Your Software Investment. John Wiley &
Sons, Inc.: Hoboken, New Jersey, 1996.
14. Polo M, Piattini M, Ruiz F. Integrating outsourcing in the maintenance process. Information Technology and Man-
agement 2002; 3(3):247–269.
15. Nakatsu RT, Iacovou CL. A comparative study of important risk factors involved in offshore and domestic
outsourcing of software development projects: a two-panel Delphi study. Information & Management 2009;
46(1):57–68.
16. Damian D, Moitra D. Guest editors’ introduction: global software development: how far have we come? Software,
IEEE 2006; 23(5):17–19.
17. Herbsleb JD, Mockus A. An empirical study of speed and communication in globally distributed software develop-
ment. Software Engineering, IEEE Transactions on 2003; 29(6):481–494.
18. Herbsleb JD, Moitra D. Global software development. Software, IEEE 2001; 18(2):16–20.
19. Hussey JM, Hall SE. Managing Global Development Risk. CRC Press: Boca Raton, Florida, 2007.
20. Seybold C, Keller RK. Aligning software maintenance to the offshore reality. In Software Maintenance and
Reengineering, 2008. CSMR 2008. 12th European Conference on, pages 33–42. IEEE, 2008.
21. Lehman MM. Programs, life cycles, and laws of software evolution. Proceedings of the IEEE 1980;
68(9):1060–1076.
22. Jung H-W, Goldenson DR. Evaluating the relationship between process improvement and schedule deviation in
software maintenance. Information and Software Technology 2009; 51(2):351–361.
23. Sneed HM. Offering software maintenance as an offshore service. In Software Maintenance, 2008. ICSM 2008. IEEE
International Conference on, pages 1–5. IEEE, 2008.
24. Wieringa R, Daneva M. Six strategies for generalizing software engineering theories. Science of Computer
Programming. 2015; 101: 136–152.
25. Kitchenham B. Procedures for performing systematic reviews. Keele, UK, Keele University 2004; 33:1–26, 2004.
26. Corbin J, Strauss A. Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory.
Sage: Washington DC, 2008.
27. Smite D, Wohlin C, Feldt R, Gorschek T. Reporting empirical research in global software engineering: a classifica-
tion scheme. In Global Software Engineering, 2008. ICGSE 2008. IEEE International Conference on, pages
173–181. IEEE, 2008.
DOI: 10.1002/smr
28. Šmite D, Wohlin C, Gorschek T, Feldt R. Empirical evidence in global software engineering: a systematic review.
Empirical Software Engineering 2010; 15(1):91–118.
29. Holmstrom H, Conchúir EÓ, Agerfalk PJ, Fitzgerald B. Global software development challenges: a case study on
temporal, geographical and socio-cultural distance. In Global Software Engineering, 2006. ICGSE’06. International
Conference on, pages 3–11. IEEE, 2006.
30. Gonzalez R, Gasco J, Llopis J. Information systems outsourcing risks: a study of large firms. Industrial management
& Data systems 2005; 105(1):45–62.
31. Holmström H, Fitzgerald B, Ågerfalk PJ, Conchúir EÓ. Agile practices reduce distance in global software
development. Information Systems Management 2006; 23(3):7–18.
32. Moe NB, Šmite D. Understanding lacking trust in global software teams: a multi-case study. Product-Focused
Software Process Improvement. Springer: Springer, Heidelberg, 2007; 20–34.
33. Lanubile F, Damian D, Oppenheimer HL. Global software development: technical, organizational, and social
challenges. ACM SIGSOFT Software Engineering Notes 2003; 28(6):2–2.
34. Verner JM, Brereton OP, Kitchenham BA, Turner M, Niazi M. Risks and risk mitigation in global software
development: a tertiary study. Information & Software Technology 2014; 56(1):54–78.
35. Nidhra S, Yanamadala M, Afzal W, Torkar R. Knowledge transfer challenges and mitigation strategies in global
software development – a systematic literature review and industrial validation. International Journal of Information
Management, 33:333â€“355, 2013.
36. Iqbal A, Gencel C, Abbas S. Communication Risks and Best practices in Global Software Development. Ajmal
Iqbal: Saarbrücken, Germany, 2012.
37. Noll J, Beecham S, Richardson I. Global software development and collaboration: barriers and solutions. ACM
Inroads 2010; 1(3):66–78.
38. Inc M-W. Merriam-Webster’s Collegiate Dictionary. Merriam-Webster: Springfield, Massachusetts, 2004.
39. McKean E. The New Oxford American Dictionary, Volume 2. Oxford University Press New York: NY:, 2005.
40. September A. IEEE standard glossary of software engineering terminology. Office 1990; 121990(1):1.
41. Boehm BW. Software Engineering Economics. Prentice Hall: Upper Saddle River, New Jersey, 1981.
42. Swanson EB. The dimensions of maintenance. Proceedings of the 2nd International Conference on Software
Engineering. IEEE Computer Society Press: New York, 1976; 492–497.
43. Moore JW. Software Engineering Standards. Wiley Online Library: Hoboken, New Jersey, 1998.
44. Chen J-C, Huang S-J. An empirical analysis of the impact of software development problem factors on software
maintainability. Journal of Systems and Software 2009; 82(6):981–992.
45. Erdil K, Finn E, Keating K, Meattle J, Park S, Yoon D. Software maintenance as part of the software life cycle.
Comp180: Software Engineering Project 2003.
46. Li T, YongGang M, JianJie D. Metric-based tracking management in software maintenance. In Education Technol-
ogy and Computer Science (ETCS), 2010 Second International Workshop on, volume 1, pages 675–678. IEEE, 2010.
47. Wood M, Roper M, Brooks A, Miller J. Comparing and combining software defect detection techniques: a replicated
empirical study. ACM SIGSOFT Software Engineering Notes, vol. 22. Springer-Verlag: New York, Inc, 1997;
262–2771.
48. Keele S. Guidelines for performing systematic literature reviews in software engineering. Technical report, Technical
report, EBSE Technical Report EBSE-2007-01, 2007.
49. Steinar K, Brinkmann S. Interviews: Learning the craft of qualitative research interviewing. Sage: Washington
DC, 2009.
50. Smith JA. Qualitative Psychology: A Practical Guide to Research Methods. Sage: Thousand Oaks, California, 2007.
51. Petersen K, Feldt R, Mujtaba S, Mattsson M. Systematic mapping studies in software engineering. In 12th Interna-
tional Conference on Evaluation and Assessment in Software Engineering, volume 17. sn, 2008.
52. Matthews PH. The Concise Oxford Dictionary of Linguistics. Oxford University Press: Oxford, United Kingdom, 2007.
53. Merriam-Webster I. Merriam-Webster’s Collegiate Thesaurus. Merriam Webster: Springfield, Massachusetts, 1988.
54. Salmeron JL, Lopez C. A multicriteria approach for risks assessment in ERP maintenance. Journal of Systems and
Software 2010; 83(10):1941–1953.
55. Svahnberg M, Gorschek T, Feldt R, Torkar R, Saleem SB, Shafique MU. A systematic review on strategic release
planning models. Information and Software Technology 2010; 52(3):237–248.
56. SE Hove and B Anda. Experiences from conducting semi-structured interviews in empirical software engineering
research. In Software Metrics, 2005. 11th IEEE International Symposium, pages 10–pp. IEEE, 2005.
57. Denzin NK, Lincoln YS. The Sage Handbook of Qualitative Research. Sage: Hoboken, New Jersey, 2005.
58. Patton MQ. Qualitative Evaluation and Research Methods. SAGE Publications, inc: Hoboken, New Jersey, 1990.
59. Sarkar S, Sindhgatta R, Pooloth K. A collaborative platform for application knowledge management in software
maintenance projects. In Proceedings of the 1st Bangalore Annual Compute Conference, page 2. ACM, 2008.
60. Sosa E. A Virtue Epistemology: Apt Belief and Reflective Knowledge, Volume I. Oxford University Press: USA, 2009.
61. Greco J. The nature of ability and the purpose of knowledge. Philosophical issues 2007; 17(1):57–69.
62. Strauss A, Corbin JM. Grounded Theory in Practice. Sage: Hoboken, New Jersey, 1997.
63. Glaser BG. Emergence Vs Forcing: Basics of Grounded Theory Analysis. Sociology Press: Mill Valley, CA, 1992.
64. Thomas G, James D. Reinventing Grounded Theory: Some Questions About Theory, Ground and Discovery. British
Educational Research Journal 2006; 32(6):767–795.
DOI: 10.1002/smr
65. Smith MA, Mitra S, Narasimhan S. Offshore outsourcing of software development and maintenance: a framework for
issues. Information & management 1996; 31(3):165–175.
66. French A, Layzell P. A study of communication and cooperation in distributed software project teams. In Software
Maintenance, 1998. Proceedings., International Conference on, pages 146–154. IEEE, 1998.
67. Lund AM, Tschirgi JE. Designing for people: integrating human factors into the product realization process. Selected
Areas in Communications, IEEE Journal on 1991; 9(4):496–500.
68. D Harding. Digest notes: the challenge of change: change mechanisms-the measurement of people, process and
product. In Business Improvement Through Measurement, IEE Seminar on, IET, 1999; 6–1.
69. McChesney I. A Proposed Curriculum for Software Engineering Project Management-process, Product and
People. IEEE Computer Science Press: New York, 1995.
70. Potgieter B, Botha J, Lew C. Evidence that use of the ITIL framework is effective. In th Annual conference of
the national advisory committee on computing qualifications, Tauranga, NZ, pages 160–167. Citeseer: Hershey,
PA, 2005.
71. Van Grembergen W. Strategies for Information Technology Governance. Igi Global: Hershey, PA, 2004.
72. Nor MZM, Abdullah R, Selamat MH, Murad MAA. Knowledge sharing interactions in collaborative software
maintenance environment. In Computer Technology and Development, 2009. ICCTD’09. International Conference
on, volume 2, pages 201–205. IEEE, 2009.
73. Hall T, Rainer A, Baddoo N, Beecham S. An empirical study of maintenance issues within process improvement
programmes in the software industry. In Software Maintenance, 2001. Proceedings. IEEE International Conference
on, pages 422–430. IEEE, 2001.
SUPPORTING INFORMATION
Additional supporting information may be found in the online version of this article at the publisher’s web site.
DOI: 10.1002/smr

A Conceptual Framework of Challenges and Solutions For Managing Global Software Maintenance

Uploaded by

Copyright:

Available Formats

A Conceptual Framework of Challenges and Solutions For Managing Global Software Maintenance

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A Conceptual Framework of Challenges and Solutions For Managing Global Software Maintenance

Uploaded by

Copyright:

Available Formats

JOURNAL OF SOFTWARE: EVOLUTION AND PROCESS

J. Softw. Evol. and Proc. 2015; 27:763–792

A conceptual framework of challenges and solutions for managing

Received 28 August 2014; Revised 23 February 2015; Accepted 29 April 2015

*Correspondence to: Kai Petersen, Blekinge Institute of Technology, Karlskrona, Sweden.

Copyright © 2015 John Wiley & Sons, Ltd.

2.1. Global software development

2.2. Global software maintenance

Table I. General challenges of a globally distributed setting.

Geographical distance Cultural distance Temporal distance

Stafﬁng Underestimate and assign new or Assign experienced personnel [P1]

3.1. Data collection

Table III. Main keywords used in the search string.

A1 global software development

Table IV. Number of studies with respect to review stages.

3.2. Data analysis

1 Ericsson AB: Ericsson is a large organization Interviewee 1 has 10 years of experience of

Table VI. Summary of organizations.

3.3. Validity threats

Table VII. Results of grounded theory coding.

Open coding 134 79

The following threats are open threats affecting the interviews:

4.1. Overview of the literature

Table VIII. Distribution of articles with regard to maintenance activities.

Table IX. Distribution of articles with regard to maintenance activities.

Table X. Research methods used.

Methods References to studies

Figure 1. Quality assessment.

Table XI. Challenges (selective code – people).

Personal attitude Degraded perception about maintenance [P1] √ ●

●, not found in source; √, found in source; SLR, systematic literature review.

• People: fundamental element operating and maintaining a product. We placed human-related

Table XII. Challenges (selective code – process).

Change management Poor impact analysis of change request ● √

●, not found in source; √, found in source; SLR, systematic literature review.

challenges were identiﬁed, namely, change management, quality management, communication

Table XIII. Challenges (selective code – product).

Third-party independence Use of COTS components [P13,P40] √ ●

Table XIV. Challenges (selective code – technology).

●, not found in source; √, found in source; SLR, systematic literature review.

Table XV. Solutions (selective code – people).

●, not found in source; √, found in source; SLR, systematic literature review.

Table XVI. Solutions (selective code – process).

●, not found in source; √, found in source; SLR, systematic literature review.

4.4. Mapping of challenges and solutions

Table XVII. Solutions (selective code – product).

Documentation Preparing documentation in different languages [P3] √ ●

Table XVIII. Solutions (selective code – technology).

●, not found in source; √, found in source; SLR, systematic literature review.

Table XIX. Mapping of challenges to solutions (selective code – people).

Table XX. Mapping of challenges to solutions (selective code – process).

Table XX. Continued

Unavailability of personal in Planning emergency maintenance procedure √ ●

●, not found in source; √, found in source; SLR, systematic literature review.

Table XXI. Mapping of challenges to solutions (selective code – product).

Table XXII. Mapping of challenges to solutions (selective code – technology).

Challenges Solutions SLR Interview

●, not found in source; √, found in source; SLR, systematic literature review.

5.2. RQ2: How do software organizations mitigate these challenges?