Benefits Of Is It Implementations

ARTICLE IN PRESS

International Journal of Information Management 25 (2005) 502–515

0268-4012/$ -

doi:10.1016/j.

�Tel.: +1 80

E-mail add

www.elsevier.com/locate/ijinfomgt

Gaining benefits from IS/IT implementation: Interpretationsfrom case studies

Gurpreet Dhillon�

Information Systems Department, Virginia Commonwealth University, 1015 Floyd Avenue, Richmond,

VA 23284-4000, USA

Abstract

This paper examines those contextual issues that determine the success of a computer-based informationsystem. It shows that a narrow technology-focused orientation in systems development is a limiting factorin realizing benefits. In doing so it argues that real benefits reside not within the IT domain but instead inthe changes in the organizational activities that the IT system has enabled. The paper reviews such benefitsthrough two information system implementation case studies.r 2005 Elsevier Ltd. All rights reserved.

Keywords: IT benefits management; Interpretive study; Case study; Qualitative research

1. Introduction

Over the years organizations have been striving to realize benefits of information systems (IS)and information technology (IT) investments. Indeed a phenomenal amount of money is lostbecause of inability of the organizations to realize IS/IT benefits. Figures coming from the USsuggest nearly $59 million being spent in cost overruns and some $81 million in cancelled IS/ITprojects (Johnson, 1995). Losses of this magnitude have often been attributed to the inability oforganizations to carry out adequate IS/IT-related benefits management (e.g., see Keil & Robey,1999; Ward, Taylor, & Bond, 1996). Nearly two decades ago, the Index Systems poll of 240 senior

see front matter r 2005 Elsevier Ltd. All rights reserved.

ijinfomgt.2005.08.004

4 828 3183; fax: +1804 828 3199.

ress: [email protected].

www.elsevier.com/locate/ijinfomgt

ARTICLE IN PRESS

G. Dhillon / International Journal of Information Management 25 (2005) 502–515 503

IS executives found that although 90% did not know how to measure the benefits of IT, morethan 50% believed that IT investments were enhancing their performance (as reported inComputerworld, 1988; Connolly, 1988). A survey of UK businesses by Ward et al. (1996) found86% of the respondents as saying that it was not possible to anticipate benefits. The main reasonthat benefits are identified and quantified seems to be in order to gain project approval. Thesurvey returns indicated that in 47% of the cases, project justification methods overstated thebenefits to get expenditure approval. However, once this ‘hurdle’ has been overcome, little furtherattention is paid to benefits, and most effort is expended on technical implementation. Thefindings of the surveys reported above reflect a degree of complacency on part of IS/IT users. OneUK building society manager, when asked how IT investments were justified, was quoted assaying, ‘‘In larger projects, we mostly go by gut feel. If the project is small, we try for a return-on-investment’’ (Financial Times, 13 June 1989). As Symons (1991) notes: ‘‘the greater the expenseand strategic importance of an information system, the less likely it is to be evaluated using aformal methodology’’. With respect to the use of formal methodologies, the Ward et al. (1996)survey found that only 50% of the organizations had a formal methodology (i.e., systemsdevelopment, project management, or investment appraisal) and only 20% had implemented allthree methodologies. Only a minority of organizations believed that these methodologies wereeffective in ensuring success.

Given the above background, this paper seeks to provide insight into some factors that willensure the delivery of benefits from IS/IT investments. The paper argues that although the choiceof an appropriate methodology is important in ensuring project success, it is not the only factor. Itis equally, if not more, important to examine the organizational context that the informationsystem is being developed for. The paper further suggests that organizations will have successfulIS/IT applications only when the drivers for investing in IT, the expected benefit set and theorganizational mode of working have been carefully considered. These three aspects need to beintegrated into a benefits management approach. The argument of this paper is conducted byevaluating a hospital information system and a customer service information system.

2. Understanding benefits management

It is useful to have an understanding about the notion of ‘benefits management’ in the contextof IS/IT. One means of doing this is to consider the ‘outcomes’, in that the benefits which aresought are the outcome of business changes, which have been brought about by the introductionand use of IT. The ‘benefits’ are then the difference between the desired outcome and the currentsituation. For instance, the outcome of an IT system implementation may be a staff reduction—the benefit is a cost saving.

