CHANGING SOFTWARE DEVELOPMENT: A CASE STUDY AT SAP AG

Transcription

1 CHANGING SOFTWARE DEVELOPMENT: A CASE STUDY AT SAP AG Ralph Trittmann Universitaet zu Koeln, Lehrstuhl fuer Wirtschaftsinformatik Albertus-Magnus-Platz, D Koeln, Germany Phone: ; Fax: trittmann@informatik.uni-koeln.de Dirk Stelzer Universitaet zu Koeln, Lehrstuhl fuer Wirtschaftsinformatik stelzer@informatik.uni-koeln.de Andreas Hierholzer SAP AG andreas.hierholzer@sap-ag.de Werner Mellis Universitaet zu Koeln, Lehrstuhl fuer Wirtschaftsinformatik mellis@informatik.uni-koeln.de Published in: Jan Pries-Heje, Claudio Ciborra, Karlheinz Kautz, Josep Valor, Ellen Christiaanse, David Avison, Claus Heje (Eds.): Proceedings of the 7th European Conference on Information Systems - Copenhagen Business School - Copenhagen, Denmark June 1999, Volume 2. Kopenhagen 1999, pp

2 CHANGING SOFTWARE DEVELOPMENT: A CASE STUDY AT SAP AG ABSTRACT The ISO 9000 quality standards, the Capability Maturity Model, and several other guidelines give recommendations to conduct software process improvement. Software process improvement usually requires considerable changes of technological and managerial tasks in software development. However, the guidelines do not provide detailed prescriptions of how to accomplish the change process. Little is known about how efforts to change software development are actually conducted. This paper describes findings of a case study into efforts to change software development at SAP, a leading software company. The case study explores general characteristics of change projects at SAP. It also identifies seven factors that distinguish successful from less successful change efforts at SAP. We compare the findings of the case study with recommendations to accomplish the change process given in the ISO 9000 quality standards. The findings may be helpful for future research into changing software development. They may also provide interesting insights for other companies aiming at software process improvement. 1. INTRODUCTION Software development is an integral element of information systems development. In spite of its particular relevance software development is often troubled by cost overruns, late deliveries, low product quality, and users dissatisfaction (Gibbs, 1994; Jones, 1996). Various sectors of the software industry are confronted with increasing instability due to continuous changes of technology, unpredictable strategies of competitors, and rapidly changing customer needs (Anderson, 1996; Arthur, 1996). These conditions require that software companies are capable to continuously adapt to their environment and to set up aggressive market strategies in order to maintain or to achieve competitive advantage. This, in turn, requires permanent product innovation and continuous improvement of software development processes. Innovation and improvement demand changes in different activities of software companies. The management of change has been explored by various disciplines, for example, by research into social science (Lewin, 1958), organizational development (Bennis, 1969), organizational transition (Beckhard & Harris, 1987), organizational transformation (Nadler et al., 1995), diffusion of innovations (Rogers, 1995), and organizational learning (Argyris & Schoen, 1996). However, studies exploring options and issues associated with changing software development are rare. This paper focuses on one area of change, namely changing software development. Changing software development in order to achieve improvements in product quality, cycle time, and development costs is addressed by the software process improvement literature (Paulk et al., 1995; Stelzer et al., 1996). ISO (1994) defines a process as "a set of interrelated resources and activities which transform inputs into outputs.... Resources may include personnel, finance, facilities, equipment, techniques and methods". Correspondingly, a software process can be defined as "a set of activities, methods, practices, and transformations that people use to develop and maintain software and the associated products" (Paulk et al., 1995). The term software process improvement denotes the "changes implemented to a software process that bring about improvements" (Olson et al., 1989). In the following we will use the terms software process improvement and changing software development interchangeably. The Capability Maturity Model (Paulk et al., 1995) and the ISO 9000 quality standards (ISO , 1994) provide guidelines for improving software development. The models and standards describe options

