Dynamic of Software Development

8/13/2019 Dynamic of Software Development

1/32

Accting., Mgmt. & Info. Tech. 10 (2000) 132

www.elsevier.com/locate/amit

The social dynamics of software development

Ari Heiskanen a,*, Michael Newman b, Jouni Simila c

a University of Helsinki, Administration Office, P.O. Box 33 (Yliopistonkatu 4), FIN-00014 University

of Oulunsala, Finland

b Vrije Universiteit, Amsterdam and the University of Manchester, UKc University of Oulu and CCC Software Professionals, Oulunsala, Finland

Abstract

A variety of experiences in software development processes between a public sector organis-ation and several software vendors over a decade-long period are described and interpreted.Three information systems histories are presented as case examples and their analysis is basedon detailed insider observations. A social process model is used to describe the relationshipsbetween key actors within the client organisation while a transaction cost framework is usedto explain the joint forms of the relationships between the client and the vendors. The resultingmodel depicts in a concise way how the relationships have evolved and stabilised over time.In this model, major encounters between the actors are those which have at least the potentialto change the relationship state between the parties. The relatively stable passages betweenconsecutive encounters are labelled episodes. By perceiving systems development as a seriesof encounters and episodes, it is possible to identify the critical turning points of developmentwork and to display the dynamics of a software development trajectory. While our findingssupport the well-known basic software procurement principle, this is only after the trajectorieshave stabilised. Two of the three trajectories exhibit major changes in software procurementstrategies before reaching a steady state. The paper ends with a discussion of the findings

and some implications for researchers and practitioners. 2000 Elsevier Science Ltd. Allrights reserved.

Keywords: Information systems development; Transaction cost economics; Co-operative patterns; Reflec-

tive practice; Longitudinal research

* Corresponding author. Tel.: +358-9-19123132; fax: +358-9-19122180.

E-mail address: [email protected] (A. Heiskanen).

0959-8022/00/$ - see front matter 2000 Elsevier Science Ltd. All rights reserved.

PII: S 0 9 5 9 - 8 0 2 2 ( 9 9 ) 0 0 0 1 3 - 2


2/32

2 A. Heiskanen et al. / Accting., Mgmt. & Info. Tech. 10 (2000) 132

1. Introduction

Our purpose in writing this article is to describe and explain the complex processes

of the software procurement histories of three major information systems (IS) at theUniversity of Helsinki, covering the period 19811991.

Whereas many textbooks are still locked into the assumption that in-housedevel-opment is the norm for procuring software, experience tells us that buying softwaresolutions or co-developing them with software houses are also viable and commonstrategies (Laudon & Laudon, 1996; Saarinen & Vepsalainen, 1994; Lacity &Hirschheim, 1993). But having raised all these options, management is faced withsome difficult choices. Given the type of system to be built or replaced, the basicquestion is which procurement approach does management adopt? Putting it simply,does management or their agents buy, make or co-develop the software solution?Closely related to this question is how the tensions and conflicts between the client-side actors shape the software procurement process.

These issues, in turn, become our main research questions which we attempt toanswer in two ways: the first answer is descriptions of three examples of thesoftware procurement process at the University. The first author is the chief IS officerat the administrative unit that makes such decisions and this dual role allows theresearch team unlimited access to the notes and records of these three procurementhistories over the chosen period. The second way is to analyse the evidence usingthe social process model of userdeveloper relationships suggested by Newman and

Robey (1992). We relate the NewmanRobey model of information systems develop-ment to the well-known software procurement model of Saarinen and Vepsalainen(1994). This prescriptive model is based on Transaction Cost Theory and it says thatsoftware for simple information systems should be bought from the market, whilemore complicated ones are better suited for in-house development or customisedcontracting with outside vendors. Saarinen and Vepsalainen used cross-sectional sur-vey data. In contrast to their approach, examining three cases over a period of 10years allows us a much broader and empirically grounded picture of software pro-curement than has hitherto been possible.

We will proceed as follows. In the next section we will describe the literature on

software procurement and how to model the process over an extended period. Weshow how Transaction Cost Theory has been used to model software procurement,but that it produces an essentially static view. The cases, in contrast, reveal thedynamic nature of software procurement. For example, in one of our cases, theprocess reverted to in-house development, instead of using the services of theformer outside contractor. We thought it therefore important to capture thisdynamic process by studying it over time, and for this purpose we employed asocial process model. We also look briefly at the context of procuring systems ina university environment.

Next we explicate our research method. We draw heavily upon the work of Donald

Schon as being most appropriate to a study conducted partly by practitioners. Schonsnotion of the reflective practitioner is shown to be highly relevant in such a study(Schon, 1983). We also take some care in situating the researchers in the stories


3/32

3A. Heiskanen et al. / Accting., Mgmt. & Info. Tech. 10 (2000) 132

presented and we briefly explore the privileged position of the researcher as aninsider and its drawbacks.

The three cases are described in some depth with particular emphasis being placed

on events judged to be important by the researchers (encounters in the languageof the process model) such as negotiations and decisions. We then interpret the casescarefully to map the unfolding trajectory1 of each software development history usingthe principles of the NewmanRobey social process model. In one case we alsodescribe and analyse the evolution of the relationship between the main user unit andthe Universitys administrative EDP unit. The trajectories of these three informationsystems are then compared with the predictions of the software procurement principleof Saarinen and Vepsalainen (1994). The article ends with a discussion of thesefindings, the limitations of the study, and draws some conclusions for researchers andparticularly for practitioners who may be considering a similar approach to analysingsoftware procurement.

2. Review of the literature

When developing an information system, organisations can apply one of threemajor approaches: in-house development (make), contractual customised develop-ment with outside vendors (a hybrid solution), or software product purchase (cf.Grudin, 1991; Saarinen & Vepsalainen, 1994). In this section we outline in general

terms how the two different organisations, the client and the vendor, are able toinfluence each other in development work. It is well known that outsourcing isdynamic (for example, Fitzgerald & Willcocks, 1994). Moreover, it is not possible tospecify every contingency in a closed contract over a long period of time (Richmond,Seidmann & Whinston, 1992; McFarlan & Nolan, 1995, p. 17). Negotiations andre-negotiations fill the void that emerges out of the incomplete contracting issue; itis also possible that the contract between the parties evolves to a relational one(Lacity & Hirschheim, 1993, pp. 3536). The influence mechanisms available to theparties form the basis for mutual control during contractual periods.

There are three kinds of bad costs involved in the software purchase process.

First, there is the cost or risk of getting the wrong or a poorly designed system.Second, there is the cost of paying too much for the right system. The third kind ismore indirect: the client must also generally avoid paying too little for the system(Page, Williams & Boyd, 1993; Fitzgerald & Willcocks, 1994). The client mustrealise that the vendor has also to make a profit for itself in order to continue serving

1 In our article, the word trajectory has a special meaning. Encounters are plotted on a time grid

reflecting the changes in procurement strategy. The subsequent shape of the connected encounters is what

we refer to as a procurement trajectory. A straight horizontal line would signify a highly stable procure-

ment strategy whereas a sharp, saw-toothed shape would show a highly dynamic, unstable procurement

policy. The trajectories show, therefore, the dynamics of the software procurement process but in a very

broad brush form. The detailed narrative and the theoretical explanation of the events provide the story

behind the pictures. This is discussed later in Section 4.


4/32


the client in future projects. The potential bad cost in this case will be realisedthrough the disillusionment of the vendor with the present project, materialising per-haps in personnel reassignments, delays in project schedules or even total project fail-

ures.

2.1. Work governance modes in IS development: a structural analysis

