REQUIREMENTS COMMUNICATION CULTURE IN MOBILE SERVICES DEVELO(7)

“Culture is one thing and varnish is another.”

“Our outsourcing organization wants a requirements’ specification, but since we do not have enough people we’ve asked them to write a proposal themselves, but then they are annoyed when we tell them they did not get it right. I would have liked to have more senior people here, like a proper development department, which could pull this off.”

Contrasted then with expectancies of globally distributed projects as resting on a weak set of requirements, or at least an extraneous requirements specification, which are actually written by the party farthest away from the customer in absolute as well as ‘cultural’ terms, we surprisingly find that globally outsourced projects are considered “better” by local product managers with regard to finishing on time than in-house ones, and only less trustworthy than locally outsourced projects in this respect. Four from seven of the product managers (not necessarily the same for each dimension) agree that globally outsourced projects finish on time, are well planned and documented, and have requirements which are within expectations. Local managers tend to think those projects which have been “locally” outsourced, e.g., carried out by consultants in the same city, do better than even in-house projects, in terms of finishing on time.

This is most likely not a reliable ‘certification’ of project properties, since they tend to inconsistently be allocated to different sites depending on project type, as the following two excerpts show:

“The requirement is always the same: produce an innovative and effective product! If there is an in-house capability, then that is my first choice. Local is next and global is third. The final determinant is: ‘what will produce the best result?’”

And:

“Often the level of complexity from a technical point of view is the criteria. Simple things you tend to solve in-house.”

Looking further at similar questions, we find that projects basically are ‘the same but different’ regardless of being organized as in-house or outsourced. In-house projects are, on one hand, considered by their “inshore” product managers to be much more likely of meeting the requirements than alternative project organizations, which is exactly what the “offshore” product managers believe is the case with the projects that are “local” to themselves, i.e., in this figure categorized as “globally outsourced”.

The trend seems to be that both parties believe that they do better than the others, but that their own global development partner does better than the “inshore outsourcing” alternative, with one exception being that product managers inshore believe this particular alternative fares better in terms of delivering projects on time.

We asked the managers at both sites to rank items from a list of software development risks, which have previously been developed by Keil, Cule et al (1998). Treating the notion of risk rationally, they assert that one needs to identify and rank risk according to its relative importance, in order for managers to concentrate on those areas which seems most “cost-effective”. Classification of risk is, according to Keil, Cule et al. (1998) an important tool since it implies which risk alleviation strategies are most applicable and effective. Keil, Cule et al. point out the importance of revisiting the list of prominent software project risk factors developed by Barry Boehm (1991), since “the organizational and technological landscape has changed considerably since [this] work appeared (Keil, Cule et al. 1998, p. 77)”. We consider that to be even more so the case, now, with the emergence of global, ubiquitous computing in the guise of mobile multimedia telephony and games.

From the 12 people in our first “managerially-oriented” questionnaire, no-one put “lack of top management commitment to the project” on the top. Noticeably, compared to Keil et al.’s list, 5 out of 12 people put this last on their list! Similarly, no-one put “failure to gain user/stakeholder commitment on the top of their list, although two people placed this second. Instead, 5 out of 12 put this as number 10 out of 11. The last of the customer mandate-oriented risks (Keil et al. 1998), “lack of adequate end-user involvement” was more uniformly distributed from the top to the bottom of the list of priorities. Commitment was seen as equally unimportant with both camps; inshore product developers as well as offshore project managers.