3 for changing the process of software development in order to achieve improvements in quality, costs and cycle time. European software organizations tend to use the ISO 9000 quality standards as a guideline for improving software development. SAP, the software company considered in our paper, has implemented an ISO 9000-based quality system. Therefore, we will focus on the ISO 9000 standards. A software company that has implemented an ISO 9001-certified quality system has to conduct continuous improvement of all processes. The corresponding recommendations in the ISO 9000 family are outlined in clause 15 of ISO (1994) and in clause 4.14 of ISO 9001 (1994) and ISO (1997) under the heading corrective action. Corrective action aims at improving the processes of an organization. Loken & Skramstad (1995) have analyzed certification reports of some 40 major software development companies in Europe. They found that on the one hand corrective action is considered to be the most useful of all ISO 9001 clauses. On the other hand, corrective action is considered to be one of the most difficult clauses. It also represents an area where many nonconformances are revealed during the certification process. ISO 9000 tells software organizations what to improve. However, the standards do not specify how to effectively implement the change process. Several empirical studies have come to the conclusion that change management is one of the key issues to achieve successful transitions of software processes (Cattaneo et al., 1995; Coffman & Thompson, 1997; Stelzer et al., 1998a). However, there are only few studies that describe how changing software development is actually managed. The findings of the studies mentioned above indicate that changing software development is a complex, time-consuming and difficult task. When we first had the chance to participate in and to observe software development at SAP we had a completely different impression. Improving software development did not seem to be difficult or unusual. Staff members initiated, conducted and supported improvement efforts whenever they considered elements of software development inefficient or when they noticed improvement options. The paper has three objectives: First, to describe findings of a case study exploring the characteristics of efforts to change software development at SAP. Second, to identify factors that contribute to the success of change efforts at SAP, and third, to compare the case study findings with the ISO 9000 recommendations. 2. METHODOLOGY The case study at SAP aimed at gaining a better understanding of change efforts in software development at SAP. Research and theory about change projects in software development are at their early, formative stages. Consequently, the research procedure followed an explorative approach. The research form of a case study was chosen because it is well-suited for conducting explorative research. Benbasat et al. (1987) describe a framework for conducting case research. Our study draws on this framework. 2.1 Site Selection SAP seemed to provide an interesting research field because of its extraordinary commercial success. Founded in 1972, SAP has realized a yearly sales growth by an average of 44 percent and has become the worldwide market leader in enterprise software (SAP AG, 1997). The development of their major product SAP R/3 mainly takes place at Walldorf, Germany. SAP s development organization is divided into several development areas, which in turn are divided into several development departments. The size of SAP (about employees by the end of 1997) required a limitation of our research to the logistics development area, which employed approximately 800 employees at the time of our research. SAP has implemented a quality system which has been certified according to the ISO 9001 (1994) standard. The quality system covers all of SAP s software development.

4 2.2 Units of Analysis Efforts to change software development at SAP are usually conducted in an incremental way. Therefore, they are only seldom explicitly documented. For this reason, the examination of change efforts was performed by interviewing staff members involved in the change efforts. In order to avoid subjective bias interviewees were split into two groups: First, staff members actively participating in the design and implementation of the change project, and second, people passively affected by the results of the change efforts. Each of the change efforts included in our study was represented by at least one person from each of the two groups. Thus, the study investigated each change effort from two different perspectives. 2.3 Data Collection Data collection was mainly performed by interviewing staff members involved in each change effort. These interviews were based on a standardized interview guideline. This method facilitates impartiality of the researcher and provides the option for systematic data analysis. The interviews were supplemented by analyzing internal SAP documents in order to understand the peculiarities of software development at SAP in greater depth. We conducted a pre-study in the form of interviews in order to identify change efforts. A random sample of 29 employees were chosen as interviewees. These employees were asked about the subject, staff members involved, success and general structure of the change efforts which they were involved in. The interviews allowed us to pinpoint 21 efforts. The overwhelming majority of these change efforts was characterized to be successful by our interview partners. We selected six successful and six less successful efforts in order to identify success factors of changing software development at SAP. During the pre-study we also identified characteristics that are essential to describe change efforts at SAP in detail. These characteristics were complemented by findings of previous studies into success factors of software process improvement (see for example Stelzer et al., 1998b). On this basis we constructed a standardized interview guideline to be used during the detailed case study. The 12 selected change efforts were analyzed by conducting 36 interviews based on the interview guideline. For every effort analyzed, we made sure that at least one representative of both, the actively participating and the passively affected people, was interviewed. The answers of the interviewees were documented during the interviews. 2.4 Data Analysis There are no objective metrics to assess the success of efforts to change software development at SAP. Therefore, we used subjective perceptions of interviewees as indicators of the success of change efforts. We characterized a change effort as successful if both, actively participating and passively affected people considered the respective change effort successful. We characterized a change effort as less successful if either participating or affected staff members considered the change effort less successful or if the change efforts were cancelled. When analyzing the interview documents we aggregated matching answers of interviewees from successful change efforts to factors. We did the same for less successful efforts. We then compared the factors identified in both groups. If a factor had different values in both groups we assumed that this factor had an impact on the success of change efforts at SAP. The method for identifying success factors is described in more detail by Trittmann (1998). During the data analysis we identified 24 success factors of change efforts at SAP. However, the data analysis was based on assumptions about cause-effect relations and on correlations between the identified factors and the success of change efforts. We therefore conducted 12 supplementary interviews with staff members to evaluate whether they considered these factors to be essential for the success of change efforts. The 12 interviewees were asked to evaluate the factors according to the perceived significance for the success of the change efforts. Each factor was evaluated to be significant.