The relationship between a software vendor and its client can be understoodthrough several theoretical frames. Some of them are mentioned here in order toillustrate the variety of approaches. Gurbaxani and Whang (1991) discuss transactioncost theory and agency theory. McWilliams and Gray (1995) add environmentaluncertainty (an organisation theory construct) and resource based theory (a strategicmanagement construct). The contracting dilemma is analysed, for example, by Rich-mond et al. (1992), and also by Whang (1992). Bakos and Brynjolfsson (1993), usingthe economic theory of incomplete contracts, indicate that a buyer will often maxi-mise profits by limiting its options and reducing its own bargaining power. Asanuma(1989) describes the Japanese style of manufacturing where the client can exercisemanagerial control upon the vendors by using at least two vendors for each servicepurchased outside, the vendors being classified according to the desirability to con-tinue business with them. Powell (1990) argues that relational or network forms oforganising are often a viable way of economic exchange, instead of tight integrationor loose market. Kirsch (1997) analyses IS development process control and ident-

ifies different modes of control for different circumstances. Beath (1983, 1987) pro-posed a transaction governance approach based on organisational economics toexplore exchanges between information systems departments and user communities.

We have chosen Transaction Cost Theory as the basis for our analysis, becausewe felt that this theory was well known (cf. Lacity & Willcocks, 1995), conceptuallyparsimonious, informative, and easily applicable in our case. Transaction CostTheory is targeted to the analysis of make-or-buy decisions. The essential questionis whether the (client) organisation should make a product or service internally, usinga hierarchy to control actor co-ordination, or purchase the product or service outside,using the mechanisms of markets (Williamson, 1991; Lacity & Hirschheim, 1993).

The clients problem is to decide which governance mode is the most economicalone in a given situation. The decision to choose Transaction Cost Theory as thebasis does not exclude broader considerations, on the contrary. We describe the casecontext as much as the space permits in order to give a rich description of the web(cf. Kling, 1987) around our processes.

Transaction Cost Theory divides costs into two categories: production costs andtransaction costs. The latter consists of the costs of monitoring, controlling and man-aging transactions. To (over)simplify, Transaction Cost Theory says that if a purchaseis relatively simple, the market mechanism should dominate, because it is moreefficient in production. Therefore simple products or services should be bought,

not produced internally. The transaction costs in the buy option will be minimal.When the complexity of the purchased object grows, the internal production becomesmore viable, because the transaction costs of a complex purchase may become too


5/32


great. The reason for this price growth may, for example, be the opportunistic behav-iour of the vendor, or the specialised resources that have to be devoted to monitoring,controlling and managing the development process. There is also a hybrid form that

is a joint organisation of the client and the vendor (Williamson, 1991). These threemodes (market, hybrid, hierarchy) are the archetypal arrangements that can prevailbetween the developer (vendor) and the user (client).

Williamsons argument is that market and hierarchy are the polar extremes oforganising the work, and that the hybrid form is an intermediate arrangement. In theideal market, the identity of the client and vendor are irrelevant: the products arestandardised in such a way that the price of the product gives enough informationfor decisions. Prices follow the changes in supply and demand; this is the dominantway of adaptation, and no negotiation is needed. The contract is a straightforwarddeal and fundamental disputes are cleared through litigation. The incentive is theprice paid by the client. It is very consequential to the vendor, because if there isno contract, there will be no payment.

In a hierarchy, the co-ordination of actors follows the command line of the organis-ation. The disputes are solved internally (e.g. through administrative fiat). Adaptationpresupposes (intraorganisational) negotiations. Williamsons argument is that theincentives are usually much less powerful in the hierarchy than in the market. Theyconsist of means like using accounting information to reveal the profitability of pro-

jects or using career rewards and penalties.A fourth organisational archetype often mentioned in this context, the clan (Ouchi,

1979), seems inappropriate for the purposes of this article, because it is unreasonableto rely on the existence of a shared value and belief system between the contractingparties. We have also found that in practice the behaviour of the internal actors ofthe University can be described closely enough without using the notion of clan.The clan metaphor seems nevertheless quite relevant and approriate, e.g. in the caseof the group of companies forming the software house with which the third authorhas been affiliated. A shared value and belief system has definitely been established.There is also rivalry between clans within the established framework. At thepresent a sizable part of contracted software development work is in effect redistrib-uted between the software producing units forming the enterprise, extending geo-

graphically even outside the mother country. In the cases discussed in this paper,and for the time periods concerned, no part of the contracted software work washowever redistributed in this manner, so we will not utilise the clan concept inthis context.

2.2. The Software Procurement Principle

The Software Procurement Principle proposed by Saarinen and Vepsalainen (1994)employs Transaction Cost Theory to prescribe a software procurement strategyaccording to an assessment of the complexity of the proposed system as follows:

routine applications (common to many organisations, well-specified requirements,like accounting) can best be implemented by acquiring a software package, i.e.through a market transaction;


6/32


standard information systems (shared functionality with a group of organisationsbut with variation in detailed requirements, e.g. personnel systems) requiresoftware contracting, which, according to our argumentation, leads to a hybrid

form of development organisation; speculative systems (specific to one company or involving high uncertainty of

requirements, like a student record system) are best left to internal development,i.e. for a hierarchy.

Saarinen and Vepsalainen (1994) used survey data of 48 development projects inFinland. They, however, found only modest support for the Procurement Principle.In their Table 1, for speculative systems, they assessed that five were internallydeveloped and only one used a software package, largely as the principle predicted.But for routine systems the same kind of pattern was found, seemingly in contradic-tion to the principle. It is easy to speculate that the problem of the weak validationof the Procurement Principle was due to their research approach. It is difficult insurvey research to construct variables from questionnaire items which capture thecomplexity of the procurement process and impossible to understand the dynamicsof it with such a crude instrument (cf. Markus & Robey, 1988; Sabherwal & Robey,1995). It is also known that Transaction Cost Theory is a problematic predictor ofsourcing behaviour (Lacity & Willcocks, 1995). However, the Software ProcurementPrinciple, a derivative of Transaction Cost Theory, is intuitively appealing from apractitioners point of view, and therefore worthy of a closer examination.

2.3. A social process model of IS development

To overcome the weakness of the survey approach we use an approach from theprocess research tradition (Gersick, 1991; Newman & Robey, 1992; Robey & New-man, 1996). We analyse the processes from the inside, as seen by the participants.While there exist good treatments of IS contracting (e.g. Whang, 1992; Richmondet al., 1992; Fitzgerald & Willcocks, 1994) and IS procurement (like Saarinen &Vepsalainen, 1994), we believe that our case gives fruitful empirical insights byrevealing in a concise manner how the dynamic relationships between software

developers (internal EDP personnel and outside vendors) and users (clients) evolveover time. Furthermore, we believe that our way to model the dynamics of softwareprocurement can be easily transferred to other circumstances.

Our approach is a further development and enlargement of the Newman and Robeymodel (1992) of userdeveloper interaction. In their process model, applied also ina further case (Robey & Newman, 1996), they identified three main elements: (1)the antecedent conditions; (2) the possible interaction states between the users anddevelopers (acceptance, equivocation, rejection); and (3) the development trajectoryof the interaction process. The interaction process consisted of equilibrium stateprogress passages, called episodes, and critical events between the episodes, labelled

encounters. Encounters have the potential to change the nature of the interaction.This has parallels with Gersicks punctuated equilibrium model (Gersick, 1991).According to our model, information system development progresses through time


7/32


as a series of longer episodes, punctuated by brief encounters. An example of anencounter can be the hand-over of a test system to the users. This may change theexisting state of client/developer interaction from acceptance to equivocation or even

rejection when the clients begin to discover that the proposed system does not fulfiltheir needs. Of course, the very stability of episodes may trigger critical events(encounters). For example, if the vendor is inactive on a project for some time, theclient may try to force progress by looking elsewhere for a solution. At other times,encounters may arise from events apparently unrelated to the project such as a changein personnel. But each encounter will represent a period of relative instability in theproject during which the issues related to the project come under close scrutiny.

2.4. The organisational context

