• No results found

The social shaping of packaged software selection

N/A
N/A
Protected

Academic year: 2020

Share "The social shaping of packaged software selection"

Copied!
29
0
0

Loading.... (view fulltext now)

Full text

(1)

The social shaping of packaged software 

selection

Howcroft, D and Light, BA

Title

The social shaping of packaged software selection

Authors

Howcroft, D and Light, BA

Type

Article

URL

This version is available at: http://usir.salford.ac.uk/11575/

Published Date

2010

USIR is a digital collection of the research output of the University of Salford. Where copyright 

permits, full text material held in the repository is made freely available online and can be read, 

downloaded and copied for non­commercial private study or research purposes. Please check the 

manuscript for any further copyright restrictions.

(2)

Journal of the Association for Information

Research Article

Abstract

Debra Howcroft

University of Manchester

debra.howcroft@manchester.ac.uk

Ben Light

University of Salford b.light@salford.ac.uk

As organisations increasingly engage in the selection, purchase, and adoption of packaged software products, how these activities are carried out in practice becomes increasingly relevant for researchers and practitioners. Our focus in this paper is to propose a framework for understanding the packaged software selection process. The functionalist literature on this area of study suggests a number of generic recommendations, which are based on rational assumptions about the process and view the decision making that takes place as producing the “best technology solution.’” To explore this, we conducted a longitudinal, in-depth study of packaged software selection in a small organisation. For interpretation of the case, we draw upon the Social Construction of Technology, a theoretical framework arguing that technology is socially constituted and regarding the process of development as contradictory and uncertain. We offer a number of contributions. First, we further our understanding of packaged software selection with the critique that we offer of the functionalist literature, drawing insights from the emerging critical/constructivist literature and expanding our domain of interest to encompass the wider environment. Second, we weave this together with our experiences in the field, drawing on social constructivism for theoretical support, to develop a framework of packaged software selection that shows how various actors shape the process.

Keywords: Packaged Software, Software Procurement, Packaged Software Selection, Social Shaping of

Technology, Social Construction of Technology, Vendors.

Volume 11, Issue 3, pp. 122-148, March 2010

The Social Shaping of Packaged Software

Selection *

(3)

1. Introduction

Recent years have seen an expansion in the literature concerned with standardized software packages as organisations become increasingly disheartened with custom–developed systems. The prevalent literature on packaged software selection conceptualizes the process as rational and linear and it is assumed that the decision-making process will elicit the ‘best technology solution.” Yet this logic appears contradictory when faced with studies that reveal inconsistent effects from the same technology within a single organisation (Barley, 1986; Orlikowski and Gash, 1994) or identical technologies being appropriated differently by different groups. These outcomes challenge the assumed simplicity of packaged software selection. More recently, a group of scholars has emerged who focus on how technology choices are the result of more complicated social and political processes. Our paper aims to make a contribution to this emerging critical/constructivist research stream.

Despite the widespread adoption of packaged software across a range of organisations, there has been limited systematic research (aside from Howcroft and Light, 2006; Pollock and Williams, 2007; Tingling and Parent, 2004) on the decision making processes surrounding the acquisition of these technologies. A survey of the Enterprise Resource Planning (ERP) literature revealed that only a limited amount of research covered adoption and acquisition, and further research was recommended to study the roles of different stakeholders (vendor, customer, and consultant) and their influence on the selection process (Esteves and Bohorquez, 2007). Therefore, the aim of this paper is to investigate how the various actors shape the selection process. We adopt a Social Shaping of Technology (SST) approach (MacKenzie and Wacjman, 1999; Williams and Edge, 1996) — in particular, the Social Construction of Technology (SCOT) (Pinch and Bijker 1984) — to enable us to account for a broader and more heterogeneous set of actors, and we use this to explain, illustrate, and analyse the process. We show the diversity of actor interpretations yet also view selection as an outcome of social processes of negotiation where actors have different perspectives or structural positions. Our concern lies in identifying competing interests and studying how this influences and shapes the decision-making process.

The paper will proceed with a review of the functionalist literature on package software selection, drawing on research from the emerging critical/constructivist literature to critique the assumed simplicity surrounding decision-making processes. This is further developed to encompass a market-oriented view (Sawyer, 2001; Wybo, 2007) of packaged software selection, thus, expanding the focus of concern beyond the organisational parameters. The subsequent section describes SCOT, which we use as a basis for the analysis of our empirical study. This is followed by our research approach, before we detail the case narrative. Using the fieldwork for illustration, we are able to examine the stages that form part of the process of packaged software selection, thus highlighting its highly unpredictable nature and the role played by relevant social groups in the stabilization of technology. Finally, we weave these elements together to develop a framework for understanding the packaged software selection process and offer some conclusions, which reflect on the theoretical and practical implications.

2. The Packaged Software Selection Process

(4)
(5)

Originating from the functionalist literature are numerous studies (Chau, 1995; Durrani et al., 1998; Lynch, 1987; Montazemi et al., 1996; Sharland, 1991; Stefanou, 2001) and practitioner oriented guides (KPMG, 1998; Martin and McClure, 1983; Nelson et al., 1996) that offer prescriptions for large or small companies. These broadly concur that packaged software selection should involve the identification and definition of user requirements, evaluation should consider “best fit” between package functionality and requirements, and final selection and purchase should be based on these two prior phases. We will discuss each of these stages in turn before moving on to considerations of the wider environment.

2.1.

Packaged Software Selection: Understanding User Requirements

With packaged software, the functionalist literature suggests that in order to achieve the “best fit” between product functionality and organisational needs, an understanding of user requirements is critical (Bansler and Havn, 1994; Chau, 1995; Nelson et al., 1996; Sharland, 1991; Stefanou, 2001) and that this will lead to successful implementation and usage (Janson and Subramanian, 1995). User involvement in package selection is seen as essential for determining functionality requirements (Akkermans and van Helden, 2002; Al-Mudimigh et al., 2001; Gremillion, 1982) and it is argued that assessing these needs is necessary for scoping the project in order to reduce costly changes (Markus and Tanis, 2000). If users achieve a thorough understanding of how the proposed system will operate, it is also assumed that misfits can be reduced (Sherer, 1993).

The functionalist literature fails to account for the fact that the adopting organisation is unable to feed in their requirements before the development takes place; instead they are faced with an assortment of pre-built packages from which they have to choose. Confronted with selecting the product that most closely matches their needs, this process within the organisation involves making trade-offs (Keil and Tiwana 2006). Therefore, many adopters eventually select a package on the basis of a persuasive sales pitch (Butler, 1999), as vendor’s attempt to influence customers regarding the appropriateness of the fit between their organisational needs and the technology that the vendors represent (Wybo, 2007). The fit between product functionality and user requirements may appear problematic as packages address their requirements in an unfamiliar or unacceptable way, since many are built with “generic users” (Bansler and Havn, 1996) in mind and seldom translate easily across boundaries, either between organisations or within the same sector (Pollock and Cornford, 2004). Indeed, this assumed transferability of standardised products across organisations is often cited as a primary reason for failure (Willis and Chiasson, 2007).

