How organizations adopt information system ... - Semantic Scholar

3 downloads 11781 Views 165KB Size Report
information technology (IT) for administrative operations and critical business .... the administrative ISPI category, we distinguish between management ...
European Journal of Information Systems (2004) 13, 35–51 & 2004 Palgrave Macmillan Ltd. All rights reserved 0960-085X/04 $25.00 www.palgrave-journals.com/ejis

How organizations adopt information system process innovations: a longitudinal analysis Erja Mustonen-Ollila1 and Kalle Lyytinen2 1

Department of Information Technology, Lappeenranta University of Technology, Lappeenranta, Finland; 2Department of Information Systems, Case Western Reserve University, The Weatherhead School of Management, Cleveland, OH, USA Correspondence: Erja Mustonen-Ollila, Department of Information Technology, Lappeenranta University of Technology, PO Box 20, FIN53851 Lappeenranta, Finland Tel: +358-5-621 2857, E-mail: [email protected]

Abstract This paper describes how three organizations adopted information system (IS) process innovations (ISPI) using a sample of over 200 adoptions over a period of four decades. Four distinct periods that roughly follow Friedman’s and Cornford’s categorization of IS development eras are analysed in terms of the rate and distribution of ISPI adoptions. These eras include early computing (1954–1965), mainframe (1965–1983), office computing (1983–1991), and distributed applications (1991–1997). We distinguish the following four types of ISPIs: base line technologies (T); tools (TO); description methods (D); and managerial innovations (M). We analyse for each era the rate of adopting different types of ISPIs, identify who made adoption decisions for those ISPI types and determine whether these ISPIs originated internally or externally. Within the three organizations, the types and rates of ISPI adoptions varied significantly. These variations can be attributed to learning mechanisms, the influence of legacy platforms and differences in the boundary spanning activities. With the exception of base line technologies, project managers were the most prominent decision-maker group, suggesting a situated ISPI adoption process. In most ISPI adoptions, internal search and experiments were the main source of innovation. The variation in ISPI adoptions can thus be partly explained by development environments, the types of IS involved and attention bias. European Journal of Information Systems (2004) 13, 35–51. doi:10.1057/ palgrave.ejis.3000467 Keywords: Empirical research; IS development methods and tools; adoption decisions; IS process-innovations

Introduction

Received: 12 October 2001 Revised: 13 June 2002 2nd Revision: 12 April 2003 Accepted: 3 June 2003

The ability to innovate both in information system (IS) products and processes has become an important contributor to organizational wealth. Consequently, organizations have increasingly invested in deploying information technology (IT) for administrative operations and critical business processes and in their ability to deliver those IT services (Swanson, 1994). The latter types of innovations, here called information system process innovations (ISPI), have become increasingly critical factors in organizational change. They improve the quality and productivity of information system development processes by introducing new ways of developing, implementing, and maintaining information systems (Swanson, 1994). Despite huge investments in ISPI activities in the past, these innovations are not necessarily widely adopted (Fitzgerald, 1997), leading many scholars to ask: how are ISPIs introduced and successfully adopted? As a result, ISPI adoption and diffusion research has been steadily increasing in the IS field (Fichman, 1992, 2000; Swanson, 1994; Prescott & Conger,

36

Analysis of ISPI adoption

1995; Wynekoop & Russo, 1997). At the moment, we know a great deal about the organizational, behavioural and individual factors and processes that can inhibit or foster adoption of ISPIs (Fichman, 1992, 2000; Fichman & Kemerer, 1993, 1997; Prescott & Conger, 1995; Sauer & Lau, 1997; Wynekoop & Russo, 1997). These studies have investigated the adoption of system development methods (Sauer & Lau, 1997; Wynekoop & Russo, 1997), software engineering tools (Fichman & Kemerer, 1993; Premkumar & Potter, 1995), new forms of IT functionality such as database management systems (Nilakanta & Scamell, 1990), and novel managerial practices (Fichman & Kemerer 1994; Swanson, 1994). At the same time, ISPI adoptions have been studied in terms of innovation types and the nature of the adoption process (Huff & Munro, 1985; Kozar, 1989; Nilakanta & Scamell, 1990; Premkumar & Potter, 1995; Sauer & Lau, 1997). Most of these studies have focused on single ISPI adoptions in a single organization at a certain point in time (Sauer & Lau, 1997) or have even explored a single adoption event in more detail (Fitzgerald, 1997; Wynekoop & Russo, 1997) using cross-sectional research designs. Not surprisingly, the results are often confounding and adequate theoretical explanations have yet to emerge to explain critical facets of ISPI adoption. There is little qualitative research on the origins of ISPIs and how organizations become aware of them. In particular, little is known about the types of ISPIs that have been adopted over time, how their proportions have changed across periods and organizations, and what factors, such as changes in the computing environment of user needs, explain such variations. In order to develop a more robust understanding of ISPI adoption and to identify commonalities across various adoptions, several types of ISPIs must be examined over a sustained duree´ within multiple organizations. Although demanding in terms of data collection and analysis, such investigations can considerably improve our understanding of ISPI adoptions and help us identify how organizational contingencies influence adoption. This paper will address some of these concerns. We investigate ISPI adoptions in three organizations by carrying out a longitudinal study that includes a detailed analysis of all 263 identified ISPI adoptions in three organizations over four decades. Our goal is to investigate in detail these ISPI adoptions and shed light on how they were influenced by differences in innovation needs (time periods) and contexts (organizational context). We explore strategies that organizations deployed while learning about ISPIs, to what extent their adoption was shaped by different organizational contexts and how changes in the computing capability and environment (as indicated by different eras of computing) affected the rate and the type of ISPI adoptions. Four conclusions emerge from our study. First, the ISPI adoption rate and scope have varied considerably across different computing generations and across organizations. Such variations can be explained partly by

European Journal of Information Systems

Erja Mustonen-Ollila and Kalle Lyytinen

differences in innovation needs (pull) over time and partly by contextual factors in the adopting organization. Second, a great majority of ISPI adoptions were outcomes of internal learning. Third, most ISPI adoptions took place at the project management level, thus suggesting a situated adoption strategy. Fourth, during times of prosperity (slack) organizations introduced more ISPIs. The rest of this paper is organized as follows. First, theoretical underpinnings are introduced featuring the concept of ISPI, the type of ISPI, and the critical dimensions of ISPI adoption, such as origin, mode of knowledge transfer, adoption scope, and decision rights. In the next section, we briefly explain the research goals and research setting for a multiple case study reported here. In the subsequent section, we communicate our main research findings as to how organizations adopted different types of ISPIs over a period of four decades. Finally, we discuss the implications of our findings for managing ISPIs.

Theoretical underpinnings ISPI and types of ISPIs For our research purposes, an ISPI is defined as any new way of developing, implementing, and maintaining information systems in an organizational context (Swanson, 1994). ISPIs are adopted by organizations because organizations expect them to improve the quality and productivity of their IS development processes. After Rogers (1995), we define an ISPI adoption as a decision to use an ISPI within a given organizational context (Sauer & Lau, 1997). In the context of our paper, we consider this to mean that a specific ISPI is adopted for use in a specific IS development project. This decision implies that there is a recorded intention to use the innovation in this project and there is a way to record the use. This does not necessarily (or often) imply that the same ISPI is adopted later for another project or that the observed (first) adoption necessarily results over time in the infusion of that innovation within the organization, which leads to the institutionalization of the ISPI (Rogers, 1995). ISPIs result mainly from experiments that seek to harness the expanding computing potential (Lyytinen & Rose, 2003). This technology potential is interpreted and filtered within technical and managerial discourses engaged with how new ISPIs can be invented, what they are good for, and how one can effectively use them. A case in point is the invention of database management systems in the late 1970s and early 1980s. This change radically expanded the design ‘space’ related to data retrieval and access functionality (integration, data independence), which soon resulted in tasks to manage enterprise wide data resources (Copeland & McKenney, 1988; Friedman & Cornford, 1989), new notations (E-R diagrams, enterprise wide data modelling), new tools (data dictionaries, E-R modelling tools), and new managerial processes (centralized data administration, data analysis policies). Therefore, ISPIs are closely inter-related

Analysis of ISPI adoption