An often-used metaphor is that universities are like collections of fiefdoms wherebarons (and baronesses) are in charge of their own, independent realms, and vigor-ously defend their territories (Noble & Newman, 1993; Heiskanen, Newman & Saar-inen, 1998). Each participant is an individual willing and capable of independentbehaviour. It would seem that universities are fundamentally different from businessorganisations in their decision making processes. Consequently the standard IS devel-opment strategies developed for business may not be appropriate in institutions ofhigher education. To develop a more analytical view, we classify universities aspredominantly professional bureaucracies (Hardy, 1991; Mintzberg, 1983). Pro-

fessors are professional bureaucrats who have a very special kind of relationshipwith their university (Mintzberg, 1983, p. 207):

Professional bureaucracies are not integrated entities. They are collections of indi-viduals who come together to draw on common resources and support servicesbut otherwise want to be left alone.

The professional bureaucracy relies on specialisation, hierarchy, rules and regu-lations that are thought to ensure the predictability of the behaviour of the organis-ation and to lead to efficiency and effectiveness. In universities, the professional

bureaucracy has a parallel organisation for the routine administration (Mintzberg,1979, p. 361). The focus of our article is in the interactions of this routine adminis-tration organisation and commercial software vendors. Although the routine adminis-tration organisation should be a normal service organisation to the professionalbureaucracy, it is well known that there are problems in co-ordinating developmentefforts in all parts of universities (Noble & Newman, 1993). It seems that the looselycoupled nature of the academic community is mirrored in the behaviour of routineadministration (cf. Weick, 1976).

In order to better understand the information system development processes ofour case, we briefly characterise the different strategies that can be found in the

university context. Later we discuss how the different archetypal strategy modelsdescribed below materialised in our cases. Maassen and Potman (1990) point outthat coordination conflicts are easily born, decision making power is extremely dif-


8/32


fused, and that there are problems in the coordination between the professionals andthe support staff. They suggest that there are three different, but not necessarilyindependent, strategy models. The first one is the linear strategy model according

to which strategy consists of integrated decisions, actions, or plans oriented towardssetting and achieving organisational goals. Both goals and means are subject to stra-tegic decisions. The major assumptions supporting the linear model are that theorganisation is tightly coupled, the environment is quite predictable, the organisationhas goals, and the achieving of the (common) goals is important.

The second strategy model is adaptive. Here the strategy is mainly concerned withthe development of a match between the opportunities and risks in the environment.The main assumptions under this model are that the organisation and its environmentare open to each other, the environment contains identifiable stakeholders like con-sumers who have preferences, and the organisation must change with its environ-ment.

The third model isinterpretive strategywhich is based on the idea that the assump-tions made under the two previous cases are not valid, e.g. when a unifying commonorganisational goal is missing or the organisation is loosely coupled. The interpretivemodel is based on a social contract through orienting metaphors or frames of refer-ence that allow the organisation and its environment to be understood by its stake-holders. The interpretive strategy model is focused on the desired relationship withthe organisation and its environment. The actors deal with their environment throughsymbolic action, instead of the instrumental relationship emphasised by the linear

model.In short (Maassen & Potman, 1990, p. 400, quoting Chaffee, 1985, p. 147):

In linear strategy, leaders of the organisation plan how they will deal with com-petitors to achieve their organisations goals. In adaptive strategy, the organisationand its parts change, proactively or reactively, in order to be aligned with con-sumer preferences. In interpretative strategy, organisational representatives conveymeanings that are intended to motivate stakeholders in ways that favour the organ-isation.

3. Method

3.1. Situating the authors as practitioners and researchers

The main point of view of this paper is that of the first author in his role as theChief Information Systems Officer of the University. He finished the studies for thelicentiate degree in administrative data processing in 1980 when a temporary job as

a special analyst and the leader of the software development work for student recordswas offered to him, which he accepted. At that time there was a heated debate of howto renew the student records information system. Several committees had prepared


9/32


memoranda for the University Senate, suggesting actions that were necessary becauseof the syllabus reform performed in Finland in the late 1970s.

In a couple of years the first author realised that it would not be possible to make

a profound improvement in the student records system of the University (more detailsof this later in Section 4.1). In the summer of 1982 he took up the position as alecturer at the University of Joensuu, continuing also as a part-time worker in hisprevious position. The situation changed in the spring of 1984. The Rector and theDirector of Administration of the University of Helsinki suggested that he considerundertaking a more responsible position in the development of the Universitysadministrative information systems. The offer was accepted, leading to his appoint-ment as the Chief Information Systems Officer of the University and the establish-ment of the administrative EDP Office in the autumn of 1984.

The third author has also been involved in the development of the informationsystems of our case. He acted in the practical role of a Strategic Business Areamanager of one of the vendors concerned (CCC Software Professionals) during theyears 19851987. He continued in other managerial tasks with the same vendor until1998 when he was appointed to be a full professor in the University of Oulu. Hehas been active in software process assessment and improvement methodology devel-opment, and an evaluator for the European Commission in several software processand multimedia related programs.

The second author became a part of this process as the dissertation inspector andopponent of the first author in 1993. His special experience in longitudinal research

has close parallels with the first authors study of university systems over a periodof more than a decade. The second author has published several studies of systemdevelopment projects covering 515 years. Using this empirical evidence and carefulinterpretations, he has developed a social process model of IS design (Newman &Robey, 1992; Robey & Newman, 1996).

3.2. The reflective practitioner

Our aim is to put our experience from practice into a form that makes sense alsoto the broader audience (Heiskanen & Newman, 1997). For this purpose we use the

notion of Reflection-in-Action, adopted from Schon (1983) and Raelin (1997). Ourtask is related to what Nonaka and Takeuchi (1995) call unarticulated practice toexplicit knowledge.

Schon (1983, p. 163) frames the work of design as a reflective conversation withthe situation where the practitioner functions as an agent and experient.2 Throughtheir transactions with the situations, they shape it and make themselves a part ofit. Hence, the sense they make of the situation must include their own contributionsto it. Yet they recognise that the situation, contrary to the intentions, may foil theirprojects and reveal new meanings.

2 By experient, Schon appears to mean an experimentor who is at the same time also a target or

part of this experiment.


10/32


The structure of the process is described by Schon (1983, pp. 129132) as follows.Practitioners approach the practice problem as a unique case. They do not act asthough they had no relevant prior experiences. On the contrary, they attend to the

peculiarities of the situation at hand, seek to discover the particular features of theproblematic situation, and from this gradual discovery, frame the situation by defin-ing its boundaries and components, and design an intervention. The situation isuncertain, and there is a problem in finding the problem. As the practitioners frameand reframe the problem, they suggest a direction for shaping the situation. Thepractitioners then take the framed problem and conduct an experiment to discoverwhat consequences and implications can be made to follow from it. In order to seewhat can be made to follow from this framing the practitioners try to adapt thesituation to the frame. But the practitioners moves also produce unintended changeswhich give the situation new meanings. The situation talks back, and the prac-titioners reframe the situation once again. The process spirals through stages ofappreciation, action, and reappreciation. The situation comes to be understoodthrough the attempt to change it, and changed through the attempt to understand it.The practitioners will develop a practice oriented theory or rationale according towhich they explain the situation and choose their acts.

The word theory here has a special meaning, because according to Schon (1983,pp. 273274), practitioners do not consider that they have formed a satisfactoryaccount of phenomena in any practice situation until they have framed it in termsof their overarching theory, a rationale according to which they explain the situation

and choose their acts. So theory has two intertwined meanings; first in action designand then in after-the-fact explanations and interpretations. An overarching theorydoes not give a rule that can be applied to predict or control a particular event, butit supplies language from which to construct particular descriptions and themes fromwhich to develop particular interpretations. Sometimes the overarching theory canbe adopted from an existing research tradition, such as in our case with TransactionCost Theory.

