The social dynamics of software development

Accting., Mgmt. & Info. Tech. 10 (2000) 1–32
www.elsevier.com/locate/amit
The social dynamics of software development
Ari Heiskanen a,*
, Michael Newman b
, Jouni Simila¨ c
a
University of Helsinki, Administration Office, P.O. Box 33 (Yliopistonkatu 4), FIN-00014 University
of Oulunsala, Finland
b
Vrije Universiteit, Amsterdam and the University of Manchester, UK
c
University of Oulu and CCC Software Professionals, Oulunsala, Finland
Abstract
A variety of experiences in software development processes between a public sector organis-
ation and several software vendors over a decade-long period are described and interpreted.
Three information systems histories are presented as case examples and their analysis is 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 findings
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 findings
and some implications for researchers and practitioners. © 2000 Elsevier Science Ltd. All
rights reserved.
Keywords: Information systems development; Transaction cost economics; Co-operative patterns; Reflec-
tive practice; Longitudinal research
* Corresponding author. Tel.: +358-9-19123132; fax: +358-9-19122180.
E-mail address: ari.heiskanen@helsinki.fi (A. Heiskanen).
0959-8022/00/$ - see front matter © 2000 Elsevier Science Ltd. All rights reserved.
PII: S0959-8022(99)00013-2

