8/19/2019 ecis-99.pdf

1/11

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 

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 23-25 June 1999, Volume 2.

Kopenhagen 1999, pp. 692-703

8/19/2019 ecis-99.pdf

2/11

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

8/19/2019 ecis-99.pdf

3/11

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 conductcontinuous 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.

8/19/2019 ecis-99.pdf

4/11

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 subjectivebias 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.

8/19/2019 ecis-99.pdf

5/11

3.  CHANGE EFFORTS IN SOFTWARE DEVELOPMENTOBSERVED 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 forvisiting 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 thattheir 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.

8/19/2019 ecis-99.pdf

6/11

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 wereprimarily 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 theresults were spread outside the immediately affected area. In this case, the results were published in the in-

house 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.

8/19/2019 ecis-99.pdf

7/11

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

0 1 2 3 4 5 6

Involvement of affected staff members

Collective decision process

Optional application of improvementresults

Precise change objectives

Promoter for the change efforts

Managing resistance

Consistent perceptions of changeobjectives

Number of less succes ful 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 theobjectives 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/19/2019 ecis-99.pdf

8/11

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 orauthoritative. 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 theless 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 THEISO 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:

8/19/2019 ecis-99.pdf

9/11

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 individualfreedom. 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.

8/19/2019 ecis-99.pdf

10/11

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.

8/19/2019 ecis-99.pdf

11/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. 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 Verbesserungs-

vorhaben in der Softwareentwicklung: Eine explorative Untersuchung innerhalb der SAP AG.Unpublished Masters thesis (Diplomarbeit), Koeln.