Software process improvement with weak ... - Semantic Scholar

European Journal of Information Systems (2010) 19, 303–319 & 2010 Operational Research Society Ltd. All rights reserved 0960-085X/10 www.palgrave-journals.com/ejis/

Software process improvement with weak management support: an analysis of the dynamics of intra-organizational alliances in IS change initiatives Ojelanki Ngwenyama1 and Jacob Nørbjerg2 1 Institute for Innovation and Technology Management, Ryerson University, Canada; 2 Department of Informatics, Copenhagen Business School, Denmark

Correspondence: Jacob Nørbjerg, Department of Informatics, Copenhagen Business School, Howitzvej 60, Frederiksberg, DK-2000, Denmark. Tel: þ 45 3815 2478; Fax: þ 45 3815 2401; E-mail: [email protected]

Abstract Software Process Improvement (SPI) projects are large-scale, complex organization-wide change initiatives. They require considerable investments in personnel, time and money and impact just about every aspect of software firms. The group charged with conducting an SPI project has, however, little formal authority to influence or force software professionals to engage in SPI work or to define and implement changes. The SPI literature suggests that successful SPI initiatives depend on strong commitment from top management. But what should the SPI group do if management support is weak? In this paper, we present an analysis of how an SPI group can use alliances to obtain influence and succeed when management support is weak. Our study is based on a 3-year longitudinal field study of SPI change initiatives at Denmark Electronics. Our findings show that a lack of top management support is not necessarily incompatible with success. This research opens an important new area of research on intra-organizational alliances and information system (IS) implementation. It has the potential to offer new theories and practical advice on how IS implementation projects can be more effectively managed. European Journal of Information Systems (2010) 19, 303–319. doi:10.1057/ejis.2010.18; published online 27 April 2010 Keywords: Software Process Improvement; implementation management; change agentry; alliances; social capital; commitment

Introduction

Received: 29 December 2008 Revised: 1 October 2009 2nd Revision: 13 November 2009 3rd Revision: 28 February 2010 Accepted: 1 March 2010

Software Process Improvement (SPI) is an organizational change paradigm that focuses on improving the performance of software companies. Since the early 1990s, software firms globally have turned to SPI as a means to transform their organizations to improve the predictability, quality and productivity of their software processes (Paulk et al., 1993; Herbsleb et al., 1997; Aaen et al., 2001; Mathiassen et al., 2002). However, studies have shown a considerable failure rate for SPI projects (Ngwenyama & Nielsen, 2003; Hansen et al., 2004). SPI change projects are large in scale and complex in scope, requiring long time horizons and impacting several levels of management, different organizational departments and stakeholders (Mathiassen et al., 2002; Ngwenyama & Nielsen, 2003). The challenges of successfully managing SPI projects have been noted by several researchers (Humphrey, 1990; Borjesson & Mathiassen, 2004). Organizational politics, turf guarding and cynicism towards change processes are considered the most common challenges that SPI project

304

SPI, weak management support

managers face (Herbsleb et al., 1997). It has been suggested that strong top management support is absolutely necessary to overcome such obstacles and to achieve successful implementation (Markus, 1981; Thong et al., 1996; Markus & Benjamin, 1996; Sabherwal et al., 2006). The SPI literature recommends that responsibility for planning and conducting SPI should be organized around a separate organizational entity such as a dedicated SPI group or department (c.f. McFeeley, 1996). While this approach consolidates SPI knowledge competencies, methods and practices into a single consultative group, it carries disadvantages when implementing organization-wide SPI change initiatives. The SPI group often may not be high in the organizational hierarchy and thus may lack formal power and influence in the wider organization (Cohen & Bradford, 2003; Porter et al., 2003a, b). Further, other important stakeholders, such as software professionals and project managers may support or resist the SPI project depending on whether they view the SPI project as enabling or constraining the achievement of their goals (Abrahamsson, 2001; Nielsen & Nørbjerg, 2001). Several researchers have suggested that management support is a key factor in successful SPI initiatives (Humphrey, 1990; Dyba˚, 2003). However, many SPI projects are faced with the problem of weak top management support and how to proceed in this context. Further, there has been little investigation of the process of how top management support develops (Abrahamsson & Jokela, 2000). Recently, researchers have argued that intra-organizational alliances are critical to SPI success (Nielsen & Ngwenyama, 2002; Iversen et al., 2004) but there is little research on this issue in the literature. In this paper, we present the results of a study of how an SPI group cultivated and managed alliances with key organizational members as a means to sustain and further the SPI project goals under conditions of weak top management support. The paper is based on a 3-year longitudinal field study of an SPI project at Denmark Electronics (a pseudonym). Our analysis uses concepts from theories of social networks and social capital to explore some of the challenges that SPI managers face when trying to cultivate and maintain alliances in support of organization-wide SPI initiatives. Presently, there is little research that investigates how intra-organizational alliances might influence outcomes in information systems (IS) projects of any kind (Nielsen & Nørbjerg, 2001; Nielsen & Ngwenyama, 2002; Nørbjerg & Ngwenyama, 2005). During the last decade, Markus & Benjamin (1996) outlined the need for more research in the area. There is a body of organization theory literature on organizational alliances (Krackhardt & Hanson, 1993; Burt, 1997; Tsai & Ghoshal, 1998; Sparrowe et al., 2001; Porter et al., 2003a, b; Oh et al., 2004) that guides our investigations, but so far little IS research has focused on understanding how intraorganizational alliances might influence outcomes of IS projects. In this study, we are interested in understanding the dynamics of these alliances in organizational change

European Journal of Information Systems

Ojelanki Ngwenyama and Jacob Nørbjerg

situations in which the change agents lack power and influence due to weak top management support. We ask: What are the key features of intra-organizational alliances for SPI change management? How are these features related? How can these alliances be cultivated and sustained?

Alliances, social networks and social capital This research is informed by concepts from the theories of social networks and social capital. Our perspective is that intra-organizational alliances can be viewed as goal-oriented social networks through which partners leverage tangible and intangible resources (i.e., social capital) to achieve individual and mutual aims. These intra-organizational alliances can be characterized by strength of ties and duration. Strength of ties refers to the level of commitment to the alliance, duration to the temporality of the alliance. Several researchers have discussed how organizational members use alliances to influence others (Cohen & Bradford, 2003) and achieve successful outcomes in organizational settings (Cross & Cummings, 2004; Oh et al., 2004; Balkundi & Harrison, 2006). Alliances depend on the idea of reciprocity in that, organizational transactions are built upon the exchange of something for something else. Partners in an alliance must therefore agree on the ‘media of exchange’ or ‘currencies’ of exchange and their value for each. Currencies can be defined in broad terms to include capital assets as well as tangible and intangible resources; for example, being allowed to excel in what one knows well, appreciation, time and effort, increased visibility, information, friendship and inclusion in networks. A special type of currency that is of great importance to intra-organizational alliances is social capital (Oh et al., 2004, 2006). Social capital is the set of intangible social-structural resources, which forms the glue of intra-organizational alliances (Coleman, 1988, 1990). A central idea of social capital theory is that the network of social relationships itself is an enabler of the alliance partners as they seek to achieve outcomes within the organization. Social capital theory draws on concepts of social network relationships such as ‘the strength of weak ties’ (Granovetter, 1973), ‘the centrality of betweenness’ (Freeman, 1977) and ‘the power of exclusive exchange partners’ (Cook & Emerson, 1978). According to Burt (1992), social capital is a function of the brokerage opportunities in the alliance. It is a contextual complement to human capital: Whereas human capital is a quality of individuals, social capital is embodied in the social ties or in the structure of the relationship among individuals (Coleman, 1990; Bourdieu & Wacquant, 1992; Burt, 1992; Putnam, 1993; Lin, 1999). The central point is that there is a perceived value to network relationships, which has an impact on achieving outcomes beyond the capacity of any partner in the network. In an alliance, social capital can be considered to support intangible assets such as (1) organizational influence; (2) access to resources;