At this stage of the selection process, larger organisations are inclined to analyse various prototypes and engage the services of consultants (Bernroider and Koch, 2001). For small to medium sized enterprises (SMEs), organisational size influences what can be a lengthy and costly decision-making process and, therefore, they often rely heavily on vendor support and presentations (Janson and Subramanian, 1995) to inform the decision, rather than carrying out detailed requirements analysis (Olsen and Saetre 2007). Yet reliance on vendor-supplied material exacerbates the likelihood that the adopted package will fail to meet user requirements (Keil and Tiwana, 2006).1

2.2.

Packaged Software Selection: Evaluation

The functionalist literature proposes various criteria for the evaluation of packaged software products; these are underpinned by an assumption that numerous options can be compared and ranked as technological properties are objectively assessed (Pollock and Williams, 2007). Selection criteria are largely centred around the themes of the functionality of the software (Keil and Tiwana, 2006; Lynch, 1987; Martin and McClure, 1983; Sprott, 2000; Stefanou, 2001; Verville and Halingten, 2002) and the capabilities of the vendor (Chau, 1995; Nelson et al., 1996; Verville and Halingten, 2002). It is assumed that understanding the capabilities of the package is an important part of the evaluation process (Akkermans and van Helden, 2002; Al-Mudimigh et al., 2001) if the “right” product is to be

1

(6)

selected.

Yet, IS evaluation is notoriously difficult (Hirschheim and Smithson, 1999; Irani, 2002) and the problem remains that no matter what measurement is used, evaluation cannot be considered objective (Wilson and Howcroft, 2005), as evaluation processes often serve as an important resource for legitimising decisions (Legge, 1984). The process is skewed from the outset as various actors with competing interests, attempt to persuade other parties that there is one best way. Potential customers are subject to the sales techniques of marketing people aligned with software vendors, yet the packages can only really be evaluated once they have been bought and installed (Bansler and Havn, 1994).

Customers commonly identify new and emerging functionality as the project evolves: at the evaluation stage vendors often attempt to scope the problem to closely match the product’s existing functionality, rather than invest in configuration that may be of little relevance to other customers (Wybo, 2007). Conflicting narratives occur within the organisation. Chau (1995) contends that owners and managers of small businesses (identified as the primary decision-makers in the process) use dissimilar criteria when evaluating packages. Likewise, Montazemi et al.’s (1996) study showed that when tasked with evaluating packages, information centres within organisations produce recommendations that do not necessarily align with the needs of end-users, who often perceive the package to be less useful to their jobs than the technical specialist had assumed.

2.3.

Packaged Software Selection: Final Selection and Purchase

In the functionalist literature, it is recommended that selection and purchase be based on the preceding two phases: the understanding of user requirements and package evaluation (Chau, 1995; Lynch, 1987; Martin and McClure, 1983; Nelson et al., 1996; Stefanou, 2001; Welke, 1981). Studies have shown that the purchase of global software packages is often motivated by expectations of the future direction and development of vendor products (Butler, 1999; Sawyer, 2001) and the vendor’s perceived strength and stability (Chau, 1994) as much as by specific internal needs. For example, one study showed that a company selected SAP because it was perceived as the market leader in ERP packages, as opposed to being the appropriate package for the organisation (Dolmetsch et al., 1998).

In order to proceed with selection and purchase, it has been suggested that the presentation of a strong business case for package adoption will attract senior management support, which is seen as essential (Kunda and Brooks, 2000; Shehab et al., 2004). Studies suggest that the primary decision makers in this environment tend to be non-information systems senior managers (Brown and Vessey, 2001; Hirt and Swanson, 1999; Sawyer, 2001), who are unlikely to have been involved in the two previous stages. What may appear on the surface as a straightforward and rational selection process is imbued with complexity that is difficult to unravel.

3. The Wider Environment

In order to provide understanding beyond the organisational level, we will outline the broader context of packaged software in this section, since this has implications for the process of selection.

3.1.

The Packaged Software Industry

(7)

embedded in the software (Soliman and Youssef, 1998).

Within the packaged software industry, success is measured according to profitability, favourable product reviews, and market share (Carmel and Sawyer, 1998). Time to market is of competitive importance (Carmel and Sawyer, 1998; Sawyer, 2000), since this is based on the desire to develop new products and attain first mover advantage in new markets or release new editions (Raghunathan, 2000) to a large installed base of customers. The focus for software vendors is on developing products rather than systems, and innovations are concerned with more accurately meeting the needs of their specialised market as opposed to a concern about a particular user organisation (Quintas, 1994).

3.2. Product

Development

Packaged software products are often conceptualised as standardised commodities, yet the more critical literature suggests they are in constant development, always provisional (Pozzebon and Pinsonneault, 2005), and should be viewed in more fluid terms, as a “biography” that evolves across multiple cycles of development (Pollock and Cornford, 2004). Package software is designed with the intention that its life will extend beyond the original locale for which it was initially designed and is marketed as having generic application. Yet, “blackboxing” of technologies over-simplifies the product and partly explains why adopting organisations discover that many of these packages show lack of appropriate functionality to meet their unique requirements (Pozzebon et al., 2006). It is difficult to query the claims being made by vendors and consultants, since they sell packages with the promise of transferring exemplary business practices – best practices – (Wagner et al., 2006) that are embedded within the technology. Configuring the software to enhance compatibility with existing processes reduces economies of scale and, consequently, organisations face pressure to conform to these best practices (Gosain, 2004). As noted, consultants and system implementers “attempt to render the institutionally diverse organisationally similar” (Pollock and Cornford, 2004: 49).