5 3. CHANGE EFFORTS IN SOFTWARE DEVELOPMENT OBSERVED IN CASE STUDY AT SAP AG This section describes the results of the case study into change efforts at SAP. After a brief presentation of the investigated projects we will present characteristics that were generally found in these projects. Finally, factors will be explained that seem to have an impact on the success of change efforts at SAP. 3.1 Observed Change Efforts in Software Development In our case study we analyzed 12 change efforts in software development at SAP in detail. These will be described briefly regarding the subject and the area that the change had an impact on. Improving the testing process: This change effort led to an additional testing phase being added to the testing process applied by SAP. This effort affected all development areas at SAP. Customer feedback program: The customer feedback program was designed to introduce rules for visiting external customers by so-called information developers. This change effort was aimed at improving the analysis of customer needs regarding documentation, help texts, etc. Handling of product change requests: This project included changes of processing product change requests from customers. It also comprised changes to development tools in order to automate the new way of handling product change requests. This change effort affected all development departments. Documentation of specification and design: This change effort aimed at explicitly defining rules for the documentation of specification and design. This project concerned both, creation and review of documents. Again, all development departments at SAP were affected. Improving communication between development departments: This improvement project comprised measures improving coordination between two development departments. These departments occasionally develop program objects simultaneously. Managing the conflict between coding and testing: This change effort aimed at smoothing the conflict between coding and testing of SAP s software. One particular aim was to increase the priority given to testing in the entire company. Measures promoting undisturbed working: Measures to eliminate disturbing factors at the work place were the subject of this improvement project. It was initiated in one development department. Module redesign: The project Module redesign was meant to change the design guidelines for program modules. It focussed on de-coupling user interface from program logic. Existing modules were redesigned according to these guidelines. The change effort was limited to one development department. Personnel backup concept: Introducing the personnel backup concept included measures of coordination and training in a development department. The idea was to guarantee that at least two developers would be capable of carrying out any task of product development and customer service that their department was responsible for. Problem management: Problem management refers to assigning responsibilities in dealing with customer problems. This change effort had the objective to improve problem management in one development department. Corporate-wide design tool: This change project aimed at introducing a corporate-wide automated design tool for all software developers at SAP. Reorganization of internal audits: The reorganization concerned changes to planning, implementing and evaluating of internal audits. These changes affected quality management in the entire company.

6 3.2 General Characteristics of Change Efforts in Software Development Analyzing the changes to the process of software development described above led to the identification of general characteristics of change projects at SAP. These characteristics were found in successful as well as in less successful change efforts. Numerous changes to software development All 29 employees of SAP interviewed during the pre-study were involved in at least one change project in the past 12 months. Thus, it seems that change efforts at SAP occur remarkably frequently. This becomes even more remarkable considering that there is no incentive system for participating in change efforts and successful changes do not lead to rewards or other kinds of acknowledgment. Decentralized change projects SAP does not have any specialized department in charge of planning, directing and controlling improvement projects. There is no institutionalized suggestion scheme at SAP, either. Rather, the majority of change projects proceeded in a decentralized way. Employees took care of problems they had noticed, made use of improvement options, and initiated corresponding changes. No formal planning for the change efforts Change efforts at SAP do not rely on formal planning. They seem to be carried out as informally as they come up. As an example, none of the analyzed projects included a prior cost-benefit-analysis, and in only one of the projects milestones were defined for its implementation. Implementation decisions without explicit criteria No decision about the implementation of a project was based on explicit decision criteria. As a rule, decisions are the result of a discussion among all participating staff members. The decisions are neither based on an analytical decision process nor supported by well-founded data. No specific success measurement None of the analyzed projects included specific success measurement. The success evaluations were primarily based on individual perceptions. In occasions, they were supported by employees feedback or that given by external customers. A systematic satisfaction survey, however, was not done in any of the projects. Individual freedom for staff members SAP s staff members enjoy marked individual freedom. In the context of the analyzed projects, this became apparent in the freedom to initiate and conduct improvement efforts with hardly any constraints. This freedom also includes top management decisions being questioned. Their disregard does not have negative consequences for staff members. Little efforts to review and spread findings Little efforts could be identified concerning reviewing and spreading the results of a change project. As an example, apparently in none of the projects a review was conducted. Only in one change effort the results were spread outside the immediately affected area. In this case, the results were published in the inhouse magazine SAP inside. 3.3 Success Factors of Change Efforts in Software Development We identified 24 factors which seem to have an impact on the success of change projects at SAP. However, due to the brevity of this paper it is not possible to describe all 24 success factors in detail. Therefore, in the following only those seven factors will be explained that distinguish best between successful and less successful change efforts. Trittmann (1998) provides detailed information on the remaining factors.