Our way of doing this research, reflecting over the actions where the authors havebeen involved, has strengths and weaknesses, and these are fully discussed elsewhere(Heiskanen, 1994, 1995; Heiskanen & Newman, 1997). For example, the access to

the research site and many sources of data is easily established and the observationperiod can be long with minimal research resources, but there is also the danger ofpost-rationalisation and one-sidedness. This approach may become worthless, evenharmful as a research approach, if the practitioner/researcher does not consider thereflective process to be a possibility for personal growth but targets research resultsat any price. The danger of contaminated research also exists, because the practitionerhas such a control over the production of the research data that it is all too easy forhim to design the data to support nearly any argumentation. This is in addition tothe normal threats of interpretative research. Reliance on organisational documents,preferably produced by other authors than the practitioner/researcher himself, is an

asset here. Data generated by the practitioner/researcher are best to be triangulatedand confirmed with other sources. The Reflective Practitioner approach does notguarantee any universal advantage over more traditional research approaches. Normal


11/32


research skill requirements are the same for a practitioner as for a professionalresearcher.

A combined researcher/practitioner role is a subtle one. Great care should be exer-

cised when deciding which kind of data gathering methods are possible. In manyoccasions the first author has felt that it is unethical to interview his co-workers forresearch purposes only. These interviews could have imposed a flavour of the authortaking undue advantage of his dual role, aggrandising himself improperly, and intimi-dating the interviewees by giving a scientific backing to his practical acts. Thishas been especially true when the author in his practitioners role has experiencedstrained relations with the informants. In the same way, direct observations seem tobe possible only when they occur as a part of the practitioners role. Observing thebehaviour of the co-workers only in order to fulfil the data gathering needs of theresearcher have not been used. This all brings some irony to the data access issue:some phenomena are more visible to an outside observer than to us.

3.3. How to model the dynamics of the software development process

For the analysis of the development of the relationships between the key actorswithin the University we use the NewmanRobey social process model in its basicform. For the clientvendor issues, our idea is to modify the NewmanRobey modelby replacing the acceptanceequivocationrejection classification with another classi-fication that is better suited to the analysis of the relationship between the client and

the (commercial) vendors. This latter classification is the markethybridhierarchynotion, based on Transaction Cost Theory, just described in Section 2.1.

In our model, we present the case histories as development trajectories over timein the form of lines punctuated by encounters that may change the state of the processfrom one class to another. The passages between the encounters, the episodes, rep-resent development work that does not change significantly or rapidly the way inwhich the parties relate (cf. Newman & Robey, 1992; Robey & Newman, 1996). Theresearchers looked carefully at the documentary and direct evidence from personalexperience before judging what was a significant event (or an encounter, in the par-lance of the social process model). In the next section we present our three cases

as narratives that are later, in Section 4.5, condensed in the model form.

4. Three cases of information systems development

The Finnish State regulates state-funded information system services. Since the1970s there have been strict rules according to which the University as well as otherstate units have had to develop their systems. The State Computing Centre had aprivileged position, and in every major application software purchase by a state

bureau a tender from the State Computing Centre had to be obtained. Projects over50,000 marks (roughly equivalent to about 200 h) had also to be authorised by theMinistry of Finance. Authorisation from the Finnish State Treasury was needed for


12/32


the development of personnel systems. The regulations were replaced in 1988 by anew and more liberal statute from the Ministry of Finance.

In addition to the information technology services purchase regulations, there were

general rules which applied to all public purchases. These rules required that themain mode of purchasing should be through competitive bidding, with at least fourfirms as competitors. Direct purchases from a single vendor should be used onlyunder special circumstances.

We have chosen three procurement histories to be analysed. The purpose of thechoice is to illustrate how a large variety of development trajectories can easily becaptured in a graphical representation. In this way it is possible to grasp easily thelongitudinal shape of an information system history over an extended period of time.All three systems reached success in the sense that finally they were in real use,they did not pose any serious problems to management, and the users appeared tobe at least moderately satisfied with them, according to user information satisfac-tion surveys.

The first system history (the student records) is described in greater detail, basedon the dissertation work of the first author (Heiskanen, 1994). The other two(personnel and accounting) mainly serve as material that supplement the first caseby presenting such features that were not present in the first one. Furthermore, bypresenting the personnel system case, we are able to show how the developmentprocesses of the student records and the personnel system interfered.

There are five software vendors in the histories below. Three of them have agreed

to participate in our research and allowed us to use their real names: KT-Tietokeskus,the State Computing Centre, and CCC Software Professionals. The other vendorsare denoted by the pseudonyms Alpha and Beta. These latter two only had a rolein 1987 and 1988. Alpha had disappeared as a firm by 1995 when the current researchproject began. However, key information concerning its behaviour was secured fromother sources. Beta was a fill-up participant in a bidding competition to get fourvendors and obey the stipulations for public bidding at that time. Based on thesereasons we did not offer them an opportunity to participate.

The client side has been represented by the administrative EDP Office of theUniversity, headed by the first author throughout the study period. One of the major

features of the late 1980s was the tight financial situation of the EDP Office comparedwith the perceived needs of the information systems to be developed. Another issuethat affected the development schedules in the late 1980s was the replacement ofthe Burroughs mainframe of the University in the beginning of 1988. This precipi-tated the change in the software (student records, personnel; see below) running onthis computer.

4.1. The student information system of the University of Helsinki

Our story about student records begins in 1981. The first author had just been

hired as a special analyst from the Computing Science Department to the centraladministration of the University, his main duty being the renewal of the studentrecords system software. He perceived the situation as follows (Heiskanen, 1994).


13/32


The large increase in incoming data caused by the syllabus reform made it neces-sary to revise the software and file structures. More hardware capacity would beneeded. The organisational data flows could not be radically changed which meant

that data had to be sent from the departments on paper to be registered in the Actu-arys Office, a unit in the Universitys Central Administration dedicated to registermaintenance and statistics production about students and personnel. The software,to be used for 23 years, could be modified as a maintenance operation, using theservices of the Computing Centre of the University that had made the previoussoftware. A totally new system was planned for 1984, provisionally based on a minic-omputer.

A scheme to buy new hardware was also sketched. The new software was plannedto be developed in co-operation with the State Computing Centre and to run on theirhardware. The annual usage costs were expected to grow gradually, and when theusage expenses would have exceeded the costs of the hardware needed, it wasthought to be possible to change the usage expense to investment funding in orderto purchase hardware. After that the system was planned to run on the Universitysown equipment.

The rationale behind the purchase strategy was based on the limited universityfunds for buying equipment. There were, however, funds available for buying ser-vices. This purchase strategy appeared to be unrealistic when it was discussed inseveral meetings of the administrative EDP Directory Group and the idea graduallyfaded. It was formally decided in 1982 as a part of the administrative EDP plan of

the University to use the Universitys Burroughs mainframe for running the studentrecords for several more years.Consequently, to fit the new circumstances, the old software could only be modi-

fied. The system remained batch oriented with add-on files for on-line terminal dataentry and inquiries. Recourse to the maintenance of the old software was a disap-pointment to the first author and was one of the reasons for the move to the Joen-suu University.

The problems with the student records grew during the early 1980s, reaching astate of crisis in the mid-1980s, owing to poor data quality. The system was in avicious circle: many teachers felt that the system demanded unproductive, extra work

in sending study credit data to the Actuarys Office. Some credits were unsent, lead-ing to poor coverage. Poor coverage, in turn, made the system incomplete, and thisinadequacy felt by its indirect users led to carelessness, etc. The interpretation ofunclear examination lists by the personnel of the Actuarys Office demanded extrawork and caused delays in data entry, this being seen by the departments as theinability of the system to produce timely statistics. The attempts by the personnelof the Actuarys Office to persuade teachers to correct erroneous data led to frus-tration on both sides.

It was clear to the first author in 1984 during his appointment to Chief InformationSystems Officer that a complete renovation was necessary. An important pre-requisite