Paradoxically, a substantial proportion of software vendor and supplier income is tied in with maintenance and upgrade activities for existing customers (Clausen and Koch, 1999). In order to gain an appreciation of their needs, it is recommended that customers are included in product development activities (Carmel and Becker, 1995; Raghunathan, 2000). However, the nature of the inclusion is not clear (Iivari, 2004; Pozzebon, 2001), and a bewildering range of customer-developer links have been developed, including trade shows, user groups, and focus groups. Yet research highlights an over-reliance on indirect links (Keil and Carmel, 1995), that have been described as “ineffective conduits” (Grudin, 1991). From the customers’ perspective, substantial social and financial resources have been put into the process of purchasing a software package, and they become reluctant to shift allegiance. They can become locked into a vendor’s product development trajectory and, in an attempt to try to influence the vendors’ plans for enhancement, become active in user groups (Markus and Tanis, 2000). The case of SAP product development is a good illustration of this (Scott and Kaindl, 2000). SAP carefully selected only those customers who they felt represented state-of-the art knowledge in the area and were also willing to change their processes. Indeed, it has been suggested that even where consumers do get involved, vendors may not view all requirements as relevant (Clausen and Koch, 1999; Pozzebon, 2001), given their aim is to maintain a generic product that can be sold to a broad customer base. It is unlikely that smaller firms will have an opportunity to influence change and, for them, the prospect of having to attend user conferences in order to lobby for modifications is neither productive nor possible in many instances (Olsen and Saetre 2007).

3.3. Intermediaries

(8)

conduits and, in effect, speaking for the technology (Bloomfield and Danieli 1995). Yet underpinning the process are salesmanship activities (Darr, 2006; Friedman and Cornford, 1989; Wybo, 2007), which aim to persuade customers of the benefits of an IT product or service. Intermediaries play an influential role, not only in technical terms, but also in managerial and political terms, as they assist their clients in modifying their expectations of what the technology can deliver (Adam and O’Doherty, 2000). Both vendors and consultants help to define how the problem and solution are framed, assist with the identification of new and emerging functionality, and influence the project size and scope (Wybo, 2007). They play a critical role as “fashion setters” in encouraging the spread of particular approaches to management (Abrahamson, 1996), but these “IT imperatives” or fashions usually emerge from persuasive discourse, rather than based on sound arguments (Pozzebon et al., 2006). This can lead to firms adopting technologies that they do not fully understand and that do not match their needs (Swan et al., 2000).

Intermediaries are co-dependent upon vendors and purchasers, since their business is generated from this mediation process. Although the relationship between clients and consultants is not based on fixed dependencies, but is multifarious (Fincham, 1999), nevertheless, consultants have received bad press, jokingly referred to as people “who [borrows] your watch to tell you the time.” A field survey by Caldas and Wood (1998) revealed that the support consultants) offer is “less than adequate” and that they are seen as insufficiently prepared for the task. Grant et al. (2006) commented that much of vendor and consultant rhetoric is based on “false promises” in that systems are extolled as having the potential for transforming the nature, structure, and management of work in a positive way. Consultants may be viewed as holding too much power (Skok and Legge, 2001) and having more of an interest in ‘sell on’ than their current project (Sturdy, 1997).

Within an SME context, many firms implement packages because they lack technical and financial resources to develop a system from scratch (Binbasioglu and Winston, 2004), and they also tend to be less developed in terms of structure and functions (Raymond 1990). Therefore, the promise of external business and technical expertise proffered by IT consultants seeks to address areas where SMEs are often found wanting. There are a number of studies that point to the value of engaging consultants for IT appropriation purposes (Kole, 1983), yet it remains a challenge to find decent IT services and consultants (Caldeira and Ward, 2002). More problematically, some SMEs take the view that they can leave consultants to undertake the work and provide minimal input themselves (Gable, 1991), thereby minimising their role in the complex process of negotiation.

To summarise, the IS literature on the packaged software selection process is predominantly functionalist and focuses on a linear process that involves the identification of user requirements, an evaluation of the best fit between packages and those requirements, and final selection and purchase. However, there is an emerging critical/constructivist literature that points to the complexity in assuming that standardised packaged products can be implemented and adopted with ease across various organisations. Within this literature, some authors have drawn attention to the wider environment that shapes the packaged software market and, hence, has some bearing on the selection process. To focus only on the organisational level without paying due consideration to wider structural forces merely “black boxes” the selection process and fails to problematise the inherent complexity. In this paper it is our intention to interrogate at close quarters the packaged software selection process with a longitudinal case study; this is supplemented with our appreciation of the wider environment and how these structural influences further shape the process. We use this to explain and illustrate how the various actors shape the selection process, drawing on the SCOT approach for theoretical support; this is elaborated upon in the next section.

4. The Theoretical Lens: Social Construction of Technology

(9)

achieves this with the provision of explanatory concepts that pattern the design and use of technology. We selected this approach since it has now become almost orthodox in the treatment of technology in general (MacKenzie and Wajcman, 1999). Within IS research this approach has been adopted by numerous writers (for example, Boland and Schultze, 1996; Mitev, 2000; Monteiro and Hanseth, 1996; Orlikowski and Gash, 1994; Sahay and Robey, 1996).

For SCOT theorists the social environment shapes the technical characteristics of the artefact, and this is their primary focus of concern. The approach suggests that technologies are socially shaped such that their resulting material form reflects the structural and political circumstances of their development. Therefore, the social relations of production (the practices, assumptions, beliefs, language, and other factors involved in its design and manufacture) are built into the technology, which has consequences for subsequent deployment. This model regards the innovation process as contradictory and uncertain, which contributes towards explaining why the excellence of a particular technological solution will not necessarily guarantee its success. The main aspects of SCOT on which we draw in this paper are as follows:

Relevant Social Groups: Relevant social groups (RSGs) will not only define a technological problem differently but also disagree over definitions of what constitutes success and failure (Pinch and Bijker, 1984; Bijker, 1997). If we are to understand the development of technology as a social process, it is crucial to take the artefacts as they are viewed by the relevant groups, since to do otherwise would imply the technology is autonomous. These groups are delineated according to similarities among their interpretations of technology so that all members of a certain social group share the same set of meanings attached to a specific artefact.

Interpretative Flexibility: Interpretative flexibility is a useful concept for understanding how problems and solutions associated with a technology present themselves differently to different groups of people (Pinch and Bijker, 1987). Demonstrating the interpretative flexibility of an artefact amounts to showing that one seemingly unambiguous “thing” (such as a bike, computer, or bridge) is better understood by tracing and identifying the meanings attributed by the relevant social groups. Interpretative flexibility helps to explain how different groups see and construct quite different objects and it “shows that neither an artefact’s identity nor its technical working or nonworking is an intrinsic property of the artefact but is subject to social variables” (Bijker, 1995: 252).

Stabilization: Pinch and Bijker (1987) go on to explain that a technology can stabilize in circumstances where relevant social groups see their problems as having been solved by the technology in question. This is also more familiarly known as “‘closure” when the contents of the technology become black boxed. Stabilization entails, amongst other things, translation (Callon, 1986), that is, the effective persuasion of pertinent actors that it is in their interest to use the technology in the prescribed manner, and that the technology is the answer to their problems (Bloomfield and Best, 1992). This is the process whereby different actors are enrolled, mobilised, or enlisted into different directions, aligned or otherwise with other actors. Hence, technological development is a multi-directional and non-linear process that involves constant negotiation and renegotiation among different groups.