(3) access to scarce or strategic knowledge and capabilities; and (4) emotional support that results in mutual gain to the partners. According to Coleman (1990), like other forms of capital, social capital is productive, facilitating the achievement of collective and individual goals. Aspects of social capital important to our study are: (1) trust, commitments, norms and reciprocity; and (2) social structures and relationship ties that affect organizational outcomes (Coleman, 1988; Burt, 1992; Portes, 1998; Krishna & Uphoff, 1999; Lin, 2001). While we are interested in these aspects, our analysis is focused on understanding the dynamics of intra-organizational alliances, which can enable successful SPI (or IS) implementation when top management support is weak.

Dependencies and intra-organizational alliances Markus & Benjamin (1996) outlined a set of conditions that they considered ‘structurally incompatible’ with change agentry. These are (1) the absence of managerial authority over the target organization for change; (2) negative perceptions of the change agents by the target organization members; and (3) weak top management support for the IS change initiative. Kotter (1996) takes a similar position and suggests similar reasons for failure of organizational change projects. The difficulties of achieving successful change in conditions in which the change agents have no authority, direct or indirect influence, over the target organization have been discussed in some detail in the organization theory literature (Cohen & Bradford, 2003; Oh et al., 2004; Balkundi & Harrison, 2006). It is instructive to briefly illustrate the problem from an IS perspective. For example, suppose an IS manager B, is dependent on manager A for resources to complete an IS change activity, then A is in a position to exert influence over B. Therefore, if B needs access to resources over which A has control, B will have considerable difficulty getting access without A’s consent. In such a situation, B might need to offer A something in exchange for access. If A has formal authority over B, then it is fairly obvious that A has power over B; but, B might be in a strong position to negotiate with A if B can convince A that the change activity is in A’s interest. However, if they work in different departments at similar levels in the organizational hierarchy, then the task of convincing A to do what B wants is more complex. If A is busy or has no interest in spending time helping B, or if A’s and B’s goals conflict, then B has no immediate way to make A collaborate. Empirical research has pointed out that many IS change projects are subject to these very dependency conditions. In such situations, change agents find themselves being dependent on complex networks of relationships for the execution of their job functions; consequently, they must enter into intra-organizational alliances as a strategic necessity to ensure performance outcomes (Tsai & Ghoshal, 1998; Sparrowe et al., 2001). Two key features of such alliances are dependence and social capital (Tsai, 2000; Porter et al., 2003a). These alliances are often held


305

together by mutual interest in specific outcomes, trust, reciprocity and exchanges of value. For example, one partner might have knowledge (expertise, problem solving skills), while another has tangible resources (time, personnel), or intangible resources (friends in high places) that he or she can bring to the alliance. The key is that the partners must view these as appropriate and valued ‘currencies’ for exchange. An exchange of resources might also be what one of the partners in the alliance is seeking. However, if the exchange is a transaction that does not require a temporal relationship, it is not considered an aspect of an alliance. Long-term commitments and the time horizon for performance outcomes are essential features that affect the perceived value of the alliance. Alliances can collapse after any of the partners, having achieved their goals, decide that the alliance is of no more value. Consequently, managers could find that intra-organizational alliances require significant investments in time and communicative actions, which may be necessary in order to ensure organizational outcomes.

The case study research methodology This research uses a case study methodology. It has been convincingly argued that a single case study can falsify an existing theory (Popper, 1959; Campbell, 1975; Lee, 1989). Some researchers take the position that case studies can be useful for exploratory/explanatory research that contribute hypotheses for testing with nomothetic methods, but by themselves are too context specific to allow generalization (Benbasat et al., 1987). However, others have pointed out that case study research offers the possibility to generalize from empirical observations to theoretical statements (Eisenhardt, 1989; Walsham, 1995; Klein & Myers, 1999; Lee & Baskerville, 2003). Lee (1989) suggests four tests to validate the theoretical contribution of case studies: (1) Does the case study consider predictions through which the theory could be falsified? (2) Are all the predictions consistent with each other? (3) Does the case study confirm the theory through empirical evidence? (4) Does the case study rule out rival theories? Lee also suggests that satisfying any three of these four criteria is sufficient to validate the explanatory power of the new theory. This case study research satisfies all four criteria: (a) We derive a model that explains empirical observations of the dynamics of IS implementation alliances under conditions of weak or no top management support; (b) We postulate a set of four propositions grounded in empirical observations and consistent with the literature on organizational alliances that can be falsified in future testing; (c) Empirical evidence from our case studies rule out the knowledge claim that weak or no top management support is structurally incompatible with IS implementation success; and (d) We offer a more theoretically nuanced explanation of the dynamics of IS implementation success under conditions of weak or no top management support.


306


Data collection The data for our study were collected during a 3-year Collaborative Practice Research (CPR) project (Mathiassen, 2002) at Denmark Electronics. CPR is an extension of the Action Research approach (cf. Avison, et al., 1999) that emphasizes a close collaboration between practitioners and researchers. It aims to improve IS development practices as well as contribute to IS research (Mathiassen, 2002). The case study of Denmark Electronics was part of a larger 7-year longitudinal research project, of SPI implementation in eight Danish companies, conducted by an interdisciplinary research team from four universities. One of the authors collaborated with Denmark Electronics’ SPI practitioners and systems developers. He attended the regular meetings of the SPI group and participated with the software developers and project managers engaged in SPI initiatives. In CPR, as well as in Action Research in general, the researcher runs the risk of becoming too involved in the day-to-day activities and goals of the practical setting (Mathiassen, 2002). To counter this pressure and maintain a critical focus on the contribution to IS research, all researchers in the research project, including the authors of this paper, met regularly to discuss findings, research methodology and publication of results. Furthermore, CPR specifies systematic and rigorous data collection to ensure sufficient rigour of the research and provide the foundation for longitudinal studies of IS development (Mathiassen, 2002). We therefore systematically collected field notes and diaries, e-mails and other documents pertaining to the SPI project, tape recordings of meetings, and tape recorded and transcribed interviews with managers, SPI professionals, and systems developers. The empirical materials in this case study comprise meeting minutes, interviews with key stakeholders, researcher diaries, e-mails and company documents (see Table 1 and Appendix A).

Table 1


Data analysis method A necessary condition for effective interpretive analysis of qualitative data is an in-depth understanding of the meanings that actors ascribe to events in their social contexts (Van Maanen, 1988; Walsham, 1995). The longterm engagement with Denmark Electronics enabled longitudinal participant observation (Monge, 1990; Pettigrew, 1990) allowing one of the researchers to develop an intimate understanding of the organizational conditions at the company and to observe the interaction dynamics as the SPI project unfolded. The analysis of the data focused on deriving empirical observations relevant to three primary questions: What are the key features of intra-organizational alliances for SPI change? How are these features related? And how are these alliances cultivated and sustained? The analysis was conducted in several stages using techniques of thematic content analysis, critical incident analysis (Chell, 1998; Edvardsson & Roos, 2001) and interpretive analysis. A data analysis software tool, NUDIST, supported the content analysis and coding. During stage 1 of the analysis, all the empirical materials were analysed in order to build an understanding of the life cycle of alliances. Applying the principles of the Hermeneutic circle, of Abstraction and Generalization, of Dialogical reasoning and of Suspicion (Klein & Myers, 1999), we searched for other more general theoretical concepts through which we could build a richer interpretation of our data. We iteratively repeated the analysis and revised the coding guided by the concepts from the theories of social network and social capital looking for empirical observations of the themes of interest (alliances, trust, commitment, currencies of exchange and social capital). Via this process, we identified three alliances and 191 empirical observations concerning them (cf. Appendix A for a sample). We then analysed and sorted the empirical observations into categories and identified relationships

List of empirical materials

Empirical materials

Media

Explanation

Meeting minutes (MM)

Almost all electronic

(1) Meetings in SPI group and sub-groups (2) Meetings with projects involved in specific improvement actions (3) Meetings in research group

Interview transcripts (IN)

Electronic/paper

Interview transcripts: (1) Interviews with participants in particular improvement activities (2) Final interviews with project managers (3) Final interviews with senior managers

Diaries (DI)

Almost all electronic documents

Reflections from participation in activities. Written on the same or following day based on field notes.

Emails (EM)

Electronic documents

(1) (2) (3) (4)


Meeting agendas Comments to draft reports and minutes Discussions/comments/frustrations exchanged among researchers Time schedules and plans


among them. In the final stage of the analysis, we used the findings from previous stages to help identify critical incidents concerning each alliance. For example, the formation of the alliance, threats to the alliance or the collapse of the alliance. For each critical incident we identified, we conducted an exhaustive search of the empirical observations to identify any specific references to the incident. The findings were coded and the passages were analysed and interpreted to derive empirical observations about critical incidents concerning each alliance. The final analysis produced a set of 90 relevant empirical observations upon which our present analysis is based.

Case description Denmark Electronics develops and produces leading edge measurement instruments and systems. A typical product would be a measuring instrument such as a thermometer, microphone or accelerometer connected to a handheld or desktop computer equipped with analysis and presentation software. The focus of our case study is the Development department, which is headed by a technical director. Shortly before the commencement of the SPI project, a new director had been appointed but was then replaced about halfway through the project. Development projects have both hardware and software components, but are managed by one project manager. A local champion had previously worked with SPIs in specific areas at Denmark Electronics; for example, testing, and requirements specification, in collaboration with outside researchers, but the organization had not been involved in organization-wide SPI projects before. Six months prior to commencing the SPI project, a bootstrap maturity assessment (Haase et al., 1994) gave an overview of the overall software process problems in the organization. There was no follow-up to the assessment.

Figure 1


307

The SPI project at Denmark Electronics was organized around an SPI group responsible for the identification of improvement areas, organization of improvement initiatives, reporting of results and the dissemination of new processes in the organization. Members of the group were project managers and improvement agents from the company and external consultants and researchers. A project manager was appointed as leader of the group. The technical director participated in some of the group’s meetings. During the SPI project, there were around 7–10 active development projects at any one time, lasting 6–18 months each and staffed with 5–10 software developers. Early on, Denmark Electronics’ own SPI professionals suggested to link improvement initiatives to ongoing projects. Support teams with members of the SPI group would introduce new processes into a software project and collect the developers’ subsequent experiences (see Figure 1). In this way, new processes would be tested (and adapted) before inclusion into the quality system and general rollout. This approach was accepted among the three important stakeholder groups: developers, project managers and top management. The SPI project activities were conducted in three phases: (1) Identification of improvement initiatives, (2) Improvement initiatives, and (3) Re-assessment and planning new initiatives.

Identification of improvement initiatives In order to identify and prioritize SPIs, the SPI group needed precise knowledge of the character of current processes and problems. The bootstrap assessment had identified a number of general process problems, but the precise nature of the problems or their causes was not clear to the SPI group. The assessment identified, for example, that the projects did not follow a common development process, but did not explain why the

Organization of the SPI project at Denmark Electronics.


308


documented process was not used, or which process better fit the needs of the projects. The SPI group therefore decided to launch a series of interviews with project managers to identify problems and collect suggestions for solutions (Iversen et al., 1999). The interviews focused on existing practices, software process problems identified by the project manager and the project manager’s suggestions on how to solve the problems. The interview series resulted in a report summarizing the SPI group’s interpretation of Denmark Electronics’ process problems and a list of suggested improvements that included an iterative software process model, requirements specification and reuse. The SPI group presented the report to project managers and top management at a workshop in which the project managers selected the issues they wanted to address in their current or upcoming projects.

Improvement initiatives Four improvement initiatives were implemented over the next 2 years: (1) Iterative development process, (2) Requirements specification, (3) Software code reuse, and (4) Software configuration management. Initiatives (1) and (2) were successful, while initiatives (3) and (4) failed (see section about the project manager alliance for a discussion of these outcomes). Each of the initiatives was associated with one or more development projects and was followed by a support team (see Figure 1). The support teams met regularly with the development groups to coach them in processes, techniques and tools, and to collect information about the projects’ progress and the developers’ experiences. The support teams also suggested changes to software development practice or ways of adjusting the process descriptions as and when needed. The resulting processes were ultimately described and included in Denmark Electronics’ quality system.

Re-assessment and planning of new improvements With the conclusion of the ongoing improvement projects, it was time to take stock and plan future activities. A second bootstrap assessment by outside assessors not only confirmed that improvements had been made in some areas, but also pointed to new or so far unaddressed problems. The previous approach (work with individual development projects) was tried once more but without success. The SPI group realized that it did not quite know how to proceed and decided to make a second round of interviews with both project managers and top management to get an evaluation of the SPI project and solicit ideas for new initiatives. During and after the interview series, the SPI group also unsuccessfully attempted to commit top management to future SPI initiatives. With key SPI persons leaving Denmark Electronics and dwindling support from top management, Denmark Electronics’ SPI project was terminated 3 years after it commenced.



Alliances in the SPI project Very early in the project, it became clear that the SPI project’s success depended on three stakeholder groups: upper management, the project managers and the software developers. The SPI group considered the project managers a powerful group whose support was critically important to the success of the SPI project: We must sell the SPI project to three groups: top management, project managers, and the project team. Top management [support] provides us with resources and visibility, but the [project managers] are key to success because of their power. [Diary notes, researcher]

The SPI group attempted to build alliances with all three groups at different points in time. Productive alliances were established with project managers and development teams, but never with management. The following sections describe and offer analysis of each of these alliances (in the case of development teams through analysis of one example), using the categories and concepts described above. Together, the descriptions and analysis illustrate different approaches to building and maintaining alliances, as well as how the context and conditions of an alliance affect its sustainability.

The project manager alliance The organizational model of SPI in Denmark Electronics anchored improvement initiatives in development projects. SPI initiatives, therefore, depended on the project managers’ participation and support. The SPI group had, however, only limited resources and authority with which to influence the project managers, and top management provided no incentives and gave no directives that the software development project managers should engage in SPI. On the other hand, the project managers were a powerful group, very aware of their crucial role in delivering the quality products that Denmark Electronics relied on. The only dark cloud is the power the [project managers] hold in the organization. There will be problems if they don’t buy-in to the improvement activities. [Meeting Minutes, SPI researchers]

The project managers were skeptical of SPI despite the clear indications of problems in Denmark Electronics’ software processes: delays, faulty products, and poor project planning and oversight. The project managers, however, blamed the problems on unrealistic expectations from the sales and marketing departments and overly bureaucratic planning processes outside their control. The lack of tangible results from previous SPI studies and attempts to address software process problems added to their skepticism. The project managers were not interested in SPI. They were sceptical towards the practical value of the results of [the internal SPI champion’s] studies. [Interview with the first technical director]


The SPI group had to convince the project managers that process improvements were needed and possible, and that collaborating with the SPI group could contribute to this. To do so, however, the SPI group needed detailed knowledge about development practices and problems at Denmark Electronics. The SPI group members knew about general software development and management techniques and approaches, but lacked the detailed knowledge required to tailor the general techniques and approaches to the project managers’ needs. The series of project manager interviews provided this insight and when the SPI group presented the results of the interviews, it was clear that the project managers accepted the interpretation of their process problems and suggestions for improvements [Meeting minutes, SPI group]. Engaging in improvement initiatives is not without costs and risks. There is an initial investment in time to learn and adapt to new processes and techniques and there is a risk that the new processes are no better, or even worse, than those they replace. The project managers, therefore, requested explicit approval from upper management to include the improvement effort in their project estimates and plans. The project managers are willing to participate in improvement initiatives provided they get sufficient resources or project plans are renegotiated to make room for the extra improvement work. [Meeting minutes, SPI group]

Upper management never granted this, but several project managers became sufficiently convinced that the processes suggested were at least as good as their current practices, that they were willing to participate anyway: You presented a new [development model] that appeared to meet our needs, contrary to our usual [waterfall] approach. It was worth trying. [Project manager]

During the following 18 months, the SPI group worked with individual project managers and teams, introducing new methods, tools and techniques into the software process. The work was successful in some cases insofar as other projects would solicit experiences and apply the new processes in their own projects, and the processes were eventually included in the company’s quality manual. Creating an interest in improvements and working directly with the projects seems to work fine. Projects are soliciting experiences across improvement initiatives, and the researchers have the resources and knowledge necessary to help [projects] adopt the new techniques. [Meeting minutes, SPI researchers]

After completion of the first round of improvements, the SPI group attempted to apply the project-centred approach once more in a new set of initiatives, but this


309

time without success. Several factors, which the SPI group did not comprehend at the time, contributed to this lack of success. First, the SPI group had failed to actively publicize its activities and achievements beyond the actively involved teams and project managers, resulting in the SPI project becoming gradually less visible in the organization. Too many improvement initiatives in too little time with too little visibility. Perhaps ‘dictates’ would give better results? (Project manager)

Second, a move towards shared hard and software platforms in Denmark Electronics’ products resulted in increasing dependencies and collaboration across development projects. Cross project collaboration has improved over the past year. Demarcations are broken down. The projects have not been able to survive without each other. [Project manager]

The changing nature of improvement initiatives added to the need for coordination: The successful initiatives from the first round, process models and requirements specification focused on individual projects, but the new initiatives, for example, reuse and configuration management required coordinated action across projects. Project managers and developers would no longer be free to (individually) adapt processes to solve their own problems, but had to coordinate with others. Individual project managers would need to give up the autonomy that they had previously enjoyed in order to further improve Denmark Electronics’ software processes. Perhaps someone ought to force us to adopt some of these processes. Common processes result in common descriptions [and] you don’t have to start all over in a new project. With all these advantages, why don’t we do it? One would have to give up one’s own authority over the project. [Project manager]

In a social network perspective, therefore, the SPI group would have had to replace the existing approach based on alliances with individual project managers with a more complex structure involving groups of project managers. Individual commitment and voluntary involvement are probably not sufficient to sustain such a network. Some form of visible management involvement is required. Neither did the SPI group acknowledge this at the time, nor did they know how to approach the problem.

Project group alliance Each improvement initiative was anchored in ongoing development projects as described above. A project group applied a new or changed process and a support team helped fine-tune the process into a new common process for the whole. This arrangement can be seen as a social network between the support team and a software project


310


group: The support team offers the partner training or other knowledge needed to improve the project group’s software process. The group invests the time and effort needed to apply the new process in daily work and allows the support team to collect and systematize the experiences gained. The end result is a tested and verified (improved) software process to be rolled out in the rest of the organization. While this approach – if successful – improves the performance of the project group, it also incurs risks and extra work without guaranteeing a useful outcome. All that the support team has to offer is knowledge that may or may not improve the group’s performance, while the group must invest time and effort to learn and adapt to the new processes and provide feedback to the support team, thus running the risk of project delays and/or poorer product quality. The project managers had all committed to participating in at least one improvement initiative, as explained above, but the commitment was informal and the project managers and their groups could back out any time without sanctions. This dilemma was very clear in some of the interactions with the project groups at Denmark Electronics, as illustrated in the following comments from an initial meeting with a team: [Question from project group:] How many resources do we get from the [support team]? Will they; e.g. participate in [requirements gathering activities]? What are the success criteria for the improvement initiative?’ [Email from member of support team]

In some cases, the support team was able to reduce the project group’s skepticism by pointing to past successes. In the area of requirements engineering, for example, previous improvement initiatives in Denmark Electronics had already demonstrated the usefulness of a number of specific techniques. The support team could persuade others to invest the time and effort needed to adapt and fine-tune a new requirements engineering process based on those techniques. In other cases, the benefits of the suggested changes were less obvious to the project group. In the case of development process models, for example, everybody agreed that an iterative development process would fit Denmark Electronics’ needs better than the waterfall process, then in use, but it was less obvious what kind of iterative process would work. All the SPI group had to offer was a general overview of iterative approaches to software development, not a ready-to-use process. It was up to the development project – helped by the support team – to adapt the iterative approaches to its own needs. The support team, on the other hand, needed frequent access to the project group in order to learn about the actual application of the iterative processes. Not surprisingly, the software developers questioned this, as e-mails and minutes from this period reveal. At the initial meeting with the support team, there was a long discussion about the expected outcome of the improvement activities, and the developers wanted



confirmation that the new processes would be better than the old [Meeting minutes, SPI group]. In subsequent meetings, the project group frequently asked for detailed advice about issues unrelated to the improvement of the project such as questions about planning and follow-up techniques, or for the support team to review the user interface and systems architecture. However, the members of the support team did not want to give detailed advice on how to solve projectspecific problems unrelated to the improvement initiative. To them, the purpose of the collaboration with the project group was to define a new company-wide development process based on the team’s experience. [There was] renewed discussion of the [support team’s] role. The [members] of the [support team] are there to collect and disseminate results beyond the project based improvement initiative. They do not have infinite resources to act as consultants. The project – on the other hand – needs to feel that the [support team] contributes with solutions/help; e.g. references, advice, consulting.’ [Meeting minutes, SPI group]

The support team was not immediately prepared to meet all the developers’ requests, leading to a series of minor crises in the collaboration, as illustrated in the following minutes from a meeting in the support team: The project group expects active response and feedback from the [support team] who, on the other hand, has been concentrating on collecting and systematizing experiences. The group requests advice and guidance beyond what the [support team] sees as the scope (development models) [of their involvement], [and] the project group may not have understood what the [support team] needs. [Meeting minutes, SPI group]

These disagreements about each partner’s contribution to the network led to insecurity and skepticism in the project group about the purpose of the collaboration: [There is a] feeling of insecurity about the purpose of the meeting and the success criteria for the collaboration. [Minutes from meeting between support team and project group]

The turning point came when the support team pinpointed a problem in the project group’s approach to planning and estimation. The support team did not suggest a specific solution or recommend specific techniques, but suggested that the software developers follow a different approach [Researcher diary notes]. This changed the meetings with the software project group into a combination of coaching and experience gathering. The project group reported progress and described their work and the problems they had encountered. The members of the support team recorded their experience and gave advice about how to overcome problems and fine-tune the process, but without going into details


about the specific solutions. This mode of collaboration between the support team and the development team lasted until the development project was cancelled due to changes in Denmark Electronics’ product strategy.

Upper management alliance failure Management support for SPI projects is obviously important since management grants the SPI project the resources and ‘rights’ to work with the organization’s software processes. From a management perspective, however, SPI is a long-term investment in improved productivity, predictability and product quality but yields few short-term results. This proved to be a challenge as the technical director for software development changed twice during the SPI project. One technical director was appointed shortly before the SPI project started. The SPI project was, in his own words, ‘already on the table’ [Interview with the first technical director] when he assumed his position, but it was never high on his list of priorities. The SPI group experienced his lack of interest in several ways: First, he allocated relatively few resources to the SPI project. Second, it was difficult to get a clear statement about Denmark Electronics’ purpose and vision for the SPI project, and finally he would not allocate time to improvement initiatives in projects. While the SPI group realized that they needed the attention and active support of top-management, they did not know how to cultivate it. At an early stage, the SPI group considered informing top management about the project’s plans and progress, but as the interview series with the project managers commenced, the SPI group more or less ceased to think about top management and concentrated on the interviews. Unknown to the SPI group at the time, this decision almost caused the cancellation of the SPI project. The technical director began to see the SPI project as a ‘pain in the butt’ that made no real progress in any useful direction. He did not understand the purpose of the interviews, but saw them as merely ‘studying the fish in the aquarium’, and he seriously considered breaking the contract with the external researchers and withdrawing Denmark Electronics from the project [Interview with first technical director]. The presentation of the interview results changed the technical director’s opinion. He now saw a purpose and direction in the SPI group’s work and he accepted the subsequent improvement initiatives in development projects, but there still wasn’t much interaction between the SPI group and upper management. The appointment of another technical director about a year into the SPI project did not change much from the SPI group’s point of view. Denmark Electronics went through some major organizational changes (including lay-offs) and the SPI group was busy with improvement projects. Signals from upper management indicated to the SPI group that the new director found SPI important [Meeting minutes, SPI group], but attempts to establish closer contact and a regular reporting routine failed. Early in the second year


311

of the SPI project, the technical director began to cancel meetings and did not attend SPI seminars and discussions. To the SPI group, this indicated that top management had no real interest in their work [Meeting minutes, SPI group]. In an interview towards the end of the SPI project, the new technical director acknowledged that SPI had produced positive results so far, but he was critical towards what he saw as the SPI group’s theoretical approach [Interview with second technical director]. He stated that he preferred practical initiatives; for example, tools and techniques based on the immediate needs of projects. He was also convinced that the development organization was capable of defining and implementing improvement initiatives without an SPI group, and he proposed to replace the SPI group with interest groups and committees of project managers around different topics [Interview with second technical director]. It was clear to the SPI group that management support and commitment to SPI was crucial for sustaining crossproject improvement initiatives. But the SPI group lacked the ability to build and maintain an alliance with upper management and this contributed to the cancellation of the SPI project at Denmark Electronics. The SPI group had focused on project managers and development groups with good results, but the work and the results were largely invisible to management, which had lost track of the SPI project’s purpose and strategy, and was withdrawing its support. The poor management visibility and their apparent lack of interest in continuing the SPI project indicate a lack of success [of the SPI project]. We believe that our strategy [working with projects etc.] has been a success, but the approach is not visible to management. On the other hand, we need management backing to disseminate results [from improvements/changes in one project] to the rest of the organization. [Meeting minutes, SPI group]

Discussion of the findings The empirical analysis of this case study provides some interesting insights into the dynamics of intraorganizational alliances in the context of weak top management support. While it is generally believed that organization-wide IS change initiatives would fail in the absence of strong top management support (Markus, 1983; Jarvenpaa & Ives, 1991; Markus & Benjamin, 1996; Thong et al., 1996; Sabherwal et al., 2006), our findings suggest that IS change agents have the potential to achieve success in conditions of weak top management support if they are able to build and maintain intraorganizational alliances with key stakeholders. Intraorganizational alliances provide IS change agents with social capital and material resources, which may be denied to them due to weak top management support. Social capital also results in a level of organizational influence for change agents beyond that which accrues from position and top management support. However,


312



Trust

ALLIANCE Commitment

Currencies of Exchange

Figure 2

Partner

Partner

Mutual Aims/ Performance Outcomes

SOCIAL CAPITAL

Dynamics of managing alliances in the SPI change initiatives.

the building and maintenance of such alliances require close attention to two core issues: (1) cultivating and enrolling partners for attaining specific organizational outcomes, (2) cultivating and managing the level of trust and commitment. Since alliances evolve due to the changing concerns of the partners, individual status and organizational situations, all three issues must be dynamically managed, lest the alliance fails. Our analysis of the data revealed the importance of four factors, trust, commitment, currencies of exchange and social capital. These are critical to the cultivation and maintenance of alliances for the achievement of mutual aims and performance outcomes. Figure 2 provides a graphical illustration of the relationships among these key concepts.

managers and software developers by offering to exchange knowledge and expertise for their time and resources and also access to the software processes and development projects. This alignment of interests between the SPI group and the software developers and project managers was essential to developing the alliances. This finding suggests the following theoretical proposition:

Cultivating and enrolling partners The SPI group was able to build two successful alliances in spite of weak top management support and little initial organizational influence. A key factor in building these alliances was developing understandings with their partners that they could together achieve their individual and mutual performance outcomes. An alignment of interests between the SPI group, project managers and software developers did not appear natural at the start. From the perspective of the software development group, the conditions of an alliance were not compelling. As a rule, SPI requires significant investments in time and effort by software professionals long in advance of any returns. The fundamental question for this analysis is: Why did the software professionals at Denmark Electronics accept these conditions and collaborate with the SPI group? A key finding of our analysis suggests that the SPI group, through their initial interviews, was able to identify and articulate a set of problems essential to software quality that were of interest to the developers. Second, the SPI group was able to offer solution strategies that the project managers and software developers found compelling. Third, the SPI group was in a position to offer knowledge and expertise that might help the software developers excel professionally. In this regard, the developers and project managers saw that an alliance with the SPI group could be valuable in achieving their individual goals. Thus, the SPI group was able to enrol the project

Two important issues in enroling partners in an alliance are the perceptions that: (a) the alliance could result in the achievement of mutual aims and individual performance outcomes; and (b) the partners bring to the alliance some ‘currencies of exchange’ relevant to each other. In this case, the project managers had resources and access to the very software processes that the SPI group needed to change to achieve the performance outcomes. On the other hand, the software developers had more pragmatic goals than the project managers. They were interested in knowledge and expertise on how to implement specific methods, techniques and software processes. This alignment of interests enabled the SPI group to negotiate for SPI support teams to be embedded with the project groups and to provide their knowledge and expertise in exchange for access to the software developers and data about their performance in specific development activities. The failure to build an alliance with the technical directors also supports P1. While one factor contributing to this failure was a change of technical directors between conception of the SPI project and its start date, there are others that relate to the issues discussed here. First, the new technical director had different goals than the SPI project leaders. Second, being a new director for software development he was more interested in ‘learning the ropes’ and ‘putting his stamp’ on the software development department. Initially, the SPI group was unable to


P1:

When potential partners of an intra-organizational alliance for IS change perceive the potential value of the alliance as high, they are more likely to engage in and cultivate the alliance.


identify a problem that the technical director found compelling enough to warrant collaboration. While the technical director was aware of the SPI group’s contributions in the past, their blunders in trying to communicate a clear vision for the project that he could align with, most likely led to his weak support. Further, he did not view the SPI group as having any technical expertise that could enable him to excel professionally. He also stated in meetings that they were not practical enough. Initially, the new technical director allocated very few resources to the project and none of his time. It was not until after the SPI group presented the results of their interviews and he could see how their involvement could improve software development that he reluctantly lent temporary support. As Cohen and Bradford (2003) point out, when potential partners do not see how the alliance can assist them in achieving a higher level of performance, they are unlikely to participate. Given the technical perception of the SPI group’s expertise and lack of vision for the SPI project, there was no potential for an alliance.

Managing trust and commitment While the SPI group succeeded in enroling the project managers and software developers into an alliance based on an alignment of interests, maintaining trust and commitment in the alliance required careful attention. Initially, building trust in this alliance was difficult because the software developers wanted detailed instructions on how to use specific techniques and implement specific software processes. But, the SPI group and researchers did not want to play the role of consultants and take responsibility for outcomes. Eventually, however, trust and commitment in the two alliances were built through communication and dialogue in various meetings. In these meetings the partners conducted detailed assessment of software practices, and developed and planned improvement strategies. The SPI group also communicated information about their prior successes in helping other software developers at Denmark Electronics achieve quality improvements and made it a point to spread information about their successes throughout Denmark Electronics. This influenced potential partners and increased their reputation. Further, while the general practice of SPI groups was to offer training and leave the software developers on their own to implement SPI, the Denmark Electronics SPI group signalled commitment to the alliances by embedding SPI support teams in the software development projects offering frontline day-to-day support. The SPI group also convened monthly to discuss and resolve problems with the project managers and developers. The SPI researchers attended all these meetings and maintained weekly contact with the SPI group and the participants of each SPI initiative. The level of commitment exhibited by the SPI group was influential in achieving a high level of trust in these two alliances. This is especially important given that the SPI group was not able to develop and maintain


313

an alliance with upper management (which we will shortly discuss). Another finding from our analysis is t hat trust and commitment are essential to a successful alliance in the absence of strong top management support. This is because the partners are risking time and other resources on a project that might appear to be weakly sanctioned (or not sanctioned) by top management. Consequently, trust and commitment take on greater importance to the parties. Two basic propositions emerge from this analysis: P2:

When there is a high level of trust among the partners in an intra-organizational alliance for an IS change, there is likely to be a high level of commitment to the alliance.

P3:

When trust and commitment among the partners in an intra-organizational alliance for change is high, the alliance will be strong.

Maintaining trust and commitment is challenging due to emerging organizational situations and contingencies. Shifting interests and goals of the partners, and interference from other organizational actors, can all lead to breakdowns in trust and commitment. For example, trust can breakdown due to perceptions of shirking (under-performance) by any of the partners. At different times during the project, the software developers felt that the SPI group was not providing them with the help they needed. On the other hand, the SPI group did not want to be consultants. These differences of opinions challenged trust in the alliance, and the SPI group had to proactively engage in changing the expectations of the developers in order to maintain trust. Other threats to an alliance could be: (1) cooptation; (2) diminished or diminishing mutual gain; (3) breakdown in trust due to shirking of responsibility. Cooptation can occur when other interested parties entice a partner away from the alliance by offering better access to resources, providing more expert knowledge, or a higher level of organizational influence. Maintaining an alliance requires significant attention as organizational situations, contingencies, and the goals and interests of partners change over time.

Social capital resulting from the alliance One key outcome of the SPI alliances at Denmark Electronics was the level of social capital that accrued to the partners of the alliance. The social capital grew out of a long process of interactions within and without the organization and eventually emerged from different sources: First, the project managers had organizationwide social influence (e.g., with upper level management) within Denmark Electronics that was leveraged to unblock obstacles. Second, the software developers within the project groups also had social connections across project groups. In this way, they could share ideas about the success (or failure) of any new method, technique or,


314


software process, which the SPI group was trying to implement. Positive stories shared by software developers assisted the SPI group in more rapidly gaining access for new initiatives. The SPI group had connections to the SPI researchers who in turn had interactions with other SPI groups in a range of Danish companies. The SPI researchers were also well known internationally, and had connections to other well-known European and North American SPI researchers. Thus, the SPI researchers enhanced the credibility of the SPI group at Denmark Electronics. However, there was a continuing tension, as the SPI researchers did not want to provide consulting support for the project managers or software developers. The strength of the two alliances and the social capital that emerged contributed to the achievement of individual and joint outcomes of the SPI group, project managers and software developers. This finding suggests the following proposition: P4: When the intra-organizational alliance is strong and social capital is high, the IS change initiative is most likely to succeed. It is also important to observe that while the failure of the SPI group to build an alliance with upper management did impact the performance of the SPI group in some ways, it did not inhibit the implementation of SPI in the wider organization. This is because of the social capital that the SPI was able to accrue and mobilize to their advantage. The literature on alliances and social capital have provided three main arguments for the effectiveness of alliances and social capital approach to organizational change: (1) the development of mutual trust among actors who might otherwise be in conflict; (2) the development power and influence that could help in changing opinions in the organization; and (3) access to resources, information and opportunities. For example, Coleman (1988) and Putman (2000) argue that the level of mutual trust developed in alliances such as those in our case facilitates exchange and collective action (see also Zaheer et al., 1998). Burt (1992, 1997) argues that social capital helps partners in an inter-organizational alliance to bridge ‘structural holes’ and gaps in organizational influence (see also Reagans & Zuckerman, 2001; Cummings & Cross, 2003; Klein et al., 2004; Oh et al., 2004). Brass (1984), Cohen & Bradford (2003), and others have explained how inter-organizational alliances could lead to greater power and influence and success in pushing difficult programmes through the organization. Friedkin & Johnsen (1999) provide some insights on how such alliances can influence opinion change in organizations. Burt (1992) and Pelled et al. (1999) suggest that inter-organizational alliances can provide information benefits. Granovetter (1973) points out that ties in alliances provide the partners access to a broader array of ideas and opportunities for solving difficult problems. Podolny & Baron (1997) outline how actors can mobilize resources that accrue from inter-organizational alliances.



Conclusion While this research comprises three examples of alliances (two successes and one failure) in a single organization, the empirical evidence compellingly refutes the generally accepted knowledge claim that weak or no top management support is structurally incompatible with successful IS implementation and change projects. Further, our cases demonstrate the importance of intra-organizational alliances to IS implementation success under conditions of weak or no top management support. Although research has advanced along different lines, until now, little attention has been given to investigating how intraorganizational alliances and organizational influence processes impact implementation success. IS and SPI research emphasize the importance of top management commitment for success of change initiatives, but our study shows that change agents can be successful even under conditions described as structurally incompatible with success. The structural conditions of the SPI group at Denmark Electronics were characterized by weak top management support and low status, factors that the current IS theory deem incompatible with successful implementation. Nonetheless, this SPI group was able to achieve success for their implementation initiatives by enroling partners in building and maintaining intraorganizational alliances. The findings from our case analysis suggest a basis upon which IS managers can cultivate and manage intra-organizational alliances. However, our analysis also demonstrates the risks involved in conducting IS change initiatives under such conditions. This research offers a new and potentially fruitful direction for empirical research on IS implementation management. As we have illustrated, the theories of intra-organizational alliances and social capital offer useful frameworks for unravelling some of the puzzles of IS implementation effectiveness. While we were able to articulate some critical factors affecting the cultivation and successful management of these alliances, there are still many open questions. For example: (1) What sorts of alliances are most effective under differing conditions of weak top management support? (2) Are different types of intra-organizational alliances required for different types of IS implementation and change projects? Here, a specific question for empirical research could be: Are effective intra-organizational alliances for Enterprise Resource Planning implementation and SPI implementation different? (3) Is there value in intra-organizational alliances when there is strong top management support? In this regard, the theories of social networks and social capital offer a fertile set of concepts to help us build understanding about lateral and indirect influence processes of the type often required in IS change projects. We also believe that an improved understanding of alliances, their formation, maintenance and termination can provide useful practical advice for IS and SPI change agents.



315

About the authors Ojelanki Ngwenyama is Director of the Institute for Innovation and Technology Management, Ted Rogers School of Management, Ryerson University. Ngwenyama’s current research focuses on organizational learning and software processes in software development organizations. He holds an M.Sc. from Roosevelt University; M.B.A. from Martin J. Withman School of Management, Syracuse University and Ph.D. from Thomas J. Watson School of Engineering, State University of New York; and Ph.D. (honoris causa, 2009) from the Faculty of Engineering, University of Pretoria, South Africa. His papers have appeared in a range of international scholarly journals. In 1996 he and Kweku-Muata Osei-Bryson won the ANBAR Excellence Award for their research; and in 1997 he and Allen Lee won the MISQ Best Paper Award. Ngwenyama is co-author of the book Learning To Improve: Software Process Improvement In Practice (Addison Wesley Press, 2001). He was an associate editor for MISQ (2001–2004) and is a member of the Editorial Advisory Board of the Scandinavian Journal of Information System, Journal of Information Technology For Development and Information Systems Journal. He has also served on the editorial boards of the Journal of Information Technology and People and Journal of the Association of Information

Systems and ICIS. Ngwenyama has been a member of IFIP Working Group 8.2 (Organization and Societal Implications of Information Systems) since 1986. E-mail: [email protected]. Jacob Nørbjerg is an associate professor at the Department of Informatics, Copenhagen Business School. His research is directed towards the organization and management of systems development, knowledge management and software process improvement. Much of his research is carried out in close collaboration with industrial partners. He has published at several international conferences and journals, including the International Conference on Software Engineering, European Conference on Information Systems (ECIS), the Database for Advances in Information Systems, Information Systems Journal and Scandinavian Journal of Information Systems. He has served as a member of programme committees of international conferences, including ECIS, Information Resources Management Association and ISD and a reviewer for MIS Quarterly, Scandinavian Journal of Information Systems, Journal of Cases in Information Technology, the International Conference on Information Systems and others. E-mail: [email protected].

References AAEN I, ARENT J, MATHIASSEN L and NGWENYAMA O (2001) A conceptual MAP of software process improvement. Scandinavian Journal of Information Systems 13, 81–102. ABRAHAMSSON P (2001) Rethinking the concept of commitment in software process improvement. Scandinavian Journal of Information System 13, 37–61. ABRAHAMSSON P and JOKELA T (2000) Development of Management Commitment in Software Process Improvement. In Proceedings of the 23rd Informations Systems Research Seminar in Scandinavia (SVENSSON L, SNIS U, SØRENSEN C, FA¨GERLIND H, LINDROTH T and MAGNUSSON M Eds), pp 487–506, University of Trollha¨ttan Uddevalla, Sweden. AVISON D, LAU F, MYERS M and NIELSEN P (1999) Action research, Communications of the ACM 42(1), 94–97. BALKUNDI P and HARRISON DA (2006) Ties, leaders, and time in teams: strong inference about structure’s effects on teams. The Academy of Management Journal 49(1), 49–68. BENBASAT I, GOLDSTEIN DK and MEAD M (1987) The case research strategy in studies of information systems. MIS Quarterly 11(3), 369–386. BORJESSON G and MATHIASSEN L (2004) Improving software organizations: agility challenges and implications. Information Technology and People 18(4), 359–382. BOURDIEU P and WACQUANT LJD (1992) An Invitation to Reflexive Sociology, University of Chicago Press, Chicago, IL. BRASS DJ (1984) Being in the right place: a structural analysis of individual influence in an organization. Administrative Science Quarterly 29(4), 518–539. BURT R (1992) Structural Holes: The Social Structure of Competition, Harvard University Press, Cambridge, MA. BURT R (1997) The contingent value of social capital. Administrative Science Quarterly 42, 339–365. CAMPBELL DT (1975) Degrees of freedom and the case study. Comparative Political Studies 8(1), 178–191.

CHELL E (1998) Critical incident technique. In Qualitative Methods and Analysis in Organizational Research (SYMON G and CASSELL C, Eds), Sage, Thousand Oaks, CA. COHEN AR and BRADFORD DL (2003) Influence without authority: the use of alliances, reciprocity, and exchange to accomplish work. In Organizational Influence Processes (PORTER LW, ANGLE HL and ALLEN RW, Eds), pp 384–394, M.E. Sharpe, Armonk, NY. COLEMAN J (1988) Social capital in the creation of human capital. American Journal of Sociology 94(Suppl), S95–S120. COLEMAN JS (1990) The Foundations of Social Theory, The Belknap Press of the University of Harvard, Cambridge, MA. COOK KS and EMERSON RM (1978) Power, equity and commitment in exchange networks. American Sociological Review 43(5), 721–739. CROSS R and CUMMINGS JN (2004) Tie and network correlates of individual performance in knowledge-intensive work. Academy of Management Journal 47(6), 928–937. CUMMINGS JN and CROSS R (2003) Structural properties of work groups and their consequences for performance. Social Networks 25(3), 197–210. DYBa˚ T (2003) Factors of software process improvement success in small and large organizations: an empirical study in a Scandinavian context. ACM SIGSOFT Software Engineering Notes 28(5), 148–157. EDVARDSSON B and ROOS I (2001) Critical incident techniques: towards a framework for analyzing the criticality of critical incidents. International Journal of Service Industry Management 12(3), 251–268. EISENHARDT K (1989) Building theories from case study research. Academy of Management Review 14(4), 532–550. FREEMAN LC (1977) A set of measures of centrality based on betweenness. Sociometry 40, 35–41. FRIEDKIN NE and JOHNSEN EC (1999) Social influence networks and opinion change. Advances in Group Process 16, 1–29. GRANOVETTER MS (1973) The strength of weak ties. American Journal of Sociology 78, 1360–1380.


316


HAASE V, MESSNARZ R, KOCH G, KUGLER HJ and DECRINIS P (1994) Bootstrap: fine-tuning process assessment. IEEE Software 11(4), 25–35. HANSEN B, ROSE J and TJORNEHOJ G (2004) Prescription, description, reflection: the shape of the software process improvement field. International Journal of Information Management 24(6), 457–472. HERBSLEB J, ZUBROW D, GOLDENSON D, HAYES W and PAULK MC (1997) Software quality and the capability maturity model. Communications of the ACM 40(6), 31–40. HUMPHREY WS (1990) Managing the Software Process, Addison-Wesley, Reading, MA. IVERSEN J, NIELSEN PA and NøRBJERG J (1999) Situated assessments of problems in software development. The Database for Advances in Information Systems 30(2), 66–81. IVERSEN JH, MATHIASSEN L and NIELSEN PA (2004) Managing risk in software process improvement: an action research approach. MIS Quarterly 28(3), 395–433. JARVENPAA SL and IVES B (1991) Executive involvement and participation in the management of information technology. MIS Quarterly 15(2), 205–227. KLEIN HK and MYERS MD (1999) A set of principles for conducting and evaluating interpretive field studies in information systems. MIS Quarterly 23(1), 67–93. KLEIN K, LIM B, SALTZ J and MAYER D (2004) How do they get there? An examination of the antecedents of centrality in team networks. Academy of Management Journal 47(6), 952–963. KRACKHARDT D and HANSON J (1993) Informal networks: the company behind the chart. Harvard Business Review 71(4), 104–111. KRISHNA A and UPHOFF N (1999) Mapping and measuring social capital: a conceptual and empirical study of collective action for conserving and developing watersheds in Rajasthan, India. Social Capital Initiative Working Paper #13. The World Bank, Washington, DC, 1–36. KOTTER J (1996) Leading Change, Harvard Business School Press, Boston. LEE AS (1989) A scientific methodology for MIS case studies. MIS Quarterly 13(1), 33–50. LEE AS and BASKERVILLE R (2003) Generalizing generalizability in information systems research. Information Systems Research 14(3), 221–243. LIN N (1999) Social networks and status attainment. Annual Review of Sociology 25, 467–487. LIN N (2001) Building a network theory of social capital. In Social Capital Theory and Research (LIN N, COOK K and BURT R, Eds), Aldine de Gruyter, New York. MARKUS ML (1981) Implementation politics: top management support and user involvement. Systems, Objectives, Solutions 1(4), 203–215. MARKUS ML (1983) Power, politics, and MIS implementation. Communications of the ACM 26(6), 430–444. MARKUS ML and BENJAMIN RI (1996) Change agentry – the next IS frontier. MIS Quarterly 20(4), 385–407. MATHIASSEN L (2002) Collaborative practice research. Information Technology and People 15(4), 321–345. MATHIASSEN L, PRIES-HEJE J and NGWENYAMA O (2002) Improving Software Organizations: From Principles to Practice, Addison-Wesley, Boston, MA. MCFEELEY R (1996) IDEAL: A User’s Guide for Software Process Improvement CMU/SEI-96-HB-001, Software Engineering Institute, Pittsburgh, PA. MONGE P (1990) Theoretical and analytical issues in studying organizational processes, Organization Science 1(4), 406–430. NGWENYAMA O and NIELSEN PA (2003) Competing values in software process improvement: an assumption analysis of CMM from an organizational culture perspective. IEEE Transactions on Engineering Management 50(1), 100–112. NIELSEN PA and NGWENYAMA O (2002) Organizational influence processes in software process improvement. In Proceedings of the Xth European Conference on Information Systems (ECIS 2002) (WRYCZA S, Ed.), University of Gdan´sk, Gdan´sk, Poland.



NIELSEN PA and NøRBJERG J (2001) Assessing software processes: low maturity or sensible practice. Scandinavian Journal of Information Systems 13(1–2), 23–36. NøRBJERG J and NGWENYAMA O (2005) Building and maintaining alliances in SPI: implications for organizing effective SPI. Proceedings of the 13th European Conference on Information Systems. University of Regensburg, Regensburg, Germany. OH H, CHUNG M and LABIANCA G (2004) Group social capital and group effectiveness: the role of informal socializing ties. Academy of Management Journal 47(6), 806–875. OH H, LABIANCA G and CHUNG M (2006) A multilevel model of group social capital. The Academy of Management Review 31(3), 569–582. PAULK MC, CURTIS B and CHRISSIS MB (1993) Capability Maturity Model for Software v. 1.1. Technical Report, CMU/SEI-93-TR-024. Software Engineering Institute, Pittsburgh, PA. PELLED LH, EISENHARDT K and XIN K (1999) Exploring the black box: an analysis of workgroup diversity, conflict and productivity. Administrative Science Quarterly 44, 1–28. PETTIGREW AM (1990) Longitudinal Field research on change: theory and Practice. Organization Science 1(3), 267–292. PODOLNY JM and BARON JN (1997) Resources and relationships: social networks and mobility in the workplace. American Sociological Review 62, 673–693. POPPER K (1959) The Logic of Scientific Discovery, Hutchinson and Co, London. PORTER LW, ANGLE HL and ALLEN RW (2003a) Influence, power, and politics in organizational settings. In Organizational Influence Processes (PORTER LW, ANGLE HL and ALLEN RW, Eds), pp 3–13, M.E. Sharpe, Armonk, New York. PORTER LW, ANGLE HL and ALLEN RW (2003b) Lateral influence. In Organizational Influence Processes (PORTER LW ANGLE HL and ALLEN RW, Eds), pp 275–281, M.E. Sharpe, Armonk, New York. PORTES A (1998) Social capital: its origins and applications in modern sociology. Annual Review of Sociology 24, 1–24. PUTNAM R (1993) The prosperous community: social capital and public life. The American Prospect 4(13), [WWW document] http:// www.prospect.org/cs/articles?article ¼ the_prosperous_community. PUTNAM R (2000) Bowling Alone, Simon and Schuster, New York, NY. REAGANS R and ZUCKERMAN E (2001) Networks, diversity and productivity: the social capital of corporate R&D teams. Organization Science 12(4), 502–517. SABHERWAL R, JEYARAJ A and CHOWA C (2006) Information system success: individual and organizational determinants. Management Science 52(12), 1849–1864. SPARROWE R, LIDEN R, WAYNE S and KRAIMER M (2001) Social networks and the performance of individuals and groups. The Academy of Management Journal 44(2), 316–325. THONG J, CHEE-SING JY and RAMAN K (1996) Top management support, external expertise and information systems implementation in small businesses. Information Systems Research 7(2), 248–267. TSAI W (2000) Social capital, strategic relatedness and the formation of intra-organizational linkages. Strategic Management Journal 21(9), 925–939. TSAI W and GHOSHAL S (1998) Social capital and value creation: the role of intra-firm networks. The Academy of Management Journal 41(4), 464–476. VAN MAANEN J (1988) Tales from the Field: On Writing Ethnography, University of Chicago Press, Chicago, IL. WALSHAM G (1995) Interpretive case studies in IS research: nature and method. European Journal of Information Systems 4(1), 74–81. ZAHEER A, MCEVILY B and PERRONE V (1998) Does trust matter? Exploring the Effects of Inter-organizational and interpersonal trust on performance. Organizational Science 9(2), 141–159.



317

Appendix A See Table A1. Table A1 Description of empirical materials Category

Sub-category

E-mails

Meeting minutes

Number

Notes

All stakeholders in the SPI project

305

Members of company SPI group Members of support team SPI researchers

31

Approved by whole group

12

Presented to the development group for approval

10

Approved by research group

Researcher (co-author of this paper)

15

Write-up of field notes and reflections on the project related to (1) meetings in SPI group and sub-groups; (2) participation in improvement activities; (3) meetings in the research group; (4) other (events related to Denmark Electronics)

With manager of development project

Researcher (co-author of this paper) and internal improvement agent)

1

Interview with a project manager about his assessment of the processes and techniques that were being tested in his development project. The interview was tape recorded and subsequently transcribed.

With project managers towards the end of the SPI project

Members of the SPI group (researchers, consultants and internal improvement agents)

4

The purpose of these interviews was to (1) assess the effect of the SPI project on development processes and practices; (2) identify strengths and weaknesses in the company’s software processes; and (3) evaluate the SPI project from the project managers’ point of view. The interview guide contained open-ended questions about processes, practices and critical events in the project manager’s current project; the project manager’s view on strengths and weaknesses in the company’s software processes; his assessment of the recommendations of the latest (bootstrap) maturity assessment; the project manager’s assessment of the improvement project and its effect on the company’s software development processes. The interviews were tape recorded and subsequently transcribed.

With topmanagement towards the end of the SPI project

Members of the SPI group (researchers, consultants, and internal improvement agents)

2

Interviews with the two managers who had held the position as technical director during the course of the development project. The interview guide contained open-ended questions about the technical director’s assessment of the recommendations of the latest (bootstrap) maturity assessment; his assessment of the improvement project and its effect on the company’s software development processes; his opinions and plans regarding future software improvement in Denmark Electronics. The interviews were tape recorded and subsequently transcribed.

SPI-group meetings Development project Research group

Diaries

Interviews

Produced by


318



Appendix B See Table B1. Table B1

Example of coded empirical observations of the project managers’ social network ((1) First phase of the SPI project; (2) Last phase of the SPI project)

Category

Doc ID

Empirical observations

Identify partners (1)

DI_970514

Project managers are evaluated on their ability to deliver on time, but they have considerable freedom to decide how to manage their projects. Thus, it is crucial [for the SPI project] to gain the project managers’ support.


DI_970514

We need to sell the SPI project to three groups: top management, project managers and the project team. Top management [support] provides us with resources and visibility, but the project managers are key to success because of their power.


MM1_Gen970806

The only dark cloud is the power the project managers hold in the organization. There will be problems if they don’t buy-in to the improvement activities.


IN2_PM

Perhaps someone ought to force us to adopt some of these processes. Common processes result in common descriptions [and] you don’t have to start all over in a new project. With all these advantages, why don’t we do it? One would have to give up one’s own authority over the project.


IN2_PM

A standardized [project] model does not have a great effect. What’s more important is that the project managers interact. A common [project] model must work at the product level: Coordinated releases of products. y Today we want to have all features in a release because there is no plan for the next release.


IN2_PM

Cross-project collaboration has improved over the past year. Demarcations are broken down. The projects have not been able to survive without each other. Team dissolving and reforming has had an impact. Standardized tools and methods; everybody now runs [Windows] NT, Visual studio, etc.

Commitment(1)

DI_970804(pm)

The project managers act politically. They apply a variety of tactics in order to complete, what in their view, constitutes a ‘good project’ (and probably support their own career).The procedures and controls of level 2–3 may inhibit this type of behaviour. Will the project managers (if they realize it) therefore resist process maturity improvements?

Commitment(1)

EM_140198 EM_160298

Cancellations of SPI meetings due to unfinished negotiations about the year’s project portfolio.

Commitment(1)

MM1_970320

SPI motivation was high following the bootstrap assessment [fall 1996]. It is low now. Some project managers have expressed non-binding interest in participating. Denmark Electronics promises to confirm SPI resources and organization at next SPI meeting.

Commitment(1)

MM1_971021

Project manager 1: Not ready to commit on the presented basis. Project manager 2: About to start major projects. Interested in several initiatives. The SPI group agrees that the purpose (of the problem diagnosis) has been fulfilled.

Commitment(2)

MM1_990507_2

Concern after bootstrap feedback meeting: Several project managers did not participate (or left early). [The new technical director] left early too.

Trust(1)

DI970514

Lack of action following previous assessments has made project managers wary of initiatives. Introduce the SPI project carefully. Let project managers formulate their views on improvements.

Trust(1)

IN2_ Tech-dir

The project managers were not interested in SPI. They were sceptical towards the practical value of the results of [name of internal SPI champion’s] studies.

Trust(1)

IN_PM

You presented a new [development model] that appeared to meet our needs. Contrary to our usual [waterfall] approach, it was worth trying.

Trust(1)

MM3_Gen980924

Creating an interest in improvements and working directly with the projects seem to work fine. Projects are soliciting experiences across improvement initiatives, and the researchers have the resources and knowledge required to help where needed.




319

Table B1 Continued Category

Doc ID

Empirical observations

Trust(2)

IN2_PM

Trust(2)

IN2_PM

Currency of Exchange (1)

MM1_971021

Currency of exchange (1)

MM_971119

Too many improvement initiatives in too little time with too little visibility. Perhaps ‘dictates’ would provide better results? A project manager characterizes the project manager involvement strategy as a strength and a weakness because of the lack of (top) management involvement. Project managers are willing to participate in improvement initiatives provided they get sufficient resources or project plans are renegotiated (to make room for the extra improvement work. Discussions about the content of an ‘SPI contract’ with project groups.

Mutual aims and performance outcomes (1)

DI_970514

Improvements are introduced in individual projects and disseminated to the rest of the organization from there.

Mutual aims and performance outcomes (1)

DI_970514

We must, therefore, convince the project managers that [software process] improvements will solve their problems.


Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.