on many levels: one innovative activity can trigger other types of innovations in the spirit of socio-technical design. For example, an introduction of a CASE tool may result in changes in the notations or organizational principles of software engineering (Fichman & Kemerer, 1993; Swanson, 1994; Tolvanen, 1998). Our ISPI definition is relatively broad and covers a wide range of innovative activity within IS development. First, an ISPI can embrace changes in the technologies that offer new computing functionality or novel non-functional features (like portability, security) for the delivered IS. Typical technological innovations include adoptions of programming languages or operating systems. ISPIs can also include administrative innovations, such as the deployment of project management methods, the introduction of participative approaches to guiding development interactions, or the contracting of development work outside. In Swanson’s terminology, ISPIs thus cover both technological (Type Ia) as well as administrative innovations (Type Ib) (Swanson, 1994). Both administrative and technological innovations can be further classified into two sub-categories (Figure 1). In the administrative ISPI category, we distinguish between management innovations (M) and description innovations (D). Within the technological innovations, we separate between tool innovations (TO) and core technology innovations (T). The motivation for such a classification is that most of the IS development literature clearly distinguishes between organizational innovations (like project management principles, programming teams, extreme programming) and notational innovations (like the development of unified modelling language (UML), method engineering and so forth). Some ISPIs specifically address the need for software engineering task improvement or advance core technologies including programming languages or database management systems. Introducing such innovations into ISPI adoption research is important if we want to integrate empirical ISPI research with the design and developmental IS research. The distinctions between ISPI types clarify to what extent different or similar factors explain the adoption of different classes of ISPIs. Management innovations (M) embrace changes in rules and administrative processes that improve, control, manage, and coordinate development activities. Examples of managerial innovations are project management

ISPI

Administrative Innovations

Management Innovations (M)

Figure 1

Description Innovations (D)

ISPI categories.

Technological Innovations

Tool Innovations (TO)

Core Technology Innovations (T)

Erja Mustonen-Ollila and Kalle Lyytinen

37

guidelines or organizational arrangements, such as chief programmer teams (Swanson, 1994). Description innovations (D) include changes in notational systems and standards, which are used to describe and communicate development products or processes between different stakeholders. Such innovations include the adoption of standardized modelling techniques like Data Flow Diagrams or UML. Some ISPIs – especially within description and managerial innovations – have long lifespans. Cases in point are the more abstract concepts of decomposition and structured design or the idea object orientation (Fichman & Kemerer, 1993). Such ISPIs create cumulative paths within organizations that over time solicit incremental flows of complementary innovations, which centre on a focal ‘starting’ ISPI. Some ISPIs can thereby induce disruptive innovations into ISD processes as they fundamentally change the nature of the problems and design spaces that they impose (Lyytinen & Rose, 2003). Tool innovations (TO) include capital-intensive software assets such as application generators, CASE tools, documentation tools, data dictionaries, etc. They may also include mundane technologies that range from desktop publishing software, groupware applications to indexing software. Core technologies (T) consist of improvements in technical platforms that are critical to delivering the IS products and include, among others, programming languages, database management systems, telecommunication software, middleware frameworks, etc. These ISPIs often have a short life expectancy and thus suggest a continued pursuit of innovation.

Knowledge transfer, scope, and decision rights From the viewpoint of organizational learning, an ISPI adoption takes place when an adoption unit first learns about an ISPI and, second, makes a decision about its use or non-use based on the available knowledge. Therefore, understanding the dynamics of ISPI-related learning is fundamental to their management. The definition of ISPI adoption raises three questions that need to be addressed in a study of ISPI adoption: (1) what is the origin of the ISPI? (2) what is the scope of the assumed ISPI adoption?, and (3) who makes the decision concerning the ISPI adoptions? How are ISPIs created and communicated? An organizational learning perspective directs our attention to the sources of knowledge, both external and internal (Huber, 1991), that trigger and enable ISPI adoption. In practice, ISPIs can be grafted externally or developed internally in an organization. Studies on knowledge transfer related to ISPI show that the scope and intensity of external searches positively affect ISPI adoptions (Nilakanta & Scamell, 1990). At the same time, other studies show that organizations mostly innovate independently, especially in terms of description innovations and managerial innovations (Sauer & Lau, 1997; Wynekoop & Russo, 1997).

European Journal of Information Systems

38

Analysis of ISPI adoption

In the early phases of the general ISPI diffusion, external knowledge is the only means by which most organizations learn the ISPI because internal experience is unavailable. Among the benefits of external knowledge are thus keeping pace with technological change, following management fashions (Newell et al., 2000), and controlling more effectively the downside risks of being outdated in systems development capability. External knowledge may be acquired by modelling other organizations (vicarious learning), by importing knowledge components directly (grafting), or by depending on intermediaries (Huber, 1991; Attewell, 1992; Fleck, 1994). The origins, contents, and formats of external knowledge for external ISPI adoptions are accordingly diverse and include published reports or confidential documents. They also cover Internet sources, commercial databases, and the knowledge possessed by vendors and consultants (Attewell, 1992). The majority of ISPI adoption research (Attewell, 1992; Fichman & Kemerer 1994), therefore, assumes that ISPI knowledge is transferred from outside and subsequently analyses barriers that can stall such transfers. As external learning originates in the experience of others, it may not be relevant or easily transferable to another context. Moreover, the validity of external knowledge can be difficult to determine at the outset, which introduces the additional risk of transfer. Therefore, in many cases, external ISPIs are adopted based on rhetorical power, symbolic value, or low cost. The cost of external learning can range from small investments in published reports about new technologies to large investments in consulting expertise. Regardless of cost, externally acquired knowledge rarely brings true competitive advantage to a company, unless it can be absorbed very quickly or bundled in truly different ways since similar knowledge is readily available. Since most of the earlier ISPI adoption research presumes that organizations choose an established ISPI ‘package’ from outside (Attewell, 1992), the possibility of a novel internal ISPI adoption does not enter into these analyses. By such internal innovation, we mean the development of ISPI-related knowledge and skills that are not dependent on or originating from external sources and that are primarily controlled by the adopting organization. In this sense, internal ISPIs combine and transform unique internal knowledge and skills garnered from a company’s own experience. In line with this concept, Fitzgerald (1997) shows how internal learning that occurs by garnering internal experience and formalizing it as ISPI (Heiskanen, 1994; Tolvanen, 1998; Ropponen, 1999) is preferred by many organizations. Internal learning produces offer superior capabilities, since such an ISPI use may be hard for other companies to imitate. Mechanisms of internal learning can range from informal communications among individuals to formal analyses of experience, experience factories, and postmortem audits of systems projects. The out-of-pocket cost of such knowledge is lower than that of external

European Journal of Information Systems

Erja Mustonen-Ollila and Kalle Lyytinen

sources, but the indirect cost of learning from experience may be greater due to internal tensions, power plays, and time demands. Yet, internal ISPIs can be ineffective forms of learning that result from inadequate boundary spanning and poor filtering of external knowledge due to a lack of incentives or limited access to intermediating organizations (Attewell, 1992).

What is the scope of ISPI adoption? ISPI adoptions influence the specific scope of technologies, skills, and routines that need to change as a result of adoption (Friedman & Cornford, 1989). Such a unit is called here an adoption population or an organizational unit. An important issue in researching ISPIs is to identify and delineate the boundaries of adoption populations and to understand to what extent these boundaries affect adoption dynamics in terms of the types of innovations adopted and the rate of adoption. Adoption populations may comprise a single formal organizational unit, several units or a half of a unit, if such a unit defines the scope of adoption decisions. A focal point in distinguishing an adoption population is the assumed scope of adopting an ISPI and knowing about it. An adoption population thus covers one or several physically separate work environments wherein developers interact. It has commonalities in terms of the core technologies used, management principles, and description techniques deployed and is normally engaged in shared lines of work. Who decides over the adoption of an ISPI? Any ISPI adoption study must identify those who actually make choices concerning changes in development practices. An ISPI decision-maker is thus defined as a formal unit in the sense that it possesses decision rights to change IS development. At the same time, they control some resources associated with those development practices. An ISPI decision-maker determines the actual set of adopters (projects, departments). Adopters here are either individual people in specific roles (project leader, member) or organizational units (project groups). In an adoption study, it is important to clarify to what extent the organization of the decision-making affects innovation in ISD environments and to identify the decision-makers for specific types of ISPIs. Three types of decision-makers will be distinguished: centralized, distributed, and situational Decision-makers are located at the company level, the department level, and the project level, respectively. When either the company or the business unit obtains the right to make decisions about an ISPI that affects the company, a centralized ISPI decision strategy is followed. When an IS department makes adoption decisions concerning ISPIs, a distributed decision strategy over ISPI adoptions is followed. The third level, the project level, implies that the ISPI decisions are carried out while developing the system. This level includes a broad variety of ISPI decision-maker roles, including the IS project