(10)

5. The Research Approach

In order to elucidate the issues discussed above, we provide an account of our empirical study below. The research being reported is based on an interpretivist perspective (Walsham, 1995), and we aim to communicate the findings of the study by employing the theoretical lens offered by a social shaping approach. The interpretivist approach is in keeping with the guiding epistemology for this approach and for gaining insights into the subjective interpretations of the working lives of the members of the relevant social groups (Wajcman, 2000).

The research project concerned a two-year funded project2 that entailed collaboration between a small- to medium-sized enterprise (SME3) – named (T.Co4) — and a University. The project involved a number of information systems projects and funding for a newly-appointed IT manager. In this paper we focus upon the Client Tracking Project that concerned the selection of a package to support the client service provision. Although the project plan was constructed in a linear fashion, the very nature of fieldwork intensifies the serendipitous events that characterise all research. In this respect, despite well-defined objectives, our experience of the project was that it was characterised by a considerable amount of flexibility and improvisation (Orlikowski, 1996).

5.1. Data

Collection

and

Analysis

We performed data collection and analysis simultaneously. The analysis of organisational practices as they unfold in situ enables us to highlight and problematize the rift between theory and practice and is, therefore, crucial to the research topic. Accordingly, we adopted data collection techniques that are inclined towards capturing contextually dependent qualitative data. The project involved unstructured and semi-structured interviewing, observation, and document review. It has been argued that if we are to improve our understanding of IT production and use, then engaging in an ongoing dialogue with multiple voices can provide an enhanced understanding of the values of the relevant actors and their framing of problems and potential solutions (Suchman, 1994). One of the benefits of carrying out longitudinal research at a small firm is that it was possible to move beyond snapshots of samples of respondents. We included numerous participants spanning vertical levels and functional groupings in the study such as senior managers, business development managers, secretaries, telesales representatives, external T.Co consultants, and vendor consultants. We aimed to derive theoretical explanations from the data by capturing multiple perspectives and by interpreting the process of interaction between people in the particular social setting.

Working within the structure of a funded research project formalised regular visits to the organisation. Prior to the official launch of the project, we visited the company several times to contextualise the study. When the project was initiated in November 2000, we visited weekly for a half to full day. Given the regularity of visits, the processes of data collection and analysis became inextricably linked and so, despite our best intentions, it is not always easy to provide accurate quantifications regarding the data collection. Indeed, many important comments were made off the cuff and beyond the confines of the formal setting. We conducted 121 interviews lasting between one and three hours, all of which were recorded and transcribed. Some of these were carried out with individuals, others with groups or teams of people. As the project progressed, it became clear that the management within this small company did not wish to waste resources on people being interviewed, especially when this detracted from their primary tasks. As an alternative, we took advantage of informal, opportunistic meetings during which we were able to watch and listen to people’s interpretations as the situation unfolded. In addition, participatory observation took the form of sitting with people and observing their working practices. We also reviewed and analysed various documentary materials, some of which were written by external consultants and vendors. The documentary evidence included the

2

The project was funded through the department of Trade and Industry/Engineering and Physical Sciences Research Council’s TCS Scheme, with T.Co making a 40 per cent contribution.

3