for this renovation was sufficient hardware resources and software tools, and this wassecured in 1986 when a VAX dedicated to administrative applications was purchased.

Now the strategy was to develop up-to-date software for a real-time on-line system


14/32


to take care of the basic student records functions and explore the possibilities ofdecentralising the user functions into the departments in order to get rid of the data-flows on paper and record the credit data at their source.

The formative years of the student record system were from 1986 to 1990. Severalorganisational actors played key roles during these years. As already discussed, the

Actuarys Office, headed by the Actuary, was responsible for the maintenance of thestudent record. The EDP Office was in charge of the software development for thestudent records from the early 1980s. It was also responsible for managing the devel-opment project, writing specifications for the software, and for educating, trainingand giving assistance to the departmental users.

The Rectorwas in charge of the University administration, but his role was minorin information systems after he had been active in hiring the first author. The Directorof Administration was the leader of the Administration Offices of the University,and the manager of the first author. Four persons acted in this capacity in 19861990. The first of them retired in 1986. After that, the Head of the General Section,subordinate to the Director of Administration, was a deputy Director of Adminis-tration for several months. The third Director of Administration, nominated from thebeginning of 1987, was replaced by the fourth one in the spring of 1987. These twopersons were competing applicants for the job. The change happened after a SupremeAdministrative Court decision that was made from the appeal by the fourth Directorof Administration, based on jurisdiction about the formal qualifications for the job.All these changes were seen by the first author as creating a difficult working

environment, especially should a crisis occur.Some of the work-force were recruited from an outside software house, CCCSoftware Professionals. The Ministry of Finance regulated the software purchases.The State Computing Centre had a privileged position as the prime vendor for theState organisations, and its statement was needed for application software procure-ment.

The key participants in decentralisation within the University were the staffandthe technical resources of the departments. The decision maker was the departmenthead. The persons responsible for the planning tasks of the departments (department

planners) were educated in their branches of science. They were mostly teaching

staff, sometimes with higher degrees. The clerical personnel of the department wasthe key group affecting the failure or success of the decentralisation of the systemfunctions.

But this assembly was not a harmonious one. Several goal differences betweenthe University actors prevailed, as the first author came to learn (Heiskanen, 1994).First, the Actuarys Office considered itself as the sole maintainer of the centralisedstudent record and resisted direct departmental updating. The Actuarys Office putit in a memo in December 1987:

According to the point of view of the Actuarys Office the direct updating of the

files of the centralised Student Records cannot be the business of departments andfaculties. Currently the whole Register is the responsibility of the ActuarysOffice. If technical maintenance of the centralised Register is transferred to facul-


15/32


ties, then the Actuarys Office cannot have complete responsibility. Instead, thedepartments and faculties can make transaction files with their own systems, withwhich the Register that contains the data of the whole University can be updated

by the keeper of the centralised Register.

A second goal difference was also about decentralisation. Some teachers saw thatdecentralisation would cause extra work in departments. This view is clearlyexpressed in the following quotation from a letter to the University Periodical by anassociate professor:

According to the credit recording system every study achievement should beincluded in the centralised register. So the smallest sneeze that produces lousycredits should be coded, be written into the file, and be obtainable from there,and why? ... As detailed centralised registration does not improve the basic func-tions of the University, i.e. teaching and research, in any way, it should be aban-doned at once. In the planned form it will unnecessarily increase the work-loadof every teacher, ruin old well-functioning systems (the particular department hada card-file by student basis, maintained by the department secretary) and take thewhole working capacity of tens of clerks. Extra jobs demanded by the systemcould be given to the departments directly ... Plan something that would advanceour functions and not make them more difficult. Or twiddle your thumbs.

Some other teachers expressed in quite sarcastic tone that they should not bebothered with the technical processing of student data. One of the planners of thedepartments put it as follows when he was asked to tell his personal goals in thedecentralisation project:

I have no personal goals, I do not get benefits from the project, because my ownstudy credits are already recorded. I expect, however, that the duties of the projectshould not be very laborious.

A third goal difference arose over how to ensure that teachers take care to provide

information for their part of the credit recording. This was expressed by a departmentclerk as follows:

... when the teachers split the courses that are already composed of many partsby letting students pass the course book by book, it is impossible for the depart-ment office to keep track of everything and watch that the lists given (to theteachers) are returned. ... The department head has tried, but more should bestressed that it is a question of legal protection for the students. The registrationof study credits should not be labelled as bureaucracy. I do not wish to be a cop.I really do not know how we can get them (teachers) to understand.

After the above description of the organisational context, we return to the develop-ment process to see how the events unfolded. The first author, as the newly appointed


16/32


Chief Information Systems Officer, soon realised that the Universitys own EDPresources could not alone develop the software. An outside vendor was needed. Thechoice was based on an informal scanning in 1985. CCC was chosen because of its

personnels good record of achievements and their strong academic background. Theplanned purchase of software was negotiated with State Officials and the Universityobtained permission to use CCCs services, instead of those offered by the StateComputing Centre. The delivery of the application software for the VAX and theadoption of the renewed enrolment subsystem in the Actuarys Office succeeded inthe summer of 1987, and the credit record subsystem in the beginning of 1988.

The decentralisation process of the functions of the student records started in thespring of 1986 in the form of an experimental project for departmental data pro-cessing. This project began in the Technical Section of the Offices of the Rector,but soon the responsibility was taken over by the EDP Office. The experimentalproject, although it suffered from some staff resignations, produced (during the springof 1987) the specifications of a PC-based system for student data processingdecentralised in departments.

The situation became problematic for the EDP Office in the summer and earlyautumn of 1987 because the Actuarys Office considered it too risky for the creditrecords to be directly used by the personnel of departments and the experimentalproject engaged in developing the PC software was suspended temporarily becauseof staff resignations.

There were two principal options for the EDP Office. One was to cancel the devel-

opment of the PC software and direct the resources of the project to change the viewof the Actuarys Office by establishing sufficient controls for security. The other wasto continue developing the PC software for the departmental student data processing.This latter option would have been the only basis of the decentralised data processing,if the Actuarys Office could prevent the direct departmental use of the VAXsoftware for credit data processing.

The further development of the PC version seemed to be the better option, mainlybecause of the apparent positive attitudes towards PCs. The anticipated capacityproblems with the VAX running the centralised student records also favoured theinclusion of the PC option, as did the lack of connections to the University data

transmission network in many departments. It also seemed that the user interface fora PC would be more convenient than that for the VAX. For example, it was easyto incorporate textual information for an individual student in the PC version. Anobvious reason was also the fact that this option only needed the approval of theEDP Office, and not the approval of other actors. Consequently, during the earlyautumn of 1987 the EDP Office began to make it a real alternative for the depart-ment level.

The commitment of the EDP Office to the development of the PC software hadseveral stages that probed the back-talk of the internal and external actors towardsthe steps taken by the Office. The specifications had been written in the spring of

1987 and a bidding competition was started in the summer of that year. The maincompetitors were software houses Alpha, CCC, and the State Computing Centre. Thefirst tenders of all these bidders had approximately the same price, but the planned


17/32


functionality of the system proposed by the State Computing Centre was inferiorwhen compared with the others. So the competition was between Alpha and CCC.During negotiations the prices of the two tenders became nearly equal. During the

negotiations it was also agreed that the first part of the software would be deliveredwith limited functionalitya prototypethat later could be developed into a fullsystem. The contract was eventually won by CCC.

The Actuarys Office reconsidered its view about the suitability and security ofthe centralised student records to be used directly by the departments and gave per-mission for departments to directly use the centralised students records in May of1988. This reconsideration was developed gradually in 1987 and early 1988 duringthe work of two consecutive committees. The task of the first one was to define theconcepts of student data processing, how to register study credits, and suggest howthe amount of credits produced by each faculty could be obtained. The second com-mittee (the register committee), established by the Senate in early September 1987,was charged with the task of planning how to decentralise the credit record dataprocessing. The first author was not a member of the first committee, but was enrolledon the second one. The arguments favouring the decentralised use of the studentrecord system, including decentralised credit data entry, prevailed over the Actuarysoriginal view, although this entailed several heated discussions. The matter wassettled in March of 1988 when the Senate approved a project to explore the possi-bilities for decentralisation as a means of solving the data problems.

