“Culture is one thing and varnish is another.”

importance to risk management (including the role of new technology), but mean by it quite different things.

Interestingly, Keil et al.’s respondents put great emphasis in the detailed and stable set of requirements, as do our respondents. They claim that “requirements drive the entire project”. This is also something that implicitly underlies the request for better requirements from our project managers, however, we find notably that “our” project are successful in terms of time, quality and even “meeting the requirements” even in the alleged absence of such requirements.

Does this indicate that our case is poorly representing the outsourcing situation of most companies, then, since the projects described here are at least perceived as highly innovative? Intuitively and sometimes even claimed by members, the degree of innovation in a project is an important determinant in the outsourcing decision. There exists, however, empirical evidence that exactly the opposite is the case:

“We expected that firms that invest heavily in R&D pursue innovation, seek long-term profits, and aggressively undertake risky initiatives, and therefore are likely to develop IT systems internally rather than purchase them through the market. The results indicate exactly the opposite; that is, the greater the intensity in R&D, the higher the propensity to outsource IT (Oh 2005).”

We maintain, therefore, that our findings are representative and relevant. It indicates on the other hand, perhaps, that the instrument by which risks are measured and categorized provide insufficient coverage of innovative projects. One of the most emphasized findings from Keil et al.’s study is that the risk that managers believed to be most important was also the ones most often not under their direct control (Keil et al. 1998). Even more clearly, they organize their findings in a conceptual framework comprising two dimensions, perceived relative importance of risk and perceived level of control, and most of the risk factors which scored highly on both dimension could be seen as pertaining to the requirements definition of the project. But in the cases that we describe here, exactly the opposite is the case, requirements are completely beyond the development organization’s control. For instance, for one customer in China, the value network comprises up to five layers of agents which each of them might get a cut from each others’ revenue. Each layer will influence the ‘requirements’ and contribute to drift in the project, and this is not a factor that should be seen as external to the project, is it ‘part-and-parcel’ of doing software engineering in this case.

We believe we have shown that in these projects, requirements should not be seen as changing; the product of the organization that we have studied is exactly about being able to change the product underway and this is a stable requirement. This is consistent with managers’ claim that:

“The requirement is always the same: produce an innovative and effective product!”

The software industry is taking on new challenges in terms of the type of projects, products and services that they target, for which the requirements necessarily are more weakly specified and evolutionary by nature. This means that developers have to work more closely with customers and product managers need to know a lot more about the technical challenges and technical opportunities pertaining to a project. But this “goes against the grain” of many other changes in society. The motivation and interest in, and respect for engineering education and culture in the developed countries are rapidly decreasing. This has to have implications for how the projects are organized, and the choice of approach. Fewer people are available locally to do the technical work that is required. Moreover, a lot of the projects are only marginally profitable and therefore organization cannot afford to keep their own full-fledged development organization. With naive understanding of the software development process as impetus, the organization of work implied by outsourcing is crudely taylorist, and it is from this that many of the ’outsourcing’ challenges stem. An assumption of developers being able to take on a set of specifications and then program them in a ”man-machine-like” fashion program a system according to specification, violates one of ethnomethodology’s central tenets, namely the ”unsatisfied substitutability of objective for indexical expressions”. Similar experiences have been documented previously when a similarly reductionist perspective on software engineering has been applied (Gibbs 1994). The question remains, however, are there any differences between globally outsourced projects’ challenges and those of software engineering in general? Kliem (2004)