“Culture is one thing and varnish is another.”

recognize that although many risk factors are shared between outsourced and local projects, there are some challenges that allegedly face offshore projects uniquely, for instance:

Lack of interaction between team members

Unclear responsibilities

Unmanaged conflict

Scope creep, no prioritization of change requests

Inadequate feedback on cost and schedule (mal-) performance

Conflicting standards of coding, behaviour, decision making- and communication procedures Animosity, historical or economical, between nationalities, cultures, institutions, etc.

Kliem (2004) nicely explicates the relationship between these risks and the geographically, culturally and institutionally dispersed nature of outsource software development, in such a way that it becomes possible to see geography, culture and institution as accounts of the order of globally outsourced software development, and in this respect, the expression of and manifestation of certain properties of such projects, rather than the other way around. And that is exactly what the most important contribution of this paper is. There is perhaps a cultural difference, but not been the East and the West (significantly), rather it is within “understanding of requirements communication culture” (a quote from one of the managers in our case). Bearing in mind that although there are (always) complaints raised from developers against ‘sales’, about the poor quality of specifications and the lack of change management, it is interesting that they are still, on both sides of the ‘cultural divide’, comfortable with the performance of the projects versus the requirements.

The rationalization of the software process has deep historical roots, and there are at least two clear lineages of thinking that can be read from the conceptualization of distributed and locally organized project models alike; namely that software engineering is about translation from one representation to another and that this is a “lossless” function (Kyle 2002), and, that it can, indeed, in a reductionist fashion be subdivided into clearly packaged units of work onto which other units of work can build via well-defined interfaces (Raccoon 1997). In opposition to such decisive, early software engineering philosophies, is not groundbreaking in itself to maintain that software engineering might not be rationalizable in a traditional sense (Ilavarasan and Arun Kumar 2003):

“Software work stands as less saturated work. Even if tasks are relatively integrated, complete closure of spaces for play in the structure of skills is difficult to achieve. That is, the worker has enough space to use his creativity and imagination in the work (ibid p. 4).”

One might look at propositions of synching, using “straddlers” and building bridging relationships as more subtle expressions of the same fundamental view on software engineering as a “downstream” process of distinct stages (Heeks et al. 2001). We have found it useful to turn the perspective of outsourcing strategies around. As a complement to trying to find out which strategy can be applied to the outsourcing scenario in order to make it more likely to succeed (Akmanligil and Palvia 2004), or how to select the exact location for development work given a project characteristic (Graf and Mudambi 2005), is would useful instead to find out which project characteristic or outsourcing strategy that comes out of a certain set of globally distributed working relationships.

This paper points toward revising the risk identification framework proposed by Keil et al. (1998) so that it can be used for a broader set of projects, including horizontal applications and innovative services for the mobile consumer. Even more importantly, this paper indicates that it is time (again) to start thinking about software engineering not as a process of translating requirements into a running system, but as a social and creative arena in which customers and developers meet to discuss and implement ideas, which might originate equally from developers as well as customers; regardless of programmers being from one part of the world or the other.