Analysis of ISPI adoption

39

Erja Mustonen-Ollila and Kalle Lyytinen

actions between computing systems and organizational agents, including customers and clients, suppliers, competitors, cooperators, representatives, and public bodies (Friedman & Cornford, 1989). This created a need to innovate with organizational development principles and processes (M innovations) and description techniques (D) that enable the analysis of new application domains.

steering group, the project manager, or an individual member of the project group. If a majority of ISPI decisions are made at the local level, the ISPI decisionmaking strategy is called situational. In most cases, organizations follow none of the ‘pure’ strategies, but rather choose a mix of strategies that is influenced by the type of innovation, the maturity of the innovation, the organizational structure and culture, the types of systems being developed, and environmental pressures.

Research methodology and research context

Dynamics of ISPI adoption Based on an extensive historical analysis of IS development, Friedman & Cornford (1989) suggest that system development has evolved through several successive stages, during which multiple simultaneous, but distinct ISPIs are integrated. Accordingly, ISPIs can be organized ‘horizontally’ into successive generations (for a more detailed description of generations, see Appendix A). To our knowledge, there is no research that has examined the rate and direction of ISPI adoptions across generations and whether these adoptions are in line with Friedman and Cornford’s predictions regarding which topics drive ISPI processes during successive generation. Shifts between generations in Friedman and Cornford’s analysis are caused by the following: (1) changes in hardware and software (T/TO innovations); (2) changes in types of systems being developed, that is, harnessing computing capability into untried organizational domains and tasks (what Swanson (1994) calls type II and type III IS innovations, respectively); and (3) resultant changes in types of users. The latter two form external pull factors that drive the content and scope of ISPIs within each generation. Hence, any ISPI adoption can be classified into a specific generation in Friedman & Cornford’s (1989) classification. Therefore, four generations of ISPIs will be recognized. The first generation (from the late 1940s until the mid 1960s) – called early computing – was largely hampered by hardware constraints. This signals the need for mostly the T type of ISPIs. The second generation (from the mid 1960s until the early 1980s) – called the mainframe era – is characterized by software constraints, that is, poor productivity of software developers and difficulties in delivering systems on time. This signals the need for M, D, and TO innovations. The third generation (early 1980s to the beginning of 1990s) – called the office computing era – faced the challenge of overcoming user-relationship constraints where system development problems arise from an inadequate understanding of user demands. This signals the need to adopt M and D innovations that organize user interactions in a new way, or T innovations that help develop faster and more user-friendly applications. Finally, the fourth generation (from the beginning of the 1990s) – called here distributed computing – was affected by organizational constraints and a poor understanding of new task domains. These constraints emerge from complex inter-

A careful analysis of past ISPI research led us to formulate the following research questions: (1) what are the dynamics of adopting these ISPIs and how are the ISPI adoptions influenced by variances in innovation needs (computing eras) and contexts (organizational context)?, (2) which decision-making strategies do organizations deploy while introducing ISPIs?, and (3) to what extent do organizations adopt ISPIs internally or transfer them from external sources? A qualitative case study with a replication logic (Johnson, 1975; Curtis et al., 1988; Laudon, 1989; Yin, 1993) was chosen to address these research questions. We collected data using a longitudinal vertical research design that involved multiple organizations. Our study was a descriptive case study (Yin, 1993) in that it embodied history and the context of ISPI adoptions (Pettigrew, 1985, 1989, 1990) and emulated Friedman & Cornford’s (1989) by covering several generations of computing. Since the bulk of the gathered data was qualitative and covered both primary and secondary sources (Ja¨a¨rvenpa¨a¨, 1991), we adopted historical methods of generalizing from context (Copeland & McKenney, 1988; Mason et al., 1997a, b). Our vertical research design approach demanded the use of extensive resources and had to overcome limited access to organizations. Therefore, we restricted our data collection to three companies that were, or had been at some point in time, part of the same ‘parent’ company. Owing to our research design, we had some control over external factors that can affect ISPI adoption. For example, economic fluctuations and market changes affected all studied companies similarly, as their environments and access to resources were almost the same. The three Finnish companies, called here A, B, and C, respectively, were chosen as our research sites. Company A is a big paper manufacturer, while companies B and C specialize in designing, implementing, and maintaining information systems for the pulp and paper sector. A more detailed description of the evolution of the companies and their development practices is presented in Appendix B. Our definition of an ISPI adoption formed the basis for interviews and the collection of archival material. Empirical data contained tape-recorded semi-structured interviews that deal with the experience of adopting ISPIs. Interviews included project managers, IS department managers, and systems analysts who had worked at the companies at that time. We also explored archival

European Journal of Information Systems

40

Analysis of ISPI adoption

files and collected system handbooks, system documentation, and minutes of meetings. The archival data encompassed a period between 1960 and 1997 that represented a secondary source of data. We thus used triangulation to verify the veracity of data by using multiple data sources. The first round of data was gathered between February 1995 and May 1997. The obtained data set was arranged in a manuscript, which included descriptions of all ISPI events, their decision-makers, participating companies, their organizational structures, technological platforms, and changes in their business organization or strategy. These events were arranged in chronological order and written into a base line description that identified all ISPI adoptions in the companies. This manuscript was sent in May 1997 to company A’s senior vice president of IT who had worked in this organization for the entire period of our study (ca. 35 years). We asked him to read the manuscript and identify any mistakes. As the base line history did not include any analysis of adoption decisions or their success, we did not ask him for explanations or reasons for these events. This was done to minimize bias in our interpretation of the data. This manuscript was corrected for multiple mistakes and omissions. Since the analysis contained several important omissions, more data were gathered until November 1997 and a second version of the manuscript was written in December 1997. This manuscript was divided into two parts: the first part covered the years 1954–1990 (in companies A and B) and the second part included the years 1984–1997 (in companies B and C). These sections were sent to the senior vice president of IT in company A and the managing director of company C, respectively. The above division of data set was justified in that the senior vice president of IT in company A had previously held important positions both in company A (1963–1984) and in company B(1984–1990), giving him an overall view of all developments within and outside of company A until 1990. The second manuscript was sent to the managing director of company C who considered to be qualified to review the second manuscript, because he had held several senior positions in companies B and C between 1984 and 1997..This division was necessary to retain confidentiality of some of the data. The new manuscript was again corrected for omissions and mistakes. Using this base line data set, all recognized ISPI adoptions were arranged into a chronological table – one row for each ISPI adoption event. Each row included a description of the company and the ISPI, the year when Table 1

Erja Mustonen-Ollila and Kalle Lyytinen

the adoption decision was made, and the involved decision-maker(s). Each ISPI event was then categorized further into four generations, four innovation types, and three companies. When several types of ISPIs were observed to be part of the same adoption event, these were split into separate ISPI adoption events. While classifying the ISPI adoptions into four generations, we used the following features: application focus, a changing technology base, and types of user interactions – as a basis for classification. We also looked at Friedman & Cornford’s (1989) suggestions of periods for each generation as an indication where shifts could be sought between generations. These time points were not used punctually in that the most decisive criterion was the actual content and focus of the ISPI being introduced. Finally, ISPI adoptions were classified into the three decision-maker categories. A condensed version of this table enumerating all ISPIs (208 separate ISPIs adopted in 263 adoption events; the difference can be explained by the fact that some ISPIs were adopted several times in organizations and some ISPIs were adopted by more than one adoption unit. In adoption decision analysis, we will use the number of adoption instances, while in the analysis of ISPI innovation types we use the number of separate ISPIs adopted), their adoption years, innovation type, and the company involved is presented in Appendix C. In the following, we shall analyse each research question outlined above in more detail in light of the analysis of the table.

Research findings ISPI adoption rates and directions across innovation types and different companies All 208 ISPI adoptions were organized into four innovation types (M, T, TO, D) per company (Table 1). Overall, large differences could be observed between frequencies of ISPI adoptions. Using the w2 test, we therefore statistically analysed whether companies and generations of computing differed significantly in their ISPI adoption rates across ISPI types (Brandt, 1976). The test indicates a statistically significant difference (w2 ¼ 65,132, a ¼ 0.05) in adoption rates. The most common ISPI types in the sample were technology innovations, tool innovations, managerial innovations, and descriptive innovations – in this order. There were important exceptions among companies in relation to this pattern. Out of all these adoptions, 123 took place over 20 years in company A; 64 were carried out over 14 years in company B; and 21 adoptions took

Number of ISPIs adopted across companies

Company

M

T

TO

D

Total number of ISPIs

Time frame

Generation

