the role of commitment in software process improvement - oulu

162
THE ROLE OF COMMITMENT IN SOFTWARE PROCESS IMPROVEMENT PEKKA ABRAHAMSSON Department of Information Processing Science, University of Oulu Infotech Oulu, University of Oulu OULU 2002

Upload: others

Post on 03-Feb-2022

1 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: The role of commitment in software process improvement - Oulu

THE ROLE OF COMMITMENT IN SOFTWARE PROCESS IMPROVEMENT

PEKKAABRAHAMSSON

Department of Information Processing Science,University of Oulu

Infotech Oulu,University of Oulu

OULU 2002

Page 2: The role of commitment in software process improvement - Oulu
Page 3: The role of commitment in software process improvement - Oulu

PEKKA ABRAHAMSSON

THE ROLE OF COMMITMENT IN SOFTWARE PROCESS IMPROVEMENT

Academic Dissertation to be presented with the assent ofthe Faculty of Science, University of Oulu, for publicdiscussion in Kajaaninsali (Auditorium L6), Linnanmaa, onJune 14th, 2002, at 12 noon.

OULUN YLIOPISTO, OULU 2002

Page 4: The role of commitment in software process improvement - Oulu

Copyright © 2002University of Oulu, 2002

Reviewed byProfessor Mike NewmanProfessor Karlheinz Kautz

ISBN 951-42-6730-3 (URL: http://herkules.oulu.fi/isbn9514267303/)

ALSO AVAILABLE IN PRINTED FORMATActa Univ. Oul. A 386, 2002ISBN 951-42-6729-X

ISSN 0355-3191 (URL: http://herkules.oulu.fi/issn03553191/)

OULU UNIVERSITY PRESSOULU 2002

Page 5: The role of commitment in software process improvement - Oulu

Abrahamsson, Pekka, The role of commitment in software process improvement Department of Information Processing Science, University of Oulu, P.O.Box 3000, FIN-90014University of Oulu, Finland, Infotech Oulu, University of Oulu, P.O.Box 4500, FIN-90014University of Oulu, Finland Oulu, Finland2002

Abstract

Software process improvement (SPI) approaches have been designed to produce changes at manylevels, i.e. in the strategies, culture and working practices, of software development. Studies haveshown that nearly two thirds of all SPI efforts have failed or fallen short of expectations. It is oftenstated in SPI-related literature and practice that "commitment" to SPI plays an important part indetermining whether an SPI endeavor ultimately becomes a success or a failure. However, it oftenremains unclear what this concept actually means and how it affects SPI.

This thesis argues for a scientifically grounded concept of commitment and delivers a descriptionand a definition of this concept in the context of software process improvement. The elaboration ofthe concept is based on a literature study, which makes the research done in behavioral psychologyand organizational science applicable in the field of software process improvement. This thesis showsthat current thinking relies on practical models of commitment, and the empirically validated analysisconducted within this study reveals a number of common misleading assumptions regarding thenotion and development of commitment in SPI. On this basis, this thesis suggests that thecommitment phenomenon is better explained through what can be called strategic, operational andpersonal commitment nets. This framework can be used for analyzing the unfolding and alteration ofcommitment towards a specific entity, in this case a software process improvement endeavor, throughtime and changing circumstances.

The viability and usefulness of the commitment nets framework is demonstrated through ananalysis of four SPI cases in two software organizations. As a result, it is shown that even though theobjective features of SPI in terms of costs and benefits may be dominating in the project initiationphase, their role tends to lose strength later on due to an inability of the SPI effort to produce quickand meaningful results, even if these are explicitly sought for. This phenomenon gives rise to a needfor enhancing the role of social and psychological drivers. If this is not achieved, SPI activities arelikely to cease to exist.

The empirical analysis demonstrates that the use of the commitment nets model enables a moreprecise analysis of the various aspects involved in the commitment phenomenon than what wouldhave been possible with current commitment models. Commitment, as conceptualized andoperationalized in this thesis, makes a significant contribution to the outcome of the SPI initiative.The empirical evidence shows that, eventually, even well-planned SPI initiatives may fail to reach thegoals set for them due to changes in commitment nets.

Keywords: improvement program, software quality, change management, organizationalmanagement

Page 6: The role of commitment in software process improvement - Oulu
Page 7: The role of commitment in software process improvement - Oulu

Preface

The road to this doctoral dissertation has been a personal challenge that I decided to take a long time ago – long before I even started my undergraduate studies. The focus of my research, however, did not crystallize to me until very late during my studies. I am grateful to Mauri Lammassaari who enabled me to gain the much-needed industrial experience working in a professional software development organization, which also led to the realization that successful industrial software process improvement does require something more than just technical knowledge. Special acknowledgment is due to my official supervisor, Professor Samuli Saukkonen, who was the one directing my interest toward the notion of commitment and making sure throughout the whole process that I had all the resources needed for this study, including the financial support enabling me to fully concentrate on the research at hand. These resources also include gaining entrance to the Infotech Oulu Graduate School, which supports the young researcher in his chosen path in a professional manner.

During the research process, a number of publications were written and also published in various international forums. This would not have been possible if I had not received guidance from Professor Kari Kuutti in the preparation of the early publications. It was from him that I learned that there were a number of ways that one’s paper could be “shot down”. Thus, the most obvious pitfalls could be avoided and the publishing could begin. I would like to express my gratitude also to Professor Juhani Iivari for his critical evaluation of my master’s thesis written on the same topic and for providing me with his expertise whenever I needed it. Emeritus Professor Pentti Kerola and Professor Pertti Järvinen deserve special thanks for their inspiring lessons on the essence of doing research, even if it was only much later that the core of their debate really unfolded to me. Pertti’s red book provided the foundation for the constitution of this research project.

I wish to express my sincerest gratitude to Timo Jokela, Mikko Siponen and Juhani Warsta, friends of mine and colleagues following a similar path to the dissertation and with whom I had the opportunity of sharing the joys of doing research. Juhani’s dedication to his work and his wide expertise provided me with a platform for thought testing the various elements of the commitment phenomenon. He made me appreciate the value of craftsmanship – a lesson ever since greatly contributing to my life also beyond the world of research.

Page 8: The role of commitment in software process improvement - Oulu

As with any scientific research, the role of empirical data is invaluable. I am therefore ever grateful to the two participating companies and the personnel whom I had contact with. Since the anonymity is to be preserved, no names are cited here. Without these people, however, the claims made in thesis could not have been empirically explored or validated. As regards university personnel, I especially wish to thank Netta Iivari for helping me in many ways and for preparing and coding the seemingly boundless empirical data into analyzable form.

I also wish to express my gratitude to Professor Karl Kautz and Professor Mike Newman, the external reviewers of the thesis, who have made a number of valuable remarks and suggestions, which have significantly improved the work at hand. Karl has also offered me great help in clarifying the value of the earlier publications in the light of my later research advancements. His extensive comments have sharpened the focus of this thesis immensely, for which I am very grateful.

I am greatly indebted to Professor Veikko Seppänen, too, who has taken the time and the effort in the role of a shadow supervisor to carefully review the drafts of this thesis. He even traveled to Copenhagen to explain the concepts “tools” and “a toolbox” to me, which I thought of having understood, but most evidently I had not. I wish to thank the interlibrary loan personnel at the main library of the University of Oulu for their patience with my always late deliveries and for the extremely efficient article retrieval provided as a regular service to their customers. Thanks are also due to VTT Electronics, which is my current employer, for providing me with the resources needed for finalizing this thesis. There are still a number of friends and colleagues, both home and abroad, who have not been recognized here, but who certainly deserve my sincerest acknowledgment.

Finally, I wish to specially thank my parents for their continuous encouragement throughout my life in all my aspirations, whether these have made sense or not. My wife Minna is the source of energy and joie de vivre for me. Her love and care have made all this possible. I wish to thank her from the bottom of my heart!

Oulu, May 2002 Pekka Abrahamsson

Page 9: The role of commitment in software process improvement - Oulu

Abbreviations

4GL Fourth Generation Language

AC Affective commitment

CASE Computer Aided Software Engineering

CC Continuance commitment

CMM Capability Maturity Model (sm)

DACS The Data & Analysis Center for Software

GQM Goal/Question/Metric method

IC Instrumental commitment

IDEAL Initiation, Diagnosis, Establishment, Acting, Learning

IS Information Systems

ISD Information Systems Development

ISO International Standardization Organization

IT Information Technology

MT Module Testing

NC Normative commitment

SE Software Engineering

SEI Software Engineering Institute

SME Small to Medium Sized Enterprise

SP Software Process

SPI Software Process Improvement

SW Software

Page 10: The role of commitment in software process improvement - Oulu

OO Object Oriented

PDCA Plan-do-check-act

PROFES PROduct Focused improvement of Embedded Software processes

PSP Personal Software Processsm

QA Quality Assurance

QIP Quality Improvement Paradigm

SCM Software Configuration Management

SEI Software Engineering Institute

SME Small to Medium sized Enterprise

SPICE Software Process Improvement and Capability DEtermination

SQA Software Quality Assurance

SW Software

TSP Team Software Processsm

UCD User-Centered Development

U.S. The United States

Page 11: The role of commitment in software process improvement - Oulu

List of original publications

This thesis is based on the following publications, which are referred to in the text by their Roman numerals.

I Abrahamsson P (1999) Expanding goal setting theory concepts - using goal commitment measurements to improve chances for success in SPI. Proceedings of International Conference on Product Focused Software Process Improvement, PROFES'99, Oulu, Finland, 481-496.

II Abrahamsson P (1999) Commitment to software process improvement -

development of diagnostic tool to facilitate improvement. Software Quality Journal 8: 61-74.

III Abrahamsson P (2000) Is management commitment a necessity after all in

softaware process improvement. Proceedings of the 26th EUROMICRO Conference, EUROMICRO '00, Maastricht, Holland, 2: 246-253.

IV Abrahamsson P (2001) Commitment development in software process

improvement: critical misconceptions. Proceedings of the 23rd International Conference on Software Engineering, ICSE 2001, Toronto, Canada, 71-80.

V Abrahamsson P (2001) Rethinking the concept of commitment in software process

improvement. Scandinavian Journal of Information Systems 13: 69-98.

VI Abrahamsson P & Iivari N (2002) Commitment in software process improvement - in search of the process. Proceedings of the 35th Annual Hawaii International Conference on System Sciences, HICSS35, Big Island, Hawaii, 3395-3404.

Page 12: The role of commitment in software process improvement - Oulu
Page 13: The role of commitment in software process improvement - Oulu

Contents

Abstract Preface Abbreviations List of original publications Contents 1 Introduction ..............................................................................................................15

1.1 Research focus ...................................................................................................16 1.2 Research problem and results..............................................................................17 1.3 Overview of the dissertation ...............................................................................18

2 Software process improvement typology....................................................................20 2.1 SPI Management ................................................................................................20 2.2 Approaches to SPI ..............................................................................................21

2.2.1 Evolutionary approaches ..............................................................................21 2.2.2 Norm based approaches ...............................................................................22 2.2.3 Commitment based approaches ....................................................................22

2.3 Improvement types .............................................................................................23 2.4 Phases in SPI......................................................................................................24 2.5 SPI outcome.......................................................................................................25 2.6 Summary............................................................................................................26

3 A typology of commitment ........................................................................................29 3.1 Commitment in organizational behavior studies ..................................................29

3.1.1 Two schools of thought ................................................................................30 3.1.2 Conceptualization of commitment ................................................................32 3.1.3 Commitment drivers identified in OB literature ............................................34

3.2 Commitment in information systems studies .......................................................36 3.2.1 Two streams of IS related commitment research ...........................................36 3.2.2 Commitment Drivers identified in IS literature .............................................38

3.3 Summary - towards a typology of commitment ...................................................40 3.3.1 Common aspects of commitment..................................................................40 3.3.2 Definition of commitment ............................................................................41

4 The Dynamic structure of the commitment process ....................................................42

Page 14: The role of commitment in software process improvement - Oulu

4.1 Analysis of dynamic commitment models ...........................................................42 4.1.1 Scientific commitment models .....................................................................43 4.1.2 Practical commitment models.......................................................................45

4.1.2.1 Commitment to change..........................................................................46 4.1.2.2 Commitment of management to “new thinking”.....................................48

4.2 Assumptions in current thinking..........................................................................49 4.2.1 Causality in commitment process .................................................................50 4.2.2 Controllability of the commitment process ...................................................50 4.2.3 The notion of a singular commitment construct ............................................51 4.2.4 Commitment as an all-positive phenomenon.................................................51 4.2.5 Shared development of commitment.............................................................52

4.3 Model of commitment nets .................................................................................52 4.3.1 (Re)discovery of commitment nets ...............................................................53 4.3.2 Actors in commitment nets model ................................................................54 4.3.3 Commitment drivers ....................................................................................56 4.3.4 Concern and action ......................................................................................57 4.3.5 Outcomes ....................................................................................................58 4.3.6 Commitment process ...................................................................................59

4.4 Summary............................................................................................................60 5 Research Design .......................................................................................................61

5.1 Research evolution .............................................................................................61 5.1.1 Metrics focus ...............................................................................................62 5.1.2 Conceptualization ........................................................................................63 5.1.3 Empirical study............................................................................................64 5.1.4 Abstraction ..................................................................................................65

5.2 Research approach and methods .........................................................................65 5.3 Research setting and case selection .....................................................................68 5.4 Data collection ...................................................................................................69 5.5 Data analysis......................................................................................................70

5.5.1 Narrative strategy.........................................................................................72 5.5.2 Alternate templates strategy..........................................................................74 5.5.3 Grounded theory strategy .............................................................................75 5.5.4 Visual Mapping Strategy ..............................................................................77 5.5.5 Synthetic strategy.........................................................................................77 5.5.6 Cross-case analysis ......................................................................................78

5.6 Summary............................................................................................................78 6 The role of commitment in four SPI cases..................................................................80

6.1 Introduction to cases...........................................................................................81 6.2 Case 1: Improving usability processes.................................................................82

6.2.1 Longitudinal analysis of commitment nets....................................................83 6.2.1.1 Initiation phase......................................................................................83 6.2.1.2 Operation phase ....................................................................................85 6.2.1.3 Closure phase........................................................................................89

6.2.2 Empirical conclusions..................................................................................93 6.2.2.1 Commitment process.............................................................................93 6.2.2.2 Changes achieved..................................................................................94

Page 15: The role of commitment in software process improvement - Oulu

6.3 Case 2: Improving module testing processes .......................................................95 6.3.1 Longitudinal analysis of commitment nets....................................................96

6.3.1.1 Initiation phase......................................................................................96 6.3.1.2 Operation phase ....................................................................................98 6.3.1.3 Closure phase......................................................................................104

6.3.2 Empirical conclusions................................................................................107 6.3.2.1 Commitment process...........................................................................107 6.3.2.2 Change achieved .................................................................................108

6.4 Case 3: Improve geographically distributed software development..................... 111 6.4.1 Longitudinal analysis of commitment nets..................................................112

6.4.1.1 Initiation phase....................................................................................112 6.4.1.2 Operation phase ..................................................................................114 6.4.1.3 Closure phase......................................................................................115

6.4.2 Empirical conclusions................................................................................118 6.4.2.1 Commitment process...........................................................................118 6.4.2.2 Change achieved .................................................................................119

6.5 Case 4: Improving software process improvement processes .............................119 6.5.1 Longitudinal analysis of commitment nets..................................................120

6.5.1.1 Initiation phase....................................................................................120 6.5.1.2 Operation phase ..................................................................................122 6.5.1.3 Closure phase......................................................................................124

6.5.2 Empirical conclusions................................................................................128 6.5.2.1 Commitment process...........................................................................128 6.5.2.2 Change achieved .................................................................................129

7 Cross-case evaluation..............................................................................................131 7.1.1.1 Analysis of commitment assumptions ..................................................131

7.1.2 Causality and controllability.......................................................................131 7.1.3 Singularity and all-positive role..................................................................132 7.1.4 Shared development of commitment...........................................................133 7.1.5 Conclusions...............................................................................................134

7.2 Commitment process ........................................................................................136 7.2.1 Operational level commitment process .......................................................136 7.2.2 Means used for creating concern ................................................................139

7.3 Commitment vs. SPI outcome...........................................................................142 8 Evaluation of the results ..........................................................................................144

8.1 Implications for theory .....................................................................................144 8.2 Implications for practice ...................................................................................146

8.2.1 Voluntary involvement ...............................................................................146 8.2.2 Embedded SPI ...........................................................................................146 8.2.3 Emphasis on the environment.....................................................................147

9 Conclusions ............................................................................................................148 9.1 Summary of the results .....................................................................................148 9.2 Limitations of the study....................................................................................149 9.3 Future research.................................................................................................150

References.................................................................................................................151 Appendix I.................................................................................................................160

Page 16: The role of commitment in software process improvement - Oulu
Page 17: The role of commitment in software process improvement - Oulu

1 Introduction

Software is playing an ever-increasing role in today’s society and in industry. Modern software organizations operate in a highly dynamic market, under tight time and cost constraints (Cugola & Ghezzi 1998). In an attempt to answer to these needs, organizations have started to undertake software process improvement (SPI) initiatives aimed at increasing the maturity and quality of their software processes (Humphrey 1989, Humphrey 1992, Grady 1997, Major & Pellegrin 1998, Zahran 1998, El Emam & Madhavji 1999, Kinnula 1999).

The investment in process improvement has yielded significant business benefits, such as improved product quality, reduced time to market, enhanced productivity (Zahran 1998), increased organizational flexibility, along with higher customer (Florac et al. 1997) and employee satisfaction (Yamamura 1999). A 1996 report commissioned by The Data & Analysis Center for Software (DACS) reports that successful SPI programs have reduced the number of defects delivered to customers by 95%, and software development schedules by 71%, and increased productivity in terms of lines-of-code or function points per day by 222%. The SEI (Software Engineering Institute) has reported an average return of 5:1 investments in successful SPI programs. Glass (1999) has evaluated financial gains on different software technologies – structured techniques, fourth generation languages (4GL), computer aided software engineering (CASE), formal methods, the cleanroom method along with object orientation and process models – concluding that the process model data reflects a consistent patter of improvement gained. Indeed, a widely accepted paradigm among SPI practitioners today is that the quality of a process has a strong relation with the quality of the product (Kinnula 1999). However, these benefit reports should be taken with a grain of salt due to a number of reasons. For example, most of these reports have originated in the US and are thus influenced by its cultural context – with some exceptions, see e.g. (Messnarz & Tully 1999) for details – which is why they might not be applicable elsewhere. Then again, although many SPI approaches are generally known in Europe, they are not widely used (Kautz & Larsen 2000).

Page 18: The role of commitment in software process improvement - Oulu

16

1.1 Research focus

While Software engineering (SE) is a practical discipline, which has its foundations in formal mathematics (Jayaratna & Sommerville 1998), many researchers have started to explore human-related issues inherently playing a major role in adopting new processes to software developers’ daily work. Understanding the processes of change from a human perspective is becoming more and more important, since studies have shown that nearly two-thirds of all organizational change efforts – software process improvement activities result in organizational changes (e.g. Johansen & Mathiassen 1998) – have failed or at least fallen short of expectations (Trahant & Burke 1996). Similar findings have been reported in the context of improving software processes (Debou 1999). For example, in spite of extensive literature being available on software measurement, companies are facing serious problems initiating even the simplest metrics programs (Hall & Fenton 1997, Herbsleb & Grinter 1998).

Early reports attributed these failures to poor planning and to the organization of the process improvement activities (Debou 1999). In recent years, however, a growing number of articles have been emphasizing the importance and role of human (or soft) factors when explaining the failure or success of various quality-related initiatives (e.g. Korson 1996, Kasse & McQuaid 1998, Weimer & Munyan 2000). Kinnula (1999) states that “people are the most fundamental element in any people-intensive activity, such as software development or software process engineering”. Thus, due to the realization that process improvement, fundamentally, is a human endeavor, since it aims at changing the way people work (Hutchings et al. 1993), researchers have begun to argue that in order to develop truly effective approaches to quality improvement, the experiences and views of ordinary practitioners should be carefully considered (Hall & Wilson 1997). These findings have been consistent in small organizations (Kautz 1999, Batista & de Figueiredo 2000, Horvat et al. 2000) as well as in large ones (Harkness & Kettinger 1996). Thus, when the attention shifts from technology to people, the management of SPI becomes management of change (Moitra 1998, Stelzer & Mellis 1998, Laporte & Trudel 1999). Among the elements in the change process that have a profound impact on the success of SPI and thus need to be ‘managed’, “commitment” to SPI at all organizational levels has consistently dominated the literature.

The need for commitment in quality endeavors originates from the writings of quality gurus (Crosby 1979, Deming 1982, Juran 1988). SPI literature has adopted these ideas and systematically placed emphasis on this concept. In their study of 56 organizations Steltzer and Mellis (1998) report that the need for commitment and support by the management was ranked number one in 97% of SPI cases. Staff involvement was ranked second. Arbaoui and the others (1999), among others, argue that managerial commitment is paramount in bringing about effective changes in working practices. Hall and Fenton (1997) characterize how successful and unsuccessful SPI projects differs:

“The successful [metrics implementation] program was managed with a tenacious commitment to see metrics work. In contrast, the unsuccessful program seemed half-hearted, despite the fact that it was ambitious and expensive to implement (Hall & Fenton 1997, p. 64).” (italics added)

Page 19: The role of commitment in software process improvement - Oulu

17

Statements similar to the above have also been made by other researchers (e.g., Almaraz 1994, Wohlwend & Rosenbaum 1994, Clegg et al. 1996, Dahlberg & Järvinen 1997, Diaz & Sligo 1997, El Emam et al. 1998, Mathiassen et al. 2002). CMM (Capability Maturity Model) is one of the best known approaches to assessing and improving software processes. A new model for implementing CMM-based improvement activities includes commitment as one of the key elements of the improvement program (Isacsson et al. 2001). Also, a recent effort to build a conceptual map of the key ideas underlying SPI classifies commitment as a specific approach for implementing SPI (Aaen et al. 2001). Commitment is seen as a force that endures over the hardships of a process improvement effort – an effort that can be considered as an investment the results of which may be visible only several years later. It has been well understood that people should not be considered as robots to be guided in a step-by-step fashion, but rather they should be viewed as the most crucial resource in software development (Cugola & Ghezzi 1998). This, however, is not a new realization. A summer issue 1990 of American Programmer (Ed Yourdon’s Software Journal, Vol. 3, No. 7-8) was devoted exclusively to ‘Peopleware’. The editor comments the special issue by pointing out that

“Everyone knows the best way to improve software productivity and quality is to focus on people.”

Recently, people-centered strategies have been argued for as an important source of competitive advantage, for, unlike technology, cost or new product development, they these human strategies are difficult to imitate (Pfeffer 1998, Miller & Lee 2001). Thus, there is a clear need to better understand the soft side of software process improvement. This thesis focuses on one aspect of this issue – commitment in software process improvement. In particular, it makes an attempt to conceptualize the concept of commitment and to empirically analyze its effects on SPI.

1.2 Research problem and results

This thesis explores the role of commitment in the field of industrial software process improvement. The specific research question is defined as follows:

What is the role of commitment in industrial software process improvement?

Answering this question requires conceptualizing the commitment phenomenon in general and, then, relating it to software process improvement. As a result of this, a definition of commitment is produced and operationalized in the form of a model on commitment nets. On this basis, this thesis sets out to suggest that software organizations operate through commitment nets. Three levels of nets – strategic, operational and personal – are defined, and commitment net elements – actors, drivers, concerns, actions, and outcomes – are introduced.

The role of commitment in SPI is explored in four SPI cases. The cases show a lot of variation in terms of improvement scope, type and subsequent success. The cases are analyzed using the model of commitment nets. It is found that none of the cases managed

Page 20: The role of commitment in software process improvement - Oulu

18

to alter their respective operational commitment nets. The reasons for the lack of success are varied and they are discussed in detail in the empirical analysis part of the thesis.

Based on empirical findings, it is shown that while the objective features of SPI in terms of costs and benefits – i.e. project drivers – are dominating in the project initiation phase, their role weakens later on due to an inability of the SPI effort to produce quick and meaningful results, even if these are explicitly sought for. This phenomenon causes a need to enhance the role of social and psychological drivers at the operational level. If this is not achieved, SPI activities are likely to cease to exist. Structural drivers that form the environment for performing process improvement activities constantly jeopardize the existence of SPI.

The empirical analysis demonstrates that the use of commitment nets model enables a more precise analysis of the many aspects involved in the commitment phenomenon than would be possible with current commitment models. In conclusion, it is shown that commitment, as conceptualized and operationalized in this thesis, makes a significant contribution to the outcome of an SPI initiative. Empirical evidence shows it was due to changes in commitment nets that two well-planned SPI initiatives failed to reach the set target for them.

1.3 Overview of the dissertation

This thesis is a collection of six original publications with an extended summary. The present writer has been the primary author in all of the original publications. Two of them are journal articles and four are articles published in refereed international conferences.

Articles I and II lay the foundation for the thesis by criticizing the rather unscientific use of the concept of commitment in SPI. The articles present two schools of thought, which, based on scientific evidence, distinguish between the attitudinal and behavioral approaches to commitment and demonstrate how such a distinction can benefit SPI practice. On this basis, article III challenges the classical demand, i.e. the necessity of commitment by management, for the success of SPI initiatives. The research evidence shows, however, that management commitment beyond providing the necessary resources might not be decisive for the positive outcome of an SPI endeavor. Article III goes on to suggest that other players, especially the so-called champions, may prove more important. Continuing to challenge the traditional perception of commitment, articles IV and V provide a thorough explanation of the commitment concept, identify archetypes of commitment and discuss four serious misconceptions about the development of commitment. The rejection of commitment as a linear, sequential and causal process, along with its controllability, singularity and the assumption of it being an all positive phenomenon leads to the introduction of commitment nets, which are used for understanding and explaining the role of commitment in SPI projects. It is argued that the application of the concept of commitment nets in SPI leads to a deeper understanding of the SPI process and enables both researchers and practitioners to better focus the needed improvement efforts. This is the content of the article VI. The thesis summary will then take a more in-depth look at the topics introduced in the six original publications.

Page 21: The role of commitment in software process improvement - Oulu

19

The summary part of the thesis is structured in nine chapters. After the introduction in Chapter 2, an SPI typology that will be used in the empirical analysis is developed. Chapter 3 explores and develops a typology for commitment. This is done by exploring the different conceptualizations proposed in related disciplines, i.e. organizational behavior and information systems development. Chapter 4 concentrates on the dynamics of commitment by analyzing existing commitment models. Potential weaknesses in current thinking are laid out and the model of commitment nets is built. Chapter 5 considers the research design by exploring how the research has evolved over time. The research approaches, methods and techniques used in the six publications and in the thesis summary are explained as well as the research settings and case selections. Chapter 6 presents the empirical research. Four SPI cases are introduced and subsequently analyzed using the commitment nets model. Chapter 7 contains a cross case analysis, in which commitment assumptions and the commitment process are explored over the four cases studied. Chapter 8 evaluates the research results by discussing the theoretical and empirical implications of the study. Finally, Chapter 9 summarizes the work and identifies research opportunities for the future.

Page 22: The role of commitment in software process improvement - Oulu

2 Software process improvement typology

The purpose of this chapter is to introduce a typology of software process improvement to be used in the empirical analysis phase. This typology includes the following analytical SPI elements: goal, scope, problem origin, management, approach, type, phase, outcome. These will be in focus in this chapter. Those interested in software process improvement in general are referred to (e.g., Humphrey 1989, Zahran 1998, Kinnula 2001, Mathiassen et al. 2002). For the purposes of this thesis, it is viewed that software is produced through software processes (SP). Software process is seen as a set of activities, methods and practices used in the production and evolution of software (Humphrey 1989). Software process improvement, then, is the mechanism through which the quality of software processes is improved (Aaen et al. 2001). Thus, software process improvement is concerned with changing the way software development organizations, teams, and individuals perform in their work. The focus of SPI is therefore on software processes, including the actors executing these processes and structures governing the activities (Zahran 1998).

2.1 SPI Management

SPI management reflects the way SPI is organized, the extent to which planning activities are performed and how the feedback mechanisms are structured (Aaen et al. 2001). Good SPI management practices require a clear organization of the SPI project, including communicating roles and responsibilities for everyone involved. SPI typically involves all organizational levels from top managers to personnel, who actually implement the software products. Thus, there are multiple types of roles that these different interest groups play in an SPI project. Such roles are, e.g., sponsorship, management, coordination, improvement team – the operational role - (Zahran 1998), and, finally, the role of the target of change.

Planning refers to the creation of an action plan that guides the improvement program. This makes it possible to allocate dedicated resources for implementing improvements. Furthermore, as Aaen and the others (2001) suggest, the existence of an improvement plan provides a number of advantages: It supports the creation of a common

Page 23: The role of commitment in software process improvement - Oulu

21

understanding, provides opportunities for decomposing the problem into smaller tasks, enables prioritization and co-ordination of the improvement needs, and the plan can be used for communicative purposes tracking the progress of the improvement project.

The participants of the SPI project need some kind of mechanisms for ensuring that the set goals are met, to what extent progress or change have been accomplished, and for working out how to create a state of stability after the change has been implemented. Such a mechanism is provided by feedback. Efficient feedback produces several advantages: It provides a means of justifying the effort spent, measurements provides vital instruments for controlling the effort, and finally measurements – at their best – contribute to maintaining motivation, commitment, and legitimacy. However, this type of feedback is often difficult to provide, as recently evidenced by Pourkomeylian (2001), who states his concern regarding the “impossibility to measure and document quality and progress of the [SPI] project”. Feedback thus requires that the progress or success of an SPI endeavor can be identified. Other measures are therefore needed. These measures are introduced and discussed in section 2.5

2.2 Approaches to SPI

Approach refers to the way in which changes are strived at in a software development organization (Aaen et al. 2001). Over the past decade, a number of different approaches for implementing SPI have been proposed. CMM (Paulk et al. 1994), SPICE (Melo et al. 1998) and Bootstrap (Kuvaja et al. 1994), in particular, have shaped the way how SPI is perceived in practice. Aaen and the others (2001) classify SPI approaches into the following three classes: evolution, norm and commitment. According to the authors, these approaches reflect the key ideas of how real changes are obtained in software processes. These three approaches will be briefly introduced in the following. The first two, i.e. the evolutionary and normative methods, are adopted for the analytical framework used in this study. The commitment based approach is introduced here along with the rationale for its omission.

2.2.1 Evolutionary approaches

The evolutionary SPI approach is based on the idea that the changes in software engineering working processes should be evolutionary rather than revolutionary (Aaen et al. 2001). It is an approach in which changes are implemented by a sequence of small changes over a period of time instead of a single, large change attempt, which would involve changes of dramatic, transformative nature. The evolutionary approach is advocated by a number of SPI authors (e.g., Basili & Green 1994, Johnson & Brodman 1996). Examples of this approach are the GQM method (van Solingen & Berghout 1999) and the CMM-accelerator model (Isacsson et al. 2001). In these methods, a series of plan-do-check-act (PDCA) cycles are implemented in an incremental fashion to bring about the changes. At the opposite end of the continuum, there is the revolutionary approach. As an example of this approach to organizational intervention Aaen and the

Page 24: The role of commitment in software process improvement - Oulu

22

others (2001) use Business Process Reengineering (BPR), which seeks to implement a fundamental change in business processes in order to achieve improvement in organizational performance.

The evolutionary approach to SPI provides several opportunities that are beneficial for SPI efforts: Practitioner involvement, experience based learning and on-going evaluation. However, the evolutionary approach also involves certain risks, such as invisibility of low-level changes, and inability to anchor the process in daily practices. Still, Aaen and the others (2001) argue that using the evolutionary method these risks are lower than with the revolutionary approach (2001).

2.2.2 Norm based approaches

Norm based approaches have largely dominated the field of software process improvement. These approaches are based on the idea that a specific set of norms can be defined and applied to guide and control the results of a change process (Arent 2000). There is a plethora of different capability models that can be used for changing the level of maturity in a software organization according to a predefined norm. Through the capability assessment procedure, an improvement strategy is drawn in an attempt to fill the gaps between norm and practice. The widespread interest in modeling the ideal way of producing software has spread over to other fields of the software organization’s daily operations in the form of people capability maturity model (Curtis et al. 1995) and the software acquisition capability maturity model (Ferguson et al. 1996). Specific capability models have also been proposed for different software quality characteristics, such as usability (cf. Jokela 2001) and security (cf. Hefner 1997). Recently, even specific software processes, such as the inspection process (Tervonen et al. 2001) and the testing process (Burnstein et al. 1999), have been formulated in terms of their respective capability levels.

Some benefits for using the norm based SPI approaches can be identified: to envision the future state clearly, to compare results across companies and countries, along with the use of benchmarking and the use of clear criteria for prioritizing improvement areas. The use of norm based approaches, however, involves a number of risks: the strategy may be overly ambitious, the use of norm for its own sake is likely to distance the organization from its purpose, and it may be difficult to obtain reliable assessment results (Aaen et al. 2001).

2.2.3 Commitment based approaches

While the central theme in this thesis is commitment in SPI, Aaen and the others (2001) argue that commitment is a specific approach to organizational interventions. The authors state that in this approach SPI should draw heavily on committing people to the changes they will be affected by. The authors use Grady’s (1997) classification of the business aspects bearing strategic importance – vision, strategic focus and core competence – and the aspects bearing tactical importance – customer perception, market share, product

Page 25: The role of commitment in software process improvement - Oulu

23

cycle time and profitability – as elements of management commitment. Grady suggests that if any of these business aspects are neglected, managers may get distracted, which may jeopardize the SPI project. It appears that Aaen and the others (2001) are referring to a change approach that is closely tied in with managerial interests. Ensuring the managerial support for the SPI effort is seen as one of the most important aspects of the change effort. Aaen and the others (2001) cite (Jakobsen 1998) and argue that ”if the entire organization shows commitment towards SPI, people will be motivated to share new ideas and experiences, try out new practices, and work together to reach challenging goals”. They, however, also note that the commitment process for SPI can be carried too far – managers and practitioners may loose sight of the original goal when they are too dedicated in solving SPI problems.

This thesis clarifies the commitment concept and empirically explores its role in SPI. Thus, the use of commitment based SPI approach here differs from the view taken in the thesis. The commitment approach of Aaen and the others (2001) serves as an example for the need for gaining a better understanding of the phenomenon. The authors argue that commitment is a distinct approach to SPI with little support from the literature. However, their distinction of the two other approaches, i.e. evolutionary and norm, is well argued and supported. Hence, the evolutionary and norm based approaches are employed in the analysis device used for analyzing software process improvement projects in this thesis (Chapter 6, Chapter 7).

2.3 Improvement types

There are four possible types of SPI: process repair, optimization, re-engineering and innovation (Seppänen et al. 2001), Fig. 1. Process repair means that short-term gains are sought through a special solution. In this SPI type, the process problems are fixed with a new tool, for example. According to Seppänen and the others (2001), such a quick fix may be centrally managed and distributed to several actors with the emphasis on short-term gains. The focus is generally on software development resources, such as methods and tools. Process re-engineering, in turn, usually focuses on actors, revising their organization, roles and responsibilities in the processes. Process optimization, for its part, lays emphasis on activities. According to our interpretation of this type, the current process already produces acceptable results, while enhancements are made to increase its effectiveness or speed, or both. Finally, process innovation focuses on the interplay of several processes rather than on some actors, activities or resources. Seppänen and the others (2001) argue that process innovation is likely to bring the most value, i.e. strategic benefits, to an organization.

Page 26: The role of commitment in software process improvement - Oulu

24

Process RepairResource focus

Process OptimizationActivity focus

Process InnovationRelationship focus

Process Re-engineeringActor focus

SPECIAL SOLUTIONS

GENERAL IMPROVEMENTS

STRATEGIC BENEFITSSHORT-TERM GAINS

Fig. 1. Software process improvement types (Seppänen et al. 2001)

In the empirical analysis, the distinction between different SPI types based on Seppänen and the others (2001) will be used for identifying the means of implementing changes to current software practices.

2.4 Phases in SPI

SPI is a mechanism used for changing a software development organization towards some desired state (Kuvaja et al. 1994). This state is achieved through a series of different phases. The purpose here is to identify the phases that are generic enough to be used in the empirical analysis phase. The generic phases that are present in any common SPI model such as IDEAL (McFeeley 1996), QIP (Basili et al. 1994) or its derivative PROFES (Birk et al. 1998) are used here. Such generic phases are initiation, operation and closure (Table 1). The initiation phase usually entails activities for identifying the stimulus for improvement, establishing the improvement infrastructure, goal setting and improvement project planning. The operation phase involves activities for executing the plan, and the closure phase usually entails activities for documenting and analyzing the results as well as revising the approach for possible future SPI activities.

Page 27: The role of commitment in software process improvement - Oulu

25

Table 1. Generic phases of an SPI project.

Phase Description IDEAL QIP PROFES

Initiation Initiating Characterize Characterize

Diagnosing Goal definition Set goals

SPI project is initiated to solve an

identified problem. Goals are set,

resources negotiated and activities

planned.

Establishment Choose process Plan

Operation SPI project is performed according to the

plan.

Acting Execute Execute

Closure Learning Analyze Analyze

SPI project is finished.

Package Package

2.5 SPI outcome

Software process is complex in both technical and social dimensions. It is technically complex, since it involves sophisticated software systems that require solutions to demanding technical problems. Its social complexity is due to the fact that the building process involves a number of individuals with different roles and activities (Arbaoui et al. 1999). While SPI essentially attempts to change the way software is being constructed, it is often difficult to discern if such an attempt has really been successful. Over the years, several authors have offered a variety of explanations for failure and success in SPI (e.g., Goldenson & Herbsleb 1995, Grady 1997, Jakobsen 1998, Moitra 1998, Stelzer & Mellis 1998, Zahran 1998, Goldenson et al. 1999, Hadden 1999, Dybå 2000). Although the researchers have been able to identify a number of common themes, such as senior management sponsoring, clarity of SPI goals, staff involvement, link to business goals, and the like, no clear agreement has been achieved.

Most SPI activities are performed as projects with their own budget, timescale, dedicated resources and goals. There is, however, no universal framework for measuring and assessing the success of a project available (Shenhar et al. 1999). Even today, this argument applies to engineering projects and process improvement projects alike.

Alongside this thesis, a study on constructing a multidimensional framework for measuring the extent of success achieved in SPI was performed (see details in Abrahamsson 2000b). The view of project success by Shenhar and the others (1999) was chosen as the starting point for the framework. The authors studied a total of 127 projects, and the factor analysis suggested certain distinct underlying dimensions determining the success of a project: project efficiency, impact on the customer, business and direct success and preparing for the future. These success dimensions are multidimensional constructs themselves, in which the overall success is the high-order abstraction. These dimensions are relevant also in determining the success of SPI initiatives (Table 2).

Page 28: The role of commitment in software process improvement - Oulu

26

Table 2. Success dimensions in SPI (Abrahamsson 2000b).

# Success dimension

Description Example measures

1 Project

efficiency

Reflects a short-term measure expressing the efficiency

with which the project is managed. This dimension is

concerned with whether the project is (a) finished on time

within (b) specified budget limits.

Development time, work

slippage, work completed,

effort expended, funds

expended

2 Impact on the

customer

(process user,

management)

The level of success is characterized in terms of the level

of satisfaction with the new process, fulfillment of the

needs of the software developers, solving the problems

experienced and whether the improved process is actually

used.

Extent of use, satisfaction,

ease of use, work morale,

level of excitement,

resource availability

3 Business success SPI goals should be connected with business goals. Such

high-level strategic business goals are, e.g. ‘gain larger

market share’, ‘reduce time-to-market’, ‘improve product

quality' and ‘increase productivity’. There should be a

balance between short-term and long-term goals.

Productivity, cycle time

4 Direct

operational

success

This dimension is concerned with whether the SPI project

manages to solve the problem initially tackled.

Number of change

requests, amount of

rework, number of

process defects, cycle

time measures, maturity

level

5 Process

improvement fit

and preparation

for future

Implies applicability of an SPI initiative to provide

opportunities for future improvement activities and the

extent to which a specific SPI project can be adapted to a

larger SPI program.

Experience database,

number and type of SPI

initiatives, number of SPI

programs,

In the empirical analysis (Chapter 6 and Chapter 7), the dimensions impact on the customer (#2) and direct operational success (#4) will be used for evaluating the outcome of the SPI cases studied.

2.6 Summary

This section has introduced a typology of software process improvement to be used in the empirical analysis phase. This typology includes the following analytical SPI elements: management, approach, type, phase, and outcome. In what follows, these elements are briefly summarized (Table 3).

Goal defines the intention of an SPI project – reasoning for its existence, including the target of improvement that specifies what is changed or improved in order to achieve the set goal. Targets can be specific processes, e.g. a module testing process, or process clusters, like software development processes or human resources used for developing

Page 29: The role of commitment in software process improvement - Oulu

27

software and their competence. Scope extends the notion of target to include its results and those who are affected by the SPI project. The effect can be restricted to a single software engineer if, for example, the PSP method (Humphrey 1995) is applied, or it can be focused on a specific software development unit or on the whole software organization. The problem origin is derived from the goal and target of the SPI project, in order to explicate the originator of the problem that is to be solved or alleviated by SPI efforts. The originator can thus be any actor within the software development organization or outside. SPI management determines the infrastructure of the SPI project in terms of organization, plan and feedback.

Table 3. SPI concepts used in empirical analysis.

SPI Element Description Source Goal Goal defines the intention of the SPI project including the

target of improvement. Target can be a specific process, a

process cluster or resources and their competence or both.

Target always includes target actor, which refers to user of

the SPI products.

Scope Defines the level of intended impact of the improvement

project: Individual software engineer, software development

unit or whole software development organization.

Problem origin Defines the originator of the problem that SPI attempts to

solve or improve. Originator can be any actor within the

software development organization or outside. Problem

origin may be external, mixed or internal to an actor.

(e.g., Zahran 1998)

Management Defines the infrastructure for the SPI project in terms of

organization, plan and feedback.

Approach Defines the overall approach to implementing

improvements. Two distinct approaches were identified:

norm and evolutionary. The two approaches are not

exclusive however, i.e., they can be used in combination.

(Aaen et al. 2001)

Improvement type Defines a specific approach including means of

implementing improvements. Four types exist: process

repair, optimization, re-engineering and innovation. These

four types also include the training of target actors

employing the improvement solution.

(Seppänen et al. 2001)

SPI phases Define generic phases of an SPI project. The project can,

basically, be divided into three phases: initiation (Initiating,

diagnosing, establishment), operation (acting) and closure

(learning).

(Basili et al. 1994,

McFeeley 1996, Birk et

al. 1998)

SPI outcome Defines the outcome of the improvement project in terms of

success achieved. Impact on the customer and direct

operational success will be used in the analysis.

(Abrahamsson 2000b)

SPI approach defines how improvement are sought to be implemented. The distinction of Aaen and the others (2001) between norm and evolutionary based improvement

Page 30: The role of commitment in software process improvement - Oulu

28

approaches are used. The improvement type adopted from (Seppänen et al. 2001) enables a distinction of specific approaches, including the means used for implementing improvements. Four types were identified: process repair, optimization, re-engineering and innovation. These four improvement approaches of improvements sought involve training target actors. Three generic SPI phases were identified in common SPI models: initiation, operation and closure. Finally, the SPI outcome will be evaluated according to (Abrahamsson 2000b). The outcome will thus be evaluated against two dimensions: impact on the customer and operational success.

Page 31: The role of commitment in software process improvement - Oulu

3 A typology of commitment

The purpose of this chapter is to introduce the work done in other disciplines on the commitment concept. These disciplines are the fields of organizational behavior and information systems. In addition to these two fields, the first publication (I, also in Abrahamsson 1999b) drew its commitment related ideas – especially the concept of goal commitment – from the goal setting literature (Locke & Latham 1990). Due to its minor role in subsequent publications and in this summary part of the thesis, it will not be included in this review. Thus, readers are referred to I for details.

As a result of the literature review, commitment is conceptualized and a typology of commitment is formed. As Kiesler (1971) puts it, this chapter builds a literary definition of commitment that will be operationalized in Chapter 4 in the form of a dynamic commitment model. For each discipline, the background, commitment conceptualizations and the drivers influencing the development of commitment are introduced. While the synthesis reached in this chapter is drawn from the conceptualizations, the drivers will be consequently synthesized in Chapter 4.

3.1 Commitment in organizational behavior studies

Literally hundreds of articles have been published on the concept of commitment since its introduction to organizational behavior research in the early 1950’s. The commitment concept emerged from studies exploring employee – organization linkages. The motivation for the studies was provided by a belief that committed employees would be beneficial due to the potential for increased performance and reduced turnover and absenteeism (Mowday 1998). In the following, the main streams of commitment research are laid out, competing definitions and conceptualizations are introduced and drivers affecting the development of organizational commitment are reviewed. Concerning the historical development of the concept, the reader is referred to the bibliography for details.

The reason for the widespread interest in the commitment concept in the field of organizational behavior has been its assumed connection with turnover behavior and

Page 32: The role of commitment in software process improvement - Oulu

30

performance (Benkhoff 1997b). However, thirty years of intense research have produced mixed results in this regard.

“The present findings suggest that commitment has very little direct influence on performance in most instances.” (Mathieu & Zajac 1990, p. 184)

“After 30 years of research on employee commitment the results are disappointing. So far there is no evidence of a systematic relationship between commitment and its presumed consequences – turnover and job performance – even though these links are almost implied by the definition of the concept. Nor do we know very much about the factors that explain the phenomenon.” (Benkhoff 1997a, p. 114)

These views are not entirely shared since others point out that:

“Numerous studies have explored the associations between OC (Organizational Commitment) and various phenomena, with impressive results.” (Baruch 1998, p. 135)

“Although a great deal has been published on organizational commitment […] it’s important to ask whether these publications represent substantive progress in our understanding of the concept, as well as its antecedents and consequences. I believe that answer is clearly yes.” (Mowday 1998, p. 389)

Baruch (1998), however, criticizes the conceptualization of organizational commitment for impracticality and lack of scientific support. Despite these contrasting findings, commitment is linked with other positive organizational consequences as well. Such consequences commonly reflect an idea that a committed person stays with the organization through thick and thin, puts in a full day and more, protects company assets, shares company’s beliefs and goals (Meyer & Allen 1997), is a happy employee (Salancik 1977), invests freely in achieving the desired outcome (Conner & Patterson 1982), and even breaks the rules when necessary (Senge 1990). Although these and many other characterizations have been put forward, few of them have been empirically validated and agreed upon. In fact, literally hundreds of studies have tried to examine the correlations between commitment and variables hypothesized to be its antecedents or consequences (Meyer & Allen 1997).

3.1.1 Two schools of thought

Organizational commitment research has made a distinction between two schools of thought: attitudinal and behavioral commitment (Reichers 1985). Attitudinal commitment stems from the works of Buchanan (1974), Porter (1974) and Mowday and the others (1982). Behavioral commitment has its origins in Becker (1960), Kiesler (1971) and Salancik (1977). Mowday and the others (1982) explain the difference as follows:

“Attitudinal commitment focuses on the process by which people come to think about their relationship with the organization. […] Behavioral commitment, on the other hand, relates to the process by which individuals become locked into a certain organization and how they deal with this problem.” (Mowday et al. 1982, p. 26)

Page 33: The role of commitment in software process improvement - Oulu

31

The attitudinal perspective of commitment research represents the view taken by organizational behavior researchers as the behavioral perspective stems from the field of social psychology.

The difference is also visible in the research foci: The research on attitudinal commitment has traditionally been closely related to discovering the antecedent factors or conditions that contribute to the development of commitment and the behavioral consequences of such commitment. Behavioral commitment research has mostly been concerned with identifying the conditions under which a behavioral pattern tends to be repeated, as well as with the effects of such behavior on attitude change (Meyer & Allen 1991). Recently, some efforts have been made to merge these two approaches. Coopey (1991) asserts that commitment would be a more valuable research target if both approaches were recognized. Brown (1996) attempts to reconcile the attitudinal and behavioral approaches by suggesting that they are just the two sides of the same coin.

“A resolution of the two approaches may lie in the recognition that both attitudes and behaviors play a role in development. Behaviors – binding acts – probably work to seal a commitment, since a person, by definition, becomes committed by virtue of having taken some action or made some pledge. In the case of an internal pledge, behaviors in support of the commitment, particularly public behaviors, would act to strengthen it” (Brown 1996, pp.237-238)

In particular, Brown simplifies the concept into a singular concept of commitment as follows.

“Commitment to a particular entity is a distinct phenomenon, albeit a complex one, that may differ depending upon how certain factors, pertinent to all commitments, are perceived and evaluated by an individual” (Brown 1996, p.232)

This view forms a part of the foundation this thesis is built upon. In specific, Brown (1996) refers to a set of “certain factors” that are common to all commitments. These are focus, terms and strength. All commitments have an object – a target of commitment. The target can be organization, work team, project goal or idea. This, however, is not a new realization. Simon and the others (1950) are among the first ones to propose this differentiation. Morrow (1993), in her review, identifies five major targets of commitment: work itself, career, job, organization and union. Commitment targets can also be non-work related (Baruch 1998). The strength of commitment varies depending on the personal meaning associated with the commitment focus, i.e. the respective commitment target. It has long been proposed that commitment is a continuous variable rather than a dichotomous one (Kiesler 1971). Accordingly, people are referred to as being more or less committed rather than being simply committed or not. Although the suggestion was made by Kiesler (Kiesler 1971) a relatively long time ago, it was not until recently that Beck and Wilson (Beck & Wilson 2000) seriously challenged the argument. Their findings support Kiesler’s original argumentation. Concerning the existence of multiple commitment targets (i.e. different foci), there is also a notion of difference in the durability of commitment. Commitment to one’s career may last for a lifetime, while commitment to a project does not.

The terms of commitment define what has to be done in order to fulfill the requirements manifested by the commitment. A contract is an explicit pact where the

Page 34: The role of commitment in software process improvement - Oulu

32

terms are listed. If no public manifestation is made, only the committed actor knows to what extent s/he has to perform to fulfill the commitment. These manifestations differ depending on the commitment target. If the target of commitment is to reach a certain goal, the manifestation of such a commitment is the acceptance of the goal, willingness to exert necessary (or even more) effort in order to reach it and persistence in the face of difficulties (DeShon & Landis 1997). However, depending on the operating level (high or middle management, or staff), the visibility of the manifestation is likely to differ.

3.1.2 Conceptualization of commitment

It is difficult to provide a clear-cut definition of commitment due to the existence of different interpretations. For example, Morrow (1983) has identified 25 commitment related constructs in organizational commitment literature. The reason for this inconsistency and confusion has been attributed to the lack of a specific commitment model (Coopey & Hartley 1991). In commitment research, the term commitment is broadly used to refer to antecedents and consequences, as well as to the process of becoming committed or attached, or to the state of commitment or attachment itself (O'Reilly & Chatman 1986).

Mowday and the others (1982) provided the first extensive theory of organizational commitment. The authors identified some competing definitions of commitment. These definitions and the ones Meyer and Allen (Meyer & Allen 1997) have found are listed in Appendix I. Even though the definitions listed are more than twenty years old, they bear importance to contemporary commitment research, since they form the basis upon which the current view on commitment has been formed. The mere number of different definitions sheds light on the fact that no real consensus exists regarding the very construct of commitment.

Meyer and Allen (1991), however, have observed that the proposed definitions appear to reflect three general themes – affective orientation, cost based and moral obligation. This enables the grouping of definitions according to the approach they exemplify. Therefore, as a result of the analysis, Meyer and Allen (1991) propose that commitment as a psychological attachment may take the following three forms: affective, normative and continuance types of commitment. These forms may also be seen as bases of commitment, motives engendering attachment (Becker 1992). Each form of commitment can be characterized through the generic attributes introduced in section 3.1.1.

It should be noted that other classification schemes have also been proposed. The most notable one is the classification of O'Reilly and Chatman (1986), which has later been redefined by Jaros and the others (Jaros et al. 1993) and applied in research on the effects of organizational change on employees by, e.g., Bennet and Durkin (2000). Drawing from Kelman’s research (1958) on attitude and behavioral change, commitment can take three forms: (a) compliance or instrumental involvement for specific, extrinsic rewards; (b) identification or involvement based on a desire for affiliation; and (c) internalization or involvement predicated on congruence between individual and organizational values (O'Reilly & Chatman 1986, p. 493). In Kelman's original taxonomy, these 'ways of accepting influence' formed the basis for describing an attitude change. However, some

Page 35: The role of commitment in software process improvement - Oulu

33

researchers (Vandenberg et al. 1994) have found it difficult to differentiate identification from internalization, and others (Meyer & Allen 1997) suggest that compliance or instrumental commitment is some kind of antithesis of commitment and its inclusion in the construct would just invite more confusion to the field. It has been proposed that internalization and identification, rather than being commitment conceptualizations, are mechanisms by which affective commitment may develop (Meyer & Allen 1997). Meyer and Allen's conceptualization, in turn, has received empirical support (Dunham et al. 1994, Hackett et al. 1994, Suliman & Iles 1999, Hartmann & Bambacas 2000) and it has been tested for homogeneity1 (Benkhoff 1997a). However, despite the criticism displayed against the notion of instrumental commitment, it can be considered as one possible form of commitment in regard to SPI initiatives. There is not enough evidence in the literature to disregard the notion of instrumental commitment.

Meyer and Allen's forms of commitment are identified from studies related to organizational commitment, but they are adaptable to other commitment targets as well (Meyer et al. 1993, Meyer & Allen 1997). Thus, an actor, be it a manager or a software developer, might be committed to an SPI project in all four forms. These forms (or archetypes) of commitment are introduced in brief in the following.

Affective commitment

Affective commitment refers to an actor’s attachment to, identification with, and involvement within the respective entity (Meyer & Allen 1991). It includes a feeling of belonging and sense of psychological attachment to the target of commitment (Hartmann & Bambacas 2000). This entity, as argued by Meyer and Allen (Meyer & Allen 1997), may be an organization, a project, a supervisor or a fellow worker – anything that bears importance for an actor. SPI authors maintain that software process improvement could bear such an importance.

Continuance commitment

Continuance commitment refers to an awareness of the costs associated with leaving or abandoning the respective entity (e.g. aborting a project) (Meyer & Allen 1991). These costs may be both financial and non-financial (Becker 1960), lack of alternatives (Hrebiniak & Alutto 1972) or binding organizational arrangements (Hartmann & Bambacas 2000). If an organization, e.g., has a reward structure in which a manager's performance is linked with the success of SPI activities, it can be said that the primary commitment driver of the manager is continuance commitment (could be other forms too, but reward structure generally invites continuance commitment). In the literature concerning information systems (IS) research, the term commitment escalation is very closely related to this form of commitment (see section 3.2 for details).

Normative commitment

Normative commitment reflects a feeling of obligation to continue membership with the entity in question (e.g., SPI project). The concept of normative commitment was originally introduced by (Wiener 1982), who argued that normative commitment should 1 Homogeneity is a statistical measure that indicates whether variance – i.e., measure of how spread out a distribution is – within each of the populations is equal.

Page 36: The role of commitment in software process improvement - Oulu

34

be viewed as “the totality of internalized normative pressures to act in a way that meets organizational goals and interests”. Another commonly used term for normative commitment is moral commitment (Jaros et al. 1993). However, as normative commitment may only last until the ‘debt’ is regarded as paid (Meyer & Allen 1991), it is subject to be lost later on. If a software project participates in an SPI initiative because of managerial mandate, personal favor or any other internal or external pressure, what we are dealing with here is normative commitment. Thus, if normative commitment is the dominating form of commitment, it will potentially only last as long as the internal or external pressure is present or until the “debt” remains unpaid.

Instrumental commitment

Instrumental commitment refers to a form of involvement for specific, extrinsic rewards (O'Reilly & Chatman 1986). It is the least traditional form of commitment in the sense of how commitment is generally perceived, since in this case the binding effect connected with commitment has to do with extrinsic rewards. Vandenberg and the others (1993) suggest that instrumental commitment indicates acceptance of [project’s, organization’s] goals not because of a personal recognition of the goals, but rather due to a desire to gain benefit and to avoid punishment. Accordingly, this form of commitment differs from the affective, continuance and normative forms, since the state attachment is directed towards a reward and not towards the goal itself. Thus, if instrumental commitment is the dominating form of commitment, its durability will be connected to the instrumental values attached to the act of participation. In the SPI context, the reward can be interpreted as the benefits obtained from an SPI initiative. In addition, the reward may well be something else than strictly of monetary value.

3.1.3 Commitment drivers identified in OB literature

Different forms of commitment (affective, continuance, normative and instrumental) develop through their own mechanisms (Meyer & Allen 1991). This argument has also received empirical support (Coleman et al. 1999). Thus, these forms shall be treated here separately.

The literature concerned with the development of affective commitment (toward an organization) has classified a wide range of variables supposedly affecting the process into three categories: 1) organizational characteristics, 2) personal characteristics and 3) work experiences (Meyer & Allen 1997). Of these characteristics, work experiences are seen to play the most important role in the development of affective commitment toward a commitment target (Mathieu & Zajac 1990). Meyer and Allen (1997) have reviewed the antecedents and found that job challenge, degree of autonomy, variety of skills used, role ambiguity, role conflict, participation in decision-making, fairness of policies and treatment, personal fulfillment, employee-manager relationship, personal importance and personal competence play an important role in the development of affective commitment.

The organizational characteristics identified were fairness of organizational policy, decentralization and policy communication in terms of amount of information given and sensitivity shown. Personal characteristics such as gender, age, tenure, marital status, and

Page 37: The role of commitment in software process improvement - Oulu

35

the level of education do not contribute significantly to the development of affective commitment. The strongest correlations of personal characteristics with commitment types have been found between perceived competence and affective commitment (Mathieu & Zajac 1990). This suggests that employees who have a strong confidence in their abilities and achievements tend to develop a stronger sense of affective commitment than those who do are less confident (Meyer & Allen 1997). Meyer and Allen conclude that it is above all through personal fulfillment that affective commitment develops.

The development of continuance commitment has not been studied as much as the development of affective commitment (Meyer & Allen 1997). However, the process through which one becomes continuance committed toward a commitment target is rather straightforward. Meyer and Allen argue that continuance commitment can develop as a result of any action or event that increases the costs of leaving the organization. Two sets of antecedent variables have been identified: investments and alternatives. In their analysis, Meyer and Allen have found investments including various factors, such as transferability of skills, retirement money, status, job security and the role of provider in one’s family. Alternatives reflect, for example, existing employment opportunities and attractiveness of those opportunities.

However, recognition of investments and alternatives prevail the development of a sense of continuance commitment. If one does not recognize having made costly investments or having no alternatives, no sense of continuance is likely to develop. This thesis maintains that continuance commitment also has a role in SPI (V, also in Abrahamsson 2001b). However, since the commitment target is different, also the antecedent factors are likely to be different from those of organization-related continuance commitment. Continuance commitment is linked closely with the concept of escalating commitments2 (this is discussed in detail in section 3.2 ).

The development of normative commitment has received the least interest of the various types of commitment in the field of organizational commitment research. Wiener has argued in his seminal work (1982), that normative commitment towards an organization develops through a socialization process. A newcomer to an organization learns what is valued and what is expected of a novice by the organization or by a project team. In turn, the newcomer is expected to behave in an acceptable manner. The process which is referred to by Wiener (according to Meyer and Allen’s (1997) interpretation) is called internalization. What is internalized is a notion of appropriateness concerning loyalty to one’s team.

Investments made by an organization in their employees that seem hard to reciprocate are also suggested to contribute to the development normative commitment (Meyer & Allen 1991). Such an investment may be an expensive training session that the organization agrees to cover. Similar reciprocal elements may also be seen in SPI efforts. Quality personnel may, for instance, assist a development project with tackling some specific problem. The project may then feel obligated to return the favor by, e.g., giving feedback for process descriptions more actively. In addition, normative commitment may develop on the basis of psychological contract (Rousseau 1995). Such a contract consists 2 Escalation of commitment refers to a situation where a decision maker commits additional resources to a failing course of action (Staw 1981). The phenomenon has been studied in IS setting, see Keil (1995) for details.

Page 38: The role of commitment in software process improvement - Oulu

36

of “beliefs of the parties involved in an exchange relationship regarding their reciprocal obligations” (Meyer & Allen 1997, p. 61). Empirical evidence (Vardi et al. 1989) also suggests that the congruence of organizational values and core values of a society may promote the development of normative commitment. In the SPI context, the ‘outer world’ or outer context is often the rest of the organization, while the inner world are the stakeholders involved in the SPI effort (Seppänen et al. 2001). Therefore, the congruence of organizational values with values brought in by the SPI effort are likely to generate normative commitment, unless the values conflict.

There are very few sources available in which the development of instrumental commitment has been researched. As stated, the notion of instrumental commitment suggested by O'Reilly and Chatman (1986) is drawn from the works of Kelman (1961). Kelman has studied the processes of attitude change. He originally maintained that the basic question was whether the influence attempt produced public conformity without private acceptance or whether it was able to produce public conformity coupled with private acceptance. The case of lacking private acceptance would thus indicate that the acceptance was achieved through other – extrinsic – reasons, such as a promised reward. The public and private attitudes, including the behavior itself, may therefore differ. In the SPI context, this would refer to a situation in which SPI actions are performed in order to avoid a possible punishment and/or to gain some rewards. Thus, the existence of reward and punishment mechanisms may serve as drivers giving rise to a form of instrumental commitment. More importantly, if the goals of an SPI effort only benefit the organization and not the person performing the defined improvement actions, a sense of instrumental commitment on the behalf of that person may develop.

3.2 Commitment in information systems studies

The research in information systems has long been arguing that the primary cause for information systems failures is related to organizational issues rather than technical ones (e.g., Lucas 1975). Ginzberg (1981), Markus (1981) and Lucas (1981) were among the first to introduce the concept of commitment to the IS field. Ginzberg, among others, has concluded that a state of commitment should be developed, since it increases the odds that appropriate actions will be taken to assure the success of a software project. This article of his has become one of the most cited publications regarding the commitment concept in the IS field.

3.2.1 Two streams of IS related commitment research

IS research has been largely occupied with the escalation of commitment in information systems development projects in recent years (Ewusi-Mensah & Przasnyski 1991, Keil 1995, Keil et al. 1995, Keil et al. 1998, Keil & Robey 1999, Mahaney & Lederer 1999, Keil et al. 2000). Escalating commitment suggests the notion of becoming ‘too much committed’ (Sabherwal & Elam 1995). Escalation occurs when troubled projects are continued instead of being redirected or cancelled (Keil et al. 2000). The research on

Page 39: The role of commitment in software process improvement - Oulu

37

commitment escalation is well founded, since as much as 84% of IT projects fail to stay within the budget and project timeframe (Johnson 1995). The research on escalating commitment originates from Staw’s early work centered on understanding why decision makers continue to recommit resources to a failed or failing course of action (Staw 1976). Recently, proponents of escalation research have turned their attention to the de-escalation phenomenon, which occurs whenever reduced commitment to a failing course of action can be found (Montealegre & Keil 2000).

Another stream of research on commitment in the field of IS which has gained some attention (much less, however) is concerned with commitment to information systems development projects, also called “good” commitment (Sabherwal & Elam 1995, Newman & Sabherwal 1996). This is the type of commitment that Ginzberg (1981) originally called for. However, this stream of research also draws heavily upon the escalation literature. Most escalation studies show variance theory3 orientation (see as an expection Montealegre & Keil 2000), suggesting that as soon as certain conditions are met, commitment to any target will appear. However, commitment to ISD (Information Systems Development) studies has relied on in-depth case studies, in which theories emerge from the case data. This is a type of approach that is very similar to the one that has been chosen for this thesis. For this reason, IS related commitment studies are to be considered within the context of this study.

Both research perspectives (too much commitment and commitment to ISD) draw their theoretical perspective on commitment from the behavioral school of commitment research. Proponents such as Becker (1960), Kiesler (1971), Staw (1976) and Salancik (1977) are referred to for definitions of the concept of commitment.

While the escalation of commitment related to software process improvement has not been proposed as a distinct phenomenon, this issue has, however, been reported in recent literature. Aaen and Bang (2002), for example, describes an industrial case in which more and more resources were invested in order to reach certain level of maturity. Due to the heavy investment in the effort other issues had to be ignored in order to reach the intended capability level. In such cases, SPI literature refers to the “certification hunting” problem (Moitra 1998). Even though the escalation phenomenon itself is beyond the scope of this thesis, the escalation literature is well suited for our purposes, because it also involves the aspect of how commitment changes over time – an issue that organizational commitment researchers have been overlooking until recently. Each case in Chapter 6 is analyzed also in terms of how commitment changes over time in the respective SPI projects.

The literature dealing with organizational commitment has mainly been interested in aspects related to individual level commitment. However, rather that focusing on a single software designer, software process improvement efforts generally concern a group of designers (e.g. a software project team) or even an organization as a whole. IS-related commitment research has acknowledged the existence of multiple level commitment. 3 Mohr (1982) distinguishes between “variance theory” and “process theory”. Variance theory explains phenomena in terms of relationships between dependent and independent variables. Process theory, on the other hand, attempts to explain the phenomena in terms of the sequence of events leading to an outcome. Understanding patterns in events is the key in the development of process theory (Langley 1999).

Page 40: The role of commitment in software process improvement - Oulu

38

Newman and Sabherwal (1996) identify four main levels to be considered when studying commitment in information systems development projects: the project, each decision maker, social group and the organization. Thus, these levels also identify actors capable of showing commitment toward a certain commitment target.

3.2.2 Commitment Drivers identified in IS literature

The literature on commitment escalation is mainly concerned with the question why a decision maker chooses to continue with a specific course of action. Even though the purpose of this study is not to explore the reasons for excessive commitment of a person, a group or an organization, the concept of commitment escalation helps us to clarify some universal developmental aspects of the commitment phenomenon.

The literature has divided the drivers (Table 4) of this sort of commitment into four types: 1) project, 2) psychological, 3) social and 4) structural drivers (Staw & Ross 1987). Project drivers are objective features of the project (i.e., target of commitment, SPI in this thesis) (Newman & Sabherwal 1996), such as costs and benefits associated with the project. The commitment to a project is likely to increase when the costs of terminating the project are high, the salvage value is low, and no feasible alternatives are available (Staw & Ross 1987). Furthermore, when the performance data is ambiguous or the problems with a project can be attributed to a temporal cause, commitment is likely to be escalated. Psychological drivers reflect the state of emotional attachment developed towards the project (Keil et al. 1995). Such issues as personal responsibility for an action, information-processing errors, continuity of champion, and prior historical success belong to this category.

The social drivers originate from the group involved in the project (Newman & Sabherwal 1996). In the case of SPI, this group may consist of peers, SPI staff or managers. Identification with the project, competitive rivalry and consistency norms are examples of drivers indicating social pressure build-up. Lastly, structural drivers represent “the contextual conditions” surrounding the project (Newman & Sabherwal 1996). These include the political environment, past experiences, SPI organization, organizational maturity, and the like. While the IS literature on commitment escalation has not acknowledged the multidimensionality of the commitment concept, the drivers of commitment suggest different forms of commitment. Newman and Sabherwal (1996) have found that project and structural drivers play an important role in the early phases of the project, during which initial commitment is generated. Later on, the role of social and psychological drivers is likely to increase, causing changes in subsequent commitment levels.

Page 41: The role of commitment in software process improvement - Oulu

39

Table 4. Summary of commitment drivers identified in IS literature.

Category Driver Original source Notes

Project Long-term payoff structure,

large closing costs, low salvage

value, large payoff, infeasibility

of alternatives, temporary cause

of setback

(Ross & Staw 1993,

Keil 1995, Keil et al.

1995)

Objective features of the project.

Personal responsibility for

failure, information processing

errors, framing, sunk costs,

reinforcement traps, continuity

of champion, emotional

attachment, prior history of

success

(Staw 1976, Davis &

Bobko 1986, Ross &

Staw 1993, Keil et al.

1995)

Information processing errors

suggest seeking and interpreting

evidence in a way sustaining prior

beliefs and overestimation of the

chances of success (Newman &

Sabherwal 1996). Framing the

decision as a choice between

losing options, and sunk costs also

causes information processing

errors (Newman & Sabherwal

1996).

Psych-

ological

Strong and repeated support in

the past, value attached to

turnarounds,

(Keil & Mixon 1994) Individual level driver; possibly a

group level. No empirical support

for these drivers.

Social Public identification with the

project, responsibility for failure,

competitive/ political rivalry,

successful models of persistence,

norms of consistency, public

decision context, emotional

attachment, prior resistance

encountered

(Fox & Staw 1979,

Caldwell & O'Reilly

1982, Ross & Staw

1993, Haunschild et al.

1994, Keil et al. 1995)

Originate from the group rather

than from the individual

Political support for the project,

including top management

support, institutionalization, or

strategic nature of the project,

slack resources

(Ross & Staw 1993,

Keil et al. 1995)

Outer context of SPI Structural

Maturity of IS function, top

management knowledge of IT,

information intensity of the

organizational value chain and

products

(Johnston & Carrico

1988, Sabherwal &

King 1992)

Potentially identifiable in SPI

context as well. No empirical

support for these drivers.

Page 42: The role of commitment in software process improvement - Oulu

40

3.3 Summary - towards a typology of commitment

The purpose of this subsection is to present a typology of commitment that can be used in this thesis as the basis of the commitment concept. A typology in the form of commitment definition is thus developed on the basis of the literature review. In the cross-case analysis (Chapter 7), the developed typology will be used and evaluated against the empirical case data.

3.3.1 Common aspects of commitment

Based on the literature review in related disciplines, Brown’s (1996) common aspects (focus, terms and target) are expanded to include form (based on the commitment concept’s multidimensional nature), durability (based on differing commitment targets) and actor (based on a multi-leveled view of the owner of the commitment). These six dimensions of the concept of commitment concept constitute the common aspects of all commitments. Table 5 summarizes these commitment aspects and states how they are expected to appear or to behave in the context of SPI.

Table 5. Common aspects of commitment.

Aspect of commitment

Description

Form The nature of commitment: Commitment is formed of its components. At least four forms

of commitments exist: affective, normative, continuance and instrumental. These forms

build up a composite that changes over time. Forms may also be seen as sources of

commitment, motives engendering attachment. (O'Reilly & Chatman 1986, Meyer & Allen

1991, Becker 1992)

Focus Defines the target of one’s commitment. Targets can be work or non-work related. Work

related targets are organization, project, one’s career, or profession. (Simon et al. 1950,

Gouldner 1960, Coopey & Hartley 1991, Morrow 1993, Brown 1996, Meyer & Allen

1997, Baruch 1998)

Durability Depending on the commitment target, the durability of ‘personal contract’ varies. For

example, commitment to career may last for a lifetime but commitment to a project is not

likely to do so. (Brown 1996)

Terms Terms of commitment define what has to be done in order to fulfill the requirements

manifested by the commitment. A contract, for example, is an explicit pact where the terms

are stated. (Brown 1996)

Strength Defines the extent to which a person or a group is attached toward an entity. A person is

more or less committed than simply committed or not. (Kiesler 1971, Brown 1996, Beck &

Wilson 2000)

Actor Unit of analysis in commitment studies. 1) An individual, 2) a group or team and 3) an

organization can show commitment toward an entity. (Newman & Sabherwal 1996)

Page 43: The role of commitment in software process improvement - Oulu

41

3.3.2 Definition of commitment

As shown above, a series of attempts have been made to define and conceptualize commitment over the last forty years. Based on the literature review of commitment research, the view on commitment closely related to that of (Meyer & Allen 1991) and (Brown 1996) has been chosen as the fundamental basis for the typology of commitment used in this thesis. The reasoning for this decision is to be found in the strong tradition of commitment research in the field of organizational behavior and its explicit focus on conceptualizations, which has not been paid too much attention to by other disciplines. Moreover, this view on commitment has – to a great extend – received the necessary empirical support. Thus, commitment is defined as follows, see also Fig. 2:

Commitment is a state of attachment that defines the relationship between an actor (an individual, a group or an organization) and an entity (commitment target). This relationships takes different forms (affective, continuance, normative and instrumental) which share certain common aspects (focus, strength, terms and durability) in all the forms of commitment.

ACTOR ENTITY (COMMITMENT FOCI)Relationship

Commitment

defines

Affective

Continuance

NormativeStrength

Focus

Terms

Durability

FORMS OF COMMITMENT

Acceptance

Effort expenditure

Persistence

Organization

Group

Individual

Instrumental

Fig. 2. Commitment defined

The definition of commitment is thus a synthesis of contemporary commitment literature from related disciplines. It is, by design, a static definition of commitment. In Kiesler’s (1971) words, it is a literary definition. As such, it provides a typology for discussing commitment at a more profound level. An operational definition is built in the following chapter by adding dynamism, which is inherent in the commitment phenomenon, to the literary definition, the outcome literary definition taking the shape of a commitment net model. The results of the commitment driver analysis are thus operationalized in Chapter 4.

Page 44: The role of commitment in software process improvement - Oulu

4 The Dynamic structure of the commitment process

While the previous chapter considers the typology of the static commitment concept, this chapter concentrates on the dynamic aspects of commitment. The purpose is to build a model of commitment that can be used for analyzing four SPI initiatives in the empirical part (VI, thesis summary) of the thesis (Chapter 6). This chapter proceeds as follows. First, existing commitment models are analyzed in terms of their assumptions about the commitment concept and its development. The analysis is divided into scientific and practical models of commitment. Based on this analysis, a model of commitment nets is developed and its parts introduced. This model, the typology of commitment concept (Chapter 3), and the typology of SPI (Chapter 2), constitute the framework through which SPI projects will be analyzed.

4.1 Analysis of dynamic commitment models

While researchers have had difficulties in conceptualizing the concept of commitment, even less is known about the commitment process itself. Commitment researchers’ self-critique has revealed that they have paid little attention to the process itself (Staw & Salancik 1977, Scholl 1981, O'Reilly & Chatman 1986, Meyer & Allen 1991).

“Considering the paucity of studies, however, [process] discussion is necessarily speculative. It is intended primarily to illustrate the importance of process considerations, to indicate how different processes are likely to operate for affective, continuance, and normative commitment, and to provide some direction for future research.” (Meyer & Allen 1991, p. 74)

The approach chosen by organizational commitment researchers has been a static one – a snapshot view on commitment (Coopey & Hartley 1991). The typology of commitment introduced in the earlier chapter is not, however, sufficient to study the complexities of the commitment process in an organizational context, i.e., if a process approach is selected.

The analysis is divided into scientific and practical models of commitment. The goal of the analysis is to identify assumptions underlying the models regarding the

Page 45: The role of commitment in software process improvement - Oulu

43

development of commitment. If it can be shown that assumptions are acceptable in the light of contemporary commitment research, these models are capable of serving as basis for the model to be used in this study. Practical models, as opposed to scientific ones, are based on anecdotal evidence and experience of consultant writers. Practical models do not use scientific evidence to support their claims.

The scientific model included in the analysis is adopted from the IS field, where the change in commitment over time has been empirically studied. Other scientific commitment models proposed are either variance theory oriented (e.g., Staw 1981) or lack the empirical support (e.g., Brown 1996). Variance theory orientation necessitates an exclusive focus on factors that contribute to the existence or non-existence of the commitment thus neglecting the developmental or processual approach. Therefore, they fall outside the scope of this thesis. A recent process study on the reduction of commitment by (Montealegre & Keil 2000) was omitted due to the differences in research context. The authors have made a qualitative study on how commitment to a failing course of action has de-escalated at Denver International Airport. The scale, scope and context of the study bear little similarity to software process improvement within a software development unit. Thus, a decision was made not to include this model in the analysis.

The SPI literature search discovered two practical models that are currently used: Conner and Patterson’s (1982) model of commitment development and Ernst & Young’s model of commitment to new thinking (Huge 1990). A slightly modified version of Conner’s model is presented at the web site of the Software Engineering Institute (SEI 1999). The stages originally suggested by Conner and Patterson are commonly transformed into the so-called standard technology adaptation curve, i.e. the S-curve (Kuvaja et al. 1994, Paulk 1999). Ernst & Young’s model is linked with the quality movement of the 1980’s, which has provided the intellectual basis for SPI thinking (Dahlberg & Järvinen 1997, Zahran 1998).

4.1.1 Scientific commitment models

In a longitudinal study of an IS project, Newman and Sabherwal (1996) have examined the drivers of commitment, i.e. the factors affecting the making, keeping or withdrawal of commitment. In specific, they have examined six major IS decisions that were made over a 17-year period. As one of the results of their study, they have built a dynamic model of commitment (Fig. 3), including five processes (A – E). Three of these are decision-making processes (A, making initial commitment; C, withdrawal of commitment; E, making commitment to a new approach) and two are intervening events (B, D). Newman and Sabherwal explain that the IS project started with A and was followed by the loop B->C->D->E->B. This loop was traversed three times. Each time the ensuing event with B was different, as depicted in Fig. 3. The authors identify the drivers influencing the different phases of the project. One of the key findings was that project and structural drivers were crucial in the project initiation phase, while social and structural drivers were found to influence the decision whether or not the commitment to the project was withdrawn, and that psychological and project drivers contributed to the escalation of

Page 46: The role of commitment in software process improvement - Oulu

44

commitment. Newman and Sabherwal (1996) base the dynamics of their model and their findings on empirical evidence.

Projectdeterminants

Structuraldeterminants

Making initialCommitment

Ensuing events

Reduction insocial

determinants

Reduction instructural

determinants

Withdrawal ofcommitment

Ensuing eventsMaking new

commitment to anew approach

conflict

changesin topmanagement

deterioatingorganizationalperformance

Reduction insocial

determinants

Reduction instructural

determinants

identificationof an alternativeapproach forcontinuing

new manager’sdesire to turn theproject around

A B C D E

Fig. 3. The dynamic commitment model (Newman & Sabherwal 1996)

The model is based on a single case study on a single IS development project (which is also acknowledged by the authors). The model is descriptive rather than a prescriptive one. Newman and Sabherwal’s (1996) dynamic model of commitment shows how commitment has evolved over a long period of time. It does not prescribe how things should have gone or be done. Even though it is not explicitly stated by the authors, the model describes the commitment process within the organization, which had been driven by top management decisions, changes in top management, organizational performance and conflicts. From the perspective of this study, their model sheds light on using the drivers identified in the organizational behavior literature to explain commitment change. However, commitment is largely seen as a dichotomous variable, i.e., it either exists or it does not.

If the level of abstraction is lifted and case specific details (events, types of drivers, types of commitment decisions) are removed, it is possible to argue (based on the model introduce above) that the commitment to a project is influenced by certain drivers (social, project, psychological and structural), which can be affected by some tactics (which are not present in the model) suggested by the authors in the article. In an earlier article, Sabherwal and Elam (1995), propose a theoretical model of commitment (Fig. 4), which is in line with the argumentation presented above and extends it to include the considerations of outcome, behavior and resource. The authors propose that project outcome depends on the behavior and on the resources available during an information system development project. Thus, the outcome box in Fig. 4 is the project outcome, not the outcome of a behavior. In fact, the outcome of a behavior is not included in their model. To Sabherwal and Elam, a behavioral act, as such, affects the drivers of

Page 47: The role of commitment in software process improvement - Oulu

45

commitment. Therefore, the unit of analysis in their theoretical model is a project, even though this is not apparent in the model. The purpose of Sabherwal and Elam’s article is not to assess the model, but to identify tactics for building and sustaining commitment. Again, the results are based on a single in-depth case study.

Determinantsof

CommitmentCommitment

Behavior- tactics- some problems- other actions

Outcome

Resources

Fig. 4. The theoretical model (of commitment) (Sabherwal & Elam 1995)

Sabherwal and Elam (1995) and Newman and Sabherwal (1996) use Staw (1982) and Salancik (1977) as their main references in defining commitment. Thus, the view on commitment that they hold is based on the behavioral school of commitment research. This bears importance since, as indicated earlier (Section 3.1.1), the behavioral school of commitment research is mostly concerned with identifying the conditions under which a behavior tends to be repeated. Therefore, the research in this area assumes that a commitment exists a priori.

An analysis shows that neither of the models shown in Fig. 3 or Fig. 4 is applicable in its current form for the purposes of this study. In specific, Newman and Sabherwal’s (1996) model is too context dependent and it fails to indicate the level of analysis clearly enough. Sabherwal and Elam’s (1995) model, on the other hand, is not described in the article accurately enough and it also contains ambiguous concepts such as “some problems” and “other actions”. Both models also presuppose the existence of commitment a priori to the target of the study.

4.1.2 Practical commitment models

Practical commitment models are important, because they reflect a common-sense view to commitment phenomena. They are also important as they are used by SPI practitioners and researchers for explaining how commitment operates in an organization. Even though the tone in the analysis is critical, the purpose here is, rather than undermining these models, to bring out their view on commitment development. Based on this approach, assumptions are identified and discussed. The assumptions will then be evaluated against the empirical findings in the cross-case analysis section of this thesis (Chapter 7).

Page 48: The role of commitment in software process improvement - Oulu

46

4.1.2.1 Commitment to change

Conner and Patterson (1982) argue that the process of building employees’ commitment to change can be represented as a causal model, through which an organization(al unit) as a whole is taken. Therefore, we are dealing here with a commitment model for the organizational level. The components and processes in the model, however, imply changes at the individual level. Thus, as will be shown, the unit of analysis remains unclear to the reader. Due to the fact that the boundaries between organization and individual fail to be clearly defined, it is often difficult to work out who is the actor in the model. Therefore, there may be some ambiguity in the following description of the model dynamics. The following model, see Fig. 5, also shows the hypothesized outcome for each stage if the stage is not adequately completed.

DE

GR

EE

OF

SUPP

OR

TFO

RT

HE

CH

AN

GE

Com

mit

men

tP

hase

Acc

epta

nce

Pha

sePr

epar

atio

nPh

ase

COMMITMENTTHRESHOLD

DISPOSITIONTHRESHOLD

I. Contact

II. Awareness ofChange

III. Understand the Change

IV. Positive perception

V. Installation

VI. Adaptation

VII. Institutionalization

VIII. Internalization

TIME

UnawarenessConfusion

Negative

perception

Decision not to

attempt/support

installation

Change aborted

after initial

utilization

Change aborted

after extensive

utilization

Fig. 5. Development of commitment to change (Conner & Patterson 1982).

The model is presented as a grid with the vertical axis representing the degree of support for a change. The authors do not, however, define whether the organization or a single employee shows this support. The horizontal axis represents the time scale. The model is suggested to provide "a cognitive map of how commitment can be generated".

Page 49: The role of commitment in software process improvement - Oulu

47

The model, therefore, is intended for managers to be used for a better understanding the complexities of commitment when planning organizational changes. The model is divided into three phases: (1) preparation, (2) acceptance and (3) commitment. Conner and Patterson propose a total of 8 stages (see Fig. 5) for an organization or a person to go through when becoming committed to a change goal. The authors claim that each stage indicates a critical juncture, in which commitment can be threatened. This is represented by the arrows pointing down. If a stage is completed successfully, advancement to next stage is possible.

The purpose of the preparation phase is to produce an awareness of the possibility of changes occurring in the future. In the acceptance phase, a person produces a tendency to act in certain ways towards a change project. The acceptance phase may also enable the development of a predominantly negative perception, which could lead to the first signs of true resistance. If a person develops a positive perception of the upcoming or ongoing change, a decision to support the change is made and one – with the entity remaining undefined, a person or an organization – is able to advance to the next commitment phase. At this stage, the change becomes operational, i.e. it is tried out or piloted, and a decision is made either to abort the change if it is, for instance, viewed too expensive, or to institutionalize it as an organizational policy. The institutionalizing stage is the highest attainable level for an organization, with the members of the organization controlling the internalization. Conner and Patterson argue that when a change has been internalized, "participants engage in goal-oriented activities in order to satisfy their own needs, as well as those of the organization." Furthermore, according to the authors, “enthusiasm, high-energy investment and persistence characterize commitment at the internalized level”. In the SPI literature, Zahran (1998), for example, acknowledges the internalization phase and suggests that the ultimate goal is to make the new process 'painless'. He describes this as follows:

“Once you have experience and knowledge of a certain situation 'wired' into your brain, this knowledge is automatically retrieved when you face a similar situation. Your actions will be nearly automatic. The process has been 'internalized' by you.” (Zahran 1998, p. 5)

Conner and Patterson's article(Conner & Patterson 1982) has been designed for a practice-oriented audience, which is why it does not contain any references to related literature, nor does it offer any specific conceptualization of the very concept of commitment. The model is based on anecdotal evidence and experience as consultants, therefore failing to provide any scientific evidence to support the claims involved.

The article is, however, well written and it provides a number of useful 'tactics' or strategies for addressing the commitment issue in times of organizational change. Many of the tactics and points made in the article seem plausible. Kaplan (1964) calls the linear transition proposed by Conner and Patterson (1982) as an 'ideal' type that

“does not function as an observational term or even an indirect observable; the fact, therefore, that there is nothing in the world corresponding to it does not of itself rob such concept of scientific usefulness.” (Kaplan 1964, p. 82)

Thus, Conner and Patterson’s model should be seen as an ideal type of commitment transition, which does not necessarily have to correlate with real world events. Indeed, the

Page 50: The role of commitment in software process improvement - Oulu

48

model is in active use. For example, SEI has adopted it as a 'tactic' or a 'strategy' for building up commitment in general (Paulk 1999).

4.1.2.2 Commitment of management to “new thinking”

Ernst &Young (Huge 1990) explore the concept of management commitment in the context of customer oriented quality thinking. Similarly to Conner and Patterson, the authors suggest that commitment moves sequentially through several stages in a causal fashion, Fig. 6.

Enough commitment tosponsor pilot activities

- Personally uninvolved- Need significant short-term results

Commitment of timeto gain an understanding

Intellectual understanding

Willingness to work oncultural issues and to increase

personal involvement

Desire to change one’s own behavior

Completely internalized,i.e., behavior reflects new thinking

- No real desire to work on cultural issues- Needs short-term benefits to justify further

investments

- No desire to change his/her behavior

- Management doesn’t need short-term benefitsto justify the investment in time and effort

- Puts quality ahead of quantity

Fig. 6. Development of management commitment to 'new thinking' (Huge 1990).

While the stages in the model seem self-explanatory and appealing at first sight, Ernst & Young do not provide any detailed explanations on what they mean by, e.g., intellectual understanding. What is the real aspiration and what it is that gives rise to it? What does it signify to put quality ahead of quantity? A detailed look into the model brings up more questions than answers. According to Ernst & Young, management has to be willing to change their own behavior to reflect the new thinking sought. In other words, Total Quality Management principles, including concepts, philosophy, and a longer-term perspective should be adopted. The progression in the model is accompanied by a decrease in the need for short-term benefits to justify further investments in quality

Page 51: The role of commitment in software process improvement - Oulu

49

initiatives (Taylor 1995). Taylor (1995) has applied Ernst & Young's model and notes that due to its foundation on anecdotal evidence and on the experience of the consultancy staff the model lacks any scientific evidence to support its claims. Ernst & Young have designed their book for the needs of a practice-oriented audience and thus use no references. The authors employ a lot of eye-catching slogans such as "they must see the light!"

Some of their arguments can be supported by such simplistic theories as the notion that if people are sufficiently involved in something, they will ultimately become committed to it. Although oversimplified, both the Ernst and Young model and this idea have some theoretical background. For example, Bem’s (1972) self-perception theory asserts that individuals come to

“know their own attitudes, emotions, and other internal states partially by inferring them from observations of their own overt behavior and/or the circumstances in which this behavior occurs.” (Bem 1972, p. 2)

The authors, however, have gone as far as to define the number of hours of involvement needed to have someone committed, e.g., 10–15 hrs/week for a period of 3–6 months. The problem with this type of practical cookbook advice is that it is not very practical (Kofman & Senge 1993) because it often oversimplifies the inherent complexities involved, omitting context, type of change and people involved.

4.2 Assumptions in current thinking

Russo and Stolterman (2000) have recently clarified and explicated the existing assumptions in IS research and argued that

“if these assumptions are not explicitly identified and analyzed by IS researchers, we believe that there is a risk that research and practice will continue to face the same problems of ''misfit'' over and over again.” (Russo & Stolterman 2000, p. 314)

Similarly, the SPI field needs to have its assumptions critically assessed in order to determine if research and practice are on legitimate paths. Based on the analysis presented above, five assumptions can be identified, which the existing models of commitment development are based upon. In the following, these assumptions are described only in brief due to the fact that the purpose here is to prepare the ground for the development of a new model of commitment, which is then used for analyzing the empirical material. Thus, regarding the assumptions, readers are referred to articles IV and V in the Appendix for a more detailed discussion. The assumptions, however, are critical since they have shaped the research in the field of SPI (Table 6).

Page 52: The role of commitment in software process improvement - Oulu

50

Table 6. Assumptions have shaped the SPI research.

Assumption Current research in SPI4 References

The causality in commitment

process

Dominating models are life-cycle

oriented with a definite set of steps for

implementation.

(Conner & Patterson 1982,

Huge 1990, Paulk 1999)

The controllability of

commitment process

Proposes tactics to build or to maintain

someone’s commitment, cookbook type

recipes on how to get someone

committed, and how to handle the

commitment problem.

(Drennan 1989)

The notion of a singular

commitment construct

One type of commitment exists and this

commitment is ‘needed’ in SPI.

(Humphrey 1989, Hadden

1999)

A view of commitment as an

all-positive phenomenon

Commitment-oriented culture is needed

for implementing SPI; commitment is an

integral part of SPI models.

(McFeeley 1996, Birk et al.

1998, Hadden 1999, Isacsson

et al. 2001)

Evolvement of shared

commitment

Individuals, groups and organizations are

not explicitly separated as different

analysis units.

(Conner & Patterson 1982,

Huge 1990, Paulk 1999)

4.2.1 Causality in commitment process

The first underlying assumption behind both models concerns the notion of causality in the development of commitment. While it fits comfortably with rational assumptions about cause and effect sequences (Galliers & Swan 1999), it fails to acknowledge that commitment exists in varying strengths. The composition and strength of one’s commitment is, however, subject to changes. Thus, it appears to be a dynamic concept, and not a static one (Coopey & Hartley 1991). Furthermore, rather than being of dichotomous nature, commitment is a continuous variable (Kiesler 1971), i.e. people are referred to as being more or less committed, thus not either committed or not. Therefore, rather than being a rational, causal process, a commitment development process is a series of self-reinforcing cycles of attitudes and behaviors evolving over time (Mowday et al. 1982).

4.2.2 Controllability of the commitment process

The second faulty assumption behind the models introduced is the idea that commitment development is a phenomenon which can be directed or controlled. Commitment research, however, has established that commitment levels also cannot be manipulated directly (Meyer & Allen 1997). Even so, SPI guidelines often (e.g., the IDEAL model

4 Here, the arguments are polarized by necessity to extreme to stress the argument.

Page 53: The role of commitment in software process improvement - Oulu

51

McFeeley 1996) require sound “management commitment” for implementing an SPI initiative or program. In other words, the SPI manager has to go out there and get commitment from, among others, the business management. What is, after all, needed for the SPI initiative is often not so much commitment as a state of psychological attachment from the managers, as adequate resources for launching the initiative and an assurance that those resources will not be withdrawn at any sign of trouble (III, also in Abrahamsson 2000a).

Is not likely that an attempt of trying to make someone committed to any entity will succeed before this person has had any experiences with the entity. The management in the SPI example may provide resources due to pure trust or hunch, thus for reasons not directly connected with the commitment phenomenon itself. It is more likely that when trying to force someone to get committed produces, at best, compliance - not commitment (Senge 1990). This compliance exists as long as the surveillance or control system is in place.

4.2.3 The notion of a singular commitment construct

The third assumption identified is the notion of a singular commitment construct. The literature on commitment strongly suggests that what we are dealing with is a multidimensional construct (Caldwell et al. 1990, Lawler 1992, Jaros et al. 1993, Meyer & Allen 1997, Coleman et al. 1999, Suliman & Iles 1999, Clugston et al. 2000). The agreement among commitment theorists on the dimensions that reflect commitment is, however, not as widespread. The failure to acknowledge different drivers and differing forms of commitment tends to invite oversimplification and misuse of the concept, as is the case with some of the present SPI-specific literature. Commitment is not a way of life as Humphrey (1989) claimed, or should we really throw away project management and bring in commitment management instead, as called for by Keen (1998).

4.2.4 Commitment as an all-positive phenomenon

All the models studied indicate that commitment is viewed as something that should always be looked for. Conner and Patterson (1982) claim that commitment "is the cement that provides the critical adhesion between people and change goals." Later in the article it is reminded that "commitment building is time consuming and expensive". Both arguments may be partly true, but, by definition, the desire of making employees or managers committed to something is a paradox, since commitment is known to have negative aspects as well. Mowday (1998) states that an all-positive view on commitment did dominate the early research on organizational commitment. To him, this belief – i.e. all commitment leads to positive outcomes – is naïve in retrospect. SPI practitioners call for commitment-oriented culture (Hadden 1999) without acknowledging the disadvantages, such as resistance to change and irrational perseverance in behavior, which both have been well documented in the literature (Pfeffer 1997). Randall (1987) has speculated that high levels of commitment might hamper individual growth, limit the

Page 54: The role of commitment in software process improvement - Oulu

52

opportunities for mobility, and lead to stress in family relationships, among other things. Jones (1986) has found that commitment has a negative correlation with the orientation toward innovativeness. Thus it may be concluded that high levels of commitment tend to lead to low levels of innovativeness. However, it has been established by later research that while the correlation does exists, it is relatively weak (Meyer & Allen 1997).

4.2.5 Shared development of commitment

Commitment models in organizational behavior studies are focused on the micro level, i.e. on the individual level. The commitment models in the IS research focus on macro levels (i.e., those of the project, and the organization). These different levels of actors can develop a commitment toward specific targets. Commitment targets, then, are likely to differ between different actors. For example, individuals may be committed to their career, while this cannot be the case with an organization.

Although different layers, i.e. micro and macro levels, are connected, the different forms of commitment at various levels are likely to advance at differing speeds. Consider, e.g., the organizational change approach proposed by (Beer et al. 1990). In that case, commitment to a new solution begins from the periphery and gradually works its way to the other parts of the organization. Therefore, while commitment can be a shared state of attachment by all the levels of an organization, its development speed and the resulting strength are very likely to differ from level to level.

4.3 Model of commitment nets

Studies addressing the development of commitment in SPI are scarce. So far, a typology of commitment has been developed (Chapter 3) and some dynamic models explaining how commitment develops have been reviewed (Section 4.1 ) and their assumptions explicated (Section 4.2 ). The analysis of commitment development at this stage maintains that

− commitment development does not necessarily following any predefined stages,

− commitment development is difficult to control,

− commitment development takes different forms,

− the phenomenon has negative implications as well, and

− the pace of commitment development may vary at different levels.

These theses serve as requirements for the new model to be worked out. The challenge for a research effort attempting to understand commitment processes in SPI lies in the fact that such processes do not necessarily exist or they just cannot be found. While the multidimensionality of the commitment form and foci have been acknowledged, any research effort attempting to discover how commitment to a specific target comes about

Page 55: The role of commitment in software process improvement - Oulu

53

should acknowledge the existence of other possible commitment targets. A model that neglects the existence of other commitments is biased a priori.

4.3.1 (Re)discovery of commitment nets

Inspired by the writings of Winograd, Flores and Spinosa (Winograd & Flores 1987, Flores & Spinosa 1998) the concept of commitment nets emerged. Commitment net is a net of commitment characteristics and their relationships, which together describe the process of commitment. The characteristics, relationships and actors acting them out are identified and described in this section on the basis of the analysis.

Flores draws on the works by Heidegger (1962 (1937)), Kierkegaard (1985) and Hegel (1979). Rather than giving any detailed description of the philosophical underpinnings of their writings, the intent here is to further elaborate the interpretation of Flores and the others in relation to understanding commitment and its operation in organizations. Winograd and Flores (1987) use the ideas of speech act theorists (Austin 1962, Searle 1979) to demonstrate that “human beings do not normally act in the world by simply transferring, disassembling, and reassembling basic thing”. Flores calls this “The Cartesian misunderstanding of language and communication”. Winograd and Flores argue that this misunderstanding has damaged our productive capacities, compromised our ability to recognize ourselves inside a changing community, and caused a failure to cultivate our political capacities.

“Because we tend to look at components of things and not commitments and how they are structured with each other, we increasingly find that our domestic and commercial lives are transforming themselves beyond our control.” (Flores & Spinosa 1998, p. 355)

Winograd and Flores have “opened the discipline of tracking, mapping, and combining commitments based on the constituting power of human speech”. In their writings on computers and cognition (Winograd & Flores 1987), they have stated that there is a general structure for forming commitments for actions to satisfy concerns. Concern, to them, is an ongoing generalization of a need. Through the focus on concerns and commitments, new domains of assessment emerge. One of these domains is “the identification of the new institutions that are arising alongside old ones”. This is explained as follows:

“Mapping social institutions in terms of their concern and commitment structure tells us what is genuinely new and what is a new way to accomplish old goals” (Flores & Spinosa 1998, p. 357)

The term social institution can be interpreted to refer to the way software is produced in a software-intensive organization. A project can thus be considered another form of social institution, with its specific concerns and commitments. If this is accepted, SPI can be seen as a method for changing or altering this institution. If we are to evaluate whether a change has occurred, we have to look at the changes in concerns and commitments, i.e., the changes taking place in the respective actors’ commitment nets.

Page 56: The role of commitment in software process improvement - Oulu

54

“[…] once we become familiar with the way commitments drive action, we no longer believe that we have to understand in advance all the component parts of whatever social action we seek. Rather, we see that we must identify concerns and begin forming commitments to address them. The basic organizing skill is forming and managing a commitment to deal with a concern. On the basis of one commitment, many others can be grown” (Flores & Spinosa 1998, p. 357)

The key concepts constituting the basis of the commitment net (Fig. 7) are actors, drivers, concerns, actions and outcomes. These concepts are introduced and defined in the following sections.

Drivers Outcomes

Concerns

Actions Intended/Unintended

Actors

OPERATIONAL:Groups

(internal, mixed,external)

PERSONAL:Individual

(internal, external)

STRATEGIC:Organization

(focal, external)

ProduceInfluence

Influence

InfluenceInfluence

Areconnected

(A)

(B)

(C)

(D)(E)

ProjectPsychological

SocialStructural Are characterized by the

static elements ofcommitment

FormFocusStrengthTerms

Fig. 7. Commitment Nets Model

4.3.2 Actors in commitment nets model

SPI efforts are rarely designed for a single software engineer, but most often for a group of engineers or for an entire software development organization. Organizations are networks (e.g., Seppänen 2000) where the actors and their relationships constitute the elements of the network. There are three levels of actors: individual, group and organization (Hage 1980, Curtis et al. 1988). For the purposes of analyzing the development of commitment in SPI it is beneficial to distinguish explicitly between these different organizational levels for two reasons. First, each organizational level actor participates in SPI for different purposes and subsequently is affected by the SPI differently. Based on the literature reviewed in chapter 3 all the levels are capable of developing a sense of commitment toward the SPI. Second, the distinction between the different organizational level actors allows the layered analysis of the changing commitment forms and drivers in the commitment process, which in turn provides a

Page 57: The role of commitment in software process improvement - Oulu

55

richer view in to the dynamic complexities of the commitment phenomenon in the cases studied.

These actors form three levels of commitment nets, respectively: strategic, operational and personal. SPI attempts to change these commitment nets at each level, so as to increase the profitability of the organization, to produce higher quality software in software projects within given time and resource constraints, and to make individual software engineers understand the benefits of the process approach, to mention some examples.

The management of the focal organization can be regarded as strategic level actors. Their function in SPI is to sponsor the project by providing the resources for performing the improvement actions. They also provide management guidance, monitor progress and promote SPI goals throughout the organization. Operational actors are represented by the SPI team and the software projects. The SPI team manages and implements planned process improvement actions. Software projects form the target of change. This means that it is these projects that ultimately adopt new behavior patterns. Personal level actors in an SPI can also be key stakeholders involved in the improvement project. SPI project managers or software project managers may also play the role of such key stakeholders. Thus, they are the key people from either of the actor groups. Their function is to facilitate the SPI progress. The actors in an SPI context are mapped with the proposed actor groups in Table 7.

Table 7. Actors in SPI context.

Commitment Net Level

Actor Role in SPI Function in SPI

Strategic

Focal or external

organization

Management Authorization of budgets and resources;

provide management guidance and strategies;

monitor progress; resolve organizational issues;

promote SPI goals

Internal, external

or mixed group

SPI team Manage and implement process improvement

activities

Operational

Internal group Object of change:

Software project

Participate in the change; adopt new behavior

patterns and tools

Personal Internal or external

individual

Key stakeholders Key people from either of the actor groups.

Facilitate SPI progress.

Different organizations can also be networked in a single SPI project. External organizations may assist a software development organization in their SPI efforts as mentors. Maturity assessments are also often done by external organizations. For this reason, each operative level also includes an external actor. “Mixed” actor refers to a joint collaboration between an external actor, such as a group of university researchers, and an internal actor, which may be an SPI group within the organization.

Page 58: The role of commitment in software process improvement - Oulu

56

4.3.3 Commitment drivers

Research in other disciplines (e.g., Sabherwal & Elam 1995, Meyer & Allen 1997) has shown that the development of commitment, represented by arrow A in the model, is influenced by various drivers. Research has also evidenced that the resulting commitment works to strengthen or weaken the drivers (e.g., Mowday et al. 1982), arrow B in the model. A potential driver is anything affecting the commitment of the actors. An exhaustive literature review (see Chapter 3 for details) on organizational commitment and commitment to information systems development (ISD) has revealed over 70 possible drivers for commitment development. However, not all of them are expected to behave similarly in the context of SPI. For example, (Whitener & Walz 1993) have found that there is a positive correlation between retirement money and the continuance form of commitment. This, however, bears little relevance to commitment research in the field of SPI. Certain drivers, therefore, are more relevant than others.

After reviewing the possible driver categories identified in related disciplines, it is proposed that the set of categories identified in the IS commitment research is likely to serve the needs of SPI relatively well. This is due to the fact SPI-related activities are most often performed as projects with their own budget, timescale, dedicated resources and goals (Zahran 1998). The four driver categories involved are project, social, psychological and structural. In addition, the drivers identified in organizational behavioral literature are mapped to the proposed four driver categories (Table 8).

Page 59: The role of commitment in software process improvement - Oulu

57

Table 8. Drivers for SPI projects.

Indicators Commitment

Driver Description Organizational

Behavior Information

Systems

Project Reflects the objective features of an

SPI project, such as costs and

benefits. Project drivers indicate

reasons for an SPI to exist.

Investments:

transferability of

skills.

Alternatives:

existence of other

solutions.

Long-term payoff

structure, closing

costs.

Psychological Psychological drivers involve key

individuals in the project, reflecting

properties such as the need for

achievement, past historical success,

etc.

Work experiences:

job scope, employee

role, personal

fulfillment,

importance and

competence.

Personal

responsibility with the

outcome, emotional

attachment, prior

historical success.

Social Social drivers originate from a group

rather than an individual. These

drivers are, e.g. power and politics, or

public identification with the SPI

project.

Investments that are

hard to reciprocate

Public identification

with the project,

public decision

context, power and

politics

Structural Structural drivers represent the

contextual conditions surrounding the

project: the environment for SPI

activities.

Organizational

characteristics:

fairness of policy,

communication

Political support for

the project, strategic

nature.

4.3.4 Concern and action

The concepts of concern and action together constitute ‘commitment’ in a processual perspective. A concern without corresponding action cannot be regarded as commitment. Consider the following example.

A person argues that he is committed to preserving the nature. One would then assume that this person acts in a manner that would indicate the existence of such a commitment. He would recycle waste, attend environmental group meetings, or give out pamphlets in the street. However, if he does not perform any actions matching his concern with nature preservation, one would conclude that such a commitment does not truly exist.

Action, in itself, does not bring about commitment, either. However, action should be interpreted as a sign of potential commitment. If the person in the example above would indeed stand in the street on a rainy day distributing pamphlets about nature preservation (i.e., commitment focus), one would conclude that this person is committed to the cause. The cause, however, is not clear to the observer. The observer’s perception of the situation (rainy day, contents of the pamphlet, etc.) and action (act of distribution) –

Page 60: The role of commitment in software process improvement - Oulu

58

commitment terms set by the observer – contributes to his understanding of a possible commitment target. One may, indeed, interpret nature preservation as the primary cause. The strength of the person’s commitment – to some degree – can be determined by observing the number of occurrences of the identified behavior pattern. Still, the observer does not know why this person is committed to the specific cause. Here, we are able to benefit from the archetypes (or forms) of commitment. It is maintained that the person is committed to the cause in all the forms of commitment as proposed previously. However, the cause of a perceived commitment is not necessarily accurate, since it might be, for instance, that the person in the example is just performing the act of distributing pamphlets due to the fact that he needs some extra money to support his family. Thus, the question arises what the concern driving the action is, which, in turn, will reveal the true commitment target to the observer. The behavioral school of commitment research emphasizes the role of action as commitment target.

“[…] commitment targets should be actions rather than objects, as it is virtually impossible to describe commitment in any terms other than one’s inclination to act in a given way towards a particular commitment target” (Oliver 1990, p. 30)

To some degree, the argumentation of the behavioral school appears acceptable. However, it is proposed that action, in itself, can be regarded as no more than a potential commitment target. If it were to be considered commitment, it should also hold the state of attachment (i.e. concern). A recent study on practitioner’s view on commitment by Shephard and Mathew (2000) explicates that 97,9% per cent of the respondents agree that attitude differentiates committed employees from non-committed ones, general behavior was stated by 72,3% of the respondents as an indication of commitment. Thus, it is only by discovering concerns and related actions in a software organization at the different operational levels that enables us to identify potential commitment targets. This knowledge puts us in a better position to analyze the arrival of new commitment – i.e. commitment to SPI in this study. A lot of anecdotal evidence shows that such commitment does not necessarily come about.

4.3.5 Outcomes

Only action produces outcome (arrow C in the model). Outcome bears relevance to this research since it has been shown that it is on the basis of outcomes that future actions are planned (Newman & Sabherwal 1996). If the outcome of an SPI action is dissatisfactory for the sponsor, resources may be withdrawn and the project can be canceled, for example. Therefore, the outcome has an influence on its operating environment – i.e., on concerns and actions and drivers, arrows E, D in the model.

In a study on implementing the Lotus Notes groupware tool in an organization, Orlikowski (1992, 1993) distinguishes (among others) between intended and unintended outcome produced by this groupware tool for the organization. Similarly, SPI activities lead to intended and unintended outcome (Kautz 1999), which both in turn affect the drivers, concerns and future actions. In SPI, unintended outcome may take the form of dissatisfaction with an introduced tool, which may subsequently lead to difficulties in the

Page 61: The role of commitment in software process improvement - Oulu

59

co-operation between process and project departments. Unintended outcome may also be positive. For example, improved work morale or a range of new SPI activities (that were initially not intended) may emerge from an SPI effort. Intended outcome reflects the fact that the SPI project has achieved the goals set for it. In the empirical part of the thesis summary, the outcome is regarded as issues, actions, artifacts, etc., produced by the SPI project being studied.

4.3.6 Commitment process

This last section preceding commitment nets model identifies the main analytical elements used for explicating the commitment processes in SPI, i.e. SPI concern, change in the commitment drivers and in the form of commitment, SPI outcome.

Concern, as was argued in 4.3.4, is an ongoing generalization of needs. It, therefore, guides actors’ attention to certain targets. SPI projects are initiated for some specific reasons. These reasons can be interpreted to be the concerns that have been found to cause problems to the software development organization. Therefore, an SPI initiative must embody a concern that directs the actions that are pursued in an SPI project. If only actions are pursued without acknowledging the driving concern, it can be maintained that the SPI project will face fundamental problems.

“The quality and continuous improvement movements, for instance, increase the number of effective options for action without making the nature of action any clearer to us.” (Flores & Spinosa 1998, p. 354)

SPI initiatives serve to meet the needs of some specific concern. As an example such a purpose can, for instance, involve the target of increasing the effectiveness of an inspection process. This can be achieved by applying perspective-based inspection techniques. Thus, the content of SPI concern is the effectiveness of the inspection activity, and the means used for achieving the goal is a new inspection method. This concern must be transferred to the operational level of the commitment net, i.e. to the software project employing the inspection process in this example. In addition, the concern has to be transferred to the strategic commitment net in order to ensure the availability of financial and human resources for executing the SPI project. The means by which strategic and operational commitment nets are changed are the core elements of SPI itself, which were introduced in Chapter 2. These SPI elements constitute the infrastructure and the means needed for performing SPI activities through which the different levels of commitment nets change.

SPI commitment processes are concerned with studying how SPI concerns and subsequent actions come about in an actor’s commitment net. This is achieved when the changes in commitment drivers and forms are identified in each SPI phase (initiation, operation, closure) along with the resulting SPI outcome.

Page 62: The role of commitment in software process improvement - Oulu

60

4.4 Summary

The purpose of this chapter is to build a model of commitment that can be used for analyzing the four SPI initiatives in the empirical part of the thesis (Chapter 6). Existing commitment models were analyzed in terms of their assumption of the commitment concept and its development. The analysis was divided into scientific and practical models of commitment. As a result of this analysis, five assumptions were made: 1) the assumption of causality in the commitment process, 2) the controllability of this process, 3) the notion of a singular commitment construct, 4) the idea that commitment is an all-positive phenomenon, and 5) shared development of commitment. Finally, based on the analysis of commitment models and the literature review in Chapter 3, a model of commitment nets was developed and its parts introduced. This model together with the typology of commitment (Chapter 3) and the typology of SPI (Chapter 2) constitute the framework through which SPI projects are analyzed.

Page 63: The role of commitment in software process improvement - Oulu

5 Research Design

This chapter describes how the research design for the study is laid out. To start with, the process is described through which the six publications were constructed, including a consideration of the motives that directed the interest of the author into studying the role of commitment in SPI. This is followed by a description of the research approaches and methods used in the study. The research settings and the rationale for the case selections are also provided. Finally, the data collection and analysis methods are described.

5.1 Research evolution

This research was originated by the need to gain a better understanding of commitment in SPI. The research was focused on software process improvement, because, in view of the author, people issues had been somewhat overlooked at that time and scientific studies addressing these issues were scarce. The development of the research process can be divided into the following four periods: metrics focus, conceptualization, empirical study, and abstraction (Fig. 8). This was, however, not the original intention when the research was initiated. The process evolved as the author’s understanding of related issues became richer and more contextualized.

During each period, publications were actively published to ensure that the research was following the right direction, which would be reflected in how it would attract attention, and how it would be accepted by the SPI community. The purpose of this section is to provide the reader with an insight into how the thinking of the author has evolved during the period of this study. This enables the reader to better evaluate the findings and conclusions produced by this research effort.

Page 64: The role of commitment in software process improvement - Oulu

62

1998 1999 2000 2001 2002

Metrics focus

Conceptualization

Empirical study

Abstraction

Paper I Paper II Paper III Paper IV Paper V Paper VIMaster’s thesis

Fig. 8. Research evolution phases.

5.1.1 Metrics focus

Commitment in software process improvement is an abstract phenomenon, which is difficult to grasp. In retrospect, naïve logic dominated the early research. This “logic” went along the following lines:

Many researchers argue that commitment to SPI is very important for securing the continuity and success of SPI activities. Therefore, if one knew how committed staff and managers were to SPI, one would actually be able to forecast the resulting level of achievement, at least in the SPI project initiation phase. Thus, what was needed was a measurement instrument that could be used for measuring the level of commitment to SPI.

Theorizing from goal commitment literature (Locke et al. 1988, Hollenbeck et al. 1989, Klein & Mulvey 1995, DeShon & Landis 1997), an attitudinal model of commitment (see I for details) was developed. This work was based on a view according to which the chances for success in software process improvement can be improved by creating a better understanding of the process users’ perception of the upcoming SPI initiative. This can be achieved by measuring software developers’ level of commitment toward SPI goals. Although the measurements proved to be of little use, the first step wastaken in clarifying the concept of commitment. This was to prove very helpful for theresearch in general. A distinction between the attitudinal and behavioral schools ofcommitment was made and the terms used for describing the concept of commitment wasto remain in use in all the subsequent publications.

Parallel to the development of the attitudinal model of commitment, another perspective was pursued, i.e. the behavioral perspective, according to which changes in the attitude were assumed to be the consequences of changes in the behavior, rather than the reverse (cf. Taylor 1995). Thus, to support this line of reasoning, another model was proposed – the behavioral model of commitment (II). The essence for the behavioral model was drawn from studies of Porras and Hoffer (1986). The authors have studied changes in behavior witnessed during successful organizational changes. It was, therefore, hypothesized that similar changes should also occur in SPI efforts. The hypotheses stated that those behavioral patterns would be relevant also in SPI and that the very demonstration of them would have a positive impact on SPI. Both models were explored qualitatively through semi-structured interviews in terms of interest, possible

Page 65: The role of commitment in software process improvement - Oulu

63

use and usefulness. The response was very positive and it triggered further experimentation exploring the validity of the proposed hypotheses. However, several problems were encountered during this phase of the study.

The behavioral commitment model turned out to be very difficult to put into use in practice. After this was reported in (Abrahamsson 1999a) the questionnaire was extensively revised on the basis of the results gathered. The attitudinal model of commitment questionnaire was also revised and tested. However, the 12 SPI efforts applying these models were all very different, and all of them were quite small-scale initiatives with very few participating software developers. Most of these endeavors lasted only a few days and the author – as the principal researcher – had a limited contact with the practitioners, restricted only to handing questionnaires over to them, to which they would then reply. Thus, the context of SPI, the environment in which the actions were performed, among other important contextual information, was not available. This made it difficult, e.g., to reliably compare cases with each other.

The commitment of management has gained a lot of attention in the SPI community throughout the past decade. The construct was operationalized by the author using commonly accepted items in the questionnaire. The participants in the 12 SPI cases involved in the questionnaire contact were asked to evaluate the extent to which the management demonstrated commitment to their SPI initiatives. They also evaluated the level of achievement using the dimensions drawn from the multidimensional success scale of Shenhar and the others (1999). While no direct connection could be drawn between management commitment and level of achievement, it was suggested that the concept of champion would possibly provide with a better success indicator (III, also in Abrahamsson 2000a). This notion was not, however, satisfactory enough with the approach that was followed. The author had been developing measurement scales, while the sample sizes proved not adequate for a reliable statistical treatment. Therefore, there was a need to learn more about the process of commitment in the actual case in which the author was involved. The author felt at the time that he had not learned enough about commitment and that he was more concerned with the validity and reliability of the instruments used.

5.1.2 Conceptualization

Subsequently, the notion of what it meant to be committed in the context of SPI started to attract more and more attention in the context of this study. The thought of having already answered to this question during the metrics period soon gave way to a re-evaluation and new, different interpretations of organizational commitment literature. The article on management commitment had just been finished and the work with the case organization for case one, i.e. the usability improvement case, had just been started. The strong support from the management provided an opportunity for studying the processual aspect of this commitment type. Using the insights gained from earlier interviews, observations and field notes from other participating researchers, a model of the managerial commitment process was proposed (Abrahamsson & Jokela 2000).

Page 66: The role of commitment in software process improvement - Oulu

64

At that time the author decided to take an in-depth look at how the SPI field thought that commitment would develop. The results of this review were interesting and generated some attention in the software engineering (SE) research community. The review was published in ICSE 2001 (IV, also in Abrahamsson 2001a). However, the review only included a brief analysis of the implications of these findings for the SPI community, and did not tie the commitment concept and SPI together. Therefore, the concept of commitment was rethought from an SPI-specific perspective and the implications for research and practice were re-analyzed with care. The results of this effort were published in a journal (V, also in Abrahamsson 2001b). For a while, there was a feeling that although the conviction as to how commitment fundamentally developed was still largely absent, it was known how it did not develop. This was clearly the main contribution of this period. In addition, a typology of commitment was successfully developed, which – at the time – could be interpreted as a research framework through which it would be possible to study commitment in SPI.

5.1.3 Empirical study

Researchers often recall gaining entrance to a case organization as a difficult task. This was also true in this case. An SPI specialist saw the author’s presentation about goal commitment at a conference. Having encountered problems in organization wide SPI efforts, the SPI specialist asked the author to give a presentation in their organization about ‘commitment’ in November 1999. After some negotiations, an agreement of a commitment research project was reached in April 2000.

In addition to striving for the research goals agreed upon, the author was trying to solve some of the more general SPI related problems within the organization and to make some educated improvement suggestions. After several interviews with the SPI staff (including a few software developers) a set of early findings not related with the research goals was proposed. These observations included the clarification of the new SPI approach, the need for acquiring hands-on experience in software development (i.e., increasing the SPI personnel credibility as well as expanding their professional skills), publishing practitioners’ reports in research forums, clarifying the decision-making structure and diversifying SPI career opportunities (in order to attract multiple types of personnel). In fact, for a period of several months the author was postponing his personal research interests and concentrating on the organization. Some of the sidetracks pursued included a preparation of a proposal of a virtual organizing model for the SPI department, an analysis of financial means to compare different SPI initiatives, lectures on Personal Software Process (Humphrey 1995) and Team Software Process (Humphrey 2000) methods.

The author thus found himself highly occupied with activities not directly related to the actual research problems. The organization granted access to three (initially four) SPI initiatives (i.e., cases 2-4). Case two was not a single initiative but a collective set of actions taken to solve a particular problem. Case three was aborted due to changes in the organization and case four did not officially start until January 2001. The level of involvement varied from observation (case three) to actual participation (case four). Thus,

Page 67: The role of commitment in software process improvement - Oulu

65

data was finally collected from quite different kinds of SPI initiatives. Nevertheless, this proved to be very useful for theorizing even though the author initially found himself in chaos just trying to survive. This period was thus marked by a clear duality of the research process. On one hand, the study was experiencing a conceptualization period, which lived a life of its own, not related to the daily activities of the case organization. On the other hand, the author was trying to cope with tasks that were directed to him as described above. Research guides often suggest that analysis should go hand-in-hand with the data collection (e.g., Eisenhardt 1989). This idea is fully supported by the findings of this study. In our case, however, it was difficult to perform these tasks simultaneously due to problems with the research framework and because of other duties involved in working for the organization.

5.1.4 Abstraction

After gaining entrance to case organization B, masses of case data were received, which the analysis process was overwhelmed by. This gave rise to some degree of concern, since it is generally a sign of poor research focus (Järvinen 2001). It was soon discovered that what was missing was a research framework through which the cases could be analyzed. The developed commitment typology (Chapter 3) proved to be difficult to use, since although it did provide the conceptual structure, it did not include any dynamic aspect. The dynamic aspect is necessary in the case of software process improvement, in the process of which change plays an important role. During the time the research report was being prepared for the case organization and the author was beginning to write the case narratives, which made it possible to interrelate the interpretations with the practitioners involved in the cases. Parallel to this, a search had been started for theoretical frameworks through which the cases could be interpreted. Using the literature as a source and case data as a test bench, the work of setting up an appropriate framework was begun. Finally, inspired by Flores and Spinosa (Flores & Spinosa 1998), the use of the notion of commitment resulted in the formation of the commitment nets model, which was introduced in Chapter 4. As a result of this process, article VI was constructed, in which the emphasis is on the commitment process considerations.

5.2 Research approach and methods

According to Järvinen’s (2000, 2001) classification of research methods, this research can be categorized as a study stressing reality: Article I tested the theory of goal commitment (Locke & Latham 1990) in a software engineering environment. Article II developed a diagnostic tool for assessing the potential of the SPI environment for nurturing commitment. Article III tested the hypothesis that management commitment could explain the level of achievement in SPI. All these efforts belong to theory-testing approaches. The principal contribution of this study as a whole, however, was achieved using the conceptual-analytical and theory-creating approaches. The former approach was used for detecting the underlying assumptions which commitment developmental models

Page 68: The role of commitment in software process improvement - Oulu

66

are based on (IV, V). The latter approach was used for identifying commitment nets and examining how they operated in software process improvement (VI). Thus, multiple methods and perspectives were employed to achieve an in-depth understanding of the role of commitment in software process improvement (Table 9).

Table 9. Research approaches utilized.

Article Research approach

Objective Research methods

I

Theory-

testing

Test the theory of goal commitment in software

engineering environment.

Case survey (11 cases)

II Theory-

testing

Develop an instrument for analyzing the

fruitfulness of an SPI environment for commitment

development.

Case survey (12 cases)

III Theory-

testing

Test the hypotheses that management commitment

would explain the difference in the level of

achievement in SPI.

Case survey (12 cases)

IV, V Conceptual

-analytical

Develop a typology for commitment, explicate

underlying assumptions in existing commitment

developmental models, develop requirements for

emerging models.

Coherent or hypothetic-

deductive reasoning

VI Theory-

creating

Explicate commitment process through

commitment nets model in case organizations.

Action research – case

study research

Thesis

summary

Theory-

creating

Provide an in-depth exploration of the different

aspects of commitment proposed in the six

publications. Based on this work, analyze the role

of commitment in SPI using the commitment nets

model.

Action research – case

study research, cross-case

analysis

Cunningham (1997) proposes that the case study method can be divided into a three different classes: intensive, comparative and action research. These classes hold at least nine different types of case study research methods. The approach used in the first three publications belongs to comparative case study category, but not in the sense proposed by Eisenhardt (1989). Her approach to comparative case study requires theoretical flexibility, since the main endeavor of Eisenhardt is to build a theoretically flexible model. In this thesis, generally accepted theories were tested in the context of SPI-related commitment. These theories were adopted from commitment-related literature (Järvinen 2000) and the sampling was done on a theoretical basis. Cunningham (1997) regards case survey as one type of comparative case study methods. Cunningham (1997) suggests that the case survey method is analogous to a questionnaire survey in which a large number of cases are studied and tabulated using common categories or factors. The research activities included a) the selection of an appropriate theory or model to be tested, b) the selection of dependent and independent constructs, c) the construction (or adoption, modification) of a multi-item instrument for measuring the phenomenon, d) the collection of measurement data, e) analysis and d) reporting. This has been the approach followed in articles I, II and III.

Page 69: The role of commitment in software process improvement - Oulu

67

According to Järvinen (2000), theory-creating approaches include, e.g., “normal” case study, ethnographic method, grounded theory, phenomenography, contextualism, discourse analysis, longitudinal study, phenomenological study, hermeneutics. However, when entering the field it was viewed by the author that he was using the action research method, which in Järvinen’s categorization can be classified into artifacts-building approaches. However, action research generates a theory that is grounded in action (Susman & Evered 1978). Järvinen (2001) follows Oquist (1978) when arguing that action produces knowledge to guide practice. This is achieved by modifying the reality as part of the research process itself. In “normal” case research, the reality is not modified during the study. The following extract from the project plan delivered to case organization B indicates that the objective was to modify the reality.

“In specific, attention is focused to improve the current practice to better cope with gaining staff's (software developers, project managers) commitment to new work procedures, software tools and innovations.” [Extract of project plan, Case organization B]

However, it was soon discovered that organization B did not have a unified way ofperforming SPI activities. The organization was merely depending upon the individualsinvolved and how they decided to handle the project. Only one case (case four) followeda clearly defined improvement model with specific steps drawn from (Isacsson et al.2001). The modification of a given reality requires the possibility to intervene. This wasnot achieved in all cases to the extent desired. Thus, the research method varied fromaction research to “normal” case study research. Avison and the others (1999) havecriticized researchers who have claimed that they have been using action research as theirprincipal research method.

“If researchers are not explicit in following the tenets of action research when working in real-life situations, their work might be better described as consulting. Alternatively, interviewing and observing people in these situations without the insight associated with intervention is also not action research. It might be described instead as case study research. Such research frequently reports what practitioners say they do. In action research, the emphasis is more on what practitioners do.” (Avison et al. 1999, p. 96)

These tenets of action research are, according to Lau (1999):

− Conceptual foundation as its underpinnings

− Study design to describe the methodological details

− Research process of diagnosis, actions, reflection and general lessons learned

− Role of the researcher and participants

However, as has been pointed out, the research of this study was not purely actionresearch in the sense Avison and the others (1999) called for. Indeed, a great deal of the participation was done through consulting methods. For example, an SPI project manager would ask for the view of the author on a specific subject matter and the author provided it gladly, indicating and further developing fruitful researcher-practitioner collaboration.

Page 70: The role of commitment in software process improvement - Oulu

68

In some cases, this proved to be very useful, as is indicated by the following extract from the final report of case four.

“It was essential that the [SPI] project had a suitable Project Advisor that understood the situation of the [SPI] project. In this case, his understanding of technical aspects and […] [different] culture[s], having an external/objective view of the situation, helping to analyze the problems, and giving good advise helped the [SPI] project to deal with difficult situations and reach its goals.” [An extract from the final report in case 4], (some parts were cut in order to preserve anonymity)

5.3 Research setting and case selection

The case selection in articles I, II and III was done on theoretical basis (as opposed to random sampling) as indicated earlier. The idea was to choose SPI cases that were not yet in operation, but rather in the initiation phase. This enabled testing the hypothesis regarding the impact of goal commitment and management commitment to the outcome of the SPI initiative. Access was granted to 12 SPI cases, the members of which were people working in the software industry, and had all participated in a privately organized project management course. Articles IV and V were of theoretical nature and did not contain any industrial cases.

Article VI and the summary part of the thesis are built upon four cases in two organizations. The first organization (Company A) is an SME (Small to Medium Sized Enterprise) developing electronic ticketing systems for national and international markets. Company A is divided into six different business units: After sales, projects delivery, product development, systems unit, mechanics unit and marketing. The second organization (Company B) is an independent business unit of a large global corporation developing electronic products and systems for industrial customers, having thousands of employees working in several locations around the world. Company B has been organized into a matrix, in which the line organization is responsible for resource management and competence development, and the project organization takes care of product development.

The four cases (see details in Chapter 6) represent different types of SPI domains: User-centered/service process, software development process, project management process and SPI process. The user-centered/service process includes customer support activities. The software development process refers to activities taking place during software development including contracting, requirement analysis, system design, program design, coding and unit testing, integration testing, system testing, acceptance testing along with operation and maintenance. The project management process covers management activities related to software development including project planning, scheduling and risk management. Software quality assurance processes typically involve activities ensuring the quality of project outcomes. SPI is a support process typically including quality assurance activities as well as giving concrete support to software development projects (Sommerville 2001).

Page 71: The role of commitment in software process improvement - Oulu

69

5.4 Data collection

The data collection method used in the case surveys (I, II, III) consisted of different types of questionnaires. Articles IV and V are based on an analysis of the existing literature. Article VI and the summary part of the thesis employ multiple data collection devices so as to ensure the data triangulation (Jick 1979). Here, the principal method used for the data collection was the open-ended interview, which was employed in 34 interview sessions with managers, software developers and process specialists. In addition, a number of semi-structured interviews were carried through. A number of unofficial corridor discussions, participation in social events in company B and a field diary ensured the use of multiple ways and sources for data collection. Table 10 summarizes the data collection methods used in this study as a whole.

Table 10. Data collection methods utilized.

Article Research method

Data collection method Descriptive details

Questionnaires

Involved the use of goal-commitment,

diagnostic behavioral SPI questionnaire

and SPI success measure framework.

I, III, III Case survey

Semi-structured interviews 5 SPI managers interviewed.

IV, V Hypothetic-

deductive

reasoning

Theoretical publications,

thus no empirical data

collected.

Competing theories of commitment

referenced in SPI literature analyzed.

Open-ended interview 34 interviews with 31 people including

managers, software developers and SPI

staff.

Semi-structured interview 8 interviews with managers and SPI staff

Participatory observation SPI meetings and activities: Cases 1, 2, 4

Observation Company internal documents and Case 3

Field diary 62 single-spaced written A4 pages

VI,

Summary

part of the

thesis

Action research

& cross-case

analysis

Email correspondence 187 emails from cases 2, 3, 4

An attempt was also made to engage practitioners as co-researchers, as proposed by Baskerville (1998). This effort was not, however, entirely successful. Based on the observations made, practitioners found it hard to take the time to reflect upon their actions. Access was also granted to the electronic documents of company B, which enabled the investigation of a wide range of issues connected with process development as well as documents related to the cases studied. E-mail correspondence (comprising a total of 187 emails) concerning the cases two, three and four were saved in the case database. All open-ended and semi-structured interviews were recorded and transcribed into plain text using a professional transcribing service. As a result, a total of approx. 1000 pages of transcribed texts were collected from the cases.

Page 72: The role of commitment in software process improvement - Oulu

70

5.5 Data analysis

Different strategies were employed to analyze the data collected in each phase of the research process. This section deals with how the data analysis was performed in the publications and in the summary part of the thesis. Langley’s (1999) strategies for analyzing qualitative process data were used as the main source for this section. While statistical data treatment was used in articles I and III, the emphasis of the publications and the summary is on qualitative data analysis. The readers interested in statistical aspects are referred to the bibliographies of articles I and III for details. Table 11 summarizes the data analysis strategies used.

The principal strategies used were the narrative strategy, the alternate templates, the grounded theory, the synthetic strategy and the cross-case analysis. The narrative strategy was used for the communication between the researcher and the case participants. This was done in order to guarantee the validity and accuracy of the interpretations of SPI events made. The alternate template strategy enabled proposing different interpretations for a single event. Thanks to the grounded theory strategy, the author was able to shake off misguiding preconceptions and to bring out the commitment elements in the cases under systematic comparison. The synthetic strategy proved useful in considering the entire qualitative database for determining how and why the process characteristics identified led to specific types of commitment. Finally, the cross-case analysis enabled the comparison of different cases against predefined categories (i.e. commitment process drivers and the assumptions identified in commitment model analysis).

Page 73: The role of commitment in software process improvement - Oulu

71

Table 11. Strategies for sensemaking used in this study.

Strategy Description Article # Extent to which utilized

Narrative Involves construction of a detailed story

from raw data.

VI, TS5 Used as a means of

communicating interpretations

with practitioners.

Alternate

templates

The researcher proposes several alternative

interpretations of specific events. The

extent to which each theoretical template

contributes to a satisfactory explanation is

assessed.

I, II, III Different theoretical

alternatives (i.e., attitudinal and

behavioral commitment

models) are proposed and

empirically explored.

Grounded

theory

Includes a systematic comparison of small

units of data, and a gradual construction of

a system for describing the phenomena

observed.

VI, TS The data analysis is grounded

theory oriented. The incidents

under systematic comparison

are the commitments made

during the SPI project.

Visual mapping Construction of graphical presentation from

raw data as an intermediate step to a more

abstract conceptualization.

VI, TS Several attempts to visually

present the cases studied were

made with poor results.

Graphical presentations helped

in gaining a broader view on

organizational events as well as

on the different operational

levels.

Synthetic The process itself is considered as a unit of

analysis. Global measures are constructed

and used for comparing different processes

and identifying regularities that relate

holistic process characteristics to other

variables such as outcome or context.

(I, II, III)

VI, TS

The entire qualitative database

is considered to show how and

why commitment process

drivers lead to different types of

commitment.

Cross-case

analysis

Cross case analysis enables the comparison

of multiple cases in many divergent ways,

which would not be possible within a single

case analysis. The case comparison can be

made against predefined categories, in

search of similarities and differences, or by

classifying the data according to data

sources.

VI, TS Cases are explored in terms of

the SPI commitment process.

Assumptions regarding the

development of commitment

are also mapped against

empirical findings through the

cross-case analysis.

In the following, a detailed consideration of each sensemaking strategy shown in Table 11 is provided.

5 TS refers to the summary part of the thesis

Page 74: The role of commitment in software process improvement - Oulu

72

5.5.1 Narrative strategy

The narrative strategy has its origins in the works of ethnographers. Langley (1999) argues that the construction of a detailed story from raw data is, at least to some extent, part of all process research. When preparing a chronology for subsequent analysis, the researcher is, essentially, utilizing a narrative strategy. For Eisenhardt (1989), the narrative strategy is part of within-case data analysis, in which the researcher prepares detailed write-ups for each [research] site (or case). Eisenhardt argues that although these write-ups are mere descriptions, they are still central to the generation of insight. She also states that these descriptions help researchers to cope with the enormous volume of data at an early stage of the analysis process. Traditionally, narratives are rich at the level of detail and convey a high degree of authenticity, which is often not economically possible to achieve with larger sample sizes. Therefore, one or few cases are better suited for narrative data analysis. The narrative approach, however, leads to neither simple nor general theory. If the purpose of the researcher is to come up with an explicit theoretical interpretation, relying solely on a narrative analysis is not enough. The danger here, according to Langley (1999), lies in the fact that “one may too easily end up with an idiosyncratic story of marginal interest to those not involved, and rather thin conceptual contribution.”

The narrative strategy was used in the preparation of Article VI and in the summary part of the thesis. It was used it in the sense proposed by Eisenhardt (1989) – as a tool for validation. A relatively short narrative description was prepared for each case studied (see, for example, Fig. 9). These descriptions were sent for review to persons who were involved in the cases, including a foreword for explaining the work being done (Fig. 10). This was done in order to ensure that all comments and corrections would be directed to the author. In most cases, only few comments were received from the practitioners involved. A typical response would be something like the following.

“Yes, [the narrative] holds pretty well. That is, I do not think anything should be added or removed.” [Case two, SPI project manager, email]

However, in one case (case four), the interpretations was not entirely objective since one of the case narratives was not prepared using triangulation. At that stage there was not enough data available for triangulation. The response for this particular case was prompt and useful as demonstrated by the following email extract (Fig. 11).

Page 75: The role of commitment in software process improvement - Oulu

73

Fig. 9. An extract from a case narrative (case two).

Fig. 10. A foreword email for case narratives (case four).

Page 76: The role of commitment in software process improvement - Oulu

74

Fig. 11. An example of practitioners’ critique concerning a case narrative (case four).

5.5.2 Alternate templates strategy

The third strategy, introduced by Langley (1999), is the alternate templates strategy. The objective of this approach is to propose several alternative interpretations for a single event or a series of events. The extent to which the proposed interpretations contribute to a satisfactory explanation is then assessed by the researcher. This strategy can be considered to reflect a hypothetic deductive standpoint to some degree, since the theories are drawn from the outside of the data set and then “formally” tested. According to Langley (1999), this strategy provides a powerful means of gaining insight even from a single rich case, due the fact that the comparison is attained by a simultaneous use of different theoretical interpretations, i.e. to provide differing explanations for the same phenomenon. An example of such an approach is Kautz et al.’s (2001) analysis of SPI work from four different theoretical perspectives. They conclude that the combination of four perspectives provided the researcher’s a better understanding regarding the nature of their SPI work, which would not have been possible if only one perspective would have been used. Thus, although each of theoretical perspective would be inaccurate on their own, overall accuracy can be provided by a certain combination of these different theoretical perspectives. Langley (1999) rightfully acknowledges that the use of this strategy brings up the problem of validity regarding the combining of different theoretical perspectives. According to Langley, any theory attempting to integrate different perspectives will become unwieldy and aesthetically unsatisfactory. Van de Ven and Poole (1995, pp. 510-511), however, state:

Page 77: The role of commitment in software process improvement - Oulu

75

“It is the interplay6 between different perspectives that helps one gain a more comprehensive understanding of organizational life, because any one theoretical perspective invariably offers only a partial account of a complex phenomenon.”

Kaplan (1964) warns about borrowing concepts from different theories without understanding the theoretical roots of these concepts, as this can produce confounded explanations. The present author agrees with Kaplan’s (and Langley’s) ideas. Thus, the alternate templates strategy can be considered to preserve the inherent richness of the study object, since it allows qualitative nuances to be represented through alternative explanations. The theoretical lenses employed should, however, be kept separate so as to preserve theoretical clarity.

Articles I and II represent two different approaches to commitment analysis. Article I, basically, uses the attitudinal approach to commitment research, whereas article II represents the behavioral school of commitment. Thus, two alternate explanations have been provided for the same phenomenon. Article III supplements the collected data (i.e. the 12 SPI cases) with a new, different viewpoint provided by management commitment, and proposes yet another explanation for the events having taken place.

5.5.3 Grounded theory strategy

Langley (1999) claims that the grounded theory has become a synonym for any kind of inductive theorizing. Originally, Glaser and Strauss (1967) introduced the grounded theory as a distinct qualitative research method. Since then, it has been broadly applied in various fields. In a more recent work, Strauss and Corbin (1990) describe the grounded theory approach as a series of highly structured steps. Small units of data are systematically compared and gradually build into a system of categories describing the phenomena observed. The researcher, then, seeks for appropriate data for verifying the properties of the emerging category systems. Grounded closely on original data, the core categories should emerge as a result of the analysis.

Articles I, II, III are written with the focus on the individual software engineer. The reason for this is that for quite some time the present author was trapped by the idea that evolving commitment in SPI was likely to be represented at the micro level by certain stages that would emerge from the data. Eventually, the analysis of commitment developmental models (IV, V) has undermined such thinking.

It was due to the data driven realization that SPI was seldom performed in isolation and that macro level events proved to intervene almost daily with SPI activities that the research focus was redirected. The question that had to be urgently addressed was concerned with the unit of analysis in SPI commitment studies.

6 Even though Van de Ven and Poole discuss the interplay of different perspectives, they do not suggest that these perspectives should be merged. Instead, they call for some integration – “working out relationships” in order to gain a greater explanatory power than with the initial perspectives separately.

Page 78: The role of commitment in software process improvement - Oulu

76

“One fundamental problem for researchers to solve is to explore deeper whether to focus on the individual level commitment process, to concentrate rather on exploring the organizational commitment process or to advance knowledge in both. Lately, the individual’s role played a minor part in organizational studies (Nord & Fox 1999). The emphasis has been moved to the context where the individual operates, on its attributes and effects. While the exploration on the commitment concept in this paper has been mainly on the individual level, a more context dependent approach might also be useful. However, one may argue that it is ultimately the individual who makes the decision whether one changes his/her behavior, which is the ultimate goal of any SPI activity. Still, individuals differ on every psychological dimension that has ever been investigated (Deci & Ryan 1980), how then would a generic model of the individual level commitment process - if such a model could be developed at all - benefit the SPI community?” (VI, also in Abrahamsson 2001b, p. 87)

Thus, the fact that the researcher is forced to go back and forth between the original data and theorization, as suggested by grounded theory principles, enables him to shake off misguiding preconceptions. However, for instance, a strategic change in a large organization – a macro level study – does not fit all that well in the textbook approach of grounded theory, since the approach requires rather detailed data. Microscopic focus on a strategic change is in danger of losing the broad pattern of the forest for the descriptive detail of the trees (Langley 1999). As elaborated above, the trees were described at the cost of other important factors affecting SPI and thus commitment development. In order to avoid losing the big picture, the grounded theory approach should be supplemented by other complementing analysis methods, especially when multiple units of analyses are involved, as it is the case with article VI and the summary part of this thesis. Following these lines, the work was started to craft a model that would make it possible to include both micro and macro levels in the study, involving both case data and literature as source material (Fig. 12).

Fig. 12. A draft model of commitment nets.

This model was then operationalized (Chapter 4) and used as an analysis tool to explore the role of commitment in SPI (VI; Chapters 6, 7). However, the construction of a

Page 79: The role of commitment in software process improvement - Oulu

77

commitment nets model or earlier commitment models would not have been possible without close interaction with the data at hand. This can be considered to emphasize the validity of the grounded theory approach in the sensemaking process.

5.5.4 Visual Mapping Strategy

The fourth approach involved, introduced by Langley (1999), is the visual mapping strategy. Miles and Huberman (1994) suggest that graphical presentations are useful in many regards. Firstly, this strategy allows large quantities of information to be presented in little space. In addition, a large number of dimensions can be simultaneously displayed, allowing the researcher to develop and to verify theoretical innovations. Such dimensions are, e.g., parallel processes, passage of time and different actors.

An attempt was made in this study to make sense of the sequence of events (VI, summary part of the thesis) by studying them in a graphical form. It took as long as two months in calendar time to produce a graphical presentation of a single case, in which it was possible to embed different organizational levels, actors, commitments made (i.e. those within the SPI project and external ones that were relevant to the specific SPI project studied), driving forces, elapsed time and some outcomes. Attempts were also made to construct similar presentations of the other cases, but the outcome of these efforts proved to be unsatisfactory considering the analytical usefulness of the resulting graphical diagrams. Conceptualization in graphical form, therefore, seems most useful in gaining an overall view on a specific sequence of events. However, as is warned by Langley (1999), the graphical presentation has a tendency to become overly simplified or too complex. Furthermore, the omission or inclusion of individual elements in the graphical presentation should not be determined by the level of difficulty in presenting them in graphical form. In this study, it was decided not to exercise the graphical presentation method to any further extent. Graphical presentation turned out to provide a good starting point for this study, and it also proved useful as a communication tool with the other researchers and practitioners involved.

5.5.5 Synthetic strategy

The synthetic data analysis strategy, according to Langley (1999), provides an answer to the proposed criticism toward process theorizing. It has been argued that developed theories often fail to possess any strong predictive power. In essence, the result of the synthetic strategy is a variance theory oriented process theory. Langley (1999) suggests that this strategy should be applied when the whole process is taken as a unit of analysis. Global measures are constructed for describing the process from detailed event data. These measures are then used for comparing different processes and for identifying regularities and enable relating the holistic process characteristics to other variables such as outcomes and/or contexts.

In articles I and II, two models were constructed – the attitudinal and behavioral based commitment models – and it was hypothesized that the level of commitment

Page 80: The role of commitment in software process improvement - Oulu

78

demonstrated by the process users (i.e., objects of change) would indicate the level of achievement in SPI (i.e., outcome). The level of commitment to SPI was thus seen as a process characteristic affecting the level of success in SPI. In article III, the global process characteristic was represented by the level of management commitment.

In article VI and in the summary part of the thesis, the synthetic strategy was applied more thoroughly. The object of analysis is constituted by the whole of the commitment process. Dependent variable refers to the type of commitment and process characteristics are the drivers of commitment development (project, psychological, social and structural). The results of this analysis are presented in connection with the case analysis (Chapter 6) and for the operational level in the cross-case analysis (Chapter 7). However, the purpose of the use of synthetic strategy in the analysis is not to construct a predictive theory but to gain a better understanding of the role of commitment in SPI.

5.5.6 Cross-case analysis

Eisenhardt (1989) argues that the cross-case analysis should preferably be used for searching patterns. To her, the overall idea is to force the researcher to go beyond the initial impressions using structured and diverse lenses on the data. As a result, the likelihood of achieving an accurate and reliable theory is improved. Three tactics are suggested: 1) select categories and look for within-group similarities coupled with intergroup differences, 2) select pairs of cases and list the similarities and differences between each pair, and 3) divide the data by data source to exploit “unique insights possible from different types of data collection” (Eisenhardt 1989, pp. 540-541).

Cross-case analysis techniques have been employed in Article VI and in Chapter 7, using the first and second tactics proposed by Eisenhardt (Eisenhardt 1989). In specific, the cases are compared against the SPI dimensions defined in Chapter 2, so as to explore if any patterns can be identified concerning the process of commitment. Cross-case analysis techniques were also employed in the analysis of the commitment assumptions identified from the commitment model analysis in Chapter 4. The method proved useful and efficient since it enabled the comparison of different cases from the chosen perspectives, which would not have been possible otherwise. As one result, it was shown how the alteration of commitment nets makes a difference in the outcome of a well-planned SPI initiative.

5.6 Summary

This chapter has described how the research design for the study was laid out. First, the research process was described through which the six publications were constructed and the motives that directed the interest of the present author into studying the role of commitment in SPI. A description of the research approaches and methods used in the study was also described. The research settings and the rationale for the case selections were provided. Finally, the data collection and analysis methods were described.

Page 81: The role of commitment in software process improvement - Oulu

79

In conclusion, the following findings were made. The principal contribution of this study as a whole was achieved using the conceptual-analytical and theory-creating approaches. The dominating research methods were the case survey, the hypothetic-deductive reasoning and the action research. While many sensemaking strategies were employed, the narrative strategy, the grounded theory, the synthetic and the cross-case analysis approaches were found most useful considering the research results achieved.

Page 82: The role of commitment in software process improvement - Oulu

6 The role of commitment in four SPI cases

This chapter focuses on an empirical analysis of the four software process improvement cases. The Analysis is performed using the commitment nets model. This model has been augmented to include the typology of SPI introduced in Chapter 2 (see Table 3). Each case is analyzed separately and presented in two sections, containing a longitudinal7 analysis of commitment nets and empirical conclusions. A brief description of the background is also provided for each case.

The longitudinal analysis of commitment nets presents the improvement initiative in a chronological order, using the commitment net concepts (Fig. 7): actor, driver, concern, action and outcome. The analysis is concerned with the three generic SPI phases - initiation, operation and closure – as defined in Table 3.

The empirical conclusions include an identification of the commitment process and an analysis of the change achieved in actors’ commitment nets. Within each phase, the commitment drivers and the resulting form of commitment are identified. A typology with the signs “+” and “-“ is used for identifying the direction of commitment development. Therefore, “+” indicates that a certain driver increases commitment while “-“ refers to a decrease in commitment. Thus, the intention is not to estimate the strength of the actors’ commitment, but to indicate the direction of development. As a result, the commitment process is explicated by presenting how commitment drivers have changed over the course of the SPI project along with how the form of commitment has developed. Finally, an analysis of the change in actors’ commitment nets is concerned with how successfully the SPI project has contributed to sustaining the changes sought.

7 The use of term “longitudinal” here refers to the way the data was collected, i.e., over three distinct periods (initiation, operation, closure) and how the data will be treated in the analysis procedure, i.e., analysis involves the comparison of data between these periods (Ruspini 1999, Järvinen 2001).

Page 83: The role of commitment in software process improvement - Oulu

81

6.1 Introduction to cases

Table 12 summarizes the cases studied briefly in terms of intended goal, planned vs. actual duration, improvement scope, improvement target, outcome in terms of direct operational success and the researcher’s role. Table 12 shows that none of the cases turned out to be a clear success.

Table 12. Summary of the cases.

SPI Goal(s) Target for improvement

Scope Outcome (Direct operational

success)

Researcher‘s role

Case 1:

Spread usability

thinking; adopt

UCD practices

UCD

processes,

development

resources

Organization-

wide

UCD practices not used,

SPI approach changed.

Expert

consultant,

participant

observer

Case 2:

Improve module

testing practices

Module testing

practices

Individual

software

designers,

business unit

wide

MT practices not

changed: new roles

defined, but not used,

practices defined/

updated, but not tested or

used.

Expert

consultant,

participant

observer

Case 3:

Improve

geographically

distributed SW

development

practices

Project

management

practices

Business unit

wide

Improvement solution

defined, not implemented

due to a decision to

terminate the SPI project.

Observer

Case 4:

Implement a new

approach for SPI.

Support and

SQA practices

1-3 projects

per site

New approach did not

sustain in use, SPI project

redirected to discovering

the improvement targets.

Participant

observer, expert

consultant

Case 1 introduced user-centered design (UCD) practices into an organization with little experience of explicit consideration of the users and usability of its products. The target of the improvement was the development of UCD processes. These processes were drawn from a variety of usability standards (Jokela 2001). Thus, the approach chosen was based on existing norms and guidelines. The purpose was to involve all organizational levels in the project. The type of improvement was process innovation focusing on the resources and processes used for developing the product. While the project has been planned to continue at the end of the year 2002, this analysis considers the first 14 months of the project. The principal outcome of the project was the changing of the SPI approach from norm-based to evolutionary. The present author participated in this SPI effort as an expert consultant and a participant observer.

Page 84: The role of commitment in software process improvement - Oulu

82

The second case was concerned with improving the module testing practices connected with the technical implementation of the software. The project was originally planned to last six months, but was then extended to one year. While the target of improvement was module testing practices at micro level – i.e. at the level of the software designer – the scope was business unit wide. Thus, new and changed practices were to be diffused to all individuals implementing software modules. No norms or guidelines were explicitly followed. Improvement targets came mainly from the software projects. Thus, the approach was evolutionary. Short term gains were sought by identifying software tools to be used for module testing and new module testing roles were established. Thus, the type of improvement was process repair and process re-engineering. As a principal outcome of the project, these roles were found inefficient, and new practices were developed and updated, but not tested. The present author took part in the project by interviewing all the key participants to find out reasons for the little advancement made and proposed actions that should be taken.

The third case made an attempt to solve problems in the practices and management of multi-site software development. The project’s actual duration was six months out of the planned 18, as the project was prematurely terminated. However, this was not due to the results obtained, but to the changes in the case organization structure. The target level for improvement was that of project management. All improvement targets were worked out through a series of interview assessments, from several multi-site projects. Thus, the approach was based on the evolutionary principle. The improvement targets were striven for by focusing on resources and their roles. Thus, the type of improvement was process re-engineering. The present author participated in this project as an observer with little interference in its implementation.

The fourth case was designed to implement a new way of providing methods and tool support for software projects by enabling the projects to tackle their existing problems systematically. It was a multi-site SPI project since five geographically distributed software development units were simultaneously participating in the project. The improvement target was to work out and implement a set of support and project management practices. While the project drew its improvement targets from the CMM, each participating project manager was in full control to decide which improvements were to be implemented. Late in the SPI project, a decision was made to redirect the project focus. The present author participated in improvement meetings and intervened by making proposals on what should be done next at one of the five sites. In the remaining four sites, the present author played the role of an observer.

6.2 Case 1: Improving usability processes

Company A is an SME with less than 100 employees, developing electronic ticketing systems for national and international markets. Company A is divided into six different units: after sales, project delivery, product development, systems unit, mechanics unit and marketing unit. The after sales unit is responsible for customer support. Project delivery coordinates and manages all ongoing projects in the company. Product development is responsible for the specification of new products. The systems unit provides resources for

Page 85: The role of commitment in software process improvement - Oulu

83

the project delivery and the product development units. The systems unit maintains old products, tailors existing solutions to new customers and implements the new products. Thus, the systems unit is in charge of all software implementation processes, and, finally, the mechanics unit develops hardware for all the products.

Company A participated in a university-driven research project. The aim of the project was to enable companies to enhance their competitiveness by producing scientifically and empirically validated models for business-based user-centered software development. This study evaluates the progress from February 2000 to April 2001. The improvement approach was changed from norm-based to evolutionary during that period.

6.2.1 Longitudinal analysis of commitment nets

The usability project team was established to implement and to oversee improvements. A usability specialist was appointed to the role of the project manager. Several actors were involved in the initiative: the actor at the organization level was the management team, which formed the strategic commitment net for the SPI initiative. The management team had a member from each unit. Operational level actors were the systems unit and the after sales unit and the research team from the university. The research team consisted of five persons. While each participant in the project also operates on the individual level, the subsequent analysis will consider only the key participant – i.e. the SPI project manager, who is responsible for the whole SPI effort. Table 15 represents the progress of the usability improvement project using the commitment net topology.

6.2.1.1 Initiation phase

The initiation phase of the usability project included the establishment of the improvement project and the current state diagnosis activities (items #1 and #2 in Table 15).

Company A was reorganized a year before the usability initiative was launched. Due to this, the company atmosphere had deteriorated considerably and the management team was fearing that this would be reflect in their image outside. Furthermore, an ongoing large project had been postponed several times due to problems with defining a number of user-interface issues in the product. The management thus saw many opportunities in participating in the usability improvement project. In their opinion, stressing usability issues would benefit the company in a number of ways: in addition to improving the company image, usability would give them a competitive edge over their rivals and it would give them control over the customer in defining the user interface requirements. These drivers are all of structural nature and, accordingly, they had a positive effect in the initiation phase. Furthermore, the participation in the project was seen as cost-effective – which can be considered a project driver – since the services and guidance in the project they were to receive from the university would by far exceed the participation costs.

Company A has had a long history of great success in producing products that had been complemented on their ease-of-use. This can be seen as a psychological driver

Page 86: The role of commitment in software process improvement - Oulu

84

exerting a positive effect on the strategic commitment net. While the participation in the usability project was seen as a cost-effective action, the intent of the usability project itself was not, however, well understood.

“[…] [Usability improvement project] was seen as a part of a university project. This meant that it was too theoretical […] We launched a project but did not think what benefits would be gained. We let the university lead it.” [Management team member, interview]

As a part of the initiation phase, a two-week usability capability assessment was conducted, including introductory and closing sessions. In the early days of the project, this received high priority among the actions in the usability improvement project. However, the assessment procedure proved to cause more confusion than clarity concerning the position and status of usability in the organization.

“It contained a lot of unfamiliar terms both to me and to the rest of the audience. So we did not understand too much of the presentation. […] I told [the personnel] that of course there are a specific terminology and other stuff related to usability. There’s some kind of mismatch between the academia and the software development organization. Here we aim at developing concrete products, this is not a research organization. […] Some of the personnel asked me if I did understand what the researchers were talking about. They used such weird language, how could you cooperate with them. [Usability specialist, interview]

As a result, the assessment team prepared a report of the current status, but failed to come up with any improvement plan. The usability capability assessment resulted in alienating the staff from usability thinking. Thus, it had a negative impact on the project, which means that a project driver also had a negative impact on the commitment at the strategic level. The dominating form of commitment in the project initiation phase at strategic commitment net level was normative, since the structural conditions can be regarded as having created a normative pressure to take action of some sort. In this case, the action taken was the participation in the usability project, although its aims were not fully understood.

Although operational level actors – the systems and after sales units – were involved in the internal usability project of the company, they were treated as project resources rather than representatives of their units, which was the original purpose. To them, the goals and the current state diagnosis actions of the usability project remained unclear. Thus, it can be seen that a project driver had a negative impact on their commitment development. In addition, while the project was at its initiation phase and the results had not been positive, it can be stated that at operational level, no form of commitment had yet been developed.

While all the project participants have their personal commitment nets, as stated earlier, this analysis considers only the key player’s personal commitment net, i.e. that of the usability specialist within the organization. The specialist showed a clear interest toward usability issues and she had also participated in a number of university courses dealing with various usability aspects. In her studies, she had reached the point where she could start writing her master’s thesis and she was offered a position as the project manager for the usability project, which she saw as a career development opportunity. Thus, all these elements represent psychological drivers affecting her affective

Page 87: The role of commitment in software process improvement - Oulu

85

commitment development positively. Table 13 summarizes the drivers at the project initiation phase.

Table 13. Commitment net drivers in the project initiation phase.

Commitment net level

Actor Driver Type Commitment form

Strategic Focal

organization:

Management

Recent changes in the organization,

deteriorated company image, problems

with customers (concerning user

requirements), need for competitive

advantage

Cost-effective participation in the

project

Project goals unclear, assessment results

incomprehensible

Long history of usable products

Struct. (+)

Project (+)

Project (-)

Psych. (+)

Normative

Operational Internal

group:

Systems unit,

after sales

unit

Project goals unclear, assessment results

incomprehensible

Project (-)

None

Personal Internal

individual:

Usability

specialist

Interest in usability issues

Attended university courses

Preparation of Master’s thesis

Availability of the project manager

position

Psych. (+) Affective

6.2.1.2 Operation phase

The operation phase of the usability project comprises the actions taken after the usability capability assessment, items #3 to #9 in Table 15.

#3 Review usability standards

The usability project members reviewed usability standards as the basis for the development of an in-house style guide. The purpose of this action, i.e. the concern, was to convince the customer that the user requirement decisions the company made for their products were based on official standards. Initial reports were produced but not all standards were reviewed. The task proved to be more difficult than originally thought. Moreover, summarizing the intent of a standard and transforming it to an in-house style guide turned out to be very difficult. Despite these difficulties, the company web pages now hold references to the use of the ISO 13407 Human-centered design processes for interactive systems and the ISO 9241-11 Guidance on usability standards.

Page 88: The role of commitment in software process improvement - Oulu

86

#4 Make customer visits

While the organization was developing a new product for the market, the usability project team visited their main customers in order to fathom out the user requirements. Although huge masses of customer data were collected, the usability specialist was assigned to deal with the analysis task on her own. Other team members complained about lack of time and failed to deliver their observations. While the usability specialist’s Master’s thesis was concerned with user requirements collection, it turned out that the others interpreted that it was her job to analyze the results, since it her who was writing the thesis. By then, the usability improvement project was seen as her personal initiative, as noted by a management team member:

“[…] some people in this organization question whether [the usability project] is about doing a Master’s thesis and [the project is] not really contributing to the company.” [Management team member, interview]

#5 Participate in the prototyping course

The researchers became worried about the continuation of financial support for the inter-organizational usability project and organized a tailored hands-on paper prototyping course for all participating companies including company A. It was seen that the organizations should have concrete tools to use in their software design process. There was a lot of discussion in the management team about sending part of the systems unit team to participate in the course, which was scheduled to last a full working week. However, the good and concrete results obtained in the course proved to be the key issue in deciding whether company A should continue its participation in the inter-organizational usability project. During the course, the participants managed to produce a specification for the new product user interface through the paper prototyping method. Afterwards, the method remained in use in the systems unit as one of their design technique tools.

#6 Decision to stay in the project

During the same time as action #5, company A’s management had discussions whether they should drop out of the university-led research project. The management team claimed that the usability project was operating in isolation with little connection to “real work”. No visible results had been obtained and it was felt that the project was only a burden to organization resources. The usability specialist then produced an analysis report of the benefits gained, which was communicated to the management team. As a result, a decision was made to continue participation. The university researchers were seen as cost-effective consultants that would help their usability project in the new product development.

Page 89: The role of commitment in software process improvement - Oulu

87

#7 Doubts raised against the project

While the software was produced in the systems unit, and it should also incorporate UCD practices in the requirements analysis and software design processes, the systems unit manager raised doubts about the usefulness of the paper prototyping technique.

“[Systems unit manager] suspects whether the specification produced by the user-interface team through paper prototyping is finished. He doubts whether the exceptions and all the requirements are taken into account.” [Research diary]

Subsequently, the usability specialist carefully reviewed all the concerns voiced, and the results of this review were reported in an official review session. This did not, however, convince the systems unit manager or improve the relationship between the systems unit and the usability project.

#8 Increased involvement in the project

The after sales unit manager was willing to gain benefit from the usability project. Accordingly, two joint workshops were held, in which the usability requirements were defined for the user manual and for the manual implementation process. As a consequence, the after sales unit manager started to consistently emphasize the importance of the usability project.

#9 Usability efforts directed to new product development

At the beginning of the second year into the usability project, the organization management required that all efforts in the usability improvement project should be directed to ensuring the usability of the new product. As a result, a series of usability tests were conducted, also using the experience of the university staff involved in the process. The new product was displayed in a marketing congress, at which all the customers were present. The new product received a lot of attention and gained highly positive feedback, especially in terms of its ease of use and other usability dimensions.

Table 14 summarizes the drivers that affected the development of commitment in the operation phase of the usability project.

Page 90: The role of commitment in software process improvement - Oulu

88

Table 14. Commitment net drivers in the project operation phase.

Commitment net level

Actor Driver Type Commitment form

Strategic Focal

organization:

Management

An observation that usability project

operates in isolation, the project

consumes resources, but does not benefit

the organization

Paper prototyping course, positive

customer feedback

A perception that the project has been

university-led

Project (-)

Project (+)

Psych. (-)

Instrumental

Internal

group:

Systems unit

Little trust in the paper prototyping

method

No involvement in the action planning

of the usability project

Project (-)

Psych. (-)

Instrumental Operational

Internal

group: After

sales unit

Joint workshops with solid results Project (+) Affective

Personal Internal

individual:

Usability

specialist

Problems in motivating usability project

team

Preparation of the Master’s thesis

Social (-)

Psych. (+)

Affective

The management team observed that the usability project had been operating in isolation and the team was ready to terminate the project at the end of the first operating year. This can be regarded as a project driver exerting a negative effect on the strategic commitment net. On the other hand, the paper prototyping course and the positive customer feedback were perceived to yield positive results. Thus, there was also a project driver with a positive effect on the strategic commitment net. Finally, the perception that the usability project was a university lead initiative – a psychological driver – had a negative influence on the strategic commitment net. The dominating commitment form at strategic level was, therefore, of instrumental nature, and the continuation of the project was strictly tied with the benefits obtained from the usability project.

The systems unit did not participate in the action planning sessions of the usability project, which can be seen as a psychological driver exerting a negative effect on the commitment development of the unit. The systems unit manager who was in charge of decision making regarding software projects did not perceive the paper prototyping method as useful enough to be used continuously in software projects. This can be seen as a project driver affecting the systems unit commitment development negatively. Therefore, the dominating form of commitment, also here, is the instrumental type.

The after sales unit increased its level of participation in the usability project in the operation phase. This was due to the after sales unit manager who wanted to benefit from the ongoing improvement project. Joint workshops were organized and the results were

Page 91: The role of commitment in software process improvement - Oulu

89

seen as very beneficial for the after sales unit. For this unit, the project driver had a positive effect on their commitment development.

The usability specialist, who was the key player in the improvement project, experienced problems in motivating the other members involved to contribute to the usability project. This can be seen as a social driver which had a negative effect on her commitment. Basically, it was the preparation of the Master’s thesis that ensured her keen interest in the project.

6.2.1.3 Closure phase

While the project faced several problems the researchers realized that in order for any improvements to be sustained when the usability project was finished, the systems unit needed to be empowered to make the improvement decisions. An evolutionary improvement approach was thus proposed and subsequently implemented, which included an explicit involvement of the systems unit in defining the improvement targets. The new approach was proposed by the university research team and welcomed by the usability project team, along with the management and the systems unit manager.

The base for attachment, i.e. the form of commitment, to the usability improvement project, however, differs from one actor to another. The management team had made a financial investment at the beginning of the year in continuing the participation in the project. Problems arising from little evident progress made so far were blamed on the “wrong approach” to improving usability. The new approach would solve these problems. Also, management placed a strong trust on the expertise of the external research team. Thus, the management can be said to have shown continuance commitment toward the usability improvement project.

The systems unit, which had started to play an increasingly important role, liked the approach, but they had gained a negative perception of UCD practices. To them, UCD had already a “too theoretical” label attached to it.

“[…] software person (architecture designer or similar) did not stay for too long, unfortunately. [He] kept looking at his watch from the beginning and soon announced that [he] had so much work to do that [he] did not have the time to stay [at the stakeholders meeting].” [Research diary]

However, the fact that the management was involved in the meeting in which the decision was made to adopt the new approach increased the social pressure to participate. Therefore, the systems unit was normatively committed toward the usability improvement project. The usability specialist relied on the expertise of the external research team, as did also the management, and thought positively of the new approach. The usability specialist’s dominating form of commitment was of affective nature. Any actions beyond this point in the usability project fall beyond the scope of this analysis, because this point of time represents a logical closure to the usability project. In addition, the project was initially planned to last until the end of 2002. Thus, it was not possible to follow the progress within the time frame of this thesis. Table 15 shows the drivers involved in the closure phase.

Page 92: The role of commitment in software process improvement - Oulu

90

Table 15. Commitment net drivers in the project closure phase.

Commitment net level

Actor Driver Type Commitment form

Strategic Focal

organization:

Management

Attractiveness of the new approach,

problems blamed on the old approach,

trust on the external research team

Need of justifying spent resources

Psych. (+)

Project (+)

Continuance

Operational Internal

group:

Systems unit

Attractiveness of the new approach

Involvement of management

Negative perception of UCD practices

Psych. (+)

Social (+)

Project (-)

Normative

Personal Internal

individual:

Usability

specialist

Attractiveness of the new approach,

trust on the external research team

Psych. (+) Affective

Page 93: The role of commitment in software process improvement - Oulu

Tabl

e 16

.Cas

e 1:

Com

mit

men

ts r

efle

ctin

g th

e pr

ogre

ss o

f the

impr

ovem

ent p

roje

ct.

Out

com

es#

SPIp

hase

Act

orC

once

rnA

ctio

nsIn

tend

edU

nint

ende

d

1In

itia

tion

:

Est

abli

sh-

men

t

Foca

l

orga

niza

tion

:

man

agem

ent

Qua

lity

(usa

bilit

y)

prob

lem

s in

the

prod

ucts

,

com

pany

imag

e, u

sabi

lity

thin

king

mis

sing

Part

icip

atio

n in

the

inte

r-

orga

niza

tiona

l usa

bilit

y

impr

ovem

ent p

roje

ct,

esta

blis

hmen

t of

com

pany

’s in

tern

al

usab

ility

pro

ject

Inte

rnal

usa

bilit

y im

prov

emen

t pro

ject

esta

blis

hed,

goa

ls a

nd m

issi

on d

efin

ed

Com

pany

was

def

inin

g ac

tion

s

on th

eir

own

with

out c

onsu

lting

with

the

univ

ersi

ty r

esea

rch

team

2In

itia

tion

:

Dia

gnos

e

curr

ent

stat

e

Mix

edgr

oup:

Usa

bili

ty

proj

ectt

eam

,

rese

arch

ers

Cur

rent

sta

tus

of U

CD

in

the

orga

niza

tion

, are

as f

or

impr

ovem

ent

Usa

bilit

y ca

pabi

lity

asse

ssm

ent p

erfo

rmed

,

emph

asis

on

the

role

of

man

agem

ent i

n th

e

asse

ssm

ent

20 p

erso

ns in

terv

iew

ed, a

rep

ort o

f th

e

curr

ent s

tatu

s pr

oduc

ed, m

anag

emen

t

had

a vi

sibl

e ro

le in

the

asse

ssm

ent,

all s

enio

r m

anag

emen

t par

ticip

ated

in

the

asse

ssm

ent

UC

D w

as p

erce

ived

dif

ficu

lt to

unde

rsta

nd a

nd to

o th

eore

tical

,

an im

prov

emen

t pla

n w

as n

ot

prod

uced

, sta

ff a

liena

ted

from

usab

ility

thin

king

3O

pera

tion

:

Act

ing

Inte

rnal

grou

p:

Usa

bili

ty

proj

ectt

eam

Usa

bilit

y re

late

d st

anda

rds

shou

ld b

e us

ed f

or

conv

inci

ng th

e cu

stom

er,

need

of

in-h

ouse

sty

le

guid

ance

Rev

iew

of

usab

ility

rel

ated

stan

dard

s

Prel

imin

ary

repo

rts

prod

uced

,

com

pany

ref

ers

to th

e us

e of

sta

ndar

ds

in th

eir

web

pag

es

It tu

rned

out

to b

e di

ffic

ult t

o

take

bits

and

pie

ces

out o

f

diff

eren

t sta

ndar

ds a

nd p

ut

them

into

ope

ratio

nal u

se.

4O

pera

tion

:

Act

ing

Inte

rnal

grou

p:

Usa

bili

ty

proj

ectt

eam

Usa

bilit

y re

quir

emen

ts f

or

the

new

pro

duct

, mas

ter’

s

thes

is

Cus

tom

er v

isits

with

the

usab

ility

pro

ject

team

Cus

tom

er d

ata

gath

ered

abo

ut c

urre

nt

prob

lem

s an

d w

ork

proc

edur

es, b

ut n

o

repo

rt p

rodu

ced

Cau

sed

prob

lem

s w

ith p

erso

nal

rela

tions

hips

(so

me

mem

bers

did

not d

eliv

er th

eir

obse

rvat

ions

.)

5O

pera

tion

:

Act

ing

Ext

erna

l

grou

p:

Res

earc

hers

Prod

uce

conc

rete

and

mea

ning

ful b

enef

its f

or th

e

com

pany

, ens

urin

g

fina

ncia

l sup

port

for

com

pany

A in

the

futu

re

A p

aper

pro

toty

ping

cou

rse

orga

nize

d

Eff

icie

nt te

amw

ork,

spe

cifi

catio

n of

user

inte

rfac

e fo

r th

e ne

w p

rodu

ct

feat

ure

prod

uced

, pap

er p

roto

typi

ng

cont

inue

s to

be

used

in th

e co

mpa

ny

The

cou

rse

prov

ed to

be

the

mai

n re

ason

for

con

tinui

ng

with

the

usab

ility

impr

ovem

ent

proj

ect

Page 94: The role of commitment in software process improvement - Oulu

92O

utco

mes

#SP

Ipha

seA

ctor

Con

cern

Act

ions

Inte

nded

Uni

nten

ded

6O

pera

tion

:

Act

ing

Foca

l

orga

niza

tion

:

Man

agem

ent

Usa

bilit

y pr

ojec

t exi

sts

only

for

the

prep

arat

ion

of

a si

ngle

mas

ter’

s th

esis

, no

retu

rn o

n m

oney

or

reso

urce

s sp

ent,

usab

ility

proj

ect i

s op

erat

ing

in

isol

atio

n

A d

ecis

ion

to c

ontin

ue

fina

ncin

g th

e us

abili

ty

impr

ovem

ent p

roje

ct:

Que

stio

ning

the

bene

fits

gain

ed f

rom

the

proj

ect i

n

man

agem

ent a

nd u

sabi

lity

proj

ect s

teer

ing

grou

ps

An

anal

ysis

rep

ort o

f be

nefi

ts g

aine

d

prod

uced

->

A d

ecis

ion

to c

ontin

ue p

artic

ipat

ion

with

in th

e in

ter-

orga

niza

tiona

l

usab

ilit

y pr

ojec

t

The

em

phas

is o

n us

abili

ty

gain

ed ‘

too

muc

h’ a

ttent

ion;

expe

ctat

ions

rai

sed

high

.

7O

pera

tion

:

Act

ing

Inte

rnal

grou

p:

Syst

ems

unit

Use

fuln

ess

of p

aper

prot

otyp

ing

for

requ

irem

ents

spe

cifi

catio

n

Que

stio

ning

the

relia

bilit

y

and

exte

nsiv

enes

s of

the

spec

ific

atio

ns p

rodu

ced

thro

ugh

pape

r pr

otot

ypin

g

Spec

ific

atio

n ca

refu

lly r

evie

wed

rega

rdin

g co

ncer

ns m

ade

by th

e

syst

ems

unit

man

ager

Hos

tile

attit

ude

deve

lope

d

betw

een

the

syst

ems

unit

(S

W

proj

ects

) an

d th

e us

abili

ty

proj

ect

8O

pera

tion

:

Act

ing

Inte

rnal

grou

p:A

fter

sale

sun

it

Aft

er s

ales

uni

t had

not

rece

ived

any

ben

efit

from

the

usab

ility

pro

ject

Enh

ance

invo

lvem

ent i

n

the

proj

ect t

hrou

gh jo

int

mee

tings

and

wor

ksho

ps

Usa

bilit

y re

quir

emen

ts f

or th

e us

er

man

ual a

nd f

or th

e im

plem

enta

tion

proc

ess

of th

e ne

w s

yste

m d

efin

ed

Aft

er S

ales

uni

t man

ager

sta

rts

to c

onsi

sten

tly e

mph

asiz

e th

e

impo

rtan

ce o

f th

e us

abili

ty

proj

ect

9O

pera

tion

:

Act

ing

Foca

l

orga

niza

tion

:

Man

agem

ent

Usa

bilit

y of

the

new

prod

uct

Con

cent

rate

all

the

effo

rt in

the

usab

ility

impr

ovem

ent

proj

ect o

n ne

w p

rodu

ct

deve

lopm

ent,

dem

onst

rate

new

pro

duct

in th

e bu

s

mar

ketin

g co

ngre

ss

New

pro

duct

des

igne

d, h

ighl

ight

ing

the

usab

ility

req

uire

men

ts a

nd u

ser

feed

back

, pos

itive

cus

tom

er f

eedb

ack

The

term

“us

abili

ty”

gain

s

nega

tive

conn

otat

ion

in th

e

orga

niza

tion:

“It

blo

cks

the

new

pro

duct

dev

elop

men

t

sche

dule

10C

losu

re:

Lea

rnin

g

Ext

erna

l

grou

p:

Res

earc

hers

Inef

fici

ent c

olla

bora

tion

with

sys

tem

s un

it

Impl

emen

t an

evol

utio

nary

impr

ovem

ent a

ppro

ach

Not

incl

uded

in th

e an

alys

is

Not

incl

uded

in th

e an

alys

is

Page 95: The role of commitment in software process improvement - Oulu

6.2.2 Empirical conclusions

In this final section of the analysis, the commitment process is depicted as it developed over the three SPI phases and the change achieved in actors’ commitment net is described.

6.2.2.1 Commitment process

In company A, the management team operates the organization’s strategic commitment net. Based on their decisions, the projects are launched and terminated. The management team saw the need for the usability improvement project. Other units, however, did not. In the initiation phase, no success was achieved in clarifying the goals or purposes of the project. The crucial instrument of diagnosing the current state, i.e. the process assessment procedure, produced results that were incomprehensible for the staff. Thus, in the initiation phase, the project drivers at the operational level decreased commitment toward the usability improvement project. At the personal level, the usability specialist, however, was involved to a high degree and the goals of the project also matched her career ambitions. Thus, psychological drivers worked to increase her commitment toward the project.

In the operation phase, a series of actions were taken to ensure that the UCD practices were incorporated in the daily practice. However, while the results were mixed and the management perceived that the university was leading the project, the project drivers worked against the usability improvement project. The positive customer feedback received from the marketing congress, however, increased the commitment toward the project, which led to an easy adoption of the new implementation approach at the closing phase of the project.

Table 17 summarizes the changes in commitment drivers and forms of commitment during the SPI project studied. Table 17 shows that at the strategic commitment net level the dominating form of commitment changed from normative over instrumental to continuance. This means that the management team’s base of attachment changed from pressure to being linked with the investment made. The systems unit and the after sales unit form the operational level commitment nets. The dominating form of commitment for them changed from no commitment over instrumental to normative. This shows how a stronger form of commitment was developed over time. At the individual level, finally, where the focus was on one key player, the usability specialist, no changes in the form of commitment were evidenced.

Page 96: The role of commitment in software process improvement - Oulu

94

Table 17. Case 1: Commitment process in the SPI project.

Initiation (#1, #2) Operation (#3 - #9) Closure (#10) Commitment Nets Drivers C-form Drivers C-form Drivers C-form

Strategic

Project (+/-)

Psych. (+)

Struct. (+) NC

Project (+/-)

Social (-)

IC

Project (+)

Psych. (+) CC

Operational

Project (-)

None

Project (+/-)

IC

Project (-)

Psych. (+)

Social (+)

NC

Personal Psych. (+)

AC Psych. (+)

Social (-) AC

Psych. (+) AC

6.2.2.2 Changes achieved

To make the usability improvement project succeed, commitment nets at all levels should be changed to include a concern about usability, along with actions to match this concern. While a number of SPI actions were employed to incorporate UCD into the daily routines of company A, after fourteen months into the improvement project UCD practices were still not part of the daily routines. Table 18 summarizes the extent of changes, i.e. the SPI outcome, achieved in the actors’ commitment nets.

The usability specialist’s devotion to the project provided the greatest contribution to the progress of the improvement project. When asked whether usability activities would be sustained if she were to leave the organization, she replied:

“But [usability activities] would not be continued at this level. Some actions would be carried out, but the whole concept of user-centered design would stay in the dark.” [Usability specialist, interview]

At the operational level, only the after sales unit participated in the project actively. They, however, do not produce the software. The systems unit, which develops and maintains all software, however, alienated from the usability project and beyond the few times that the paper prototyping method was employed UCD practices were, basically, not used. There were several reasons for this. For one thing, user-interface design and usability were not considered to be very important.

“[System specialist and systems unit manager] did not consider user-interface to be a very important part of the system, because the system has few users and it is not used that frequently. [They claimed that] besides, everybody knows that this kind of a system is difficult to use and people [just] have to adapt to that. New [system solutions] are always based on the existing one. Usability problems come from the distant past” [Research diary, during an assessment interview]

More important than usability was the customer’s quick acceptance of the design solution. The designers wanted to have as little as possible to do with the customer. In fact, they viewed that by using the UCD methods the customer would stay out of the

Page 97: The role of commitment in software process improvement - Oulu

95

development process. However, the UCD methods were perceived as too theoretical and difficult to understand. These realizations lead to the university research team proposing a change from norm-based to evolutionary in the SPI approach of the usability project. In the new approach, the systems unit would define, prioritize and implement the improvement actions.

The strategic commitment net was successfully altered during the period of research. The founder (and co-owner) of company A participated in the project in a consistent and active manner. He took an especially active role in usability assessment, even though he did not thoroughly understand what the assessment was all about. He continued to publicly emphasize the importance and benefits of the usability project. The interest of the management in the usability project was also based on the need of an enhanced competitive edge. The Internet pages of Company A now indicate that they are adhering to the ISO 13407 (Human-oriented design processes for interactive systems) and ISO 9241-11 (Guidance on usability) standards. Thus, the change in strategic commitment net is clearly visible to other organizations as well as to Company A personnel.

Table 18. Change achieved in actors’ commitment nets.

Commitment Net

Target actor SPI outcome (Impact on the customer)

Evidence

Strategic Focal

organization:

Management

Usability seen as one tool in

management toolbox. Used

predominantly as a marketing

device.

Usability used as a marketing tool,

web pages state the use of

usability standards, continuing

participation in the usability

project.

Internal group:

Systems unit

Systems unit alienated from the

usability improvement project;

apart from the paper prototyping

method having been used

occasionally, UCD practices have

not been diffused.

Unwillingness to participate in

joint workshops, group members

claim that usability and UCD are

only theoretical matters, thus not

related to their practical

development work.

Operational

Internal group:

After sales

After sales unit manager

convinced of benefits, continues to

emphasize the importance of the

project publicly.

Joint workshops organized;

usability requirements for user

manual and its implementation

process defined.

Personal Internal

individual:

Usability

specialist

Training, skills and experience

gained in relation to UCD.

Attitude enthusiastic toward the

usability concept.

Active and enthusiastic

participation in the project.

6.3 Case 2: Improving module testing processes

Case company B is an independent business unit of a large global corporation developing electronic products and systems for industrial customers. It has thousands of employees

Page 98: The role of commitment in software process improvement - Oulu

96

working in several locations around the world. Company B has been organized into a matrix, where the line organization is responsible for resource management and competence development, and the project organization takes care of product development. The SPI department belongs to the line organization and provides support concerning tools, methods and processes used in software projects. The global SPI department is responsible for making the go, or no-go decisions regarding SPI projects.

Company B has years of experience in producing software on their in-house platform. A high management decision was made to implement a new product on a commercial platform. The new platform required adopting new programming methods, tools and processes. Thus, also low-level practices were to be changed. The process also involved redefining and distributing module testing (MT) practices. This analysis concerns a period of 12 months during which several strategies were employed to achieve the set targets.

6.3.1 Longitudinal analysis of commitment nets

No single initiative was launched to tackle the module testing problem. Instead, six different strategies, i.e. different levels of action, were employed to define and to introduce new module testing practices to Company B: (1) develop new process descriptions and operating instructions, (2) define new roles and responsibilities, (3) evaluate a module testing tool with volunteer software designers, (4) develop and distribute a MT survey to the software designers, (5) evaluate module testing tools and practices in a pilot project, and (6) hire a researcher to evaluate reasons for the little progress made in module testing improvement. The progress of the SPI effort is laid out in Table 20.

6.3.1.1 Initiation phase

The SPI project manager had been discussing the defining, improving and harmonizing of module testing practices with project teams for three years already. For historical reasons, each development unit had their own ways of performing the module testing procedure. This practice showed differences also at the individual level, where different designers had been responsible for their own modules.

Company B was in a transition phase where new product development upon a new operating platform was well under way. The intention was to reduce the software development cycle time within the new development paradigm (i.e., incremental SW development) by 30%. The module testers in the software team had been complaining about the inefficiency of current techniques for a long time already. Each team had been solving problems as they had seen fit. The SPI department was not aware of the tools that were currently used. Furthermore, the environment that the SPI department was to support had changed within a few years’ time from a single product to multiple products and operating systems. At the time the project was started, a total of four testing environments had to be supported. Thus, the problems concerning module testing

Page 99: The role of commitment in software process improvement - Oulu

97

improvement were widely recognized. No new practices for the new technology or for the software paradigm had not yet been defined. Little change resistance was therefore expected.

[…] Well, now there is an opportunity to do again. New product [development] is underway. This means that [improving the module testing methods] should be done now or it will never get done. Now we have the time to do it. Now we can fix it for good, as otherwise there will never be enough time, and for sure, no second chance will be given after [some solution] has been implemented. [Software designer, interview]

Table 19 shows the commitment net drivers in the project initiation phase.

Table 19. Commitment net drivers in the initiation phase.

Commitment net level

Actor Driver Type Commitment form

Strategic Focal

organization:

Management

New product development, testing took

over half of the total development time,

software development cycle should be

reduced by 30% -> Testing process will

be automated to the highest possible

extent (also MT phase)

Struct. (+) Normative

Internal

group:

Software

projects

New product development, not enough

support available

Module testing difficult and time

consuming, timing is right

Social (+)

Psych. (+)

Instrumental Operational

Internal

group: SPI

department

Poor history of success in the

development of module testing practices

Too many tools & platforms to support,

new product development ->Increasing

need for complete support also in MT

methods, tools and processes

Unawareness of current status in terms

of module testing practices

Psych. (+)

Struct. (+)

Project (+)

Normative

Personal Internal

individual:

SPI project

manager

Three years of discussions and singular

attempts to improve the situation in

regard to MT practices

Social (+),

Psych. (+)

Affective

The SPI actions to improve module testing practices were launched out of necessity. The structural driver, which refers to the environment for SPI activities, thus had a positive effect on commitment development regarding the management of the focal organization, which constitutes the strategic commitment net for the SPI initiative. The dominating commitment form was, therefore, normative. The internal groups, i.e. software projects and the SPI department, which had had difficulties in coping with

Page 100: The role of commitment in software process improvement - Oulu

98

module testing practices, represented various types of social, psychological and structural drivers, as presented in Table 19. However, the form of commitment showed a lot of variation. Software projects were found instrumentally committed, while the SPI department showed commitment of normative kind. This is a significant finding: although the drivers were the same, the developed form could differ. The reason for this is explained in the analysis of SPI actions in the operation phase.

6.3.1.2 Operation phase

In what follows, each improvement action shown in Table 20 is analyzed separately.

#1 Common MT process & instructions development

The MT testing issues were embedded in a larger improvement effort (in terms of goals, not man power) targeted to provide “more efficient testing methods, tools and environments in Company B’s R&D-projects”. In fact, this improvement action was targeted to meet the requirements of one of the development projects. Four goals were defined: 1) Methods, tools and instructions ready for module testing (Platform A, Platform B, Platform C), 2) Methods, tools and instructions ready for platform C Integration, 3) Testing tool parameters ready for module testing in the development project and Platform C Integration, 4) Training and support for the new tools.

The SPI project manager had initially planned the SPI action for six months, including the rollout phase (connected with Project X schedule). The SPI project manager, however, soon realized that the timeframe was unrealistic and thus the SPI action was later expanded to include another six months, i.e. 12 months altogether. The SPI project manager was the only dedicated resource for the SPI action #1. When asked why this was the case he responded that

“Yes, [Global SPI manager] says that this is important, but then, generally pleads [the fact] that no resources are available, or something.” [SPI project manager, interview]

In another interview, Company B’s top manager speculated that if something was not seen truly important, a traditional way to decline politely was to argue for lack of resources. As a result, status reports were produced only twice per calendar year. Normally, a status report should have been produced monthly. The SPI project manager responded that he was, basically, reporting to himself. Nevertheless, some concrete advancements were made: a common MT process was developed, module testing instructions and templates for different platforms were revised and the reporting practice was also redefined. Due to changes in the organization, however, there was no roll out with adequate training. Resulting documents were entered in a document database with public access. It is possible that some developed instructions were used, but this was not further investigated.

“You are the first one who has asked anything about the final report. I wonder if you are the fist reader :)?” [Email, SPI project manager]

Page 101: The role of commitment in software process improvement - Oulu

99

As is indicated by the statement above, the findings of the SPI action aroused little discussion in the organization. Still, the goals, as they were defined in the SPI action plan, were achieved to some extent. These goals were met, because the SPI project manager took personal responsibility for producing draft versions of the documents.

At personal level, referring to the SPI project manager, this reflects the existence of personal responsibility for the outcome SPI action. Thus, the form of commitment can be interpreted as affective. At the operational level, referring to the SW development project in this particular SPI action, no participation was achieved. Thus, this can be interpreted as no form of commitment having been achieved. At strategic level, the global SPI department agreed to extend funding for this action, but failed to add any new resources to SPI action #1, which can be regarded as a form of continuance commitment.

#2 Define new roles and responsibilities

SPI department suggested that each development unit should have a person responsible for module testing (referred as to MT power user) defined in their group; this person would coordinate and help the activities of the group in this regard. This person was given a recommendation by the management that 10 to 20% of their work effort should be devoted to only module testing development and support. Thus, the need to organize module testing support activities in a new way emerged from among the needs of SPI department. Module testing power user kick off days were organized, during which the management set expectations for this new role. Another role, i.e. that of a module testing core team (MT core team), was also established. Their task was to oversee all activities and to make the necessary decisions and adjustments. MT core team was not, however, a new idea. A similar group had existed earlier, too, but it used to be called MT group, and it involved one person from each software project team. The MT group was too large and too diverged, and it was found to be inefficient. The MT core team, again, was a smaller unit. The purpose of setting up such a core team was to ensure that activities would endure even if the persons responsible for these activities changed their position in the organization. The MT core team consisted of a software project leader as a chair, along with some members of the SPI department and some software developers. The software project leader involved in the MT core team, however, did not want to invest a lot of effort in this role.

“[…] It is more of an extra duty. I am not too passionate about it.” [Software project leader, interview]

No authority to decide upon resource use was granted. The MT core team soon realized that the 10 to 20% work effort devoted to module testing was a ‘virtual work effort’ that would be taken away at the first sign of trouble in the development project.

“[…] when you start getting busy, as it always is, it is just those [20% work effort dedicated to MT work] kind of things that will be cut off first.” [Software project leader, interview]

“[…] as an idea [having MT power users] it is OK. […] The responsibility [for MT practice development] should be taken by the SPI department.” [Software department leader, interview]

Page 102: The role of commitment in software process improvement - Oulu

100

“It is virtual time all the way. There should be different people developing the [module testing] practices and if there is some support function similar to what I do, it is done beside [your regular activities]. It does not take ten percent or twenty percent. But, it is a utopistic thought that one could use that 10 or 20%. Projects will always take it away.” [Software designer, MT core team member, interview]

A software designer who had recently been appointed to the MT power user role was not aware of the help available for MT practice support and development. He was doubting whether it would ever be realized as planned. Moreover, MT power users were not advised on how to use the time available nor were they given a plan on what MT-related issues to solve, as is shown by the interview extract below.

“[…] and if there was some kind of roadmap and if someone organized how to proceed, why not.” [MT power user, interview]

Software projects were thinking that the allocation of MT responsibilities to them was ‘another responsibility’, which would be given to a person with little extra duties. The role of the MT person’s was seen somewhat similar to that of the quality agent, and in managers’ and the software developers’ view it was ‘just another meaningless duty’. In fact, none of the interviewees reported any benefits of having a quality agent role in their software team. The quality department, which was separate from the SPI department and did not participate in the SPI actions analyzed, was in charge of performing quality audits and reporting the current status to the management. Managers were then expected to deliver the message to software projects. There was also a discrepancy concerning the role of the SPI department. Software projects felt that they should receive complete, packaged support from the SPI department. The SPI department, however, did not have any resources for planning, evaluating, piloting and updating the tools and methods.

“[…] [The SPI department] should have the resources and time to think about what our tools should be. [They should] evaluate them and keep a tool list updated so that everyone could use it. The information should come from the SPI department. Now, whenever [software] projects find out that their tool does not work or this version of the tool does not work, they make their own decisions and update their tools. This is working currently in the wrong order.” [Software project manager, interview]

The purpose of the new roles was to transfer the concern for module testing development from the SPI department to individual software projects. Based on the above description, this transfer failed to succeed. The software projects saw that the roles, as suggested by the SPI department, were neither useful nor necessary. Still, the roles were established, but failed to achieve their purpose. The target actor, i.e. the involved software projects, proved to nominate the MT power users, because the management had required it.

#3 Module testing tool evaluation

One of the improvement strategies was to evaluate a commercially sold module testing tool in close cooperation with the volunteering software engineers. However, the commercial tool package arrived late and failed to contain the functionality promised. Moreover, the testing platform was not ready at the time of the intended evaluation. In

Page 103: The role of commitment in software process improvement - Oulu

101

addition, when the SPI project manager asked for volunteers to participate in the effort, very little positive responses arrived. Due to the reasons stated above the SPI project manager aborted the action.

#4 Module testing survey

In order to find out the current status of module testing practices, the MT core team prepared a module testing questionnaire, which was distributed to all software developers in 17 software teams. A total of 57 responses were gathered. The MT core team was satisfied with the amount of questionnaires returned.

The results showed that slightly over 30% of all software designers were not satisfied with the current practice. The software designers were claiming that the currently used test case simulation took too much effort. Also, tool support was needed and current tools were regarded as inefficient for the purpose. Even though everyone (i.e., 100% of respondents) agreed on the importance of module testing improvement, only 3% agreed to participate in the improvement effort.

The MT core team was unable to come up with an action plan and a timetable that everyone in the team could agree upon. They also failed to decide who would take the responsibility for summarizing the results into a slide set that would be reported back to the software teams for feedback. This was due to the other responsibilities that the MT core team personnel were engaged in. They decided to perform this activity as a collective effort. This task, however, was never completed. As a result, they reported to upper management that they needed dedicated resources for solving the problem.

The MT core team suffered from lack of reason to exist. The team members were unsure whether they could make any real decisions. This could be seen as a further hindrance to their work. A software designer suspected that the MT core team was still at “vision level”. He thought that they would remain there and little useful will come out. On the basis of the description above, it can be interpreted that the members in the MT core team had a normative commitment toward the development of module testing practices. By and large, the individual software designers had not developed any form of commitment since only 3% agreed to put extra effort into MT development.

#5 Pilot project

Apart from the tool evaluation attempt (SPI action #3) described above, a pilot project was launched where the object-oriented software technology and the incremental software development paradigm were to be tested. An evaluation of module testing tools and practices was set as the fourth goal of this SPI action to be achieved. The main concern of the pilot project was related to performance figures, i.e. whether the new technology was efficient enough for the platform. The pilot team members indicated that the third and the fourth goals were rarely if ever achieved. Although the 3-month timetable for the pilot project was unrealistic, everyone involved was aware of it. The pilot team members indicated that they would be satisfied if they managed to achieve the first goal, i.e. to develop a running version. A manager from the pilot project’s steering group stated that the pilot project was of great importance and that they would follow up its progress on weekly basis. The project was called ‘pilot project’ for the specific reason of making it draw more attention among software projects. The same manager recalled that they had had problems in recruiting people to evaluation type projects. In addition,

Page 104: The role of commitment in software process improvement - Oulu

102

the pilot team members would give a brief ‘news flash’ to rest of the software group weekly. Thus, the importance of the pilot effort was widely recognized. The same manager also indicated that if the pilot team did not solve the testing issues, they would have another pilot later on that would specifically tackle module testing practices.

The pilot team managed to produce two working increments (i.e. they managed to achieve the most important goal for them), but did not manage to solve module testing issues even though an additional dedicated resource was included in the pilot at later stage to address this problem, in particular. However, this was not all due to the pilot team. The SPI department was not able to provide tools to be used for testing within pilot time limits, since the tool providers had too strict requirements for the evaluation/piloting procedure: strict licensing terms, short evaluation periods, mandatory meetings with sales personnel, piloting personnel direct names and contact information, and the like. The necessary hardware decisions had not been made yet either. The SPI project manager did not want to have something piloted that would not be used anyway. The pilot team was given an opportunity to use the tools available, but these were “too difficult to use”. The SPI project manager recalled:

“The most important matter is that the pilot team did not know what [in specific] and how it should be tested. Object-oriented testing is different from [the old platform] testing [SPI Project Manager, email]

No other pilot was launched due to time pressure. In this SPI action, none of the participating actors were committed to solving module testing procedures in the new object-oriented environment. An affective form of commitment to the pilot project was developed among the pilot project members. Concerning the module testing improvement they possessed no form of commitment due to the low priority granted. However, the only real objective of the pilot project was to evaluate the new technology in terms of its performance, which was achieved.

#6: Use an outsider to evaluate the progress

A decision was made that the present author would be used to work out the reasons forthe little progress made in module testing improvement and to find out if the SPI actionsdescribed above were producing efficient results. Thus, 12 key participants including twoglobal managers were interviewed. As a result, eight major themes were identified thatexplained the successes and problems faced: timing, need for change, willingness toparticipate, the level of risk of not achieving the intended results, managementcommitment, organization for improvement, taking responsibility, and action plan. It canbe argued that while the timing of improvement was well planned and the need forchange was widely acknowledged, the resources for necessary actions were not adequate.However, due to the poor reputation of process development, not too many people werewilling to participate, even if they were given the opportunity. The level of risk of notachieving the intended results was not high, since it was indicated by everyone involvedthat problems could be solved somehow if not through these actions. The organization forimprovement was adequate, but a clear action plan was missing. For this reason, nosingle initiative, but a cluster of diverse actions was launched.

The results above were reported to the MT core team and the global SPI manager. The SPI project manager indicated later that the results were delivered also to the global test

Page 105: The role of commitment in software process improvement - Oulu

103

process manager, who would consider them in planning future test process improvement initiatives.

Table 20 presents the drivers that affected the development of commitment in the operation phase of the SPI project. The focus here is on the actors participating in the SPI actions described in this section.

Table 20. Commitment drivers in the operation phase.

Commitment net level

Actor Driver Type Commitment form

Strategic Focal

organization:

Management

Lack of resources in the pilot project

(SPI action #5)

Project (+) Continuance

Internal

group:

Software

projects

Management expectations

Goals of the actions well understood,

new roles perceived as redefinition of

old already existing ones

Social (+)

Project (-)

Instrumental

Internal

group: MT

core team

No decision making authority, other

duties

No management involvement

Management expectations

Struct. (-)

Psych. (-)

Social (+)

Normative

Internal

group: Pilot

team

MT development prioritized as the

fourth goal of the pilot project

Project (-) None

Operational

Internal

group: SPI

department

Software project’s need of support

Software projects showed little

personal interest in MT development

Struct. (+)

Social (-)

Normative

Internal

individual:

MT power

user

Role was not perceived as important

Lack of clear guidance, action plan and

support for the role

Psych. (-)

Project (-)

Normative Personal

Internal

individual:

SPI project

manager

Personal responsibility for the outcome

of the SPI actions (except for #5 and

#6)

Psych. (+) Normative

At the strategic level, the focal organization management was involved only in SPI action #5. The pilot project resources were tied in performance evaluation. This project driver caused a need to allocate an additional resource for developing module testing practices – which can be considered a form of increased continuance commitment. At the operational level, several actors were involved: software projects with MT power users, the MT core team, the pilot team and the SPI department. The software projects did allocate one person per group to the new role, but only to avoid unnecessary conflict with the SPI department – which can be regarded as a sign of instrumental commitment. The MT core team did not have any authority to make the required decisions regarding MT development and the team members were tied to other duties – which can be seen as

Page 106: The role of commitment in software process improvement - Oulu

104

structural drivers decreasing the commitment toward MT development. However, although no management involvement was apparent, the management had indeed communicated their expectations – which can be seen as a social driver exerting an increasing effect on commitment development. As a result, the dominating form of commitment is of normative kind. The pilot team, on the other hand, did not show any form of commitment toward the development of MT practices, since no one really expected it from them. The remaining actors, i.e. the SPI department and, at the individual level, the MT power users and the SPI project manager, all exhibited normative commitment toward MT development. The SPI project manager’s form of commitment can be interpreted to have changed from affective to normative due to several reasons. At the beginning of the project he truly wanted to solve MT problems and saw that SPI actions would yield new opportunities. However, as the SPI actions progressed, little positive feedback was received. Practically none of the other participating actors wanted to share the responsibility for solving the common problem everyone seemed to acknowledge.

6.3.1.3 Closure phase

Company B went through a major organizational restructuring during the second part of the twelve-month period. The SPI Project manager responded to the case description narrative by placing emphasis on the major impact that the reorganization had on the SPI actions. In his view, organizational restructuring had a destructive effect on the development of MT practices. He noted that in the new organization there were even fewer MT practice developers than before. When studying the outcomes of the actions, similar conclusions can be drawn, since only SPI actions #1 and #5 produced outcomes that had a longer-term impact on the organization. However, although the pilot project (#5) did not manage to test any MT tools, it did manage to evaluate the performance capability of the object-oriented technology, which was their driving concern. What was unforeseen and thus unplanned, was the use of the results from SPI actions #1, #3 and #6 in the new organization mode, when a new initiative for test process improvement was being planned. This, however, falls beyond the scope of this analysis since the initiative did not begin within the time limits set for the data gathering of this thesis.

As a result of one year’s effort, some concrete advancements were made. The SPI project manager developed a common MT process and revised the module testing instructions and templates for different platforms. However, due to the changes in the organization, no roll out with adequate training was managed. The resulting documents were entered in a document database with public access. However, these advancements were made only due to the fact that the SPI project manager had taken the responsibility for preparing draft versions of the documents. The underlying core problem remained intact: systematic MT practice improvement on the new operating platform and software paradigm. The infrastructure created to support ongoing development efforts did not survive beyond the initial efforts.

Organizational restructuring, which is a structural driver, had a decreasing effect on commitment toward MT development at all actor levels. The MT core group was

Page 107: The role of commitment in software process improvement - Oulu

105

dissolved and MT power users were no longer supported after the organizational change. At present, the SPI department still has responsibility for MT development.

Page 108: The role of commitment in software process improvement - Oulu

Tabl

e 21

.Cas

e2:

Com

mit

men

tsre

flect

ing

the

prog

ress

ofth

eim

prov

emen

tpro

ject

.

Out

com

es#

Act

orC

once

rnA

ctio

nsIn

tend

edU

nint

ende

d

1In

tern

algr

oup:

Soft

war

epr

ojec

t,

SPI

depa

rtm

ent

MT

inst

ruct

ions

outd

ated

Dev

elop

com

mon

MT

proc

ess

and

inst

ruct

ions

Com

mon

MT

pro

cess

def

ined

, MT

inst

ruct

ions

rev

ised

, MT

rep

ortin

g

prac

tice

rede

fine

d

Inpu

t pro

vide

d fo

r a

larg

er te

st

proc

ess

impr

ovem

ent i

nitia

tive

laun

ched

in th

e ne

w o

rgan

izat

ion

mod

e.

2In

tern

algr

oup:

SPI

depa

rtm

ent

Inab

ility

to p

rovi

de

adeq

uate

sup

port

Def

ine

new

rol

es a

nd

resp

onsi

bilit

ies

MT

Pow

er U

ser

allo

cate

d in

eac

h

soft

war

e de

velo

pmen

t tea

m, M

T C

ore

Tea

m e

stab

lishe

d

Cha

nge

perc

eive

d as

non

-cha

nge

(i.e

. rol

es h

ad e

xist

ed a

lso

prev

ious

ly w

ith

diff

eren

t nam

es).

3In

tern

algr

oup:

SPI

depa

rtm

ent,

soft

war

epr

ojec

ts

Feas

ibili

ty o

f ne

w

tool

Eva

luat

e ne

w M

T to

ol

Not

ach

ieve

d, a

ctio

n w

ithdr

awn

Req

uire

men

ts f

or to

ol a

cqui

sitio

n

proc

edur

e.

4In

tern

algr

oup:

SPI

depa

rtm

ent,

MT

core

team

Una

war

enes

s of

curr

ent M

T s

tatu

s,

area

s fo

r

impr

ovem

ent

Dev

elop

and

dis

trib

ute

MT

ques

tionn

aire

57 r

espo

nses

gat

here

d, c

urre

nt s

tatu

s

clar

ifie

d, n

o fe

edba

ck b

ack

to p

roje

cts,

no a

ctio

n pl

an p

rodu

ced

Inpu

t pro

vide

d fo

r a

larg

er te

st

proc

ess

impr

ovem

ent i

nitia

tive

laun

ched

in th

e ne

w o

rgan

izat

ion

mod

e.

5Fo

calo

rgan

izat

ion:

Man

agem

ent

Inte

rnal

grou

p:Pi

lot

team

New

tech

nolo

gy

perf

orm

ance

capa

bilit

y

Perf

orm

pil

ot p

roje

ct o

n

new

tech

nolo

gy

Tw

o w

orki

ng in

crem

ents

pro

duce

d, n

o

MT

tool

s/m

etho

ds e

valu

ated

Proc

ess

depa

rtm

ent w

as u

nabl

e to

deliv

er th

e to

ols

nece

ssar

y fo

r th

e

pilo

t pro

ject

: req

uire

men

ts f

or

tool

acq

uisi

tion

proc

edur

e.

6In

tern

algr

oup:

SPI

depa

rtm

ent,

Ext

erna

lind

ivid

ual:

Res

earc

her

Mod

ule

test

ing

prac

tices

will

not

be

impr

oved

Hir

e an

out

side

res

earc

her

to e

valu

ate

reas

ons

for

the

little

pro

gres

s m

ade

12 in

-dep

th in

terv

iew

s pe

rfor

med

,

susp

ecte

d re

ason

s fo

r th

e pr

ogre

ss

wor

ked

out a

nd r

epor

ted

to p

roce

ss

depa

rtm

ent h

ead

and

MT

Cor

e T

eam

Inpu

t pro

vide

d fo

r a

larg

er te

st

proc

ess

impr

ovem

ent i

nitia

tive

laun

ched

in th

e ne

w o

rgan

izat

ion

mod

e.

Page 109: The role of commitment in software process improvement - Oulu

6.3.2 Empirical conclusions

In this final section of the analysis, the commitment process is depicted as it developed over the three SPI phases and the change achieved in respective actors’ commitment net is described.

6.3.2.1 Commitment process

Even though great expectations were entertained for the SPI actions attempting to solve module testing problems, the results were not far reaching. The new product development practices on the new object-oriented platform required the adoption of new software development practices. Thus, the structural drivers forming the environment for SPI actions dominated both strategic and operational commitment nets. Based on personal experience, software projects had found out that module testing was difficult and time consuming. While the actions taken were producing outcomes, the organizational restructuring caused many of them to diminish their value. Thus, the structural drivers that gave rise to the need for the module testing process improvement also caused a decrease in commitment by changing the operating environment. Table 22 presents the change in commitment drivers in case 2 for the main actor groups: Strategic (focal organization management), operational (SW projects, SPI department) and personal (SPI project manager). This case evidences, again, that different commitment drivers contribute to the development of different forms of commitment. The dominating forms of commitment in this SPI project were of normative and instrumental kind, with one occurrence of the continuance and one of the affective type.

Page 110: The role of commitment in software process improvement - Oulu

108

Table 22. Case 2: Commitment process in the SPI project.

Initiation Operation (#1 - #6) Closure Commitment Nets Drivers C-form Drivers C-form Drivers C-form

Strategic Struct.(+)

NC

Psych. (-)

Project (+)

CC

Struct. (-)

NC

Operational (SW

projects)

Psych. (+)

Struct. (+) IC

Social (+)

Project (-)

IC

Struct. (-) None

Operational (SPI

dept.)

Psych. (+)

Struct. (+)

Project (+) NC

Struct. (+)

Social (-)

NC

Struct. (-) NC

Personal (SPI

project manager)

Psych. (+)

Social (+)

AC

Psych (+)

NC

Struct. (-)

NC

6.3.2.2 Change achieved

While the target of the SPI initiative was to change the module testing practices of software projects, this was not achieved within the 12-month period. However, whereas in case one the commitment net of the management contained a clear concern about usability issues, no indication of such a concern for module testing development is revealed by studying the open-ended interviews concerning the commitment net of the focal organization management in this case (Table 22).

The only concern that indirectly relates to module testing development is the one about the efficiency of new technology. SPI action #5 involved actions to match this concern. The management followed up the project closely. Weekly “news flashes” were delivered to a larger body of audience. The management communicated their expectations clearly. In addition to the performance evaluation, however, also the module testing tools, methods and processes should have been piloted. The pilot team managed to produce two working increments, thus achieving their most important goal. However, they failed to solve any of the issues related to module testing, even though an additional dedicated resource was included in the pilot at a later stage to tackle specifically this problem, which, again, can be considered a sign of increased commitment. Yet, the pilot team is not to blame for this, as it was the SPI department that was not able to deliver the platform, tools and methods needed for testing within the time limits of the pilot project. This was also partially caused by problems with tool vendors (i.e. unacceptable licensing rules).

It was the commitment net of the SPI department that did show concern about the development of module testing practices. There was an attempt to transfer this concern for software projects by defining new roles (SPI action #2). As stated earlier in the analysis, this transfer was not successful due to the perception that there was, essentially, nothing

Page 111: The role of commitment in software process improvement - Oulu

109

new to this role and due to the fact that there was no willingness to take over the responsibility from the SPI department.

Page 112: The role of commitment in software process improvement - Oulu

Tabl

e 23

.Cas

e 2

– Fo

cal o

rgan

izat

ion:

Man

agem

ent’

s co

mm

itmen

t net

.

Out

com

esD

rive

rsC

once

rns

Act

ions

Inte

nded

Uni

nten

ded

His

tori

cal d

evel

opm

ent

“G

ivin

g up

old

wor

ld, m

ovin

g to

new

wor

ld”

Org

aniz

atio

n’s

stat

e of

will

Prob

lem

s w

ith s

elf-

deve

lope

d to

ols

Tec

hnol

ogic

al a

dvan

cem

ents

Part

neri

ng, s

ubco

ntra

ctin

g an

d

outs

ourc

ing

pres

sure

s

Bel

iefs

Em

erge

d te

chno

logy

, ris

ks a

ssoc

iate

d

Mak

e su

re p

roje

cts

stay

on

sche

dule

Prod

uce

a pr

oduc

t tha

t can

be

furt

her

deve

lope

d

Use

of

com

mer

cial

ly d

evel

oped

met

hods

/tool

s

Con

cent

ratio

n on

cor

e co

mpe

tenc

e

Qua

lity

requ

irem

ent:

Dow

n-tim

e/ye

ar

To

have

rig

ht p

eopl

e in

rig

ht p

roje

cts

Inte

rnal

fre

e re

crui

tmen

t

Und

erst

andi

ng th

e ne

w te

chno

logy

(m

aint

aini

ng

pers

onal

com

pete

nce)

Mai

ntai

ning

trus

t and

aut

hori

ty

Ach

ieve

’en

ough

’ qu

ality

Perf

orm

ance

eff

icie

ncy

of n

ew te

chno

logy

Mak

e m

anag

emen

t dec

isio

ns

Stra

tegy

for

mat

ion

Vis

ion

form

atio

n

Part

icip

ate

in p

rodu

ct r

elat

ed s

teer

ing

grou

p m

eetin

gs

Hol

d pe

rson

nel d

iscu

ssio

ns

Follo

w u

p pr

ogre

ss

Mak

e re

sour

ce d

ecis

ions

Rec

ruitm

ent p

olic

y

Han

dle

resi

stan

ce

Ow

n co

mpe

tenc

e m

aint

enan

ce a

nd

deve

lopm

ent

Com

mun

icat

e ex

pect

atio

ns

Exp

ecta

tions

clea

r: T

est

proc

ess

auto

mat

ion

Mod

ule

test

ing

was

prio

ritiz

ed

low

er [

than

othe

r ph

ases

]

Page 113: The role of commitment in software process improvement - Oulu

The module testing improvement effort lacked personnel dedicated to developing practices. The software projects had a clear view on the process department’s role in this matter. It was up to the commitment net of the process department to solve these types of problems. Software projects wanted packaged support, including the tools, methods and processes needed for each separate environment. The process department was aware of this, but was not able to deliver any support of the kind, since it was understaffed due to an increased number of software projects and operating environments. Thus, the improvement strategies employed did not succeed in altering the software projects commitment net. Thus, no commitment to SPI was achieved apart from the SPI department. A software designer clarified this by stating:

“Yes, but there is no such [module testing development] in the project [plan]. At least, as of yet it hasn’t. It is stated [in the project plan] that the [cycle] time must be reduced. Probably something like that.” [Software designer, interview]

Thus, software projects are constrained by the project plan. Their dominating concern is to meet the requirements stated in the plan. Other issues are treated as secondary. Table 24 summarizes the extent of change achieved in commitment nets at strategic and operational levels.

Table 24. Change achieved in actors’ commitment nets.

Commitment Net

Target actor SPI outcome (Impact on the customer)

Evidence

Strategic Focal

organization:

Management

No concern about module testing

was developed. In their opinion, it

was up to the SPI department to

develop module test processes.

Strategic commitment net does not

contain any concern about MT

development.

Operational Internal group:

Software

projects

No concern about module testing

was developed. In their opinion,

SPI department should be

developing module test processes.

Reluctance to participate in MT

development, new roles lost their

significance in the new

organizational structure.

6.4 Case 3: Improve geographically distributed software development

Company B develops software simultaneously in different locations around the world. In spring 2000, one of the distributed software development projects faced serious problems with the project management. The management had decided that there was an urgent need for an effort to develop guidelines, rules, roles and responsibilities on how to operate in a multi site environment. In specific, the target of the SPI project was to identify in detail what were the true problems, to propose an action plan regarding how these problems would be solved, and finally to solve the problems. There are five actor groups participating in this initiative: the focal organization management and the global SPI department at the strategic level, the software projects and the local SPI department at the operational level, and the software project managers at the personal level.

Page 114: The role of commitment in software process improvement - Oulu

112

6.4.1 Longitudinal analysis of commitment nets

The SPI project included five identifiable actions, which are shown in Table 28. In what follows, each project phase is analyzed separately and the drivers affecting commitment development are identified.

6.4.1.1 Initiation phase

The SPI project was prioritized high as it was included in the site level strategies of Company B. Thus, the project was included in the management incentives of the focal organization. The SPI project was established and it enjoyed a wide support from senior management down to project level. The improvement strategy included a current status assessment through a series of interviews with people at different levels in the organization to find out what the main problems to be solved were. The SPI department saw that it was no use developing guidelines unless all key stakeholders’ opinions are carefully taken into consideration. The SPI department acknowledged that the scope of the improvement effort was very wide. All real problems, however, would be tackled. A workshop was planned to present the results of the assessment, after which improvement targets were to be organized in work packages.

The strategic commitment net was altered, which is indicated by the fact that the managerial incentive structure (SPI action #1) held elements connected with this SPI project. Also, the focal organization managers were willing to sponsor the project even if the global SPI department would oppose. The data does not, however, reveal what the means were that were used to achieve this.

The findings of the assessment (SPI action #2) suggested that it was the communication mechanisms that was the most important aspect in multi site operation. The multi site organization, project planning, expertise transfer, and technical problems, such as configuration management, were acknowledged as potential factors undermining the efficiency of product development in a multi site environment. Based on the results from the assessment, the SPI project manager developed a set of draft guidelines, which were to be further developed in a workshop. The SPI project manager had collected experienced people for the project team which would participate in the workshops. The SPI project manager had explicitly picked up staff that wanted to participate in this effort. Therefore, all the key individuals were personally asked about how much time they were willing to invest in this effort. Another selection criterion for these people was that they were the ones who had actually faced problems typical of multi site development.

The level of impact initially concerned personal level commitment nets. The persons involved included project managers who, in this organization, had control over the practices which were followed in their project. Thus, they were able to influence their immediate operational commitment nets. These project managers all shared a concern about working out guidelines for multi site software development. This concern arose from their own experiences as multi site project managers.

Table 25 indicates the drivers for the SPI project in the initiation phase. As is indicated by the table, the project was needed and also supported. All the drivers identified had an

Page 115: The role of commitment in software process improvement - Oulu

113

increasing effect on the actors’ commitment development toward the SPI project. In this case, the focal organization management directing the strategic commitment net showed an affective form of commitment to the SPI project. This was indicated by their decision to sponsor the project even if the global SPI department was not willing to do this. At the operational level, two internal groups involved, the software projects and the local SPI department, were affectively and normatively committed to solving multi site operation issues. The goals of the SPI project indicated that their actual problems would be solved, which was an objective project driver exerting a positive effect on the commitment development of software projects. Finally, at the personal level, the software project managers were each asked personally whether they wanted to participate and only those that voicing their interest were included in the initiative. Thus, it was likely that an affective form of commitment dominated their commitment development.

Table 25. Commitment drivers in the initiation phase.

Commitment net level

Actor Driver Type Commitment form

Strategic Focal

organization:

Management

Coordination and management

problems in recent distributed

software projects, more and more

software is being developed in a

distributed environment in the future

Managerial incentives tied to this

project.

Social (+)

Psych. (+)

Affective

Internal

group:

Software

projects

Coordination and management

problems in recent distributed

software project.

Software project managers involved

in the diagnosis state

Project (+)

Psych. (+)

Affective Operational

Internal

group:

Process

department

Lack of resources for supporting

external sites

Need to coordinate support practices

in globally distributed software

development

Social (+)

Project (+)

Normative

Personal Internal

individual:

SW project

manager

Coordination and management

problems in recent distributed

software project.

Project (+) Affective

Page 116: The role of commitment in software process improvement - Oulu

114

6.4.1.2 Operation phase

The operation phase of the SPI project includes items #3 and #4, as presented in Table 28.

#4 Workshop for training and action planning

The planned workshop was initially cancelled, because the project managers (that had problems in their multi site projects) had withdrawn from the participant list. The SPI project manager indicated that this type of work was often seen as extra effort. Thus, while a concern for the improvement existed, no actions that would map this concern were apparent at a personal level. Using the notion of commitment as applied in this thesis, no commitment had been generated toward the SPI project, even if it was identified in the initiation phase.

The workshop (SPI action #3) was held a few months later. The SPI project manager was planning to generate discussions that would enable the project managers to gain something concrete and practical that they could use immediately in their own projects. The initial workshop organization involved separate workgroups addressing important issues during a two-day meeting and then agreeing upon an action plan that had initially been developed by the SPI project manager. However, after the preliminary ideas were introduced, a debate followed in which some of the participants started to question the goals set for the workshop, raising doubts whether this sort of improvement effort was truly beneficial. As a result of a lot of discussion, little concrete advancement was achieved.

#4 Action package development

The SPI project manager subsequently divided the scope of the SPI project into seven distinct work packages (SPI action #4). Each work package comprised a separate problem to be solved. These work packages included deployment of virtual organization practices, development of generic support practices, development of multi site project management guidelines along with development of configuration management practices.

Table 26 summarizes the commitment drivers in the project operation phase. Despite the need for this initiative and the successful initiation phase, only the SPI department could be interpreted to have shown any form of commitment toward the SPI project in the project operation phase. Their interest was primarily driven by the existence of other duties that were more important to the management, the software projects and the participating software project managers.

Page 117: The role of commitment in software process improvement - Oulu

115

Table 26. Commitment drivers in the operation phase.

Commitment net level

Actor Driver Type Commitment form

Strategic Focal

organization:

Management

Existence of other more important

duties -> no participation in the

workshop

Struct. (-) None

Internal

group:

Software

projects

Inability to agree upon improvement

targets

Social (-) None Operational

Internal

group: SPI

department

Inability to agree upon improvement

targets

Social (-) Normative

Personal Internal

individual:

SW project

manager

Existence of other more important

duties

Inability to agree upon improvement

targets

Struct. (-)

Social (-)

None

6.4.1.3 Closure phase

As was witnessed in the analysis of case 2, case company B underwent a major organizational change during that time. As a result, all ongoing SPI initiatives were re-evaluated (SPI action #5) and the global SPI department decided that this project should be put on hold for then. The scarce improvement resources would be spent where they were more urgently needed. This change in strategic commitment net was made based on a concern to continue those SPI projects that would bring most value to the business unit as a whole. The SPI project under analysis was targeted on one technology area within a newly formed business unit. As a result of the decision to put the SPI project on hold, the resources assigned to the development of multi site software development practices were drawn away and retargeted. Table 27 summarizes the drivers and commitment forms in the project closure phase. No commitment to the SPI project or to the concerns involved can be identified when the decision was made to terminate the initiative.

Page 118: The role of commitment in software process improvement - Oulu

116

Table 27. Commitment drivers in the closure phase.

Commitment net level

Actor Driver Type Commitment form

Strategic Focal

organization:

Global SPI

department

Organizational restructuring:

Resources should be spent where

they are most urgently needed in the

new business unit, harmonization of

all SPI activities

Struct. (-) None

Internal

group:

Software

projects

Organizational restructuring:

Problems did not go away, no unified

solution is searched, each project

tackles problems themselves

Struct. (-) None Operational

Internal

group: SPI

department

Organizational restructuring: Due to

the global SPI department decision,

resources are targeted to other

activities.

Struct. (-) None

Personal Internal

individual:

SW project

managers

Organizational restructuring:

Problems are solved on a project-to-

project basis

Struct. (-) None

Page 119: The role of commitment in software process improvement - Oulu

Tabl

e 28

.Cas

e3:

Com

mit

men

tsre

flect

ing

the

prog

ress

ofim

prov

emen

tpro

ject

.

Out

com

es#

SPIp

hase

Act

orC

once

rnA

ctio

nsIn

tend

edU

nint

ende

d

1In

itia

tion

:

Est

abli

shm

ent

Inte

rnal

grou

p:

SPI

depa

rtm

ent

Ens

ure

the

man

ager

iali

nter

est

Incl

ude

the

goal

sof

the

SPI

proj

ecti

nth

e

man

ager

iali

ncen

tive

s

Man

agem

ents

uppo

rted

and

part

icip

ated

inth

e

proj

ect

Proj

ect

face

dea

rly

diff

icul

ties

inen

suri

ng

glob

alS

PIde

part

men

t

fund

ing

2In

itia

tion

:

Cur

rent

stat

e

diag

nosi

s

Inte

rnal

grou

p:

SPI

depa

rtm

ent

Invo

lve

asm

any

peop

leas

poss

ible

in

the

proc

ess,

unaw

aren

ess

ofcu

rren

t

stat

usin

term

sof

prob

lem

san

d

solu

tion

s

Inte

rvie

wal

lrel

evan

t

stak

ehol

ders

Com

mon

prob

lem

s

iden

tifi

ed,a

llre

leva

nt

stak

ehol

ders

had

thei

rsa

y

onth

esu

bjec

tmat

ter

Prob

lem

sw

ere

unex

pect

edly

foun

dat

diff

eren

tlev

els,

from

com

mun

icat

ion

to

tech

nica

l.

3O

pera

tion

:

Act

ing

Inte

rnal

grou

p:

SPI

depa

rtm

ent,

soft

war

epr

ojec

ts

Foca

l

orga

niza

tion

:

Man

agem

ent

Bri

ngab

outa

war

enes

sof

mul

tisi

te

soft

war

ede

velo

pmen

tpro

blem

s,ne

edto

tack

leri

ghti

ssue

sfi

rst

Org

aniz

ea

wor

ksho

p

for

trai

ning

and

subs

eque

nt a

ctio

n

plan

ning

Litt

leco

ncre

te

adva

ncem

ents

mad

e

Dis

cuss

ions

ofth

e

usef

ulne

ssof

the

SPI

proj

ect,

slow

eddo

wn

the

prog

ress

ofSP

Ipr

ojec

t

4O

pera

tion

:

Act

ing

Inte

rnal

grou

p:

SPI

depa

rtm

ent

Use

find

ings

from

the

asse

ssm

entt

o

impr

ove

the

curr

entp

ract

ice

Def

ine

wor

kpa

ckag

esW

ork

pack

ages

defi

ned

Due

toSP

Iac

tion

#5

defi

ned

wor

kpa

ckag

es

wer

eno

tope

rati

onal

ized

aspl

anne

d

5C

losu

re:

Lea

rnin

g

Foca

l

orga

niza

tion

:

Glo

balS

PI

depa

rtm

ent

Mai

ntai

nco

ntro

love

ral

lSPI

init

iati

ves

glob

ally

,inv

estr

esou

rces

whe

reth

eyar

e

mos

turg

entl

yne

eded

(i.e

.inv

esti

n

init

iati

ves

that

brin

gth

em

ostv

alue

to

who

lene

wly

form

edbu

sine

ssun

it)

Ter

min

ate

the

impr

ovem

enti

niti

ativ

e

Proj

ect

was

fini

shed

Prob

lem

sin

mul

tisi

te

soft

war

ede

velo

pmen

t

have

tobe

solv

edon

proj

ect-

to-p

roje

ctba

sis

Page 120: The role of commitment in software process improvement - Oulu

118

6.4.2 Empirical conclusions

In this final section of the analysis, the commitment process is depicted as it developed over the three SPI phases, and the change achieved in actors’ commitment net is described.

6.4.2.1 Commitment process

As stated above, there were problems in the multi site operation and the urgency of this type of improvement effort was widely recognized. However, the new organizational structure presented other challenges for software development to be tackled by the software process department. Thus, the project was given a no-go decision after six months in operation. Table 29 presents the commitment process in the SPI project. This case is significantly different from the first two analyzed, since it shows how commitment to the SPI project was systematically reduced over the three phases. At the strategic level, for the first time, a form of affective commitment was identified. However, this commitment, the strongest form of commitment, was reduced to no commitment in only a matter of months, indicating that affective commitment shown by an organization is not likely to ensure any continuity for an SPI project. A similar change was witnessed at the individual level, where the participating project managers wanted to participate and contribute to the development of multi site operating practices, but eventually failed to do so. Other duties, such as their projects, proved more important.

Table 29. Case 3: Commitment process in the SPI project.

Initiation (#1, #2) Operation (#3, #4) Closure (#5) Commitment Nets Drivers C-form Drivers C-form Drivers C-form

Strategic Social (+)

Project (+) AC

Struct. (-)

None

Struct. (-)

None

Operational (SW

projects)

Social (+)

Psych. (+) NC

Social (-)

None

Struct. (-)

None

Operational (SPI

department)

Social (+)

Project (+) NC

Social (-) NC

Struct. (-) None

Personal (SW

project managers)

Project (+)

AC

Social (-)

Struct (-)

None

Struct. (-)

None

Page 121: The role of commitment in software process improvement - Oulu

119

6.4.2.2 Change achieved

The SPI project was urgently needed for solving the problems faced in the latest software development projects carried out in a geographically distributed environment. Although this concern was widely shared, the project managers would rely on the SPI department to come up with a solution, even if the managers had personally encountered the problems. At that time, they did not agree on the action plan or the task prioritization that the SPI department had initially produced on the basis of an assessment. A decisive factor in the process came, however, from the outside. A new organizational structure brought pressure on the global SPI department to serve widely all software development units. This resulted in a decision to terminate the SPI project. Table 30 summarizes the extent of change achieved in commitment nets at strategic, operational and individual level.

Table 30. Change achieved in actors’ commitment nets.

Commitment Net

Target actor SPI outcome (Impact on the customer)

Evidence

Strategic Organization:

Management

Concern about multi site software

development still exists, but its

importance has diminished.

Decision to terminate the

improvement project.

Operational Group:

Software

projects

Projects keep solving multi site

problems case by case. Concern

continues to exist – actions are

missing.

Project was terminated before

work packages were implemented.

Personal Individual:

Project

managers

Project managers had the concern

for multi site operation based on

their extensive experience.

However, they relied mainly on

the process department to solve the

problem.

Little personal involvement

throughout the SPI project,

withdrawal from workshop

participant list due to project tasks

In the first two cases, the problem was related to the non-existence of an appropriate concern for the SPI project. This case has demonstrated that it is not enough for the commitment to develop if there is only a concern about the improvement. Although the problems with multi site operation were identified and found relevant, the organizational restructuring caused a need to re-evaluate these problems in line with the others. As a result, the problem remained unsolved.

6.5 Case 4: Improving software process improvement processes

While case company B operates in a number of different sites around the world, the local SPI department in each site coordinates the support for the software projects through an appointed support person(s). The number of projects to be supported has tripled in a few years and the support effort has become inefficient due to a lack of resources. One of the

Page 122: The role of commitment in software process improvement - Oulu

120

sites had piloted a new approach to organizing support in a systematic manner. Since the pilot experiences were good, a systematic preparation to spread the new SPI practice over to four other sites was initiated. The participating actors to the SPI project were the SPI department, the global SPI department, the organization’s top management and the software projects in each participating site. In this case, the SPI project manager did not participate in the actual operation phase, but controlled the overall progress of the initiative.

6.5.1 Longitudinal analysis of commitment nets

Case 4 improved SPI and software quality assurance (SQA) processes through the establishment of a new support structure and by using CMM as the backbone for discovering improvement items in software projects. The two main concerns for the SPI project can be identified: software production capability and collaboration with the SPI department. The concern for software production capability is connected with the use of CMM, while the collaboration with the SPI department is connected with the new support structure. The global SPI department launched the SPI project in January 2001 with five participating sites with their own specific timetables according to their needs and demands. This timetable included a set of defined activities for the year. The original aim was to have an official CMM assessment by December 2001. Projects would be prepared to that assessment using the systematic support structure.

At each site, the SPI project was introduced to a number of project managers. Then, these project managers decided on a volunteer basis whether they wanted to participate in the SPI project. After one to three projects from one site had agreed to participate, the dates were set for CMM training and a light self-assessment session. After the two-day training session, a systematic support structure called “change engine” would start running so that once in every two weeks there would be a progress meeting. Periodically, a light CMM assessment would be carried out to evaluate further improvement items. Table 34 presents the SPI project using the commitment net typology.

6.5.1.1 Initiation phase

The initiation phase included the establishment and the current state diagnosis activities, items #1 through #4 in Table 34. Cases 2 and 3 have shown that case company B underwent a large organizational restructuring, which influenced the outcome in both cases. In case 4, a careful planning of the project (SPI action #1) took several months. Special attention was paid to ensuring the funding for the project in the newly formedbusiness unit. The organization required that all software development units should meetthe requirements of the CMM level two at the minimum. This SPI project was targeted sothat each participating software project would reach this level. Thus, these were structuraldrivers that facilitated ensuring the funding for the SPI project. Also, the visibility of thesoftware projects was increased in terms of process issues. This was a project driver thatincreased strategic commitment toward the SPI project. In addition, this SPI project was

Page 123: The role of commitment in software process improvement - Oulu

121

the first to be initiated after the organizational change. Thus, it was carefully monitoredby the global SPI department.

In order to ensure the readiness of the site for the project, the SPI project managernegotiated resources for the SPI project in all sites including a list of candidate projectsthat could become part of the project (SPI action #3). As a result, all the sites hadpersonnel appointed to the roles required by the SPI project approach. An SPI projectpresentation was held, which was also attended to by the candidate project managers.After the facts about the project were introduced, project managers made their individualdecision about whether their project would participate in the SPI project. Theparticipation was strictly on a voluntary basis. However, the mere act of showing up atthe SPI project presentation was likely to increase the social pressure to participate. As aresult, each site had 1 to 3 projects volunteering for participation in the SPI project.

A current state diagnosis was arranged in a two-day kick-off session, where thesoftware projects were educated in CMM and a light assessment was performed toidentify improvement areas and concrete action points (SPI action #4). This was achievedin all sites. In one site, the schedule had to be delayed by three months due to an intensephase in a software project.

Thus, while the software projects agreed that support practices were inefficient they had become used to it. The software projects had learned how to solve problems as they arose without the help of the SPI department. Therefore, this can be interpreted so that regular project work had a negative effect on the commitment of software projects to the SPI project in the initiation phase.

Table 31 shows the commitment drivers affecting the actors’ commitment toward the SPI project in the initiation phase. In this project, the strategic commitment net is directed by the global SPI department, which ensures funding for the SPI project. This project was the first SPI project to be launched after the organizational change. Thus, it was followed intensely. Several drivers had a positive effect on the development of affective commitment. The SPI project was seen to yield extremely positive results as regards confirming the CMM requirements. Through the SPI project, the process problems of the software projects involved will be common knowledge, since the progress is reported every two weeks. At the operational level, the software projects had faced problems with inadequate support from the SPI department. They had realized that quite many of the technical problems and management issues arose rather late during the projects. These are project drivers affecting positively to the commitment development. In general, the dominating form of commitment in the software project initiation phase was normative. The SPI department was also normatively committed to the SPI project due to the urgent need to solve support problems.

Page 124: The role of commitment in software process improvement - Oulu

122

Table 31. Commitment net drivers in the initiation phase.

Commitment net level

Actor Driver Type Commitment form

Strategic Focal

organization:

Global SPI

department

Organization’s standard requires

projects to be at CMM level 2

Increase projects visibility in terms

of process issues

Extensive preparation time for the

initiative, first SPI project after the

organizational change

Struct. (+)

Project (+)

Psych. (+)

Affective

Internal

group:

Software

projects

Current support was inadequate,

prevent problems from arising late in

the project

Act of participation to the kick-off

session

Regular project work

Project (+)

Social (+)

Struct. (-)

Normative Operational

Internal

group: SPI

department

Problems with existing way of

providing support for the project.

Proactive problem solving rather

than fire fighting

Increase visibility of project

problems

Social (+)

Project (+)

Normative

6.5.1.2 Operation phase

The operation phase includes items #5 - #8 in Table 34.

#5 Organize change engine meetings

The SPI approach to be implemented was similar to Isacsson and the others (2001): The process development responsibility is moved away from the SPI department to the software projects themselves. The software projects map themselves to the CMM framework, prioritize and plan the action points needed, and allocate resources to solving the most important problems. The progress of the SPI effort is then followed through the accomplishment of the generated action points. The project manager is in full control of his project and decides, together with the project staff, which improvements are to be made. The systematic support structure also requires an external mentor helping the project manager to plan the action points and a process specialist from the SPI department periodically meeting together with the project manager to oversee the progress. The project manager’s immediate manager is also involved once a month to evaluate the progress. The immediate manager may also be allocated action points if such should appear.

One of the underlying ideas is to maintain a continuous momentum so that once in every two weeks something concrete happens. The purpose of this is to help project

Page 125: The role of commitment in software process improvement - Oulu

123

managers develop a sense of concern for the SPI project and for the action points derived from the periodic CMM self-assessment. This approach was implemented as planned and clear progress was made in each site through the change engine meetings (SPI action #5). This means that a number of action points were identified and consequently some of them solved. There were, however, some problems, too. The software project managers wanted to postpone the meetings when they had not made progress concerning the action points they had defined. In those cases, the process specialist from the SPI department insisted that the meeting should be held as planned. In most cases, this also happened. This shows that a periodic progress meeting increases the pressure on the software projects to act upon the issues they have decided to treat, which can be considered a form of continuing normative commitment toward the SPI project. The other problems faced concerned, e.g., the explicit use of CMM terminology, since some software project managers had had poor experiences with a CMM assessment held years ago.

#6 Business decision - 1

The first severe problem was caused by a top management decision to redirect a software development project (#6). While the improvement effort was targeted on the software project level, the SPI project was also terminated in this site. A change in the environment where the SPI actions were performed – a structural driver – again worked to decrease (or actually terminate) the commitment toward the SPI project regardless of lower level actors’ commitment status as indicated in the following. In this particular site, the software project manager commented on this as follows:

“I am really disappointed that the […] SW project was cancelled because I saw improvements due to [the participation in the SPI project]. Maybe some other time…” [Software project manager, email]

#7 Reduce project’s scope

Due to the slowness of the progress, the global SPI management decided to cut the SPI project budget to less than a half of what was originally planned. This was done by cutting off the official CMM assessment that would have been the final action of the SPI project. The SPI project manager supported the decision since it had already became clear what was the current status of all operating software projects in terms of their CMM levels.

#8 Business decision - 2

Finally, another top management decision to redirect the activities of one site caused the third major problem. The problem was due to the fact that the participation in all global activities was seized on the day the decision was made official. The SPI project manager was physically working in that site and there was an imminent danger of the whole SPI project being terminated despite the progress made.

Table 32 shows the commitment drivers in the operation phase. By and large, progress was made, although there still were drivers working to decrease commitment toward the SPI project. Top management decisions, which can be seen as structural drivers, caused the global SPI department to reconsider the actions of the specific SPI project. At the operational level, the software projects were identifying and solving the action points, but

Page 126: The role of commitment in software process improvement - Oulu

124

were not fully satisfied with the new approach. The software projects had other concerns, e.g. technical problems in the projects, which would divert their attention from the SPI projects. This is a psychological driver, since it is related to the importance of the SPI project, which was not very high even if it helped them in some regards.

Table 32. Commitment drivers in the operation phase.

Commitment net level

Actor Driver Type Commitment form

Strategic Focal

organization:

Global SPI

department

Top management decisions

Progress slower than expected, costs

and benefits in the project unbalanced

Struct. (-)

Project (-)

Instrumental

Internal

group:

Software

projects

Management involvement in change

engines, concrete actions every two

weeks

The existence of other concerns

Social (+)

Psych. (-)

Normative Operational

Internal

group: SPI

department

Top management decisions

Slow progress

Struct. (-)

Psych. (-)

Continuance

6.5.1.3 Closure phase

The closure phase includes item #9 in Table 34. In the changed situation, the global SPI department did not want to terminate the project, but rather redirect it to capturing improvement items globally. The infrastructure was in place to perform CMM assessments at each site. Thus, the original intent of the project, i.e. the implementation of a new SPI approach, was forgotten. No plans were made to continue with the new support structure. Thus, the change engines fell, evidently, apart. In one site, however, a decision was made to continue the change engine meetings ‘unofficially’ because they had gotten used to the idea. Table 33 shows the drivers and commitment forms in the closure phase. The global SPI department made a decision to continue the SPI project although the situation had changed. They had invested quite a bit of money in this project and wanted to have some concrete results, which can be regarded as a sign of continuance commitment. The software projects were not involved in the decision making process, and they had just been practicing the new support structure for a period of few months. This was a psychological driver with a negative effect on their commitment development. The local SPI department was satisfied of not having the project terminated, even if it seemed so for a while. This, again, can be seen as a psychological driver affecting the commitment to evaluation activities positively. The local SPI staff had also invested a lot of effort in this project and wanted to gain some concrete benefit from it.

Page 127: The role of commitment in software process improvement - Oulu

125

Table 33. Commitment net drivers in the closure phase.

Commitment net level

Actor Driver Type Commitment form

Strategic Focal

organization:

Global SPI

department

Investment made in the SPI project Social (+) Continuance

Internal

group:

Software

projects

Not involved in deciding future actions Psych. (-) Normative Operational

Internal

group:

Process

department

Project was not terminated Psych. (+) Continuance

Page 128: The role of commitment in software process improvement - Oulu

Tabl

e 34

.Cas

e4:

Com

mit

men

tsre

flect

ing

the

prog

ress

ofim

prov

emen

tpro

ject

.

Out

com

es#

SPIp

hase

Act

orC

once

rnA

ctio

nsIn

tend

edU

nint

ende

d

1In

itia

tion

:

Est

abli

shm

ent

Inte

rnal

grou

p:

SPI

depa

rtm

ent

To

have

prop

er

infr

astr

uctu

rere

ady

for

the

SPI

proj

ect

Prep

arat

ive

acti

ons:

Ens

ure

fund

ing

for

the

proj

ecti

n

new

lyfo

rmed

busi

ness

unit

,tra

in

proj

ectp

arti

cipa

nts

inC

MM

,

part

neri

ngw

ith

anou

tsid

em

ento

ring

orga

niza

tion

,pla

npr

ojec

tdet

ails

Proj

ectt

eam

esta

blis

hed

and

prep

ared

for

the

proj

ectl

aunc

h

SPI

proj

ectu

noff

icia

lly

nom

inat

edas

bein

ga

pilo

tin

new

lyfo

rmed

busi

ness

unit’

sgl

obal

proc

ess

engi

neer

ing

unit

2In

itia

tion

:

Est

abli

shm

ent

Inte

rnal

grou

p:

SPI

depa

rtm

ent

Ens

ure

site

read

ines

sfo

r

the

SPI

proj

ect

Neg

otia

tere

sour

ces

for

the

SPI

proj

ecti

nclu

ding

cand

idat

epr

ojec

ts

All

site

sha

dpe

rson

nel

appo

inte

dto

SPI

proj

ect

role

s

Dif

ficu

lties

mat

chin

gth

e

role

sre

quir

edby

the

norm

insi

teB

3In

itia

tion

:

Est

abli

shm

ent

Inte

rnal

grou

p:

SPI

depa

rtm

ent

To

have

volu

ntee

rpr

ojec

t

part

icip

atin

g

Org

aniz

eS

PIpr

ojec

tpre

sent

atio

nA

pres

enta

tion

was

deli

vere

dat

each

ofth

e

five

site

s:1-

3pr

ojec

tspe

r

site

volu

ntee

red

to

part

icip

ate

inth

epr

ojec

t

The

leve

lof

volu

ntee

rism

vari

ed,

SPI

Proj

ectw

asgi

ven

a

CM

Mla

belt

hath

inde

red

itsac

cept

ance

4In

itia

tion

:

Cur

rent

stat

e

diag

nosi

s

Inte

rnal

grou

p:

SPI

depa

rtm

ent

To

have

prop

er

impr

ovem

enti

tem

s

iden

tifi

edon

the

basi

sof

proj

ecta

ndC

MM

need

s

Org

aniz

eki

ck-o

ff:C

MM

-tra

inin

gan

d

self

-ass

essm

ent(

2da

ys)

Info

ursi

tes

kick

-off

sess

ion

was

held

as

plan

ned

Insi

teB

,kic

k-of

fse

ssio

n

was

shor

tene

dto

one

day

Insi

teB

,one

proj

ect

coul

dno

tpar

tici

pate

in

the

kick

-off

mee

ting

.

The

irpa

rtic

ipat

ion

inth

e

proj

ecth

adto

be

repl

anne

d.

5O

pera

tion

:

Act

ing

Inte

rnal

grou

p:

SPI

depa

rtm

ent,

soft

war

e

proj

ects

To

have

mom

entu

m,t

o

have

visi

bilit

yon

the

prog

ress

Org

aniz

ea

chan

geen

gine

mee

ting

ever

ytw

ow

eeks

Out

com

eva

ried

betw

een

soft

war

epr

ojec

tsan

dsi

tes.

Uni

nten

ded

outc

ome

vari

edbe

twee

nso

ftw

are

proj

ects

and

site

s.

Page 129: The role of commitment in software process improvement - Oulu

127

Out

com

es#

SPIp

hase

Act

orC

once

rnA

ctio

nsIn

tend

edU

nint

ende

d

6 O

pera

tion:

Act

ing

Foca

l

orga

niza

tion

:

Top

man

agem

ent

Org

aniz

atio

nalc

ost-

effi

cien

cy

Bus

ines

sde

cisi

on:R

edir

ecta

deve

lopm

entp

roje

ct

SPI

proj

ectw

aste

rmin

ated

inon

eof

the

part

icip

atin

g

site

s.

Thi

sw

asth

efi

rstl

arge

r

setb

ack

inth

eS

PI

proj

ect

->di

ffic

ulti

esin

acce

ptin

gth

eSP

Ipr

ojec

t

term

inat

ion

inth

issi

te.

7 O

pera

tion:

Act

ing

Foca

l

orga

niza

tion

:

Glo

balS

PI

depa

rtm

ent

Bal

ance

proj

ect’

sco

sts

wit

hbe

nefi

tsre

ceiv

ed

Red

uce

proj

ects

cope

:Cut

off

the

offi

cial

CM

Mas

sess

men

tpla

nned

to

behe

ldin

Dec

embe

r.

SPI

proj

ectp

lan

was

chan

ged.

Firs

tlar

ger

chan

geto

the

orig

inal

plan

.Str

ateg

ic

impo

rtan

cedi

min

ishe

s.

8 O

pera

tion:

Act

ing

Foca

l

orga

niza

tion

:

Top

man

agem

ent

Org

aniz

atio

nalc

ost-

effi

cien

cy

Bus

ines

sde

cisi

on:R

efoc

usac

tivi

ties

ofon

esi

te

SPI

proj

ectw

asre

dire

cted

glob

ally

Sinc

egl

obal

acti

viti

es

wer

efr

ozen

for

ape

riod

,

SPI

proj

ects

tatu

sw

as

uncl

ear

for

ash

ortp

erio

d

9 C

losu

re:

Lea

rnin

g

Foca

l

orga

niza

tion

:

Glo

balS

PI

depa

rtm

ent

Use

mon

eyan

dre

sour

ces

asef

fici

entl

yas

poss

ible

Har

ness

the

proj

ectt

oca

ptur

e

impr

ovem

enti

tem

sgl

obal

ly,

Hol

dC

MM

asse

ssm

ents

atea

chsi

te

Impr

ovem

enti

tem

s

succ

essf

ully

iden

tifi

edat

site

leve

l

The

role

ofch

ange

engi

nes

fade

d,no

acti

ons

plan

ned

tosu

ppor

tthe

acti

vity

stru

ctur

e

adop

ted.

Page 130: The role of commitment in software process improvement - Oulu

128

6.5.2 Empirical conclusions

In this final section of the analysis, the commitment process is depicted as it developed over the three SPI phases and the change achieved in actors’ commitment net is described.

6.5.2.1 Commitment process

Case four was loaded with high hopes by the global and local SPI departments. Historical success in using the new SPI approach in one of the sites was seen to be transformed to present success in a grand scale. The software projects were not that eager in participating but still 1-3 projects from five sites volunteered to the project. However, the problems faced in the operation phase and particularly the top management business decisions caused the SPI project to be redirected to a “mere” exploration of improvement areas globally.

Table 35 summarizes the changes in commitment drivers and forms of commitment in the SPI project. In this case, some form of commitment toward the SPI project can be identified in each phase. High hopes for the SPI project arose from the fact that the project showed all the possible types of drivers with a positive effect on the commitment development at all the investigated levels. The software projects, the most important actor in the SPI project, revealed normative commitment toward the SPI project as their dominating form of commitment. This remained unchanged even if it was the software project manager who together with the software project members, was in charge of identifying and agreeing upon the specific improvement actions to be made. The process issues that the SPI project brought to their attention through a series of light CMM assessments were not seen that important altogether. If the change engine meetings would have not been systematically pursued every two weeks, little change would have happened. The software projects realized that it was up to them to implement the improvements. This was not seen as a positive issue, after all. Thus, if the pressure had been taken away, the changes would not have happened.

Page 131: The role of commitment in software process improvement - Oulu

129

Table 35. Case 4: Commitment process in the SPI project.

Initiation (#1 - #4) Operation (#5 - #8) Closure (#9) Commitment Nets Drivers C-form Drivers C-form Drivers C-form

Strategic Struct. (+)

Project (+)

Psych. (+) AC

Struct. (-)

Project (-) IC

Social (+)

CC

Operational (SW

projects)

Project (+)

Social (+)

Struct. (+) NC

Social (+)

Psych. (-)

NC

Psych. (-)

NC

Operational

(process

department)

Social (+)

Project (+) NC

Struct. (-)

Psych. (-)

CC

Psych. (+)

CC

6.5.2.2 Change achieved

The overall aim of the SPI project was to implement a new approach combining support and SPI work on the project level, by using the CMM as a basic framework for identifying improvement opportunities. Changes were sought at all commitment net levels – strategic, operational and personal. The two main concerns that this project was attempting to address have been identified earlier: concern for software production capability and efficient collaboration with the process department. Table 36 shows the extent of change achieved in target actors’ commitment nets. Note that the target actor at strategic level is the management of the focal organization, which is not the global SPI department.

Table 36. Change achieved in actors’ commitment nets.

Commitment Net

Target actor SPI outcome (Impact on the customer)

Evidence

Strategic Focal

organization:

Management

Concern for software production

capability was widely diffused

among the management of

company B.

Number of process assessments

performed, aggregated results

reported widely to the

management.

Operational Internal group:

Software

projects

Concern for software production

capability did not diffuse to

software project commitment nets.

Some projects, however, continue

to use new support structure.

Project managers wanted to

receive support from the process

department not their “capability”

to be developed.

Page 132: The role of commitment in software process improvement - Oulu

130

The means, i.e. actions taken in the SPI project, to strengthen or to bring about these two concerns imply attempts to create a sense of normative and affective commitment. At the strategic level, the act of including CMM in site level incentive structure can be seen as an attempt to create a sense of normative commitment toward software production capability. The evolutionary approach used for implementing the new way of performing SPI, i.e. the means used at operational level, implies an attempt to create affective commitment to both capability and efficient collaboration. However, regardless of the results achieved from the SPI project, the business decision of top management (item #8 in Table 34) made the global process department, which is the owner of SPI effort, rethink the role of SPI effort in a larger context (item #9 in Table 34). Using the commitment typology, this act can be regarded as a result of continuance commitment toward the SPI project. There was also a wish to preserve some activities that would bring the most value in a changed situation. Global SPI department decided to refocus the project and to harness it to capture improvement items globally with a view to upcoming improvement initiatives. The ability to redirect the SPI project saved it from not being totally terminated.

Even though affective commitment toward the main concerns was sought at the operational level, there is no indication in the case data implying that this was achieved. Instead, normative commitment toward making progress was identified. The softwareproject manager stated after CMM self-assessment that

“It is good to have this action point list. Now we can perform these actions…of course we knew these problems…you (the external mentor + a process specialist) are pushing us to solve them.”

The involvement of immediate management overseeing the progress periodically is likely to enforce normative commitment.

In broad, this case evidences in several situations how changes in one commitment net cause changes in others. In one site, the process responsible was offered another position in the organization, which he decided to take. This change in his personal commitment net caused the SPI project manager to act in his role for some while until a new person was found to fill the position. The business decision (item #6 in Table 34) to redirect a software project in one site caused the SPI project to terminate, because it was targeted at project level. As indicated earlier, in that particular case the project manager wanted to participate in the project.

In the changed situation, the original attempt to change the way SPI was performed was compromised. In one site, a decision was made to continue change engine meetings without the support of the mentor since they “had gotten used to the idea”. Thus, some elements of the new way survived – even if the normative pressure to comply with SPI project demands was taken away. This indicates that some benefits were gained from using the approach. The collaboration between process department and software project increased and the visibility of software projects was enhanced in terms of process issues. No diffusion of the new and then re-modified practice of support and the SPI was planned. Thus, the changes were achieved at personal level with only few key individuals participating in the project. If these individuals move outside the organization, the old way, which separates support and SPI, is likely to be restored.

Page 133: The role of commitment in software process improvement - Oulu

7 Cross-case evaluation

While each case was analyzed separately in the previous chapter, the intent of this chapter is to perform a cross-case analysis over the four cases. The intent is to evaluate the commitment-related assumptions identified in Chapter 4 in the light of empirical findings. The operational level commitment process is also identified. Finally, it is explored whether commitment makes a difference with regard to SPI outcome as SPI literature has claimed, thus explicating the role of commitment in SPI.

7.1 Analysis of commitment assumptions

In Chapter 4, it was argued that certain assumptions about commitment have shaped the SPI research and practice. Now these assumptions will be mapped against the SPI practice identified from the empirical case material and the empirical findings drawn in Chapter 6.

7.1.1 Causality and controllability

It was argued that there exists an assumption that involves the notion of causality in the development of commitment. While it fits comfortably with linear, rational assumptions about cause and effect sequences, it fails to acknowledge that commitment exists in varying strengths. Commitment is a dynamic rather than a static concept. This means that people are referred to as being more or less committed rather than being simply committed or not.

The observations made by the present author indicate that software professionals perceive commitment as an internal attribute of an actor at the individual level. Based on the findings of the interviews, they maintain that this attribute is either on or off and that they have little influence on the state of this attribute. Or they lack the means to influence. To them, the means equals power or division of responsibilities. SPI staff does not generally have any power over software projects. This means that they can not dictate

Page 134: The role of commitment in software process improvement - Oulu

132

how things should be done. The SPI staff reports to the management and expects them to take the necessary actions. The practitioners in case company B referred to this as “escalating issues”. In both case companies, the management controlled the distribution of resources, but not the way the work was performed. Thus, process related decisions were up to the project manager. The observations in practice indicated that practitioners did not think of commitment in terms of simple cause and effect sequences, but as an internal attribute of an actor that exists a priori and there is not much that can be done about changing it. However, while SPI staff was lacking the means to influence the commitment to software projects, those with authority could do it. Thus, for the practitioners, commitment was connected with the issue of organizational power and legitimate authority.

Empirical case analyses show that clear causal relations are difficult to identify from the case data. In each case, commitment drivers were identified together with the dominating form of commitment. However, the resulting form of commitment was not necessarily the same even if the drivers were. Certain characteristics, such as volunteerism and control over SPI decisions, thus predispose to commitment but do not cause it. If such causal relations existed, cases 3 and 4 should have been great successes. Although both of these cases were explicitly designed to have the commitment enabling elements in place, the case analyses show that commitment failed to develop as intended. Management decisions, however, proved to affect lower level commitment nets. For example, the SPI project was terminated in case 3. In both case organizations, the project managers directed operational level commitment nets by making decisions regarding their level of involvement with the SPI projects. This indicates that at the strategic and operational levels, commitment, to a certain degree, is controllable through power and distribution of accepted roles. The individual level seems to have the most uncontrollable characteristics. In conclusion, the practitioners in the cases studied had a limited perception of commitment in this regard, and this bears important consequences. If the developmental nature of commitment is not acknowledged, problems will arise when someone is perceived as being non-committed to the SPI project.

7.1.2 Singularity and all-positive role

Another assumption suggested is the notion of a singular commitment construct. While it has been suggested by commitment-related literature that commitment is a multidimensional construct, the present author has argued that SPI practice does not acknowledge this (V). The failure to acknowledge different drivers and differing forms of commitment is likely to invite oversimplification and misuse of the concept. Also, since no critique against commitment was found it was suggested that the SPI practitioners view commitment as an all-positive phenomenon.

Empirical observation shows that practitioners do not think commitment may take multiple forms. Managerial commitment is needed to secure financial support for the project. When a new tool is rolled-out in the organization, it is expected that the staff “commits” itself to its use. When the SPI staff is asked to define a checklist for software projects, both parties are expected to show “commitment” to its development and

Page 135: The role of commitment in software process improvement - Oulu

133

subsequent use. The term commitment is also often used in practice. An SPI manager’s talk in SPI training contained tens of instances of using the term commitment. All of these instances were in a positive tone. Thus, even though individual level commitment is viewed as an internal and unchangeable attribute (or one that is difficult to change), it is used predominantly in a positive context (no negative use instances of the concept were encountered by the present author). Practitioners attribute part of the failures to the lack of commitment. This lack of commitment makes itself apparent through low interest and lack of SPI actions, e.g. not showing up at document reviews. When asked what should be done in order to generate interest toward process reviews, the interviewees could not identify any actions that could be taken. This, again, strengthens the evidence that the view practitioners have of the commitment phenomenon is relatively limited.

All forms of commitment were found among the case data, as is shown in the empirical analysis. However, the dominating forms of commitment were of instrumental and normative nature. This is due to fact that SPI requires activities that are not part of normal software development work. It has thus gained an overhead status. The results are also not clear or readily accessible. Thus, in order for SPI to gain significance, extraordinary interest toward “quality” is needed. Empirical cases show that commitment, as a phenomenon, is neither predominantly positive nor negative. The perception held by the practitioners, however, appears to be only positive.

7.1.3 Shared development of commitment

The commitment nets model maintains that there are different levels of actors that are equipped with a possibility to develop a commitment toward a certain target. Commitment targets, then, differ between different actors. For example, an individual may be committed to his career, while this would be impossible for an organization. It has been argued that while commitment can be a shared state of attachment by all the levels of an organization, its development and the resulting strength are most likely not shared.

Based on the observations made in practice it can be stated that this assumption causes the most problems. When a tool is spread in use to a large group of software developers with a managerial mandate that it should be used for some specific purpose, difficulties are bound to arise. Even though tools represent the repair type of improvement solution – as they are seen as an answer to many process problems – software professionals are extremely skeptical of adopting just anything to their use. When interviewed, managers, software developers and SPI personnel explain in detail how training, support and documentation should be arranged, but when observed in practice, little training or support is available or even possible to arrange within the time scales defined. It appears, however, that this assumption holds true only in relation to the tool adoption process. None of the SPI projects expected their participants to equally develop a sense of commitment at the same pace. In fact, it was for this particular reason that case 4 was planned separately for each participating site.

The empirical cases studied support the argumentation for different actors and their differing commitment targets. In case 2, it was shown what the commitment targets of the

Page 136: The role of commitment in software process improvement - Oulu

134

management were – none of which were related to the SPI under study. However, if explicated further, the SPI concern can be a shared target, but its development not.

7.1.4 Conclusions

The assumptions that were identified through the literature study were mapped against SPI practice in the four SPI cases as well as against the empirical conclusions drawn in Chapter 6. In summary, there are three conclusions that are drawn from this section. First, the analysis has shown that SPI practice is not hampered by faulty assumptions to the extent initially argued, even if the perception of practitioners concerning commitment is limited. Second, while all forms of commitment can be identified in the cases studied, normative and instrumental were the most common types. Finally, commitment is neither a predominantly positive or negative phenomenon, but rather a phenomenon that should be understood better. These conclusions bear important consequences, which will be addressed in brief in the following.

SPI practice views commitment as an internal attribute of an actor that is difficult to control or influence from the outside. This is the case at the individual level. While control, however, is attempted, it is connected with power and division of responsibilities. SPI staff often lacks this power in relation to the software projects due to the supportive role of SPI in the organization, with little strategic importance. However, by not acknowledging the developmental nature of commitment, problems arise when someone is perceived as being non-committed to the SPI project. This results in situations where any attempt to involve software projects in SPI work is all too easily given up. In addition, the practitioners do not acknowledge the different forms of commitment. The empirical conclusions have shown that normative and instrumental forms of commitment are the most common. This is caused by a perception that SPI requires activities that are not part of normal software development work, which in turn has given SPI an overhead status. The results are not clear or readily accessible. This has resulted in a situation where special interest toward quality is needed for making SPI successful. Instrumental commitment is not enough, since its existence is dependent upon the benefits achieved as expected. This, furthermore, leads to a situation where normative commitment is searched through managerial pressure, which is likely to shed negative light on SPI work.

Finally, the empirical conclusions stress the fact that commitment is neither a predominantly positive or negative phenomenon. It is rather a “natural” or “everyday” phenomenon that should be better understood. While SPI actions are intended to bring the concern for SPI about, this appears not to be the case at present. Table 37 summarizes the findings made regarding the assumptions in SPI practice.

Page 137: The role of commitment in software process improvement - Oulu

Tabl

e 37

.Ass

umpt

ions

: C

urre

nt r

esea

rch

and

empi

rica

l fin

ding

s m

appe

d.

Em

piri

cal f

indi

ngs

Ass

umpt

ion

Cur

rent

res

earc

h SP

I pr

acti

ce a

s ob

serv

ed

Em

piri

cal c

oncl

usio

n

The

cau

salit

y in

the

deve

lopm

ent o

f

com

mitm

ent

Dom

inat

ing

mod

els

are

life

cycl

e or

ient

ed

with

a d

efin

ite s

et o

f st

eps

for

impl

emen

tatio

n.

No

clea

r ca

use-

effe

ct s

eque

nces

exp

ecte

d.

Rat

her,

at i

ndiv

idua

l lev

el c

omm

itmen

t vie

wed

as a

n in

tern

al a

ttrib

ute

of a

n ac

tor.

To

prac

titio

ners

com

mitm

ent i

s co

nnec

ted

with

the

issu

e of

org

aniz

atio

nal p

ower

and

legi

timat

e au

thor

ity

Cle

ar c

ausa

l rel

atio

ns d

iffi

cult

to id

entif

y. C

erta

in

char

acte

rist

ics

(e.g

. vol

unte

eris

m, c

ontr

ol o

ver

SPI

deci

sion

s) p

redi

spos

e to

com

mitm

ent,

but d

o no

t

caus

e it.

The

con

trol

labi

lity

of th

e co

mm

itmen

t

proc

ess

Tac

tics

to b

uild

or

mai

ntai

n so

meo

ne’s

com

mitm

ent,

cook

book

type

rec

ipes

on

how

to g

et s

omeo

ne c

omm

itted

, how

to h

andl

e

the

com

mitm

ent p

robl

em a

re p

ropo

sed.

Whi

le c

ontr

ol is

con

tinuo

usly

atte

mpt

ed,

dom

inat

ing

view

pos

tula

tes

that

as

an in

tern

al

attr

ibut

e of

an

acto

r it

is d

iffi

cult

to c

ontr

ol.

Stra

tegi

c an

d op

erat

iona

l lev

el c

omm

itmen

t can

be,

to a

cer

tain

deg

ree,

con

trol

led

thro

ugh

pow

er a

nd

dist

ribu

tion

of a

ccep

ted

role

s. I

ndiv

idua

l lev

el h

as

the

mos

t unc

ontr

olla

ble

char

acte

rist

ics.

The

not

ion

of a

sing

ular

com

mitm

ent

cons

truc

t

One

for

m o

f co

mm

itmen

t exi

sts

and

this

com

mitm

ent i

s “n

eede

d” in

SPI

.

Dif

fere

nt f

orm

s of

com

mitm

ent a

re n

ot

ackn

owle

dged

. Pra

ctiti

oner

s at

trib

ute

part

of

failu

res

to la

ck o

f co

mm

itmen

t. T

his

lack

of

com

mitm

ent i

s vi

sibl

e th

roug

h lo

w in

tere

st a

nd

lack

of

SPI

acti

ons,

suc

h as

not

sho

win

g up

at

docu

men

t rev

iew

s.

SPI

requ

ires

act

iviti

es th

at a

re n

ot p

art o

f no

rmal

soft

war

e de

velo

pmen

t wor

k. I

t has

gai

ned

an

over

head

sta

tus.

Res

ults

are

not

cle

ar o

r re

adily

acce

ssib

le. I

nstr

umen

tal a

nd n

orm

ativ

e

com

mitm

ent f

orm

s w

ere

mos

t com

mon

ly

iden

tifie

d.

A v

iew

of

com

mitm

ent a

s an

all-

posi

tive

phen

omen

on

Com

mitm

ent-

orie

nted

cul

ture

is n

eede

d fo

r

impl

emen

ting

SPI;

com

mitm

ent i

s in

tegr

al

part

of

SPI

mod

els.

Prac

titio

ners

arg

ue th

at it

is d

iffi

cult

to c

hang

e

non-

com

mitm

ent i

nto

com

mitm

ent.

Thu

s,

ackn

owle

dgin

g th

e bi

ndin

g ef

fect

. How

ever

,

the

conc

ept i

s us

ed f

requ

ently

and

dom

inan

tly

in a

pos

itive

con

text

.

Com

mitm

ent i

s pr

edom

inan

tly n

eith

er a

pos

itive

or

nega

tive

phen

omen

on. R

athe

r, it

is a

phe

nom

enon

that

sho

uld

be b

ette

r un

ders

tood

. SPI

act

ions

do

not t

rans

fer

conc

erns

as

mod

els

and

prac

tice

expe

cts.

Shar

ed d

evel

opm

ent

of c

omm

itmen

t

Indi

vidu

als,

gro

ups

and

orga

niza

tions

are

not

seen

as

diff

eren

t uni

ts o

f an

alys

is.

Com

mitm

ent t

hus

deve

lops

in a

sha

red

mod

e.

SPI

prac

tice

expe

cts

the

deve

lopm

ent o

f

shar

ed c

omm

itmen

t onl

y in

rel

atio

n to

the

use

of to

ols.

Stra

tegi

c, o

pera

tiona

l and

per

sona

l lev

els

have

diff

eren

t tar

gets

of

com

mitm

ent.

SPI

con

cern

can

be a

sha

red

com

mitm

ent t

arge

t, bu

t not

its

deve

lopm

ent o

r th

e re

sulti

ng s

tren

gth.

Page 138: The role of commitment in software process improvement - Oulu

136

7.2 Commitment process

In software process improvement, commitment processes are concerned with studying how SPI concerns and subsequent actions come about in an actor’s commitment net. This means that the focus is on analyzing the journey of a SPI concern to the target actor’s commitment net. In concrete terms, the target actor is most often the software project developing the software. For this reason, only the operational level commitment process is at focus here.

In the empirical analysis, the drivers affecting the commitment to SPI either positively or negatively were identified together with the form of commitment possessed by the actors. This thesis maintains that in order for an SPI project to be successful, target actors’ commitment nets need to be permanently altered, i.e. the SPI concern needs to be involved. In what follows, the commitment process of software projects is analyzed across the four cases studied. First, the process is explicated and then it is studied why the process looks the way it does.

7.2.1 Operational level commitment process

Table 38 shows how commitment to SPI developed in the software projects of the four cases studied over the three SPI phases, and in terms of the concern that was striven for. The table also presents the drivers8 affecting each phase and the commitment form generated or possessed along with the resulting SPI outcome. The SPI outcome considers whether the SPI project was successful in transforming the underlying concern into commitment nets within the software project.

None of the cases managed to successfully alter the software project commitment nets. In other words, the systems unit in company A (case 1) is not using UCD practices after fourteen months into the SPI project. In case 2, module testing remains to be considered time consuming and difficult, while software projects will not invest their effort in MT development. In case 3, again, multi site software development problems are still solved case by case, and finally in case 4, the concern for the software production capability failed to become part of the commitment net within the specific software project.

However, certain similarities can be found by comparing the cases. For one thing, it appears that structural drivers forming the environment for performing process improvements tend to constantly jeopardize the existence of SPI. This is identifiable in the cases studied. In case 1, positive customer feedback, the decisive element in the process, came from outside the usability improvement project. Due to this, the new evolutionary approach for performing SPI was accepted. In case 2, organizational changes caused the improvement infrastructure to fall apart along with making the new 8 The drivers in the table have been deliberately placed on the abstract level (project, psychological, social and structural). This enables the comparison of the cases for identifying similarities and differences.

Page 139: The role of commitment in software process improvement - Oulu

137

roles obsolete in the new organizational structure. In case 3, all ongoing SPI projects were re-evaluated and a decision was made to put the case studied on hold. The case failed to meet the efficiency requirements set by the new management for SPI projects. In case 4, finally, one of the sites and one of the software projects were redirected. Events like these constitute structural drivers affecting the SPI project which are often beyond the scope of influence of the SPI endeavor. This gives evidence of the vulnerability of SPI activities to changes in the environment.

The SPI initiative and the development of target actors’ commitment are to be seen in their operating context. While SPI attempts to change the way software is produced, these activities are often seized by organizational turbulence. Actors’ concerns are replaced by survival in organizational restructuring either by explicit order (terminate all improvement activities) or implicit behavior (ignoring people regarding improvement issues). In such an environment, SPI is bound to lose its importance.

Table 38 shows that the participation of software projects in SPI initiatives is not necessarily based on objective SPI project features. These objective features are, e.g., project costs and benefits. In fact, for case 1 it was quite the opposite. It was the objective features of the usability improvement project that proved to decrease the software project’s commitment. It was perceived by the software project, as a collective group, that UCD was too theoretical and time consuming. Still, this case has turned out to be the only one to have survived without being terminated or redirected. Social drivers have maintained the connection of the software project with the usability improvement project. This commitment, however, exists only as long as normative pressure remains present or when the UCD methods prove their position as useful requirement specification and/or design methods.

In cases 2, 3 and 4, social, project and psychological drivers worked to increase the attention to the SPI project in the initiation phase. However, empirical conclusions indicate that while a positive boost to the project was gained, it was simultaneously weakened due to the inability of the SPI cases studied to produce quick and meaningful results, even if there were explicitly striven for. In case 4, this explicit attempt consisted of an evolutionary approach to SPI where the results were made visible once in every two weeks. However, in that particular case it was only the social drivers that worked to increase commitment toward the SPI project. This included the involvement of immediate management, an external mentor and a local process specialist at the change engine meetings. Thus, it is rather difficult to give meaningful interpretations to SPI results regarding a short time frame. This leads to a need to increase the role of social and psychological drivers as dominating SPI factors at the operational level. If this is not achieved, SPI activities will cease to exist or the results will not be far reaching.

Page 140: The role of commitment in software process improvement - Oulu

Tabl

e 38

.Com

mit

men

t pro

cess

es –

ope

rati

onal

leve

l

Initi

atio

n O

pera

tion

Clo

sure

C

ase

# C

once

rn

Dri

ver

C-f

orm

D

rive

r C

-for

m

Dri

ver

C-f

orm

SP

I ou

tcom

e

1 C

usto

mer

foc

us,

usab

ility

in th

e

proc

ess.

Proj

ect (

-)

Non

e

Proj

ect (

-)

Psyc

h. (

-)

IC

Proj

ect (

-)

Psyc

h. (

+)

Soci

al (

+)

NC

The

sys

tem

s un

it al

iena

ted

from

the

usab

ility

impr

ovem

ent p

roje

ct, b

eyon

d

few

occ

asio

ns o

f us

ing

the

pape

r

prot

otyp

ing

met

hod

UC

D p

ract

ices

hav

e

not b

een

diff

used

.

2 M

odul

e te

stin

g

impr

ovem

ent.

Soci

al (

+)

Psyc

h. (

+)

IC

Soci

al (

+)

Proj

ect (

-)

IC

Stru

ctur

al (

-)

Non

e

No

conc

ern

abou

t mod

ule

test

ing

was

deve

lope

d. I

t was

fel

t by

prac

titio

ners

that

SPI

dep

artm

ent s

houl

d de

velo

p

mod

ule

test

pro

cess

es.

3 So

lvin

g so

ftw

are

deve

lopm

ent

prob

lem

s in

mul

ti

site

env

iron

men

t.

Soci

al (

+)

Proj

ect (

+)

NC

Soci

al (

-)

Non

e

Stru

ctur

al (

-)

Non

e

Proj

ects

kee

p so

lvin

g m

ulti

site

prob

lem

s ca

se b

y ca

se. C

once

rn

cont

inue

s to

exi

st –

act

ions

are

mis

sing

.

4 So

ftw

are

prod

uctio

n

capa

bilit

y,

colla

bora

tion

betw

een

proc

ess

and

proj

ects

depa

rtm

ents

.

Soci

al (

+)

Proj

ect (

+)

NC

Soci

al (

+)

Psyc

h. (

-)

NC

Psyc

h. (

-)

NC

Con

cern

for

sof

twar

e pr

oduc

tion

capa

bilit

y di

d no

t dif

fuse

to s

oftw

are

proj

ect’

s co

mm

itmen

t net

s. S

ome

proj

ects

con

tinue

to u

se th

e ne

w s

uppo

rt

stru

ctur

e.

Page 141: The role of commitment in software process improvement - Oulu

139

Studying Table 38 from the commitment form point of view, four instances of normative commitment, three instances of instrumental commitment and four instances of no commitment can be identified. No commitment implies that the software projects were lacking actions in the SPI project. This can be explained through examining the differences and similarities in the light of SPI problem originator, which was defined to be the originator of the problem to be solved or improved by SPI activities. This originator can be any actor within the software development organization or outside. In cases 1 and 4, the problem originated outside the software projects (case 1: External research team, case 4: SPI department). In case 2, the problem with module testing was recognized both externally and internally in relation to the software projects. In case 3, the problem was not only widely recognized but also identified within the actual software projects. The case results show that when the problem originates from external sources, the software projects expect them also to be externally solved. The separation of SPI department from the software projects further invites this type of thinking, and this is also why the dominating forms of commitment across cases varied between no commitment, instrumental and normative. When the problem origin is external and the problem cannot be solved within the SPI initiative as intended, an external party, e.g. management, SPI staff and/or external researchers, are required for dealing with the problem.

7.2.2 Means used for creating concern

The problem faced by process specialists when dealing with a software project is a classic one: How to make the project realize that those involved should deal with process issues? Table 39 summarizes the means used for bringing about concerns in the SPI projects studied in terms of the SPI elements identified in Table 3 and in section 4.3.6

Judging the columns in Table 39 representing basic SPI elements it can be seen clearly that in the cases studied these elements have not been effectively performed. This further explains why the operational level commitment process identified in section 7.2.1 obtained its current form. Cases 1 and 4 used assessments as a means to bring about the concern. In case 1, the assessment was a two-weeks-long company wide assessment. In case 4, the assessments were private, light self-assessments with a process specialist and an outside mentor. Thus, two opposite continuums of assessment types were evidenced. It is evident that better results are obtained using the latter approach. A grand scale assessment proved to be incomprehensible to practitioners. A positive momentum gained early on is challenged by findings that are difficult to grasp. Company A had to spend resources on translating the improvement findings in a way that would make their staff comprehend them better. However, assessment is capable of bringing about a concern for the quality of the process only in case the method through which the assessment is performed is understood and accepted. In case 4, at least one project manager seriously doubted the CMM as a useful backbone for any type of software production. Case 4 was specially designed to incorporate the positive elements for commitment development. Such elements are voluntary participation, project control, visibility, management involvement, and the like. It, however, lacked one basic element or requirement that is often called for – the involvement of practitioners when the project is planned. While

Page 142: The role of commitment in software process improvement - Oulu

140

practitioners themselves decided what they would improve, the operating structure was preplanned without any involvement by the practitioners.

In chapter 2, it was maintained that the process innovation type of SPI improvement brings the most value to an organization. The focus is then on the interplay of many processes including the actors and their competence. Such an improvement solution was used in case 1. Process innovation is a long-term solution focusing on core problems, while simple fixes are not even attempted. However, for this very reason, the project drivers were evaluated to decrease commitment toward the improvement initiative. The benefits of “usability thinking” were not obtainable since only few concrete actions were taken. Towards the end the usability project, the SPI actions became more and more concrete, until, finally, the software project was put in charge of deciding which improvements they wanted to tackle.

Page 143: The role of commitment in software process improvement - Oulu

Tabl

e 39

.Mea

ns u

sed

for

tran

sfer

ring

a c

once

rn to

ope

rati

onal

leve

l com

mit

men

t net

.

Man

agem

ent o

f SP

I pr

ojec

t Im

prov

emen

t sol

utio

n C

ase

# C

once

rn

Org

aniz

atio

n Pl

an

Feed

back

SP

I A

ppro

ach

Typ

e T

rain

ing

1 C

usto

mer

foc

us

Usa

bilit

y in

the

proc

ess

Stru

ctur

e

defi

ned,

rol

es

uncl

ear

No

over

all

impr

ovem

ent p

lan

was

prod

uced

.

Stan

dard

ass

essm

ent

feed

back

giv

en. N

o

syst

emat

ic f

eedb

ack

stru

ctur

e at

tem

pted

.

Nor

mat

ive:

usa

bilit

y

capa

bilit

y as

sess

men

t

Proc

ess

inno

vatio

n:

Focu

s on

bot

h

reso

urce

s an

d

proc

esse

s.

Cou

rse

on p

aper

prot

otyp

ing

met

hods

orga

nize

d

2 M

odul

e te

stin

g

impr

ovem

ent

Dis

pers

ed to

seve

ral a

ctio

ns,

stru

ctur

e an

d

role

s un

clea

r.

No

over

all

impr

ovem

ent p

lan

was

prod

uced

.

No

feed

back

prov

ided

to s

oftw

are

proj

ects

nor

atte

mpt

ed.

Evo

lutio

nary

: pilo

t

proj

ect,

ques

tionn

aire

,

inte

rvie

ws

Proc

ess

repa

ir &

re-e

ngin

eeri

ng:

New

tool

s

sear

ched

, rol

es

defi

ned.

No

trai

ning

on

MT

org

aniz

ed

3 So

lvin

g so

ftw

are

deve

lopm

ent

prob

lem

s in

mul

ti

site

env

iron

men

t

Stru

ctur

e

defi

ned,

impl

emen

tatio

n

role

s no

t def

ined

Impr

ovem

ent p

lan

prod

uced

, not

impl

emen

ted.

Feed

back

on

find

ings

prod

uced

and

repo

rted

in th

e

wor

ksho

p.

Evo

lutio

nary

: Int

ervi

ews,

pers

onal

con

tact

s

Proc

ess

re-

engi

neer

ing:

Cla

rifi

catio

n of

role

s in

mul

ti si

te

envi

ronm

ent

Tra

inin

g on

mul

ti si

te

soft

war

e

deve

lopm

ent i

n

wor

ksho

p

4 So

ftw

are

prod

uctio

n

capa

bilit

y

Eff

icie

nt

colla

bora

tion

betw

een

proc

ess

and

proj

ects

depa

rtm

ents

Stru

ctur

e an

d

role

s de

fine

d an

d

com

mun

icat

ed.

Exp

licit

invo

lvem

ent o

f

SW p

roje

cts.

Impr

ovem

ent p

lan

with

in e

ach

part

icip

atin

g pr

ojec

t

prod

uced

and

impl

emen

ted.

Syst

emat

ic a

nd

visi

ble

feed

back

give

n ba

ck to

SW

proj

ect t

hrou

gh

chan

ge e

ngin

e

mee

tings

eve

ry tw

o

wee

ks.

Nor

mat

ive:

Man

agem

ent

invo

lvem

ent

Evo

lutio

nary

: Coa

chin

g,

light

CM

M a

sses

smen

ts,

botto

m u

p im

prov

emen

ts,

SW p

roje

ct p

rior

itiz

es

impr

ovem

ent t

arge

ts,

volu

ntee

r pa

rtic

ipat

ion

Proc

ess

re-

engi

neer

ing:

Red

efin

ition

of

role

s w

ithin

the

new

cha

nge

engi

ne

impr

ovem

ent

stru

ctur

e.

1-2

day

trai

ning

for

each

sof

twar

e

proj

ect i

n C

MM

Page 144: The role of commitment in software process improvement - Oulu

142

Based on the empirical evidence, it can be stated that the software projects were searching for process repair solutions, whereas the SPI practitioners – having more of a “theoretical” perspective – were seeking for process innovation based solutions. In between, both actor groups efficiently employed process re-engineering solutions. In fact, new roles can provide efficient mechanisms for bringing about a concern – consider a person moving to a new role or position, new concerns emerge naturally – but only if the role bears importance, is understood and effectively supported. In case 4, the new role of module testing power user was established, but not supported actively. Software projects were given a requirement for establishing this role within each development unit. However, this was seen as just “another responsibility”, which thus became dysfunctional and later obsolete due to changes in the organization.

7.3 Commitment vs. SPI outcome

SPI literature has claimed that commitment to SPI makes a difference regarding the outcome of the SPI initiative. This argument holds the assumption that the SPI project is otherwise well organized and planned. Table 40 highlights the cases studied simply in terms of whether the SPI project organization, planning, feedback and training activities were performed or not. Thus, the purpose is to identify those cases that had a sound basic infrastructure, so as to enable a further investigation of the role of commitment in such an initiative. Therefore, the contents of Table 40 are drawn from Table 39 in performance terms.

Table 40. Performance of the basic SPI elements.

Case # Organization Planning Feedback Training

1 No No No Yes

2 No No No No

3 No Yes Yes Yes

4 Yes Yes Yes Yes

Table 40 provides further evidence for the cases 1 and 2 not being able to bring about the SPI concern at the operational level. Commitment to the SPI project should not be expected if the SPI attempt is not properly managed. Cases 3 and 4, on the other hand, were well organized and properly planned. They had their feedback structure defined and proper training was organized. Thus, in accordance with SPI literature, these cases had a chance for success. Now, what needs to be investigated is whether commitment or lack thereof made a difference in regard to the outcome of those initiatives.

Case 4 was completed, but not in its original form having been redirected to discover the improvement items and case 3 was terminated after six months of operation. Did commitment, therefore, cause these outcomes, or, in other words, does the argument drawn from SPI literature still hold in the light of empirical findings gathered in this thesis?

Page 145: The role of commitment in software process improvement - Oulu

143

Answering this question requires a recognition of the cause-effect sequences regarding the commitment phenomena involved. The present author has maintained throughout the thesis that the assumption of causality in the commitment process is misleading, even at its best. However, on the basis of empirical data such causal relations can be retrospectively shown, which then links commitment with the outcome of the SPI initiative studied.

In case 3, the global SPI department re-evaluated all their SPI projects and the outcome of this evaluation process was that the initiatives bringing the best benefit to the whole organization receive funding and those that do not will be put on hold. As a result, the SPI project under study was terminated. In other words, a change in the strategic commitment net caused the organization to be rearranged. The business unit grew larger as the existing units were merged and others divided. The global SPI department was facing new concerns, one of which included the requirement to harmonize the way software projects were organized and operated business unit wide. As a result of this, the strategic commitment net that the global SPI department operated had to be rearranged also. This resulted in a re-evaluation of all ongoing SPI initiatives and what is now known is that as a result of re-evaluation, the SPI project was terminated before it could make an impact on the operational level commitment nets, i.e. software projects.

Case 4 proved to affect operational commitment nets throughout its existence. However, there were three changes in the strategic commitment nets, two of which did not originate from the SPI project, caused the SPI outcome. The two changes were the redirection of a software project and that of a software development site. The one that originated directly from the SPI initiative was the number of problems faced and the speed at which the improvements were made. The global SPI department which was acting as a sponsor for the initiative wanted to redirect the project away from the new SPI implementation structure to detecting improvement items.

Therefore, commitment as conceptualized and operationalized in this thesis plays an integral role concerning the outcome of an SPI initiative. Empirical evidence shows that two well-planned SPI initiatives failed to achieve the original goal due to changes in commitment nets. This does not, however, mean that this result compliments the existing SPI literature, which claims that commitment is important on the basis of merely anecdotal evidence. It is the typology and the dynamics of commitment as developed and presented in this thesis that enable the present author to maintain the argument.

Page 146: The role of commitment in software process improvement - Oulu

8 Evaluation of the results

The purpose of this chapter is to discuss the implications of the study. The discussion has been organized into theoretical and practical implication sections, thus addressing both the research and practice of SPI.

8.1 Implications for theory

In this section, the model of commitment nets (section 4.3 ) is evaluated in terms of how well it has operated as an analysis tool for SPI projects and how it should be improved on the basis of the findings made. The evaluation is based on metrics identified by Järvinen (2001), who is using the ideas put forth by March and Smith (March & Smith 1995) as his main source. The focus here is on the following metrics proposed for the evaluation of the model: fidelity with real world phenomena, completeness, level of detail, robustness, and internal consistency. Based on the evaluations, Table 41 summarizes the improvement suggestions for the proposed commitment nets model.

The actors defined for the initial model were organization, group and individual. These actors were involved in three levels of commitment nets: strategic, operational and personal. The actors, as they have been used in this study, were introduced in Table 7. While these actors were found to be adequate, some improvements are suggested regarding certain actor attributes. In specific, since most SPI is targeted at software projects (i.e., operational level) the following three additional attributes are suggested: the type of the software project, the type of software being developed and the phase in the project. This addition would make the analysis richer, thus making it possible to gain a deeper understanding of the operating context.

During the analysis process, it became evident that the commitment driver categorization adopted from IS literature – project, psychological, social and structural drivers – did not cover all the driver types present in an SPI project in sufficient detail. In the initial model, all the drivers were considered to be internal. This produced problems in the analysis, in which the SPI project was affected by environmental changes. The problem was solved by labeling these environmental variables as structural drivers. Although this solution proved to work in this case, it is suggested that in the future

Page 147: The role of commitment in software process improvement - Oulu

145

research efforts the differentiation between inner and outer contexts should be made explicit. The inner context refers to SPI, and the outer refers to SP.

Table 41. Improvements to commitment nets model.

Construct Initial model Improvements

Actors Strategic: organization

Operational: Group

Personal: Individual

Include actor attributes to operational level:

Software project type, type of software and

the phase of the SW project.

Commitment drivers External/internal: Structural,

project, social, psychological.

Inner context (SPI): Project, social,

psychological, structural.

Outer context (SP): historical (incl. process

maturity), environmental.

Commitment Viewed in terms of concern and

action

Each action included in the analysis should be

roughly the same size. Thus, actions should be

harmonized in a consistent set of SPI

activities.

Outcomes Intended/unintended No improvements suggested.

Commitment process Viewed in terms of change in

commitment drivers and by

identifying the SPI elements as the

means used for influencing

commitment.

No improvements suggested.

Currently, the analysis blends together different levels of actions. An action that required lots of effort, such as “perform pilot project on a new technology” (case 2), is not distinguished from a minor action, such as “review usability standards” (case 1). This hinders the possibility of comparing different cases at the activity level. Thus, as an improvement suggestion to the initial model, actions should be regarded as harmonized sets of SPI activities, which are roughly at the same level of detail.

Some difficulties were experienced in identifying the unintended outcomes of the SPI actions. Unintended outcomes may appear weeks or months later and it requires extreme sensitivity by the researcher to capture these. However, the inclusion of them in the model forces the researcher to observe items beyond the immediate surroundings. Thus, no changes are proposed to the model in this regard.

The initial model calls for an identification of changes in commitment drivers over the three generic SPI phases. The means by which strategic and operational commitment nets are changed are the core elements of SPI (Table 3). Some improvement suggestions were already made regarding the commitment driver categorization (see above). This also influences the subsequent analysis of the commitment process, since it is formed around the drivers. Therefore, no changes are needed regarding the analysis of commitment process.

Page 148: The role of commitment in software process improvement - Oulu

146

8.2 Implications for practice

In this section, three principal implications for the SPI practice are identified and described: 1) SPI activities should be dominantly based on voluntary involvement, 2) software development practices should incorporate elements of process improvement, and 3) SPI practice should place emphasis on the understanding the environment where SPI activities take place.

8.2.1 Voluntary involvement

Commitment research has established that if a person becomes committed towards any entity – organization, team, co-workers, goal, vision, career, etc. – the entity itself should be placed in the center of the person’s experiences (Brown 1996). In the case of SPI, this means that people from all organizational levels should be involved (Humphrey 1989). Involvement is also crucial for the success of innovation diffusion, and this is also valid for SPI as an organizational innovation (Green & Hevner 2000, Kautz & Larsen 2000). To put it simply, if software developers are not involved in the process of defining SPI activities, no commitment can be achieved. In fact, non-involvement invites alienation, which is the opposite of commitment (Meyer & Allen 1997). Although involvement does not directly indicate that something is important for the person involved, it is an important psychological driver for the commitment process.

Case 4 serves as an example of an improvement initiative in which voluntary involvement in the improvement process is explicitly defined in the improvement plan. In this case, project managers volunteered to the SPI projects after being briefed about the goals and benefits of the project. This contributed to their continuing participation throughout the project. It is acknowledged that voluntary involvement in practice is not always possible. Therefore, better results are obtained if practitioners used work methods that incorporate SPI elements. This issue is discussed in the following.

8.2.2 Embedded SPI

This implication here is concerned with the difficulties of having SPI as a target of one’s commitment. The cases studied strengthen the evidence in this regard. SPI is not an easy commitment target. The research findings from this study are that SPI is not perceived as a business issue, but as support work the results of which are often not visible, or not directly visible, the used vocabulary is uncommon, and the work is often done on an abstract level. Systematic SPI requires activities that, initially, are not part of the usual software engineering practices, i.e. software is not produced through SPI. Moreover, while SPI is perceived as somewhat unclear, it is easily misused as the research evidence shows:

Page 149: The role of commitment in software process improvement - Oulu

147

“We have organized [the SPI work] so that Mike’s (SPI manager) group is for people doing the thesis [for their educational institution]. It has found to be a suitable way of getting people acquainted [with the organization] […]”. [Senior manager, interview]

The SPI manager and the senior manager in the above case example have experienced difficulties in attracting new staff to SPI work. Thus, when SPI is embedded into daily routines, the software professionals are able to concentrate on their core work – producing better software. A more natural target for one’s commitment is the development of one’s profession and competence. This would involve the development of such essential skills as abstraction, problem solving and communication, technical knowledge and team orientation (Wynekoop & Walz 2000). SPI provides a mechanism with the conceptual and operational tools required for working in this direction.

8.2.3 Emphasis on the environment

While there is a tendency for people to become committed to a specific target in different forms – affective, continuance, normative and instrumental – this research has explicated that in the case of SPI commitment is most often of instrumental or normative type. The affective form of commitment, again, is desirable, but also difficult to achieve due to its uncontrollable nature. To make it possible for affective commitment to develop, emphasis should be placed on the environment. Article II has identified the characteristics of such an environment. It takes more than just a simple reward structure to support SPI activities. Such tactics as reward systems may initially work, but if incentives remain the main source of motivation, they may easily be circumvented and become dysfunctional (Iversen & Kautz 2002).

While the cases studied in the empirical part were not failures per se – i.e. concrete results were achieved in each of them – the environmental changes had a serious impact on cases 2, 3 and 4. Turbulence in the environment in terms of changes in organization structure is likely to cause changes in priorities in regard to actors’ concerns. Security in terms of securing the position in the new organizational mode becomes the main concern while SPI is prioritized lower. Thus, SPI practitioners should be aware of the vulnerability of SPI activities to changes in the environment.

Page 150: The role of commitment in software process improvement - Oulu

9 Conclusions

This final chapter of the thesis summarizes the main results, describes the main limitations of the present study and identifies some future research opportunities.

9.1 Summary of the results

Software process improvement approaches are designed to produce changes at the different levels – working practices, organization, and culture – of a software organization. Studies have shown that nearly two-thirds of all SPI efforts have failed or fall short of expectations. Literature and practice have claimed that commitment to SPI by all organizational levels is an important factor determining whether an SPI endeavor ultimately turns out to be a success or a failure. In this thesis, the commitment phenomenon was conceptualized and its role explored in various industrial SPI efforts. Thus, the specific research question was defined as follows:

What is the role of commitment in industrial software process improvement?

This question was answered by conceptualizing the commitment phenomenon in general and, then, relating it to software process improvement (Chapter 3). As a result of this, a definition of commitment was produced and operationalized in the form of a model on commitment nets (Chapter 4). This thesis set out to suggest that software organizations operate through commitment nets. Commitment net was defined as a net of commitment characteristics and their relationships, which together describe the process of commitment in the context of software process improvement.

The role of commitment in SPI was then explored in four SPI cases. The cases showed a lot of variation in terms of improvement scope, type and subsequent success. The cases were analyzed using the model of commitment nets. It was found that none of the cases managed to alter their respective operational commitment nets. The reasons for the lack of success are varied and they were discussed in detail in the empirical analysis part of the thesis (Chapter 6).

Based on the empirical findings, it was shown that while the objective features of SPI in terms of costs and benefits – i.e. project drivers – are dominating in the project

Page 151: The role of commitment in software process improvement - Oulu

149

initiation phase, their role tends to lose strength later on due to an inability of the SPI effort to produce quick and meaningful results, even if these are explicitly sought for. This phenomenon gives rise to a need for enhancing the role of social and psychological drivers at the operational level. If this is not achieved, SPI activities are likely to cease to exist. It was found that the structural drivers constituting the environment for process improvement activities tend to jeopardize the operation and even the existence of SPI.

The empirical analysis demonstrated that the use of commitment nets model enabled a more precise analysis of the many aspects involved in the commitment phenomenon than would have been possible with current commitment models. In conclusion, commitment, as conceptualized and operationalized in this thesis, makes a significant contribution to the outcome of the SPI initiative. Empirical evidence shows that it was due to changes in commitment nets that two well-planned SPI initiatives failed to reach the goals set for them.

9.2 Limitations of the study

There are two limitations that need to be acknowledged and addressed regarding the present study. The first limitation concerns the cross-disciplinary nature of this research project. The commitment phenomenon was studied within the context of software process improvement. There is an apparent danger involved whenever concepts are borrowed from related disciplines, i.e. from the fields of organizational behavior and information systems, and then applied in the present context. The author of this thesis does not have any degree in psychology, but he has had several discussions with scholars specializing in psychological phenomena. These scholars thought that it would be rather beneficial to have an “outsider” investigating the role of commitment in the present context, since it has not been done before and the present author does not represent any specific school of thought, which frees him to make an attempt at bridging various views presented in contemporary commitment research in a novel way. In addition, in the preparation phase for the article V, the present author consulted a practicing psychologist about the terminology used in this thesis. Furthermore, no new psychometric measurement instruments have been constructed since the dominating research approach has focused on gathering qualitative data. Finally, the commitment nets model used in this study does not attempt at explaining how an individual behaves, but rather provides the conceptual and operational tools for investigating commitment in the context of software process improvement.

The second limitation has to do with the extent to which the findings can be generalized beyond the cases studied. The number of cases is too limited for broad generalizations. However, the four software process improvement cases represent rather different aspects of the software development processes. Therefore, software organizations performing SPI activities can benefit from the findings. Further empirical evaluations, however, are needed to replicate the findings in different contexts and surroundings.

Page 152: The role of commitment in software process improvement - Oulu

150

9.3 Future research

This research has introduced the model of commitment nets, which is employed as a means to understand the dynamic aspect of commitment in software process improvement. This model should, however, be put into perspective. This would include a rigorous analysis and comparison of the already existing more general organizational theories. Such competing theories are, e.g., the activity theory (e.g., Kuutti 1991), formative contexts (Ciborra & Lanzara 1994) and the actor-network theory (e.g., Law & Hassard 1999). It is only through a rigorous review that it would be possible to place the commitment nets model among the rich body of scientific advancements. During the process, it may even turn out that the commitment net constitutes an extension to some already existing theory. However, since the contents and dynamics of this research effort draw on empirical data, they can be considered to enjoy adequate empirical support, which is necessary for any theoretical model. Thus, the contribution of the commitment nets model remains to be assessed further in future research. Some interest has, however, already been shown in the concept of commitment nets by the scientific community, due to the fact that the notion has been published in (Abrahamsson 2002)

Second, the basis for SPI research should be expanded. This thesis has provided rather an unconventional perspective on the complexities of software process improvement. However, in recent years this has become more and more frequent along with the maturing of the field. Rather than originating from software engineering research, the methods and models employed in software process improvement originate in the works of enthusiastic practitioners. This fact would certainly merit a broader acknowledgement and a more detailed treatment among researchers. Furthermore, the tracks combining the research done in related disciplines should also be pursued rather than settling for an attempt to treat software process improvement merely as a specific new phenomenon without explicating its links to other related phenomena, such as information systems implementation, innovation-diffusion research, organization development and the like. While some steps in this direction have already been taken (cf. Kautz & Larsen 2000, Aaen et al. 2001, Kautz et al. 2001, Seppänen et al. 2001, Kautz & Thaysen 2002) a lot of work in the field still remains to be done.

The exploration of the nature and foundation of process improvement is still at a developmental stage, which leaves a lot of room for further research of interdisciplinary nature, in particular. While the field of software engineering has typically been eager to develop new models and approaches, less attention has been paid to the underlying assumptions. This thesis has explicated a set of assumptions that are drawn from the commitment perspective. These assumptions appear to be pushing the research and practice in a specific direction. If the explicated assumptions prove prevalent, critical evaluations should be performed regarding the way software engineering is thought about.

Page 153: The role of commitment in software process improvement - Oulu

References

Aaen I, Arent J, Mathiassen L & Ngwenyama O (2001) A conceptual map of software process improvement. Scandinavian Journal of Information Systems 13: 123-146.

Aaen I & Bang S (2002) The correct effort. In: Mathiassen L, Pries-Heje J & Ngwenyama O, (eds) Improving software organizations: From principles to practice. Addison-Wesley, New York, p 49-64.

Abrahamsson P (1999a) Commitment to Software Process improvement – Development of Diagnostic Tool to Facilitate Improvement. INSPIRE'99, Heraklion, Crete, 13-25.

Abrahamsson P (1999b) Expanding Goal Setting Theory Concepts – Using Goal Commitment Measurements to Improve Chances for Success in SPI. International Conference on Product Focused Software Process Improvement, Profes'99, Oulu, Finland, 481-496.

Abrahamsson P (2000a) Is Management Commitment a Necessity After All in Software Process Improvement? The 26th EUROMICRO Conference, EUROMICRO '00, Maastricht, Holland, 2: 246-253.

Abrahamsson P (2000b) Measuring success in SPI initiatives: The dimensions. EuroSPI'00, Copenhagen, Denmark.

Abrahamsson P (2001a) Commitment Development in Software Process Improvement: Critical Misconceptions. 23rd International Conference on Software Engineering, ICSE 2001, Toronto, Canada, 71-80.

Abrahamsson P (2001b) Rethinking the concept of commitment in software process improvement. Scandinavian Journal of Information Systems 13: 69-98.

Abrahamsson P (2002) Commitment nets in software process improvement. Annals of Software Engineering, in press.

Abrahamsson P & Jokela T (2000) Development of Management Commitment to Software Process Improvement. Information Systems Research Seminar (IRIS23), Uddevalla, Sweden, 487-505.

Almaraz J (1994) Quality Management and the Process of Change. Journal of Organizational Change Management 7: 6-14.

Arbaoui S, Lonchamp J & Montangero C (1999) The human dimension of the software process. In: Derniame J-C, Ali Kaba D & Wastell DG, (eds) Software Process: Principles, Methodology, and Technology. Springer, New York, p 165-200.

Arent J (2000) Normative software process improvement. Deparment of computer science. Aalborg, Aalborg University.

Austin JL (1962) How to do things with words: The William James lectures delivered at Harvard University in 1955. Oxford University Press, Oxford.

Avison D, Lau F, Myers M & Nielsen PA (1999) Action Research. Communications of the ACM 42: 94-97.

Baruch Y (1998) The rise and fall of organizational commitment. Human Systems Management 17: 135-143.

Page 154: The role of commitment in software process improvement - Oulu

152

Basili V & Green S (1994) Software process evolution at the SEL. IEEE Software 11: 58-66. Basili VR, Caldiera G & Rombach HD (1994) Experience Factory. In: Marciniak JJ, (ed)

Encyclopedia of software engineering. Wiley, New York, p 469-476. Baskerville RL & Wood-Harper AT (1998) Diversity in information systems action research

methods. European Journal of Information Systems 7: 90-107. Batista J & de Figueiredo AD (2000) SPI in a very samll team: A case with CMM. Software

Process Improvement and Practice 5: 243-250. Beck K & Wilson C (2000) Development of Affective Organizational Commitment: A Cross-

Sequental Examination of Change with Tenure. Journal of Vocational Behavior 56: 114-136. Becker HS (1960) Notes on the concept of commitment. American Journal of Sociology 66: 32-40. Becker TE (1992) Foci and bases of commitment: Are they distinctions worth making? Academy

of Management Journal 35: 232-244. Beer M, Eisenstat RA & Spector B (1990) Why Change Programs Don't Produce Change. Harvard

Business Review 68: 158-66. Bem DJ (1972) Self-perception theory. In: Berkowitz L, (ed) Advances in experimental social

psychology. Academic Press, New York, p 1-62. Benkhoff B (1997a) Disentangling organizational commitment - The dangers of OCQ for research

and policy. Personnel Review 26: 114-131. Benkhoff B (1997b) Ignoring Commitment Is Costly: New Approaches Establish the Missing Link

Between Commitment and Performance. Human Relations 50: 701-726. Bennet H & Durkin M (2000) The effects of organizational change on employee psychological

attachment: An exploratory study. Journal of managerial Psychology 15: 126-147. Birk A, Järvinen J, Komi-Sirviö S, Kuvaja P, Oivo M & Pfahl D (1998) PROFES - A product

driven process improvement methodology. European Conference on Software Process Improvement (SPI'98), Monaco.

Brown ME (1969) Identification and some conditions of organizational involvement. Administrative Science Quarterly 14: 533-546.

Brown RB (1996) Organizational commitment: Clarifying the concept and simplifying the existing construct typology. Journal of Vocational Behavior 49: 230-251.

Buchanan B (1974) Building organizational commitment: The socialization of managers in work organizations. Adiminstrative Science Quarterly 19: 533-546.

Burnstein I, Homyen A, Saxena G & Grom R (1999) A testing maturity model for software test process assessment and improvement. Software Quality Professional 1.

Caldwell DF, Chatman JA & O'Reilly CA (1990) Building organizational commitment: A multi-firm study. Journal of Occupational Psychology 63: 245-261.

Caldwell DF & O'Reilly CA (1982) Response to failure: The effects of choice and responsibility on impression management. Academy of Management Journal 25: 121-136.

Ciborra CU & Lanzara GF (1994) Formative contexts and information technology. Journal of Accounting, Management and Information Technology 4: 61-86.

Clegg BT, Wingrove SJ & Boardman JT (1996) Improving process management performance using systematic methods and tools. IEE Colloquium on Systematic Methods for Improving Business Performance 1/1-12.

Clugston M, Howell JP & Dorfman PW (2000) Does cultural socialization predict multiple bases and foci ofo commitment. Journal of Management 26: 5-30.

Coleman DF, Irving GP & Cooper CL (1999) Another look at the locus of control-organizational commitment relationship: It depends on the form of commitment. Journal of Organizational Behavior 20: 995-1001.

Conner DR & Patterson RB (1982) Building Commitment to Organizational Change. Training and Development Journal: 18-30.

Coopey J & Hartley J (1991) Reconsidering the case for organizational commitment. Human Resource Management Journal 1: 18-32.

Crosby PB (1979) Quality Is Free: The Art of Making Quality Certain. Mentor, New York. Cugola G & Ghezzi C (1998) Software Processes: a Retrospective and a Path to the Future.

Software Process Improvement and Practice 4: 101-123.

Page 155: The role of commitment in software process improvement - Oulu

153

Cunningham JB (1997) Case study principles for different types of cases. Quality and quantity 31: 401-423.

Curtis B, Hefley WE & Miller S (1995) People Capability Maturity Model. Pitssburgh, Software Engineering Institute, Technical report, CMU/SEI-92-TR-19.

Curtis B, Krasner H & Iscoe N (1988) A field study of the software design process for large systems. Communications of the ACM 31: 1268-1287.

Dahlberg T & Järvinen J (1997) Challenges to IS Quality. Information and Software Technology Journal 39: 809-818.

Davis M & Bobko P (1986) Contextual effects on escalation processes in public sector decision making. Organizational Behavior and Human Decision Processes 37: 121-138.

Debou C (1999) Goal-based software process improvement planning. In: Messnarz R & Tully C, (eds) Better software practice for business benefit: Principles and experience. IEEE Computer Society, Los Alamitos, CA, p 107-150.

Deci EL & Ryan RM (1980) The Empirical Exploration of Intrinsic Motivational Processes. In: Advances in Experimental Social Psychology. Academic Press, New York, p 39-80.

Deming WE (1982) Out of the crisis. Productivity Press, Cambridge, Mass. DeShon RP & Landis RS (1997) The Dimensionality of the Hollenbeck, Williams, and Klein

(1989) Measure of Goal Commitment on Complex Tasks. Organizational Behavior and Human Decision Processes 70: 105-116.

Diaz M & Sligo J (1997) How software process improvement helped Motorola. IEEE Software 14: 75-81.

Drennan D (1989) How to get employees committed. Management Today: 121-129. Dunham RB, Grube JA & Castañeda MB (1994) Organizational Commitment: the Utility of an

Integrative Definition. Journal of Applied Psychology 79: 370-380. Dybå T (2000) An instrument for measuring the key factors of success in software process

improvement. Empirical Software Engineering 5: 357-390. Eisenhardt KM (1989) Building theories from case study research. Academy of Management

Review 14: 532-550. El Emam K, Goldenson D, McCurley J & Herbsleb J (1998) Success or Failure? Modeling the

Likelihood of Software Process Improvement, International Software Engineering Research Network.

El Emam K & Madhavji NH (1999) Elements of software process assessment and improvement. IEEE Computer Society, Los Alamitos, Calif.

Ewusi-Mensah K & Przasnyski ZH (1991) On information systems project abandonment: An exploratory study of organizational practices. MIS Quarterly 15: 67-86.

Ferguson J, Cooper J, Falat M, Fisher M, Guido A, Marciniak J, Matejceckn J & Webster R (1996) Software Acquisition Capability Maturity Model. Pitssburgh, Software Engineering Institute, Technical report, CMU/SEI-96-TR-020.

Florac WA, Park RE & Carleton AD (1997) Practical Software Measurement: Measuring for Process Management and improvement. Pittsburgh, The Software Engineering Institution.

Flores F & Spinosa C (1998) Information technology and the institution of identity - Reflections since Understanding computers and cognition. Information Technology & People 11: 351-372.

Fox F & Staw BM (1979) The trapped administrator: The effects of job insecurity and policy resistance upon commitment to a course of action. Adiminstrative Science Quarterly 24: 449-471.

Galliers B & Swan J (1999) Information Systems and Strategic Change - A Critical Review of Business Process Re-engineering. In: Currie W & Galliers B, (eds) Rethinking management information systems: an interdisciplinary perspective. Oxford University Press, Oxford, p 361-387.

Ginzberg MJ (1981) Key Recurrent Issues in the MIS Implementation Process. MIS Quarterly 5: 47-59.

Glaser BG & Strauss AL (1967) The discovery of grounded theory. Aldine, Chicago. Glass RL (1999) The realities of software technology payoffs. Communications of the ACM 42:

74-79.

Page 156: The role of commitment in software process improvement - Oulu

154

Goldenson DR, Gopal A & Mukhopadhuay T (1999) Determinants of Success in Software Measurement Programs: Initial Results. Proceedings of the Sixth International Software Metrics Symposium 10-21.

Goldenson DR & Herbsleb J (1995) After the appraisal: a systematic survey of process improvement, its benefits, and factors that influence success. Carnegie Mellon U & Software Engineering I. Pittsburgh, Pa., Carnegie Mellon University Software Engineering Institute.

Gouldner HP (1960) Dimensions of organizational commitment. Administrative Science Quarterly 4: 468-490.

Grady RB (1997) Successful software process improvement. Prentice Hall PTR, Upper Saddle River, NJ.

Green GC & Hevner AR (2000) The successful diffusion of innovations: Guidance for software development organizations. IEEE Software 17: 96-103.

Grusky O (1966) Career mobility and organizational commitment. Adiminstrative Science Quarterly 10: 488-503.

Hackett RD, Bycio P & Hausdorf PA (1994) Further assessment of Meyer and Allen's three-component model of organizational commitment. Journal of Applied Psychology 79: 15-23.

Hadden R (1999) Building Highly Effective SPI Projects: What You Must Do Right. Cutter IT Journal 12: 10-16.

Hage J (1980) Theories of organizations: Form, process and transformation. Wiley, New York. Hall DT, Schneider B & Nygren HT (1970) Personal factors in organizationl identification.

Adiminstrative Science Quarterly 15: 176-190. Hall T & Fenton N (1997) Implementing Effective Software Metrics Programs. IEEE Software 14:

55-65. Hall T & Wilson D (1997) View of software quality: a field report. IEE Proceedings of Software

Engineering 144: 111-118. Harkness WL & Kettinger WJ (1996) Sustaining process improvement and innovation in the

information services function: Lessons learned at the Bose Corporation. MIS Quarterly 20: 349-368.

Hartmann LC & Bambacas M (2000) Organizational commitment: A multi method scale analysis and test of effects. The International Journal of Organizational Analysis 8: 89-108.

Haunschild PR, Davis-Blake A & Fichman M (1994) Managerial overcommitment in corporate acquisition processes. Organization Science 5: 528-540.

Hefner R (1997) Lessons learned with the systems security engineering capability maturity model. International Conference on Software Engineering (ICSE), Boston, Massachusetts, USA, 566 - 567.

Hegel GWF (1979) The Phenomenology of spirit. Oxford University Press, Oxford. Heidegger M (1962 (1937)) Being and Time. Basil Blackwell, Oxford. Herbsleb JD & Grinter RE (1998) Conceptual simplicity meets organizational complexity: case

study of a corporate metrics program. Proceedings of the 1998 International Conference on Software Engineering 271-280.

Hollenbeck JR, Klein HJ, O'Leary AM & Wright PM (1989) Investigation of the construct validity of a self-report measure of goal commitment. Journal of Applied Psychology 74: 951-956.

Horvat RB, Rozman I & Györkös J (2000) Managing the complexity of SPI in small companies. Software Process: Improvement and Practice 5: 45-54.

Hrebiniak LG & Alutto JA (1972) Personal and role-related factors in the development of organizational commitment. Adiminstrative Science Quarterly 17: 555-572.

Huge EC (1990) Helping managers see the light: Developing leadership commitment to quality improvement. In: The Ernst & Young Quality Improvement Consulting Group U, (ed) Total quality: A manager's guide for the 1990s. Dow Jones-Irwin, Homewood, Ill., p 26-38.

Humphrey WS (1989) Managing the Software Process. Addison-Wesley, Reading, Mass. Humphrey WS (1992) Introduction to software process improvement. Carnegie Mellon University

Software Engineering Institute, Pittsburgh, Pa. Humphrey WS (1995) A discipline for software engineering. Addison Wesley, Reading, Mass. Humphrey WS (2000) Introduction to the team software process(sm). Addison-Wesley, Reading,

Mass.

Page 157: The role of commitment in software process improvement - Oulu

155

Hutchings T, Hyde M, Marca D & Cohen L (1993) Process improvement that lasts: An integrated training and consulting method. Communications of the ACM 36: 105-113.

Isacsson P, Pedersen G & Bang S (2001) Accelerating CMM-based improvement programs: The accelerator model and method with experiences. Software Process Improvement and Practice 6: 23-34.

Iversen J & Kautz K (2002) Principles of metrics implementation. In: Mathiassen L, Pries-Heje J & Ngwenyama O, (eds) Improving software organizations: From principles to practice. Addison-Wesley, New York, p 287-305.

Jakobsen AB (1998) Bottom up process improvement tricks. IEEE Software 15: 64-68. Jaros SJ, Jermier JM, Koehler JW & Sincich T (1993) Effects of continuance, affective, and moral

commitment on the withdrawal process: An evaluation of eight structural equation models. Academy of Management Journal 36: 951-995.

Jayaratna N & Sommerville I (1998) Editorial: The role of information systems methodology in software engineering. IEE Proc.-Softw. 145: 93-94.

Jick TD (1979) Mixing qualitative and quantitative methods: Triangulation in action. Administrative Science Quarterly 24: 602-611.

Johansen J & Mathiassen L (1998) Lessons learned in a National SPI Effort. EuroSPI'98, Gothenburg, Sweden, 5.2 - 5.17.

Johnson D & Brodman J (1996) Realities and rewards of software process improvement. IEEE Software 13.

Johnson J (1995) Chaos: The dollar drain of IT project failures. Application Development Trends 2: 41-47.

Johnston HR & Carrico SR (1988) Developing capabilities to use information strategically. MIS Quarterly 12: 37-48.

Jokela T (2001) Assessment of user-centred design processes as a basis for improvement action. Anexperimental study in industrial settings. Dept Information Processing Science, Univ Oulu.

Jones GR (1986) Socialization tactics, self-efficacy, and newcomers' adjustments to organizations. Academy of Management Journal 29: 262-279.

Juran JM (1988) Juran on planning for quality. The Free Press, New York, NY. Järvinen J (2000) Research questions guiding selection of an approariate research method.

ECIS2000. Järvinen P (2001) On research methods. Juvenes-Print, Tampere. Kanter RM (1968) Commitment and social organization: A study of commitment mechanisms in

utopian communities. American Sociological Review 33: 499-517. Kaplan A (1964) The conduct of inquiry: Methodology for behavioral science. Chandler, New

York. Kasse T & McQuaid PA (1998) Entry Strategies into the process improvement initiative. Software

Process - Improvement and Practice 4: 73-88. Kautz K (1999) Software process improvement in very small enterprises: Does it pay off? Software

Process - Improvement and Practice 4: 209-226. Kautz K & Larsen EÅ (2000) Diffusion theory and practice - Disseminating quality management

and software process improvement innovations. Information Technology & People 13: 11-26. Kautz K & Thaysen K (2002) Knowledge, learning and IT support in a small software company.

Journal of Knowledge Management 6: in press. Kautz K, Westergaard H & Thaysen K (2001) Understanding and changing software organizations.

Scandinavian Journal of Information Systems 13: 31-50. Keen PGW (1998) Let's put project management out of its misery. Computerworld:

http://www.computerworld.com/home/print.nsf/all/9812078166. Keil M (1995) Pulling the Plug: Software Project Management and the Problem of Project

Escalation. MIS Quarterly 19: 421-447. Keil M, Cule PE, Lyytinen K & Schmidt RC (1998) A Framework for Indentifying Software

Project Risks. Communications of the ACM 41: 76-83. Keil M & Mixon R (1994) Understanding runaway IT projects: Preliminary results from a program

of research based on escalation theory. The Twenty-Seventh Annual Hawaii International Conference on System Sciences, Kihei, HI, 469-478.

Page 158: The role of commitment in software process improvement - Oulu

156

Keil M, Mixon R, Saarinen T & Tuunainen V (1995) Understanding runaway information systems development projects: a result from an international reserach program based on escalation theory. Journal of Management Information Systems 11: 67-87.

Keil M, Rai A & Mann J (2000) Why software projects escalate: An empirical analysis and test of four theoretical models. MIS Quarterly 24: 631-664.

Keil M & Robey D (1999) Turning Around Troubled Software Projects: An Exploratory Study of the Deescalation of Commitment to Failing Courses of Action. Journal of Management Information Systems 15: 63-87.

Kelman HC (1958) Compliance, identification, and internalization: Three processes of attitude change. Journal of Conflict Resolution 2: 51-60.

Kelman HC (1961) Processes of opinion change. Public Opinion Quarterly 2: 51-60. Kierkegaard S (1985) Fear and Trembling. Penguin, London. Kiesler CA (1971) The Psychology of Commitment: Experiments Linking Behavior to Belief.

Academic Press, London, UK. Kinnula A (1999) Software process engineering in a multisite enviroment: An architectural design

of a software process engineering system. Dept Information Processing Science, Univ Oulu. Kinnula A (2001) Software process engineering systems: Models and industry cases. Dept

Information Processing Science, Univ Oulu. Klein HJ & Mulvey PW (1995) Two investigations of the relationships among group goals, goal

commitment, cohesion, and performance. Organizational Behavior and Human Decision Processes 61: 44-53.

Kofman F & Senge PM (1993) Communities of commitment: The Heart of Learning Organizations. organizational Dynamics 22: 4-23.

Korson TD (1996) Managing your corporate culture (High heels and coffee cups). Object Magazine.

Kuutti K (1991) Activity theory and its applications to information systems research and design. In: Nissen H-E, Klein HK & Hirscheim R, (eds) Information Systems Research Arena of the 90's, North-Holland, Amsterdam, p 529-550.

Kuvaja P, Similä J, Kranik L, Bicego A, Saukkonen S & Koch G (1994) Software Process Assessment and Improvement - The BOOTSTRAP Approach. Blackwell Publishers, Cambridge, MA.

Langley A (1999) Strategies for theorizing from process data. Academy of Management Review 24: 691-710.

Laporte CY & Trudel S (1999) Addressing people issues when developing and implementing engineering processes. CrossTalk, The Journal of Defense Software Engineering: 8-17.

Lau F (1999) Toward a framework for action research in information systems studies. Information Technology & People 12: 148-175.

Law J & Hassard J, (eds) (1999) Actor Network Theory and After. Blackwell Publishers. Lawler EJ (1992) Affective attachment to nested groups: A choice process theory. American

Sociological Review 57: 327-339. Locke EA & Latham GP (1990) A Theory of Goal Setting & Task Performance. Prentice Hall,

Englewood Cliffs, NJ. Locke EA, Latham GP & Erez M (1988) The determinants of goal commitment. Academy of

Management Review 13: 23-39. Lucas HC (1975) Why information systems fail. Columbia university press, New York. Lucas HC, Jr. (1981) Implementation: The key to successful information systems. Columbia

University Press, New York. Mahaney RC & Lederer AL (1999) Runaway information systems projects and escalating

commitment. Computer personnel research (ACM SIGCPR), New Orleans, LA. Major J & Pellegrin JF (1998) Meeting the software challenge: Strategy for competetive success.

Research Technology Management 41: 48-56. March ST & Smith GF (1995) Design and natural science research on information technology.

Decision Support Systems 15: 251-266. Markus ML (1981) Implementation politics: Top management support and user involvement.

Systems, Objectives, Solutions 1: 203-215.

Page 159: The role of commitment in software process improvement - Oulu

157

Marsh RM & Mannari H (1977) Organizational commitment and turnover: A predictive study. Adiminstrative Science Quarterly 22: 57-75.

Mathiassen L, Pries-Heje J & Ngwenyama O, (eds) (2002) Improving software organizations: From principles to practice. Addison-Wesley, New York.

Mathieu JE & Zajac DM (1990) A review and meta-analysis of the antecedents, correlates, and consequences of organizational commitment. Psych. Bulletin 108.

McFeeley B (1996) IDEAL: A User's Guide for Software Process Improvement. Pittsburgh, Software Engineering Institute.

Melo Wl, El Emam K & Drouin J-N (1998) SPICE : the theory and practice of software process improvement and capability determination. IEEE Computer Society Press, Los Alamitos, Calif.

Messnarz R & Tully C, (eds) (1999) Better software practice for business benefit. IEEE Computer Society.

Meyer JP & Allen NJ (1991) A three-component conceptualization of organizational commitment. Human Resource Management Review 1: 61-89.

Meyer JP & Allen NJ (1997) Commitment in the Workplace: Theory, Research, and Application. Sage Publications, Thousand Oaks.

Meyer JP, Allen NJ & Smith CA (1993) Commitment to organizations and occupations: Extension and test of a three-component conceptualization. Journal of Applied Psychology 78: 538-551.

Miles MB & Huberman AM (1994) Qualitative data analysis. Sage, Newbury Park, CA. Miller D & Lee J (2001) The people make the process: commitment to employees, decision

making, and performance. Journal of Management 27: 163-189. Mohr LB (1982) Explaining organizational behavior. Jossey-Bass, San Francisco. Moitra D (1998) Managing change for software process improvement initiatives: A practical

experience-based approach. Software Process - Improvement and Practice 4: 199-207. Montealegre R & Keil M (2000) De-escalating information technology projects: Lessons from the

Denver International Airport. MIS Quarterly 24: 417-447. Morrow PC (1983) Concept redundancy in organizational research: The case of work commitment.

Academy of Management Review 8: 486-500. Morrow PC (1993) The Theory and Measurement of Work Commitment. JAI Press, Inc.,

Greenwich, CT. Mowday RT (1998) Reflections on the study and relevance of organizational commitment. Human

Resource Management Review 8: 387-401. Mowday RT, Porter LW & Steers R (1982) Organizational linkages: The psychology of

commitment, absenteeism, and turnover. Academic Press, San Diego. Newman M & Sabherwal R (1996) Determinants of Commitment to Information Systems

Development: A Longitudinal Investigation. MIS Quarterly 20: 23-54. Nord WR & Fox S (1999) The individual in organizational studies: The great disappearing act? In:

Clegg SR & Hardy C, (eds) Studying organizations. Sage Publications, Thousand Oaks, p 142-168.

Oliver N (1990) Rewards, investments, alternatives and organizational commitment: Empirical evidence and theoretical development. The British Psychological Society 63: 19-31.

Oquist P (1978) The epistemology of action research. Acta Sociologica 21: 143-163. O'Reilly C & Chatman J (1986) Organizational Commitment and Psychological Attachment: The

Effects of Compliance, Identification, and Internalization on Prosocial Behavior. Journal of Applied Psychology 71: 492-499.

Orlikowski WJ (1992) Learning from Notes: Organizational Issues in Groupware Implementation. Proceedings of CSCW'92 Conference 362-369.

Orlikowski WJ (1993) CASE tools as organizational change: Investigating incremental and radican changes in systems development. MIS Quarterly 17: 309-340.

Paulk M, Weber C, Curtis B & Chrissis MB (1994) The Capability Maturity Model - Guidelines for improving the Software Process. Addison-Wesley,

Paulk MC (1999) Structured approaches to managing change. CrossTalk, The Journal of Defense Software Engineering: 4-7.

Pfeffer J (1997) New directions for organization theory: problems and prospects. Oxford University Press, New York.

Page 160: The role of commitment in software process improvement - Oulu

158

Pfeffer J (1998) The human equation : building profits by putting people first. Harvard Business School Press, cop, Boston, MA.

Porras JI & Hoffer SJ (1986) Common behavior changes in successful organization development efforts. Journal of Applied Behavioral Science 22: 477-494.

Porter L, Steers R, Mowday R & Boulian P (1974) Organizational commitment, job satisfaction and turnover among psychiatric technicians. Journal of Applied Psychology 59: 603-609.

Pourkomeylian P (2001) Analysing an SPI project with the MAP framework. Scandinavian Journal of Information Systems 23: 147-165.

Randall DM (1987) Commitment and the organization: The organization man revisited. Academy of Management Review 10: 465-476.

Reichers AE (1985) A review and reconceptualization of organizational commitment. Academy of Management Review 10: 465-476.

Ross J & Staw BM (1993) Organizational escalation and exit: Lessons from the Shoreham Nuclear Plant. Academy of Management Journal 36: 701-732.

Rousseau DM (1995) Psychological contracts in organizations: understanding written and unwritten agreements. SAGE Publications, Thousand Oaks.

Ruspini E (1999) Longitudinal research and the analysis of social change. Quality and Quantity 33: 219-227.

Russo NL & Stolterman E (2000) Exploring the assumptions underlying information systems methodologies: Their impact on past, present and future ISM research. Information Technology & People 13: 313-327.

Sabherwal R & Elam J (1995) Overcoming the problems in information systems development by building and sustaining commitment. Accounting, Management, and Information Technologies 5: 283-309.

Sabherwal R & King WR (1992) Decision processes for developing strategic applications of information systems: A contingency approach. Decision Sciences 23: 917-943.

Salancik GR (1977) Commitment and the control of organizational behavior and belief. In: Staw BM & Salancik GR, (eds) New directions in organizational Behavior. St. Clair Press, Chicago, p 1-53.

Scholl R (1981) Differentiating organizational commitment from expectancy as a motivating force. Academy of Management Review 6: 589-599.

Searle JR (1979) Expression and meaning. Cambridge University Press, Cambridge. SEI (1999) Building Commitment, Software Engineering Institute, Carnegie Mellon University.

2001. Senge PM (1990) The Fifth Discipline. Century Business, Kent. Seppänen V (2000) Competence change in contract R&D: Analysis of project nets. Technical

Research Centre of Finland (VTT) publications, number 418, Otamedia, Espoo. Seppänen V, Komi-Sirviö S, Mäntyniemi A, Rahikkala T & Pikkarainen M (2001) Contexts of KM

based SPI: The case of software design experience reuse. Profes 2001, Kaiserslautern, Germany, 57-67.

Sheldon M (1971) Investments and involvements as mechanisms producing commitment to the organization. Adiminstrative Science Quarterly 16: 143-150.

Shenhar AJ, Dvir D & Levy O (1999) Project Success: A Multidimensional, Strategic Concept. Hoboken, NJ, Stevens Institute of Technology.

Shepherd JL & Mathews BP (2000) Employee commitment: academic vs. practitioner perspectives. Employee Relations 22: 555-575.

Simon HA, Smithburg DW & Thompson VA (1950) xx. Public Administration: 94-100. Sommerville I (2001) Software engineering. Addison-Wesley, New York. Staw BM (1976) Knee deep in the big muddy: A study of escalating commitment to a chosen

course of action. Organizational Behavior and Human Performance 16: 27-44. Staw BM (1981) The Escalation of Commitment to a course of action. Academy of Management

Review 6: 577-587. Staw BM (1982) Counterforces to change. In: Goodman PS, (ed) Change in organizations: New

perspectives on theory, research and practice. Jossey-Bass Inc., San Francisco, CA, p 87-121.

Page 161: The role of commitment in software process improvement - Oulu

159

Staw BM & Ross J (1987) Behavior in Escalation Situations: Antecedents, Prototypes, and Solutions. In: Cummings LL & Staw BM, (eds) Research in Organizational Behavior. JAI Press, Greenwich, Conn., p 39-78.

Staw BM & Salancik GR (1977) New directions in organizational behavior. St. Clair Press, Chicago.

Stelzer D & Mellis W (1998) Success Factors of Organizational Change in Software Process Improvement. Software Process - Improvement and Practice 4: 227-250.

Strauss A & Corbin J (1990) Basics of qualitative research. Sage, Newbury Park, CA. Suliman A & Iles P (1999) Is continuance commitment beneficial to organizations? Commitment-

performance relationship: a new look. Journal of managerial Psychology 15: 407-426. Susman GI & Evered RD (1978) An Assessment of the Scientific Merits of Action Research.

Administrative Science Quarterly 23: 582-603. Taylor WA (1995) Senior executives and ISO 9000 attitudes, behaviours and commitment.

International Journal of Quality and Reliability Management 12: 40-57. Tervonen I, Iisakka J & Harjumaa L (2001) A tailored capability model for inspection process

improvement. Asia-Pasicif Conference on Quality Software (APAQS), Hong Kong. Trahant B & Burke WW (1996) Creating a change reaction: How understanding organizational

dynamics can ease reengineering. National Productivity Review 15: 37-46. Van de Ven AH & Poole MS (1995) Explaining Development and Change in Organizations.

Academy of Management Review 20: 510-540. van Solingen R & Berghout E (1999) The Goal/Question/Metric Method: A Practical Guide for

Quality Improvement of Software Development. McGraw-Hill, Cambridge, UK. Vandenberg RJ & Self RM (1993) Assessing newcomer's changing commitments to the

organization during the first six moths of work. Journal of Applied Psychology 78: 557-568. Vandenberg RJ, Self RM & Seo JH (1994) A critical examination of the internalization,

identification and compliance commitment measures. Journal of Management 20: 123-140. Vardi Y, Wiener Y & Popper M (1989) The value content of organizational mission as a factor in

the commitment of members. Psychological Reports 65: 27-34. Weimer AI & Munyan RJ (2000) Recipe for a successful system: Human elements in systems

development. Software Quality Professional 14. Weiner Y & Gechman AG (1977) Commitment: a behavioral approach to job involvement. Journal

of Vocational Behavior 10: 47-52. Whitener EM & Walz PM (1993) Exhange theory determinants of affective and continuance

commitment and turnover. Journal of Vocational Behavior 42: 265-281. Wiener Y (1982) Commitment in organizations: a normative view. Academy of Management

Review 7: 418-28. Winograd T & Flores F (1987) Understanding computers and cognition. Addison Wesley, Reading,

MA. Wohlwend H & Rosenbaum S (1994) Schlumberger's software improvement program. IEEE

Transactions on Software Engineering 20: 833-839. Wynekoop JL & Walz DB (2000) Investigating traits of top performing software developers.

Information Technology & People 13: 186-195. Yamamura G (1999) Process improvement satisfies employees. IEEE Software 17: 83-85. Zahran S (1998) Software process improvement: practical guidelines for business success.

Addison-Wesley Pub. Co., Reading, Mass.

Page 162: The role of commitment in software process improvement - Oulu

Appendix I

Definitions of commitment (Mowday et al. 1982, pp. 20-21, Meyer & Allen 1997, p. 12): Definition Original source

Commitment comes into being when a person, by making a side-bet, links

extraneous interests with a consistent line of activity.

(Becker 1960)

(1) It includes something of the notion of membership; (2) it reflects the

current position of the individual; (3) it has a special predictive potential,

providing predictions concerning certain aspects of performance, motivation to

work, spontaneous contribution, and other related outcomes; and (4) it

suggests the differential relevance of motivational factors.

(Brown 1969)

A partisan, affective attachment to the goals and values of an organization, to

one’s role in relation to goals and values, and to the organization for its own

sake, apart from its purely instrumental worth.

(Buchanan 1974)

The nature of the relationship of the member to the system as a whole. (Grusky 1966)

The process by which the goals of the organization and those of the individual

become increasingly integrated or congruent.

(Hall et al. 1970)

A structural phenomenon which occurs as a result of individual-organizational

transactions and alterations in side bets or investments over time.

(Hrebiniak & Alutto 1972)

The willingness of social actors to give their energy and loyalty to social

systems, the attachment of personality systems to social relations which are

seen as self-expressive.

(Kanter 1968)

A state of being in which an individual becomes bound by his actions and

through these actions to beliefs that sustain the activities and his own

involvement.

(Salancik 1977)

An attitude or an orientation toward the organization which links or attaches

the identity of the person to the organization.

(Sheldon 1971)

Commitment behaviors are socially acceptable behaviors that exceed formal

and/or normative expectations relevant to the object of commitment.

(Weiner & Gechman 1977)

The committed employee considers it morally right to stay in the company,

regardless of how much status enhancement or satisfaction the firm gives him

or her over the years.

(Marsh & Mannari 1977)

The relative strength of an individual’s identification with and involvement in

a particular organization

(Mowday et al. 1982)

The totality of internalized normative pressures to act in a way which meets

organizational goals and interests.

(Wiener 1982)