However, to be able to realize this benefit, it will be necessary to make changes in the way thatthe work is hitherto done. It will not be sufficient to merely install the IT application and hope forthe savings. At the very least, some training will be required, and probably changes in tasks, rolesand responsibilities (e.g., see Benjamin & Levinson, 1993; Brynjolfsson & Hitt, 1998). Benjaminand Levinson (1993) claim that the benefits of IT are often not realized because investment isbiased towards technology and not towards managing change in process, organizational structureand culture. They conclude that managing change enabled by IT is at least as important as

ARTICLE IN PRESS

G. Dhillon / International Journal of Information Management 25 (2005) 502–515504

bringing IT to the organization. Dhillon and Backhouse (1996) also stress on consideration beinggiven to the informal softer issues if risk of failure is to be avoided.

Johnston and Yetton (1996) bring out another interesting issue regarding benefits managementand business change. Their notion of fit and compatibility suggests that the IT configuration of anorganization should match the organizational structures. Although the main focus of their paperis on integrating IT divisions during a merger, the concepts seem to be equally relevant within anorganizational context. Similar arguments have been proposed by other researchers as well,particularly those who have focused on strategic alignment (e.g., see Burn & Szeto, 1998;Henderson & Venkatraman, 1993). Thus it can be suggested that the notion of IS/IT success (i.e.the management into existence of desired benefits) be fundamentally linked to changes within thebusiness. Although the importance of having an approach to business change has been recognizedin the literature (e.g., see Benjamin & Levinson, 1993; McKersie & Walton, 1991; Prager &Ovenholt, 1994), a study by McGolpin and Ward (1997) found that in addition toinstitutionalized change management practices, a well-defined benefits management process wasthe most significant factor in the success of IS/IT implementation.

In general, it can be stated that the proposed benefits from an IT investment project must link insome way into the objectives of the business itself. Expenditure proposals should take the form ofa business case with an explicit statement of how the system will contribute towards businessobjectives, goals or critical success factors via the changes in the business it will facilitate/support.The contribution should also be measurable—or at least observable—in terms of the businessobjective. If this is not achieved then there is significant risk that the project will be off-target in abusiness sense, will consequently not be owned by affected stakeholders, then subsequently slideinto being merely technology implementation with an over-emphasis on technical functionality atthe expense of business improvements. Findings from the literature support this assertion (e.g., seeBlonkvist & Goble, 1994; Dhillon, 1995; Keil et al., 1995). Failure to engage with the trulyimportant business objectives effectively restricts the contribution to low-level orders of benefit(e.g., small improvements in task efficiency). For success, there must be a clear dependencylinkage from IT features which enable sets of changes in working practices to occur, that in turnleverage useful business changes which themselves contribute to a desired business goal. Thelinkage is best described in terms of the ‘fried egg’ analogy (see Fig. 1).

The high-level view of stages of benefits dependence is a useful means to understand howbenefits come from changes within the business. The technology component of an IT project istypically the focus for most of the project effort. The linkage mentioned above is often addressedmerely through the adding-on of a training component to the project plan. This generally resultsin some benefits at the formal system level as shown in Fig. 1. However, the majority of realbenefits will come from changes within the business itself.

Fig. 1 also illustrates the issues of project scope and managerial responsibilities. For fullbenefits, both IT management and business management must be involved in the project, withclearly defined roles for the latter in the area of change. The ‘training’ component of a project isusually solely concerned with basic hands-on training in how to operate the new IT system.However, as Fig. 1 indicates, ‘education’ is also necessary in order that stakeholders understandwhy the IT investment is being made, what benefits they and the overall business will obtain, thenecessary changes required and their role in achieving them. Such has been found to be animportant factor in exploiting the full business potential of IT.

ARTICLE IN PRESS

IT System

Has few benefitson its own

Organizational

environment

The informal organizationalenvironment affords

the business changeswhere most benefits

are embedded

Formal

training/education

program

Some benefitscan be linked to

formal training and education programs

Fig. 1. A high-level view of benefits dependency.


3. Case studies