In a way, the first author was fighting on two fronts in the autumn of 1987. First,

within the University there were many and strongly differing views of the viabilityof the development work and decentralised student record data processing. Second, ashortage of money necessitated tight bargaining in bidding competitions for softwarepurchases. By first developing the prototype in the autumn of 1987, the EDP Officekept open the possibility of stopping the development work without too many costsbeing incurred should the University community react negatively. But at the sametime, it kept open the possibility to continue. The decision of the Senate to launchthe decentralisation project in March 1988 ensured the continuation of the work.

In 1987 the EDP Office did not have enough money to consider the simultaneousdevelopment of the student record system and the personnel system (see the follow-

ing subsection). So a low price was very important. The first author had a strongbelief that funding could be secured during 1988, but that demanded positive andconcrete signs of progress. On CCCs side, lowering the price of the first part ofthe PC software delivery was possible, because the software house could give thework to an analyst who just at that time did not have any other assignments. So theUniversitys need for a low price for the first stage of the work and the vendorsneed to find a task for the analyst complemented each other, and a favourable agree-ment over the price could quite rapidly be achieved between the first author and thevendor director.

CCC was a preferable vendor compared with Alpha because of its familiarity with

the University and its experience with the VAX version of the student recordssoftware. Whether the price level of the bids of either vendor for the whole softwareor the first part of it was realistic is difficult to decide, because it was anticipated


18/32


that the specification contained only a part of the true user requirements. Thebilling of the further work could compensate for the losses caused by the possiblelow price level of the early work.

The development co-operation between the University and CCC evolved over theyears, typically from fixed-price deliveries of pieces of software into contract pro-grammer hiring. It appeared that changing the maintenance and further developmentof software from the vendor to the EDP Office would be the most economic option,because the personnel of the EDP Office, acting as gatekeepers (Heiskanen & Simila,1992) between users and outside developers, considered it easier to develop thesoftware by themselves. Therefore the University decided in 1990 to develop andmaintain the software without outside assistance. This was possible, because theamount of work was small enough for one or two analysts to master.

The decentralisation project ended in March of 1989. The first departments hadadopted a decentralised student records system during the project. For the rest ofthe departments, decentralised data entry was optional. Each department could eitheradopt an EDP variant (VAX or PC-version), or continue its previous method ofsending data on paper to the Actuarys Office. The departments were made respon-sible for the purchase of the equipment needed, and they had to arrange clericalpersonnel and organise their internal data processing. The Central Administrationwould provide education, support, and the installation of the software. The resourceallocation process of the University was to be more reliant on the data in the creditrecords. The students would obtain a register excerpt annually, in order to secure

that all credits would eventually be recorded. This strategy appeared successful. Ina few years, virtually all departments had adopted the decentralised processing ofstudent record data.

4.2. The personnel and job system

The history of the personnel system development described here began with com-petitive bidding in November 1986. The EDP Office was in charge when the specifi-cations were prepared prior to the bidding competition, and it represented the usersin the bidding competition with the software houses Alpha, Beta, CCC and the State

Computing Centre. The contract was won by Alpha, because it eventually promisedto deliver the specified software free of charge. This vendor wanted to expand intothe public administration sector and to get a reference project of a particular toolenvironment. It effectively forced the other bidders out of the game by its pricing policy.

The contractual price level is indeed a very powerful control mechanism,especially in public bidding. The vendor can in effect force the clients hand bylowering the price to a level where other bidders are not willing to enter. However,the use of the price level control mechanism in the described manner carries largepenalties for both parties if the expected business opportunities fail to materialise.This is what happened in this case leading to the vendors disillusionment with the

project, reassignment of project personnel, and finally to project failure from its pointof view.

Although Alpha had delivered the core part of the software successfully in 1987


19/32


and its use began as planned in the beginning of 1988, Alpha was not able to delivera reporting package later that year. Consequently, the EDP Office gradually came toa decision to stop the co-operation with Alpha and continue the development with

another software house, CCC. The University had used CCCs services in developingthe student record systems with acceptable performance. This was the main reasonbehind the choice, and so to avoid the work that would have been incurred in thesearch of a totally new software house. The change-over entailed several steps thatrevolved around two issues. First, the price level of Alpha was very economical tothe University. Therefore the client did not want to prematurely stop the co-operation.However, the University realised that it could not force the vendor into the deliveryof a useful reporting package or other pieces of new software. Second, the Universityprobed the capability of CCCs personnel in small deliveries like a training versionof the personnel system in the summer of 1988, before full commitment. By the endof 1988 CCC appeared to be a viable choice. In March of 1989 the University formallyclosed the co-operation with Alpha. The development and maintenance of the person-nel system continued with CCC until 1997 when it was replaced with a new system.

The low price of the first software delivery was essential for the University,because it needed the approval or positive statements for its actions from the Ministryof Finance, the State Treasury, and the State Computing Centre. The State ComputingCentre and the State Treasury had together developed systems for personnel adminis-tration, but the adoption of these would have required changes in the ways the Uni-versity operated in personnel administration. Moreover, the University had chosen

a specific database management system for student records, and wanted the personnelsystem to be based on this database also. It was clear that the state-privileged vendor,the State Computing Centre, would not base any of its work on this database. So alsoin this occasion the short term interests of the vendor (Alpha) and the client matched.

4.3. Accounting

The purchase of the accounting package in 1991 represents an extremely straight-forward case: it was a direct purchase, without a bidding competition, from a singlevendor, Tietovoima, which had earlier been chosen by the State after a bidding com-petition to develop an accounting package for all state bureaux. In the beginning of

1992, KT-Tietokeskus purchased the accounting systems business from the ownerof Tietovoima. This purchase meant moving the accounting system development andsupport personnel from the old host to the new one. The contract made between theUniversity and the prior vendor remained valid without renegotiations. At the timeof purchase, the choice of software vendor of accounting packages for the statebureaux was extremely simple, because there was only one state-approved option.Later the State abandoned its guiding role and relaxed the statutes allowing othervendors to bid also.

4.4. Features of contracting

Some general comments can be made based on our experiences of software con-tracting, especially concerning how the parties are able to control each other, i.e.


20/32


how one party can affect the behaviour of the other party. In this respect, we shouldremember that these contracting parties are quite often in an adversarial relationship.Several control mechanisms have been described in IS outsourcing literature (see,

for example, Lacity & Hirschheim, 1993), but those below have been the most vitalones in our experience.

The dominant control mechanism is the mutually acceptable price level in thebidding process. The vendor must strive towards reasonable compensation in orderto survive economically. The obvious motive of the client is not to pay too much.The compensation level may, however, be viewed in a short-term or long-term per-spective. For example, in developing the PC version of the student records softwareand the first part of the personnel software, the University had to act on a short-term perspective and choose the lowest price option.

The price level control mechanism can also be used in a reverse sense by thevendor in order to break involvement with a client at least temporarily. A furthernegative effect of the use of the price level control mechanism, at least in an exagger-ated manner, is its effect on future bidding. The vendor may profile itself as tooexpensive to be included in future bidding or too cheap to bid profitably.

The second control mechanism emphasises thelong-term relationshipbetween thesoftware house and the client. This is because there is a trade-off between the empha-sis on competition leading to reduced price of the work and a need for creating long-standing and mutually beneficial relationships between users and developers. Anaspiration towards a long-range relationship with the client may at times conflict

