Dynamic of Software Development

Accting., Mgmt. & Info. Tech. 10 (2000) 132 www.elsevier.
com/locate/amit
The social dynamics of software development

Ari Heiskanen
a
a,*
, Michael Newman b, Jouni Simila
University of Helsinki, Administration Ofce, P.O. Box 33 (Yliopistonkatu 4), FIN-00014 University of Oulunsala, Finland b Vrije Universiteit, Amsterdam and the University of Manchester, UK c University of Oulu and CCC Software Professionals, Oulunsala, Finland
Abstract A variety of experiences in software development processes between a public sector organisation 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 based on detailed insider observations. A social process model is used to describe the relationships between key actors within the client organisation while a transaction cost framework is used to explain the joint forms of the relationships between the client and the vendors. The resulting model 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 potential to change the relationship state between the parties. The relatively stable passages between consecutive encounters are labelled episodes. By perceiving systems development as a series of encounters and episodes, it is possible to identify the critical turning points of development work and to display the dynamics of a software development trajectory. While our ndings support the well-known basic software procurement principle, this is only after the trajectories have stabilised. Two of the three trajectories exhibit major changes in software procurement strategies before reaching a steady state. The paper ends with a discussion of the ndings and some implications for researchers and practitioners. 2000 Elsevier Science Ltd. All rights reserved.
Keywords: Information systems development; Transaction cost economics; Co-operative patterns; Reective practice; Longitudinal research
* Corresponding author. Tel.: +358-9-19123132; fax: +358-9-19122180. E-mail address: ari.heiskanen@helsinki. (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
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 the University of Helsinki, covering the period 19811991. Whereas many textbooks are still locked into the assumption that in-house development is the norm for procuring software, experience tells us that buying software solutions or co-developing them with software houses are also viable and common strategies (Laudon & Laudon, 1996; Saarinen & Vepsa la inen, 1994; Lacity & Hirschheim, 1993). But having raised all these options, management is faced with some difcult choices. Given the type of system to be built or replaced, the basic question 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 conicts between the clientside actors shape the software procurement process. These issues, in turn, become our main research questions which we attempt to answer in two ways: the rst answer is descriptions of three examples of the software procurement process at the University. The rst author is the chief IS ofcer at the administrative unit that makes such decisions and this dual role allows the research team unlimited access to the notes and records of these three procurement histories over the chosen period. The second way is to analyse the evidence using the social process model of userdeveloper relationships suggested by Newman and Robey (1992). We relate the NewmanRobey model of information systems development to the well-known software procurement model of Saarinen and Vepsa la inen (1994). This prescriptive model is based on Transaction Cost Theory and it says that software for simple information systems should be bought from the market, while more complicated ones are better suited for in-house development or customised la inen used cross-sectional surcontracting with outside vendors. Saarinen and Vepsa vey data. In contrast to their approach, examining three cases over a period of 10 years allows us a much broader and empirically grounded picture of software procurement 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. We show how Transaction Cost Theory has been used to model software procurement, but that it produces an essentially static view. The cases, in contrast, reveal the dynamic nature of software procurement. For example, in one of our cases, the process reverted to in-house development, instead of using the services of the former outside contractor. We thought it therefore important to capture this dynamic process by studying it over time, and for this purpose we employed a social process model. We also look briey at the context of procuring systems in a university environment. Next we explicate our research method. We draw heavily upon the work of Donald Scho n as being most appropriate to a study conducted partly by practitioners. Scho ns notion of the reective practitioner is shown to be highly relevant in such a study n, 1983). We also take some care in situating the researchers in the stories (Scho
presented and we briey explore the privileged position of the researcher as an insider 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 language of the process model) such as negotiations and decisions. We then interpret the cases carefully to map the unfolding trajectory1 of each software development history using the principles of the NewmanRobey social process model. In one case we also describe and analyse the evolution of the relationship between the main user unit and the Universitys administrative EDP unit. The trajectories of these three information systems are then compared with the predictions of the software procurement principle la inen (1994). The article ends with a discussion of these of Saarinen and Vepsa ndings, the limitations of the study, and draws some conclusions for researchers and particularly for practitioners who may be considering a similar approach to analysing software procurement.
2. Review of the literature When developing an information system, organisations can apply one of three major approaches: in-house development (make), contractual customised development with outside vendors (a hybrid solution), or software product purchase (cf. Grudin, 1991; Saarinen & Vepsa la inen, 1994). In this section we outline in general terms how the two different organisations, the client and the vendor, are able to inuence each other in development work. It is well known that outsourcing is dynamic (for example, Fitzgerald & Willcocks, 1994). Moreover, it is not possible to specify every contingency in a closed contract over a long period of time (Richmond, Seidmann & Whinston, 1992; McFarlan & Nolan, 1995, p. 17). Negotiations and re-negotiations ll the void that emerges out of the incomplete contracting issue; it is also possible that the contract between the parties evolves to a relational one (Lacity & Hirschheim, 1993, pp. 3536). The inuence mechanisms available to the parties 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 is more indirect: the client must also generally avoid paying too little for the system (Page, Williams & Boyd, 1993; Fitzgerald & Willcocks, 1994). The client must realise that the vendor has also to make a prot for itself in order to continue serving
In our article, the word trajectory has a special meaning. Encounters are plotted on a time grid reecting 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 procurement 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.
the client in future projects. The potential bad cost in this case will be realised through the disillusionment of the vendor with the present project, materialising perhaps in personnel reassignments, delays in project schedules or even total project failures. 2.1. Work governance modes in IS development: a structural analysis The relationship between a software vendor and its client can be understood through several theoretical frames. Some of them are mentioned here in order to illustrate the variety of approaches. Gurbaxani and Whang (1991) discuss transaction cost theory and agency theory. McWilliams and Gray (1995) add environmental uncertainty (an organisation theory construct) and resource based theory (a strategic management construct). The contracting dilemma is analysed, for example, by Richmond et al. (1992), and also by Whang (1992). Bakos and Brynjolfsson (1993), using the economic theory of incomplete contracts, indicate that a buyer will often maximise prots by limiting its options and reducing its own bargaining power. Asanuma (1989) describes the Japanese style of manufacturing where the client can exercise managerial control upon the vendors by using at least two vendors for each service purchased outside, the vendors being classied according to the desirability to continue business with them. Powell (1990) argues that relational or network forms of organising are often a viable way of economic exchange, instead of tight integration or loose market. Kirsch (1997) analyses IS development process control and identies different modes of control for different circumstances. Beath (1983, 1987) proposed a transaction governance approach based on organisational economics to explore exchanges between information systems departments and user communities. We have chosen Transaction Cost Theory as the basis for our analysis, because we felt that this theory was well known (cf. Lacity & Willcocks, 1995), conceptually parsimonious, informative, and easily applicable in our case. Transaction Cost Theory is targeted to the analysis of make-or-buy decisions. The essential question is whether the (client) organisation should make a product or service internally, using a 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 economical one in a given situation. The decision to choose Transaction Cost Theory as the basis does not exclude broader considerations, on the contrary. We describe the case context 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 and transaction costs. The latter consists of the costs of monitoring, controlling and managing transactions. To (over)simplify, Transaction Cost Theory says that if a purchase is relatively simple, the market mechanism should dominate, because it is more efcient 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 becomes more viable, because the transaction costs of a complex purchase may become too
great. The reason for this price growth may, for example, be the opportunistic behaviour 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 three modes (market, hybrid, hierarchy) are the archetypal arrangements that can prevail between the developer (vendor) and the user (client). Williamsons argument is that market and hierarchy are the polar extremes of organising the work, and that the hybrid form is an intermediate arrangement. In the ideal market, the identity of the client and vendor are irrelevant: the products are standardised in such a way that the price of the product gives enough information for decisions. Prices follow the changes in supply and demand; this is the dominant way of adaptation, and no negotiation is needed. The contract is a straightforward deal and fundamental disputes are cleared through litigation. The incentive is the price paid by the client. It is very consequential to the vendor, because if there is no contract, there will be no payment. In a hierarchy, the co-ordination of actors follows the command line of the organisation. The disputes are solved internally (e.g. through administrative at). Adaptation presupposes (intraorganisational) negotiations. Williamsons argument is that the incentives are usually much less powerful in the hierarchy than in the market. They consist of means like using accounting information to reveal the protability of projects 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 unreasonable to rely on the existence of a shared value and belief system between the contracting parties. We have also found that in practice the behaviour of the internal actors of the 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 case of the group of companies forming the software house with which the third author has been afliated. A shared value and belief system has denitely been established. There is also rivalry between clans within the established framework. At the present a sizable part of contracted software development work is in effect redistributed between the software producing units forming the enterprise, extending geographically 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 was however redistributed in this manner, so we will not utilise the clan concept in this context. 2.2. The Software Procurement Principle la inen (1994) The Software Procurement Principle proposed by Saarinen and Vepsa employs Transaction Cost Theory to prescribe a software procurement strategy according to an assessment of the complexity of the proposed system as follows: routine applications (common to many organisations, well-specied requirements, like accounting) can best be implemented by acquiring a software package, i.e. through a market transaction;
standard information systems (shared functionality with a group of organisations but with variation in detailed requirements, e.g. personnel systems) require software contracting, which, according to our argumentation, leads to a hybrid form of development organisation; speculative systems (specic 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 Vepsa la inen (1994) used survey data of 48 development projects in Finland. They, however, found only modest support for the Procurement Principle. In their Table 1, for speculative systems, they assessed that ve were internally developed 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 contradiction to the principle. It is easy to speculate that the problem of the weak validation of the Procurement Principle was due to their research approach. It is difcult in survey research to construct variables from questionnaire items which capture the complexity of the procurement process and impossible to understand the dynamics of 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 of sourcing behaviour (Lacity & Willcocks, 1995). However, the Software Procurement Principle, a derivative of Transaction Cost Theory, is intuitively appealing from a practitioners 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 the process research tradition (Gersick, 1991; Newman & Robey, 1992; Robey & Newman, 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; Richmond et al., 1992; Fitzgerald & Willcocks, 1994) and IS procurement (like Saarinen & la inen, 1994), we believe that our case gives fruitful empirical insights by Vepsa revealing in a concise manner how the dynamic relationships between software developers (internal EDP personnel and outside vendors) and users (clients) evolve over time. Furthermore, we believe that our way to model the dynamics of software procurement can be easily transferred to other circumstances. Our approach is a further development and enlargement of the Newman and Robey model (1992) of userdeveloper interaction. In their process model, applied also in a further case (Robey & Newman, 1996), they identied three main elements: (1) the antecedent conditions; (2) the possible interaction states between the users and developers (acceptance, equivocation, rejection); and (3) the development trajectory of the interaction process. The interaction process consisted of equilibrium state progress 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
as a series of longer episodes, punctuated by brief encounters. An example of an encounter can be the hand-over of a test system to the users. This may change the existing state of client/developer interaction from acceptance to equivocation or even rejection when the clients begin to discover that the proposed system does not full their 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, the client 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 change in personnel. But each encounter will represent a period of relative instability in the project 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 efdoms where barons (and baronesses) are in charge of their own, independent realms, and vigorously defend their territories (Noble & Newman, 1993; Heiskanen, Newman & Saarinen, 1998). Each participant is an individual willing and capable of independent behaviour. It would seem that universities are fundamentally different from business organisations in their decision making processes. Consequently the standard IS development strategies developed for business may not be appropriate in institutions of higher education. To develop a more analytical view, we classify universities as predominantly professional bureaucracies (Hardy, 1991; Mintzberg, 1983). Professors are professional bureaucrats who have a very special kind of relationship with their university (Mintzberg, 1983, p. 207): Professional bureaucracies are not integrated entities. They are collections of individuals who come together to draw on common resources and support services but otherwise want to be left alone. The professional bureaucracy relies on specialisation, hierarchy, rules and regulations that are thought to ensure the predictability of the behaviour of the organisation and to lead to efciency 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 administration organisation and commercial software vendors. Although the routine administration organisation should be a normal service organisation to the professional bureaucracy, it is well known that there are problems in co-ordinating development efforts in all parts of universities (Noble & Newman, 1993). It seems that the loosely coupled nature of the academic community is mirrored in the behaviour of routine administration (cf. Weick, 1976). In order to better understand the information system development processes of our case, we briey characterise the different strategies that can be found in the university context. Later we discuss how the different archetypal strategy models described below materialised in our cases. Maassen and Potman (1990) point out that coordination conicts are easily born, decision making power is extremely dif-
fused, and that there are problems in the coordination between the professionals and the support staff. They suggest that there are three different, but not necessarily independent, strategy models. The rst one is the linear strategy model according to which strategy consists of integrated decisions, actions, or plans oriented towards setting and achieving organisational goals. Both goals and means are subject to strategic decisions. The major assumptions supporting the linear model are that the organisation is tightly coupled, the environment is quite predictable, the organisation has goals, and the achieving of the (common) goals is important. The second strategy model is adaptive. Here the strategy is mainly concerned with the development of a match between the opportunities and risks in the environment. The main assumptions under this model are that the organisation and its environment are open to each other, the environment contains identiable stakeholders like consumers who have preferences, and the organisation must change with its environment. The third model is interpretive strategy which is based on the idea that the assumptions made under the two previous cases are not valid, e.g. when a unifying common organisational goal is missing or the organisation is loosely coupled. The interpretive model is based on a social contract through orienting metaphors or frames of reference that allow the organisation and its environment to be understood by its stakeholders. The interpretive strategy model is focused on the desired relationship with the organisation and its environment. The actors deal with their environment through symbolic 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 competitors to achieve their organisations goals. In adaptive strategy, the organisation and its parts change, proactively or reactively, in order to be aligned with consumer preferences. In interpretative strategy, organisational representatives convey meanings that are intended to motivate stakeholders in ways that favour the organisation.
3. Method 3.1. Situating the authors as practitioners and researchers The main point of view of this paper is that of the rst author in his role as the Chief Information Systems Ofcer of the University. He nished the studies for the licentiate 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 records was offered to him, which he accepted. At that time there was a heated debate of how to renew the student records information system. Several committees had prepared
memoranda for the University Senate, suggesting actions that were necessary because of the syllabus reform performed in Finland in the late 1970s. In a couple of years the rst author realised that it would not be possible to make a profound improvement in the student records system of the University (more details of this later in Section 4.1). In the summer of 1982 he took up the position as a lecturer at the University of Joensuu, continuing also as a part-time worker in his previous position. The situation changed in the spring of 1984. The Rector and the Director of Administration of the University of Helsinki suggested that he consider undertaking a more responsible position in the development of the Universitys administrative information systems. The offer was accepted, leading to his appointment as the Chief Information Systems Ofcer of the University and the establishment of the administrative EDP Ofce in the autumn of 1984. The third author has also been involved in the development of the information systems of our case. He acted in the practical role of a Strategic Business Area manager of one of the vendors concerned (CCC Software Professionals) during the years 19851987. He continued in other managerial tasks with the same vendor until 1998 when he was appointed to be a full professor in the University of Oulu. He has been active in software process assessment and improvement methodology development, and an evaluator for the European Commission in several software process and multimedia related programs. The second author became a part of this process as the dissertation inspector and opponent of the rst author in 1993. His special experience in longitudinal research has close parallels with the rst authors study of university systems over a period of more than a decade. The second author has published several studies of system development projects covering 515 years. Using this empirical evidence and careful interpretations, he has developed a social process model of IS design (Newman & Robey, 1992; Robey & Newman, 1996). 3.2. The reective practitioner Our aim is to put our experience from practice into a form that makes sense also to the broader audience (Heiskanen & Newman, 1997). For this purpose we use the notion of Reection-in-Action, adopted from Scho n (1983) and Raelin (1997). Our task is related to what Nonaka and Takeuchi (1995) call unarticulated practice to explicit knowledge. Scho n (1983, p. 163) frames the work of design as a reective conversation with the situation where the practitioner functions as an agent and experient.2 Through their transactions with the situations, they shape it and make themselves a part of it. Hence, the sense they make of the situation must include their own contributions to it. Yet they recognise that the situation, contrary to the intentions, may foil their projects and reveal new meanings.
2 By experient, Scho n appears to mean an experimentor who is at the same time also a target or part of this experiment.
10
The structure of the process is described by Scho n (1983, pp. 129132) as follows. Practitioners approach the practice problem as a unique case. They do not act as though 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 the problematic situation, and from this gradual discovery, frame the situation by dening its boundaries and components, and design an intervention. The situation is uncertain, and there is a problem in nding the problem. As the practitioners frame and reframe the problem, they suggest a direction for shaping the situation. The practitioners then take the framed problem and conduct an experiment to discover what consequences and implications can be made to follow from it. In order to see what can be made to follow from this framing the practitioners try to adapt the situation to the frame. But the practitioners moves also produce unintended changes which give the situation new meanings. The situation talks back, and the practitioners reframe the situation once again. The process spirals through stages of appreciation, action, and reappreciation. The situation comes to be understood through the attempt to change it, and changed through the attempt to understand it. The practitioners will develop a practice oriented theory or rationale according to which they explain the situation and choose their acts. The word theory here has a special meaning, because according to Scho n (1983, pp. 273274), practitioners do not consider that they have formed a satisfactory account of phenomena in any practice situation until they have framed it in terms of their overarching theory, a rationale according to which they explain the situation and choose their acts. So theory has two intertwined meanings; rst in action design and then in after-the-fact explanations and interpretations. An overarching theory does not give a rule that can be applied to predict or control a particular event, but it supplies language from which to construct particular descriptions and themes from which to develop particular interpretations. Sometimes the overarching theory can be adopted from an existing research tradition, such as in our case with Transaction Cost Theory. Our way of doing this research, reecting over the actions where the authors have been 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 observation period can be long with minimal research resources, but there is also the danger of post-rationalisation and one-sidedness. This approach may become worthless, even harmful as a research approach, if the practitioner/researcher does not consider the reective process to be a possibility for personal growth but targets research results at any price. The danger of contaminated research also exists, because the practitioner has such a control over the production of the research data that it is all too easy for him to design the data to support nearly any argumentation. This is in addition to the 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 triangulated and conrmed with other sources. The Reective Practitioner approach does not guarantee any universal advantage over more traditional research approaches. Normal
11
research skill requirements are the same for a practitioner as for a professional researcher. A combined researcher/practitioner role is a subtle one. Great care should be exercised when deciding which kind of data gathering methods are possible. In many occasions the rst author has felt that it is unethical to interview his co-workers for research purposes only. These interviews could have imposed a avour of the author taking undue advantage of his dual role, aggrandising himself improperly, and intimidating the interviewees by giving a scientic backing to his practical acts. This has been especially true when the author in his practitioners role has experienced strained relations with the informants. In the same way, direct observations seem to be possible only when they occur as a part of the practitioners role. Observing the behaviour of the co-workers only in order to full the data gathering needs of the researcher 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 actors within the University we use the NewmanRobey social process model in its basic form. For the clientvendor issues, our idea is to modify the NewmanRobey model by replacing the acceptanceequivocationrejection classication with another classication that is better suited to the analysis of the relationship between the client and the (commercial) vendors. This latter classication is the markethybridhierarchy notion, based on Transaction Cost Theory, just described in Section 2.1. In our model, we present the case histories as development trajectories over time in the form of lines punctuated by encounters that may change the state of the process from one class to another. The passages between the encounters, the episodes, represent development work that does not change signicantly or rapidly the way in which the parties relate (cf. Newman & Robey, 1992; Robey & Newman, 1996). The researchers looked carefully at the documentary and direct evidence from personal experience before judging what was a signicant event (or an encounter, in the parlance 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 the 1970s there have been strict rules according to which the University as well as other state units have had to develop their systems. The State Computing Centre had a privileged position, and in every major application software purchase by a state bureau a tender from the State Computing Centre had to be obtained. Projects over 50,000 marks (roughly equivalent to about 200 h) had also to be authorised by the Ministry of Finance. Authorisation from the Finnish State Treasury was needed for
12
the development of personnel systems. The regulations were replaced in 1988 by a new 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 the main mode of purchasing should be through competitive bidding, with at least four rms as competitors. Direct purchases from a single vendor should be used only under special circumstances. We have chosen three procurement histories to be analysed. The purpose of the choice is to illustrate how a large variety of development trajectories can easily be captured in a graphical representation. In this way it is possible to grasp easily the longitudinal shape of an information system history over an extended period of time. All three systems reached success in the sense that nally they were in real use, they did not pose any serious problems to management, and the users appeared to be at least moderately satised with them, according to user information satisfaction surveys. The rst system history (the student records) is described in greater detail, based on the dissertation work of the rst author (Heiskanen, 1994). The other two (personnel and accounting) mainly serve as material that supplement the rst case by presenting such features that were not present in the rst one. Furthermore, by presenting the personnel system case, we are able to show how the development processes of the student records and the personnel system interfered. There are ve 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 vendors are denoted by the pseudonyms Alpha and Beta. These latter two only had a role in 1987 and 1988. Alpha had disappeared as a rm by 1995 when the current research project began. However, key information concerning its behaviour was secured from other sources. Beta was a ll-up participant in a bidding competition to get four vendors and obey the stipulations for public bidding at that time. Based on these reasons we did not offer them an opportunity to participate. The client side has been represented by the administrative EDP Ofce of the University, headed by the rst author throughout the study period. One of the major features of the late 1980s was the tight nancial situation of the EDP Ofce compared with the perceived needs of the information systems to be developed. Another issue that affected the development schedules in the late 1980s was the replacement of the Burroughs mainframe of the University in the beginning of 1988. This precipitated the change in the software (student records, personnel; see below) running on this computer. 4.1. The student information system of the University of Helsinki Our story about student records begins in 1981. The rst author had just been hired as a special analyst from the Computing Science Department to the central administration of the University, his main duty being the renewal of the student records system software. He perceived the situation as follows (Heiskanen, 1994).
13
The large increase in incoming data caused by the syllabus reform made it necessary to revise the software and le structures. More hardware capacity would be needed. The organisational data ows could not be radically changed which meant that data had to be sent from the departments on paper to be registered in the Actuarys Ofce, a unit in the Universitys Central Administration dedicated to register maintenance and statistics production about students and personnel. The software, to be used for 23 years, could be modied as a maintenance operation, using the services of the Computing Centre of the University that had made the previous software. A totally new system was planned for 1984, provisionally based on a minicomputer. A scheme to buy new hardware was also sketched. The new software was planned to be developed in co-operation with the State Computing Centre and to run on their hardware. The annual usage costs were expected to grow gradually, and when the usage expenses would have exceeded the costs of the hardware needed, it was thought to be possible to change the usage expense to investment funding in order to purchase hardware. After that the system was planned to run on the Universitys own equipment. The rationale behind the purchase strategy was based on the limited university funds for buying equipment. There were, however, funds available for buying services. This purchase strategy appeared to be unrealistic when it was discussed in several meetings of the administrative EDP Directory Group and the idea gradually faded. 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 student records for several more years. Consequently, to t the new circumstances, the old software could only be modied. The system remained batch oriented with add-on les for on-line terminal data entry and inquiries. Recourse to the maintenance of the old software was a disappointment to the rst author and was one of the reasons for the move to the Joensuu University. The problems with the student records grew during the early 1980s, reaching a state of crisis in the mid-1980s, owing to poor data quality. The system was in a vicious circle: many teachers felt that the system demanded unproductive, extra work in sending study credit data to the Actuarys Ofce. Some credits were unsent, leading to poor coverage. Poor coverage, in turn, made the system incomplete, and this inadequacy felt by its indirect users led to carelessness, etc. The interpretation of unclear examination lists by the personnel of the Actuarys Ofce demanded extra work and caused delays in data entry, this being seen by the departments as the inability of the system to produce timely statistics. The attempts by the personnel of the Actuarys Ofce to persuade teachers to correct erroneous data led to frustration on both sides. It was clear to the rst author in 1984 during his appointment to Chief Information Systems Ofcer that a complete renovation was necessary. An important pre-requisite for this renovation was sufcient hardware resources and software tools, and this was secured 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
to take care of the basic student records functions and explore the possibilities of decentralising the user functions into the departments in order to get rid of the dataows on paper and record the credit data at their source. The formative years of the student record system were from 1986 to 1990. Several organisational actors played key roles during these years. As already discussed, the Actuarys Ofce, headed by the Actuary, was responsible for the maintenance of the student record. The EDP Ofce was in charge of the software development for the student records from the early 1980s. It was also responsible for managing the development project, writing specications for the software, and for educating, training and giving assistance to the departmental users. The Rector was in charge of the University administration, but his role was minor in information systems after he had been active in hiring the rst author. The Director of Administration was the leader of the Administration Ofces of the University, and the manager of the rst author. Four persons acted in this capacity in 1986 1990. The rst of them retired in 1986. After that, the Head of the General Section, subordinate to the Director of Administration, was a deputy Director of Administration for several months. The third Director of Administration, nominated from the beginning of 1987, was replaced by the fourth one in the spring of 1987. These two persons were competing applicants for the job. The change happened after a Supreme Administrative Court decision that was made from the appeal by the fourth Director of Administration, based on jurisdiction about the formal qualications for the job. All these changes were seen by the rst author as creating a difcult working environment, especially should a crisis occur. Some of the work-force were recruited from an outside software house, CCC Software Professionals. The Ministry of Finance regulated the software purchases. The State Computing Centre had a privileged position as the prime vendor for the State organisations, and its statement was needed for application software procurement. The key participants in decentralisation within the University were the staff and the technical resources of the departments. The decision maker was the department head. 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 was the key group affecting the failure or success of the decentralisation of the system functions. But this assembly was not a harmonious one. Several goal differences between the University actors prevailed, as the rst author came to learn (Heiskanen, 1994). First, the Actuarys Ofce considered itself as the sole maintainer of the centralised student record and resisted direct departmental updating. The Actuarys Ofce put it in a memo in December 1987: According to the point of view of the Actuarys Ofce the direct updating of the les of the centralised Student Records cannot be the business of departments and faculties. Currently the whole Register is the responsibility of the Actuarys Ofce. If technical maintenance of the centralised Register is transferred to facul-
15
ties, then the Actuarys Ofce cannot have complete responsibility. Instead, the departments and faculties can make transaction les with their own systems, with which 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 that decentralisation would cause extra work in departments. This view is clearly expressed in the following quotation from a letter to the University Periodical by an associate professor: According to the credit recording system every study achievement should be included in the centralised register. So the smallest sneeze that produces lousy credits should be coded, be written into the le, and be obtainable from there, and why? ... As detailed centralised registration does not improve the basic functions of the University, i.e. teaching and research, in any way, it should be abandoned at once. In the planned form it will unnecessarily increase the work-load of every teacher, ruin old well-functioning systems (the particular department had a card-le by student basis, maintained by the department secretary) and take the whole working capacity of tens of clerks. Extra jobs demanded by the system could be given to the departments directly ... Plan something that would advance our functions and not make them more difcult. Or twiddle your thumbs. Some other teachers expressed in quite sarcastic tone that they should not be bothered with the technical processing of student data. One of the planners of the departments put it as follows when he was asked to tell his personal goals in the decentralisation project: I have no personal goals, I do not get benets from the project, because my own study credits are already recorded. I expect, however, that the duties of the project should 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 department clerk as follows: ... when the teachers split the courses that are already composed of many parts by letting students pass the course book by book, it is impossible for the department ofce to keep track of everything and watch that the lists given (to the teachers) are returned. ... The department head has tried, but more should be stressed that it is a question of legal protection for the students. The registration of 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 development process to see how the events unfolded. The rst author, as the newly appointed
16
Chief Information Systems Ofcer, soon realised that the Universitys own EDP resources could not alone develop the software. An outside vendor was needed. The choice was based on an informal scanning in 1985. CCC was chosen because of its personnels good record of achievements and their strong academic background. The planned purchase of software was negotiated with State Ofcials and the University obtained permission to use CCCs services, instead of those offered by the State Computing Centre. The delivery of the application software for the VAX and the adoption of the renewed enrolment subsystem in the Actuarys Ofce succeeded in the 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 the spring of 1986 in the form of an experimental project for departmental data processing. This project began in the Technical Section of the Ofces of the Rector, but soon the responsibility was taken over by the EDP Ofce. The experimental project, although it suffered from some staff resignations, produced (during the spring of 1987) the specications of a PC-based system for student data processing decentralised in departments. The situation became problematic for the EDP Ofce in the summer and early autumn of 1987 because the Actuarys Ofce considered it too risky for the credit records to be directly used by the personnel of departments and the experimental project engaged in developing the PC software was suspended temporarily because of staff resignations. There were two principal options for the EDP Ofce. One was to cancel the development of the PC software and direct the resources of the project to change the view of the Actuarys Ofce by establishing sufcient controls for security. The other was to 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 Ofce could prevent the direct departmental use of the VAX software for credit data processing. The further development of the PC version seemed to be the better option, mainly because of the apparent positive attitudes towards PCs. The anticipated capacity problems with the VAX running the centralised student records also favoured the inclusion 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 for a PC would be more convenient than that for the VAX. For example, it was easy to incorporate textual information for an individual student in the PC version. An obvious reason was also the fact that this option only needed the approval of the EDP Ofce, and not the approval of other actors. Consequently, during the early autumn of 1987 the EDP Ofce began to make it a real alternative for the department level. The commitment of the EDP Ofce to the development of the PC software had several stages that probed the back-talk of the internal and external actors towards the steps taken by the Ofce. The specications had been written in the spring of 1987 and a bidding competition was started in the summer of that year. The main competitors were software houses Alpha, CCC, and the State Computing Centre. The rst tenders of all these bidders had approximately the same price, but the planned
17
functionality of the system proposed by the State Computing Centre was inferior when 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 rst part of the software would be delivered with limited functionalitya prototypethat later could be developed into a full system. The contract was eventually won by CCC. The Actuarys Ofce reconsidered its view about the suitability and security of the centralised student records to be used directly by the departments and gave permission for departments to directly use the centralised students records in May of 1988. This reconsideration was developed gradually in 1987 and early 1988 during the work of two consecutive committees. The task of the rst one was to dene the concepts of student data processing, how to register study credits, and suggest how the amount of credits produced by each faculty could be obtained. The second committee (the register committee), established by the Senate in early September 1987, was charged with the task of planning how to decentralise the credit record data processing. The rst author was not a member of the rst committee, but was enrolled on the second one. The arguments favouring the decentralised use of the student record system, including decentralised credit data entry, prevailed over the Actuarys original view, although this entailed several heated discussions. The matter was settled in March of 1988 when the Senate approved a project to explore the possibilities for decentralisation as a means of solving the data problems. In a way, the rst author was ghting on two fronts in the autumn of 1987. First, within the University there were many and strongly differing views of the viability of the development work and decentralised student record data processing. Second, a shortage of money necessitated tight bargaining in bidding competitions for software purchases. By rst developing the prototype in the autumn of 1987, the EDP Ofce kept open the possibility of stopping the development work without too many costs being incurred should the University community react negatively. But at the same time, it kept open the possibility to continue. The decision of the Senate to launch the decentralisation project in March 1988 ensured the continuation of the work. In 1987 the EDP Ofce did not have enough money to consider the simultaneous development of the student record system and the personnel system (see the following subsection). So a low price was very important. The rst author had a strong belief that funding could be secured during 1988, but that demanded positive and concrete signs of progress. On CCCs side, lowering the price of the rst part of the PC software delivery was possible, because the software house could give the work to an analyst who just at that time did not have any other assignments. So the Universitys need for a low price for the rst stage of the work and the vendors need to nd a task for the analyst complemented each other, and a favourable agreement over the price could quite rapidly be achieved between the rst author and the vendor 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 records software. Whether the price level of the bids of either vendor for the whole software or the rst part of it was realistic is difcult to decide, because it was anticipated
18
that the specication contained only a part of the true user requirements. The billing of the further work could compensate for the losses caused by the possible low price level of the early work. The development co-operation between the University and CCC evolved over the years, typically from xed-price deliveries of pieces of software into contract programmer hiring. It appeared that changing the maintenance and further development of software from the vendor to the EDP Ofce would be the most economic option, , because the personnel of the EDP Ofce, acting as gatekeepers (Heiskanen & Simila 1992) between users and outside developers, considered it easier to develop the software by themselves. Therefore the University decided in 1990 to develop and maintain the software without outside assistance. This was possible, because the amount of work was small enough for one or two analysts to master. The decentralisation project ended in March of 1989. The rst departments had adopted a decentralised student records system during the project. For the rest of the departments, decentralised data entry was optional. Each department could either adopt an EDP variant (VAX or PC-version), or continue its previous method of sending data on paper to the Actuarys Ofce. The departments were made responsible for the purchase of the equipment needed, and they had to arrange clerical personnel and organise their internal data processing. The Central Administration would provide education, support, and the installation of the software. The resource allocation process of the University was to be more reliant on the data in the credit records. The students would obtain a register excerpt annually, in order to secure that all credits would eventually be recorded. This strategy appeared successful. In a few years, virtually all departments had adopted the decentralised processing of student record data. 4.2. The personnel and job system The history of the personnel system development described here began with competitive bidding in November 1986. The EDP Ofce was in charge when the specications were prepared prior to the bidding competition, and it represented the users in the bidding competition with the software houses Alpha, Beta, CCC and the State Computing Centre. The contract was won by Alpha, because it eventually promised to deliver the specied software free of charge. This vendor wanted to expand into the public administration sector and to get a reference project of a particular tool environment. 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 by lowering 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 large penalties 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 nally to project failure from its point of view. Although Alpha had delivered the core part of the software successfully in 1987
19
and its use began as planned in the beginning of 1988, Alpha was not able to deliver a reporting package later that year. Consequently, the EDP Ofce gradually came to a decision to stop the co-operation with Alpha and continue the development with another software house, CCC. The University had used CCCs services in developing the student record systems with acceptable performance. This was the main reason behind the choice, and so to avoid the work that would have been incurred in the search of a totally new software house. The change-over entailed several steps that revolved around two issues. First, the price level of Alpha was very economical to the 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 delivery of a useful reporting package or other pieces of new software. Second, the University probed the capability of CCCs personnel in small deliveries like a training version of the personnel system in the summer of 1988, before full commitment. By the end of 1988 CCC appeared to be a viable choice. In March of 1989 the University formally closed the co-operation with Alpha. The development and maintenance of the personnel system continued with CCC until 1997 when it was replaced with a new system. The low price of the rst software delivery was essential for the University, because it needed the approval or positive statements for its actions from the Ministry of Finance, the State Treasury, and the State Computing Centre. The State Computing Centre and the State Treasury had together developed systems for personnel administration, but the adoption of these would have required changes in the ways the University operated in personnel administration. Moreover, the University had chosen a specic database management system for student records, and wanted the personnel system 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 also in 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 straightforward case: it was a direct purchase, without a bidding competition, from a single vendor, Tietovoima, which had earlier been chosen by the State after a bidding competition to develop an accounting package for all state bureaux. In the beginning of 1992, KT-Tietokeskus purchased the accounting systems business from the owner of Tietovoima. This purchase meant moving the accounting system development and support personnel from the old host to the new one. The contract made between the University and the prior vendor remained valid without renegotiations. At the time of purchase, the choice of software vendor of accounting packages for the state bureaux was extremely simple, because there was only one state-approved option. Later the State abandoned its guiding role and relaxed the statutes allowing other vendors to bid also. 4.4. Features of contracting Some general comments can be made based on our experiences of software contracting, especially concerning how the parties are able to control each other, i.e.
20
how one party can affect the behaviour of the other party. In this respect, we should remember 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 vital ones in our experience. The dominant control mechanism is the mutually acceptable price level in the bidding process. The vendor must strive towards reasonable compensation in order to 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 perspective. For example, in developing the PC version of the student records software and the rst part of the personnel software, the University had to act on a shortterm perspective and choose the lowest price option. The price level control mechanism can also be used in a reverse sense by the vendor in order to break involvement with a client at least temporarily. A further negative effect of the use of the price level control mechanism, at least in an exaggerated manner, is its effect on future bidding. The vendor may prole itself as too expensive to be included in future bidding or too cheap to bid protably. The second control mechanism emphasises the long-term relationship between the software house and the client. This is because there is a trade-off between the emphasis on competition leading to reduced price of the work and a need for creating longstanding and mutually benecial relationships between users and developers. An aspiration towards a long-range relationship with the client may at times conict with the price level control mechanism in the short-term. The vendors aspiration towards a long-term relationship with the client is, in general, preferable from both the vendors and the clients viewpoints. This aspiration may be realised in ways other than by contractual price level control. For example, a vendor may, by assigning highly qualied persons in the early projects, make in effect a lasting impression and a strategic investment for getting future projects from the client. The third control mechanism may come out of the certied quality management and assurance system. For example, the ISO 9000 certicate is conditional and it is awarded for a limited period. If the client nds the vendors performance unacceptable, a powerful means for improvement is a complaint to the standardisation organisation that awards (and withdraws) the certicates. The development of a certied quality assurance scheme such as ISO 9000 can be 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 production , Kuvaja & Krzanik, 1995). In the long term, this is a remarkable maturity (Simila inuence 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 rst part of our model, the development encounters in Tables 1 and 2 for the student records, in Table 3 for the personnel system, and in Table 4 for the accounting system. The second part of our model
21
Table 1 The internal encounters of the student records development Enc. No 1 2 3 4 Date 1/1981 2/1982 8/1984 Spring 1987 Encounter description The rst author is hired as a special analyst to the Administration Ofces of the University of Helsinki The rst author moves to the University of Joensuu, remaining also as a part-time worker in his previous position The rst author is re-hired by the University of Helsinki, now as the Chief Information Systems Ofcer An encounter that lead to bifurcation: on the one hand the Actuarys Ofce takes, nally, an active role in the development of the VAX version, but, on the other hand, forcefully resists the decentralisation of student records data entry The Actuarys Ofce takes an active role in software development The Actuarys Ofce writes a memorandum expressing its resisting view of the decentralisation The Actuarys Ofce nally approves the decentralised data entry to the student records
5 6 7
3/1987 12/1987 5/1988
Table 2 The external encounters of the student records development Enc. No 1 2 3 4 Date 1985/9 1985/9 1985/11 1986/6 Encounter description Preliminary specications for the student records system prepared Informal contract between the University and CCC for rening the specications Contract between the University and CCC concerning the core part of VAX-software An experimental project for developing departmental data processing begins. The idea of the PC version emerges within this project The specications of the PC version completed within the University. Request for proposals of development mailed to vendors CCC chosen to be the vendor of the PC software The University takes over the development (perfective maintenance) of both pieces of student records software
1987/6
6 7
1987/10 1990/5
presents the shapes or trajectories of the process by connecting the encounters with the episodes. They are in Figs. 14, including also the respective encounter numbers. With these two sources, we believe that the reader is able to easily understand the dynamics of the processes. The gures also contain brief descriptions of the antecedent 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
Table 3 The encounters of personnel systems development Enc. No 1 2 Date 1986/11 1987/26 Encounter description Specications for the personnel system prepared within the University and a request for proposals is mailed to vendors Alpha wins the contract, development begins but the nal contract must be approved by the State ofcials. Finally the contract is signed between the University and Alpha The University begins to change the software vendor to CCC because Alpha is not able to deliver the reporting package
1988/6
Table 4 The encounters of the purchase of the accounting package Enc. No 1 Date 1991/68 Encounter description The University asks for a tender from Tietovoima about the delivery of the accounting package which has just been approved by the State Ofcials. 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
Fig. 2. The development trajectory of the clientvendor relationships of the student records system.
Fig. 3. The development trajectory of the personnel systems.
24
Fig. 4.
The development trajectory of the accounting system.
encounters as well as the ensuing episodes were identied and classied by the rst author. This work was based on his analysis of the archived data. The data were familiar to him, because he had participated in all the clients decisions concerning the relationships with the vendors, as well as negotiations with the internal actors. The identity of the encounters and episodes was conrmed by the third author on CCCs part. The managers of the other vendors did not make any objections when the manuscripts describing the episode/encounters were sent to them for review. The episodes and encounters have been discussed in several occasions with internal actors of the University and no objections have been presented to our classications and interpretations. The encounter/episode classication rules were quite simple, but required careful considerations. If the software developers were employed by the University, it was classied 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 in software development. Second, especially for encounters, when there was a bidding competition or contract negotiation, or a possibility for the University to easily change 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 and the hierarchy where the input of the client or user organisation, or the expertise of the vendor, was essential to software development.
25
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 get more professionalism in vendor/client control, and to increase self-understanding. As Boland (1991) says of these kinds of self-reective studies, intellectual curiosity toward ones own professional practice can produce insights that help to improve the quality of management information systems both in particular and general cases. This development and decentralisation process of the student records was also the topic of his dissertation (Heiskanen, 1994). As a researcher over the years, he learned to perceive the implementation process quite differently from the initial framing. The research began in 1986 with a straightforward factor approach, planning to include variables describing the departments, the personnel, technical alternatives as seen by the departments, and the like. The original set of research questions in 1986 did not contain the most important nal research question which was about the reality of action design, i.e. how action strategies get their birth. The introduction of this question meant a radical departure from the positivistic, backwards looking stance expressed in the earlier research plans toward action research, action design, and future orientation of the nal research plan. This change occurred when the rst author reected on the meaning of the decentralisation strategy that he had planned (cf. Scho n, 1983). Developing several information systems concurrently with few resources for a dispersed user community can be very stressful. This has been felt by the rst author on many occasions, especially with the student records in 1987 and 1988. An additional source of stress was that the development process of this system was his dissertation topic. However, the basic literature survey for research work can help in dealing with the anxieties of practice. For the rst author this happened when he tried to learn to take a stoic apathy stance, or, in other words, exercise the art of indifference, as suggested by Hodgkinson (1983). Here indifference is to be understood in a special sense. It does not mean that one does not care, but a leader has to be concerned about human and organisational outcomes in which he has full or partial 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 to be eliminated from the set of relevant variables. This is idealistic, and one can accomplish it only by approximation, by constant effort and constant failure. In practical terms, the exercise of the art of indifference has been different in the three cases. In the case of the student records, the acts of the rst author conform to the interpretive strategy (Maassen & Potman, 1990). He felt unsure of whether the support of decentralisation would be great enough to over-come the clearly felt resistance originating from the Actuarys Ofce. What was certain for him consisted of the power over the acts of his own unit. It is possible to speculate at hindsight that 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
sity when the development process began. The system was adapted rst to the hardware change, and later it was adapted to the work-ows 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 development and implementation of a project without high level of stakes, and consequently did not cause any special stress, and the exercise of indifference was not difcult. The process maps are helpful in depicting the software procurement dynamics over several years. By taking a longitudinal position we can begin to see the emergence of patterns in the trajectories and the signicance of alliances with specic software houses. What is revealed is a picture of organisational learning (two-way) as parties adjust and negotiate over time. The maps indicate the importance of establishing and fullling successful contracts at an early stage. Additionally, the theoretical lens of Williamson (1991) acts as a powerful explanatory vehicle in the analysis of the clientvendor relationship. It seems that Transaction Cost Theory gives us intellectual machinery to explain our experience in relatively simple terms. For example, in the initial purchase of the student record system, the goal of efciency and lack of internal resources seemed to dominate. Therefore solutions were sought from the market. Later, during the use and maintenance phases, the costs of using an outside vendor became too great, because the gatekeepers had to devote much of their time to acting as intermediaries between the end users and 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 processes according to the maturity of the application area. Accounting is a very mature eld, and therefore the contracts are also of a market type (Fig. 4). The data processing needs in student administration seem to be rather immature and constantly evolving. Therefore the systems in this area need constant tailoring as the users learn new ways to do their business. In our case, this tailoring meant internal development. Personnel systems seem to be somewhere between the extremes of mature and immature. By using longitudinal data in our study, we observed how the procurement strategies developed over time until they reached relatively stable conditions. It is these stable conditions which our study revealed which give more support to the Procurement Principle. These conditions would be difcult to capture using snap-shot type survey data (cf. Saarinen & Vepsa la inen, 1994). Although our three example systems followed the Procurement Principle, thus increasing its credibility, further empirical research is needed before it is possible to say how much the intuitively appealing Procurement Principle predicts or explains actual behaviour, and under which circumstances it does so. Each of our three cases represent selective sourcing. It seems that in these kinds of cases the predictive power of Transaction Cost Theory and its derivatives like the Software Procurement Principle is greater than in total sourcing decisions (cf. Lacity & Willcocks, 1995). It is well known that several different interpretations can be drawn from the same evidence. Lacity and Hirschheim (1993) used two viewpoints with which to analyse information systems outsourcing: economic (Transaction Cost Theory) and political.
27
They found that different views complement each other. We follow suit. The Newman and Robey (1992) classication acceptanceequivocationrejection has overtones of political behaviour, and we supplement this view with the markethybrid hierarchy classication. It is possible that in some situations political considerations will dominate, imposing additional costs in the form of, say, conicts between stakeholders. In these kinds of analyses, Orlikowski and Hofmans (1997) notion of improvising could be a good characterisation (see also Ciborra, 1997). Indeed, improvising has been prominent in our situations when a clear-cut strategy was difcult to nd for reasons like lack of resources, different development projects interfering with each other, or because of conicts between University actors. All these issues made the situations difcult to master in a co-ordinated manner. By looking at the picture one gets in combining the development trajectories of the student records and the personnel system in 1987, it is easy to see a cluster of simultaneous encounters that shape the progress. In recollection, 1987 began in equivocation about how to develop the student records. A set of three encounters emerged: encounter 4 in Fig. 1 meant a bifurcation, because the Actuarys Ofce, 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 towards the decentralisation turned into outright rejection and forceful resistance (encounter 6). The resistance was eventually abandoned, because the register committee suggested decentralisation, which was approved by the University Senate. Lack of money also necessitated improvisational acts in the autumn of 1987. The free-ofcharge delivery of the rst part of the personnel systems was one example and the incremental development of the microcomputer version of the student records was another. In addition to improvising, our experience can be related (see Table 5) to two other 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 requires some comments. Three different organisational metaphors from Morgan (1986) can be interpreted to have been present in our cases. The accounting system purchase conforms to a simplistic, mechanistic view: the organisation is like a machine in this straightforward task. The personnel system is a little bit more complicated. We can frame its development best as an adaptive process where the view of the organisation is that of an organism. In the rst authors interpretations of the organisational view, the student 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. According to this notion, the functions of the brain do not have a certain and distinct locus but they 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 without totally paralysing them. Performance deteriorates proportionally to the amount of brain tissue removed. Other areas take over the duties of the removed tissue. Simi-
28
Table 5 Summary of the case information systems Student records Type of system Major system, tailored software development Personnel Originally marginal system, growing to a major one, tailored software development Accounting Major system, packaged software purchase
Organisational Severe conicts between situation in the key actors, anarchical phases of the procedures, poor data development quality process
Poor data quality because Poor service level the system is not integrated to any work process, lack of organisational host because the University did not have a personnel department Software renewal because Adoption of an on-line of hardware change, system integration of the system to personnel work process Adaptive, phased development, rst basic system replaced, then integrated to work-ow Organism Linear, straightforward adoption process according to the vendors delivery scheme Machine bureaucracy
Motivation for the Out of the anarchy development through decentralisation process as seen by the rst author Development strategy Interpretive, incremental decentralisation process, improvisation in the formative phase
Dominant image of Holographic the organisation held by the rst author Relationships changes between internal developers and users Relationships changes between the client and the vendor(s)
From acceptance to From acceptance to equivocation and rejection equivocation and back to (major conict), and then acceptance back to acceptance
Acceptance throughout the whole process
From hierarchy via market From hierarchy via market Market and hybrid back to to hybrid hierarchy
Amount of state Modest control of software purchase
Tight, pronouncements of Total control, because the several bodies were State chose the vendor required
29
larly, organisations are thought to contain independent but connected areas that can take over the duties of each other should one part fail. The whole is encoded into each 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 university are in a way coded into individual departments as well. Should a department fail to do 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 the curriculum. Morgan (1986, p. 101) says that the use of this metaphor entails the implementation of four principles: (1) increasing the requisite variety of the parts of the organisation; (2) creating a redundancy of functions into the parts of the organisation; (3) improving the organisational learning; and (4) applying the principle of minimum critical specication, i.e. giving as few direct commands as possible. This was exactly what was tried in the decentralisation strategy (Heiskanen, 1993).
6. Conclusions This paper is the rst journal article in our research project. We will devote further research 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 the reasons for this is that the nuances of contract negotiations are not normally revealed to outsiders. Our plan is to use the modelling principles presented here to see which kind of patterns can be identied from a wider spectrum of information systems development trajectories. For the practitioner, the results should provide some encouragement in the quest for a solution to the software procurement issue. Each of our three systems can be seen as representative of the three types of projects encountered by most information systems management: routine applications, standard systems, and speculative systems. In the cases as described, the University in the long run stabilised on software solutions which match the project types providing further support for the Software Procurement Principle. Whether this matching would t other projects and other organisations is best left to the decision makers concerned, but the evidence could at least be considered when decisions are being made. We have also shown how development processes can entail improvisation in a complicated situation, where different information system development processes interacted. The outcome of this battle between forces inside and outside of the University over the student record system was the emergence of a coherent (but interpretive) development and decentralisation strategy. The limitations involved in this kind of research are clear. In addition to the ones discussed above concerning the reective practitioner, we present only three cases as a basis for our ndingsa relatively small sample. Other factors which limit the general usefulness of the ndings include the university setting in which the study
30
took place and the location. As Saarinen and Vepsa la inen (1994) point out, there are few package solutions available in Finland to satisfy the needs of managers seeking software solutions to their problems. The setting of the study in a university is known to affect how decisions are made. It is notoriously difcult to co-ordinate actions in such settings (Noble & Newman, 1993; Weick, 1976). This may imply that software projects are likely to take longer than in other organisations.
Acknowledgements We would like to thank Dick Boland and two anonymous reviewers for helpful comments on the earlier drafts of this paper. This article is partly based on our earlier work: Heiskanen, A., Newman, M., & Simila , J. (1996) Software contracting, a process model. In J. I. DeGross, S. Jarvenpaa, & A. Srinivasan, Proceedings of the Seventeenth International Conference on Information Systems, Cleveland, Ohio, 16 18 December. Support for this work was partly provided by the Institute of Chartered Accountants in England and Wales.
References
Asanuma, B. (1989). Manufacturersupplier relationships in Japan and the concept of relation-specic skill. Journal of the Japanese and International Economics, 3, 130. Bakos, J. Y., & Brynjolfsson, E. (1993). Information technology, incentives and the optimal number of suppliers. Journal of Management Information Systems, 10, 3753. Beath, C. M. (1983). Strategies for managing MIS projects: a transaction cost approach. In Proceedings of the fourth international conference on information systems (pp. 133147). Houston, TX. Beath, C. M. (1987). Managing the user relationship in information systems development projects: a transaction governance approach. In Proceedings of the eight international conference on information systems (pp. 415427). Pittsburgh, PA. Boland, R. J. (1991). In search of management information systems: explorations of self and organization. In Second Kilpisja rvi IS Seminar. Finland. Chaffee, E. E. (1985). The concept of strategy: from business to higher education. In J. C. Smart, Higher education: handbook of theory and research, I. New York: Agathon. Ciborra, C. (1997). Improvising in the shapeless future. In C. Sauer, & P. W. Yetton, Steps to the future, fresh thinking on the management of IT-based organizational transformation (pp. 257277). San Francisco: Jossey-Bass. Fitzgerald, G., & Willcocks, L. (1994). Contracts and partnership in the outsourcing of IT. In J. I. DeGross, S. L. Huff, & M. C. Munro, Proceedings of the fteenth international conference on information systems (pp. 91-98). Vancouver, Canada. Gersick, C. J. G. (1991). Revolutionary change theories: a multilevel exploration of the punctuated equilibrium paradigm. Academy of Management Review, 16, 1036. Grudin, J. (1991). Interactive systems: bridging the gaps between developers and users. Computer, April, 5969. Gurbaxani, V., & Whang, S. (1991). The impact of information systems on organizations and markets. Communications of the ACM, 34, 5972. Hardy, C. (1991). Conguration and strategy making in universities, broadening the scope. Journal of Higher Education, 62 (4), 363393. Heiskanen, A. (1993). Organizational metaphors and information systems practice: a case example of
31
implementation strategy formulation. In D. Avison, J. E. Kendall, & J. I. DeGross, The proceedings of the IFIP WG 8.2 working conference Information systems development: human, social and organizational aspects (pp. 399-417) Noorwijkerhout, 1719 May. Amsterdam: North-Holland. Heiskanen, A. (1994). Issues and factors affecting the success and failure of a student record system development process, a longitudinal investigation base on reection-in-action. Doctoral Dissertation at the University of Tampere. The University of Helsinki. Heiskanen, A. (1995). Reecting over a practice, framing issues for scholar understanding. Information Technology and People, 8, 318. Heiskanen, A., & Newman, M. (1997). Bridging the gap between information systems research and practice: the reective practitioner as a researcher. In K. Kumar, & J. I. DeGross, Proceedings of the eighteenth international conference on information systems (pp. 121131). Atlanta, GA, 1517 December. Heiskanen, A., Newman, M., & Saarinen, V. (1998). Innovations in efdoms: developing a common student information system in six Finnish universities. In T. J. Larsen, L. Levine, & J. I. DeGros, Proceedings of the IFIP WG8.2 and 8.6 joint working conference on information systems: current issues and future changes (pp. 455469). Helsinki, Finland, 1013 December. Heiskanen, A., & Simila , J. (1992). Gatekeepers in the action structure of software contracting: a case study of the evolution of userdeveloper relationships. ACM Computer Personnel, 14, 3044. Hodgkinson, C. (1983). The philosophy of leadership. New York: St Martins Press. Kirsch, L. J. (1997). The management of complex tasks in organizations: controlling the systems development process. Organization Science, 7 (1), 121. Kling, R. (1987). Dening the boundaries of computing across complex organizations. In R. J. Boland, & R. A. Hirschheim, Critical issues in information systems research (pp. 307362). Chichester: Wiley. Lacity, M. C., & Hirschheim, R. (1993). Information systems outsourcing: myths, metaphors and realities. Chichester: Wiley. Lacity, M. C., & Willcocks, L. P. (1995). Interpreting information technology sourcing decisions from a transaction cost perspective: ndings and critique. Accounting, Management, and Information Technology, 5 (3/4), 203244. Laudon, K. C., & Laudon, J. (1996). Management information systems: organizations and technology. (4th ed.). New York: Prentice-Hall. Maassen, P. A. M., & Potman, H. P. (1990). Strategic decision making in higher education: an analysis of the new planning system in Dutch higher education. Higher Education, 20, 393410. Markus, M. L., & Robey, D. (1988). Information technology and organizational change: causal structure in theory and research. Management Science, 34, 583598. McFarlan, F. W., & Nolan, R. L. (1995). How to manage an IT outsourcing alliance. Sloan Management Review, 36, 923. McWilliams, A., & Gray, S. R. (1995). Understanding quasi-integration. The Journal of Business Strategies, 12, 6985. Mintzberg, H. (1979). The structuring of organizations, a synthesis of the research. Englewood Cliffs, NJ: Prentice-Hall. Mintzberg, H. (1983). Structure in ves: designing effective organizations. Englewood Cliffs, NJ: Prentice-Hall. Morgan, G. (1986). Images of organization. Great Brittain: Sage Publications. Newman, M., & Robey, D. (1992). A social process model of useranalyst relationships. MIS Quarterly, June, 249266. Noble, F., & Newman, M. (1993). Integrated systems, autonomous departments: organizational invalidity and system change in a university. Journal of Management Studies, 30 (2), 195219. Nonaka, I., & Takeuchi, H. (1995). The knowledge-creating company. New York: Oxford University Press. Orlikowski, W.J., & Hofman, J.D. (1997). An improvisational model of change management: the case of groupware technologies. Sloan Management Review, Winter. Ouchi, W. G. (1979). A conceptual framework for the design of organizational control mechanisms. Management Science, 25, 833848.
32
Page, D., Williams, P., & Boyd, D. (1993). Report of the inquiry into the London Ambulance Service. UK: Southwest Thames Regional Health Authority. Powell, W. (1990). Neither market nor hierarchy: networked forms of organization. In B. Staw, & L. Cummings, Research in organizational behavior (volume 12) (pp. 295336). Greenwich, CT: JAI Press. Raelin, J. A. (1997). A model of work-based learning. Organization Science, 8 (6), 563578. Richmond, W. B., Seidmann, A., & Whinston, A. B. (1992). Incomplete contracting issues in information systems development outsourcing. Decision Support Systems, 8, 459477. Robey, D., & Newman, M. (1996). Sequential patterns in information systems development: an application of a social process model. ACM Transactions of Information Systems, 14, 3063. Saarinen, T., & Vepsa la inen, A. P. J. (1994). Procurement strategies for information systems. Journal of Management Information Systems, 11, 187208. Sabherwal, R., & Robey, D. (1995). Reconciling variance and process strategies for studying information systems development. Information Systems Research, 6, 303327. Scho n, D. (1983). The reective practitioner, how professionals think in action. New York: Basic Books. Simila , J., Kuvaja, P., & Krzanik, L. (1995). BOOTSTRAP: a software process assessment and improvement methodology. International Journal of Software Engineering and Knowledge Engineering, 5, 559584. Weick, K. (1976). Educational establishments as loosely-coupled systems. Administrative Science Quarterly, 21, 111. Whang, S. (1992). Contracting for software development. Management Science, 38, 307324. Williamson, O. E. (1991). Comparative economic organization: the analysis of discrete structural alternatives. Administrative Science Quarterly, 36, 269296.

Dynamic of Software Development

Uploaded by

Copyright:

Available Formats

Dynamic of Software Development

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dynamic of Software Development

Uploaded by

Copyright:

Available Formats

How did the relationships between the client and vendors evolve over time?

How did the relationships between the client and vendors evolve over time?

What software procurement strategies did the client adopt for the different systems?

What software procurement strategies did the client adopt for the different systems?

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

The social dynamics of software development

, Michael Newman b, Jouni Simila

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3/1987 12/1987 5/1988

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

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

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

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

The development trajectory of the accounting system.

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

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

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

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

Acceptance throughout the whole process

Amount of state Modest control of software purchase

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

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

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

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

You might also like