This section presents two case studies. Case 1 focuses on a British hospital for people withlearning disabilities where an IT system was being developed for supporting organizationalprocesses. Case 2 relates to the implementation of a customer service information system in acomputer manufacturing organization. The purpose of the case studies is to develop anunderstanding of deep-seated organizational issues related to IT benefits realization. As has beennoted in Section 2, although there are a number of studies focusing on IS/IT success and IS/IT-related organizational change, there is a dearth of interpretative case studies focusing on realizingIT investment payoffs. The findings presented in this paper will add to the existing research inbenefits realization and IS/IT evaluation (e.g., Canevet, 1996; McGolpin, 1996; Miller & Dunn,1999; Serafeimidis & Smithson, 1996). Findings presented in this paper are drawn form caseworkcarried out during 1996–2000. The conduct of the case studies was informed by Walsham’s notionof interpretive research (see Walsham, 1993, 1995). Data were collected from both primary andsecondary sources. Primary sources covered various IS/IT project stakeholders and majordecision-makers. Topic guides were prepared for each in-depth interview. Numerous probingquestions were used to identify underlying patterns. Secondary sources were related to internalmemos, publications and government reports.

3.1. Case of the hospital information system

This case shows that an IT-based solution on its own adds little value to the organization.Substantial gains can only be achieved if there are commensurate business changes. The caseillustrates that just an elegant systems design and implementation falls short of realizing the

ARTICLE IN PRESS


anticipated benefits. It further suggests that benefits, tangible and intangible, often reside in anorganizations internal and immediate context.

3.1.1. Organizational environment

The case study hospital provides services to people with learning disabilities through a numberof sites. In line with the national initiative, service provision takes the form of a single line ofcommand and an integrated structure. The hospital is dominated by a number of specialisms.Although formal communication lines exist among various functions, the day-to-day running ofthe hospital depends much on the informal communication among specialisms to coordinatework. The success of a diagnosis or a treatment plan of a patient, therefore, is largely dependentupon the ability of the specialists to adapt to each other.

Given that the hospital exclusively looks after psychiatric patients, the hospital managers havea dominant belief that such patients can be best served by moving them into a natural communitysetting. Such a belief stems from the philosophy advocated by the central administrators. As aconsequence, the health care delivery process within the hospital is viewed as a dynamic systemwhere people with mental health problems enter the hospital, are offered treatment anddischarged back into the community. All along the process, the emphasis is to encourage patientsto stay in the community.

The hospital administrators consider a two-fold advantage of such a system. First, patients withlearning disabilities will be able to experience and live in a natural environment. Second, withpatients moving out into the community, overhead cost of running a hospital will be substantiallyreduced. Hence, patients would only be admitted to the hospital if their condition deteriorates orwhen they need urgent specialist medical attention.

Health care within the hospital is provided through a service specification, which is made up of anumber of elements called care packages. Hence, for any patient there would be a number ofrelevant care packages. The individual mix of care packages would constitute a servicespecification. The purpose of defining care packages is to establish the cost of the service beingprovided. When a patient is referred to the hospital, a need assessment is done and an individualcare plan is developed. The need assessment and the subsequent care plan implementation aredone by a multidisciplinary team made up of nurses, physiotherapists, dieticians, doctors, etc. Thehospital model for service planning considers multidisciplinary teams as central to the success ofthe health care delivery process.

A key issue with the health care delivery process at the hospital is the need for timelyavailability of many sets of information, and a computer-based information system was seen as ameans of filling the need. It was thought that such a system would not only help the hospitalprovide precise information on its activities, but also add value to the health care delivery process.It would also overcome certain current shortcomings such as the inability to perform audits andassess the effectiveness of resources used. Significantly, it was to embrace the care planningfunction mentioned above.

3.1.2. Towards an IT-based solution

With respect to the need for an IT-based solution, interviews with members of the threeprofessional groups (doctors, nurses and administrators) revealed conflicting ideologies—bothorganizational and professional. The doctors and nurses believed in the profession and its norms.

ARTICLE IN PRESS


Although they agreed with the importance placed on managing the information, they were unsureif an all-encompassing computer-based system was the ideal solution. They saw the new system asenforcing new goals and objectives onto the hospital environment. The managers, on the otherhand, wanted to derive business value out of the health care delivery process. Though the nursesand doctors agreed with this in principle, they had their own ideas as to how it could be achieved.

The main point of contention for the doctors and nurses was the nature of the managementsystem designed by the managers (described above). The doctors felt that at a clinical level, thesystems could not be utilized effectively largely because they did not reflect the very nature ofclinical work. Even though the hospital focused attention on moving patients out into thecommunity, the computer-based system was essentially geared to the needs of the residentialpatients, i.e., the long-stay patients in the hospital. In this respect, the objective of the clinicalsystem was clearly out of touch with the new organizational policy of moving patients out into thecommunity. The managers, however, did not agree with this objection raised by the doctors andthe nurses. Further investigations revealed a lack of communication between the managersand the system analysts involved in carrying out requirement analysis. It became clear that thesystem analysts had only sampled those aspects of the hospital that were primarily residential innature.