with the price level control mechanism in the short-term. The vendors aspirationtowards a long-term relationship with the client is, in general, preferable from boththe vendors and the clients viewpoints. This aspiration may be realised in waysother than by contractual price level control. For example, a vendor may, byassigning highly qualified persons in the early projects, make in effect a lastingimpression and a strategic investment for getting future projects from the client.

The third control mechanism may come out of the certified quality managementand assurance system. For example, the ISO 9000 certificate is conditional and it isawarded for a limited period. If the client finds the vendors performance unaccept-able, a powerful means for improvement is a complaint to the standardisation organis-

ation that awards (and withdraws) the certificates.The development of a certified quality assurance scheme such as ISO 9000 canbe used as a powerful marketing device in negotiations with the client. To this end,the vendor will attempt to develop measures for improving its software productionmaturity (Simila, Kuvaja & Krzanik, 1995). In the long term, this is a remarkableinfluence mechanism that has a lasting effect from the vendors point of view.

4.5. The models of development trajectories

The long and eventful histories of our cases can be condensed using the method

described in Section 3. We have tabulated, as the first part of our model, the develop-ment encounters in Tables 1 and 2 for the student records, in Table 3 for the personnelsystem, and in Table 4 for the accounting system. The second part of our model


21/32


Table 1

The internal encounters of the student records development

Enc. No Date Encounter description

1 1/1981 The first author is hired as a special analyst to the Administration

Offices of the University of Helsinki

2 2/1982 The first author moves to the University of Joensuu, remaining also

as a part-time worker in his previous position

3 8/1984 The first author is re-hired by the University of Helsinki, now as

the Chief Information Systems Officer

4 Spring 1987 An encounter that lead to bifurcation: on the one hand the

Actuarys Office takes, finally, an active role in the development of

the VAX version, but, on the other hand, forcefully resists the

decentralisation of student records data entry

5 3/1987 The Actuarys Office takes an active role in software development6 12/1987 The Actuarys Office writes a memorandum expressing its resisting

view of the decentralisation

7 5/1988 The Actuarys Office finally approves the decentralised data entry

to the student records

Table 2

The external encounters of the student records development


1 1985/9 Preliminary specifications for the student records system prepared

2 1985/9 Informal contract between the University and CCC for refining the

specifications

3 1985/11 Contract between the University and CCC concerning the core part

of VAX-software

4 1986/6 An experimental project for developing departmental data

processing begins. The idea of the PC version emerges within this

project

5 1987/6 The specifications of the PC version completed within the

University. Request for proposals of development mailed to

vendors

6 1987/10 CCC chosen to be the vendor of the PC software7 1990/5 The University takes over the development (perfective

maintenance) of both pieces of student records software

presents the shapes or trajectories of the process by connecting the encounterswith the episodes. They are in Figs. 14, including also the respective encounternumbers. With these two sources, we believe that the reader is able to easily under-stand the dynamics of the processes. The figures also contain brief descriptions of theantecedent conditions of the development trajectories as well as explanation boxes for

especially interesting encounters and episodes.In order to save space, episodes were not included in this tabulation. Each of

the encounters was consecutively numbered, dated (year/month), and described. The


22/32


Table 3

The encounters of personnel systems development


1 1986/11 Specifications for the personnel system prepared within the

University and a request for proposals is mailed to vendors

2 1987/26 Alpha wins the contract, development begins but the final contract

must be approved by the State officials. Finally the contract is

signed between the University and Alpha

3 1988/6 The University begins to change the software vendor to CCC

because Alpha is not able to deliver the reporting package

Table 4

The encounters of the purchase of the accounting package


1 1991/68 The University asks for a tender from Tietovoima about the

delivery of the accounting package which has just been approved

by the State Officials. The tender is accepted immediately. The

contract of delivery is signed and the adoption project begins,

leading to the use of the software in February 1992

Fig. 1. The development trajectory of the student records system within the University.


23/32


Fig. 2. The development trajectory of the clientvendor relationships of the student records system.

Fig. 3. The development trajectory of the personnel systems.


24/32


Fig. 4. The development trajectory of the accounting system.

encounters as well as the ensuing episodes were identified and classified by the firstauthor. This work was based on his analysis of the archived data. The data werefamiliar to him, because he had participated in all the clients decisions concerningthe relationships with the vendors, as well as negotiations with the internal actors.The identity of the encounters and episodes was confirmed by the third author onCCCs part. The managers of the other vendors did not make any objections whenthe manuscripts describing the episode/encounters were sent to them for review. The

episodes and encounters have been discussed in several occasions with internal actorsof the University and no objections have been presented to our classifications andinterpretations.

The encounter/episode classification rules were quite simple, but required carefulconsiderations. If the software developers were employed by the University, it wasclassified as a hierarchy. The category market was chosen in the following cases.First, when the Universitys EDP personnel did not have an intention to be active insoftware development. Second, especially for encounters, when there was a biddingcompetition or contract negotiation, or a possibility for the University to easilychange the vendor. An example of market was the making of a contract to purchase

the licence to use a software package. A hybrid form was between the market andthe hierarchy where the input of the client or user organisation, or the expertise ofthe vendor, was essential to software development.


25/32


5. Discussion

For the authors who are also practitioners, the motive in writing this article was

to gain more understanding of what has been the essence of their experience, to getmore professionalism in vendor/client control, and to increase self-understanding. AsBoland (1991) says of these kinds of self-reflective studies, intellectual curiositytoward ones own professional practice can produce insights that help to improvethe quality of management information systems both in particular and general cases.

This development and decentralisation process of the student records was also thetopic of his dissertation (Heiskanen, 1994). As a researcher over the years, he learnedto perceive the implementation process quite differently from the initial framing.The research began in 1986 with a straightforward factor approach, planning toinclude variables describing the departments, the personnel, technical alternatives asseen by the departments, and the like. The original set of research questions in 1986did not contain the most important final research question which was about the realityof action design, i.e. how action strategies get their birth. The introduction of thisquestion meant a radical departure from the positivistic, backwards looking stanceexpressed in the earlier research plans toward action research, action design, andfuture orientation of the final research plan. This change occurred when the firstauthor reflected on the meaning of the decentralisation strategy that he had planned(cf. Schon, 1983).

Developing several information systems concurrently with few resources for a

dispersed user community can be very stressful. This has been felt by the first authoron many occasions, especially with the student records in 1987 and 1988. Anadditional source of stress was that the development process of this system was hisdissertation topic. However, the basic literature survey for research work can helpin dealing with the anxieties of practice. For the first author this happened when hetried to learn to take a stoic apathy stance, or, in other words, exercise the art ofindifference, as suggested by Hodgkinson (1983). Here indifference is to be under-stood in a special sense. It does not mean that one does not care, but a leader hasto be concerned about human and organisational outcomes in which he has full orpartial responsibility. What should be a matter of indifference is his own success or

failure. Hodgkinson claims that the leaders ego has to cease to count and it has tobe eliminated from the set of relevant variables. This is idealistic, and one canaccomplish it only by approximation, by constant effort and constant failure.

In practical terms, the exercise of the art of indifference has been different in thethree cases. In the case of the student records, the acts of the first author conformto the interpretive strategy (Maassen & Potman, 1990). He felt unsure of whetherthe support of decentralisation would be great enough to over-come the clearly feltresistance originating from the Actuarys Office. What was certain for him consistedof the power over the acts of his own unit. It is possible to speculate at hindsightthat the amount of stress is proportional to the uncertainty of the process and what

the stakeholders have to lose or win.In the case of the personnel system, his strategy is best described as adaptive

(Maassen & Potman, 1990). The personnel system was not a vital one for the Univer-


26/32


sity when the development process began. The system was adapted first to the hard-ware change, and later it was adapted to the work-flows of personnel data processing.The accounting system purchase is an example of linear strategy, a straightforward

adoption task to be performed. These two cases represent a quite normal developmentand implementation of a project without high level of stakes, and consequently didnot cause any special stress, and the exercise of indifference was not difficult.