Company A Company B Company C Total Number of ISPIs

38 2 2 42

49 11 16 76

24 40 3 67

12 11 0 23

123 64 21 208

1954–1984 1984–1997 1989–1997 1954–1997

1 and 2 3 and 4 4

European Journal of Information Systems

Analysis of ISPI adoption

place over 9 years in company C. Thus, on average, company A adopted six ISPIs per year; company B adopted ca four ISPIs each year; while company C adopted ca two ISPIs per year. Company A adopted ISPIs evenly across all categories, company B invested especially in tools (TO) and, to a lesser extent, in technology (T) and description techniques (D). In contrast, company C primarily innovated in the technology category. It is also worthwhile to note that Company A was engaged in a large number of managerial innovations (its second largest group). This can partly account for the need to establish some managerial principles to control software development during the second generation of computing. Likewise, company B has been engaged in a disproportionately large number of tool innovations. This can be explained by the company’s focus on increasing the efficiency of its software development and its use of specific software development platforms. Both companies adopted a similar amount of description innovations, although company B adopted them in a 60% shorter period of time. In contrast, company C has not been engaged in any descriptive ISPI. This suggests that ISPI rates and types of innovations varied significantly and companies can experience, even within similar economic and business conditions, large variations in the type and frequency of their ISPI adoptions. The causes for variance can be many and range from differences in slack, the use of varying learning mechanisms, alternative and more refined technology platforms, differences in development environments and types of system being developed, and variations in the external boundary spanning activities. Company A implemented systems for all its business units and thus ran a large number of separate IS projects in diverse task domains. Owing to their hands-free approach to managing ISPI adoptions, each project group could make adoption decisions on the fly (see below). Its wider span of activities and its larger number of projects when combined with lax control spawned a large number of innovation processes and increased its assimilative capability (Fichman & Kemerer, 1997). Moreover, the company had at that time significant slack to experiment. In contrast, company B focused on production planning and logistics systems. In addition, it faced a major economic downturn in the early 1990s, which forced it to concentrate on ISPIs that could improve operational efficiencies. At the same time, the amount of time available to implement ISPIs shortened and thus reduced the scope of possible innovative activity further. This, for example, resulted in the adoption of Microsoft’s visual programming environment to speed up development and learning times. Overall, the paucity of resources resulted in fewer innovations and primarily generated changes that improved coding efficiencies. Company C, the most recently examined company, concentrated on applying object-oriented technologies in a relatively narrow application domain of production planning and

Erja Mustonen-Ollila and Kalle Lyytinen

41

control systems to a small number of well-defined clients. It also carefully chartered a distinct technology platform, which it used to develop the systems. The company made a conscious shift toward the use of specific objectoriented design and client–server architectures in their computing platforms. Therefore, its ISPI adoptions were mostly technological in nature. Some differences between ISPI type adoptions across IT generations can be identified. During the first and second generations, the adoption speed was highest in the managerial innovations (M). This finding is surprising and in contrast to Friedman & Cornford’s (1989) analysis, which argued for the need to focus on technology innovations. As the number of T type innovations forms the largest group, it looks as if their adoption in a wider scale necessitated ISPIs in other innovation types. The second generation introduced several innovations in the description techniques category (D), as predicted by Friedman & Cornford (1989). During the third generation, the highest number of adoption events was observed nearly evenly in managerial innovations (M), core technology (T), and tool innovations (TO). This finding is somewhat different from Friedman and Cornford’s analysis, which did not predict such a large number of core technology innovations for this period. In the fourth generation, the technology (T) and the tools (TO) were the most salient ISPIs, which reflects the shift towards client–server computing. Again, here we see much less of a focus on managerial innovations when compared to Friedman & Cornford’s (1989) prediction. Overall, the analysis shows that the pace and intensity of the ISPI has been quite high across all generations of system development. Yet, a decreasing rate of ISPI adoptions over time can be recognized. This can be explained by the following two reasons: (1) the absorptive capacity of the companies seems to decrease over time due to increased internal cohesion and the routinization of the development environment; (2) innovation potential becomes more exhausted over time in several areas due to accumulated learning, the garnering of development competencies, and diminishing returns. For example, one needs to invent a good participative development method only once (like a wall graph method) and a decent data modelling approach. The organizational value of adopting another slightly better approach cannot be justified economically or psychologically. The innovative activity also seems to slow down during later generations. For example, company C adopted only fourth-generation ISPIs and its pace of innovation was slower. This is a somewhat surprising result since some recent studies claim that the pace of IS process innovation has increased over the last decade (Lyytinen & Rose, 2003). This can be, however, an outcome of a sampling bias in the sense that some recent studies have analysed leading edge software companies in areas of IS operations that have not been well established, as those in our study.

European Journal of Information Systems

42

Analysis of ISPI adoption

At the present time, highly innovative ISPI adoptions may concentrate on fewer companies. ISPI adoptions in all companies were also lumpy in nature since several ISPIs were adopted together due to their interdependencies that demonstrate the socio-technical nature of ISPI adoption. This made even the separation of some ISPI events difficult. For example, between 1982 and 1985, one IS project introduced modular programming and the use of generic program patterns (Type TO and D), project design procedures as defined in the Hewlett-Packard handbook (type M), entityrelationship diagrams (Type D), and the use of wall graph techniques (Type D and M). All these were later adopted in a larger scale in organizations A and B. The IS project group also carried out pilots regarding the use of a new database platform (Type T). How much of all ISPI adoptions were driven by such bursts of innovation is beyond the scope of this paper and requires a separate analysis.

Who makes ISPI adoption decisions? We identified 67 decision-makers in 263 separate adoption decisions. These were classified into three decision authority categories as shown in Table 2. Thereafter, ISPIs were divided into the four ISPI types. The number of adoption decisions made for each ISPI category by a specific decision-maker category could be accordingly analysed. The data in Table 2 were analysed using the w2 test (Brandt, 1976), which indicated a statistically significant difference (w2 ¼ 31,272; a ¼ 0.05) between different decision-maker groups. This reveals that the studied organizations followed different decision rights allocation strategies and focused on different types of ISPIs while allocating decision rights for different organizational units. As shown in Table 2, large portions of the decisions (145 out of 263) were made during IS projects. This shows that organizations mostly followed a situational strategy in managing ISPI adoption. This was followed by the department level decision-making and company-wide decisions. The company level strategies focused mostly on managerial principles, for example, the demand to follow a specific project management handbook, or formulate budgets. Some centralized decisions involved tools, such as determining which platforms should or should not be used to develop applications. Centralized strategies also formulated general technology policies related to infrastructure investments (standards, operating systems, DBMS). Not surprisingly, departments made Table 2

Erja Mustonen-Ollila and Kalle Lyytinen

the highest number of decisions within the technology category (T), but were also concerned with managerial innovations (M) and the tools (TO). When combined, these two innovation types, however, cover less than half of the total number of decisions made at the department level. The description techniques innovations (D) comprise by far the smallest group among the four ISPI types and show that such decisions were nearly always carried out at the project level. It is also obvious that these innovations seem to have become routinized in these companies in the late 1980s in such a way that after that there was little need to change them through higher-level intervention. The analysis indicates that decisions taken by the project group were spread evenly across all innovation types categories. Overall, IS project level decision-making was guided by organizational guidelines concerning project establishment and scope definition. Such principles evolved over a long period of time. Consequently, IS projects engaged in decision-making concerning ISPIs by enacting routines that guided the governance of the system development activities included in the project scope. This approach was hierarchical in the sense that some decisions had to be made prior in the higher echelons of the organizational hierarchy, but at the same time flexible enough to allow for the diverse needs of IS projects. The prominent role of business managers in ISPI adoption (Sauer & Lau, 1997) was not confirmed with our data, but our finding is in line with Huff & Munro’s (1985) findings that project teams make adoption decisions. No support was found for Kozar’s (1989) observation that individuals play a critical role in ISPI adoptions.

Knowledge transfer mechanisms Despite relatively easy access to external knowledge, a surprisingly large number of ISPIs originated from internal sources in all companies. Out of 208 analysed ISPI adoptions, 122 were adopted based on learning from in-house sources, while 86 were externally furnished (Appendix C). In furnishing external knowledge related to ISPIs, companies employed several mechanisms identified in the organizational learning literature (Huber, 1991; Lyytinen & Robey, 1999). They would periodically scan their environment triggered by a critical incident (e.g., the emergence of information about new technology, a failure etc.) or a periodic routine. Such scans normally

Adoption decisions by decision authority in four innovation types

Decision made by

M

