This paper aims to explore the concept of early warning signs (EWSs) in offshore-outsourced software development (OOSD) projects at the team level. It also aims to identify the EWSs of failure in the onshore-offshore project context and understand how they are perceived by responsible managers.
A grounded theory approach is followed by gathering data from 19 failed OOSD projects using project managers from client and vendor sides as the key informants.
This study identified 13 EWSs of failure in five categories of trust and team cohesion, common project execution structures, awareness of shared work context, collaboration between teams and onshore-offshore team coordination capabilities. EWSs were found to comprise two components: early warning issues and early signals of failures.
India-based vendors’ data in the study formed the primary weakness of the work regarding generalizability, even though it brought homogeneity to data. Lack of triangulation of failure data through client or vendor peers proved impossible in this research as failure remains a very sensitive topic. Dual composition of EWSs could be applied to institutionalize an early warning tool in projects.
The paper develops an exploratory model of EWSs of failure and project failure in the OOSD project context. The two-component framework of EWSs allows project managers to eliminate false positives while identifying EWSs. It contributes to the information system failure, risk management and information technology offshoring research streams.
Philip, T. and Schwabe, G. (2018), "Understanding early warning signs of failure in offshore-outsourced software projects at team level", Journal of Global Operations and Strategic Sourcing, Vol. 11 No. 3, pp. 337-356. https://doi.org/10.1108/JGOSS-12-2017-0057Download as .RIS
Emerald Publishing Limited
Copyright © 2018, Emerald Publishing Limited
The global information technology (IT) outsourcing business boomed in the 1990s, and as a result of this ongoing trend, IT offshore outsourcing has been experiencing strong growth. Application or software development in low-cost countries such as India and China has been one of the dominant business areas in IT offshoring. However, IT offshoring does not always bring anticipated benefits for outsourcing organizations. Several academic (Rottman and Lacity, 2008) and practitioner-oriented (Vashistha and Vashistha, 2005) studies have reported failures in offshore projects to realize the intended objectives. The reasons behind the failures in offshore-outsourced software development (OOSD) projects could range from wrong expectations from IT offshoring by the client to poor execution by the vendor. In OOSD projects, a well-established governance mechanism to manage the project, as well as control it throughout its execution, becomes imperative.
In failed projects, the seeds of failure seem to have been sown early, and they mature in an environment of ignorance (Cule et al., 2000). However, one positive aspect is that post-mortem examination of failures has shown significant early warning signs (EWS) of failure before the projects actually failed (Kappelman et al., 2006). Project troubles are rarely detected early enough in the IT industry (Havelka and Rajkumar, 2006). Nevertheless, project managers (PMs) are mostly in a good position to identify project troubles during project execution (Keil et al., 1998). Examining the collaboration between the vendor and client teams in the early project stages provides the direction in which the project is heading. Identifying potential problems during the first 20 per cent of the project’s vendor-client collaboration phase and taking measures to control them would allow PMs to take appropriate corrective measures early enough to finish the project according to original estimates (Kappelman et al., 2006). In this work, we define EWS as a project state or indication that surfaces in the first 20 per cent of the project’s cooperation or collaboration period between clients and vendors, and that signals possible or impending problems or issues (based on Kappelman et al., 2006).
The failure to reap intended objectives in OOSD projects has practical implications for both client and vendor organizations, especially for PMs and program or portfolio managers who need to understand the project development well during the execution stages. Perception of project activities is an initial step to use control activities and intervene at the right time. Therefore, organizations involved in onshore-offshore projects need to set up appropriate control structures (Hughes et al., 2016) to ensure successful OOSD project implementation. Because of imperfect control in offshore-outsourced projects and the intangible nature of software development, the identification and management of EWSs offers a predictive managerial tool for understanding the risks and issues that lead to failures. The potential to apply EWS to control team activities in the unique OOSD project context requires a detailed study.
From the research perspective, the risk management stream has been collecting risk factors (Iacovou and Nakatsu, 2008; Schmidt et al., 2001) about outsourced projects, and several studies have studied specific EWSs (Havelka and Rajkumar, 2006; Kappelman et al., 2006). Some studies have synthesized EWSs and developed models to be used as project management tools (Ansoff, 1984; Nikander and Eloranta, 2001). However, these models were not geared for providing specific support for controlling OOSD projects. To achieve specific support, we need to systematically collect and structure current factors and models, as well as explore the extent to which they are applicable to OOSD projects, and further identify EWSs specific to the OOSD project environment.
In this study, we focus on team-level factors as this area received the least attention from researchers and because team level factors – both from client and vendor perspectives involving client onshore, vendor onshore and vendor offshore teams – are crucial in culturally diverse settings. We intend to understand EWSs of failure in OOSD projects better from the project team perspective in this exploratory research and will attempt to answer the following research questions:
Which early warning signs indicate failures in offshore-outsourced software projects at a team level?
How can the responsible managers perceive them?
The structure of this paper is as follows. After this introduction, Section 2 discusses related work in outsourcing, software development and EWS. Section 3 discusses the research methodology used in this study, followed by the analysis and findings, which are presented in Section 4. Section 5 is devoted to discussing conclusions.
2. Theoretical background
2.1 Software development and offshore teams
Software development has been considered as a perfect activity for global dispersion as it requires little customer contact or physical presence (Apte and Mason, 1995). However, the inherent complexity of the software development process makes its success difficult even in conditions of co-location (Sahay et al., 2003). Captive offshore development by an organization’s extended arm in the offshore country has proven to be a costly variant for many organizations. As a result, more organizations have relied on third-party organizations in offshore countries to save the capital investment required in the case of captive outsourcing. This development fueled the growth of OOSD. Nevertheless, Iacovou and Nakatsu (2008) noted that there are more risks associated with offshore outsourcing than onshore-outsourced or captive offshore projects, and thus, offshore projects are more prone to failure. Several authors have studied offshore-specific risks; they include cultural differences, linguistic differences, coordination, control and communication difficulties and work practice differences (Dibbern et al., 2008; Sakthivel, 2007).
Team members identify themselves strongly with the team rather than with the organization (Knippenberg and Schie, 2000). This is because the organization, being so large, poses a threat to the team members’ individual characteristics, while the smaller environment of the team offers more commonality that creates fellow-feeling and mutual identification. Nevertheless, Hofstede et al. (1990) found that while organizational culture had more context-specific influence pertaining to work practices, national culture guided the priorities of team members based on underlying values. In fact, project risks are perceived differently by PMs on different continents (Schmidt et al., 2001), mainly because of varying underlying values and cultural orientations. Most studies in offshore projects are drawn from the vendor perspectives (Lacity et al., 2010), while Soderberg et al.’s (2013) study from the Indian vendor perspective highlighted the need for senior management commitment, mutual trust and cultural sensitivity to remain successful in client–vendor partnerships that have reached advanced stages of outsourcing.
The significance of context in OOSD projects can be best analyzed using the agency theory that explains the relationship aspects between client (principal) and vendor (agent) in IT outsourcing. In a contractual relationship, it is assumed that the agent has access to more private information than the principal, and thus, the consequent information asymmetries allow the agent to hide information during the engagement (Baiman, 1990). Differences in risk attitudes and goals, as well as uncertainties, define the hidden behaviors and actions of actors during the cooperative contracting period (Eisenhardt, 1989; Ross, 1973). Due to the intangible nature of software and the difficulties in monitoring incomplete contracts in the OOSD project context, an OOSD project is a case of an agency problem. Offshore-specific conditions imply imperfect monitoring and verification problems (Eisenhardt, 1989), where the agent is not compelled to behave according to the principal’s interest. The warning signs of unanticipated outcomes from onshore and offshore teams provide the cues to avoid project failures.
2.2 Early warning signs of failure
Practitioners and academics alike do not have a consensus regarding the definition of project failures (Pinto and Mantel, 1990), and it has been defined in numerous ways. In the outsourcing context, contracts provide the primary form of control for IT outsourcing engagements (Kern and Willcocks, 2000). Hence, we consider the fulfillment of contractual obligations as the basis of OOSD project success and failure. According to the agency theory, contracts form the best instrument to control the outcomes because of missing informal controls and the intangible nature of the software artefacts. This study focuses on project abandonment or cancelation, which is the most extreme form of project failure. Therefore, we define project failure as the cancelation of the project, resulting in termination of contractual activities between clients and vendors prematurely, i.e. before the information system becomes operational. It includes projects that were abandoned at any project phase or insourced because of the vendor’s inability to implement the system.
The seminal work in the area of warning signs was presented by business economist Ansoff (1975), who noted that sudden and unfamiliar changes in an organization’s environment affect the working environment. Ansoff’s (1975) work noted warning signs as noticeable weak signals first that become more specific and stronger with the passage of time. Several academic and practitioner studies have come up in the areas of communications, military intelligence and business economics (Nikander, 2002) that used weak signals under synonyms such as symptoms, early indicators, presignals and EWSs.
Ansoff (1984) later developed the initial ideas of weak signals (presented by Ansoff, 1975) by adding a temporal dimension and differentiating weak and strong signals. Weak signals are defined as “imprecise, early indications about impending impactful events,” whereas strong signals are issues that “will be sufficiently visible and concrete to permit the firm to compute their impact and to devise specific plans for response” (Ansoff, 1984, p. 22). Loosemore’s (2000, p. 31) study of EWSs with regard to their visibility as part of crisis management in the construction industry asserted that the visibility of EWSs is “determined by their intensity, duration, and subtlety.” EWSs were found to be difficult to detect in project designs that are subtle, of low-intensity and short duration, as opposed to physical buildings that emit blatant signals of high intensity and long duration. Because of the intangible nature of software coding, EWSs of failure in OOSD projects exhibit similar characteristics in the project design phase.
Nikander and Eloranta’s (2001) study of EWSs in industrial construction projects found that most of the information about EWSs came from within the project, and they argued that an observed event or indication could be interpreted as a warning, a problem or a cause of the problem depending on the project conditions in the various project stages. Although this study indicated the possibility of using EWS as a project management tool, PMs could not clearly differentiate between a warning, problem or cause of the problem to apply their framework in a timely manner. The symptoms and causes of troubled information system (IS) projects analyzed by Havelka and Rajkumar (2006) produced the most comprehensive list of symptoms in the area of software development to date that included team symptoms. As opposed to the project management or execution perspective adopted in the present study, Klakegg et al.’s (2010) report for Project Management Institute discussed EWSs in complex projects from the project owners or governance perspective in IT, oil and gas, construction, manufacturing and public sector industries. They differentiated EWSs into two types: hard issues and soft issues. Hard issues are of a technical nature that can be measured through project assessments and soft issues are related to people who can be identified through gut feelings. Williams et al.’s (2012) study of EWSs in complex projects found that the behavioral complexities of team members result in situations in which the causal relationships between the causes of failures and EWSs are less obvious.
In contrast to above research works on EWSs that consider the whole lifecycle of project, Kappelman et al. (2006) studied the first 20 per cent of the project lifecycle. Their work on IT projects identified 53 EWSs from the literature in three risk categories (social subsystem, project management and technical subsystem). Following Kappelman et al.’s (2006) concentration on the first 20 per cent of project lifecycle, our own preliminary research on offshore software development projects found 21 EWSs in four categories, namely, communication, people, formal process and formal output-related EWSs (Philip et al., 2010). The offshore-specific ones identified by that work were all related to team communication and coordination, which showed the relevance of interaction among team members in OOSD projects to avoid project failures. It explored the EWSs relevant to offshore projects in general (captive and outsourced offshoring). However, the extant studies provide only limited help to practitioners regarding how to recognize concretely the EWSs.
A thorough understanding of specific risk scenarios forms the critical precondition to effectively setup risk management measures such as an early warning system (Thamhain, 2013). The deployment of tsunami early warning system in the Indian Ocean that predicts an impending tsunami is an example of a practical implementation of an early warning system (Sobolev et al., 2007). This system was developed after the horrific tsunami that occurred as a result of the undersea earthquake in December 2004. The challenge in this system includes eliminating EWSs that are false positives. For instance, the difficulty of distinguishing whether an earthquake involves horizontal or vertical movement of the tectonic plates has posed problems for this system. The former movement is much more likely than the latter to cause a tsunami; however, detecting the direction of movement is less than precise in the system. This lack of precision resulted in several false alarms, such as the ones given in several Asian countries in April 2012 (Padma et al., 2012). In our study, rather than providing causal explanations of the event or scenario – in the tsunami case, the direction of the earth plate movement – we aim to focus on relating particular scenarios and thus provide valuable information to PMs to identify future project states and thus initiate necessary measures to avoid failures.
A review of the literature shows that there is no clear differentiation between causes, EWSs and early warning issues (EWIs) that allowed PMs to act upon EWSs and avoid reactions on false positive signals. Klakegg et al. (2010) appealed for industry/project-specific studies to ascertain the nature of EWSs in each industry/project. Apart from the intangible nature of software development, offshore-specific conditions further lower the visibility of EWSs in OOSD projects. Further, varying perception of project risks by PMs in culturally diverse settings called for an identification of EWSs of failures in OOSD projects to differentiate between causes, EWSs and EWIs. Although a few studies discuss EWSs in early stages of software development projects, the literature review reveals missing research regarding EWSs in the OOSD context. There is less research that touches upon onshore-offshore team relevant aspects, such as team coordination and collaboration, particularly involving onshore and offshore vendor teams. Therefore, this team-level research is valuable for practitioners and academics to uncover the specific EWSs of failures in OOSD projects, as well as the ability of PMs to perceive them correctly. The present study will concentrate specifically on the offshore-outsourced context and will provide a basis to understand the EWSs that point to project failures better.
Lack of failure research in offshore software projects, especially in the offshore-outsourced context, called for an exploratory research approach to study the EWSs of failure. We used qualitative analysis to understand the EWSs in OOSD projects. Although several studies deal with EWSs, none deal with offshore-outsourced projects and how responsible managers can perceive them. The failures in offshore outsourcing were also studied before; however, the study of the partially known phenomenon of OOSD project failures requires inductive reasoning (Stebbins, 2001) to understand the failure process. This qualitative exploratory investigation was done using the grounded theory methodology (Corbin and Strauss, 2008), which was the appropriate methodology to explore the EWSs prior to failure and how they are perceived by PMs. Considering the sensitivity of outsourcing failures and the consequent difficulty of gaining access to project details, this methodology allowed us to gain theoretical and practical insights. As allowed by grounded theory methodology (Corbin and Strauss, 2008), we have reviewed relevant literature before and after conducting our empirical research. The literature review after the empirical findings helped us to reconcile our findings with the state of knowledge in the area.
According to the taxonomy of IS theory types provided by Gregor (2006), the primary goals of theory include:
analysis and description;
Among these goals, our primary objective has been the analysis and description of EWS by identifying interrelations, especially in early project phases. Explanations or causal logic between constructs may not be established in their completeness in exploratory research. Project failures in IS cannot be predicted with precision, as any external or internal factor could bring a project to its downfall. Nevertheless, our aim has been to facilitate the application of theoretical knowledge gained through research to the profession of PMs.
Semi-structured interviews were used as the data collection technique to “obtain a rich, in-depth experiential account” of EWSs and the failure process (Fontana and Frey, 2000). This interview type has an incomplete script and allowed us to improvise questions to obtain rich details of failures (Myers and Newman, 2007). For interviews, we used the interview guide approach (Myers, 2008), i.e. we came to the interview with a set of open-ended questions that covered team and project contexts, as well as project issues, that guided the interview and also allowed substantial flexibility for interaction with the interviewee and for follow-up questions. The literature review supported the formulation of initial open-ended questions, especially from an agency theory perspective.
The PMs narrated the details of a major offshore software project failure in their careers. Information about important project episodes and event chains that described the failure process were obtained. The interviews were tape-recorded and transcribed, which resulted in a total of 255 pages of text. The average interview lasted around 1 h. The interview text was sent to the interviewed PMs for validation. The data analysis techniques we applied included the analysis of memos, series of events, critical incidents, content analysis and inductive analysis (Myers, 2008). The MAXQDA 10 software was used for data coding and analysis. The theoretical saturation of categories and concepts was reached after 19 project cases, as is required by the grounded theory approach (Corbin and Strauss, 2008).
Memos were written for each emerged concept in the initial analysis, and this was then further used for developing categories. The content analysis helped us to make sense of the events, issues and situations that were instrumental to project failures. It involves “the process of identifying, coding, and categorizing the primary patterns in the data” (Patton, 2002, p. 381). Open and axial coding schemes (Corbin and Strauss, 2008) were used to build thematic categories of data and to further understand the relationships between the emerging concepts and categories. By the use of open coding in the initial analysis, concepts were delineated from the data. Further, axial coding was used to relate the emerged concepts to each other. This process has resulted in the emergence of 91 concepts. In the concepts emerged, we applied inductive analysis to understand the patterns and relationships between concepts. The emerged concepts in the qualitative data analysis were then combined to develop theoretical relations about failures in the early stages of OOSD projects.
To study the failure process from the project team perspective, we included experienced PMs from the client and vendor sides in our research. The inclusion of both sides was important as they played equal roles in the project outcome. We contacted PMs involved in offshore software projects at major multinational organizations located in Switzerland and India with at least two years of OOSD project experience as the key informants for interviews. They were chosen as interviewees because they were the “most knowledgeable and qualified” stakeholders involved in failed projects (Glick et al., 1990). After interviews with initial contacts, we asked them to recommend other PMs with possible experience of failed OOSD projects for interviews, a technique called “snowballing” in qualitative research (Myers and Newman, 2007). Out of 42 interviews, we used only 19 of them (9 from the client and 10 from the vendor sides) for data analysis. The other 23 interviews were not used for analysis as those managers defined project failure in a manner different from our definition, which meant that their project cases did not qualify for inclusion within our narrow failure definition. These latter interview cases rather came under the categories of challenged projects (Standish, 1995) or nearshore projects on the same continent.
Table I offers background information about interviewees and shows the overall career experience of the interviewed PMs from both the client and the vendor sides. Although the median value of OOSD project failures was 1 for both clients and vendors, the higher standard deviation of client PMs (11.22) compared to vendor PMs (1.37) could reflect the differences in the project context for clients and vendors.
All project cases involved India as the offshore destination, and thus, this study can be considered India-centric. Table II provides an overview of the failed OOSD project cases. It denotes 19 interview cases referred to in this paper using the letters A-S in an anonymous manner (anonymity was assured to PMs as part of this research). A summary of the countries involved in failed OOSD projects, the industry where the project was executed and the cancelation phase during the project are also given in the table.
The typical phases of an offshore project include requirement analysis, design, coding and integration and testing. Most of the projects in the interviews limped along all the way to the integration and testing phase, where the final decision of project cancelation was taken. The project cancelation took place earlier only in cases F, M, and S; these were canceled in the requirement and analysis phase, where the lack of business benefits and project management capabilities were noted early during the execution.
4. Analysis and findings
4.1 Modeling early warning sign failures
Data analysis of project episodes and event chains that led to failure shows that there are different levels of warning signals in terms of noticeability. PMs could notice some EWSs of failure in the project directly and some of them indirectly. These different levels of perceptions allowed us to differentiate the concept of EWSs that have been discussed in the literature. The early issues that were noted by PMs in early stages and warned them of potential problems in the project are referred to as EWIs. An EWI is defined as an issue that threatens project success and requires attention in the first 20 per cent of the OOSD collaboration.
Most of the EWSs described in prior research (Nikander and Eloranta, 2001; Kappelman et al., 2006) can be subsumed into the category of EWIs. These EWIs are difficult for PMs to notice during the project. However, our data analyses show that some EWSs offer clear signals of impending project failure. We call them early signals of failure. Thus, an early signal is defined as a project indication or situation that provides concrete information about the early warning issue of failure during the first 20 per cent of the OOSD collaboration. Even though they appear as weak signals during the start of project collaboration, they indicate the development of EWIs in projects. A few EWSs identified by Nikander and Eloranta (2001), Havelka and Rajkumar (2006) and Kappelman et al. (2006) are actually early signals.
All EWIs identified in our study were accompanied by one or more early signals of failure. Therefore, we re-conceptualize EWSs as two components comprising EWI and one or more early signals of failure. However, there is no strict causal link between the appearance of signals of failure and EWI. Rather, we propose that EWIs of failure indicate the presence of one or more early signals of failure.
As early signals of failure are more visible, a manager can use it as a tool to identify the EWI.
Further, we found that even though early signals are more concrete for the PMs to identify during the project, they may not point unambiguously to an EWI. For instance, we noted that the early signal of missing interaction between vendor offshore and onsite teams could indicate that there exists a warning issue of lack of collaboration between vendor teams. This signal could, however, also mean that the vendor onshore team lacks the motivation to work with the vendor offshore team. Early warning issues may become distinct and noticeable as the project progresses. The presence of other early signals will then help PMs assign the early signals to a particular EWI of failure. This way, the PMs can clearly identify the EWS of failure as two components consisting of EWI and its early signals.
Figure 1 summarizes our findings in a model of the EWSs of failure and how they are related to project failures. This comprehensive model links EWS with the ultimate project failure, as exemplified in Project Case A: the vendor did not promptly address escalation. This was an early signal of the vendor not honoring deadlines – an EWI. One underlying cause for this behavior can be found in cultural differences regarding time conception: without giving due importance to agreed milestones, vendors considered fulfilling the tasks of primary importance, which was not appreciated by the client. This ultimately led to the failure issue of a slipped project schedule and project cancelation.
The example above points to three further constructs of a comprehensive model on EWS of failure: underlying causes of failure issues explain why actors show a behavior that leads to early warning issues. They typically also explain the behavior that leads to the failure issues that eventually lead to project failure. There is already a rather extensive literature on failure issues, their causation and project failure (Ewusi-Mensah, 2003). Our further analysis will therefore focus on the EWSs.
In the subsequent analysis, we analyzed the two components of EWS, namely, EWSs and EWIs of failures from project cases. Further, we constructed categories on the basis of concepts that we found by subsuming the particulars into general ones (Miles and Huberman, 1984). We discuss the five categories that emerged from this analysis: trust and team cohesion, common project execution structures, awareness of shared work context, collaboration between teams and onshore-offshore team coordination capabilities. These are explained in detail in the following sections.
4.2 Trust and team cohesion
In the semi-virtual onshore-offshore project environment, a project team that is aligned well and is glued together by a common objective form the basis of successful team performance. As timely face-to-face meetings between onshore and offshore teams are rare in the OOSD project context, an important role in avoiding project failures is played by the PMs’ initiatives to develop trust and cohesion within the team that includes members from onshore and offshore sites. We discuss below the EWSs of failure that we identified and are related to trust and team cohesion. An overview of the EWIs of failure regarding trust and team cohesion and their early signals is shown in Table III. The project cases from our analysis are provided in brackets.
Lack of trust between vendor and client teams is an EWI; this can show up as the lack of any appreciation by client team members for extra efforts made by vendor offshore members. In such scenarios, members of neither team will feel part of the project team, especially the offshore team members who are part of the extended team. In Project Case O, offshore team members were not treated with due respect by the client team, and this resulted in mistrust between teams. This showed up as the client team’s lack of appreciation of good work done by offshore team members and considering them as “software factory workers,” which denied them respect. Client team members’ concern regarding their job security could play a role in causing mistrust. Missing opportunities for informal conversations or online meetings could be an indicator of mistrust and warning sign of failure. Mutual trust between vendor and client teams was found to affect knowledge sharing and thus collaboration. This is particularly relevant in virtual or semi-virtual environments, where trust between counterparts plays a crucial factor in the team development and trust-building measures, such as face-to-face meetings and workshops, which rarely take place in OOSD projects.
Insufficient team cohesion or bonding is an EWI that leads to poor results within the team. The PM of Case P recalled insufficient team building efforts resulting in poor-team bonding and the functioning of the team:
At the expectation end, there was no need to build a team. By definition, there was no team charter. Then you have no contract or no rules being defined on how you will behave in presence of conflicts.
Other early signals include lack of project team kickoff meetings and lack of procedures to integrate new team members into the team.
4.3 Common project execution structures
A common understanding of the work practices within a project is a prerequisite for executing offshore-outsourced projects. These practices provide warning signs regarding the team’s development. The team behavior related to work practices is more associated with organizational and professional cultures rather the national culture. Such shared project practices or execution structures are required for successfully executing offshore projects.
Table IV provides an overview of the EWIs of failure that emerged from the project cases regarding project execution structures and their early signals. The lack of a common understanding regarding project deliverables could lead to significant gaps in terms of expectations. This will result from significant expectation gaps of deliverables between clients and vendors and also from missing explicit agreements regarding outputs in each project phase. In Project Case P, the lack of a common understanding of deliverables led to poor initial deliverables, which in turn eventually led to the cancelation of the project.
The vendor offshore team’s failure to honor deadlines will be shown up as missing deadlines by the team, as well as the failure to address escalations promptly. This issue was primarily found to have a cultural dimension to it as the sense of urgency and priorities assigned to the execution of tasks on a temporal scale could differ among global teams based on their perceptions of time. Saunders, Van Slyke and Vogel (2004) found that regions with predominant Hindu or Buddhist cultures, such as India, tend to view time as timeless (i.e. having a cyclical, recurrent, long-term and polychronic nature), whereas the Western vision of clock time characterizes time as having a linear, unidimensional, short-term and monochronic nature.
Lack of project management maturity could lead to missing agreements regarding the process of project execution. Onsite and offshore teams could have different concepts of project execution that lead to diverging outcomes. The PM of Case O remarked on missing project structures that led to a deadlock in the project: “…the lack of process or the key responsibility charged or responsibilities lead to the situation where people find no directions, whether they are supposed to do that or not.” PMs could note the differences in project execution when different methodologies are followed or when change management and documentation processes are not established. Software and hardware versions used at client and vendor sites that are not the same can also indicate diverging outcomes.
4.4 Awareness of shared work context
Differences in the shared work context among onsite and offshore teams affect the communication among team members, and the failure to recognize it and adapt the work practices accordingly will affect the project outcome. In the virtual working environment, the organizational culture and the work practices further exacerbate the situation that may prevent the emergence of a shared work context between onshore and offshore teams. Table V lists the EWSs of failure regarding shared context awareness along with their early signals.
An issue raised by the client may not be handled seriously by vendors, as the vendors may have different time perceptions and priorities. The early signals of this EWI include assurances of normality by the vendor and promises that everything will be perfect with the next deliverable. Further, repeated expectation gaps in agreed deliverables could be considered as an indicator that the project could be heading for trouble. The deliverables got worse in Project Cases A and B after the assurances from the vendor’s onsite managers. When the client team cannot check the progress of development at the offshore site, escalations are anticipated to be followed up with expected results. The failure to meet the client demands could result in situations that damage the trust between teams and the onsite teams’ motivation to work with their counterparts.
Lack of openness to discuss problems or delays within the project to the client team by the Indian offshore team was found to be an EWI that affects the project execution. The indicators of this EWI include deliverable delays not being communicated in advance and not openly admitting technical problems or mistakes during the project.
Lacking organizational and professional cultural intelligence regarding the other team result in a situation with missing awareness of shared work context. One possible signal is the lack of initiative to ask questions or challenge requirements by vendor offshore team members. This reluctance to question could be rooted in an unwillingness to show “disrespect” to the client, keep the team hierarchy in projects or in a wish to protect the dignity of one’s team or the client. The cultural intelligence of team members was found to positively affect project execution and thus the outcome. The PM of Case C remarked the difficulty of collaboration as follows, which acted as an early signal of project failure:
And the reason is that I think that the teams over there are very hierarchical, they have their internal structure of importance and of the supervision and it’s difficult to flatten that.
Vendor offshore team members might not talk openly in the presence of their superiors during a meeting or workshop. This is because of the hierarchies and social structures followed in the team. The silence of vendor team members in Project Case B was interpreted by the client PM as a normal project situation. However, the client realized this team dynamic only later after the first poor delivery, in which the offshore team did not demonstrate an understanding of requirements.
4.5 Collaboration between teams
The lack of adequate collaboration between vendor teams at onshore and offshore sites, as well as between vendor and client teams, has emerged as one of the EWSs of failure relevant in the OOSD project context in our research. Collaborative processes on the inter-team level during the early project phases improve the team bonds and thus positively affect team trust and performance. Table VI provides an overview of the EWIs of failure and their early signals that emerged from the project cases regarding the collaboration between teams.
Collaboration between vendor’s onshore and offshore teams can be inadequate or missing, and that can lead to the project team missing the project objectives. This issue can be noticed from the lack of regular meetings or interactions between the vendor’s offshore and onsite teams. Even though both teams are part of the project, they may not feel the need for collaboration. Such a situation could result if both vendor organizations operate independently and the offshore team will be expected to deliver by default.
A communication structure within the teams forms the prerequisite to efficient collaboration. An indicator of this missing structure would be an undefined path for communication that leads to communication breakdown in the team. In Project Case O, the offshore client PM noted the following regarding communication and alignment in the project:
It [communication] was not to the level where it should have happened. Of course, there was some communication, ad-hoc communication, but there was no formal team-based communication. So that was one of the reasons, which resulted in a situation where the offshore team was truly getting misaligned with the complete project objectives.
Another signal for the lack of communication structure is missing interactions between the client and vendor teams.
Another EWI that emerged from the analyzed data of project cases was the lack of collaboration know-how between teams. The vendor onsite team could also expect that they would receive the deliverables based on specifications on an agreed deadline without much interaction in between. Early signals of this misguided assumption include the lack of regular meetings online and the lack of knowledge feedback mechanisms, such as quizzes or verification of vendor’s written documentation. Furthermore, the inability to invest effort in identifying dependencies in knowledge areas and the blocking of questions from the vendor offshore team by the vendor onsite team are further signals of this wrong assumption.
4.6 Onshore-offshore team coordination capabilities
One of the capabilities that has emerged as crucial to executing the OOSD project successfully is the onshore-offshore team management by both the client and vendor organizations. In the onshore-offshore organizational setup, the vendor offshore team acts as an extended arm of the vendor onshore team. Therefore, it is imperative that both client teams acquire this capability to manage teams, knowledge and deliverables. Table VII summarizes the EWIs of failure and their accompanying early signals regarding onshore-offshore team coordination.
Lack of team coordination know-how in the OOSD project context can result in projects getting out of hand, and thus derailing the timeline, budget and quality expectations. If neither the client nor the vendor has PMs with experience in distributed or virtual environments, problems could be challenging to head off. Project management know-how by the client was identified as important for, and relevant to, offshore project success by Iacovou and Nakatsu (2008). However, our research shows the need for both clients and vendors to possess team coordination capabilities. Further early signals of failure include the absence of shared project plans at client and vendor locations and a lack of an integrated organization chart with defined team members to contact for queries. The size of the project team at the offshore site is another signal of challenged team management. Offshore delivery or PMs can become overwhelmed if they manage more than ten employees.
The knowledge coordination across sites is a challenge for PMs at different locations. The achievement of mutual knowledge levels between onshore and offshore teams was found to be difficult in our project cases. This is because dispersed teams cross cultural and organizational boundaries can amplify the feedback lags regarding information exchange and interpretation. This information lag in turn leads to misinterpretation of embedded and tacit knowledge by offshore members, which then results in incorrect deliverables. An early signal of this knowledge transfer issue to the offshore team comes from knowledge feedback mechanisms that can verify the transferred knowledge and thus reveal the lack of proper understanding on the offshore side. In particular, complex knowledge transfer requires intensive feedback loops. Project case Q was canceled because the vendor offshore and onshore teams lacked interactions in addition to knowledge feedback mechanisms.
5. Conclusions and discussion
In this paper, we attempted to study the EWSs of failure that occur in OOSD projects at the team level. Further, we also explored how they are perceived by PMs.
Our model of EWSs of failure and project failure (Figure 1) provides exploratory insights into the failure process of OOSD projects. This exploratory model is an extension of the EWS concept developed by Nikander and Eloranta (2001). The indicative links related to the EWSs and project failures were extended, and the concept of EWSs of failure was further elaborated to serve as a tool for PMs to manage EWSs in OOSD and non-OOSD contexts.
Analyzing the early warnings in the first 20 per cent of project collaboration, an extension of idea put forward by Kappelman et al. (2006), we characterized the EWSs of failure in the OOSD project context. Further, we found that the EWSs of failure can be perceived by PMs by looking for the presence of early signals of failure during the early project stages. Our analysis found that the EWSs of failure is composed of two parts: EWIs and early signals of failure. This differentiation of EWSs forms a main contribution of this exploratory work to understand the early stages of project failure. The identification of the more concrete early signals together with the check for the emergence of EWI allows PMs to confirm the existence of EWSs of failure and also eliminate the possibilities of false positive signals. Williams et al. (2012) maintain that PMs are generally not good at picking up EWSs during the project. Nevertheless, our concept of EWSs of failure could possibly allow PMs to notice them before the issues appear turn into failure issues in the later phases.
Imperfect monitoring posed by offshore-specific context, as well as higher risk, could explain why EWSs can be best identified as two components in OOSD projects. As stated by the principal-agent theory [that is, both actors will have difficulties to attain the same state of knowledge (Ansoff, 1984)], PMs could also find it difficult to identify EWSs in time during the project. Especially, as vendors possess private information that clients do not have access to, the state of knowledge will improve only with unfolding situations or events (Baiman, 1990). This means that clients will have to put in more effort for reducing the information asymmetries as a result of differing behaviors related to uncertainty, risk aversion and measurability. This research contributes to the risk management stream by identifying the early project risks through EWSs of failure, in which the principal-agent theory explains the inherent difficulties to attain the same state of knowledge among actors. There are several implications from this research, which we discuss below.
5.1 Implications for research and practice
This study laid an exploratory foundation for an improved understanding of the nature of EWSs by discovering a dual composition – early signals and EWIs of failure – that can be used to institutionalize an early warning mechanism to act upon in software projects. The identification of EWIs and early signals provides advance information about project risks. However, the information regarding the probability and the impact of potential issues are traditionally handled by risk management measures (Nikander, 2002). EWSs of failure can be used as a tool in risk management. This early risk perception tool could be applied in conjunction with project assessment measures, such as project reviews, project health checks and benchmarking (Williams et al., 2012). EWS detection mechanism for risk identification and management can be integrated with other risk management tools such as check lists, balanced scorecards and “traffic lights” (Williams et al., 2012). The use of a risk management instrument that involves EWSs would be particularly helpful in outsourced projects, as these projects experience greater risks than in-house ones.
Our analysis has shown that many issues were hard issues of technical nature and can be measured to a great extent. Soft issues, on the other hand, are difficult to measure as they include people issues related to culture, such as behavior, attitudes and values. Among the EWIs that were found in our study, the category of soft issues included matters such as absence of trust between vendor and client teams, lack of openness to discuss problems by the vendor offshore team and a dearth of trust between client and vendor offshore teams. Williams et al. (2012, p. 47) maintain further that addressing soft issues requires “broad experience and a deep understanding of both objectives and culture” from PMs. The level of PMs’ onshore-offshore team management capability and the ability to notice soft issues could be of interest to practitioners and requires further analysis. Cultural intelligence in terms of national, organizational and professional cultures across onshore and offshore teams could alert PMs to the EWSs that are of a soft nature. The presence of EWSs related to cultural orientations in our study further points to the importance of OOSD projects attaining onshore-offshore team management capabilities.
Among the five categories of EWSs of failure identified in this study, the categories of onshore-offshore team coordination and collaboration between teams are the least discussed in the literature. We found that onshore-offshore team coordination is a particularly important aspect. Particularly, addressing both the client and vendor’s – not just the client’s – capability to coordinate onshore-offshore teams was key for avoiding failures. The IS offshoring literature (Lacity et al., 2010; Wiener et al., 2010) mainly discussed the collaboration between the client and vendor offshore teams. However, we found that the interaction between the vendor’s onshore and offshore teams is an area that requires further research to provide insights into the work practices and organizational cultures that impede collaboration. Furthermore, the lack of adequate collaboration between the vendor’s onshore and offshore teams was another area that lacks research because of confidentiality agreements between clients and vendors, as well as language problems (Vlaar et al., 2008).
From the practitioner perspective, the EWSs of failure with its five categories can be considered as a general framework in projects that could be adapted depending on the national and organizational set-ups in the project. Particularly, among the five categories of EWSs in our research, the categories of shared project execution structures and team collaboration related to organizational practices and national values could be further adapted to the organizational settings and national differences to monitor the EWSs in projects. This is mainly because project risks are perceived differently by PMs on different continents (Schmidt et al., 2001).
Klakegg et al.’s (2010) call for industry/project specific studies deserved particular attention to the software industry because of the difference in the visibility of EWSs determined by their intensity, duration and subtlety (Loosemore, 2000) compared to, for instance, the construction industry. Because of imperfect control in offshore-outsourced projects and the intangible nature of software development, the software industry is characterized by high project failures (compared to the original objectives) as a result of relatively low visibility of EWSs. Hence, the identification and management of EWSs provides a managerial tool for understanding the risks and issues that lead to failures.
The EWSs of failure are primarily meant as an indicative framework, rather than providing a causal explanation of failures. This is because the utility of an indicative instrument is better in an exploratory field where research is scanty. As found by Williams et al. (2012), the behavioral complexities of team members mean that the causal relationships between the causes of failures and EWSs are not obvious. Our model of EWSs of failure and project failure focuses on the indications between constructs in an exploratory context rather than on providing well-developed causal explanations of each construct (Gregor, 2006).
We studied project failures from the OOSD project team perspective that was composed of client onshore, vendor offshore and vendor onshore teams. All team members from the client and vendor sides need to realize the need to establish an integrated project team and to work toward it to avoid failures. This means that each team would need to understand the national, organizational and professional cultures of the other teams in different countries for the project team to develop a shared understanding and shared work practices.
5.2 Limitations and areas of further research
Our research has contributed to IS failure, IT outsourcing and risk management streams. However, as in every research endeavor, this study has its own limitations and requires further studies in several directions.
Our research has shed light on offshore-outsourced project failures, which is a relatively uncharted area of investigation. We concentrated on India-specific projects, which is the primary weakness of this work, as it causes our data to be limited by the homogenous organizational culture on the vendor side. Therefore, the research results may not be entirely generalizable (Glick et al., 1990). Nevertheless, it was decided to anchor the data to Indian development projects as an exploratory endeavor. This choice to concentrate on India is because this country is the most dominant IT offshoring nation (Oshri et al., 2011). Further research could include other mature and emerging software development countries to improve the generalizability of results.
PMs were chosen as the key informants as they are the most knowledgeable persons involved in failed projects, which is a source of informant bias. The triangulation of failure data in projects with other project sponsors, project team members or the vendor or client counterparts could have improved the validity of our results. However, because of the sensitivity involved in failure research, especially in outsourced failures, getting PMs to agree to tape-recorded interviews was a very difficult job. To follow up with validation from counterparts in other organizations proved to be an impossible task. If practitioners and researchers succeed in establishing trust and convincing clients and vendors of the benefits of conducting research covering both sides, ideally, a case study research would shed valuable light on the dynamics behind client-vendor offshore and vendor onshore teams. The processes behind project failures could be better understood through case study research, which would also allow triangulation of data and thus improve the validity of qualitative research. Furthermore, interviews involving detailed retrospective narration of projects are prone to recollection errors. However, to minimize the recollection errors (Glick et al., 1990), PMs were asked to focus on major events and issues involved in two major projects in their career, one failed and one successful, and to choose projects that could be narrated with greater ease than other projects.
This research served the purpose of identifying and establishing the existence of EWSs in the offshore-outsourced context. This existence could be researched further by validating the identified EWSs by using a broad survey among PMs involved in OOSD projects. An important aspect in such a survey would be the verification of the usefulness and effectiveness of EWSs in the onshore-offshore project context by using successful and failed projects. The extent to which offshore-specific risks influence the effectiveness of the early warning mechanisms to manage EWSs could be explored as well.
Because we focused on exploring EWSs regarding project failures, we did not analyze further causal relationships that explain team development and performance. This includes the relationships among the five categories found in this research. A theory of explanation (Gregor, 2006) could be developed further by expanding the categories, provided both the vendor and client sides agree to become part of a research. The model of the EWSs of failure could be further extended by providing well-developed causal explanations between the constructs. Furthermore, analysis of inter-organizational and professional work practices, as well as the cultural negotiations that take place between the teams involved, could be fruitful future directions to take so as to advance causal theoretical models.
Finally, our research found mostly hard issues that can be measured during the project. The EWSs of failure also appear as soft issues that are identified using gut feelings. The identification of soft issues requires in-depth experience and a thorough understanding of the project environment. Even though we elicited the experiences of PMs in terms of IT, project management and offshore project management experiences, we could not establish a direct link between their experiences and their ability to perceive and manage soft issues in OOSD projects. Research on soft issues requires a deeper analysis of interpersonal effects across organizational and national boundaries. It would be of great interest to practitioners to study the extent to which such capabilities affect PMs’ ability and maturity to execute OOSD projects.
Overall career experience of PMs
|No. of interviewed PMs||9||10|
|IT-related (average years)||16.56||15.22|
|OOSD project (average years)||8.33||9.56|
|Project management (average years)||11.11||8.56|
|OOSD project management (average years)||7.22||6.11|
|Median (standard deviation) of OOSD failures||1 (11.22)||1 (1.37)|
|Median (standard deviation) of OOSD successes||12 (21.02)||5.5 (16.08)|
Failed project cases
|Interview cases||Countries involved||Industry||Cancelation phase|
|A||Germany, India, Switzerland||Power generation||Integration and testing|
|B||India, Switzerland||Banking||Integration and testing|
|C||India, Switzerland||Insurance||Integration and testing|
|D||India, Switzerland||Banking||Integration and testing|
|E||India, Switzerland||Banking||Integration and testing|
|F||India, Switzerland||Insurance||Requirement analysis|
|G||India, Switzerland||Banking||Integration and testing|
|H||India, Singapore, Switzerland||Banking||Integration and testing|
|I||India, Switzerland||Air transport||Integration and testing|
|J||Germany, India, Switzerland||Insurance||Integration and testing|
|K||India, Switzerland||Banking||Integration and testing|
|L||India, USA||Automotive||Integration and testing|
|M||India, Switzerland, USA||Insurance||Requirement analysis|
|N||Germany, India, Switzerland||Public sector||Integration and testing|
|O||Germany, India||Automotive||Integration and testing|
|P||India, Switzerland||Public sector||Integration and testing|
|Q||India, Switzerland||Insurance||Integration and testing|
|R||India, Switzerland||Air transport||Integration and testing|
|S||India, Canada, Switzerland||Insurance||Requirement analysis|
Trust and team cohesion
|Early warning issues||Early signals|
|Lack of trust between vendor and client teams [A, B, N, O]||Client team do not appreciate extra efforts put in by vendor offshore team [O]
Lack of opportunities for informal interactions [N, O]
Significant expectation gaps in technical deliverables [A, B]
|Insufficient team cohesion [D, K, N, P]||Managers do not set up regular meetings involving onshore and offshore teams [K, P]
Lack of project team kickoff meetings [D]
Lack of procedures to integrate new team members [N]
Common project execution structures
|Early warning issues||Early signals|
|Lack of common understanding about deliverables [A, J, L, P]||Significant expectation gaps in deliverables [A, J, P]
Lack of explicitly agreed project outputs [L]
|Vendor offshore team fails to honor agreements [A, I, J, L]||Deadlines not met by vendor offshore team [I, J, L]
Escalations not addressed promptly [A]
|Lack of shared concepts for project execution [D, G, K, O]||Vendor and client teams have different methodologies, documentation, and change management processes [D, O]
Lack of identical software and hardware versions at client and offshore sites [G, K]
Awareness of shared work context
|Early warning issues||Early signals|
|Vendor does not react appropriately on escalations [A, B]||Assurance of normality by vendor when issues are raised [B]
Repeated expectation gaps in deliverables [A]
|Lack of openness to discuss problems by vendor offshore team [A, I]||Delays of deliverables not communicated in advance [A]
Non-admission of technical problems or mistakes [I]
|Insufficient cultural intelligence among vendor and client teams [I, L, R]||Vendor offshore team members do not challenge requirements [I, L]
Vendor offshore team members do not talk openly in meetings in the presence of superior [C, R]
Collaboration between teams
|Early warning issues||Early signals|
|Lack of collaboration between vendor teams [B, N, O]||Lack of regular meetings [B, N, O]
Missing interaction between vendor offshore and onsite teams [B, O]
Vendor offshore and onsite teams are part of independent organizations and both are not integrated into the project [B]
|Lack of agreed communication structures between vendor and client teams [C, N, O]||Communication paths are not clear for team members [C, N]
Lack of interactions between client and vendor teams [N, O]
|Lack of collaboration know how [N, O, P, Q]||Teams do not hold regular meetings [N]
Teams do not apply knowledge feedback mechanisms [P, Q]
Complex knowledge areas not identified [O]
Questions from vendor offshore team are blocked by vendor onsite team [N, P]
Onshore-offshore team coordination
|Early warning issues||Early signals|
|Lack of onshore-offshore team coordination know-how by client and vendor [B, E, F, M, N]||Team members do not use a shared project plan [F, M]
Team members do not use an integrated organization chart with defined contact persons [F]
Vendor offshore managers manage too large teams [B, N]
|Vendor onsite team fails to transfer knowledge to offshore team properly [H, N]||Knowledge feedback mechanism shows lack of understanding by vendor offshore team [H, N]|
Ansoff, H.I. (1975), “Managing strategic surprise by response to weak signals”, California Management Review, Vol. 18 No. 2, pp. 21-33.
Ansoff, H.I. (1984), Implanting Strategic Management, Prentice Hall, New York, NY.
Apte, U.M. and Mason, R.O. (1995), “Global disaggregation of information-intensive services”, Management Science, Vol. 41 No. 7, pp. 1250-1262.
Baiman, S. (1990), “Agency research in managerial accounting: a second look”, Accounting, Organizations and Society, Vol. 15 No. 4, pp. 341-371.
Corbin, J. and Strauss, A. (2008), Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory, 3rd edn, Sage Publications, Los Angeles.
Cule, P., Schmidt, R., Lyytinen, K. and Keil, M. (2000), “Strategies for heading off IS project failure”, Information Systems Management, Vol. 17 No. 2, pp. 1-9.
Dibbern, J., Winkler, J. and Heinzl, A. (2008), “Explaining variations in client extra costs between software projects offshored to India”, MIS Quarterly, Vol. 32 No. 2, pp. 333-366.
Eisenhardt, K.M. (1989), “Agency theory: an assessment and review”, Academy of Management Review, Vol. 14 No. 1, pp. 57-74.
Ewusi-Mensah, K. (2003), Software Development Failures: anatomy of Abandoned Projects, MIT Press, Cambridge.
Fontana, A. and Frey, J.H. (2000), “The interview: from structured questions to negotiated text”, in Denzin, N. and Lincoln, Y. (Eds), Handbook of Qualitative Research, 2nd edn, Sage Publications, Thousand Oaks.
Glick, W.H., Huber, G.P., Miller, C.C., Doty, D.H. and Sutcliffe, K.M. (1990), “Studying changes in organizational design and effectiveness: retrospective event histories and periodic assessments”, Organization Science, Vol. 1 No. 3, pp. 293-312.
Gregor, S. (2006), “The nature of theory in information systems”, MIS Quarterly, Vol. 30 No. 3, pp. 611-642.
Havelka, D. and Rajkumar, T.M. (2006), “Using the troubled project recovery framework: problem recognition and decision to recover”, E-Service Journal, Vol. 5 No. 1, pp. 43-73.
Hofstede, G., Neuijen, B., Ohayv, D.D. and Sanders, G. (1990), “Measuring organizational cultures: a qualitative and quantitative study across twenty cases”, Administrative Science Quarterly, Vol. 35 No. 2, pp. 286-316.
Hughes, D.L., Dwivedi, Y.K., Rana, N.P. and Simintiras, A.C. (2016), “Information systems project failure – analysis of causal links using interpretive structural modelling”, Production Planning & Control, Vol. 27 No. 16, pp. 1313-1333.
Iacovou, C.L. and Nakatsu, R. (2008), “A risk profile of offshore-outsourced development projects”, Communications of the ACM, Vol. 51 No. 6, pp. 89-94.
Kappelman, L.A., McKeeman, R. and Zhang, L. (2006), “Early warning signs of IT project failure: the dominant dozen”, Information Systems Management, Vol. 23 No. 4, pp. 31-36.
Keil, M., Cule, P.E., Lyytinen, K. and Schmidt, R.C. (1998), “A framework for identifying software project risks”, Communications of the ACM, Vol. 41 No. 11, pp. 76-83.
Kern, T. and Willcocks, L. (2000), “Exploring information technology outsourcing relationships: theory and practice”, The Journal of Strategic Information Systems, Vol. 9 No. 4, pp. 321-350.
Klakegg, O.J., Williams, T., Walker, D., Andersen, B. and Magnussen, O.M. (2010), Early Warning Signs in Complex Projects, Project Management Institute, Newtown Square.
Knippenberg, D. and Schie, E. (2000), “Foci and correlates of organizational identification”, Journal of Occupational and Organizational Psychology, Vol. 73 No. 2, pp. 137-147.
Lacity, M.C., Khan, S., Yan, A. and Willcocks, L.P. (2010), “A review of the IT outsourcing empirical literature and future research directions”, Journal of Information Technology, Vol. 25 No. 4, pp. 395-433.
Loosemore, M. (2000), Crisis Management in Construction Projects, American Society of Civil Engineers, Danvers.
Miles, M.B. and Huberman, A.M. (1984), Qualitative Data Analysis: A Sourcebook of New Methods, Sage Publications, Beverly Hills.
Myers, M.D. (2008), Qualitative Research in Business and Management, Sage Publications, London.
Myers, M.D. and Newman, M. (2007), “The qualitative interview in IS research: examining the craft”, Information and Organization, Vol. 17 No. 1, pp. 2-26.
Nikander, I.O. (2002), Early Warnings: A Phenomenon in Project Management, Helsinki University of Technology, Helsinki.
Nikander, I.O. and Eloranta, E. (2001), “Project management by early warnings”, International Journal of Project Management, Vol. 19 No. 7, pp. 385-399.
Oshri, I., Kotlarsky, J. and Willcocks, L. (2011), The Handbook of Global Outsourcing and Offshoring, 2nd edn, Palgrave Macmillan, Hampshire.
Padma, T., Daniel, S. and Yamin, K. (2012), “Asian Tsunami Alert Systems ‘pass Major Test’”, SciDev.net.
Patton, M.Q. (2002), Qualitative Research and Evaluation Methods, 3rd edn, Sage Publications, Thousand Oaks, CA.
Philip, T., Schwabe, G. and Wende, E. (2010), “Identifying early warning signs of failures in offshore software development projects - a Delphi survey”, Proceedings of the 16th Americas Conference on Information Systems, Lima.
Pinto, J.K. and Mantel, S.J. (1990), “The causes of project failure”, IEEE Transactions on Engineering Management, Vol. 37 No. 4, pp. 269-276.
Ross, S.A. (1973), “The economic theory of agency: the principal’s problem”, The American Economic Review, Vol. 63 No. 2, pp. 134-139.
Rottman, J. and Lacity, M. (2008), “A US client’s learning from outsourcing IT work offshore”, Information Systems Frontiers, Vol. 10 No. 2, pp. 259-275.
Sahay, S., Nicholson, B. and Krishna, S. (2003), Global IT Outsourcing: Software Development Across Borders, Cambridge University Press, Cambridge.
Sakthivel, S. (2007), “Managing risk in offshore systems development”, Communications of the ACM, Vol. 50 No. 4, pp. 69-75.
Saunders, C., Van Slyke, C. and Vogel, D.R. (2004), “My time or yours? Managing time visions in global virtual teams”, Academy of Management Perspectives, Vol. 18 No. 1, pp. 19-31.
Schmidt, R., Lyytinen, K., Keil, M. and Cule, P. (2001), “Identifying software project risks: an international Delphi study”, Journal of Management Information Systems, Vol. 17 No. 4, pp. 5-36.
Sobolev, S.V., Babeyko, A.Y., Wang, R., Hoechner, A., Galas, R., Rothacher, M., Sein, D.V., Schröter, J., Lauterjung, J. and Subarya, C. (2007), “Tsunami early warning using GPS-shield arrays”, Journal of Geophysical Research, Vol. 112 No. B8, pp. 1-18.
Soderberg, A.M., Krishna, S. and Bjorn, P. (2013), “Global software development: commitment, trust and cultural sensitivity in strategic partnerships”, Journal of International Management, Vol. 19 No. 4, pp. 347-361.
Standish (1995), The CHAOS Report into Project Failure, The Standish Group International, Boston.
Stebbins, R.A. (2001), Exploratory Research in the Social Sciences, Sage Publications, New York.
Thamhain, H. (2013), “Managing risks in complex projects”, Project Management Journal, Vol. 44 No. 2, pp. 20-35.
Vashistha, A. and Vashistha, A. (2005), The Offshore Nation: The Rise of Services Globalization, Tata McGraw-Hill Publishing Company, New York, NY.
Vlaar, P.W.L., van Fenema, P.C. and Tiwari, V. (2008), “Cocreating understanding and value in distributed work: how members of onsite and offshore vendor teams give, make, demand, and break sense”, MIS Quarterly, Vol. 32 No. 2, pp. 227-255.
Wiener, M., Vogel, B. and Amberg, M. (2010), “Information systems offshoring – a literature review and analysis”, Information Systems, Vol. 27 No. 1, pp. 455-492.
Williams, T., Jonny Klakegg, O., Walker, D.H.T., Andersen, B. and Morten Magnussen, O. (2012), “Identifying and acting on early warning signs in complex projects”, Project Management Journal, Vol. 43 No. 2, pp. 37-53.