The process maps are helpful in depicting the software procurement dynamics overseveral years. By taking a longitudinal position we can begin to see the emergence ofpatterns in the trajectories and the significance of alliances with specific softwarehouses. What is revealed is a picture of organisational learning (two-way) as partiesadjust and negotiate over time. The maps indicate the importance of establishing andfulfilling successful contracts at an early stage.

Additionally, the theoretical lens of Williamson (1991) acts as a powerful explana-tory vehicle in the analysis of the clientvendor relationship. It seems that Trans-action Cost Theory gives us intellectual machinery to explain our experience in rela-tively simple terms. For example, in the initial purchase of the student record system,the goal of efficiency and lack of internal resources seemed to dominate. Thereforesolutions were sought from the market. Later, during the use and maintenance phases,the costs of using an outside vendor became too great, because the gatekeepershad to devote much of their time to acting as intermediaries between the end usersand the (outside) developers. In this case, the development reverted to in-house(Fig. 2).

We can also give a broad explanation to the shapes of the development processesaccording to the maturity of the application area. Accounting is a very mature field,and therefore the contracts are also of a market type (Fig. 4). The data processingneeds in student administration seem to be rather immature and constantly evolving.Therefore the systems in this area need constant tailoring as the users learn newways to do their business. In our case, this tailoring meant internal development.Personnel systems seem to be somewhere between the extremes of mature and imma-ture.

By using longitudinal data in our study, we observed how the procurement stra-tegies developed over time until they reached relatively stable conditions. It is these

stable conditions which our study revealed which give more support to the Procure-ment Principle. These conditions would be difficult to capture using snap-shot typesurvey data (cf. Saarinen & Vepsalainen, 1994). Although our three example systemsfollowed the Procurement Principle, thus increasing its credibility, further empiricalresearch is needed before it is possible to say how much the intuitively appealingProcurement Principle predicts or explains actual behaviour, and under which cir-cumstances it does so. Each of our three cases represent selective sourcing. It seemsthat in these kinds of cases the predictive power of Transaction Cost Theory and itsderivatives like the Software Procurement Principle is greater than in total sourcingdecisions (cf. Lacity & Willcocks, 1995).

It is well known that several different interpretations can be drawn from the sameevidence. Lacity and Hirschheim (1993) used two viewpoints with which to analyseinformation systems outsourcing: economic (Transaction Cost Theory) and political.


27/32


They found that different views complement each other. We follow suit. The New-man and Robey (1992) classification acceptanceequivocationrejection has over-tones of political behaviour, and we supplement this view with the markethybrid

hierarchy classification. It is possible that in some situations political considerationswill dominate, imposing additional costs in the form of, say, conflicts betweenstakeholders. In these kinds of analyses, Orlikowski and Hofmans (1997) notion ofimprovising could be a good characterisation (see also Ciborra, 1997).

Indeed, improvising has been prominent in our situations when a clear-cut strategywas difficult to find for reasons like lack of resources, different development projectsinterfering with each other, or because of conflicts between University actors. Allthese issues made the situations difficult to master in a co-ordinated manner. Bylooking at the picture one gets in combining the development trajectories of thestudent records and the personnel system in 1987, it is easy to see a cluster ofsimultaneous encounters that shape the progress. In recollection, 1987 began inequivocation about how to develop the student records. A set of three encountersemerged: encounter 4 in Fig. 1 meant a bifurcation, because the Actuarys Office,on the one hand, approved the development of the centralised system (encounter 5)and participated actively in this work. On the other hand, its equivocation towardsthe decentralisation turned into outright rejection and forceful resistance (encounter6). The resistance was eventually abandoned, because the register committee sug-gested decentralisation, which was approved by the University Senate. Lack ofmoney also necessitated improvisational acts in the autumn of 1987. The free-of-

charge delivery of the first part of the personnel systems was one example and theincremental development of the microcomputer version of the student records wasanother.

In addition to improvising, our experience can be related (see Table 5) to twoother theoretical contexts: development strategies in a university context (Maassen &Potman, 1990) and metaphorical thinking in organisational analysis (Morgan, 1986).The strategy issues have already been dealt with, but metaphorical thinking requiressome comments.

Three different organisational metaphors from Morgan (1986) can be interpretedto have been present in our cases. The accounting system purchase conforms to a

simplistic, mechanistic view: the organisation is like a machine in this straightfor-ward task. The personnel system is a little bit more complicated. We can frame itsdevelopment best as an adaptive process where the view of the organisation is thatof an organism. In the first authors interpretations of the organisational view, thestudent records development is the most complicated: we can use the brain metaphor,or the holographic view of the organisation, which is the other name for this approach(Heiskanen, 1993).

A key word in seeing the organisation as a brain is self-organisation. Accordingto this notion, the functions of the brain do not have a certain and distinct locus butthey are distributed all over the brain (Morgan, 1986, p. 77). Therefore a considerable

amount of brain tissue can be removed from rats training through a maze withouttotally paralysing them. Performance deteriorates proportionally to the amount ofbrain tissue removed. Other areas take over the duties of the removed tissue. Simi-


28/32


Table 5

Summary of the case information systems

Student records Personnel Accounting

Type of system Major system, tailored Originally marginal Major system, packaged

software development system, growing to a software purchase

major one, tailored

software development

Organisational Severe conflicts between Poor data quality because Poor service level

situation in the key actors, anarchical the system is not

phases of the procedures, poor data integrated to any work

development quality process, lack of

process organisational host

because the University didnot have a personnel

department

Motivation for the Out of the anarchy Software renewal because Adoption of an on-line

development through decentralisation of hardware change, system

process as seen by integration of the system

the first author to personnel work process

Development Interpretive, incremental Adaptive, phased Linear, straightforward

strategy decentralisation process, development, first basic adoption process

improvisation in the system replaced, then according to the vendors

formative phase integrated to work-flow delivery scheme

Dominant image of Holographic Organism Machine bureaucracy

the organisation

held by the first

author

Relationships From acceptance to From acceptance to Acceptance throughout the

changes between equivocation and rejection equivocation and back to whole process

internal developers (major conflict), and then acceptance

and users back to acceptance

Relationships From hierarchy via market From hierarchy via market Marketchanges between and hybrid back to to hybrid

the client and the hierarchy

vendor(s)

Amount of state Modest Tight, pronouncements of Total control, because the

control of software several bodies were State chose the vendor

purchase required


29/32


larly, organisations are thought to contain independent but connected areas that cantake over the duties of each other should one part fail. The whole is encoded intoeach part, so that every part represents the whole in a similar way to the process of

building a hologram (Morgan, 1986, p. 80).The departments are thought to be the independent parts of the organisation. The

functions (teaching, research, clerical and support functions) of the entire universityare in a way coded into individual departments as well. Should a department fail todo its share in an educational program, other departments are able to take over,perhaps with only a marginal shift in the emphasis of the topics included in thecurriculum. Morgan (1986, p. 101) says that the use of this metaphor entails theimplementation of four principles: (1) increasing the requisite variety of the parts ofthe organisation; (2) creating a redundancy of functions into the parts of the organis-ation; (3) improving the organisational learning; and (4) applying the principle ofminimum critical specification, i.e. giving as few direct commands as possible. Thiswas exactly what was tried in the decentralisation strategy (Heiskanen, 1993).

6. Conclusions

This paper is the first journal article in our research project. We will devote furtherresearch on the encounters found in other information systems development projects.This should be interesting to the research community, because it seems that there is

a paucity of in-depth and longitudinal analysis of software procurement. One of thereasons for this is that the nuances of contract negotiations are not normally revealedto outsiders. Our plan is to use the modelling principles presented here to see whichkind of patterns can be identified from a wider spectrum of information systemsdevelopment trajectori

Date post:	04-Jun-2018
Category:	Documents
Upload:	sivainscribd
View:	214 times
Download:	0 times

Dynamic of Software Development

Documents