1.3 Nature of GSW
Software development and maintenance activities are the characteristics of processes of the ˜new economy involving programmers, software designers and analysts (collectively referred to as ˜knowledge workers ) engaged in designing, developing, testing and implementing software (referred to as ˜knowledge work ). However, the nature of this knowledge is multi-
and continuously negotiated and contested by the various actors involved in the software development process (see for example, the case analysis of Sierra in chapter 7). GSW also reflects characteristics of other forms of global work in general where the focus is on developing standardization, productivity and efficiency. Ritzer (1996) labels such work as ˜McDonaldization . Based on an analysis of fast food
, notably McDonald s, Ritzer develops a critique of current-day work practices and society as excessively
with institutions to
rationalize and control behaviour
. Drawing on Max Weber s views of rationalization, Ritzer identifies four dimensions of modern institutions:
As the case analysis of Witech in chapter 4
, a constant quest in GSAs is to standardize and make efficient various aspects of infrastructure and work practices including, for example, defining the template in which project-
communication takes place. This quest for standardization and efficiency can also be
in the historical context of the software engineering tradition, and the
attempt to impart structure and predictability to software development processes.
GSW involves the application of various kinds of
, including programming languages, software development methodologies, project management techniques and the application domain. Different programming languages are used in software development, from the older FORTRAN and COBOL to the current Java and Visual Basic. Several hundred programming languages have been developed for use in both general-purpose and specialized domains. In the 1960s and 1970s, as technology of language compilers developed, large IT firms like IBM, Hewlett Packard and Univac formulated their own languages to support proprietary operating systems and system utilities. Users in other domains also developed their own languages “ for example Nortel Networks, a large telecommunications firm, had software for their digital switches written in a proprietary language called Protel. A key technology for GSW came in the 1980s. Common standards increasingly emerged and C and then C++ (
˜open platforms) became widely used for system software development. Although the development of standards remains contested, developers preferred these
platforms as these did not restrict them to particular technologies, or to specific firms with their proprietary languages and products.
Although global work is not a new
, distributed software development work is relatively new and begs the empirical question: can approaches to global manufacturing (for example, car assembly plants) or global services (for example, consulting) be transferred seamlessly to software development work? As software work involves physically intangible
whose value is derived from qualities such as efficiency of algorithms, ˜look and feel aspects of the
interface, richness of features and so on, this distinction from the production of material goods is useful. Software work has
features, for example, in contrast to manufacturing where production and consumption take place in separate physical domains, services are
distinguished by the
of these functions. This is true of a range of different services from hotels and medical work to legal and accounting practices. However, these services are also starting to be outsourced offshore, as reflected in the growth of firms providing legal and medical transcription services and also those
in various transaction-processing functions like billing and ticketing.
Production and consumption are separable to a major degree in software work, where at each stage of the development, artefacts such as program code and documentation enable outputs to be specified and disembedded from the development domain to other use situations. However, information systems research has increasingly established that software design and development is never really ˜finished , but involves an ongoing interaction and redefinition with the process of use (Bjerknes, Bratteteig and Espeseth 1991). Development and use of software can thus be quite distinct, linked together by various artefacts, and
be also intricately
. Managing these
is a defining aspect of GSW.
Software may be regarded as a knowledge industry but is different from the traditionally accepted knowledge work of consulting in which many aspects rely fundamentally on the expertise of individuals, making it difficult to obtain economies of scale. Software work covers a range of activities including the development of algorithms and user interface designs that require creative talent of the highest order that cannot be scaled up in a mechanical fashion. Friedman (1989) points out that software work of this nature is continually being disciplined,
and made subject to
control, but that this is thwarted by factors such as rapid changes in technology and the associated lack of skills in these new domains. Other activities in the spectrum of software work include the work of call
, data entry and medical and legal transcription that typically need a minimum level of English, typing skills and ability to use a word-processing program. Such work can easily be scaled up with a suitable work place and telecommunications infrastructure, wherever people with these minimal background skills are available in large
. In between these extremes, there is a range of activities that demands different degrees of knowledge and skills, and is amenable to varying degrees of scaling up. For example, while maintaining legacy software does not need creative talent of the highest order, it needs individuals who can, in a short span of time, learn new languages, understand the complex relationships in a large piece of software and sensitively
in the use domain. The extent of
and scaling, therefore, varies for different software
and is significantly shaped by the infrastructure in place, including the available bandwidth, the degree of sophistication of management processes and the prior experience of the
In GSW, tasks at various stages of the software life-cycle may be separated and implemented at different geographic locations coordinated through the use of ICTs. Maintenance and testing were among the first tasks to be outsourced, while early life-cycle tasks such as design and user requirements analysis were considered more difficult to contract out as they required more intimate knowledge of the firm s work practices as compared to maintenance and testing. On the face of it, those types of technology oriented development appear better suited for outsourcing where specifications can be developed and given to an outside party to execute. However, design tasks become harder to undertake because they assume a close
with the market and user preferences. Alternatively, in modular approaches, modules of the software are divided into independent modules and its development ˜outsourced to
in different locations.
Intangibility, heterogeneity, mobility and scalability are features that differentiate software work from other services and also manufacturing activity. The mental or intellectual activity involved in software work is captured in a form not
in the literal sense of being touchable by a human hand but nevertheless is made perceptible through magnetic or optical readers and other devices. The heterogeneity of software work is often limited by the standardization of development processes, methodologies and programming languages. While new and innovative work involves heterogeneity at early stages of conceptualization and design, it requires less at the stages of testing and implementation. Standardization of processes is central to disembedding and fragmenting of software processes to make them amenable to GSW. Perishability,
important in services like hotels, is not so in software since artefacts like software code and manuals provide mobility with the use of ICTs and enable the life of the software to endure over time.
Another distinctive aspect of software work is the variety of social and human issues that come into play in the phases of design, development, implementation and interpretation of its longer-
implications. Software work, when carried out in a global setting, magnifies these complexities as it involves relationships of people, teams, organizations and nations with different backgrounds, spoken languages and styles of working in conditions of temporal and spatial separation. Standardization, which is the key to coordinating distributed work, is extremely hard to implement because of the complexities of GSW. Whereas many firms in the manufacturing and services industry try to downplay national and cultural issues through standardization, managers of certain GSAs may capitalize on local ideosyncracies, strengths and creative energies (for example, the case of ComSoft described in chapter 5). While large MNCs are widely seen as weakening of local cultural values, smaller software firms (like ComSoft), in contrast, often attempt to reassert these identities in an effort distinctively to define
, drawing upon resources like national and cultural identities in the face of global competition. An ongoing challenge is how to find the appropriate blend between universal solutions and local particularities in a context
characterized by a multiplicity of networks.
Another key feature of GSW is the manner and speed in which its knowledge content is subject to change and
readjustment and is characteristic of work in Castells (1996) ˜network society . Founded fundamentally on technology and information, GSW involves a new form of ˜informational
in which time, space and knowledge are key resources that entities try to dominate and standardize using various organizational forms. Changes, both technological and organizational, are the norm in GSW. The rapid uptake of Web-based systems by businesses has
changed the skill sets (like Java) required for software development, for example. Changes are taking place at many levels, from the business models adopted to specific policies and procedures implemented to stem the attrition rate among developers. To deal with these rapid changes, firms need reflexively to monitor and modify their processes on an ongoing basis.
GSW, as we use the term, is broader than the traditional ˜software outsourcing that involved the purchase of goods or services previously obtained internally. Box 1.1 shows Apte s (1990) summary of the activities that were typically outsourced in the past. Prior to the early 1980s, the involvement of foreign companies in outsourced work of this nature was restricted
to data-processing or coding-type projects completed by a team of on-site foreign contract programmers. GSW now commonly involves the design and development of new products, support, special services, and whole-life-cycle projects involving different levels of complexity. While ˜outsourcing refers to work contracted out to third-party firms, typically located in the same country, GSW includes work done by subsidiaries and alliances that are
located in a different country. GSW involves turning over to this third party or offshore subsidiary some or all the software development and maintenance tasks,
from simple data entry or programming to complete software design, development, data
operations and full system integration. As the software component in hardware such as telephones, DVDs,
phones and in
, the demand for outsourcing has multiplied (Box 1.1).
Box 1.1 Outsourced IT services
Data-processing services: data entry, transaction processing, back-office clerical tasks
Facilities management: operation and support of data centres
Support operations: maintenance services and data recovery
Special services: training, hotline support
Source: Apte (1990).
GSAs allow for a range of possibilities both in terms of the kind of projects contracted out and the extent to which the different stages of the development life-cycle can be outsourced. Issues that influence these decisions are the strategic importance of the activity, the degree to which the requirements can be specified and the
cost of having the software developed in-house versus having it outsourced. Various arguments have been made for and against companies contracting out
projects: ˜never outsource a problem, only a defined task (Willcocks, Fitzgerald and Lacity 1996; Willcocks and Sauer 2000). Gurbaxani (1996) argues, to the contrary, that innovative projects can be outsourced with support of a strong contracting structure, presence of multiple
and a selective outsourcing strategy. In addition to this debate on what should be outsourced, there are also discussions on whether firms should go for ˜total or ˜selective outsourcing, ranging from small stand-alone projects completed through short-term employment of programmers, to projects where the third-party vendor is completely in charge of hardware, software and staff. Total outsourcing can involve design, implementation and maintenance of large projects, or even the support for whole pieces of legacy software or the porting of them to alternative platforms.
While the issues referred to above have been debated extensively in the information systems literature, they
open empirical questions in the GSW domain. McFarlan (1995) has argued that ˜highly structured projects where processing, file structures and outputs are completely defined, are easy to outsource, as compared to those whose outputs are more open to the users changing judgement on desirable features, for example, in business process re-engineering projects. Such projects, it is argued, are best done in-house in conditions of co-location and proximity. In addition, to reduce
in design, Kobitzch, Rombach and Feldmann (2001) argue that structured projects are amenable to an ˜engineering approach which makes it easier to scale up and achieve economies of scale that justify the investments required for establishing a GSW infrastructure. This is related to the maturity and compatibility of the structured processes in both the outsourcing vendor and client organizations. Our empirical work in Japan (see chapter 9) suggests that firms there may be more willing to operate in relatively unstructured projects as compared to North American firms, and this can
challenge the popular
about the need for structure in remote work.While it is still early to say whether the Japanese approach will be successful, their experience will provide key learning for the practice of GSW.
In summary, we have pointed out four distinctive features of GSW:
GSW does not reflect either a traditional manufacturing or service activity, and includes
elements of both
GSW can take on varying levels of
sophistication and need for creative and intellectual inputs
, ranging from call centres to designing new technologies.
of GSW varies with the nature of work and the life-cycle stage of the project.
Social and human issues
in GSWs are magnified as compared to traditional outsourcing because of the increased diversities of people, practices and technologies involved.