The Discursive Structure of the Social-Technical Divide: The Example of Information Systems Development

1995 ◽  
Vol 43 (2) ◽  
pp. 251-273 ◽  
Author(s):  
Janet Rachel ◽  
Steve Woolgar

The social and technical are commonly defined in opposition to each other. Yet technology practitioners are often quite comfortable with the idea that the technical is constitutively social. Drawing on an ethnographic study of a computerised information systems development project, this paper examines various usages of notions of ‘technical’. Attempts to situate the study at the ‘technical core’ of the project were met with a series of rebuffs. ‘Technical’ talk is to be understood as a categorising device which does boundary work. Technical talk invokes and performs a disjunction between networks of social relationships and stipulates a moral order with associated norms for acceptance and transition. The difficulty of penetrating the intelligibility of technical talk is understandable as a struggle in familiarising oneself with the routine social actions of a separate community. In addition, the private sphere of the technical is often distanced in time. The costs involved in journeying into the future are analogous to those of penetrating alien cultures. Ideas of progress and advance are often associated with the invocation of ‘the technical’. These connote a notion of timing which reinforces the distance and difference of – and hence depicts the costs involved in penetrating – removed sets of social relationships. Technical a. Appropriate or peculiar to, or characteristic of, a particular art, science, profession, or occupation (OED).

Author(s):  
David Avison ◽  
Trevor Wood-Harper

Multiview is a framework to support the information systems development process. It was formulated originally in 1985, but has been developed and changed since that time. It was originally defined to take into account the human and organisational aspects of information systems development, as the alternative methodologies of the time–and most since that time–took a very technology-oriented approach. Furthermore, it is a contingency approach, and again this compares with the alternative bureaucratic and prescriptive methodologies. In this chapter, we describe the history of Multiview, and we reflect on the experiences of using it in action in many organisations.


Author(s):  
Steve Clarke

In philosophical terms, a key issue of communities of practice (CoPs) can be located within one of the key philosophical debates. The need for CoPs is traceable to the inadequacy in certain contexts of the so-called scientific or problem-solving method, which treats problems as independent of the people engaged on them. Examples of this can be drawn from the management domains of information systems development, project management, planning, and many others. In information systems development, for example, the whole basis of traditional systems analysis and design requires such an approach. In essence, in undertaking problem solving, the world is viewed as though it is made up of hard, tangible objects, which exist independently of human perception and about which knowledge may be accumulated by making the objects themselves the focus of our study. A more human-centered approach would, by contrast, see the world as interpreted through human perceptions: the reason why the problem cannot be solved is precisely because it lacks the objective reality required for problem solving. In taking this perspective, it may or may not be accepted that there exists a real world “out there”, but in any event, the position adopted is that our world can be known only through the perceptions of human participants. This question of objective reality is one with which philosophers have struggled for at least 2,500 years, and an understanding of it is essential to determining the need for, and purpose of, CoPs. The next section therefore discusses some of the philosophical issues relevant to the subjective-objective debate: a search for what, in these terms, it is possible for us to know and how we might know it.


2012 ◽  
Vol 9 (1) ◽  
pp. 135-164 ◽  
Author(s):  
Damjan Vavpotic ◽  
Olegas Vasilecas

The paper presents a decision model and a tool that helps to find an information systems development methodology (ISDM) for a computer-based business information system (IS) that is suitable to a certain IS development project or an organization dealing with IS development. The intention of the model is not only to suggest a certain ISDM, but also to propose the properties an ISDM should have to suite the project or the organization. It is designed in a way that facilitates experimentation with different project, organization and ISDM properties. Based on the model we created a tool that has been applied on several cases in which we validated the correctness of its recommendations and established that it can have a significant positive contribution in the process of ISDM selection and in the process of improvement of existing ISDM.


Author(s):  
Fran Ackermann ◽  
Colin Eden

Identifying what different stakeholders in a business need from Information Systems development has always been seen as problematic. There are numerous cases of failure as projects run over time, over budget, and, most significantly, do not meet the needs of the user population. Whilst having a structured design process can go some way towards reducing the potential of failure, these methodologies do not attend sufficiently to clarifying and agreeing objectives or to considering the social and cultural elements inherent in the ownership and adoption of any new system. Instigating an effective, and structured, dialogue between users, developers and, when appropriate, sponsors, is therefore a critical consideration. Linking user needs, as they see them, to the language of IS developers and vice versa is crucial. Both parties need ownership. This chapter focuses upon the use of causal mapping, supported where appropriate by special software, that facilitates the development of a shared understanding (of both business needs and IT opportunities) and through this common platform enables a negotiated and agreed outcome. The nature of the outcome invites translation to structured design processes.


Sign in / Sign up

Export Citation Format

Share Document