Implementing Software Process Improvement: Two ... - Semantic Scholar

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

Implementing Software Process Improvement: Two Cases of Technology Transfer Karlheinz Kautz & Peter Axel Nielsen Department of Computer Science, Aalborg University, Denmark [email protected], [email protected]

Abstract This paper addresses the issue of technology transfer in software development organizations. Common problems for the software industry are still software failures, project overruns, and unfinished projects. To remedy these, knowledge-intensive technologies like quality management and software process improvement (SPI) have been promoted. The organizational implementation of such approaches is an important and problematic matter. Here, two cases of implementing SPI are reported. A framework integrating theories of general innovation with theories on adoption of information technologies is used to present and interpret the cases. The framework consists of three perspectives: an individualist, a structuralist, and an interaction process perspective. The latter comprises the first two and emphasizes the content, context and process of implementation. The framework turned out to be well suited and provided a rich understanding of the interplay of the different elements influencing the implementation process in the two cases. As such, it might be a useful guide for future SPI implementation in organizations.

working group 8.6 on ‘Diffusion, Transfer & Implementation of Information Technology’ (see e.g. the proceedings of their first four working conferences [12, 13, 14, 16]. We will present two cases that deal with implementation of software process improvement activities in two Danish software developing companies. A framework integrating theories on general innovations in organizations and theories on the development and adoption of information technologies in organizations is used to analyze and compare the two cases. By applying the framework in the area of implementing process improvement in software enterprises we were able to understand why implementation was comparably successful in one case and not in the other. The paper is structured as follows. In the next two sections, we will develop our research framework and argue for our research method. In sections 4 and 5, we will present both cases. In section 6, the cases will be compared and discussed with regard to the interplay of the different elements influencing implementation and the knowledge and technology transfer processes. Based on the comparison, we conclude by pointing to the broader implications for understanding and managing implementation processes.

1. Introduction The development of software is known to be a complex task, and despite the progress made by the introduction of methods and techniques, unfinished projects, project overruns, and system failures are still the norm. The limited success of technology-driven approaches has led to a stronger focus on organizational and process-oriented aspects of software development. As a consequence, several innovations in the field of quality management and software process improvement (SPI) have been developed and are promoted for the software industry. Thomsen & Mayhew [20] provide a good overview of current approaches to software process improvements. The organizational implementation of such approaches is an important and problematic issue of knowledge and technology transfer. It has for instance been a controversial issue and thoroughly discussed in the IFIP

2. Research Framework Research on adoption, implementation and transfer of innovations is confronted with a multitude of concepts. Within the field of knowledge management, Gibson postulates in the call for papers [8] for the HICCS 2000 Conference that knowledge management is comprised of knowledge generation, transfer, accumulation, adoption, and diffusion, and he defines technology transfer as the adoption of knowledge. This definition is debatable, both with a view to the concept of adoption and the concept of technology transfer. Within the field of information technology, Cooper & Zmud [4] introduce a six-stage implementation model consisting of initiation, adoption, adaptation, acceptance, routinization, and infusion. Adoption denotes the phase where a decision is made to invest resources to

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

1


accommodate implementation, and acceptance is the phase where the innovation is finally utilized. The concept of technology transfer is, for example, explicated by Lien [15] as part of a chain through which technology moves. According to him, technology development is followed by technology transfer and technology diffusion. Technology transfer is a supply driven and micro-managed movement of technology, whereas diffusion is a demand driven, macro-based

technologies in organizations developed by Walsham [22] and used by Kautz [11] in an earlier paper. The framework is employed to analyze and compare the two cases, and by applying it to the field of software process improvement we aim to understand the interplay of the different elements that influence and drive implementation and the knowledge and technology transfer processes. Literature on organizational innovations can be divided

Basic assumptions

Individualist Change/innovation is caused by individuals

Structuralist Change/innovation is determined by structural characteristics

Conceptualization of a change/innovation

Static and objectively defined objects or practices

Static and objectively defined objects or practices

Conceptualization of the change/innovation process

Simple, linear with focus on the adoption stage

Simple, linear with focus on the adoption stage

Core concepts

Champion Leaders, Entrepreneurs Change agents

Environment Size Complexity Formalization Centralization Professionalism

Interactive Process Change/Innovation is produced by the interaction of structural influences and the actions of individuals Content is perceived, changes/innovations are subject to reinvention and reconfiguration Complex, social process of interrelated events and stages seen from different perspectives Context Innovative capability Proliferation Shocks

Table 1: Perspectives on the Implementation of Innovations (adapted from [19])

movement. Heidtman [9] refers to Fowler & Levine [7] and states that technology transfer can cover the spectrum of events from conceptualization of a new technology through industry wide use. He prefers to use the term technology transition when he describes the process of institutionalizing new tools, techniques or approaches in an organization. Damsgaard et al. [5] talk about penetration to describe the process of information technology uptake through and in organizations. Veryard [21] also uses the notion of penetration, but he criticizes that penetration, like transfer only describes a one way influence: either the organization accommodates itself to the technology or the organization assimilates and transforms the technology. He favors the concept of adaptation, which comprises a two way process and brings us back to the ideas introduced by Cooper & Zmud, but expressed in other terms. Their definition is the starting point for the research presented here. On this background, we have developed a framework that combines theories on the diffusion and adoption of innovations in organizations by Slappendel [19] and theories on the development and adoption of information

into three perspectives, namely an individualist perspective, a structuralist perspective and an interactive process perspective. The first perspective covers characteristics of the individual role players. The second includes structural elements of the organization, such as the interrelationship between its task environments, its size, the degree of complexity of its organizational form, its degree of formalized jobs, its degree of centralized power, and its degree of professionalism, e.g. its general use of plans and methodologies. Where these two perspectives understand innovation as a simple and linear phenomenon, the third perspective sees innovation as a complex, non-linear process consisting of both individual and structural components. The process perspective is emphasized in the second part of our framework. It deals with organizational change in relation to information technology and comprises three components. Obviously, the content of the modifications and of those affected by it plays a significant role. Innovations are not just adopted, but often adjusted, reconfigured, or reinvented. The process component interprets organizational change as caused by the introduction of innovations and as a social process.

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

2


Beyond a mere account of the historical flow of events, it proposes a cultural and a political view for a better comprehension of the change. Finally, the context of the change is crucial, both in terms of external – political and/or market related – circumstances and internal conditions, e.g. inter-departmental conditions. Innovations depend on the organization’s general capability for change and for generating and utilizing new ideas. They are often generated by shocks or striking events. It is important to note that implementation of change has to be understood as a continuous interplay between the three components.

3. Research Method In our paper, we report on two cases. The research method in both of them can be characterized as action research. Action research is an approach that attempts simultaneously to achieve practical value to the client organization and contribute to theoretical knowledge [1]. A number of explanations of action research covers our approach; in particular [2, 3, 6, 10, 18]. In Case I, the researchers have been visiting the organization over a period of two years, and the engagement will continue for another year. Once a month, a full-day meeting has been held in the SPI group attended by three university researchers, two consultants, and four employees from the organization’s software engineering process group, SEPG. At the meetings, the researchers and the consultants act as support (both on theoretical and practical issues) for the organization’s SPI initiative. The support encompasses, but is not limited to, carrying out interviews, running meetings, providing advice, taking minutes. In case II, two researchers have been visiting the organization on a daily basis over a 10-week period, which constituted the start of a still ongoing SPI program. A third researcher was occasionally active, mainly as a supervisor and additional adviser. The two researchers who worked daily in the organization soon became the local specialists on SPI. They formed the most significant part of the SEPG. So far, the SEPG has performed a software process assessment, which has resulted in an improvement plan. Parts of the improvement plan have already been implemented. The research process was documented in a number of ways. First, minutes were taken from the SEPG meetings and shared with members of the group and management. Second, meetings in Case I were recorded on tape and are now available for later reproduction of statements. Third, interviews were conducted and in Case I recorded on tape. Immediately afterwards, elaborate minutes were taken. The interviews have been conducted in accordance with Patton’s guideline [17]. In Case II, the data material was

based on minutes from meetings, written observations and formal assessments as well as informal interviews and conversations. In addition, the engagement in the organizations resulted in several presentations and reports.

4. Case I: High-Tech Measurement The company High-Tech Measurement (HTM) produces hardware and software integrated into extremely complex, specialized high-tech products. The division under study produced instruments for measuring sound and vibration. At the time, the researchers entered HTM the company’s market position had been under significant pressure for 4-5 years. Previously, the company had done well producing products of world-class quality and selling them at high prizes, which, however, customers were willing to pay. There was little competition. But as the competitors learned to produce measurement products of sufficient quality based on inexpensive specialized software for PC’s with a few hardware extensions, competition gradually grew. In this climate, the company’s first reaction was to downsize. Then, survival of the company came to depend on the viability of a few R&D projects. The project managers who survived this phase became vital to the company and extremely influential in all matters concerning projects. The company became very dependent on the performance of the projects. During stabilization of the company, software process improvement was introduced. It was introduced in two ways. First, there was a small group of employees who were engaged in error-driven improvement where classification of errors in software was used to directly indicate beneficial improvements. Second, an external consulting firm performed an assessment of the company’s software processes focussing on technical management. It was the interplay between these two initiatives that fostered HTM’s own approach to SPI. In response to the assessment, a SEPG was established. It consisted of the principal SPI practitioner from the first initiative, a few of his colleagues, one of the project managers, two consultants and three researchers. The SPI practitioners and the project manager worked part-time on SPI, and the researchers and consultants used 2-6 days a month.

4.1. Individualistic Perspective From an individualistic perspective, our research revealed several significant individuals with different role and attitudes. At the introduction of SPI in HTM, the individuals were the project managers, the technical director, the above mentioned principal SPI practitioner,

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

3


and the researchers. In the following, we will interpret their roles. Before the researchers entered the organization, the SPI practitioner had been working with SPI for some time on his own or sometimes with other colleagues - also responsible for the quality system - on identifying beneficial improvements. He had studied error reports and based on their classification he was able to induce where an error could have and should have been avoided. The study of errors was systematic and thorough. Yet, only a few people in the organization took notice of his work despite an effort to communicate and report the findings. Only a few project managers regarded the studies as directly relevant to their projects. They were under pressure to deliver products of high quality on time. Management did encourage the work, but did not ask for improvements; they focused primarily on marketing the company’s products. When the researchers entered the organization, the SPI practitioner was fairly pessimistic about a revival of SPI in HTM. Nevertheless, he became an influential player in the SEPG that was formed. The project managers were hesitant to use resources from their own projects on any improvement activity. During interviews with project managers, it became clear that product development was more prestigious than all other activities, including management and process improvement. Project managers who were able to deliver on time despite horrendous circumstances were promoted. The project managers were the heroes of HTM. As a consequence, the survival of the company was placed in the hands of a few project managers. The technical director of HTM had no prior experience with SPI and its potential benefits. Throughout the two years of the study, the director continued to reward the heroes for their development efforts. He would only occasionally support the SPI initiative. The support would typically be given at large meetings for all developers, while non-support implicitly would be visible through other actions. Three researchers were interacting with the SEPG assisting and advising on SPI matters. The researchers’ role was to facilitate a series of interviews with project managers, to help the SEPG insist on their initiative, transfer knowledge from the outside into HTM, and to study the implementation of SPI at HTM. In addition, consultants performed an assessment just prior to the initiation of the SPI effort. The assessment was offered to the division as part of a national survey of software maturity in the electronics industry.

4.2. Structuralistic Perspective HTM is a division in itself, and internally it is divided into departments. The main departments are R&D,

marketing, production, and sales. The SPI initiative only dealt with software engineering in the R&D department. It is an old company that has all the characteristics of a traditional engineering organization. Within R&D, there was a dominant professional attitude. R&D were organized around professional values exercised in the projects. R&D showed all the characteristics of an organization of professional practitioners. The main focus was on recruiting staff with the right education and experience. Most of the professionals were engineers by education and experience. Work was organized in projects with significant autonomy as long as they delivered on time. The managerial hierarchy was fairly flat, as the project managers wielded considerable influence. Above the project managers was the technical director and above him the CEO. The researchers observed that values and attitudes were focused on high standards in product quality, which often implied a considerable trade-off with delivery time. All professionals experienced a constant battle between product quality and the ability to meet deadlines. HTM had a quality management system certified according to the ISO 9000 series. The quality management system had initially been defined with hardware engineering in mind, but it was also used for software engineering. As a structural element, it created some resistance towards software process improvement because most project managers feared that it would be as useless as they felt the quality management system had been.

4.3. Interaction Perspective Content of implementation. HTM has moved from a situation dominated by product values to a situation where both the merits of products and processes are acknowledged. The balance of the different values is delicate, but HTM has definitely reached a state where software process improvement is considered relevant. They are now in a position where it makes sense to actually improve processes on a large scale. Context. The context of implementation was largely determined by the crisis that HTM had been through. HTM had a fragile market position. They had a small number of products on the market, and any deviation from market plans in the development of a single product was likely to create turbulence for the company as a whole. Management, project managers and developers were painfully aware of this. The crisis had become the governing force for the R&D department. Emphasis on products prevailed. Furthermore, the professional values of the engineers dominated the organization, i.e. solutions

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

4


produced now were better than improving processes and competence in preparation for tomorrow. These values were at the very center of the culture that provided the context for implementing SPI. Consequently, implementation of SPI was tough, as none of the professionals would admit that they had any problems with software processes. However, interviews with project managers by the researchers and the SEPG showed significant problems with software processes. According to the project managers, the problems were related to management issues, such as insufficient resources, political deadlines, etc. Only a few project managers were able to see that there might be problems with their own practice. There was almost no experience in HTM with SPI, and the project managers had no background for understanding that their perceptions were the main obstacles for implementing SPI and benefiting from specific SPI initiatives. Process. There is a huge body of experience with SPI as well as theories and models of successful SPI. According to the researchers, it would only be feasible to implement this body of knowledge in HTM if the project managers were able to perceive the problems to which SPI was a solution. If they did not understand the problems and did not give them a high priority, the implementation would fail from the very beginning. As a consequence, implementation of SPI in HTM was directed at the project managers. A major effort based on systematizing errors by a dedicated SPI practitioner was both a failure and a success. The effort failed to overcome any of the immediate defenses in the project culture. The effort did, however, give the SPI practitioner an experience of what did not appear to work in HTM. The actual techniques developed during this effort slowly gained momentum and most new projects will in the future engage the techniques in their development. In the end, the interaction process between the one proactive individual and the hesitant organization turned out to be useful. A small, but visible effort to perform an assessment was efficient to determine the need for SPI. However, little happened as the report was delivered to management. The project managers remained largely untouched by the findings or were without power to effectively deal with the planning of SPI on their own. Based on these two efforts, a SEPG was formed and a contract was signed with the researchers and consultants. Until now, the SEPG has had several minor failures and two significant successes. The following were failures. The SEPG never established a plan for the SPI effort. The original strategy was to let project managers handle the improvement assisted by the SEPG. However, in reality it turned out that the SEPG handled the improvement

assisted by the projects. An attempt to improve the area of re-use also failed dramatically. Everybody agreed that it was important, but there was a latent conflict on how to manage re-use. An attempt to improve the area of project planning and tracking has also suffered major setbacks. The idea was simply to buy a planning tool and implement it in the projects. The technical director initiated the improvement, although the SEPG knew that buying more tools rarely effects change. After a year and a half, the tool has not yet provided the desired functionality. On the other hand, it was a success that the SEPG, the researchers, and the consultants interviewed the project managers, which enabled them to build on the managers’ perceptions when suggesting improvement areas. The project managers regarded the interviews as very useful, also for the projects. It resulted in a strategy stating that all improvement efforts had to be directly useful for the projects. In addition, it might explain why the other efforts failed. None of these efforts had been connected to areas where the projects had expressed a real need. A second success was the creation of support teams through the SEPG and the researchers. A support team was made responsible for transferring new ideas and specific support to a designated project within an improvement area, e.g., a new process model. The team meets regularly with the projects to assist them in applying the new ideas and is constantly trying to be useful to the projects.

5. CASE II: Network Products The company Network Products (NP) was one year old when implementation of SPI was launched. The company wanted to pursue an innovative solution for presentation of information on 20000 warehouse items on a 14’’ screen through a slow network in a fast and structured way. The aim was to have the product ready for the market before any competitors. At the time, the company had 25 employees where 15 were directly involved in software development and the rest in business administration, marketing, and sales. Software development is roughly divided into two departments of equal size. A production department deliveres standard intra- and internet solutions. This department generates the company’s present income. The other department is R&D and deals with the future product. R&D are to some extent financed by public money. Our investigation was directed at software development in R&D. During our study, the first version of the product was still under development. From the start of the company, NP showed an original interest in quality and quality management matters. Management wanted to establish all basic software

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

5


processes and keep them under control as soon as possible. This step was considered particularly important because the company expected a considerable increase in staff. NP took the initiative to contact the researchers.

manager. Two technical working groups were temporarily established to develop and implement concrete improvement proposals.

5.3. Interactive Process Perspective 5.1. Individualistic Perspective The following individuals were involved in the implementation of SPI: the managing director, the researchers, one project manager, and the developers. Management played an important role as the driving force behind the whole improvement effort. They took the first initiative and contacted the researchers because they felt a need for knowledge on SPI. They provided the necessary resources and took actively part in meetings with the researchers and the staff. At times, management was even too enthusiastic entertaining too high expectations. The researchers acted as specialists in software process improvement. They performed an assessment and prepared an oral and written presentation of the results. They worked as facilitators in the implementation process. As mentors and coaches they supported the developers during the planning and implementation of the improvement proposals. The developers were actively involved in each phase of the implementation. When the current processes were analyzed, they were asked to give their opinion on improvement proposals. They also elaborated and implemented the improvement proposals themselves. Finally, the project manager played a significant role. As a respected employee, he was the mediator between the researchers and management and championed the initiative through his active involvement in all activities.

5.2. Structuralistic Perspective NP was a simple organization where the two founders were managing directors. They were involved in all decisions one way or another. The work in R&D was project-oriented. Two project managers were coordinators for a varying number of subprojects where the developers in groups of 4-5 persons performed all development tasks. These project groups often emerged on an ad hoc basis. Normally, they only existed for a short period of time and were dissolved when they had solved the problem. A contract was negotiated and signed between management and the researchers. The contract contained a preliminary project plan, defined the resources for the project, and the expected deliverables. A SEPG was defined and given the task of supervising, supporting, and performing the improvement activities. It consisted of the two researchers and the influential project

Content of implementation. Implementation of SPI in NP aimed to supply SPI knowledge from the outside and organize the first SPI activities. The researchers provided the SPI knowledge and the actual SPI activities included a general organizational analysis, an assessment of the software processes, production of an assessment report, and a resulting action plan as well as implementation of the first improved process. Context. The organization’s environment featured a growing market with growing competition. NP aimed at gaining a reputation as an organization known for its competence and emphasis on quality. NP wished to produce a product of high standards based on professional craftsmanship. For a limited period of time, NP’s financial foundation was largely based on EU support for development of new businesses. In its business plan, which was also a contract with the sponsor, NP had committed itself to create a quality assurance group or division, and it was determined that some of the resources had to be used for this objective. An entrepreneurial and frank atmosphere that supported internal communication and co-ordination of mutual adjustment characterized NP. The organization was project-oriented and displayed a creative, dynamic, energetic and at times hectic environment. To nourish such a culture, NP employed largely young, newly graduates in information systems and computer science, who had no ‘bad’ habits and were open to innovations. Management made the strategic decisions on business and products. They expected that everyone would take on responsibility and work for a common interest. The management style can be described as management-bywalking-around. The project managers maintained an overview of the technical tasks and achievements, and the software developers had a large degree of autonomy. The autonomy covered the solutions to technical problems, including the purchase of tools and other materials. The staff showed commitment, was highly motivated and often worked overtime. Process. The implementation of SPI and the concrete improvement activities were performed according to a framework, the so-called IDEAL model, which consisted of five phases. After the Initiating phase, the Diagnosing phase, the Establishing phase, the Acting phase, and the Leveraging phase followed. All phases were part of the

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

6


first cycle in the structured approach to continuous improvement. The adjustment of the abstract model to the concrete situation at NP was part of the project. In the first phase, the expectations of the groups involved were clarified and the immediate goals were established. The contract was signed and the SEPG was established as part of the infrastructure. In this process, the researchers, the project manager and management were most active, but all developers were informed about the proceedings at a meeting where consensus was reached on improvement of software processes. In the next phase, the researchers assessed the organization by interviewing the staff and making a survey among the project managers. Document studies and observations supplemented these activities. Again, everyone was involved and invited to contribute with any concrete experience they might have. The researchers identified acute problems and long-term improvement needs, which were presented to the staff at a meeting. In the establishing phase, the improvement proposals were further elaborated and placed in a life cycle model that illustrated where the proposals would be most appropriate in the organization’s software development process. On this basis, it was easy to prioritize the necessary actions and show that fast progress was possible. The SEPG performed most of the activities. Partly in parallel, the two working groups, consisting of all the developers, tried to solve the two acute problems, namely the lack of meeting structures and the lack of code documentation guidelines. Within one week, both problems were solved and the solutions implemented. Leveraging in the sense of learning took place during the whole period. After the original project period, the two researchers evaluated the whole process. The improvement that had been implemented consisted of rules on meeting performance. After some use, it was determined to abandon the code documentation guidelines. According to the project manager, it was due to time pressure and lack of control. In general, management preferred as little formalization as possible, whereas the developers would have liked a little more formalization. Nevertheless, both groups considered the project a success. The lessons that were learned and a refined action plan have been used to continue the improvement efforts in NP and to implement new processes and procedures for project planning, quality assurance and configuration management. More than a year after the initial improvement project, the two researchers are now full-time employed by NP as process improvement specialists.

6. Discussion and Conclusion The discussion falls into three parts. The framework that we have presented consists of three perspectives: the individualist, the structuralist, and the interaction process perspective. It is based on the insight that both the individualist and the structuralist perspectives are incomplete accounts of the implementation of innovations in organizations. The interactive process perspective encompasses the other two positions and provides a better understanding of the implementation process compared to the other two perspectives. The interpretation and comparison of the two cases serve as a practical confirmation of our claim and show that the framework also can be applied in the field of software process improvement. This is the basis of the first part of our argument. However, the interactive process perspective goes beyond a mere combination of elements from the two other perspectives. It also considers the complex interplay of the various factors. For this purpose, the framework introduces further concepts that provide an even broader understanding of the phenomenon. By contrasting the two cases, this aspect will be demonstrated in the second part of our debate. Finally, we will address to what extent technology transfer in the context of software processes actually means knowledge transfer and what impact this issue has on understanding the cases. When we compare the cases, it appears that implementation of software process improvement has had less impact on HTM than on NP. HTM has struggled with a frequent loss of momentum in the implementation process. NP has been both efficient and effective in their efforts to improve at least some software processes. Here, the individualist perspective offers a simple explanation, namely that HTM had no champion who could recreate momentum by being persuasive and powerful. In NP, the managing directors acted as champions striving to improve by encouraging, arguing, and convincing the SEPG and the developers to get the implementation process off the ground. Applying the individualist perspective provides a useful insight, but it is insufficient and gives only a partial explanation. However, the structuralist perspective offers a complementary explanation. HTM is an old, large and departmentalized organization. The SEPG was in charge of the implementation process, but the members had many other obligations that competed for their time and resources. It is unclear to what extent and in which way the SEPG had the mandate to involve developers in the implementation process. The group fought a constant battle to commit others and to gain sufficient resources. The SEPG and its

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

7


competence did not have a central position at HTM. In contrast, NP is a young and small organization where everyone literally works in the same room. Two of the SEPG members only had one task, namely to drive the implementation process. The SEPG was visible and enjoyed a central position. In fact, one of its members was the project manager of the most significant project in NP. Again, analyzing the difference from a structuralist viewpoint provides a useful insight, but it is still insufficient and gives only a partial explanation. In the discussion of the individualistic perspective we have used the core concept of champion, and in the structuralist perspective we have applied the core concepts of size and centralization. We could also explain the different outcome of the cases by utilizing other core concepts such as change agents and the environment of the innovation’s implementation, but that is not the point here. What is important is that neither of the two perspectives are sufficient on their own. To apply both perspectives at the same time, relate their elements to each other and to reinterpret the cases based on the juxtaposition of the two perspectives make the difference. The interaction process perspective focuses on the interaction between the actions of individuals and the structural influences. In HTM, both the absence of a champion and the peripheral SEPG slowed down implementation. But these elements were not unrelated incidents as one led to the other and vice versa. In NP, there was a champion and the SEPG was centrally positioned; implementation gained momentum by a combination and interplay of the two factors. Applying the interaction process perspective on implementation of SPI allows us to interpret the two cases even further. In our exploration we will not combine core concepts from the individualist and the structuralist perspective. Instead, we will explicate the two cases in the light of the core concepts of the interaction process perspective: context, innovative capability, proliferation, and shocks. The context of implementing SPI in HTM was dominated by the dramatic decrease in market shares. For a while, the company had been following its usual survival tactics, i.e. to market a better product as soon as possible. The tremendous focus on survival had - at least temporarily - impaired the company’s verve and ability to work on improved software processes. The improvement of software processes would create an overhead in the short run, but would be an investment in the long run. The benefits of a proper implementation of SPI might pay off eventually, but only to a limited extent, if at all, in the running projects. Thus, all the innovative capabilities and competence of the project managers and the software developers were directed at creating new and better products. With regard to software processes, there was no

innovative capability. Management was reluctant and provided little support for the SEPG members in the R&D department. Consequently, development and dissemination of new ideas and practices, in other words, proliferation was almost absent and visions of a better future were vague. In contrast, the context of NP was dominated by the company’s strong desire to be among the best organizations on the marked in future. Very early on, management realized that software process improvement might increase the likelihood of achieving this goal. It was first of all management who had the time and energy to think of the future, as the project managers and the systems developers were under permanent pressure to reach their deadlines. Management, however, communicated their thoughts to everyone. Yet, NP had not experienced any dramatic setback. The company’s whole philosophy was based on taking risks, of which it was fully aware: the aim was to develop just one major product hoping that it would sell on the market. Such an attitude will certainly create an aspiration for improvement. Furthermore, in NP there was plenty of room for proliferation. Management constantly encouraged new ideas and practices, and the software developers, most of whom had just graduated from university, had considerable, innovative capabilities. Their prevailing attitude was a curiosity and interest in learning new things which led to an openness towards any innovation that might enhance their work routines and the products. In addition, it provided the ground for implementation of software process improvement. The above application of the interactive process perspective together with elements elucidated through the other two perspectives has provided an ample understanding of the two cases, but has not covered all aspects of the implementation process. Therefore, we want to return to the concepts of environment and change agents, but within the wider context of the interactive process perspective. In both cases, external actors, researchers and consultants introduced SPI from the outside to the organizations. Thus, implementation of SPI can partly be interpreted as a process of technology transfer. Furthermore, SPI consists primarily of a body of knowledge which in order to be implemented must be transferred to the organization and adopted by it. Or better, adaptation has to take place. HTM made a relatively modest effort to bring in and utilize SPI as a body of knowledge, and the transfer of SPI knowledge was rather slow. There are several possible explanations for this approach. There were only few dedicated change agents with SPI knowledge in the organization, and the external experts with SPI knowledge, the academic researchers, found it difficult to establish their credibility in the eyes of the project

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

8


managers. The project managers were reluctant to absorb new ideas as they were focused on the development of products. It was a common attitude that it is better to develop your own experience than rely on others. In NP, the efforts to assimilate and accommodate knowledge were considerably higher as two employees out of a staff of nearly twenty-five did nothing else. The transfer was initiated when the two researchers introduced the SPI knowledge in the organization. Through cooperation with a project manager in the SEPG, the researchers quickly became adopted and respected in NP. The transfer was facilitated because the project managers and systems developers were eager to incorporate the new ideas and because they relied on the experience of others in a situation where their own competence was insufficient. The preceding discussion based on the interactive process perspective on innovations in organizations has shown the usefulness of our framework. It has convincingly shown why one of the case organizations, HTM, had a hard time with adaptation of SPI and only achieved a limited penetration of SPI knowledge and a slow implementation of SPI. It has also explained in a credible manner why the other organization, NP, was more successful. The company was very dedicated, which paid off. The knowledge of SPI was greatly diffused and intensively used to improve the company’s performance. Thus, beyond supporting the understanding of the two cases, our framework might be useful for future implementation of SPI in other organizations.

References [1] Avison, D., F. Lau, M. D. Myers, and P. A. Nielsen, (1999). Action research. Communications of the ACM, 42(1):94-97. [2] Checkland, P., (1981). Systems Thinking, Systems Practice. Wiley, Chichester. [3] Checkland, P., (1991). From framework through experience to learning: the essential nature of action research. In: H.-E. Nissen et al., editors. Information Systems Research: Contemporary Approaches & Emergent Traditions. North-Holland, Amsterdam. [4] Cooper, R. B. & R. W. Zmud (1990), Information technology implementation research: A technological diffusion approach. In Management Science, Vol. 36, No. 2, pp.123-139. [5] Damsgaard, J. et al. (1994), How Information technologies penetrate organizations: an analysis of four alternative models. In Levine L. (1994), Diffusion, Transfer and Implementation of Information Technology, Proceedings on the IFIP TC8 Working Conference, North Holland, Amsterdam, The Netherlands, pp. 1-22.

[6] Foster, M., (1972). An introduction to the theory and practice of action research in work organizations. Human Relations, 25(6):529-556. [7] Fowler, P. & L. Levine (1992), Toward a problem solving approach to software technology transition. In Van Leeuven, J. (ed.), Proceedings of the 12th IFIP World Computer Congress, Vol. 1, pp. 57-64, North Holland, The Netherlands. [8] Gibson, D. V. (1999), HICCS 2000, Call for Papers, Organizational Mini Tracks: Knowledge/Technology Transfer and Adoption. URL: http://www.hicss.hawaii.edu/HICSS_33/orgcfp.htm, May 15, 1999. [9] Heidtman, S. E. (1994), Exploration of an incremental approach to technology transfer and the issues affecting its implementation. In Levine L. (1994), Diffusion, Transfer and Implementation of Information Technology, Proceedings on the IFIP TC8 Working Conference, North Holland, Amsterdam, The Netherlands, pp. 347-351. [10] Hult, M. & S.-Å. Lennung, (1980). Towards a definition of action research: a note and bibliography. Journal of Management Studies, 17(2):242-250. [11] Kautz, K. (1996), Information Technology transfer and Implementation: The introduction of an electronic mail system in a public sector organization. In Kautz, K. & J. Pries-Heje (eds.), Diffusion and Adoption of Information Technology, Chapman & Hall, London, UK, pp.83-92. [12] Kautz, K. & J. Pries-Heje (eds.) (1996), Diffusion and Adoption of Information Technology. Proceeding of the 1st IFIP 8.6 Working Conference, Chapman & Hall, London, UK. [13] Larsen, T. & L. Levine (eds.) (1998), Information Systems: Current Issues and Future Changes, Proceedings of the IFIP WG 8.2 & 8.6 Joint Working Conference, IFIP Laxenburg, Austria. [14] Levine, L. (ed.) (1994), Diffusion. Transfer and Implementation of Information Technology. Proceedings of the IFIP TC8 Working Conference on Diffusion, Transfer and Implementation of Information Technology, North Holland, Amsterdam, The Netherlands. [15] Lien, L. (1995), Toward a management model for the transfer of technology. In Kautz, K. et al. (eds.), Diffusion and Adoption of Information Technology, Conference Notebook from the 1st IFIP 8.6 Working Conference, Norwegian Computing Center, Report No. 900, Oslo, Norway, pp. 153-166. [16] McMaster, T. et al. (eds.) (1997), Facilitating Technology Transfer through Partnership – Learning from Practice and research, Proceedings on the 2nd IFIP 8.6 Working Conference, Chapman & Hall, London, UK. [17] Patton, M. Q., Qualitative Evaluation, Sage Publications, 1983.

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

9


[18] Rapoport, R. N., (1970). Three dilemmas in action research. Human Relations, 23(6):499-513. [19] Slappendel, C. (1996), Perspectives on Innovation in Organzations. In Organization Studies, Vol. 17, No. 1, pp. 107-129. [20] Thomsen, H.E., P. Mayhew (1998), Approaches to Software Process Improvement. In Software Process Improvement and Practice, Vol. 3, Issue 1, pp. 3-17. [21] Veryard, R. (1995), IT implementation or delivery? Thoughts on Assimilation, Accommodation and Maturity. In Kautz, K. et al. (eds.), Diffusion and Adoption of Information Technology, Conference Notebook from the first IFIP 8.6 Working Conference, Oslo, Norway, Norwegian Computing Center, Report No. 900, pp. 181194. [22] Walsham, G. (1993), Interpreting Information Systems in Organizations, Wiley Series on Information Systems, Chichester, UK.

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

10