It also became clear from the interviews with different members of the organization that therewas a clear mismatch between the formally designed information system and the actual practices.Therefore, the IT system may neither contribute to productivity nor effectiveness of theorganization. Furthermore, there was an inherent weakness in the informal organizational norms.This resulted in the clinical and business objectives not supporting each other. Since the variousgroups within the organization disagreed with the manner in which the information system wasconceptualized, analyzed and designed, they felt that the computer-based system would imposeunrealistic groupings onto members of the organization. Therefore, there was a risk that theinformation system would not be used.

3.1.3. Systems design

The hospital information system project team and system developers regarded health careprovision as an input–output process with patients coming into the hospital, being treated andthen discharged into the community. This conception dominated the modeling activities ofsystems developers. Insufficient consideration was given to the impact of the system on the users.Having purportedly identified the problems and bottlenecks that slowed down the input–outputprocess, the designers developed the logical view of the system (using structured systems analysisand design methodology—SSADM). The logical view was so heavily focused on the input–outputprocess idea that it lacked a representation of the real operations.

The IT-based system embodied the output of the above design process and formed an integralpart of the health care delivery process. A key aspect of the system was the design of individualcare plans for each patient. Since the health care delivery process and the related individual careplans did not represent the reality, the needs of the doctors were not met. The clash of logicalinput–output model vs. doctors’ ways of working shows itself dramatically in that the system asdesigned saw the various ward rounds that doctors made being decided by the care plan—whereasdoctors would formulate care plans as a result of doing ward rounds. In fact, the doctors saw careplans and ward rounds as one evolving process not the hierarchy envisaged in the system.

ARTICLE IN PRESS


3.2. Case of ESL’s customer service information system

This case illustrates the shortcomings of an IT-based solution that gives little credence toorganizational change issues. The case study shows that although a computer-based solution mayseem to promise substantial benefits, these cannot be realized unless the organizational context isunderstood. Following the argument presented in the previous case study, this case also identifiesthe inadequacies of structured methods in systems design. The case is set in Electronic SystemsLimited (ESL), an organization involved in the manufacture, sales and marketing of PC clonesand peripherals.

3.2.1. Organizational environmentThis section describes the customer service function of ESL, a manufacturer of PC clones and

various peripherals. At the time of the study, ESL had been in business for some 15 years. Theorganizational and manufacturing processes were mature. The company boasted of selling PCsand various peripherals at very competitive prices. Because of the nature of the business, thecompany laid a lot of emphasis on sales and marketing. In order to stay in business, it wasimportant for the company to bundle free software and services along with the sale of a given PC.It also meant that the company was in a position to respond to the needs and expectations of thecustomers. Most of the time, the customer service component of the sale dealt with honoring thewarranties and annual maintenance contracts. The success of maintaining the existing customerbase and attracting new ones largely depended upon satisfying the current ESL customers.

Since the very existence of ESL was based on increased sales volume, the company oftenignored the ‘customer service’ component of the sales. Providing customer service was also asignificant challenge for ESL. This was because most of the components (e.g., motherboards,memory chips, etc.) were procured at the lowest available price from numerous manufacturers inTaiwan and South Korea. Although a given batch of machines would have some level ofstandardization, it was very difficult to keep track of the details. This meant that whenever therewas a problem with a machine at customer site, the service engineer was often opening a ‘blackbox’, not knowing what to expect. This meant that, more often than not, the particularcomponent had to be removed and brought back to factory premises.

The customers would be happy if customer service turn around time was reasonable and if ESLwas in a position to identify the status of their complaint/service request. However, this was oftennot the case because the maintenance engineers were usually as baffled as the service engineers.This was because of two reasons. First, the maintenance department did not have any clue of thenature and type of parts used in the machines (e.g., the layout of motherboards for every batch ofmachines, etc.). Second, their competence was limited to card-level repair (i.e., if they diagnosed afault in a particular card, it would be replaced by a new/alternative one). The combination ofthese two factors meant that customer complaints could not be addressed since the maintenanceand customer service departments did not know the details of each of the parts used in theproduction of a PC. As a consequence, they were unable to maintain an inventory of cards andother parts that went into the production of each batch of PCs.