2 A. Heiskanen et al. / Accting., Mgmt. & Info. Tech. 10 (2000) 1–32
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 1981–1991.
Whereas many textbooks are still locked into the assumption that in-house devel-
opment 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ïnen, 1994; Lacity &
Hirschheim, 1993). But having raised all these options, management is faced with
some difficult 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 conflicts between the client-
side actors shape the software procurement process.
These issues, in turn, become our main research questions which we attempt to
answer in two ways: the first “answer” is descriptions of three examples of the
software procurement process at the University. The first author is the chief IS officer
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 user–developer relationships suggested by Newman and
Robey (1992). We relate the Newman–Robey model of information systems develop-
ment to the well-known software procurement model of Saarinen and Vepsa¨laïnen
(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
contracting with outside vendors. Saarinen and Vepsa¨laïnen used cross-sectional sur-
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 pro-
curement than has hitherto been possible.
We will proceed as follows. In the next section we will describe the literature on
software procurement and how to model the process over an extended period. 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 briefly 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¨n’s
notion of the reflective practitioner is shown to be highly relevant in such a study
(Scho¨n, 1983). We also take some care in situating the researchers in the stories

3A. Heiskanen et al. / Accting., Mgmt. & Info. Tech. 10 (2000) 1–32
presented and we briefly 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 Newman–Robey social process model. In one case we also
describe and analyse the evolution of the relationship between the main user unit and
the University’s administrative EDP unit. The trajectories of these three information
systems are then compared with the predictions of the software procurement principle
of Saarinen and Vepsa¨laïnen (1994). The article ends with a discussion of these
findings, 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 develop-
ment with outside vendors (a hybrid solution), or software product purchase (cf.
Grudin, 1991; Saarinen & Vepsa¨laïnen, 1994). In this section we outline in general
terms how the two different organisations, the client and the vendor, are able to
influence 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 fill 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. 35–36). The influence 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 profit for itself in order to continue serving
1
In our article, the word trajectory has a special meaning. Encounters are plotted on a time grid
reflecting the changes in procurement strategy. The subsequent shape of the connected encounters is what
we refer to as a procurement trajectory. A straight horizontal line would signify a highly stable procure-
ment strategy whereas a sharp, saw-toothed shape would show a highly dynamic, unstable procurement
policy. The trajectories show, therefore, the dynamics of the software procurement process but in a very
“broad brush” form. The detailed narrative and the theoretical explanation of the events provide the story
behind the pictures. This is discussed later in Section 4.

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 per-
haps in personnel reassignments, delays in project schedules or even total project fail-
ures.
2.1. Work governance modes in IS development: a structural analysis
The relationship between a software vendor and its client can be 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 Rich-
mond 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 maxi-
mise profits by limiting its options and reducing its own bargaining power. Asanuma
(1989) describes the Japanese style of manufacturing where the client can exercise
managerial control upon the vendors by using at least two vendors for each service
purchased outside, the vendors being classified according to the desirability to con-
tinue 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 ident-
ifies different modes of control for different circumstances. Beath (1983, 1987) pro-
posed 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 client’s 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 man-
aging transactions. To (over)simplify, Transaction Cost Theory says that if a purchase
is relatively simple, the market mechanism should dominate, because it is more
efficient 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 behav-
iour of the vendor, or the specialised resources that have to be devoted to monitoring,
controlling and managing the development process. There is also a hybrid form that
is a joint organisation of the client and the vendor (Williamson, 1991). These three
modes (market, hybrid, hierarchy) are the archetypal arrangements that can prevail
between the developer (vendor) and the user (client).
Williamson’s 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 organis-
ation. The disputes are solved internally (e.g. through administrative fiat). Adaptation
presupposes (intraorganisational) negotiations. Williamson’s 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 profitability of pro-
jects or using career rewards and penalties.
A fourth organisational archetype often mentioned in this context, the clan (Ouchi,
1979), seems inappropriate for the purposes of this article, because it is 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 affiliated. A shared value and belief system has definitely 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 redistrib-
uted between the software producing units forming the enterprise, extending geo-
graphically even outside the mother country. In the cases discussed in this paper,
and for the time periods concerned, no part of the contracted software work was
however redistributed in this manner, so we will not utilise the clan concept in
this context.
2.2. The Software Procurement Principle
The Software Procurement Principle proposed by Saarinen and Vepsa¨laïnen (1994)
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-specified 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 (specific to one company or involving high uncertainty of
requirements, like a student record system) are best left to internal development,
i.e. for a hierarchy.
Saarinen and Vepsa¨laïnen (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 five 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 contradic-
tion 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 difficult 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
practitioner’s 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 & New-
man, 1996). We analyse the processes from the inside, as seen by the participants.
While there exist good treatments of IS contracting (e.g. Whang, 1992; Richmond
et al., 1992; Fitzgerald & Willcocks, 1994) and IS procurement (like Saarinen &
Vepsa¨laïnen, 1994), we believe that our case gives fruitful empirical insights by
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 user–developer interaction. In their process model, applied also in
a further case (Robey & Newman, 1996), they identified 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 Gersick’s 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 fulfil
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 fiefdoms where
barons (and baronesses) are in charge of their own, independent realms, and vigor-
ously defend their territories (Noble & Newman, 1993; Heiskanen, Newman & Saar-
inen, 1998). Each participant is an individual willing and capable of independent
behaviour. It would seem that universities are fundamentally different from business
organisations in their decision making processes. Consequently the standard IS devel-
opment 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). Pro-
fessors 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 indi-
viduals 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 regu-
lations that are thought to ensure the predictability of the behaviour of the organis-
ation and to lead to efficiency and effectiveness. In universities, the professional
bureaucracy has a “parallel” organisation for the routine administration (Mintzberg,
1979, p. 361). The focus of our article is in the interactions of this routine adminis-
tration organisation and commercial software vendors. Although the routine adminis-
tration organisation should be a “normal” service organisation to the 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 briefly 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 conflicts 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 first 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 stra-
tegic 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 identifiable stakeholders like con-
sumers who have preferences, and the organisation must change with its environ-
ment.
The third model is interpretive strategy which is based on the idea that the assump-
tions 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 refer-
ence that allow the organisation and its environment to be understood by its stake-
holders. The interpretive strategy model is focused on the desired relationship 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 com-
petitors to achieve their organisation’s goals. In adaptive strategy, the organisation
and its parts change, proactively or reactively, in order to be aligned with con-
sumer preferences. In interpretative strategy, organisational representatives convey
meanings that are intended to motivate stakeholders in ways that favour the organ-
isation.
3. Method
3.1. Situating the authors as practitioners and researchers
The main point of view of this paper is that of the first author in his role as the
Chief Information Systems Officer of the University. He finished 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 first 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 University’s
administrative information systems. The offer was accepted, leading to his appoint-
ment as the Chief Information Systems Officer of the University and the establish-
ment of the administrative EDP Office in the autumn of 1984.
The third author has also been involved in the development of the 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 1985–1987. 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 devel-
opment, 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 first author in 1993. His special experience in longitudinal research
has close parallels with the first author’s study of university systems over a period
of more than a decade. The second author has published several studies of system
development projects covering 5–15 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 reflective 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 Reflection-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 reflective 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.