Although there is no single definition for an SME either nationally or internationally according to the UK Department for Business, Enterprise and Regulatory Reform an SME refers to a firm employing less than 250 employees (http://www.berr.gov.uk/).

(11)

minutes of meetings, project documentation, email correspondence and company newsletters. Viewed holistically, these documents played a key role in providing multiple interpretations of the situation being studied (Klein and Myers, 1999).

The method of analysis was based on an ongoing iterative process of reflection and discussion of packaged software selection as described in the literature and as enacted in practice, to help identify concepts, themes, and issues (Miles and Huberman, 1994). Our aim was to understand the processes and themes within these multiple interpretations with a view to presenting a plausible theoretical explanation. We began with reading through all of the interview transcripts, observation notes, and documentary evidence to identify issues and topics that related to the package selection process. We shared the initial findings with various participants within the organisation and their helpful comments confirmed and elaborated on these themes. The reaction of practitioners in the field is seen to offer a crucial validation of the interpretation (Klein and Myers, 1999). The insights from the empirical study form a basis from which further investigations can consider the implications of selecting and adopting packaged software in organisations. In sum, the findings are intended to be insightful and assist scholars and practitioners in deepening their understanding of the complexity of the packaged software selection process. How these materialised will follow in the next section, which discusses the details of the case study.

6. The Organisational Environment: Structures, Systems, And

The Client-Tracking Project

T.Co is a consultancy company that provides a range of career management services covering executive outplacement. The company was established in 1990, and by 1999 it comprised a headquarters in the North of England and one satellite office. Throughout the duration of the study, three additional satellite offices were added, and staffing levels increased to 27 internal personnel and 26 external consultants. In 2000, the UK market for outplacement services was valued at £80 million, and T.Co had a two percent national share, but a larger regional share of around 10 percent. Their clients are primarily senior managers, usually funded by their current employer as part of a severance package. The services offered are geared towards the sourcing of potential new employment.

6.1. Organisational

Structure

T.Co is a small organisation that is hierarchically structured with strong control and command structures. The Managing Director (MD), who founded the company, dictates organisational goals and sees dissent and disagreement as something to be reprimanded. The board of directors represents the senior management team and consists of the MD, the chair, non-executive board members, and regional business development managers. The sales and marketing department are responsible for identifying prospective sponsors and managing client relations. The research department assists clients in sourcing and presenting themselves to prospective employers. The external consultants operate on a self-employed basis and act as mentors for the clients, offering career advice and occasional counselling services.

T.Co’s underlying business process model begins with identifying potential sponsor companies and ends with client placement/employment, which is complicated by the need to coordinate activities across departments and with external consultants. The process begins with obtaining information about firms due to make staff reductions and securing a contract for career placement for the newly unemployed. Clients then embark on a process of mentoring and job search activities with the external consultants. Their progression is confidentially reported back to the sponsor as a way of informing them that the services they have purchased are being delivered appropriately. An element of the business is based on follow on as clients may become future sponsors, hence, the importance of ensuring that the clients’ experiences are positive.

6.2. Information

Systems

(12)

applications created in the Filemaker Pro database environment, which were initially designed and built by the firm’s commercial director, who had no formal systems development training. T.Co had used a local IT support consultancy to assist with the management of its infrastructure, but was disappointed with the service received. The MD described his future requirements as requiring advice from a consultancy “who has the capability to contribute towards the IT strategic vision of an

expanding company.

The company had a number of systems containing data that was duplicated and often inaccurate. This was frustrating for end-users and, at the same time, managers wanted a more sophisticated analysis of the data. For example, the sales manager commented, “If we are going to expand, I need

to have my finger on the pulse of the business!” In 2000 the board decided to overhaul the existing

information system and predicted an expenditure of £50,000, which soon grew to over £250,000 given the expanding project objectives and company growth. Added to this was a further combined annual maintenance cost of £77,500. The project involved several sub projects, but in this paper, we focus on the client tracking project.

6.3.

The Client tracking Project

Initially the project concerned the acquisition and installation of a client tracking system in the research department. This department provides a personalised service for clients, which has been described by senior management as a “unique selling point.” It was intended that the new system would support the sequence of activities that began when new clients arrived at T.Co, monitoring them as they went through the process of client placement. The client tracking system consists of two main stages: the first is related to the finding and securing of sponsors (companies that provide clients); the second concerns the monitoring of client progress. The quicker the client progresses and finds another position of employment, the fewer resources needed, which generates greater profitability. Senior management hoped that a Customer Relationship Management (CRM) package would standardise and streamline activities across the growing number of locations, contribute towards enhanced profitability, and enable a greater market share. A further underlying objective of the implementation was that the CRM package would facilitate data collection on the external consultants, monitoring their contribution to client progression. A summary timeline of events for the project is shown in Figure 1.

The Client tracking Project Begins: In December 2000 the client tracking project was launched,

with a dedicated project team5 and an anticipated implementation date of February 2002. The implementation was to take place within the research department because the staff there were under pressure due to the increasing number of clients and because their work involved some of the most complex business functions. End-users in the research department were aware that new software was being considered and viewed this as a panacea to their problems, with one administrative worker remarking, “When the client tracking system comes, my head will stop spinning.”

In order to aid in understanding user requirements, the project team conducted an analysis of the client journey, mapping out the business processes (the requirements document). During our initial meetings with the project team, while there was an acknowledgement that users should have a voice in the change process, in practice little concrete effort was put into encouraging participation. A focus day with end-users was scheduled on a number of occasions, but this never materialised as managers deemed the staff to be too busy. One supervisor commented, “We’d love to get people involved, but we just don’t have the time.

The requirements document that had been drawn up by the project team was to be used to evaluate various products. The document specified fairly generic criteria, such as excellent after-sales support, accessible to remote users, compatible with current infrastructure and existing systems. At this stage, their main concern seemed to lie with ensuring the (financial) support of senior management. Much of the documentation was written in a way that appealed to the interests of senior management with

(13)

statements such as: “Our aim is to introduce a flexible system that will streamline and improve our

current business processes and speed up the client journey thus becoming more cost effective.”6

[image:13.595.77.529.160.504.2]

Similarly, the project was claimed to enable “T.Co to continue to provide a business class service and grow effectively in the future, whilst maintaining efficiency in all areas.”7 There was little information provided on the day-to-day functionality that was required.

Figure 1: Client-tracking project timeline

Product Identification and Selection: The project team conducted research into a variety of

packages so that vendors could be short-listed. By December 2001, four different products (from four vendors) had been identified. The process was difficult as the IT manager reported that she had been inundated with calls from numerous vendors following their expression of interest. However, one of the providers (Vendor A) of a CRM package (Siebel) responded by stating that it could not meet the company’s requirements, since its product was “too big” and T.Co “couldn’t afford us”; any dialogue ended here.

Initial negotiations were set up between the project team and three other vendors and their resellers: Vendor B who supplied a Sage product; Vendor C who supplied Goldmine; and Vendor D who supplied a product called Commence. Each provided reference sites and the project team followed up with visits to some vendors, but the IT manager stated that because the sites were in different sectors, it was difficult to evaluate the product in use. Any visits that took place focused on evaluating the vendors and their relationships with their clients, rather than on the software packages.

Communications with Vendor B (Sage) were problematic from the outset. They seemed reluctant to respond, and when invited to T.Co the sales consultant was described by the IT manager as unprofessional and “reeking of beer and fags” and so she assumed that the vendor lacked interest in

6

User Requirements Document - December 2001

7

(14)

a business contract. Cost was used as the basis for rejection. At this stage, it would have been possible to contact other Sage resellers, especially given T.Co was already using a Sage financial system, but Sage was ruled out. Vendor D gave a presentation to senior management, but presented only the standard package (i.e., not tailored), and, it was not perceived as containing the required functionality. The IT manager had concerns that both the company and user base were small and showed little initiative regarding future product development and enhancements. Vendor C, who sold the Goldmine product, had a number of detailed discussions on the nature of the company requirements with the project team before demonstrating the product to the MD, yet it also presented its standard product. Both of these presentations were viewed poorly as generic products seemed to deny the uniqueness of T.Co. Thus, senior managers demanded research into further custom development of their existing applications.

Despite senior managers expressed desire to explore custom development, the project team believed that a package was the best way forward and continued its search. An additional vendor for the Goldmine product (Vendor E) was invited to give a presentation to the project team. Keen to avoid further custom development, the IT manager coached the consultants in the language, culture, and working practices of T.Co in the hope that vendors would be perceived as a reliable provider of a solution.

Having satisfied the project team that it could tailor their product to the needs of T.Co, Vendor E was invited to present to senior management. The vendor made extensive use of the background information and personalised much of the product terminology for the presentation. The MD took control in this meeting and asked if Goldmine was able to support a number of T.Co’s business functions. Notably, many of these functions were outside of the research department and centred more on sales and marketing activities, which was the primary orientation of the package. The sales consultants responded by saying that Goldmine was able to support all of their requirements, even though it was evident that the product was more applicable to sales and marketing activities than to research activities. As the presentation came to a close, the MD shifted his position from initial suspicion of Goldmine to completely embracing it: He remarked: “This system can do all we need….

and more!” Further custom development was no longer an option. The MD also decided that the

system was to be installed incrementally throughout the whole organisation, rather than in the research department, as originally intended. Senior managers’ resistance to cost seemed no longer relevant as the number of user licences increased and the costs were revised to more than double the original estimates. Indeed, the cost of Goldmine from Vendor E was marginally higher than the same product from Vendor C, but in the eyes of senior managers’ vendor C was no longer a viable alternative.

Implementation Planning: As the implementation was now to take place across the whole

organisation, the starting point was altered. The sales consultant recommended that, as the research department was the most complicated business function, it should be left until last. Vendor E proposed a different phasing of the implementation process,8 which was to begin with sales and marketing, since these functions had the “best fit” with Goldmine. This was also the most expensive phase, accounting for nearly 60 percent of the budget. The MD explained that it was less risky to implement this module first, as the standard software mapped closely with the existing functions in T.Co. By contrast, the research process embodied functionality different from the standard version of Goldmine, thus more change would be required. As the process of implementation began, it was now perceived as crucial that users play a part in this process. The IT manager reported: “Organisational change will be managed as a high priority and emphasis will be placed upon bringing the users fully

into the project.”9 A workflow day was planned and it was intended that all the user groups would be

represented.

The Workflow Day: Departmental representatives were invited to attend the workflow day, since

senior managers agreed that all personnel needed to participate in the project to ensure minimum

8

Vendor E workflow document – July 2002

9

(15)

resistance to change. The technical consultant began the meeting by introducing the package and outlining the purpose of the day, which was to draft an overall specification for T.Co. He was quick to point out that although the software was highly configurable, “Sometimes the organisation has to

bend toward the product as well.” He also stressed that it was up to the users to decide how they

wanted the product to work and pressed the point that if “you don’t say it, you don’t get it,” thus ensuring clear demarcation of responsibility.

As the technical consultant discussed user requirements, he configured the package on his laptop, which was linked to a projector. As the capability of the application began to unfold in front of them, staff refined and generated further requirements. The mood was one of optimism since they had been convinced by senior management and the project team that the product was “good for them,” even though they were only just discovering its capabilities. All the team members aided the technical consultant by suggesting how they might change their existing ways of working to accommodate the software. As the day progressed, an underlying tension emerged as users focused on lower-level details (their everyday working practices), whilst the technical consultant resisted suggestions of reconfiguration in the hope of being able to implement the vanilla software — by far the easiest option for him. For example, the sales manager wanted automatic reminders for follow up actions, and although initially the technical consultant said this was not feasible, when pressed, he agreed that reconfiguration was possible. It became obvious that he wanted to minimise configuration and customisation, and described the staff discussion of their requirements as “navel gazing,’ complaining that they were “gettinginto the detail.’ When asked if Goldmine was capable of converting a client into a sponsor at a later date, the technical consultant replied that this may be possible in the future, but only “if enough customers ask for it.”

As the discussion proceeded, it became clear that the technical consultant had not familiarised himself with either the original requirements documentation or the basic workings of T.Co. Looking increasingly uncomfortable, he changed the boundaries of the discussion by stating that the purpose of the day was to focus upon sales, not other areas of the business. During a coffee break, the human resources manager remarked: “I’ve only just joined the company and I know more than he does, he’s just not prepared.”

By the end of the day, staff expressed unease about the selection of Goldmine, and these concerns were voiced to the MD. He contacted the sales consultants to express his disappointment since he had assumed the workflow day would be focussed on aligning T.Co processes with those embedded within the software, rather than ascertaining whether or not it was the right product for them. The sales consultants advised him to wait for the delivery of the workflow document. Pending its arrival, the MD arranged a meeting with staff members in the hope of persuading them that adopting Goldmine was the best way forward. At the meeting, the MD asked staff to agree that Goldmine could broadly do what they required. He said: “…we know there are problems with Goldmine, but can

it do most of what we want – yes or no?” Essentially, he was pushing for a decision and given his

dictatorial attitude, the majority of people acquiesced. On this basis, the decision to proceed with Goldmine was made, despite not having yet received the workflow document.

Signing off on the Workflow Document: When the workflow document10 arrived, it failed to meet

the expectations of the project team. The IT manager said, “It’s not clear what we are buying at this

stage, it’s going to need more work.” The research manager was equally unconvinced, stating “It does

not provide us with enough detail about the proposed system for us to sign this off.” By now, the MD

had become the product champion and arranged a series of internal meetings to enroll, support and further endorse his decision. Although backing was sought from end-users, there was no attempt made to involve them, and the MD dealt directly with the technical consultant. He stated he had

different, simpler requirements”11 and the changes he suggested were reflected in a second workflow

document12 that was delivered at the end of September. The sign-off of this document was scheduled

10

Vendor E workflow document – July 2002

11

For example, he wanted to generate exception reports that would highlight where deadlines had not been met.

12

(16)

for 21 October 2002, but further internal meetings with the project team generated additional requirements. The purchase was postponed to December, and further postponements were still taking place in 2003 when our involvement came to a close. When interviewed, the IT manager commented that it was becoming difficult to keep staff motivated because of numerous postponements and false starts. Her patience was clearly wearing thin: “This isn’t over, I expect the workflow document to be double the size it is now – just you see.”

7. A Framework for the Packaged Software Selection Process

[image:16.595.72.527.218.751.2]

This section presents the theoretical framework (depicted pictorially in Figure 2), which draws on some of the conceptual tools from SCOT and is based on an analysis of the findings of the field study.

(17)

We use the findings that have emerged from the case to offer rich propositions in terms of broad and diffuse implications and the generation of theory. In the discussion that follows, we augment the SCOT approach with Klein and Kleinman’s (2002) suggestions for illuminating structural influences, because in order to understand the capacity of groups to shape a technology we need to discern where they are situated within a structural matrix. In this respect, the contribution shows how the various actors (RSGs) shape the selection process, noting the influence of dominant groups, while acknowledging their position within a broader structural context.

Predominantly, studies of packaged software selection broadly comprise a linear model of activities associated with identifying user needs, evaluating software on the basis of those needs, and then selecting the most suitable package on this basis. Drawing upon a more critical/constructivist literature and undertaking the fieldwork reveals substantial variations in practice. Together, these form the basis of the framework, which is intended to represent competing perspectives of the packaged software selection process and illustrate that the same technology is perceived differently by different groups of people and that these actors have varying levels of ability to dominate at several stages throughout.

The framework explicitly acknowledges the role of relevant social groups (RSGs) involved with the packaged software selection process. The identification of RSGs in the case study reveals how they both defined the technological problem differently and disagreed about what constituted the “technological solution.” Identifying the groups and their major concerns in simplified form demonstrates the conflicting views on the adoption of packaged software (see Table 2). By and large, the boundaries and composition of the groups can be explained primarily along hierarchical lines and by the division of labour. The research and sales and marketing departments represent functional units; the project team represents middle management; senior management controls economic resources within T.Co and determines strategy; the vendors and consultants are external to the organisation. Table 2 illustrates shared perceptions within these groups, but this is not intended to imply that these groups are homogenous or that the groups operate on a level playing field, since some have more authority than others and a greater capacity to influence the decision-making process. Regarding inequalities within groups, the IT manager steered the project team and, similarly, the MD shaped the direction of senior management strategy. Therefore, it cannot be assumed that all viewpoints within RSGs carry equal weight and are given equivalent representation. These groups also change their perspectives over time; for example, the MD fluctuates from initial enthusiasm about packaged software, to disappointment and a desire to pursue custom development, before returning to act as product champion for Goldmine. These shifts are documented in Table 2 and can be seen in relation to particular events over time.

Some groups had greater relevance, and the power to influence rests primarily on access to economic resources. For example, the project team was established at the request of senior managers and it had the capacity to make recommendations to the board. Yet ultimately, the MD had the final say and indeed the decision he made was largely unrelated to the project teams efforts. Implicitly within organisational structures, rules of access allow social actors to make decisions at the level that is deemed appropriate to their status and position. So, while various interpretations of the technology existed, power imbalances meant that control of the negotiation process was commandeered by the MD, who exercised ultimate control when differing perspectives surfaced.

(18)
(19)

One of the criticisms levelled at SCOT is that it tends to neglect broader political and economic influences. In this research, we have attempted to contextualise the case study with our consideration of the wider environment. RSGs extended beyond the consumer organisation and included consultants and the packaged software industry more generally. As compared with large enterprises, this SME study reveals the degree of influence this group had in steering the direction of the project. For them, the technological solution was based on their desire to secure the business, as the sales consultant promised whatever configuration was deemed necessary to ensure T.Co’s sales contract. Their selling skills and ability to present Goldmine as the technological solution were persuasive, to the extent that the MD became enrolled into the consultants’ worldview and aided their project pursuit, rather than aligned with the endusers. The consultants’ task was to impress the powerful owner-manager, rather than mobilise the support of a broad range of organisational actors, as might be the case in a large enterprise.

In the case study, the ability of RSGs to enable their view of technology to dominate and stabilize can only be partially explained with recourse to structural influences and economic positioning. While the MD, in particular, assumed that his position in the firm would ensure that his shifting interpretations would be endorsed by others, in reality this was not the case. Tensions simmered beneath the surface and, in order to negate the contrasting views of others (such as endusers following the workflow day or the project team when the scope changed), he aligned himself with other RSGs (sometimes the project team, sometimes the vendors/consultants) to strengthen and validate his interpretation of the technological solution. By doing so, he ensured that the outcome suited his interests, while not appearing as an outlier.

These differing views among RSGs characterise the technology as having a degree of interpretative flexibility. The articulation of different views is reflected in the framework as different perceptions of

technological problems and solutions; these occur throughout the selection process. The case has

borne out the claims that the artifact’s identity is open to distinct constructions by different groups “the best of breed,” a technology with reliable after-sales support, a means to generate efficiencies and free up time, an instrument for monitoring consultants, a deliverer of economic benefits, a product to be sold) and that its technical properties are subject to social variables. Senior management wanted to effect managerial changes and carefully framed the project by disclosing certain benefits (standardization and increased efficiency) that had broad appeal to time-pressured staff, while remaining silent about the desire for performance management information on the external consultants. For senior managers, the technology also represented a means of augmenting customer service, thereby potentially leading to increased profit margins and a greater market share. These issues are clearly of primary concern to senior managers and do not feature in the articulation of reasons for packaged software selection within other RSGs, such as endusers. For them, a more pressing concern was the desire to eliminate time-consuming, onerous tasks and to reduce the duplication of activity.

The study also reveals how differing perceptions of seemingly objective criteria, such as costs, fluctuate over the course of the project. From the perspective of senior management and the project team, the seemingly favourable cost of packaged software was seen as preferable to custom development and was one of the reasons for abandoning the latter. On the surface, costs are tangible, objective criteria that can be used as a basis for comparison, yet the more expensive supplier of Goldmine was awarded the contract and the costs escalated as the scope increased.

(20)

It would be naïve to assume that the RSGs with the power to influence the selection process are placed entirely within the consumer organisation, since the packaged software industry and the accompanying intermediaries are likely to have considerable influence in shaping the artefact and the decision-making process. IT vendors and consulting firms rely heavily on the power of advertising to persuade potential adopters that their products are the solution to their organisational problems (Pozzebon et al., 2006; Swanson and Ramiller, 2004), while downplaying the limited generalizability, complexity, and risk involved (Swan et al., 2000). The consultants from Vendor E played a major role in shaping the different perceptions of technological problems and solutions: The sales consultant persuaded the MD that packaged software was the solution and the scope of the project should be expanded, while the technical consultant caused considerable distress to endusers who became convinced that Goldmine was inappropriate for their needs.

The framework suggests that throughout the process, additional reasons in support or against package adoption may emerge; this could occur, for example, during requirements gathering or evaluation activities. This emergence of further problems and solutions has consequences for the

stabilization of the technology as closure is achieved when the RSGs see their problems as having

being solved by the technology. At T.Co, closure was achieved “by re-definition of the problem” (Pozzebon et al, 2006) in that the initial project focus (technology support for the research department) was re-defined as the implementation of Goldmine across the entire organisation, beginning with sales and marketing. In this respect, the problem was re-defined so that the available technology could deliver the solution.

According to the SCOT approach, closure is seen as the product of consensus, but as the study illustrates, the enduring relations of power and control of resources means that the opinion of the MD is the one that carries most weight. As a consequence, although it may appear on the surface that consensus has emerged, in reality the dictatorial attitude of the MD prevails. Closure implies conclusion, but it is not necessarily permanent, and further post-hoc reasons may also emerge to either stabilize or de-stabilize the technology. Conflict and controversies may re-emerge, and so stabilization and closure are essentially ongoing, provisional positions.

We will now move on to discuss the three different aspects of the packaged software selection process: requirements gathering, evaluation, and selection decision. The framework is intended to illustrate that the process is shifting and emergent — these phases can be stand-alone, can overlap with each other, may be repeated, or can be avoided entirely.

7.1.

The Packaged Software Selection Process: Requirements Gathering

Requirements gathering is included in the framework, although we acknowledge that requirements are continually emerging (Truex et al., 1999) and that differing, possibly competing sets of requirements will be brought to bear throughout by distinct RSGs. The iterative nature of the process may result in the emergence of new requirements.

(21)

roll-out with the most standard (and most financially rewarding) part of the project.

Critically, those in the wider market environment may also play a role in shaping these requirements. In a market, oriented environment, not all requirements will be perceived as equal, with different types of users having varying levels of access to and influence with the implementation partner. The nature of packaged software development means the developer is involved in the process of “predicting the future world” of consumers and shaping different organisational and market environments. The final consumer often has little opportunity to influence the artefact beyond choosing whether to adopt or not (Williams and Edge, 1996). As the technical consultant commented, some changes are possible, depending on the level of customer demand.