Clearly, there were problems in the communication between various functional areas of ESL.To begin with, the materials and procurement department had to document the details for eachbatch. The production department had to maintain a strict discipline in maintaining the standards

ARTICLE IN PRESS


for each batch. Furthermore, the configuration of each production batch had to be communicatedto maintenance and customer service departments. ESL recognized this problem and themanagement systems department was entrusted with the responsibility to provide an integratedcomputer-based system to support all necessary functions so as to increase the level of ESL’scustomer service.

3.2.2. Towards an IT-based solutionIn assessing the nature and scope of the problem at ESL, interviews were conducted with

prominent stakeholders in each of the concerned functional areas, viz. materials and procurement,production, maintenance, customer service and management systems. Discussions revealedconflicting viewpoints. The maintenance and customer service departments felt that they did notneed a massive integrated computer-based system. They felt that it would be too laborious andtime consuming to build such a system. All they wanted was a sufficient inventory of cards andparts that were used in each production batch. Managers in materials and procurement were notconcerned with customer service. For them, the firm profited because of their ability to sourcecomponents in a very cost-effective manner. They had a manual system that logged the details ofeach purchase. The production manager, on the other hand, did not communicate with materialsand procurement. He worked on production schedules based on reports from the sales andmarketing department. The management systems department managers felt that all departmentshad the right kind of information that is necessary to develop a good customer serviceinformation system, all that had to be done was integrate the individual systems.

In developing a computer-based solution, the management systems department felt that theyhad to develop a huge database of all parts/components coming into ESL and linking them tomachine numbers and production batches. They felt that by developing such a database, theywould be able to provide the right kind of information necessary to provide better customerservice. The production and materials and procurement departments disagreed with thisapproach. They felt that the development of a new computer-based system would radicallychange their existing business processes. They were unwilling to change. This would also have aknock-on effect on the marketing department since they usually focused on promising a lot to theretailers and then asked the production department to meet their deadlines. The managementdepartment conveniently ignored these concerns since it had the blessings of the CEO.

3.2.3. Systems designIn realizing their mission to develop an all-encompassing IT-based solution, outside consultants

were hired to carry out the systems analysis and design exercise. As in the case of the hospitalinformation system discussed in Section 3.1, the management systems project team and the systemdevelopment consultants considered the customer support problem domain as an input–outputprocess. They viewed the cards and components coming into ESL, being put together by theproduction department and a finished product being sold by the sales and marketing department.The outside consultants had a limited understanding of the nature of the business, hence theinput–output conception dominated their ‘world-view’. Using the Jackson Systems Developmentmethod, a logical view of the business was prepared through the use of Jackson diagrams. Clearly,the needs and expectations of dominant user groups within ESL were ignored. Furthermore, themechanistic representation of ESL’s business world forced a particular way of working on the

ARTICLE IN PRESS


departments, hence failing to extract a part of the complex business process that neededautomation. As one materials manager pointed out, ‘‘they are trying to do too much and change alot of unnecessary tasks’’.

Implementation was carried out through Oracle. The completed system reflected the ‘world-view’ of the systems developers. It took nearly 15 months to complete the project. The physicalimplementation and the later use of the information system was not without problems.Undoubtedly, the new customer service information system had much broader a scope than theoriginal intent. Once the system went live, there were very few takers. Since the whole processbegan at the materials and procurement department, their buy-in was very critical to the successof the system, since it was radically changing material and procurement department’s ways ofworking. However, there was a limited use of the system in that department. This had a knock-oneffect on the system’s use in other departments. Unsatisfactory use of the system carried on fornearly 2 years, eventually it had to be abandoned.

4. Summary and discussion

This section presents a summary and discussion of the key emergent themes from the two casestudies. First, the drivers for managing benefits are presented. Second, various planning issuesrelated to kinds of benefits types are analyzed. Third, the importance of organizational context inthe success of IT-based solutions is discussed. Finally, a list of key lessons from the case studies ispresented.

4.1. Drivers

When considering key drivers necessary for a successful IS/IT investment, the following issuesemerge:

Incompleteness of driver analysis: In both the cases, an unbalanced and unquestioning view ofthe drivers was taken. Both in the case of hospital information system and ESL’s informationsystem, the system developers felt that a full and rigorous implementation of the respectivesystems would be the main driver and underscore the definition of success. In the case of thehospital, this system was nothing more than an administrators’ tool for establishing control andwould not in itself deliver benefits. These should have come from the implementation of animproved health care delivery process. ESL presented a similar situation. This meant that certainbroader contextual changes had to be put in place. Somehow, the information system and thechanges became synonymous—thus ‘hows’ and ‘whats’ mingled to the point where the benefit tothe whole organization became obscured by benefits to a lower level task set.

