“Culture is one thing and varnish is another.”

Looking at a slight modified version of the data, however, brings out some new dimensions. Firstly, by aggregating the scores from 1-3 into “Important”; 4-6 into “Less important”; 7-9 into “Almost unimportant” and finally 10-11 and n/a into “Unimportant”, we find that not only does “Changing scopes and requirements get a majority of the votes as them most important risk factor, but the other risk-factors relating to requirements management, e.g., 9 out of 12 similarly considered “Requirements not frozen/lack of change management” to be important (in the top half) as well as misunderstanding

the requirements which are put in the top half by 10 people.

9

8

7

6

5

4

3

2

1

ImportantSomewhat

importantNot so importantUnimportant

Figure 1: The view on risk

Some of these variables are quite balanced, e.g., “Lack of management commitment to the project” is seen as moderately important and unimportant, at the same time. Looking more closely at the data, we find that user mandate-oriented risks (Keil et al. 1998) are not ranked as high priority risks by the “offshore” project managers, only by product managers placed locally. Looking at resources and staffing, however, we do not have sufficient evidence to say that there is a difference as to how people in the different types of locations perceive the situation, yielding an interpretation in the direction of this simply being project-dependent. In terms of having the right competencies, however, the following quote is one interesting indication:

“The biggest problem is having the capacity to do the specification work, but I have tried to get ‘offshore’ to do more of it. The problem is that the project manager ‘offshore’ have got too many things to manage, and that is a problem right now, no one has the time to follow up continuously, but if we had had one person assigned to that…We have not written a design, yet, the specification, you know are made like ‘we need this and this and this’ and then we sort it out along the way. It might be a high risk venture, but we’ll see”

Summarizing the findings, the scope and requirements of a project in our case of mobile services development is not considered by “inshore” product managers as something that they control. “Offshore” project managers ask for better specifications, according to an idealized project process which is part of the “outsourcing institution”, as it were. In return they are asked to write the requirements’ specification themselves. This ought, according to a reductionist and rational view of software engineering to be working poorly, but in our case we found the opposite to be true. It actually works quite well. In the next section we will compare these findings with pervious work on software project risks, and see how it can be explained.

5 DISCUSSION

One of the challenges in studying outsourcing projects quantitatively is that there is great variation between projects (Sjøberg et al. 2005), perhaps too great to be able to generalize findings and recommendations. Instead, therefore, this paper is based on an in-depth study of one organization, the