T

TO

D

Total number

Company A, B, C, or a business unit (centralized strategy) Department inside the business unit (distributed strategy) IS project steering group, the project manager, or IS project group (situational strategy)

12 20 40

8 45 44

11 19 29

1 2 32

32 86 145

Total number of adoption decisions

72

97

59

35

263

European Journal of Information Systems

Analysis of ISPI adoption

went rapidly through their immediate environment by pooling knowledge related to ISPIs from several sources, including ‘friendly’ consulting houses and major computer vendors. In most cases, organizations searched knowledge by using their main vendor as the focal access point. The search mechanisms also included vicarious learning – the company representatives visited seminars, established development groups within other companies or with their peers in other industries, or asked consulting houses to offer education and provide reports of new developments. Over time, companies established friendly, trustful, and long-lasting relationships with specific vendors and consulting houses. In most ISPI adoptions, companies preferred to adopt an externally furnished innovation only if it fit well with an identified problem and there were no internal resources available to furnish the innovation. Hence, in the base line technology area (T), externally furnished ISPIs were most frequently used. In addition, the amount of internal innovation decreased over time within the core technology. Most externally furnished ISPIs could only be made useful after a considerable adaptation where the ‘available’ solution was fitted with a unique problem (Fitzgerald, 1997; Sauer & Lau, 1997). In spite of this, many transfers failed because adaptations were inadequate. Therefore, many, if not most, of the externally furnished description and managerial ISPIs such as the wall graph technique (D, M) and the use of entity relationship diagrams (D) underwent a major adaptation. Some ISPI adoptions became widely successful after such adaptations and had a long-lasting impact. They were still used in the late 1990s when the companies were visited after over 15 years had passed since their first adoption. The main reason for this is that a large number of users in company A were educated to use them in the 1980s. Moreover, personnel turnover had not been so dramatic that the knowledge had been easy to maintain. It became, over time, a part of the ‘organizational’ infrastructure for systems development and the established ‘archaeology’ of system development knowledge, which was unconsciously drawn during development. Project teams shared this archaeology often unconsciously, although this has become more difficult as more development has been outsourced to people who are not members of this archaeology. In most cases, companies preferred to turn to their internal experience rather than search for external knowledge when they had to innovate. This applied especially to innovations in D, M, and TO types in that, in these categories, a majority of ISPIs were internally generated, thus covering self-developed tools, their ‘own’ notations or description techniques (although they were inspired many times by external sources), proprietary managerial principles, or interaction techniques. Surprisingly, companies adopted internal tool ISPIs more often than furnishing them externally. Moreover, the volume of internal innovation also increased in the tool category over time.

43

Erja Mustonen-Ollila and Kalle Lyytinen

How these innovations came into being varied. Some of them were developed for an immediate technological or organizational need, while others emerged as a byproduct of successful projects and thereafter were adopted by other organizations’ projects. For their internally furnished ISPIs, companies often developed an internal ‘triage’, and spawned a dedicated innovation process by themselves. During the triage, the company would select a project through which they would address a specific ‘concern’ by internally developing a solution for it (e.g., interaction techniques, notations). This propensity for deploying internal ISPIs in these companies can be explained by several factors: a dominant ‘techie’ culture within the companies; unique technology platforms; lax decision rights; slack resources; and dedicated internal knowledge transfer mechanisms for ISPI adoption. The creation of a ‘techie’ culture in these companies increased the confidence of employees to rely on their own skills. This resulted in ‘will do’ attitude and fostered the development of several homegrown technologies. The use of uncommon technology platforms amplified this pioneering attitude of trying out new solutions when there were none available in the market. As noted, the organizations had relatively lax control over decision rights and therefore the companies never tried to introduce a ‘big-bang’ adoption of externally furnished ISPI ‘silver bullets’. In contrast, most ISPI adoptions were local responses to problems including how to use CASE tools or how to improve software processes. An additional factor that increased internal learning was that the IS department in company A had ample resources during its early days. The department had slack and, consequently, many people sought opportunities to improve their technical skills and career paths; this created an innovative culture in company A. Consequently, all three companies employed the same effective knowledge transfer mechanism to distribute the outcomes of internal learning. In company A, internal education offered between the early 1960s until 1984 established effective mechanisms of knowledge transfer, which enabled ISPI knowledge sharing among communities. Many of the mechanisms focused on devising and adjusting ISPIs and influencing their subsequent adoption. At the same time, people involved in these activities became gatekeepers for transferring external ISPIs. Several key employees within company A cooperated with external experts from the mid-1960s through 1984, thus spawning a tight knowledge network that fostered continued ISPI adoption.

Discussion and conclusions In this study, we analysed 208 ISPI adoptions in three companies in a longitudinal setting. Our analysis shows that there were significant differences in ISPI adoptions between computing eras and among organizations. The overall trend has been towards a decreasing rate of ISPI, which is resulting from garnered learning and decreased marginal returns. Much of the variance between organi-

European Journal of Information Systems

44

Analysis of ISPI adoption

zations could be explained by their varying scopes of IS activity, the availability of slack, and how their decision rights were organized. Much of the change could also be explained by increased business pressures and economic cycles (Sauer & Lau, 1997). We also observed that innovation frequencies between different types of ISPIs varied greatly among studied organizations and between generations, although no discernible pattern could be observed between ISPI type adoptions and computing generations or organizations. These findings go against Friedman & Cornford’s (1989) suggestion that specific types of ISPIs would become dominant during specific computing periods. We also observed that many ISPI adoptions were bundled, which suggested that an ISPI adoption should be understood as a set of parallel sociotechnical transformation processes that involve several interrelated adoption events. To our surprise, organizations would, in most cases, turn to internal exploration and utilize past experience and immediate resources. In line with this tendency, externally furnished ISPIs could only be made useful after considerable adaptation. This demonstrates a high level of stickiness in transferring external ISPI-related knowledge. Companies preferred adopting an externally furnished innovation only if it fit well with an identified problem. The dominance of internal learning applied to all ISPI types save core technology innovations. Moreover, there was no change in this over time. These companies routinely formalized, made explicit, and transferred internal ISPI knowledge into a broader use. One reason for this surprising finding can be found in the organizational culture and management strategies of the companies, their unique technology platforms and welldeveloped knowledge transfer practices. As a consequence, all companies showed surprising resilience in maintaining high levels of innovative activity. There are several limitations to our study. First, the classification of ISPI data into innovation types had to be accomplished, sometimes by using the limited knowledge of the context and content of the innovation because access to secondary sources was allowed alone. The second limitation concerns the limited number of studied companies. Our findings can be generalized across a set of organizations with care. At the same time, they show that generalizing explanations for variations in ISPI activities is difficult, and should be made with considerable caution. Our study has several implications for managers. Organizations look for ISPIs either when they develop

Erja Mustonen-Ollila and Kalle Lyytinen

slack or when they feel a strong need to change their behaviour. Therefore, if managers want to create innovative IS organizations, they must both allow for the additional ‘slack’ and manage it effectively, thus creating a more responsive environment, or they must run the organization with a ‘burning platform’ mentality. In so doing, companies should delegate more freedom to local development groups to explore and innovate. Therefore, project level decision-making has to be guided by organizational guidelines concerning project establishment and scope definition, which delegates clear responsibilities in the innovating process. The bundling of many ISPIs also suggests that managers should approach ISPI adoptions as socio-technical transformation processes that integrate multiple interrelated ISPI adoptions. Managers must also consider effective strategies for ISPI knowledge transfer and sharing. This includes the means to document and share innovation knowledge, to make them available through traditional and electronic media, and to enable and create peer networks to learn from one another. The early routinization of such activity in company A carried further much of the internal innovation activity in all three companies. Organizations did not approach ISPIs as capital investments, since they did not feel that they had the ability to do so and therefore stalled innovative efforts. Therefore, managers should carefully think how they balance the idea of costs and benefits of ISPIs with the need to constantly innovate with ISD. As noted above, this study focused solely on ISPI adoptions and did not investigate whether these innovations were effectively taken into use (Swanson & Ramiller, 1997). According to our preliminary analysis, ca 10 % of the adopted ISPIs later became successfully institutionalized (ca 30 ISPIs). We have not analysed reasons for failures or successes in infusion processes or how they vary between different ISPI types. This is clearly a research task ahead. Our data show that organizations are now spending more time to search externally for ISPIs. As a consequence, organizations must make careful choices about the types and natures of ISPIs that can be sourced during the project set up and understand how this becomes part of the mission of the project. How this can be done effectively also needs to be addressed in future research.