Ignored drivers: The drivers for successful IS/IT application operating in the professionalmedical stakeholder groups and ESL’s functional departments were largely ignored—the systemanalysts fell short of seeking or recognizing the stakeholder groups definition of success. In thecase of the hospital information system, a move towards community care was the key driverresulting in a ‘better health care system’ (a key benefit). However, the actual system ignored thisdriver and all system development efforts were aimed towards long-stay patients within thehospital. Similarly in the case of ESL’s system, the main problem was of maintaining a proper

ARTICLE IN PRESS


inventory of the right kind of spare parts within the maintenance department; this necessarily didnot mean that the whole value chain of the business had to be redefined.

In case of both the organizations, no attempt was made to get behind the number of drivers thatwere operating, such as, the move from specialists to generalists, the models of systematicmonitoring, single line of command integrated structure and communication between differentfunctional areas. Even if these are to be taken as ‘givens’ by the project team, they are capable ofbeing interpreted in more than one way.

Method drivers: Both in the case of the hospital information system and the customer serviceinformation system, the system developers placed too much faith in the structured methods. Theybelieved that the methodologies were robust and capable enough to deal with the kind of issuesaddressed in this paper. Clearly, a number of early steps were missed and the mechanics of themethod were applied too soon. Undoubtedly, it was important to understand the nature andscope of various business change issues and the total benefit, let alone the needs, expectations andbuy-in by various stakeholders. Consequently, the project started as a technology project beingdone in the dark and stayed there.

Value set drivers: The total driver set within the two case study organizations was a complexmixture of political, organizational and operational factors in which all parties had value sets thatoperated strongly, e.g., the government’s belief that the internal market strategy was very suitablefor the National Health Service situation in case of the hospital information system; the hospitaladministration’s beliefs in ‘running things like a business’ and the value of accountability asmeasured by certain parameters; in ESL the management system department’s belief that all partshad to be tracked to the final destination; and finally the project team’s view in both organizationsthat an input–output process model was a suitable description of the whole health care scene atthe hospital and the business operations at ESL.

4.2. Analysis and planning of benefit types

Analysis of the two case studies suggests that prior to any IT-based application development,there is a need to consider the total ‘benefits set’, their location within an organization and relatedchange management.

Whenever an organization considers an IT-based solution, it is important to consider the natureand scope of various kinds of benefits. This means that planners need to identify and choose aparticular benefits set. There could be some efficiency benefits that are realized through certaincontrol activities. There could also be certain effectiveness benefits, such as improved customercare proffered by health care packages and service specifications. An organization would be betterplaced to deal with the benefits management if it can identify and choose a particular set ofbenefits. Both in the case of the hospital information system and the customer service informationsystem, there was significant confusion as to the purpose of IS/IT investment. Investment payoffin such cases is minimal since no one understands the nature and scope of the benefits.

The second aspect that needs to be considered is benefits location. This means asking thequestion that are the benefits intended to occur because of tighter control and hence the efficiencyor are they going to be located at a managerial level emerging out of effective business processes?It is important to pinpoint benefit location since this sets the scene for benefits planning and change

management initiatives. Benefits planning and change management initiatives focus on choosing

ARTICLE IN PRESS


the right kind of benefits vis-a-vis the investment objective and in instituting the necessarybusiness changes. In both the case studies presented above, there was clearly a lack of emphasis onbenefits planning and change management since there was a dominant belief that the new processwould be so good and so different that there would be no difficulty in switching from the old waysof working to the new ones.

4.3. Organizational context

An understanding of organizational context in relation to successful IT-based solutions cannotbe understated. One of the main arguments of this paper has been that adequate technologicalbenefits can only be realized if commensurate changes are instituted in the business. Based onanalysis of the two case studies presented above, it becomes clear that little or no considerationwas given to the context within which the IT-based solution was implemented. This resulted inlaying little emphasis on the investment objective. Moreover, the systems (both at the hospitaland ESL) aspired to ‘over-formalize’ modes of working. In fact, in the case of the hospital,the information system acquired a Trojan horse attribute, i.e., it was thought that its introduc-tion would force the formal way of working onto a predominantly informal environment.Whilst it might have worked in a low-level task situation, it demonstrably did not induce thedesired changes higher up—which could only occur through careful change planning andmanagement.

