“Culture is one thing and varnish is another.”

complex, unpredictable, and variable in terms of requirements and circumstances of use (The British Computer Society12). Motivation seems ample, therefore, to examine aspects of offshore outsourcing in terms of dimensions that are common to software engineering research in general.

The most important finding of the research reported in this paper is that when developing new services for the telecommunications infotainment market (quite horizontally), the “first requirement” is to be able to accommodate continually changing requirements and scope, as and when the product adapts to malleable value chains, new technologies and aggregating layers of agents and actors in the service architecture. This is the one requirement that does not change. Outsourcing developers complain about the lack of specifications, and thus implicate that they, indeed, expect to be able to get them. This we see as an expression of distributed projects naively subjected to a “scientific” organization of work (Taylor 1911). This is an analogy to many historical attempts to conceive of applications development as a “software factory” in a true perspective of reductionism. The outsourcing organization responds to that by accounting for their achievements (and underachievements, for that matter) in terms that are relevant to this idealized organization of work.

Outsourcing works, though, in this particular organization as in most others. There is really no indication that performance is any worse than in non-outsourced collaborative projects (Bruce, Leverick and Littler 1995). It should not be seen as working well despite a local order of software engineering wherein which project managers and developers contribute to formulate the specifications when they themselves need them. Quite the opposite, it works because project managers and developers are involved in writing specifications, meeting the customer when:

“It is difficult for the customer to make himself understood, so the spec is often not enough. It is essential to meet him face-to-face, from time to time (quote from project manager).”

Of course this goes against a fundamental principle of outsourced development, and usually the recommendation is to make sure requirements do not “creep” and that management of the project is strong “within”. This paper might be taken as an indication that such recommendations are part of the problem, rather than the solution.

The next section deals briefly with risk management as one pivotal aspect of understanding software engineering. After that, the methodological perspective underlying the analysis of this paper is presented. We are aware that using an ethnomethodologically influenced approach to a hybrid approach of web-based questionnaires, albeit not at this stage primarily intended to be read quantitatively, and face-to-face interviews, might encounter opposition. Our hope is that it can be appreciated as a contribution in its own right, almost orthogonally to the rest of the paper. Section 4 presents the empirical results, before the discussion concludes the paper.

2 RISK MANAGEMENT

The notion of risk management has historically been at the core of software engineering methodologies, and indeed, many of the implicitly anticipated problems of globally outsourced software projects, such as lacking management commitment, poor requirements definition and change management, communication problems and not having a clear and explicit process model, are commonly held as important risks in the field (Boehm 1991; Lyytinen, Mathiassen and Ropponen 1998). We are interested therefore, to see how actors involved in global outsourcing formulate notions of risk. Selecting one seminal article to compare our findings (Keil et al. 1998), we explore the differences. It is not our intention to pre-empt eventual differences in the perspectives of researchers concerned with traditional IS or mobile services and global outsourcing, respectively, at least not in an absolute sense. That is why we have not surveyed the complete literature on risk management. Neither is it the focus of this paper to extract a representative set of risk assessments from people involved in distributed projects. Therefore, it has not been necessary to investigate the opinions in managers across several companies. The ambition of this paper is more modest; to look at members’ own accounts of risk factors in globally distributed software development, in order to characterize the situation as seen 12 /NR/rdonlyres/3B36137E-C5FE-487B-A18B-4D7281D88EF7/0/complexity.pdf