REQUIREMENTS COMMUNICATION CULTURE IN MOBILE SERVICES DEVELO(6)

“Culture is one thing and varnish is another.”

The situation “inshore”, however, is quite different (almost the opposite), as shown by the following quote from one of the managers about how a game application typically is conceived:

“You go to the customer and ask him, ‘so you want a web page,’ right, then the question is how do you want to market it, in printed press, okay, and how you want to reach the customer is via SMS, and then we have a standard interface for that, that is that info in, sending it, game number, our partner logs onto our server and provides the info and then we push the content, and we can bill. Or if our customer have got a solution then we write the report, there are lots of opportunities, lots of standards…The point is if you ‘know your game’ when you get to an opportunity, well, because the customer does not know what he want, but if you have a standard package there, it is no hocus-pocus…We’ve developed solutions where people pay for games, even though that is not allowed. The operator does not care, you are not supposed to be able to pay for your shirts, but everyone is doing it.”

This excerpt indicates that there is, indeed, no specification ‘out there’ to grab and fix on paper, since the customer does not know what he wants, i.e., the application development is not needs driven. This is not really surprising, but we ought to notice that the ‘operation’ of selling is made with reference to “finished solutions” and “standards,” which, it turns out, are not standardized at all. Firstly there are many competing standards to choose from; secondly, one tends to ‘stretch’ beyond that to make the project outperform its own premises.

That has obvious consequences, but the findings go deeper: These projects are supposed not to be large-scale development projects. Given multifarious standards and solutions ‘that we have already,’ “Turnarounds are much quicker and does not take any time. “

However, mobile services are offered to the market in a layered architecture, reflecting a value chain with multiple actors each taking a ‘cut’ of each others revenue. In each step of the aggregate, a new stakeholder is introduced with their individual brand, approach, desires and experiences, which, in the next instance will influence the ‘requirements’.

It is interesting to observe, in terms of alleged communication problems, that that is always “somebody else’s problem”. In this particular organization, e.g., the product managers “locally” complained about communication problems vs. the East European site, which in its term complained about communication problems vs. a development site even further East, in China. In terms of the “reverse direction” of communication, however, the developers at the East European site do not perceive themselves as being “at the sharp end” of communication problems, although they do indicate that the product managers might not know how to produce a requirements specification, and when they do, it is likely to be changed again and again after programming has actually started.

Thus, there seems to be an indication here that “communication problems” ought to be conceived of much specifically and precisely, and in this case it circles around the capacity to communicate what one wants the developers to develop. But this is exactly what one did not know, and still agreed to build, approaching the matter in a “standard-yet-to-be-developed” fashion from the Oslo side initially. The specification of requirements, and the work thus involved, rightly seems to deserve ‘cornerstone’ status with regards to further analysis. It is actually possible already to bring this to the fore, analytically speaking, and say that lacking the competencies, and/or treating the writing of exact requirements as an ‘option’ along the tradition that is expected by the software developers and the technical managers, as such is glossed by referring to it as a communication issue or a cultural issues, as indeed one of the managers locally did when he referred to the “offshore” developers as “not understanding our requirements specification culture”. The sales organization and product manager ‘manage the customer’s expectations’ and ‘plan the project’ with ‘adequate’ understanding of what the project entails. It is an observable and accountable praxis to treat such adequate descriptions as constitutive of the social order, i.e., reasonable platform to initiate projects, in this case. The project’s offshore managers, however, inversely question the adequacy of the specification that they receive, exactly in a way that indicates a ‘disruption’ of the working relationship.

The outsourcing organization deals with this situation by asking the developers to write the requirements’ specifications: