Effects of intra-group conflict on packagedsoftware development team performanceSteve SawyerSchool of Information Sciences and Technology, The Pennsylvania State University,University Park, PA 16802 USA, email: [email protected]. Data from 40 packaged software development teams are used to testa path model that relates three antecedents, the presence of intragroup conflictand the level of conflict management to software development team performance.Findings indicate that a combination of the team’s characteristics, team membercharacteristics and existing levels of intragroup conflict accounts for nearly one-half of the variance between the best and worst-performing teams. Furthermore,the level of conflict management moderates the relationship between existinglevels of intragroup conflict and performance. These results highlight both thecomplexity of the social processes of packaged software development and thevalue of this perspective for gaining insight on software development performance.Keywords: Conflict, conflict management, packaged software, path models, soft-ware development, software development team performance, teamsINTRODUCTIONIntra-group conflict among members of a software development team is seen as bothinevitable and likely to lead to bad consequences (Brooks, 1974; Robey, 1984). There havebeen two general approaches to minimizing such conflict. In the software engineering litera-ture the typical approach is to hire the best individuals (Boehm, 1981; Walz et al., 1993). Theinformation systems development literature has emphasized conflict resolution and the selec-tion of people who are socially skilled to do so. The primary focus of this second line ofresearch has been to focus on the relationship between the team’s members and varioususers/external stakeholders (Robey, 1984; Robey et al., 1989; 1993). Both literatures suggestthat some combination of the ‘right’ skill blend (be they technical or social) will reduce thenegative consequences of conflict. Thus, the contemporary advice to software developmentmanagers is to hire ‘team players’ and to carefully assemble teams of ‘compatible’ people.We also believe that intragroup conflict is inevitable (Simmel, 1955). However, like others,we contend that conflict, if it is well managed, may improve the software development team’sperformance (Carmel & Sawyer, 1998; Zachary, 1998). From this perspective, the presenceof conflict is less important than how it is managed: if a team manages their intragroup con-Info Systems J (2001) 11, 155–178155© 2001 Blackwell Science Ltdflict well they should out-perform a team that does not, even if the relative levels of conflictare similar. This shifts the managerial emphasis from picking team members that can workwithout too much conflict to selecting team members who can work well in an open, and oftencontentious, social environment (McCarthy, 1995). The research reported on in this paperexplores:1 What factors most affect the level of intragroup conflict in packaged software developmentteams?2 What effects do these factors have on packaged software development team performance?To respond to these questions we draw on data collected from 40 packaged software devel-opment teams at one site of a large, global, computer software and hardware manufacturer.Selecting the teams from one site minimizes the potential confounding effects of varying indus-trial/organizational factors. That is, by selecting teams from one site, we know that they sharecommon production goals, have a common software development methodology and use thesame software development tools. Project managers for these teams are trained in the sametechniques and also report to the same senior managers.Studying packaged software development teams also allows us to explore the role ofintragroup conflict in a different context. Packaged software [also known as commercial,commercial-off-the-shelf (COTS) or shrink-wrap] is licensed for use by others (Carmel, 1997).Carmel & Sawyer (1998) argue that packaged software development differs from customdevelopment along a number of dimensions. The most pertinent of these dimensions for thispaper is the level of user involvement. As Keil & Carmel (1995) show, there is little directcontact between most developers and users of packaged software. This means existingmodels regarding the effects on intragroup conflict and performance due to the involvementand/or participation of users (i.e. Robey et al., 1993) cannot be used without some additionalconceptualizing.The paper continues in five sections. In the next section, we develop the concepts of intra-group conflict among the members of packaged software development teams (called conflictthrough the remainder of the paper), theorize about the antecedents to conflict and detail whatwe mean by software development performance. The second section lays out how these con-structs are measured. The research approach and data collection efforts are presented in thethird section, while the fourth contains the analyses and findings. The paper concludes witha discussion of the findings and their implications to software development management andresearch.CONFLICT AMONG SOFTWARE DEVELOPMENT TEAM MEMBERSIntra-group conflict is a general social phenomenon and the relevant literature contains severaldefinitions that encompass factors such as objective conditions, emotions, perceptions andbehaviour (Simmel, 1955; Pondy, 1967; Deutsch, 1969; Thomas, 1975; Green & Taber, 1980;Wall, 1987; Volkema & Bergman, 1989). Rather than attempt to argue the superiority of any156S Sawyer© 2001 Blackwell Science Ltd, Information Systems Journal 11, 155–178one specific definition, in this paper we treat conflict generically to be a difference betweentwo or more people about the meaning of some information (such as a requirement or need,an idea, or a decision). Thus, the existence of conflict indicates neither a positive nor nega-tive state, just a difference between how people interpret information (Simmel, 1955).Conflict management (also known as conflict resolution) is the process of resolving thesedifferences (Green & Taber, 1980; Sambarmurthy & Poole, 1992). The resolution of conflictcan lead to both positive and negative outcomes (Simmel, 1955; Deutsch, 1969). For example,Robey’s work on conflict among software developers posits conflict as a mostly negative effect(Robey, 1984; Robey & Farrow, 1989; Robey et al., 1989; 1993). Walz