changing software development: a case study at sap ag

changing software development: a case study at sap ag

CHANGING SOFTWARE DEVELOPMENT:
A CASE STUDY AT SAP AG
Ralph Trittmann
Universitaet zu Koeln, Lehrstuhl fuer Wirtschaftsinformatik
Albertus-Magnus-Platz, D-50923 Koeln, Germany
Phone: +49 - 221 - 4705374; Fax: +49 - 221 - 4705386
[email protected]
Dirk Stelzer
Universitaet zu Koeln, Lehrstuhl fuer Wirtschaftsinformatik
[email protected]
Andreas Hierholzer
SAP AG
[email protected]
Werner Mellis
Universitaet zu Koeln, Lehrstuhl fuer Wirtschaftsinformatik
[email protected]
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 23-25 June 1999, Volume 2.
Kopenhagen 1999, pp. 692-703
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
9000-1 (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 9000-1,
1994) provide guidelines for improving software development. The models and standards describe options
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 9004-1 (1994) and in clause 4.14 of ISO 9001 (1994) and ISO 9000-3 (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 12.000 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.
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.
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.
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.
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
0
1
2
Number of less succesful change efforts
3
4
5
6
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
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 9004-1 (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 9004-1 (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:
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.
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), 21-36.
ARTHUR, W.B (1996). Increasing Returns and the New World of Business. Harvard Business Review,
74 (4), 100-109.
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. 2nd
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), 369-386.
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. 115-121, 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),
72-81.
ISO 9000-1 (1994). Quality management and quality assurance standards. Part 1: Guidelines for
selection and use. Geneva.
ISO 9000-3 (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 9004-1 (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. 197-211, 3rd 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), 38-45.
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.
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. 4th Edition, The Free Press, New York.
SAP AG (1997). Geschaeftsbericht 1997. 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. 197-210.
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. 3-7.
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 297-344, 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.