Acknowledgments We express our gratitude to Mr. Mauri Mustonen, Mr. Tapani Ollila, Dr. Jukka Heikkonen, and interviewees. We also thank the associate editor and two anonymous reviewers.

References ATTEWELL P (1992) Technology diffusion and organisational learning: the case of business computing. Organization Science 3(1), 1–19. BRANDT S (1976) Statistical and Computational Methods in Data Analysis. North-Holland Publishing Company, Amsterdam.

European Journal of Information Systems

COPELAND DG and MCKENNEY JL (1988) Airline reservations systems: lessons from history. MIS Quarterly, September 353–370. CURTIS B, KRASNER H and ISCOE N (1988) A field study of the software design process for large systems. Communications of the ACM 31(11), 1268–1287.

Analysis of ISPI adoption

FICHMAN R (1992) Information technology diffusion: a review of empirical research. In Proceedings of the 13th International Conference on Information Systems (DEGROSS J, BECKER J and ELAM J, Eds), 13–16 December Dallas, pp 195–206. ACM Conference proceedings series FICHMAN R (2000) The diffusion and assimilation of information technology innovations. In Framing the Domains of IT Management: Projecting the Future through the Past (ZMUD RB, Ed), Pinnaflex Educational Resources, Cincinnati. FICHMAN RG and KEMERER CF (1994) Toward a theory of the adoption and diffusion of software process innovations, diffusion, transfer and implementation of information technology (A-45) In IFIP Transactions (LEVINE L, Ed), pp 23–30, Elsevier Science B.V. (North-Holland), Amsterdam. FICHMAN R and KEMERER C (1993) Adoption of software engineering process innovations, the case of object orientation. Sloan Management Review 34(2), 7–22. FICHMAN R and KEMERER C (1997) Assimilation of software process innovations: an organizational learning perspective. Management Science 43(10), 1345–1363. FITZGERALD B (1997) The use of systems development methodologies in practice: a field study. Information Systems Journal 7, 201–212. FLECK J (1994) Learning by trying: the implementation of configurational technology. Research Policy 23(6), 637–652. FRIEDMAN A and CORNFORD D (1989) Computer Systems Development: History, Organization and Implementation. John Wiley & Sons, Information Systems Series, New York. HUBER GP (1991) Organizational learning: the contributing processes and the literatures. Organization Science 2(1), 88–115. HEISKANEN A (1994) Issues and factors affecting the success and failure of a student record system development process, a longitudinal investigation based on reflection-in-action. PhD Dissertation, University of Helsinki, Helsinki, Yliopistopaino. HUFF S and MUNRO MC (1985) Information technology assessment and adoption: a field study. MIS Quarterly December 327–339. JOHNSON JM (1975) Doing Field Research. The Free Press, New York. Ja¨a¨RVENPa¨a¨ S (1991) Panning for gold in information systems research: ‘second-hand’ data, Information systems research arena in the 90’s (1991): information systems research: contemporary approaches and emergent traditions: proceedings of the IFIP TC/WG 8.2. Working Conference on the Information Systems Research Arena of the 90’s Challenges, Perceptions and Alternative Approaches, Copenhagen, Denmark, 14–16 December, pp. 63–80, North Holland, Amsterdam. KOZAR KA (1989) Adopting systems development methods: an exploratory study. Journal of Management Information Systems 5(4), 73–86. LAUDON KC (1989) Design Guidelines for Choices Involving Time in Qualitative Research, Harvard Business School Research Colloquium, The Information Systems Research Challenger: Qualitative Research Methods, Vol. 1, pp. 1–12. LYYTINEN K and ROBEY D (1999) Learning failure in information system development. Information Systems Journal 9(2), 85–101. LYYTINEN K and ROSE G (2003) Distruptive Information system innovation: the case of internet. Information Systems Journal 13(4), 301–330. LUNDBERG M, GOLDKUHL G and NILSSON A (1981) Information systems development: a systematic approach. Prentice-Hall Inc., Englewood Cliffs, New Jersey. MASON RO, MCKINNEY JL and COPELAND DC (1997a) Developing a historical tradition in MIS research. MIS Quarterly 21(3), 257–278. MASON RO, MCKENNEY JL and COPELAND DG (1997b) A historical method for MIS research: steps and assumptions. MIS Quarterly 21(3), 307–320. NEWELL S, SWAN J and GALLIERS D. (2000) A knowledge-focused perspective on the diffusion of complex information technologies: the BPR example. Information Systems Journal 10(3), 239–259. NILAKANTA S and SCAMELL RW (1990) The effect of information sources and communication channels on the diffusion of innovation in a data base development environment. Management Science 36(1), 24–40. PETTIGREW A (1985) The Wakening Giant, Continuity and Change in ICI. Basil Blackwell, Oxford and New York.

45

Erja Mustonen-Ollila and Kalle Lyytinen

PETTIGREW A (1989) Issues of Time and Site Selection in Longitudinal Research on Change, Harvard Business School Research Colloquium, The Information Systems Research Challenger: Qualitative Research Methods, Vol. 1, pp. 13–19. PETTIGREW AM (1990) Longitudinal field research on change: theory and practice. Organization Science 1(3), 267–292. PREMKUMAR G and POTTER M (1995) Adoption of computer aided software engineering (CASE) technology: an innovation adoption perspective. Data Base Advances 26(2&3), 105–124. PRESCOTT MB and CONGER SA (1995) Information technology innovations: a classification by IT locus of impact and research approach, The Data Base for Advances in Information Systems, A Quarterly publication of SIGMIS, Special Issue of Technological Diffusion of Innovations, Vol. 26, Nos. 2 and 3, Special Double Issue: of Diffusion Technological Innovation, pp. 20–41. ROGERS EM (1995) Diffusion of Innovations (4th edn). The Free Press, New York. ROPPONEN J (1999) Software risk management – foundations, principles and empirical findings Jyva¨skyla¨ Studies in Computing 1, Ph.D dissertation thesis, University of Jyvaskyla. SAUER C and LAU C (1997) Trying to adapt systems development methodologies – a case-based exploration of business users’ interests. Information Systems Journal 7, 255–275. SWANSON EB (1994) Information systems innovation among organizations. Management Science 40(9), 1069–1088. SWANSON EB and RAMILLER NC (1997) The organizing vision in information systems innovation. Organization Science 8(5), 458–474. TOLVANEN J-P (1998) Incremental method engineering with modeling tools: theoretical principles and empirical evidence. Jyva¨skyla¨ Studies in Computer Science, Economics and Statistics 47, University of Jyva¨skyla¨, PhD Dissertation thesis. YIN RY (1993) Applications of case study research. Applied Social Research Methods series Vol. 34, SAGE publications, Beverley Hills, CA. WYNEKOOP JL and RUSSO NL (1997) Studying system development methodologies: an examination of research methods. Information Systems Journal 7, 47–65.

Appendix A: Four generations of ISPIs Friedman & Cornford (1989) distinguish between 36 ISPI categories. Each one can be further partitioned into individual ISPIs (see Table A1). Their ISPI categories are listed in the second column in Table A1. The respective ISPI categories in our data set are listed in the third column. The ISPIs described in Friedman & Cornford (1989) thus match those found in our data set. In fourthgeneration ISPIs high-level programming languages are included like structured query language (SQL), C++, Java; Object-Oriented technology and tools like OMT and OMT++; and Client/Server technology and tools. CASE tools belong also to the fourth generation. The joint analysis shows that the first-generation development took place in a centralized environment where punched card systems were transformed into batch processing systems. During the second generation, the systems environment changed into a remote spooling of computing tasks when transaction-oriented information systems substituted batch-processing systems. Interactive computing was put into use. The IS department concentrated on developing programs for such transaction systems. The end-user problems began to mount, while IS personnel were fully occupied with such technical activities. In the third generation, the environment consisted of a centralized data processing environment where the user control increased. Tailor-made applications and prototypes were

European Journal of Information Systems

46

Analysis of ISPI adoption

Erja Mustonen-Ollila and Kalle Lyytinen

Table A1 Main features of the ISPIs in four generations Generation

Friedman & Cornford (1989)

Observed ISPIs in the data set

Company

Generation 1

Machine code and assembler languages Programming techniques Modularization COBOL, FORTRAN Program generators Database management systems Structured programming, analysis, and design ISPIs Project control techniques Life cycles Prototyping User involvement CASE tools

Programming languages (T) Specific programming techniques (T) Modular programming (T) COBOL, FORTRAN (T) DMS prototyping generators (T, TO) IDMS database management system (T) ISAC (Lundeberg et al., 1981) (D, M)