7 As shown in figure 1, these factors in general can be found in all successful change efforts, yet in only very few of the less successful ones. Figure 1. Presence of success factors Consistent perceptions of change objectives Managing resistance Promoter for the change efforts Precise change objectives Optional application of improvement results Collective decision process Involvement of affected staff members Number of less succesful change efforts Number of successful change efforts Consistent perceptions of change objectives Perceptions of change objectives denotes the degree to which people involved in the change efforts perceive the objectives consistently. We asked the interviewees to describe what they perceived as the objectives of the change efforts they were involved in. All employees in successful change efforts named the same goals, respectively. They described the goals with similar precision. In less successful change efforts the interviewees named heterogeneous objectives. Most notable of all were the marked differences in the perception of change objectives between those actively participating in the design of the changes and those passively affected by these changes. Managing resistance Managing resistance describes the efforts that are made to minimize potential resistance of staff members affected by the change efforts. In all successful change efforts a conscious analysis of potential resistance was carried out. As an example, possible conflicts were anticipated and taken into account while implementing changes. Moreover, changes were introduced incrementally, and criticism voiced in the process was used directly to modify the change efforts. Comparable activities, however, could be identified in only one of the less successful improvement projects. Promoter for the change efforts A promoter is a person that initiates, guides, controls, and supports the change efforts. This individual encourages participation in the improvement efforts and establishes communication between staff members participating in and affected by the improvement efforts. All successful improvement projects included in our study were initiated, guided, and promoted by at least one promoter. When asked about the change efforts not implemented participants explicitly mentioned the lack of a promoter as an essential reason for not carrying out the planned changes. Precise change objectives Objectives of change efforts may be precisely defined, or the change efforts may be characterized by woolly objectives. All successful change efforts considered in our study had precise objectives. However, with the exception of two projects all less successful improvement efforts were characterized by woolly

8 objectives. As an example, objectives were described precisely in the Customer Feedback Program, while in a different, less successful effort only the general goal of quality improvement was mentioned. For this success factor it is irrelevant whether objectives are formulated quantitatively or qualitatively. Rather, it seems to be important that they be capable of guiding the change activities of all employees participating. Optional application of improvement results Efforts to change software development usually result in improved activities, processes, documents, methods or tools. Application of these improvement results may be mandatory or optional. Mandatory application means that staff members are compelled to apply the results of the change effort. Optional application means that staff members are free to choose whether or not to adopt the improvement results. Optional application is positively correlated with the success of improvement efforts at SAP. In all less successful change efforts included in our study staff members affected by the change projects were compelled to apply the improvement results. With the exception of one project all successful change efforts left it up to staff members whether or not to adopt the improvement results. Collective decision process The process of deciding whether to implement or to reject a change project may be collective or authoritative. Collective decision processes are based on an agreement of all staff members participating in, or affected by the change project. In all successful change efforts the decision whether and how to implement a change effort was based on agreement. It resulted from a discussion about the change effort, which integrated as many people of those involved as possible. These characteristics of the implementation decision could only be identified in two of the less successful change efforts. The other less successful change efforts were either marked by an authoritative decision process or were cancelled before any explicit implementation decision could be taken. Involvement of affected staff members Involvement of affected staff members denotes the degree to which staff members that are affected by the change efforts are involved in the change process. In successful change efforts staff members participating made considerable efforts to actively include those employees who would later be affected. This was achieved, for example, by integrating representatives of affected staff members. In most of the less successful change efforts the employees affected by the changes were not included in the designing of the changes. 4. COMPARISON OF THE CASE STUDY FINDINGS WITH THE ISO 9000 RECOMMENDATIONS The case study has revealed several aspects of how software development is changed at SAP. In this section we will first summarize recommendations to continually change software development made in the ISO 9000 quality standards. Second, we will briefly compare these recommendations with characteristics of improvement efforts observed in our study. Third, we will attempt to explain differences between the ISO 9000 recommendations and characteristics of change efforts at SAP. ISO (1994) recommends that careful analytical planning should precede any improvement effort (clause 15). For example, the significance of a problem should be evaluated in terms of its potential impact on costs and quality. Responsibility and authority for instituting improvement efforts should be defined as part of the quality system (clause 15.2). "When the corrective action is implemented, its effect should be monitored in order to ensure that the desired goals are met" (clause 15.7). ISO (1994) also recommends that permanent changes resulting from improvement efforts should be recorded in work instructions and the quality system documentation (clause 15.8). Furthermore, the management of an organization should acknowledge successes and achievements when changing software development (clause 5.6). The ISO 9000 recommendations to manage change efforts are in sharp contrast to the characteristics of changing software development at SAP:

9 For example, at SAP change efforts do not rely on formal planning. They seem to be carried out as informally as they come up. Improvement efforts are initiated by staff members when they notice problem areas or improvement options. In our case study, no decision about the implementation of a change project was based on explicit decision criteria. As a rule, decisions on improvement efforts are the result of an intensive discussion among all participating staff members. Responsibility and authority for conducting improvement efforts are not explicitly defined. SAP s staff members enjoy remarkable individual freedom. In the context of the analyzed projects this became apparent in the freedom to initiate and conduct improvement efforts with hardly any constraints. None of the improvement efforts observed in our case study included specific success measurement. Evaluating the success of the improvement efforts was primarily based on perceptions of participating staff members involved. We could hardly find any activity aimed at spreading the results of an improvement effort. Furthermore, at SAP there is no incentive system for improvement efforts and successful changes to software development do not lead to rewards or other kinds of acknowledgment. Only one of the factors that successful efforts to change software development at SAP have in common and that discriminate successful efforts from less successful improvement efforts is explicitly addressed by the ISO 9000 standards ( precise change objectives ). In regard to another success factor ( optional application of improvement results ) ISO 9000 gives counterproductive recommendations. The remaining five factors are not explicitly addressed by the ISO 9000 standards. In the following paragraphs we will attempt to explain why the ISO 9000 recommendations to conduct improvement projects differ from the characteristics of change efforts at SAP. The ISO 9000 quality standards are based on experience made in processing bulk goods. The standards describe quality systems for manufacturing tangible products (Matsubara, 1994). SAP, however, operates in the knowledge-based industry. The software company develops complex software systems that cannot be produced with repetitive processes as in the manufacturing industries. Arthur (1996) claims that the two worlds of business - manufacturing of tangible goods and designing knowledge-based products - differ in their character of competition and their culture of management. Manufacturing of tangible products requires constant optimization of product quality and production costs. Knowledge-based industries, however, require flexibility, creativity and continuous adaptation to changing business environments. Optimizing manufacturing processes requires careful planning and control. Management in companies operating in manufacturing industries often rely on hierarchical structures. Designing knowledge-intensive products, however, requires innovation and adaptation. Accordingly, SAP s management rely on a flat hierarchy and the creativity and flexibility of staff members. Presumably, Arthur s two worlds of business also differ in the way change efforts are managed. Whereas the ISO 9000 standards rely on carefully planned, formally controlled, and meticulously documented improvement projects, change efforts at SAP come up informally and evolve organically. This helps the software company to react swiftly to changing customer needs, to rapidly evolving technologies, and to new business strategies of competitors. 5. CONCLUSION Our study has revealed several differences between the recommendations to change software development described in the ISO 9000 standards and the change efforts at SAP. Change efforts at SAP seem to be more informal, less carefully planned and more organically evolving than is recommended by the ISO 9000 standards. The fact that SAP does not follow the ISO 9000 recommendations concerning continuous improvement, however, does obviously not negatively effect SAP s capability to improve software development. Recommendations to manage change processes in the ISO 9000 standards may be appropriate for manufacturing industries. However, they may not be suitable for knowledge-based industries, for example software development.

