“Culture is one thing and varnish is another.”

findings for which is compared to allegedly general findings from previous work (e.g., (Keil et al. 1998).

We have studied an organization which is deeply engaged in developing various components of content provision services for the international mobile market. Similarly to Smith and Mitra (Smith, Mitra and Narasimhan 1996), we found that the prevalent frameworks for analyzing distributed development have perhaps been slightly too narrowly focusing on:

Outsourcing as the cause of, rather than the result of, a redistribution of competencies

Communication and cultural issues as determinants ‘from without’, exerting constraints on

projects, and

Outside issues, at ‘face value’, wholly or partly stipulating which managerial practices ought

to be applied to “bridge” such gaps

One perspective towards our findings is that they are no different from the ‘ordinary rhetoric’ which have always motivated software engineering research; seeing projects as complex, deliveries as hard to estimate and predict in terms of time, cost and quality and needing to secure the commitment of major shareholders and lead executives. However, although much is the same as asserted by e.g., Keil et al. (Keil et al. 1998), there are also many differences. We believe that this is due to the characteristic properties of projects here being outsourced, which is, typically, reasonable small and innovative, but most of all, “un-fixed” in terms of their requirements although they were conceived and explicitly possible to conceive as they were based on standard technologies and proven, albeit meagre, business models. This alone indicates that one ought to be sceptical of claims that such projects’ performance can be improved by “supermanaging” it with an (even) unified process, (even) stronger focus on requirements, (even) better planning and (even) more teambuilding (cf. (Prikladnicki, Nicolas and Evaristo 2003). This is not only due to the ‘inevitably creeping’ requirements, but because it represents a conceptualization of the software process as one in which the project is subjected to risk from without! This is a common perspective in software engineering (Boehm 1991). Similarly, Keil et al. treat risk as external to the project and something alien and foreign to the product itself (Keil et al. 1998). This does not seem at all to be the case for the software processes described in this paper. The projects referred to by product managers in the organization are exactly about taking risks. This further raises the question about risk and risk management, not as a rational exercise of calculating the severity and probabilities of events, but as ‘work in itself’, ethnomethodogically seen as accounting for the application (or lack thereof) of systematic methods. After all, since software engineering methodologies are explicitly oriented towards dealing with extraneous risk, ‘risk from without’ in a predictive and rational fashion, ‘acting as a software engineering professional’ entails referring to such terms.

Keil et al suggest that they have found eleven stable, global and universal risk factors. The introduction of new technology was not considered particularly significant. This is different from our findings, where a majority of managers say that they consider the introduction of new technology to be an important risk. This is understandable; inasmuch as the projects are sold with reference to their ‘finished’ status and that the conceptual complexity of services for mobile phones, at the current stage, arguably is still limited. Keil et al., moreover, suggest that the importance of top management support is obvious, and in their panels’ many managers espoused this factor as a risk that overshadowed all others. This is very different from our results, after carefully analyzing the data we found that this was, indeed, one of the least important risk factors that people considered. Some people thought that it was important, but no-one classified it as “somewhat important”.

“Another prime area of concern to the panellists was the failure to gain user commitment which was viewed as critical because it helps ensure that users are actively involved in the requirements determination process, and it creates a sense of ownership, thereby minimizing the risk that the system will be rejected. To some, strong user commitment was seen as something that could even compensate for a lack of executive commitment (Keil et al. 1998, p. 79)”.

This points firmly in the direction of Keil et al. describing entirely different types of projects than what we do, and this of course explains also that both “panels” of managers can attribute the greatest