7.2.

The Packaged Software Selection Process: Evaluation

The evaluation process may influence which package is selected for implementation; however, there is no guarantee that any formal evaluation will occur, or if it does take place, that it will necessarily affect the selection decision. Given the emphasis on the role of various RSGs, there are multiple and sometimes competing evaluations that further complicate the process of selection.

One of the problems with packages is that the characteristics are difficult to ascertain and so it is difficult to evaluate them across a common plane (Pollock and Williams, 2007). The standing of suppliers, the provenance of their system, and observed displays of competence cannot be separated out and numerically ranked. The evaluation criteria that was described in the requirements document was brief and fairly generic (excellent after sales support, accessible for teleworkers, compatible with current infrastructure and packages, reducing time-spans, and streamlining processes). In practice various measures were used; these had different explanatory power and their value shifted throughout the duration of the project. These “stabilized forms of accountability” (Pollock and Williams, 2007) gave considerable discretion to the actors and RSGs, allowing them to elevate the importance of certain criteria to suit their own agenda.

Regarding vendors, while Vendor A rejected T.Co (we’re too big), Vendor B was considered unresponsive “they don’t want our business”, which calls into question the view that consumer organisations are able to make choices in a buyers’ market. The choices for SMEs may be more limited than for large enterprises, as the process of evaluation is reversed with vendors rejecting the consumer organisation. The case study shows how Vendor C and D were outside the provenance of the system (they failed to tailor their demonstrations), yet Vendor E, who was selling exactly the same system as Vendor C – only at a higher cost – was deemed appropriate. Echoing Pollock and Williams (2007) we see that the sales demonstration takes on a magnitude of importance that is disproportionate to the amount of information being provided. Yet, this 30-minute presentation was sufficient to turn around the opinion of the MD. The public sales demonstration became the only criteria used to adjudge packaged software and was crucial for aligning views, particularly in an SME environment where few employees had technical knowledge. What was clear after the presentation was the volte-face by the MD and the presumption that others would follow suit and endorse his opinion.

Wybo (2007) comments how vendors may intentionally cultivate relationships with influential members of the organisation, leveraging social occasions as a tactic to gain influence. Social relationships with Vendor E started out well, as the MD of the company struck up a rapport with the MD of T.Co. The IT manager described this as playing a significant role in the MD’s evaluation of the product, since he was vocal in his praise of their commitment of “top-level support” to the project. This reveals how personal criteria plays a role in the evaluation process, as contrasted with the prevalent notion of rational, objective evaluations.

7.3.

The Packaged Software Selection Process: Selection Decision

(22)

selection was based upon Vendor E’s a successful sales presentation of Goldmine. The IT manager was not able to foresee that the MD would radically amend the original plan by deciding that the package should be rolled out to other areas of the company, where there had been no instances of requirements gathering or evaluation. Moreover, even though Goldmine had been selected, purchase did not automatically follow. Indeed, the project stalled after selection because of serious problems, which occurred at the workflow day, suggesting that a decision in favour of packaged software adoption does not necessarily guarantee implementation and usage.

8. Conclusion

Given the momentum surrounding software packages in the 1990s, organisations increasingly engage in the selection, purchase, and adoption of these products. Yet much of our understanding of this is based on prescriptions that have dominated the IS literature to date. The primary contribution of this paper is to challenge such studies by drawing on the emerging critical/constructivist literature and offering a theorization that furthers our understanding of this process.

Drawing on both the existing literature and the longitudinal case study, we are able to offer a number of propositions concerning packaged software selection:

The value of generic recommendations arising from the functionalist literature, which are often based on a linear model of selection and adoption, fail to offer useful prescriptions for action and have little bearing on the reality of organisational life.

While package software is viewed as a bounded artefact, the same technology may be perceived differently by distinct groups of people. These groups have varying levels of ability to dominate, as not all viewpoints carry equal weight and have equivalent representation. Levels of authority are often related to structural positioning, and power may be mobilized when oppositional perspectives need to be quashed. The SCOT approach is useful for explaining how this manifests, but in order to avoid agency-centrism, this is augmented with a political perspective to account for structural influences.

We ought to expand our analysis beyond the organisational level and the point of encounter with the user. Due attention should be paid to wider market forces and the array of social actors that are involved — the software suppliers and vendors, the IT consultants, and the industry analysts. These outside parties may wield considerable influence in shaping the selection process, as they mobilise expectations of technology and organisational change/improvement. Situating the small firm T.Co within the wider environment can help explain divergences from the process of negotiation that occurred within the large, public sector environment from the Pollock and Williams (2007) study. Had T.Co been a large firm, the relationship with vendors may well have been quite different.

Technological legacies and histories shape how future development, problems and solutions are interpreted. With reference to the case, T.Co’s past encounters with software suppliers and consultants framed their expectations.

The emergence of an apparent consensus should not be assumed to signify that all the stakeholders agree on the outcome. This could be skewed by the ability of dominant groups to ensure their viewpoint prevails. This, in itself, is de-stabilizing.

Although one of the purported benefits of packaged software is that it removes the lengthy process of bespoke development, as the study reveals, there is not necessarily a clear end-point to the process, as problems and solutions are reconsidered and re-defined along the way.

Figure

Figure 1: Client-tracking project timeline
Figure 2: A Framework for Packaged Software Selection

References

Related documents

This essay asserts that to effectively degrade and ultimately destroy the Islamic State of Iraq and Syria (ISIS), and to topple the Bashar al-Assad’s regime, the international

Perhaps the most controversial law to have a major bearing on 2017 is the highly contested Democracy Sustainability Act—passed by the House and Senate in 2012 despite receiving

Results suggest that the probability of under-educated employment is higher among low skilled recent migrants and that the over-education risk is higher among high skilled

National Conference on Technical Vocational Education, Training and Skills Development: A Roadmap for Empowerment (Dec. 2008): Ministry of Human Resource Development, Department

The state bridging pension cannot ex- ceed the state old-age pension that two people receive jointly, this being a sum of approx.. However, you can opt to receive a lower

19% serve a county. Fourteen per cent of the centers provide service for adjoining states in addition to the states in which they are located; usually these adjoining states have

ًلاومعم رد تاعلاطم مس یسانش تارذ فلتخم زا نیا بیکرت ب ه لیلد تیللاح و تیمس نییاپ نآ ب ه ناونع لرتنک یفنم هدافتسا یم دوش ( 7 ، 9 .) ره دنچ Warheit و

Field experiments were conducted at Ebonyi State University Research Farm during 2009 and 2010 farming seasons to evaluate the effect of intercropping maize with