10 Although the nature of our study is such that no generalizable conclusions can be drawn from our observations, the findings may be helpful for future research into efforts to change software development. They may also provide interesting insights for other companies aiming at software process improvement. Software companies wishing to conduct continuous software process improvement may have to consider various factors that are not sufficiently accounted for in the ISO 9000 standards. 6. REFERENCES ANDERSON, C. (1996). A World Gone Soft: A Survey of the Software Industry. IEEE Engineering Management Review, 24 (4), ARTHUR, W.B (1996). Increasing Returns and the New World of Business. Harvard Business Review, 74 (4), ARGYRIS, C. and D.A SCHOEN (1996). Organizational Learning II: Theory, Method, and Practice. Addision-Wesley, Reading/Mass. BECKHARD, R. and R.T. HARRIS (1987). Organizational Transitions: Managing Complex Change. 2 nd Edition. Addision-Wesley, Reading/Mass. BENBASAT, I., D.K. GOLDSTEIN, and M. MEAD (1987). The Case Research Strategy in Studies of Information Systems. MIS Quarterly, 11 (3), BENNIS, W.G. (1969). Organization Development. Addision-Wesley, Reading/Mass. CATTANEO, F., A. FUGETTA, and L. LAVAZZA (1995). An Experience in Process Assessment. In: Proceedings of the 17th International Conference on Software Engineering, pp , New York. COFFMANN, A. and K. THOMPSON (1997): Air Force Software Process Improvement Report. Crosstalk - The Journal of Defense Software Engineering, 10 (1). GIBBS, W.W (1994): Trends in Computing: Software's Chronic Crisis. Scientific American, 43 (9), ISO (1994). Quality management and quality assurance standards. Part 1: Guidelines for selection and use. Geneva. ISO (1997). Quality management and quality assurance standards. Part 3: Guidelines for the application of ISO 9001:1994 to the development, supply, installation and maintenance of computer software. Geneva. ISO 9001 (1994). Quality systems. Model for quality assurance in design, development, production, installation and servicing. Geneva. ISO (1994). Quality management and quality system elements. Part 1: Guidelines. Geneva. JONES, C. (1996). Patterns of Software Systems Failure and Success. International Thomson Computer Press, London. LEWIN, K. (1958). Group Decision and Social Change. In Readings in social psychology (MACCOBY, E.E., T.M. NEWCOMB, and E.L. HARTLEY Ed.), pp , 3 rd Edition, Holt, Rinehart and Winston, New York. LOKEN, C.B. and T. SKRAMSTAD (1995). ISO 9000 Certification - Experiences from Europe. In Proceedings of the First World Congress for Software Quality, (Session Y) pp. 1-11, San Francisco. MATSUBARA, T. (1994). Does ISO 9000 really help improve Software Quality? American Programmer, 7 (2), NADLER, D.W., R.B. SHAW, and A.E. WALTON (1995). Discontinuous Change: Leading Organizational Transformation. Jossey-Bass, San Francisco. OLSON, T., W. HUMPHREY, and D. KITSON (1989). Conducting SEI-Assisted Software Process Assessments. Technical Report, CMU/SEI-89-TR-7, Pittsburgh.

11 PAULK, M.C., C.V. WEBER, B. CURTIS, and M.B. CRISSIS (1995). The Capability Maturity Model: Guidelines for Improving the Software Process. Addison-Wesley, Reading/Mass. ROGERS, E.W (1995). Diffusion of Innovations. 4 th Edition, The Free Press, New York. SAP AG (1997). Geschaeftsbericht Walldorf/Germany. STELZER, D., W. MELLIS, and G. HERZWURM (1996). Software Process Improvement via ISO 9000? Results of Two Surveys Among European Software Houses. In Software Process - Improvement and Practice, 2 (3), 1996, pp STELZER, D., M. REIBNITZ, and W. MELLIS (1998a). Benefits and Prerequisites of ISO 9000 based Software Quality Management. Software Process Newsletter, 5 (12), 1998, pp STELZER, D., W. MELLIS, and G. HERZWURM (1998b). Technology Diffusion in Software Development Processes: The Contribution of Organizational Learning to Software Process Improvement. In Information Systems Innovation and Diffusion: Issues and Directions (LARSEN, T. and E. McGUIRE Ed.), pp , Idea Group Publishing, Hershey/USA. TRITTMANN, R. (1998). Der Zusammenhang zwischen Unternehmenskultur und Verbesserungsvorhaben in der Softwareentwicklung: Eine explorative Untersuchung innerhalb der SAP AG. Unpublished Masters thesis (Diplomarbeit), Koeln.