Company A

Generation 2

Generation 3

Generation 4

Phase models (M) Life cycles (M) Pilots (M) Wall analysis techniques (D, M) Application Development Workbench (TO)

Company A

Company B

Company B, and Company C

Object-oriented methods (OMT, OMT ++) Client–server technologies (T) Object-oriented programming languages Java, C++ (T) Database query languages SQL (T)

widely deployed. The IS personnel became more interested in the needs of the end-users and they started to utilize database software and functionality, such as query languages, report generators, and prototype generators. The system specifications were written in cooperation with the end-users. By the end of the third generation computing client–server applications emerged within local area networks. At the same time end-users began to actively participate in and manage IS projects. Finally, in the fourth generation, the environment changed into a distributed environment and users started to buy their own applications. The focus of development was on group activity. Distributed ISs were implemented, while organizational processes were streamlined and rationalized across functional and organizational borders. New technologies emerged including workstations, local area networks, and client–server applications. Also, new tools and notational innovations were introduced including software re-engineering, Case-tools, and object-oriented notations.

Appendix B: Short description of the three companies Three Finnish organizations, here called companies A, B, and C, respectively formed the data collection sites. Company A is a big global paper-producer. Company B designs, implements, and maintains information systems mostly for company A, and also for other companies in the paper industry. The origin of company B is that, in 1984, company A transferred its IS department into a newly formed company, company B, which was owned by the employees of the company. In 1995, company B was further divided into five separate companies. One of them is company C that was located close to the

European Journal of Information Systems

headquarters of company B and continued to mainly serve company A. Thus, until the end of 1997, company C formed a division within company B when it was bought by another large software house that operates in Scandinavia (this evolution since 1997 is not included in our data). These three companies’ locales are situated in three Finnish cities. Company A was located in a city in the Eastern part of Finland and housed several IS activities between 1954 and 1969 in its separate functional departments (accounting, engineering, etc.). In 1969, a separate IS department was established and it was continued until 1984 when the department was transformed into a separate profit centre. Company A also had in-house IS activities in Helsinki between 1961 and 1969. During 1969–1984, these belonged to the IS department of company A. Despite having separate locations, both these sites were chosen to be treated as one organization called company A, due to the fact the two were working intimately together and belonged to the same IS department and also followed the same formal development guidelines. After 1984, company B’s site in the eastern part of Finland has been treated as a separate company. Between 1995 and 1997, this site continued to operate separately. The third company, company C, was established in 1989 as a separate division, which was located in a different city in Eastern Finland within company B. It continued its existence until 1995 under the formal management of company B. It is treated as a separate company because it had totally independent IS development functions and markets. It operated on a different technological platform and was treated as a separate profit centre in company B. The IS and business knowledge within company A’s IS department was inherited through outsourcing to

Analysis of ISPI adoption

47

Erja Mustonen-Ollila and Kalle Lyytinen

service unit was established and an additional data system unit was established 1 year later. The establishment of these units marked a ‘kick-off’ event for a more rigorous and systematic ISPI development in company B. The information Technology Service Unit emphasized feasibility-based IS designs and evolutionary development and sought to connect IT strategy to business planning. The focus was to support the chosen business strategy of company A. The Data Systems Unit focused on the production and logistics-based information systems, factory maintenance and introduced technologies for IS development. Its goal was to increase the speed and decrease the cost of technical implementation.

company B. Not surprisingly, company B continued with the same organizational structure as before the outsourcing and company A recognized company B easily as its main IS vendor. Considerable organizational development and internal changes that occurred as a result of ISPIs and market changes have taken place since 1984. One reason is that company B has expanded its markets with multiple new services in the paper industry by buying other units and also obtaining new clients. When company B began to design company A’s ISs, all project guidelines and phase models from company B were used in common projects. Moreover, company B’s employees participated in company A’s development groups in close cooperation with company A’s business lines. During 1986 and 1987, company B renewed its organization and several separate IS design groups were disposed. At the same time, an information technology

Appendix C Details of ISPI data in four generations, four ISPI types, and three locales are summarized in Table C1.

Table C1 ISPI no.

ISPI categories, time periods, and locales. 1=present

206 2 3 9 12 176 180 58 68 169 177 178 179 197 4 59 168 174 181 182 183 184 185 186 17 35 43 95 150 175 187 207 13 60 69 108 165 196

System development phase method ADPH1.’s phase model Phase model 2, Material IS Program structures System phase model Programming modules Common operating procedures Project management guidelines Form design guidelines New Phase models Description techniques Report models Screen prototyping (form painting programs) ADPH 2. Cooperative system development instructions ADPH 2. System development guidelines Phase models in ADPH2. Modular computing ADPH 2., Management Instructions, ADPH 2. Programming guidelines ADPH 2. User interaction design instructions ADPH 2. Standard forms Programming method recommendations (ADPH 1.) ADPH 2. Modular programming instructions Program skeletons, standards, general modules Program modularization Tailor-made 3780 emulator in IBM environment Programming instructions Project management guidelines ADPH 2. IANS COBOL program structures Data communication tools for IBM computers Program skeletons, generalized programs COBOL PL instructions Principal planning instruction, OHS Phase models IBM database handling tools Generators for controlling terminals Phase models for planning A technique to describe diagrams

ISPI: ISPI: ISPI: ISPI: Com Com Com T TO M D (A) (B) (C) 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Year 1960 1969 1969 1969 1969 1969 1969 1970 1970 1970 1970 1970 1970 1970 1972 1972 1972 1972 1972 1972 1972 1972 1972 1972 1973 1973 1973 1973 1973 1973 1973 1973 1974 1974 1974 1974 1974 1974

Gen Gen Gen Gen Int 1 2 3 4 1

Ext 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

European Journal of Information Systems

48

Analysis of ISPI adoption

Table C1 ISPI no.

ISPI categories, time periods, and locales. 1=present

11 109 110 14 18 19 44 61 127 129 164

Project management instructions ROSCOE (program generator) Data communications network tools Documentation standards Instructions for phase model and IS implementation COBOL code generator (CARELIA) Screen and output procedures New phase models for projects DEL product from HP IBM’s CICS/VS and DMS/VS Nokia Compus phase models, project management guidelines PDP 4-11/76 documentation Wall technique ADPH 2. System forms (DMS screen descriptions) ADP standards Work flow charts and organization Standards for programming languages IS-oriented planning schedules Project guidelines ADP instructions IBM 370/148 computer controlling tool IDEA- packet in HP environment System development, programming standards Terminals connected with many-point-connection Database handling modules Separate message handler tool for HP 1000 ADPH 2. Output instructions in programming ADPH 2. System development instructions ADPH 2. Record forms ADPH 2. Text file handling programs ADPH 2. General program ANTTI Wall technique Prototyping in HP and IBM environments Local networks handling tools Data communications architecture SNA Asynchronous calling connections tool IBM’s VSAM handling tools IMAGE 3000 database management system tools QUERY language in HP3000 environment Wall technique, entity analysis, diagonal matrices, process analysis ADP working instruction 1-1: phase structure Work methods in HP and IBM environments Small entity models COBOL platform General modules ADPH 2. IDMS screen handling instructions ADPH 2. Automatic documentation concerning IDMS instructions Text database tool Demos from databases System design and documentation tools General instructions for systems work Project timetables Preliminary pre-compilers in HP and IBM environments IDMS database management and IDD data dictionary, and OLQ query language

189 191 1 15 16 45 62 63 101 128 151 163 170 36 39 5 6 46 47 48 192 20 55 148 49 71 89 138 198 7 28 33 37 40 50 51 52 54 64 65 66 70 90

European Journal of Information Systems

Erja Mustonen-Ollila and Kalle Lyytinen

Continued

ISPI: ISPI: ISPI: ISPI: Com Com Com T TO M D (A) (B) (C) 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Year

Gen Gen Gen Gen Int 1 2 3 4

1 1 1 1 1 1 1 1 1 1 1

1975 1975 1975 1976 1976 1976 1976 1976 1976 1976 1976

1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1976 1976 1977 1977 1977 1977 1977 1977 1977 1977 1977 1977 1977 1978 1978 1979 1979 1979 1979 1979 1979 1980 1980 1980 1981 1981 1981 1981 1981

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1

1 1 1 1 1 1 1

1982 1982 1982 1982 1982 1982 1982

1 1 1 1 1 1 1

1

1 1 1 1 1 1 1

1982 1982 1982 1982 1982 1982 1982

1 1 1 1 1 1 1