The structure of the process is described by Scho¨n (1983, pp. 129–132) 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 defin-
ing its boundaries and components, and design an intervention. The situation is
uncertain, and there is a problem in finding 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 prac-
titioners 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. 273–274), 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; first 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, reflecting 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
reflective 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 confirmed with other sources. The Reflective Practitioner approach does not
guarantee any universal advantage over more traditional research approaches. Normal

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 exer-
cised when deciding which kind of data gathering methods are possible. In many
occasions the first author has felt that it is unethical to interview his co-workers for
research purposes only. These interviews could have imposed a flavour of the author
taking undue advantage of his dual role, aggrandising himself improperly, and intimi-
dating the interviewees by giving a “scientific” backing to his practical acts. This
has been especially true when the author in his practitioner’s 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 practitioner’s role. Observing the
behaviour of the co-workers only in order to fulfil 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 Newman–Robey social process model in its basic
form. For the client–vendor issues, our idea is to modify the Newman–Robey model
by replacing the acceptance–equivocation–rejection classification with another classi-
fication that is better suited to the analysis of the relationship between the client and
the (commercial) vendors. This latter classification is the market–hybrid–hierarchy
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, rep-
resent development work that does not change significantly 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 significant event (or an encounter, in the par-
lance of the social process model). In the next section we present our three cases
as narratives that are later, in Section 4.5, “condensed” in the model form.
4. Three cases of information systems development
The Finnish State regulates state-funded information system services. Since 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

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
firms 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 finally they were in real use,
they did not pose any serious problems to management, and the users appeared to
be at least moderately satisfied with them, according to user information satisfac-
tion surveys.
The first system history (the student records) is described in greater detail, based
on the dissertation work of the first author (Heiskanen, 1994). The other two
(personnel and accounting) mainly serve as material that supplement the first case
by presenting such features that were not present in the first 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 five software vendors in the histories below. Three of them have agreed
to participate in our research and allowed us to use their real names: KT-Tietokeskus,
the State Computing Centre, and CCC Software Professionals. The other 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 firm by 1995 when the current research
project began. However, key information concerning its behaviour was secured from
other sources. Beta was a “fill-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 Office of the
University, headed by the first author throughout the study period. One of the major
features of the late 1980s was the tight financial situation of the EDP Office 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 precipi-
tated 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 first 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).

The large increase in incoming data caused by the syllabus reform made it neces-
sary to revise the software and file structures. More hardware capacity would be
needed. The organisational data flows could not be radically changed which meant
that data had to be sent from the departments on paper to be registered in the Actu-
ary’s Office, a unit in the University’s Central Administration dedicated to register
maintenance and statistics production about students and personnel. The software,
to be used for 2–3 years, could be modified 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 minic-
omputer.
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 University’s
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 ser-
vices. 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 University’s Burroughs mainframe for running the student
records for several more years.
Consequently, to fit the new circumstances, the old software could only be modi-
fied. The system remained batch oriented with add-on files for on-line terminal data
entry and inquiries. Recourse to the maintenance of the old software was a disap-
pointment to the first author and was one of the reasons for the move to the Joen-
suu University.
The problems with the student records grew during the early 1980s, reaching 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 Actuary’s Office. Some credits were unsent, lead-
ing 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 Actuary’s Office 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 Actuary’s Office to persuade teachers to correct erroneous data led to frus-
tration on both sides.
It was clear to the first author in 1984 during his appointment to Chief Information
Systems Officer that a complete renovation was necessary. An important pre-requisite
for this renovation was sufficient 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

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 data-
flows on paper and record the credit data at their source.
The formative years of the student record system were from 1986 to 1990. Several
organisational actors played key roles during these years. As already discussed, the
Actuary’s Office, headed by the Actuary, was responsible for the maintenance of the
student record. The EDP Office was in charge of the software development for the
student records from the early 1980s. It was also responsible for managing the devel-
opment project, writing specifications 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 first author. The Director
of Administration was the leader of the Administration Offices of the University,
and the manager of the first author. Four persons acted in this capacity in 1986–
1990. The first of them retired in 1986. After that, the Head of the General Section,
subordinate to the Director of Administration, was a deputy Director of Adminis-
tration for several months. The third Director of Administration, nominated from 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 qualifications for the job.
All these changes were seen by the first author as creating a difficult working
environment, especially should a crisis occur.
Some of the work-force were recruited from an outside software house, 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 procure-
ment.
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 first author came to learn (Heiskanen, 1994).
First, the Actuary’s Office considered itself as the sole maintainer of the centralised
student record and resisted direct departmental updating. The Actuary’s Office put
it in a memo in December 1987:
According to the point of view of the Actuary’s Office the direct updating of the
files of the centralised Student Records cannot be the business of departments and
faculties. Currently the whole Register is the responsibility of the Actuary’s
Office. If technical maintenance of the centralised Register is transferred to facul-