Another important aspect of any IT-based solution is to consider the viewpoints of variousstakeholders. Clearly, in both case study situations, an insufficiently wide group of stakeholderswas consulted leading amongst other things to misunderstandings about the nature and scope ofbusiness processes and work practices. Inability to recognize various stakeholder viewpoints led tosignificant confusion. In the hospital information system case, lack of recognition (or avoidance ofit) of the hierarchical split—clinicians vs. managers—and the weakness of the informal linkagebetween them was not thought through properly, even though the new care planning system wasgoing to insist on new role definitions. In the case of ESL’s information system, exclusive focus oncost containment on part of the material and procurement department was not given significantattention while designing the new information system and hence the new business process.Clearly, the survival and profitability of ESL was dependent on procuring components at a verycompetitive price. In both cases, an organizational context factor was being addressed as a systemelement as though it were a process entity or some such, and again a solution to an issue in thewider environment was being sought at the formal system level.

4.4. Summary of key learning points

The analysis of the case study and an evaluation of the benefits management issue suggest anumber of key learning points. Although these are specific to the two case studies presentedabove, nevertheless, they suggest the growing importance of having a benefits focus in order torealize IS/IT investment payoffs. The key learning points can be enumerated as follows:

Success of an IS/IT implementation will be experienced and defined by the stakeholders withinthe wider (informal) environment of the system. It will be encountered or defined neither fromwithin the IT system itself nor from within the formal system which the IT system supports.

ARTICLE IN PRESS


The use of a systems methodology cannot define or generate success. The role of a methodologyshould instead be understood to be a means of ‘raising the safety net’ during systems developmentthrough the avoidance of known traps that have occurred in IS/IT projects.

In the interest of achieving success, before any systems method work commences, significantattention should be paid to three factors in the wider environment. These are:

�
the drivers which lead to the IT investment being contemplated in the first place, � the types of benefits being sought and where they will appear and � the organizational context—especially the roles and responsibilities of the stakeholders.
The results of considering the above should be factored into a benefits realization plan withinwhich the systems development plan is located.

As a step towards avoiding failure, it is wise to analyze and then manage the perceptions andexpectations of all stakeholders. Importantly, the impact on the stakeholders should be openlydiscussed and dealt with, as should their involvement in the changes that are needed to drive outthe potential benefits of IS/IT. This is especially true for those who will experience disbenefits ‘forthe greater good’.

Since nothing improves until people start doing things differently, all IS/IT implementationscan be regarded as change programs and the mechanisms and responsibilities for change becomeelements in the benefits plan. As part of the change management processes, some dependencylinkages need to be established between the high-level objectives set in the wider environmentthrough the formal system and on into the IT system as a means of:

�
linking IT investment to business objectives, � charting the changes at all levels necessary to get the benefits and � conversely, since things do change when people work differently, some assessment must be
made of unexpected and unwelcome outcomes.

5. Conclusion

This paper has examined the various contextual features that determine the success of atechnology-based system. It highlights that a narrow technology-focused orientation in systemsdevelopment is a limiting factor in realizing benefits. Real benefits reside not within the IT domainbut instead in the changes in the organizational activities that the IT system has enabled.Furthermore, these changes can be identified and planned for using an approach that analyzesbenefit drivers, benefit types and the organizational context, especially stakeholders’ expectationsand roles. It follows that for IS/IT success, the enabled benefits and associated changes should bethe focus of any IS/IT developmental activity.

The hospital information system and customer service information system case have provided auseful means to explicitly bring out the constraints in achieving benefits from IS/IT investmentsand has helped in conducting the argument. An analysis of the stakeholders in the hospital andESL shows that although all concerned were interested in improving the level of their services, themanner in which change was introduced was somewhat dubious. There were apparently a number

ARTICLE IN PRESS


of hidden agendas that were being pursued by different members of the organizations. With suchconflicting objectives, the success of any change initiative and the possibility of realizing anybenefits are remote. Although this paper presents an analysis based on just two case studies, thefindings form the basis for further work to enable generalization and wider applicability.

References

Benjamin, R. I., & Levinson, E. (1993). A framework for managing IT-enabled change. Sloan Management Review

(Summer), 23–33.

Blonkvist, C. L., & Goble, S. C. (1994). Re-engineering isn’t the only answer. Manufacturing Systems(February), 52–56.

Brynjolfsson, E., & Hitt, L. M. (1998). Beyond the productivity paradox. Communications of the ACM, 41(8), 49–55.

Burn, J., & Szeto, C. (1998). Effective management of information technology: Closing the strategic divide. In P.

Banerjee, et al. (Eds.), Business information technology management: Closing the international divide (pp. 522–536).

New Delhi: Har-Anand.

Canevet, S. (1996). The role of information systems evaluation across an extended system life cycle. Ph.D. thesis,

University of London, unpublished.

Computerworld (1988). Editorial-The perception. Computerworld December 5.

Connolly, J. (1988). Study: spending up; Stress on strategy. Computerworld November 28.

Dhillon, G. (1995). Complex managerial situations and the development of computer-based information systems. In: R.

Hackney (Ed.), BIT’95. Manchester Metropolitan University, UK.

Dhillon, G., & Backhouse, J. (1996). Risks in the use of information technology within organizations. International

Journal of Information Management, 16(1), 65–74.

Henderson, J. C., & Venkatraman, N. (1993). Strategic alignment: Leveraging information technology for transforming

organizations. IBM Systems Journal, 32(1), 4–16.

Johnson, J. (1995). Chaos: The dollar drain of IT project failures. Application Development Trends, 2(1), 44–47.

Johnston, K., Yetton, P. (1996). Integrating IT divisions in a bank merger: Fit, compatibility and models of change. In

Proceedings of the 4th European conference on Information Systems. 2–4 July, Lisbon, Portugal.

Keil, M., & Robey, D. (1999). Turning around troubled software projects: An exploratory study of the deescalation of

commitment to failing courses of action. Journal of Management Information Systems, 15(4), 63–87.

Keil, M., R Mixon, R., Saarinen, T., & Tuunainen, V. (1995). Understanding runaway information technology

projects: Results from an international program based on escalation theory. Journal of Management Information

Systems, 11(3), 67–87.

McGolpin, P. (1996). An examination of the inter-related factors and issues affecting the degree of success with strategic

information systems: Throughout the application lifecycle. Ph.D. thesis, Cranfield University School of Management,

UK, unpublished.

McGolpin, P., & Ward, J. M. (1997). Factors influencing the success of strategic information systems. In J. Mingers, &

F. Stowell (Eds.), Information systems: An emerging discipline. New York: McGraw-Hill.

McKersie, R. B., & Walton, R. E. (1991). Organizational change. In M. S. Scott Morton (Ed.), The corporation of the

1990’s (pp. 244–277). Oxford: Oxford University Press.

Miller, K., & Dunn, D. (1999). A framework for post-implementation evaluation aimed at promoting organizational

learning: A case of looking into the past to solve problems of the future. In M. Khosrowpour (Ed.), Managing

information technology resources in organizations in the next millennium (pp. 411–418). Hershey: Idea Group

Publishing.

Prager, P. P., & Ovenholt, M. H. (1994). How to create a changed organization. Information Systems Management

(Summer), 64–70.

Serafeimidis, V., & Smithson, S. (1996). The management of change for information systems evaluation practice:

Experiences from a case study. International Journal of Information Management, 16(3), 205–218.

Symons, V. (1991). A review of information systems evaluation: Content, context and process. European Journal of

Information Systems, 1(3), 205–212.

ARTICLE IN PRESS


Walsham, G. (1993). Interpreting information systems in organizations. Chichester: Wiley.

Walsham, G. (1995). Interpretive case studies in IS research: Nature and method. European Journal of Information

Systems, 4(2), 74–81.

Ward, J., Taylor, P., & Bond, P. (1996). Evaluation and realization of IS/IT benefits: An empirical study of current

practice. European Journal of Information Systems(4), 214–225.

Gurpreet Dhillon is a Professor of Information Systems in the School of Business, Virginia Commonwealth University,

Richmond, USA. He holds a Ph.D. from the London School of Economics and Political Science, UK. His research

interests include management of information security, ethical and legal implications of information technology. His

research has been published in several journals including Information Systems Research, Information & Management,

Communications of the ACM, Computers & Security, European Journal of Information Systems, Information Systems

Journal, and International Journal of Information Management among others.

Benefits Of Is It Implementations

Business

Transcript of Benefits Of Is It Implementations