1 1 1 1 1

Ext

1 1 1

1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1

1 1 1 1

1 1 1 1 1 1

1 1

Analysis of ISPI adoption

Table C1 ISPI no.

ISPI categories, time periods, and locales. 1=present

91

Data dictionary (QSCHEMA), report language (QUIZ), event1 handling program (QUICK) Operating guidelines for Hewlett - Packard handbook 1 Hewlett - Packard start-up manual 1 EPOK packet solution 1 Data dictionary system DOKUB1 for HP3000 environment: COBOL code generator with Q-parts ADI program for data selection, analysing and output, 1 equipped with APL graphics, ADI Query language, and APL programming language COBOL programming language 1 HP 3000 general programs manual (instructions for HP26451 display terminal, display terminal instructions for HP2626A/ HP2624B terminals HP2626A terminal Modular computing with COBOL 1 Project specifications, hardware diagrams, output lay outs, transfer descriptions of data bases Entity analysis with wall technique Entity analysis in team work Wall technique, entity analysis, present situation analysis, change needs HP standards IDEA code generator CARELIA2- tool, IBM based Front-End device for data communications OLQ (IBM’s query language) 1 CARELIA (a COBOL generator) IDMS/R product 1 EPOK methods 1 EPOK tools 1 Photographs from the wall pictures Commercial data networks handling tools X-25 local networks’ controlling tools PERT net chart Net database IDMS management tools 1 End-user activities, function processes, business process reengineering System work model for A Wall technique Specifications, wall technique, entity analysis CARELIA2 -tool in VMS operating system CAREL- tools in DOS environment Diagonal matrices of wall technique Control-AA product family COBOL 1 Data Base II 1 Workstation program EDA 1 Application Development Workbench (ADW) including COBOL code generator in mainframe environment CARELIA- tool (COBOL etc. code generator) Beta testing tools with RISC 955 computer 1 IBM 3090-180S Winchester hard disk unit controlling tools1 CARELAAMU tool from CICS System design method SQL and C language 1 OO analysis, design and implementation methods, C++ 1 UNIX with Motif user interface: tool environment 1 System and program documentation tools 1

92 96 99 103 153

155 156

157 171 172 193 199 208 21 24 34 97 104 154 161 162 38 56 57 67 72 137 188 200 201 25 26 202 27 73 74 98 105 107 75 76 106 173 77 87 88 102

49

Erja Mustonen-Ollila and Kalle Lyytinen

Continued

ISPI: ISPI: ISPI: ISPI: Com Com Com T TO M D (A) (B) (C)

Ext

1982

1

1

1 1 1 1

1982 1982 1982 1982

1 1 1 1

1 1 1

1

1982

1

1

1 1

1982 1982

1 1

1 1

1 1

1982 1982

1 1

1 1 1

1982 1982 1982

1 1 1

1982 1983 1983 1983 1983 1983 1983 1983 1983 1984 1984 1984 1984 1984 1984

1 1 1 1 1 1 1

1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1984 1984 1984 1987 1987 1987 1988 1988 1988 1988 1988

1

1 1

1 1 1 1 1 1 1 1 1

1 1 1 1

1

1 1

1

1 1 1 1 1 1 1 1

1

1

1

1 1 1

1

Gen Gen Gen Gen Int 1 2 3 4

1

1

1

Year

1

1 1 1 1 1

1988 1989 1989 1989 1989 1990 1990 1990 1990

1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1

1 1 1 1

1 1 1 1

1 1 1 1

1 1 1 1 1 1

European Journal of Information Systems

50

Analysis of ISPI adoption

Erja Mustonen-Ollila and Kalle Lyytinen

Table C1 Continued ISPI no.

ISPI categories, time periods, and locales. 1=present

143 144 41 100 111 112 145 42 79 116 123 146 147 80 114 115

HP NewWave Porter’s value chain CARELLINK tool Mirac tool sets 1 C language in UNIX 1 Screen handling products in UNIX ADW tool from IBM supporting IE methodology CARELCONNECT generator FOCUS program as a query language 1 Q+E Multilink/VB version Visual Basic 1.0 Prototypes with Visual Basic 1.0 Visual Basic 1.0 version and 2.0 MVS tools 1 CARELIA/Win 1.0 (a tool base), VB/APPC/CICS/COBOL/DB2 CARELIA/Win 1.1: VB/TCPIP/COBOL/HP3000/Image/MPEXL/AllBase/SQL CARELIA- tool CARELIA/Win 2.0: supported Client/Server- Q+E environment CARELIA/WIN tool CONTROL-A family Windows version of LASKE Demo version of Windows LASKE BASE BB 3.X version: C language library (UNIX based tool library) ODBC- driver 1 Network handling tools for Client/Server Object-Oriented technology 1 Entity analysis, concepts Project instructions of B ADW- tool S-Designer- tool S-Designer Power- Designer, Fenix F project’s working in OO- environment 1 Event database handling tools 1 Entity diagram and data catalogue handling tools 1 C++ programming language 1 CARELIA/Win 4.32, Visual Basic CARELIA/Win 3.11a CARELIA- tool and VB, CARELAAMU CARELIA/Win 3.0, supported Client/Server and CCODBC CARELIA/Win- tool CARELIA/Win generator, Visual Basic CARELIA/Win 3.11s or greater OO design methods, OMT, expanded to OMT ++ OO tool base, BASE BB 4.X version: C++ programming 1 language Wall technique, object orientation Diagonal matrices Wall picture technique SQL 1 Java programming language, SQL 1 C++ , 32 bits class library, list controlling 1 Interfaces management environment 1 Own database DB2 in IBM mainframe Product family CAREL was renewed

117 118 119 124 140 142 166 84 149 194 203 8 29 30 31 32 53 81 82 94 120 121 122 126 130 131 133 141 190 204 205 22 78 85 86 93 125 132

European Journal of Information Systems

ISPI: ISPI: ISPI: ISPI: Com Com Com T TO M D (A) (B) (C) 1 1

Gen Gen Gen Gen Int 1 2 3 4

1 1

1 1 1 1 1 1 1 1 1 1

1990 1990 1991 1991 1991 1991 1991 1992 1992 1992 1992 1992 1992 1993 1993 1993

1 1

1 1

1993 1993

1 1

1 1

1 1

1 1 1 1

1993 1993 1993 1993 1993

1 1 1 1 1

1 1 1 1 1

1994 1994 1994 1994 1995 1995 1995 1995 1995 1995 1995 1995 1995 1995 1995 1995 1995 1995 1995 1995 1995 1995

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1

1 1 1

Year

1 1 1

1 1 1 1 1 1 1

1 1 1

1 1

1

1 1 1 1

1 1 1 1

1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1

1 1 1 1 1 1 1 1

1 1 1 1 1

1 1 1 1 1 1 1

1 1

1 1

1995 1995 1996 1996 1996 1996 1996 1996 1996

1

1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Ext

1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Analysis of ISPI adoption

Table C1 ISPI no.

ISPI categories, time periods, and locales. 1=present

134 135 139 195 23 10 83 113 136 152 158

CARELIA/Win 3.11s CARELIA/Win 4.0 Re-engineering- method BAFE´ (B Application Framework Environment) 1 HELP instructions software Project deliveries procedure Relational database 1 CARELIA/Win 5.00, supports WWW etc. CARELIA/Win 4.32 beta. Network handling and controlling tools Object-oriented tool base (base of the technology platform1 Base +BB) OMT ++ 1 CARELIA/Win 4.32 Common tools with HP3000, VB 4.0 and CARELIA/5.0 components

159 160 167

51

Erja Mustonen-Ollila and Kalle Lyytinen

Continued

ISPI: ISPI: ISPI: ISPI: Com Com Com T TO M D (A) (B) (C) 1 1 1

1 1 1 1

1 1 1 1 1

1 1 1 1 1 1 1 1

1 1

1 1

Sum Company A Sum Company B Sum Company C

49 11 16

24 40 3

38 2 2

12 11 0

123 0 0 64 0 0

0 0 21

Total sum

76

67

42

23

123 64

21

Year

Gen Gen Gen Gen Int 1 2 3 4

1996 1996 1996 1996 1996 1997 1997 1997 1997 1997 1997

1 1 1 1 1 1 1 1 1 1 1

1997 1997 1997

1 1 1

1 1 1

208

Ext

1 1 1 1 1 1 1 1 1 1 1

1 0 0

109 10 1 13 0 4

3 50 17

74 37 11

49 27 10

1

110 27

70

122 86

European Journal of Information Systems