ties, then the Actuary’s Office cannot have complete responsibility. Instead, the
departments and faculties can make transaction files 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 file, and be obtainable from there,
and why? ... As detailed centralised registration does not improve the basic func-
tions of the University, i.e. teaching and research, in any way, it should be aban-
doned at once. In the planned form it will unnecessarily increase the work-load
of every teacher, ruin old well-functioning systems (the particular department had
a card-file 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 difficult. 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 benefits 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 depart-
ment office 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 develop-
ment process to see how the events unfolded. The first author, as the newly appointed

Chief Information Systems Officer, soon realised that the University’s 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
personnel’s good record of achievements and their strong academic background. The
planned purchase of software was negotiated with State Officials and the University
obtained permission to use CCC’s 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 Actuary’s Office 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 pro-
cessing. This project began in the Technical Section of the Offices of the Rector,
but soon the responsibility was taken over by the EDP Office. The experimental
project, although it suffered from some staff resignations, produced (during the spring
of 1987) the specifications of a PC-based system for student data processing
decentralised in departments.
The situation became problematic for the EDP Office in the summer and early
autumn of 1987 because the Actuary’s Office 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 Office. One was to cancel the devel-
opment of the PC software and direct the resources of the project to change the view
of the Actuary’s Office by establishing sufficient 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 Actuary’s Office 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 Office, and not the approval of other actors. Consequently, during the early
autumn of 1987 the EDP Office began to make it a real alternative for the depart-
ment level.
The commitment of the EDP Office to the development of the PC software had
several stages that probed the “back-talk” of the internal and external actors towards
the steps taken by the Office. The specifications had been written in the spring of
1987 and a bidding competition was started in the summer of that year. The main
competitors were software houses Alpha, CCC, and the State Computing Centre. The
first tenders of all these bidders had approximately the same price, but the planned

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 first part of the software would be delivered
with limited functionality—a prototype—that later could be developed into a full
system. The contract was eventually won by CCC.
The Actuary’s Office reconsidered its view about the suitability and security of
the centralised student records to be used directly by the departments and gave per-
mission for departments to directly use the centralised students records in May of
1988. This reconsideration was developed gradually in 1987 and early 1988 during
the work of two consecutive committees. The task of the first one was to define 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 com-
mittee (the “register committee”), established by the Senate in early September 1987,
was charged with the task of planning how to decentralise the credit record data
processing. The first author was not a member of the first 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 Actuary’s
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 possi-
bilities for decentralisation as a means of solving the data problems.
In a way, the first author was fighting on two fronts in the autumn of 1987. First,
within the University there were many and strongly differing views of the 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 first developing the prototype in the autumn of 1987, the EDP Office
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 Office did not have enough money to consider the simultaneous
development of the student record system and the personnel system (see the follow-
ing subsection). So a low price was very important. The first author had a strong
belief that funding could be secured during 1988, but that demanded positive and
concrete signs of progress. On CCC’s side, lowering the price of the first 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
University’s need for a low price for the first stage of the work and the vendor’s
need to find a task for the analyst complemented each other, and a favourable agree-
ment over the price could quite rapidly be achieved between the first author and 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 first part of it was realistic is difficult to decide, because it was anticipated

that the specification 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 fixed-price deliveries of pieces of software into contract pro-
grammer hiring. It appeared that changing the maintenance and further development
of software from the vendor to the EDP Office would be the most economic option,
because the personnel of the EDP Office, acting as gatekeepers (Heiskanen & Simila¨,
1992) between users and outside developers, considered it easier to develop 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 first 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 Actuary’s Office. The departments were made respon-
sible 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 com-
petitive bidding in November 1986. The EDP Office was in charge when the specifi-
cations were prepared prior to the bidding competition, and it represented the 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 specified 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 client’s 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 vendor’s disillusionment with the
project, reassignment of project personnel, and finally to project failure from its point
of view.
Although Alpha had delivered the core part of the software successfully in 1987

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 Office 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 CCC’s 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 CCC’s 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 person-
nel system continued with CCC until 1997 when it was replaced with a new system.
The low price of the first software delivery was essential for the University,
because it needed the approval or positive statements for its actions from the 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 adminis-
tration, but the adoption of these would have required changes in the ways the Uni-
versity operated in personnel administration. Moreover, the University had chosen
a specific database management system for student records, and wanted the 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 straight-
forward 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 com-
petition to develop an accounting package for all state bureaux. In the beginning of
1992, KT-Tietokeskus purchased the accounting systems business from the 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 con-
tracting, especially concerning how the parties are able to control each other, i.e.

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 per-
spective. For example, in developing the PC version of the student records software
and the first part of the personnel software, the University had to act on a short-
term perspective and choose the lowest price option.
The price level control mechanism can also be used in a reverse sense by 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 exagger-
ated manner, is its effect on future bidding. The vendor may profile itself as too
expensive to be included in future bidding or too cheap to bid profitably.
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 empha-
sis on competition leading to reduced price of the work and a need for creating long-
standing and mutually beneficial relationships between users and developers. An
aspiration towards a long-range relationship with the client may at times conflict
with the price level control mechanism in the short-term. The vendor’s aspiration
towards a long-term relationship with the client is, in general, preferable from both
the vendor’s and the client’s viewpoints. This aspiration may be realised in ways
other than by contractual price level control. For example, a vendor may, by
assigning highly qualified 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 certified quality management
and assurance system. For example, the ISO 9000 certificate is conditional and it is
awarded for a limited period. If the client finds the vendor’s performance unaccept-
able, a powerful means for improvement is a complaint to the standardisation organis-
ation that awards (and withdraws) the certificates.
The development of a certified quality assurance scheme such as ISO 9000 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
maturity (Simila¨, Kuvaja & Krzanik, 1995). In the long term, this is a remarkable
influence mechanism that has a lasting effect from the vendor’s point of view.
4.5. The models of development trajectories
The long and eventful histories of our cases can be condensed using the method
described in Section 3. We have tabulated, as the first part of our model, the develop-
ment encounters in Tables 1 and 2 for the student records, in Table 3 for the personnel
system, and in Table 4 for the accounting system. The second part of our model

Table 1
The internal encounters of the student records development
Enc. No Date Encounter description
1 1/1981 The first author is hired as a special analyst to the Administration
Offices of the University of Helsinki
2 2/1982 The first author moves to the University of Joensuu, remaining also
as a part-time worker in his previous position
3 8/1984 The first author is re-hired by the University of Helsinki, now as
the Chief Information Systems Officer
4 Spring 1987 An encounter that lead to bifurcation: on the one hand the
Actuary’s Office takes, finally, an active role in the development of
the VAX version, but, on the other hand, forcefully resists the
decentralisation of student records data entry
5 3/1987 The Actuary’s Office takes an active role in software development
6 12/1987 The Actuary’s Office writes a memorandum expressing its resisting
view of the decentralisation
7 5/1988 The Actuary’s Office finally approves the decentralised data entry
to the student records
Table 2
The external encounters of the student records development
1 1985/9 Preliminary specifications for the student records system prepared
2 1985/9 Informal contract between the University and CCC for refining the
specifications
3 1985/11 Contract between the University and CCC concerning the core part
of VAX-software
4 1986/6 An experimental project for developing departmental data
processing begins. The idea of the PC version emerges within this
project
5 1987/6 The specifications of the PC version completed within the
University. Request for proposals of development mailed to
vendors
6 1987/10 CCC chosen to be the vendor of the PC software
7 1990/5 The University takes over the development (perfective
maintenance) of both pieces of student records software
presents the “shapes” or trajectories of the process by connecting the encounters
with the episodes. They are in Figs. 1–4, including also the respective encounter
numbers. With these two sources, we believe that the reader is able to easily under-
stand the dynamics of the processes. The figures also contain brief descriptions of 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

Table 3
The encounters of personnel systems development
1 1986/11 Specifications for the personnel system prepared within the
University and a request for proposals is mailed to vendors
2 1987/2–6 Alpha wins the contract, development begins but the final contract
must be approved by the State officials. Finally the contract is
signed between the University and Alpha
3 1988/6 The University begins to change the software vendor to CCC
because Alpha is not able to deliver the reporting package
Table 4
The encounters of the purchase of the accounting package
1 1991/6–8 The University asks for a tender from Tietovoima about the
delivery of the accounting package which has just been approved
by the State Officials. The tender is accepted immediately. The
contract of delivery is signed and the adoption project begins,
leading to the use of the software in February 1992
Fig. 1. The development trajectory of the student records system within the University.

Fig. 2. The development trajectory of the client–vendor relationships of the student records system.
Fig. 3. The development trajectory of the personnel systems.

Fig. 4. The development trajectory of the accounting system.
encounters as well as the ensuing episodes were identified and classified by the first
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 client’s decisions concerning
the relationships with the vendors, as well as negotiations with the internal actors.
The identity of the encounters and episodes was confirmed by the third author on
CCC’s 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 classifications and
interpretations.
The encounter/episode classification rules were quite simple, but required careful
considerations. If the software developers were employed by the University, it was
classified as a hierarchy. The category “market” was chosen in the following cases.
First, when the University’s 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.

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-reflective studies, intellectual curiosity
toward one’s 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 final 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 final research plan. This change occurred when the first
author reflected 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 first 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 first 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 under-
stood 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 leader’s 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 first 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 Actuary’s Office. 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-

sity when the development process began. The system was adapted first to the hard-
ware change, and later it was adapted to the work-flows of personnel data processing.
The accounting system purchase is an example of linear strategy, a straightforward
adoption task to be performed. These two cases represent a quite normal 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 difficult.
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 significance of alliances with specific 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
fulfilling successful contracts at an early stage.
Additionally, the theoretical lens of Williamson (1991) acts as a powerful explana-
tory vehicle in the analysis of the client–vendor relationship. It seems that Trans-
action Cost Theory gives us intellectual machinery to explain our experience in rela-
tively simple terms. For example, in the initial purchase of the student record system,
the goal of efficiency and lack of internal resources seemed to dominate. 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 field,
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 imma-
ture.
By using longitudinal data in our study, we observed how the procurement stra-
tegies developed over time until they reached relatively stable conditions. It is these
stable conditions which our study revealed which give more support to the Procure-
ment Principle. These conditions would be difficult to capture using “snap-shot” type
survey data (cf. Saarinen & Vepsa¨laïnen, 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 cir-
cumstances 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.

They found that different views complement each other. We follow suit. The New-
man and Robey (1992) classification acceptance–equivocation–rejection has over-
tones of political behaviour, and we supplement this view with the market–hybrid–
hierarchy classification. It is possible that in some situations political considerations
will dominate, imposing additional “costs” in the form of, say, conflicts between
stakeholders. In these kinds of analyses, Orlikowski and Hofman’s (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 difficult to find for reasons like lack of resources, different development projects
interfering with each other, or because of conflicts between University actors. All
these issues made the situations difficult 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 Actuary’s Office,
on the one hand, approved the development of the centralised system (encounter 5)
and participated actively in this work. On the other hand, its equivocation towards
the decentralisation turned into outright rejection and forceful resistance (encounter
6). The resistance was eventually abandoned, because the register committee sug-
gested decentralisation, which was approved by the University Senate. Lack of
money also necessitated improvisational acts in the autumn of 1987. The free-of-
charge delivery of the first part of the personnel systems was one example and 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 straightfor-
ward 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 first author’s 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-

Table 5
Summary of the case information systems
Student records Personnel Accounting
Type of system Major system, tailored Originally marginal Major system, packaged
software development system, growing to a software purchase
major one, tailored
software development
Organisational Severe conflicts between Poor data quality because Poor service level
situation in the key actors, anarchical the system is not
phases of the procedures, poor data integrated to any work
development quality process, lack of
process organisational host
because the University did
not have a personnel
department
Motivation for the Out of the anarchy Software renewal because Adoption of an on-line
development through decentralisation of hardware change, system
process as seen by integration of the system
the first author to personnel work process
Development Interpretive, incremental Adaptive, phased Linear, straightforward
strategy decentralisation process, development, first basic adoption process
improvisation in the system replaced, then according to the vendor’s
formative phase integrated to work-flow delivery scheme
Dominant image of Holographic Organism Machine bureaucracy
the organisation
held by the first
author
Relationships From acceptance to From acceptance to Acceptance throughout the
changes between equivocation and rejection equivocation and back to whole process
internal developers (major conflict), and then acceptance
and users back to acceptance
Relationships From hierarchy via market From hierarchy via market Market
changes between and hybrid back to to hybrid
the client and the hierarchy
vendor(s)
Amount of state Modest Tight, pronouncements of Total control, because the
control of software several bodies were State chose the vendor
purchase required

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 organis-
ation; (3) improving the organisational learning; and (4) applying the principle of
minimum critical specification, 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 first 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 identified 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 sys-
tems. 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 fit 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 decentra-
lisation strategy.
The limitations involved in this kind of research are clear. In addition to the ones
discussed above concerning the reflective practitioner, we present only three cases
as a basis for our findings—a relatively small sample. Other factors which limit the
general usefulness of the findings include the university setting in which the study

took place and the location. As Saarinen and Vepsa¨laïnen (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 difficult 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 pro-
cess 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). Manufacturer–supplier relationships in Japan and the concept of relation-specific
skill. Journal of the Japanese and International Economics, 3, 1–30.
Bakos, J. Y., & Brynjolfsson, E. (1993). Information technology, incentives and the optimal number of
suppliers. Journal of Management Information Systems, 10, 37–53.
Beath, C. M. (1983). Strategies for managing MIS projects: a transaction cost approach. In Proceedings
of the fourth international conference on information systems (pp. 133–147). 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. 415–427). 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. 257–277). San Fran-
cisco: 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 fifteenth international conference on information
systems (pp. 91-98). Vancouver, Canada.
Gersick, C. J. G. (1991). Revolutionary change theories: a multilevel exploration of the punctuated equilib-
rium paradigm. Academy of Management Review, 16, 10–36.
Grudin, J. (1991). Interactive systems: bridging the gaps between developers and users. Computer, April,
59–69.
Gurbaxani, V., & Whang, S. (1991). The impact of information systems on organizations and markets.
Communications of the ACM, 34, 59–72.
Hardy, C. (1991). Configuration and strategy making in universities, broadening the scope. Journal of
Higher Education, 62 (4), 363–393.
Heiskanen, A. (1993). Organizational metaphors and information systems practice: a case example of

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 organi-
zational aspects” (pp. 399-417) Noorwijkerhout, 17–19 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 reflection-in-action. Doctoral Dissertation
at the University of Tampere. The University of Helsinki.
Heiskanen, A. (1995). Reflecting over a practice, framing issues for scholar understanding. Information
Technology and People, 8, 3–18.
Heiskanen, A., & Newman, M. (1997). Bridging the gap between information systems research and prac-
tice: the reflective practitioner as a researcher. In K. Kumar, & J. I. DeGross, Proceedings of the
eighteenth international conference on information systems (pp. 121–131). Atlanta, GA, 15–17
December.
Heiskanen, A., Newman, M., & Saarinen, V. (1998). Innovations in fiefdoms: 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. 455–469). Helsinki, Finland, 10–13 December.
Heiskanen, A., & Simila¨, J. (1992). Gatekeepers in the action structure of software contracting: a case
study of the evolution of user–developer relationships. ACM Computer Personnel, 14, 30–44.
Hodgkinson, C. (1983). The philosophy of leadership. New York: St Martin’s Press.
Kirsch, L. J. (1997). The management of complex tasks in organizations: controlling the systems develop-
ment process. Organization Science, 7 (1), 1–21.
Kling, R. (1987). Defining the boundaries of computing across complex organizations. In R. J. Boland, &
R. A. Hirschheim, Critical issues in information systems research (pp. 307–362). 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: findings and critique. Accounting, Management, and Information Tech-
nology, 5 (3/4), 203–244.
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, 393–410.
Markus, M. L., & Robey, D. (1988). Information technology and organizational change: causal structure
in theory and research. Management Science, 34, 583–598.
McFarlan, F. W., & Nolan, R. L. (1995). How to manage an IT outsourcing alliance. Sloan Management
Review, 36, 9–23.
McWilliams, A., & Gray, S. R. (1995). Understanding quasi-integration. The Journal of Business Stra-
tegies, 12, 69–85.
Mintzberg, H. (1979). The structuring of organizations, a synthesis of the research. Englewood Cliffs,
NJ: Prentice-Hall.
Mintzberg, H. (1983). Structure in fives: designing effective organizations. Englewood Cliffs, NJ: Pren-
tice-Hall.
Morgan, G. (1986). Images of organization. Great Brittain: Sage Publications.
Newman, M., & Robey, D. (1992). A social process model of user–analyst relationships. MIS Quarterly,
June, 249–266.
Noble, F., & Newman, M. (1993). Integrated systems, autonomous departments: organizational invalidity
and system change in a university. Journal of Management Studies, 30 (2), 195–219.
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, 833–848.

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. 295–336). Greenwich, CT: JAI
Press.
Raelin, J. A. (1997). A model of work-based learning. Organization Science, 8 (6), 563–578.
Richmond, W. B., Seidmann, A., & Whinston, A. B. (1992). Incomplete contracting issues in information
systems development outsourcing. Decision Support Systems, 8, 459–477.
Robey, D., & Newman, M. (1996). Sequential patterns in information systems development: an application
of a social process model. ACM Transactions of Information Systems, 14, 30–63.
Saarinen, T., & Vepsa¨la¨inen, A. P. J. (1994). Procurement strategies for information systems. Journal of
Management Information Systems, 11, 187–208.
Sabherwal, R., & Robey, D. (1995). Reconciling variance and process strategies for studying information
systems development. Information Systems Research, 6, 303–327.
Scho¨n, D. (1983). The reﬂective practitioner, how professionals think in action. New York: Basic Books.
Simila¨, J., Kuvaja, P., & Krzanik, L. (1995). BOOTSTRAP: a software process assessment and improve-
ment methodology. International Journal of Software Engineering and Knowledge Engineering, 5,
559–584.
Weick, K. (1976). Educational establishments as loosely-coupled systems. Administrative Science Quar-
terly, 21, 1–11.
Whang, S. (1992). Contracting for software development. Management Science, 38, 307–324.
Williamson, O. E. (1991). Comparative economic organization: the analysis of discrete structural alterna-
tives. Administrative Science Quarterly, 36, 269–296.

The social dynamics of software development

Recommended

Recommended

More Related Content

Similar to The social dynamics of software development

Similar to The social dynamics of software development (20)

More from aliaalistartup

More from aliaalistartup (20)

Recently uploaded

Recently uploaded (20)

The social dynamics of software development