Introduction

Research on innovation adoption and diffusion has long converged on a core set of theoretical frameworks that seek to explain target adopter attitudes and their innovation-related behavior. These core frameworks - Diffusion of Innovations (Rogers 1983), the Theory of Reasoned Action (Ajzen & Fishbein, 1975), the Technology Accept-ance Model (Davis, Bagozzi & Warshaw, 1989), the Theory of Planned Behavior (Ajzen, 1985; Taylor & Todd, 1995), and SocialCognitive Theory (Compeau & Higgins, 1995) -- have received widespread validation for many technological innovations where individual autonomy is permitted to adopt or reject an innovation. Increasing evidence suggests that these traditional frameworks neglect the realities of implementing technology innovations within organizations, especially when adoption decisions are made at the organizational, division, or workgroup levels, rather than at the individual level (Fichman & Kemerer, 1997; Orlikowski, 1993; Wynekoop, 1992). Under these conditions, which correspond to "contingent authority innovation decisions" (Zaltman, Duncan & Holbeck, 1973), authorities make the initial decision to adopt and targeted users have few alternatives but to adopt the innovation and make the necessary adjustments for using it to perform their jobs. Thus rather than fitting the conditions under which traditional models of innovation adoption and diffusion (Rogers, 1983) or technology acceptance (Davis, 1989; Ajzen & Fishbein, 1975) were created, the reality of innovation adoption and implementation within organizational settings may require modifications to these frameworks - or entirely new ones - to explain implementation of contingent authority innovation decisions, that is non-voluntary adoption processes.

This paper explores the relevance of traditional innovation adoption frameworks when applied to organizational adoption and implementation of technology innovations, in particular when there is an organizational mandate to adopt the innovation. This study reviews efforts that have been made to modify these traditional frameworks, which focus on the individual user as the level of analysis, or to substitute entirely new frameworks to better account for the forces shaping implementation in organizations. While some of these modifications have been valuable in helping to explain factors such as social influences within a firm, or employees' perceived control over their adoption behavior (Ajzen, 1985; Taylor & Todd, 1995), the choice of innovation usage or individual adoption as the dependent variable in most studies would appear moot under the circumstances that adoption and use are mandated. Along these lines, one researcher who investigated CASE tool adoption at both the individual and the company levels of analysis noted that:

Since innovation diffusion theory is based on voluntary adoption decisions, one of its primary limitations is its incompleteness in the area of organizational implementation of innovations after authoritarian or contingent adoption decisions. Innovation researchers have neglected this area, leaving the definition of independent and outcome variables very exploratory.... Organizational and individual implementation outcomes may not be the same - that is, one may be successful, and the other unsuccessful.

-Wynekoop 1991: 120, 122

While the researcher recognizes the value of some recent models proposing more complex influences on individual adoption - including Ajzen's (1985) Theory of Planned Behavior -- gaps still exist between the assumption of individual autonomy in these models versus the reality of organizational implementation processes. Additional literature streams of organizational process research and stage research (Prescott & Conger, 1995) must be considered to develop suitable frameworks for understanding the processes and outcomes relevant to individual, workgroup, and company-wide innovation adoption and implementation.

To reconcile these gaps, a hybrid framework is proposed that combines key elements from existing individual- and organizational-level models, and is used to illustrate events at one firm that adopted a technology innovation to replace its mainframe-based software development processes with client/server development, and sought to implement other changes in the work processes and culture of its IS department. The value of this hybrid framework is demonstrated by using analytical induction techniques (Miles & Huberman, 1994) to analyze key factors and events that influenced implementation outcomes.

The importance of key managerial interventions (Agarwal, 2000) in this firm is demonstrated, as is the inconsistent influence of the firm's bureaucratic culture in facilitating initial innovation adoption, while constraining many of the organizational changes in work process and culture required to institutionalize and fully exploit the technology's potential benefits. The next section provides a literature review of both the individual and organizational-level frameworks that have been used to explain innovation adoption and implementation behavior.

Literature Review

This literature review is organized into three sections. The first section introduces the concepts and terminology related to contingent authority innovation adoption decisions. The second section reviews frameworks that have been used to explain individual technology adoption and usage, and examines their limitations when applying them to authority innovation adoption scenarios in organizations. The third section reviews organizational-level process research and stage research models for studying implementation, and underscores their value in reconciling the aforementioned gaps in using individual-level frameworks to explain these contingent adoption processes in organizations.

Contingent and Authority Innovation Adoption

Zaltman, Duncan & Holbeck (1973) examined innovation adoption within organizations and found that the adoption process often occurs in two stages - a firm-level decision to adopt the innovation (primary adoption), followed by actual implementation, which includes individual adoption by users (secondary adoption). This process has been labeled as two-step adoption (Leonard Barton & Deschamps, 1988) or two-stage implementation (Lucas, Ginzberg & Schultz, 1990). Figure 1 illustrates the key processes at a high level of analysis: managers identify objectives to change some aspect of their business, seek available innovations which may fit their objectives, and then make the primary adoption decision -- essentially providing the "go ahead" for other members of the firm to purchase and implement the innovation. Figure 1 is consistent with Rogers' (1983) description of the initiation stages of the innovation process in organizations, where he specifies the activities of agenda-setting, then matching an innovation to a pre-defined problem, which precede the firm's adoption decision.

Once the primary adoption decision has occurred, management may proceed by three fundamentally different paths to ensure secondary adoption: (1) they can mandate that the innovation be adopted throughout the organization at once; (2) they can provide the necessary infrastructure and support for users to adopt the innovation, while allowing it to diffuse voluntarily; or (3) they may target specific pilot projects within the firm, observe the processes and outcomes that unfold, and decide whether to implement the innovation more broadly later on. These options are consistent with recent work that identified three implementation strategies and conditions that favor each of them: a total commitment implementation strategy, support strategy, and advocacy strategy, respectively (Agarwal, Tanniru & Wilemon, 1997; Gallivan, 1996).

Zaltman et al., (1973) label this two-stage implementation scenario a contingent adoption decision, because employees cannot adopt the innovation until primary adoption has occurred at a higher level of authority; actual user adoption is thus contingent on a prior event. This two-stage process may even be broadened to a multi-stage framework if additional, intermediate levels of adoption approval are required - for example, if after senior management adopts the innovation, it must then be approved at the division or workgroup level, before end users have the opportunity to adopt it. Furthermore, while Zaltman et al., describe that, for each stage in contingent adoption, the decision to adopt may be optional, consensus-based, or authority-based, researchers have shown that the most common pattern within organizations is a consensus-based primary adoption decision (at the management level), followed by authority-based secondary adoption that is, mandated adoption at the user level (Rogers, 1983; Cooper & Zmud, 1990; Lucas et al., 1990).

Where Figure 1 falls short in describing this two-- stage process is its neglect of details contained in the construct "other influences on innovation adoption." The goal of this paper is to open this black box, in order to understand more clearly the processes, influences upon, and outcomes of secondary adoption in organizations. With Figure 1 firmly in mind as a high-level framework for representing contingent innovation adoption, Figure 2 is used as a classification scheme for different organizational adoption categories to show that the focus of this paper is on contingent, authority-- based innovation adoption (top-left cell) - that is, where both primary and secondary adoption do occur.

This paper does not consider the other possible permutations of contingent adoption decisions (e.g., where primary and secondary adoption are both voluntary or consensus-based), since these scenarios have been addressed elsewhere (Markus, 1981, 1983; Orlikowski, 1992). Clearly, innovation in organizations does not always occur top-down, but may instead emerge as a grass roots or bottom-up initiative (bottom-right cell). Further, although two-stage adoption may be the objective, the primary adoption decision does not guarantee that the innovation will actually be implemented or used by the targeted users (bottom-left cell), as illustrated by the notion of an assimilation gap (Fichman & Kemerer, 1999). Given this paper's focus on contingent, authority-- based adoption within organizations (i.e., mandated use), the next two sections review the separate literature streams on individual and organizational adoption, respectively.

Review of Individual-level Innovation Adoption Frameworks

This section reviews relevant research on technology adoption and acceptance conducted by IS researchers and identifies some conceptual and methodological limitations. Several theories have been developed to explain individual adoption and acceptance of IT. Among these are Diffusion of Innovation theory (Rogers, 1983; 1996), the Theory of Reasoned Action (Ajzen & Fishbein, 1975), the Technology Acceptance Model (Davis, 1989; Davis, Bagozzi & Warshaw, 1989; Szajna, 1996), the Theory of Planned Behavior (Ajzen, 1985), and Social Cognitive Theory (Compeau & Higgins, 1995). Although it is beyond the scope of this paper to describe all of these models, two that have received the most attention in the IS literature are reviewed briefly: Rogers' (1983) diffusion of innovation (DOI) theory and Davis' (1989) Technology Acceptance Model (TAM). (Interested readers are referred to recent summaries by Fichman (2000) and Agarwal (2000) for their comprehensive reviews of prior research on innovation diffusion and technology acceptance, respectively.)

Comparison of 'TWo Individual-level Adoption Models: Diffusion of Innovations and TAM. There are many similarities between the TAM and DOI frameworks, beyond the high level of interest they have drawn from IS researchers studying technology adoption. First, both models identify the perceived attributes of an innovation as key predictors explaining adoption. Second, both models feature users' intentions to adopt a technology (or their actual adoption/use) as their dependent variable. Third, both models apply most readily to situations where the individual user can voluntarily choose whether to adopt the innovation or not. There are important differences, however, in the origins and the scope of these models. One key difference is that DOI, which was synthesized from hundreds of prior studies on a range of innovations beginning with agricultural innovations (Rogers, 1962), identifies five perceived attributes of an innovation as influencing adoption behavior (relative advantage, complexity, compatibility, trialability, and observability). In contrast, TAM was created specifically to explain IT adoption and it posits just two perceived attributes that influence adoption (usefulness and ease-of-use). A second difference is that, while DOI theory has a broader focus in seeking to explain how communication channels and opinion leaders shape adoption, TAM is much narrower in its objective to predict technology acceptance and usage by potential adopters. Due to many similarities between these models, and also owing to the fact that many IS researchers have combined elements of both models (Agarwal & Prasad, 1997; Thompson, Higgins & Howell, 1991; Moore & Benbasat, 1991; Karahanna, Straub & Chervany, 1999), 1 will jointly refer to these models by the label "traditional innovation adoption frameworks."

The traditional innovation adoption models have received considerable attention in the IS literature and, while the following review identifies some limitations, this should not be construed as a general criticism or rejection of them. These frameworks are well-grounded in theory and have proven their value, for example in explaining individuals' behavioral intentions to adopt a technology, or in providing managers with guidelines for designing intervention strategies to encourage IT adoption (Davis, Bagozzi & Warshaw, 1989). The summary below argues that these traditional innovation adoption models are well-suited to a particular range of adoption scenarios and technology types, however, when they are misapplied in situations where their underlying assumptions are not met, they are likely to produce findings that are weak, unstable, or open to question. In particular, these traditional innovation adoption frameworks may yield inconsistent results when:

* Adoption occurs within an organizational setting where users are mandated to use the innovation.

* Adoption is subject to heavy coordination requirements or strong interdependencies across multiple adopters.

* Adoption requires extensive, specialized training to learn the principles underlying the innovation, in order to overcome knowledge barriers to use.

* Adoption and use occur within an organizational setting, but only a single respondent is available to vouch for the innovation use of many other employees in the organization.

Traditional innovation adoption frameworks have repeatedly shown strong explanatory power in studies that examined certain classes of innovation adoption. The adoption scenarios for which these frameworks are well suited are those where individuals voluntarily decide whether to use a "personal use" technology, such as PCs, word processing software, or spreadsheets (Brancheau & Wetherbe, 1990; Davis, 1989; Adams, Nelson & Todd, 1992; Szajna, 1996). This type of scenario is where TAM and DOI have demonstrated their value in explaining individual acceptance of technology. These traditional frameworks have limitations, however, as argued by Fichman (1992), who reviewed 18 technology adoption studies and argued that the outcomes of applying traditional innovation models to IT adoption were sensitive to the fit between the assumptions underlying these models and the specific features of the adoption context and the technology in question. Fichman noted that these frameworks were most often employed and demonstrated the most success (i.e., positive findings) when applied to a narrow range of adoption scenarios and technologies, which he characterized as: "the adoption of innovations by individuals making autonomous choices about whether to adopt personal use innovations that do not require extensive specialized knowledge prior to adoption" (Fichman, 1992, p. 196). These conditions correspond to Figure 3, cell 1, where the cited studies strongly validated the traditional innovation adoption models.

Complex Adoption Scenarios where Traditional Models Are Not Supported. Where traditional adoption models have not been applied either as frequently or as successfully are where the adoption decision is made at the organizational level and employees are mandated to use the technology (Figure 3, cell 2), for more complex technologies and adoption scenarios which require high levels of coordination across multiple adopters, or where the technology has a high "knowledge burden, (cell 3). One other scenario (cell 4) where traditional models appear to fit least well is one that combines both organizational mandates to use an innovation (as in cell 2) and complex technologies requiring coordination across multiple users (as in cell 3). Application of traditional models to this most complex scenario has produced mixed findings that show the greatest deviation from the expected results, generating "only weak or inconclusive support" (Fichman, 1992). Examples of the latter scenario (cell 4) including MRP systems (Cooper & Zmud, 1990), database design tools (Nilakanta & Scamell, 1990), and "modern software practices" (Zmud, 1982, 1984).

The Influence of "Implementation Complexity" on Adoption Outcomes. The predictions of traditional adoption frameworks have not been wellsupported for scenarios corresponding to cells 2 and 3, most likely due to their high levels of implementation complexity (Leonard Barton, 1998a), where successful outcomes cannot be achieved by a few users independently adopting the innovation. Instead, technology use and other outcomes depend on implementation activities that must be coordinated and synchronized across many adopters who may be distributed across multiple departments or geographic locations. The scenario represented by cell 4 signifies a very high level of complexity, both in terms of the technology itself - due to high knowledge barriers to use (Attewell, 1992), and due to high implementation complexity. Rather than using traditional models to explain adoption behavior in these scenarios, Fichman (1992) argues that researchers should consider abandoning such models or integrating them with new metaphors and theories such as critical mass (Markus, 1987), absorptive capacity (Cohen & Levinthal, 1990), or organizational learning (Attewell, 1992), in order to build theoretical frameworks that fit these complex scenarios.

While this review of the IT adoption literature has focused on the nature of the models themselves rather than on the research methods used to study adoption, issues of theory and method are often intertwined, since particular models of human behavior favor certain research methods to investigate them (Markus & Robey, 1988). For example, a research model which assumes that people's innovative behavior changes over time depending on interactions among the person, the technology, and the organization (Leonard Barton, 1988b; Orlikowski & Robey, 1991), should capture longitudinal data on all three dimensions. Given such a theoretical model, researchers would not choose a methodology which ignores temporal aspects of implementation, or which neglects one of the three dimensions (e.g., changes in the technology). Where the assumptions underlying a theoretical model are not consistent with the research methods, problems of misspecification can occur.

The "Key Informant Research Tradition. One set of studies where traditional adoption models have been applied are key informant studies conducted within organizations. In such key informant studies, researchers ask a single respondent to complete a survey indicating whether her organization has adopted one or more innovations. Such data is usually gathered from a senior manager, such as the President, CEO, or - for IT innovations - from the CIO or other senior IT executive. Adoption of one or more innovations is examined as the dependent variable and, through regression techniques (most typically), adoption is linked to attributes of the organization (e.g., centralization), the individual respondent (e.g., educational level), and the innovation itself, as perceived by the key informant (e.g., relative advantage). Although Fichman identified only a few such key informant studies in the IS literature published during the 1980s (Figure 3, cell 2), many innovation studies have been conducted along these lines to explain organizational innovativeness and adoption behavior (Rogers, 1983). Researchers employing such methods have identified attributes of "innovative" organizations and have constructed theories to explain why some organizations are more innovative, in general, or more innovative in adopting certain types of innovations (Downs & Mohr 1976; Pierce & Delbeq 1977).

The Need for Multiple Perspectives of Organizational Adoption. Despite the popularity of the key informant methodology, however, leading researchers have challenged the validity of this approach for understanding innovative behavior in organizations, because such studies draw conclusions about processes and events that may involve many people in the firm, but where the data are based on input from a single respondent. For example, a key informant study may ask the CIO whether her firm has adopted Windows NT/2000 as its standard operating system, and then correlate this adoption outcome with the CIO's rating of several company attributes, as the independent variables (e.g., company size, centralization, total IT budget, etc.). The problem is that there is little opportunity to validate the data with information from other members of the firm - notably the users who are alleged to have adopted the Windows NT/2000 operating system. Given the validity and reliability issues raised in such key informant research, the founder of diffusion of innovation theory, Everett Rogers, decried the use of this method to understand organizational innovativeness. Rogers even explained his actions to "lead an intellectual revolt against them":

The question troubling any diffusion scholar who depends solely on data from the top leader in an organization is how fully such information can describe the organization's innovation behavior. Not very fully, the available evidence suggests.... In essence [data from] each organization in these diffusion studies was reduced to the equivalent of an individual... (T)here was no way to determine how adequately these data truly represented the entire organization's behavior with regard to a technological innovation.

- Rogers 1983: 355, 357-358

The key informant method may not be a reliable source of data regarding adoption behavior, especially where no triangulation is possible.1 Despite Rogers' criticism of combining DOI theory and the key informant method to examine organizational adoption and use of innovations, this approach has been frequently used to investigate adoption of various technologies, and to identify the factors that influence such innovative behavior. Technologies investigated in this manner include laptop computers, (Robertson & Gatignon, 1989), EDI (Premkumar & Nilakanta, 1994), digital imaging (Liberatore & Breem, 1997), and telecommunications technologies (Grover & Goslar, 1993).

Rogers (1983) reserves his strongest criticism of such applications of DOI theory for those studies that claim to investigate the determinants of innovation, yet which inquire about the adoption decision only (i.e., primary adoption), rather than implementation (i.e., secondary adoption). For technology innovations, adoption is often operationalized as management authorizing purchase of the technology, rather than capturing whether the firm has actually deployed the technology or whether it moves beyond a trial stage toward routinizing the technology for everyday use (Rogers, 1983). As any IS manager knows, there are many technologies adopted by companies (i.e., approved and purchased), but where little or no actual implementation occurs, even years later. Such an assimilation gap (Fichman & Kemerer, 1999) between adoption and implementation is especially common for technologies with high implementation complexity (Leonard Barton, 1988a; Agarwal, Tanniru & Wilemon, 1977), such as those depicted in Figure 3, cell 4. Implementation may occur many years after initial purchase - or may never occur - for complex technologies, such as CASE tools, ERP systems, or object-oriented development.

To create realistic models of actual innovation behavior in organizations, we must take into account the implementation processes that follow adoption while capturing data from multiple perspectives - including the innovation's actual or intended users (secondary adopters), as well as its primary adopters. The next section explores issues of implementation process, and identifies the value of process and stage research models for understanding implementation dynamics.

Organizational Level Process Models of Implementation

There is a growing literature stream focusing on process models and stage research models for understanding organizational implementation of innovations. Such stage research models (Prescott & Conger, 1995) identify the sequences of events that occur during implementation - with most stages focused on events following the adoption decision. Stage models are a sub-type of process research models (Markus & Robey, 1988; Mohr, 1982) and, like other process models, are valuable in describing how implementation processes unfold, with a focus on the time-ordering of events, and identifying the events and conditions necessary for certain outcomes to occur (Soh & Markus, 1995; Shaw & Jarvenpaa, 1997). Process and stage research models are also valuable in identifying the context in which events occur and show the causal linkages and temporal relationships among context, behavioral processes, and outcomes. Rogers (1983) advocates developing such dynamic models to "capture the complex, over-time nature of the innovation process in organizations.... [which] permits greater insight in tracing the nature of the innovation process" (Rogers 1983: p. 361, p. 358).

Rogers proposed a five-stage model of innovation adoption and implementation in organizations,2 roughly corresponding to initiation (stages 1-2) and implementation (stages 3-5). Initiation includes agenda-setting (problem identification) and matching (fitting an innovation to a predefined problem), while implementation includes making changes to both the organization and the innovation to exploit the innovation: redefining/restructuring, clarifying, and routinizing. Through this sequence of stages the firm redefines/restructures both the technology and organizational processes - akin to mutual adaptation (Leonard Barton, 1988b), clarifies its members' understanding of the innovation and the firm's goals for adopting it, and routinizes the innovation by making it part of everyday practice. While Rogers' model was the first process model of organizational adoption and implementation, there have been many other stage models proposed over the years. Considerable work in this area has been undertaken by management scholars (Meyer & Goes, 1988) as well as IT researchers - notably by Zmud and colleagues (Kwon & Zmud, 1987; Cooper & Zmud, 1990; Saga & Zmud, 1994).

A thorough review of this literature is beyond the scope of this paper, however, the fundamental concepts and terminology of such models are summarized. In organizational-level process and stage research models, it is not technology use or user adoption per se that matters as the outcome of interest, but rather how extensively the innovation is used and how deeply the firm's use of the technology alters processes, structures, and organizational culture. Research-ers have generally referred to this notion as the innovation's degree of assimilation into the organization, or assimilation stage (Meyer & Goes, 1988; Fichman & Kemerer, 1997). Assimilation may be divided into two sub-constructs: breadth and depth of technology use. Breadth of use refers to the number of adopters within a firm (also labeled internal diffusion), while depth of use is a less tangible construct describing how extensively the innovation is used and its level of impact within the firm.

Following the early research by Zmud and colleagues (Kwon & Zmud, 1987; Cooper & Zmud, 1990) in this area, this notion of depth of usage and level of impact is labeled technology infusion, where the infusion metaphor refers to the innovation penetrating down into the organization. Common definitions of infusion include "embedding an IT application deeply and comprehensively within an individual's or organization's work systems" (Saga, 1994: 37), and "the extent to which an innovation is used completely and effectively and improves the organization's performance" (Wynekoop, 1991, p. 21). Re-searchers have used various synonyms to describe the infusion concept, including injection depth (Howard & Rai, 1993), routinization (Rogers 1983), institutionalization (Meyer & Goes, 1988), and widespread deployment (Fichman & Kemerer, 1997).

In the IS literature, the best-known model describing technology implementation in organizations is the six-stage model proposed by Zmud and colleagues (Kwon & Zmud, 1987; Cooper & Zmud, 1990), which has been praised as "an example of good definitions which serve as a model for adequate construct definition" (Prescott & Conger, 1995, p. 34). The stages in this model of organizational adoption and implementation are defined as follows (Cooper & Zmud, 1990, p. 124):

* initiation - a match is found between an innovation and its application in the organization

* adoption - a decision is reached to invest resources to accommodate the implementation effort

* adaptation - the innovation is developed, installed and maintained. Procedures are developed and revised. Members are trained both in the new procedures and in the innovation

* acceptance - organizational members are induced to commit to the innovation's usage

* routinization - usage of the technology application is encouraged as a normal activity

* infusion - increased organizational effectiveness is obtained by using the IT application in a more comprehensive and integrated manner to support higher level aspects of work.

Given the strengths of such process and stage research models for describing change processes, they are useful for understanding the various stages of technology assimilation, including the factors and events that influence them. Although there continues to be far more research on the factors influencing technology adoption (i.e., primary adoption) than on assimilation, there is growing interest in using process and stage models to understand assimilation processes and outcomes (Prescott & Conger 1995; Saga & Zmud 1994; Orlikowski 1993; Fichman & Kemerer 1997). Given the strength of such models in explaining implementation process, I integrate the six-stage assimilation process model along with some constructs from traditional individual adoption frameworks to forge a new framework to understand authority-based contingent adoption of innovations.

A New Framework for Innovation Adoption and Implementation

Figure 4 presents the framework, which will be the focus of the remainder of the paper. The figure traces a two-stage (or multi-stage) adoption process from the primary adoption decision, which may occur at the corporate-, division-, or department-level in an organization. The vertical dotted lines separating the figure into three sections (primary adoption, secondary adoption/ assimilation, and outcomes) are used to indicate that our focus is on the center part of Figure 4. Although primary adoption must occur to trigger secondary adoption (for contingent, authority innovation adoption), the factors that trigger primary adoption are not the focus of the framework and are largely disregarded in this paper. The antecedents of primary adoption have previously been identified for many technologies, including client/server development (Chengalur-Smith & Duchess!, 1998; 1999). Similarly, the consequences of various technologies have been investigated. It is the center of Figure 4 that has received insufficient attention and, thus, is the focus here.

The center of Figure 4 explicates the set of influences and processes leading to secondary adoption and organizational assimilation. This part of the framework is the most complex and has been neglected by researchers who have studied primary adoption of technologies while neglecting issues of secondary adoption and assimilation. The center of Figure 4 incorporates and adapts some constructs from the Theory of Planned Behavior (Ajzen, 1985; Taylor & Todd, 1995), specifically the factors that mediate between primary and secondary adoption: managerial interventions, subjective norms, and facilitating conditions.

Managerial interventions describe the actions taken and resources made available by managers to expedite secondary adoption, including mandating usage (Leonard-Barton & Deschamps, 1988; Agarwal, 2000). Subjective norms describe individuals' beliefs about the expectations of relevant others regarding their own secondary adoption behavior. The particular norms may vary for a given innovation and adoption context (Ajzen & Fishbein, 1975; Davis, Bagozzi & Warshaw, 1989), however, subjective norms shape potential adopters' beliefs about when and why to adopt an innovation, how much effort to undertake on their own to learn it, or when to abandon the technology for an even-newer innovation. Managerial interventions and subjective norms are specific constructs related to managers' actions and employees' beliefs about others' expectations, respectively.

The third construct, facilitating conditions is a broad category that captures other factors that can make implementation more- or less-likely to occur (Orlikowski, 1993). These include specific attributes of the innovation, the organizational context and culture, and the work task itself. Facilitating conditions have historically been defined as "objective factors 'out there in the environment' that several judges or observers can agree make an act easy to do" (Triandis, 1980, p. 205). Despite the construct's focus on agreement among multiple observers, operationalizing this construct has itself been plagued by a lack of agreement among researchers. For example, Orlikowski operationalized facilitating conditions as a broad construct that aggregates many forces either favoring or impeding assimilation. In her study of CASE tool implementation in two organizations, she concluded that various attributes related to the technology, the organizational context, and individual adopters served as facilitating conditions. Other researchers have operational!zed the facilitating conditions construct more narrowly in survey research on individual technology adoption, with inconsistent results (Taylor & Todd, 1995; Thompson, Higgins & Howell, 1991).

These mixed results were likely due to using narrow, technically-focused measures to operationalize facilitating conditions, while neglecting other potential facilitators related to the organizational context or the individual. Given these prior mixed results, it is unlikely that the measures they employed represent generalizable facilitating conditions. Nevertheless, the researcher believes that there are facilitating conditions that are generic, and others that are specific to a particular innovation or context, or specific to the interaction between a particular innovation and context (Meyer & Goes, 1988). One objective for developing this framework and applying it empirically is to identify facilitating conditions, and consider whether they may be generalizable to other settings.

Figure 4 distinguishes between managerial interventions and subjective norms as separate constructs. While this distinction is consistent with some prior IS research, other studies have conflated these constructs, depicting organizational mandates or actions to ensure innovation adoption as equivalent to subjective norms. Subjective norms do not so much relate to organizational mandates, as they do to an individual's perception of what they believe others think they should do (Agarwal, 2000; Saga, 1994).3 While there may indeed be a subjective element to how different members interpret such organizational mandates (Leonard Barton & Deschamps 1988), there is also an objective reality to such managerial interventions - namely, whether the technology is required for employees perform their jobs. Even in situations where managers do not explicitly dictate that employees use an innovation, if the traditional processes or resources for accomplishing required work tasks have been eliminated, there is captive use of technology (Adams, Nelson & Todd, 1992). Figure 4 thus conceptually distinguishes between managerial interventions as the objective reality (steps taken and resources made available by managers) and subjective norms. Managerial interventions may thus include activities such as mandating usage, as well as offering company-sponsored training, resource support, hiring new employees or hiring consultants experienced with the technology to serve as mentors. These activities have important implications for secondary adoption by individuals, the next construct in the model.

Secondary adoption refers to adoption at the individual level, but in this model, the issue in question is not whether employees adopt the innovation (since this is assumed), but rather when and how they adopt it - through what experiences, with what obstacles encountered, and how these events influence organizational assimilation and outcomes. The set of processes that constitute organizational implementation of an innovation are very different from their individual adoption counterparts (Rogers, 1983), and outcome measures applicable to organizational assimilation may differ dramatically from individual outcomes (Wynekoop, 1991; DeLone & McLean, 1992). Once secondary use occurs, it is meaningful to consider the organization's assimilation stage. Assimilation stage describes how deeply the innovation penetrates the adopting unit (e.g., the company, division, or workgroup). Figure 4 shows that there are four assimilation stages that follow adoption - adaptation, acceptance, routinization, and infusion (Cooper & Zmud, 1990). Thus, the center of Figure 4 is a multi-level representation of the factors and events that intervene between the primary adoption decision (at a higher authority level) and the overall assimilation processes and outcomes of the adopting unit. While secondary adoption refers to events at the individual level, assimilation stage, describes the degree of implementation within the adopting unit as a whole. The overall framework is thus a hybrid model that combines processes and factors at both the individual and firm levels of analysis. While traditional epistemologies have cautioned against combining processes and factors into the same research model (Mohr, 1982; Markus & Robey, 1988), a review and recasting of IT research objectives by Shaw and Jarvenpaa (1997), actually advocates such hybrid models for studying implementation processes, particularly for understanding the implementation events that occur and the factors that promote or constrain implementation outcomes. Shaw and Jarvenpaa (1997) identify several exemplars of such hybrid process/factor models of technology implementation (Newman & Robey, 1992; Poole & DeSanctis, 1992; Sambamurthy & Poole, 1992; Orlikowski & Yates, 1994). They argue that both processes and factors are necessary to explain change events that occur over time, and the factors that influence them.

The following example illustrates how to apply the framework (see Figure 4). Consider an company that decides to have all employees use personal digital assistants (PDAs) (e.g., a Palm Pilot or Apple Newton) for communicating work-related messages to each other, even for team members who work in the same office. Following the primary adoption decision by the firm's senior managers, secondary adoption refers to the set of processes describing when and how employees actually begin using their PDAs for communication, including their learning activities and any problems encountered. Employees' secondary adoption behavior is influenced by managerial interventions such as training sessions and "help desk" support, as well as by the subjective norms that evolve within each workgroup regarding which PDA features to use and other aspects of usage (e.g., norms regarding whether certain messages are considered "work-related," appropriate message length, degree of formality for the messages, etc.). Finally, other factors (facilitating conditions) may also influence how quickly and easily employees adopt PDAs for work communication, what obstacles they encounter, and the degree of change in the work environment. The adopting unit reaches a higher level of assimilation stage, depending on how deeply the new communication behaviors become embedded or infused (Saga & Zmud, 1994) into workplace routines, and the extent to which accompanying changes occur with regard to the organizational culture, rewards and incentives, job definitions, and management processes and structures. Figure 4 describes six assimilation stages using Cooper and Zmud's (1990) stage model.4 This model features one pre-adoption stage (initiation), then adoption, followed by four post-adoption stages (adaptation, acceptance, routinization, and infusion). In more recent work, Saga and Zmud (1994) suggest three different facets of technology infusion. Technology infusion may be characterized by more extensive use of the innovation (e.g., using more technology features), more integrative use (using technology to create new workflow linkages among tasks), or emergent use (using technology to perform tasks not previously considered possible).

Finally, the arrow leading from assimilation stage to the right-hand side of Figure 4 links the organization's assimilation stage to a set of possible outcomes. Since these outcomes may vary depending on the specific innovation - as well as based on a host of factors such as management's intentions for the technology, the implementation strategy, the actions of key actors during implementation, and even chance events (Orlikowski, 1993; Markus, 1993; Soh & Markus, 1995), it is impossible to specify with certainty what these outcomes will be or whether they will be achieved. This lack of determinism is characteristic of process models (Soh & Markus, 1995; Shaw & Jarvenpaa, 1997). The arrow between assimilation stage and consequences suggests, however, that the more deeply the innovation becomes infused or assimilated into the organization, the greater the likelihood of observing some outcomes - whatever they may be. The right-hand side shows a sample of some possible outcomes that may be occur for the specific example of implementing client/server development as a replacement for mainframe-based software development. These outcomes are not guaranteed and any outcomes that do occur will likely be perceived differently by different stakeholders. For example, some benefits of client/server development that may be visible to the adopting IS employees may include faster development times, easier software maintenance, and better hardware scalability (Chengalur-Smith & Duchessi, 1998; 1999). In contrast, the benefits visible to the business divisions that commission and use client/server applications may include greater ease-of-use, faster system response time, and increased control over data.

Figure 4 thus presents a hybrid framework that spans multiple levels (individuals, workgroups, and the organization), as well as a combination of processes that occur over time and the factors that influence them. I reiterate that the center of Figure 4 will be the focus here, and not the determinants of primary adoption (left side of figure) or the specific outcomes achieved (right side of figure). The framework acknowledges the complexity of the assimilation process through feedback loops, notably the reverse arrows from "consequences" back to "assimilation stage" and to "secondary adoption processes." For example, a firm may decide to implement an innovation on a widespread basis, after observing the outcomes from a pilot project in a single department, or they may decide to cease using the innovation altogether, if outcomes from the pilot project are negative. The feedback loops from consequences back to assimilation stage and to secondary adoption are thus critical for signifying that implementation is a dynamic process; learning that occurs in one adopting unit can influence future adoption and assimilation behavior elsewhere in the organization (Agarwal, Tanniru & Wilemon, 1997; Orlikowski, 1993).

Despite the complexity of the framework, there are many details that still remain unspecified. For example, Figure 4 does not specify what managerial interventions matter when adopting technologies with high implementation complexity (Leonard Barton, 1988a), or what is the content of subjective norms that influence secondary adoption behavior. Moreover, there may be subjective norms or other facilitating conditions factors which promote early stages of assimilation but exert a different effect on later stages, such as routinization and infusion. This figure does not allow for the possibility of such stage-dependent factors, which may influence assimilation at certain stages but not at others, although this has been a matter of interest and debate in the innovation literature (Cooper & Zmud, 1990; Downs & Mohr, 1976; Fichman, 2000; Karahanna, Straub & Chervany, 1999). In summary, despite the apparent complexity of the theoretical framework, there are many unresolved issues about innovation adoption and assimilation. Fleshing out some of these issues is critical if this framework is to have future value for researchers and practitioners. The following sections describe a field study and then analyze it by using this framework. First, the research methods and case study results are presented, and then a set of themes that emerged from analysis of the data are identified. These themes provide additional details of the framework - identifying specific managerial interventions, subjective norms, and other facilitating conditions that influence the firm's innovation adoption and assimilation. Then the framework is used to analyze the implementation scenario and improve upon older innovation adoption frameworks.

Field Study of Insureco

This study collected data on the implementation of client/server development in four large firms. Client/server development represents a technological innovation that changes the skills and procedures necessary for creating application software. Client/server development is a type 1b innovation, according to Swanson's typology (Swanson, 1994), since it is a "technical innovation" within the IS department. Client/server development represents a new software development process - a "software process innovation" (Fichman & Kemerer, 1993) - that replaces mainframe computers with distributed, network-based systems as the platform for developing and running application systems. In addition, client/server development replaces the use of traditional, third generation programming languages (e.g., COBOL or PL/11), with application development toolsets (e.g., PowerBuilder) (Vaskevitch, 1993).

Research Methods

During the period from 1993-1994, initial access was secured to interview a variety of IS managers and employees in four firms that were in the process of implementing client/server development. Since this time period was still early in the evolution of client/server development, the firms were chosen opportunistically - that is, the researcher sought firms that were beginning to implement client/server development, rather than to seek a representative set firms who were at different stages of adoption and assimilation. A total of 53 interviews were conducted in the four firms (with a range of 9-16 interviews per firm). These interviews followed a semi-structured protocol and lasted approximately 60-90 minutes each. Most interviews were tape-recorded and transcribed verbatim. For the remaining interviews where tape-recording was not possible, detailed handwritten notes were taken and immediately transcribed following the interview. Additional background information about each firm was collected by conducting online searches of public databases and reading firm documents.

Since the objective of the field studies was to capture the insights of various stakeholders with regard to the client/server implementation process, each firm provided respondents ranging across IS, business unit, and HR/training departments, including a mix of management and nonmanagement employees. While the single largest category of interviews was conducted with IS managers (60% of total interviews), approximately equal numbers of interviews were conducted with respondents from other categories (e.g., HR/training managers, business unit managers, training staff, and IS employees).

Four phases of interviews were conducted, spanning 30 months from June 1993 to November 1995 (see Table 1). Phase 1 identified broad changes in IS management practices, the business and technology drivers underlying these changes, and the context and culture of each firm and its IS division.5 Phase 2 captured information about each firm's objectives for adopting client/server development, their implementation process, and approaches for retraining their software developers in the new technologies. Following Phase 2, preliminary analysis of the data revealed that two firms (Telco and Investco) did not intend to deploy client/server development with their existing IS staff but, rather planned to rely primarily on consultants or new hires with prior client/server experience to develop their systems. Since widespread deployment of client/server development was not planned for the existing IS staff in these two firms (Telco and Investco), they were not suitable candidates for ongoing study of secondary adoption and assimilation of client/server development. Follow-up research was conducted in the two remaining firms (Insureco and Chemco) where secondary adoption and assimilation of client/server development occurred during 1994-1996. Two additional research phases (Phases 3 and 4) were conducted in these firms, concluding in 1996.

Data Collection and Analysis

For Phase 1, the interview data were collected and analyzed without any particular theoretical framework in mind, however for the subsequent phases, the framework in Figure 4 provided a high-level lens to guide the interviews and to structure data analysis. The constructs in the center of Figure 4 were perceived as rather broad, and therefore more specific examples of adoption and assimilation processes were sought to operationalize and illustrate these constructs. For this reason, respondents were asked about key milestones, resources, participants, as well as critical events, obstacles or surprises that they perceived to be significant to implementation. Following each interview, detailed transcripts were immediately prepared and key themes were identified.6 As interview results accumulated, analytical induction methods (Miles & Huberman 1994) were used to identify themes that were important to the implementation process at each site. As with other interpretive research approaches, isolating these themes required constant iteration between the field study data and the emerging framework - a process known as dialogical reasoning (Klein & Myers, 1999). Next, the constant comparative method (Strauss & Corbin, 1993) was used to identify similarities and differences across field sites, and several key themes were found to be relevant for explaining the observed processes and outcomes in the various firms. Although these themes emerged from the field study results, I present these themes first (see Table 2) to allow readers to anticipate their importance in the case study results. In the subsequent Discussion section, which follows the results, these themes will be categorized according to the broader constructs of Figure 4. Given the space constraints, detailed results are presented from a single case site only (Insureco), however, interested readers may find details of the other three firms in related publications (Gallivan, 1995; 1996a; 1996b; 1997; 2001). The Discussion section will also suggest some critical contrasts between Insureco and other field study sites.

Results of Insureco Field Study

Company Overview. Insureco is among the ten largest U.S. life insurance firms, with over $90 billion in assets under management. The firm has more than 14,000 total employees nationwide, of which over one-third are located in its headquarters. Insureco operates in four business segments: group life insurance, retail (individual) insurance, financial investment services, and pension fund management. Total IS headcount in 1994 was over 900 employees, divided into six separate divisions as shown in Table 3: five application development divisions were distributed to their respective business units, plus two corporate-level IS groups that provide centralized services. One large centralized IS division (Corporate Information Services) manages the corporate IT infrastructure and oversees a rigid standard-setting process, while the other, smaller division implements Corporate Sector systems (e.g., payroll). The current hybrid organizational structure had been designed in 1988 to enable better alignment between the IS divisions and the business units, while retaining some firm-wide authority for centralized infrastructure management, emerging technology assessment, plus development and enforcement of standards. The total size of Insureco's two centralized IS divisions (nearly 400 IS employees and 40% of total IS staff) signifies the ongoing importance of centralization within the firm's overall IS function.

Organizational Culture of the Corporation. Insureco respondents perceive the firm's culture to be stodgy and bureaucratic, however, increased competition in insurance and financial services creates pressure for a more dynamic, entrepreneurial culture. Several senior business unit executives had recently been hired externally to re-invigorate the firm. The CIO explained:

It's a culture change for this company to go from a stodgy insurance company to a vibrant financial services company that can change and be agile, flexible, strong. A big, big, big change.... That's what we're trying to do is change the direction of this company. And people look at Insureco as a major, stodgy institution. But it's changing. It is changing!

In 1991, Insureco's business units experienced a "hugely dramatic downsizing and re-organization," and a "purge of staff" was undertaken in response to both increased competition in financial services and the general economic recession. Since 1991, however, employment has been stable, and respondents perceived high job security - perhaps too secure, since several respondents described a "sense of entitlement" that permitted many employees to be complacent in their jobs.

Technology Context and Use. Like other insurance firms, Insureco respondents described the firm as conservative in its use of IT and more a technology laggard than a leader. IS applications had historically supported actuarial calculations and other structured, batch-oriented financial transaction processing. In 1994, nearly all corporate systems were written in procedural third generation languages (COBOL or PL/1) or older, Assembly language code, and ran on mainframes with IBM's MVS operating system.

Insureco was historically one of the largest IS employers in the geographic region, hiring over 100 college graduates as programmers each year. The firm was recognized as the technology training ground for many local firms, and while some experienced IS employees left to seek employment in other firms, those employees who remained at Insureco worked in IS throughout their entire careers. Promotions occurred internally, with very little external hiring of experienced IS talent, and virtually no transfer of staff between IS and business units.

Few employees were hired with technical degrees; most new staff had a liberal arts background and, once hired, were immersed in a structured, eight-week programmer training course. Given the importance of training entrylevel programmers, Insureco created a sizable IS training department with over a dozen full-time trainers. This Technical Training department operates from a spacious, state-of-the-art training facility with a half-dozen workstation-equipped training classrooms that is the envy of HR/training managers in other local firms. Technical Training provides IT training to both IS and business unit employees and delivered over 700 classes and 8000 person-days of training in 1994. Insureco's significant investment in formal training infrastructure was critical to its implementation of client/server development, since the existing resources shaped its implementation philosophy and tactics.

Organizational Culture of the IS Division. Respondents characterized the firm's IS culture as "very insular," focused on technology itself, not very interested in the business itself or in IT's potential for supporting or transforming it. Prior relations between IS employees and business users had not been close, as IS employees were perceived as "not very customer-oriented" and not interested in networking with business users. Prior Experience with Adopting Technology Innovations. IS professionals had worked exclusively in the mainframe environment until 1992 and, given the traditional platforms and tools they used to develop systems in 1994, many respondents admitted to having little opportunity to experiment with new technologies or adopt work process innovations. This staid work environment was disrupted in the early 1990s, when PCs started to infiltrate the company via the business units. PC technology was introduced to Insureco by "smart mavericks in the business groups," and the IS division had little choice but to follow suit:

There was an explosion of interest in the PC technology and IS just panicked! There was a sense that `we gotta get our hands on it and manage it, or it will get the best of us.' That was the wake-up call!

Business users increasingly created their own standalone applications (using Paradox database software), with minimal involvement from Insureco's in-house IS staff. This forced IS employees to learn more about these technologies (PCs, GUI operating systems, and shrinkwrapped software) to keep abreast of the business units' technology use. The IS employees' software development practices continued to rely on mainframe systems and related languages, tools, and procedures.

Adopting Client/Server Technology. In 1992, Insureco's senior IS management commissioned their first client/server systems, which were implemented by Andersen Consulting project teams. Although this decision to implement client/server development fit the literal definition of primary innovation adoption (since client/server systems had been developed and were in operation at Insureco), secondary adoption of client/server among Insureco's own employees did not occur until 1994, two years later. Figure 5 shows a timeline of critical events related to client/server implementation, at Insureco. When Insureco decided that it was ready to evaluate client/server development for possible adoption among its own staff, Corporate Information Services (the largest centralized IS group) founded two new committees: the Client/Server Environment Committee and the Reskilling Task Force. The former group sought to investigate and establish new technology standards for the client/server platform, while the latter group (the Reskilling Task Force) sought to identify the range of skill sets required for IS professionals to operate in the new environment. The Client/Server Environment Committee sought to identify a clear set of hardware, software and networking standards consistent with the standards-setting mission of the Corporate Information Services division, which the CIO described as "a very aggressive, coordinative, collaborative, facilitative, and driving role ... [to] manage the overall standards process from start to finish, including communicating what the standards are."

The Reskilling Task Force was a high-visibility initiative with significant financial support (over $2 million) from both the CIO's office and the Human Resources division to provide the necessary client/server training to both IS and business unit employees. Later renamed Reskilling `95, this task force oversaw a highly centralized initiative to manage the deployment of client/server development and to help all employees make the transition to the new skill sets required. While Insureco's overall strategy and planning for implementing client/server development was centralized, the actual implementation process in each IS division was partially decentralized at the business unit level (see Table 3).

All senior IS executives and managers participated in the planning and implementation of client/server in one of the following four ways. First, all senior IS executives served on the Reskilling Task Force, which selected the consulting firm Ernst & Young to oversee the Reskilling '95 initiative. Second, the Ernst & Young consultants solicited 40 additional IS managers for focus groups to incorporate their input in developing a detailed implementation strategy. Third, IS managers within each of the six divisions created "Sector Transition Plans" to target the necessary skill sets and identify changes in work processes that would occur within their business units. This included creating a structured skill profile and target skill plan for each IS employee and organizing this information into a proprietary Skills Management System database! Finally, on a project-by-project basis, application project managers conducted structured skills assessment workshops to identify reskilling objectives for each employee, and to design the necessary composition of each project team.

At the onset of each new client/server project, every IS employee and manager on the project team provided a self-assessment of their own current expertise for each relevant skill, any potential skill gaps, plus various activities to remedy them. For example, these activities could include formal classroom training or informal personal development activities to improve the employees' technology, interpersonal, or business skills. Examples of informal personal development activities aimed at reskilling IS employees included "have lunch with a business unit associate," "solicit advice from others," or "sit in on data modeling session."

Reskilling IS Employees through Classroom Training. The largest share of the overall client/server implementation effort was focused on traditional, classroom training to reskill IS employees and managers in new technical skills.

In 1994, a structured "client/server curriculum" was developed by Technical Training, consisting of more than 20 courses. Three separate curriculum tracks were established for application developers, network support personnel, and IS managers. While the new client/server training curriculum focused exclusively on technical and system development process skills, there was widespread discussion of the need to update both the business knowledge and interpersonal skills of IS employees. The CIO articulated this need:

IS historically has attracted a fairly analytic, heads-down, focused kind of person. We're in a different business now. We're really in a consultative business to a large measure ... and we need to change the behavioral focus from being inward- and technologically-focused to being externally- and customer-focused. [We need] to try to help people transition from the more heads-down introspective roles and behaviors that were successful and appropriate in the"past when IS was a large, centralized function in a much more simplistic technology world ... to the behaviors that we believe are the success factors of the future: focusing on customers, people-orientation, quality, and teamwork.

In general, respondents made frequent references to the need to change the culture of the IS workforce and their approach to dealing with business users, but they offered little evidence of actual changes that were taking place. When prompted for more information, respondents sized up the situation in one of two ways: some respondents assumed that the IS work culture could be altered by sending respondents to training classes (e.g., to learn about business issues and interpersonal skills); others believed that culture change would be difficult or impossible to achieve, and that and formal training could do little to alter this reality. The CIO belonged to the first category, as her perspective was more optimistic than most:

There's a whole education process that all the managers in the company are required to [participate in] to take so many courses ... and all that is on change, transformation, and leadership... We are breaking down the barriers ... in terms of the internal workings of the company, in terms of our people.

Organizational Culture as an Obstacle to Innovation. The Director of Technical Training who oversaw the $2 million budget to implement Reskilling '95 believed in the value of implementing change through both formal training, as well as hands-on practice, guided by mentors or coaches. His statement that "90% of learning goes on outside the classroom" was repeated by several respondents, however, the dominant mechanism for reskilling IS staff was still formal training. The focal role of training at Insureco was a double-edged sword: IS employees had ready access to enormous training resources, however, many respondents criticized the "paternalistic" philosophy underlying Insureco's culture and training orientation - namely that the parent company was responsible for employees' career path and personal development, rather than employees themselves. As described above, each IS Division created a "Sector Transition Plan" early in the implementation process which described its detailed implementation plan and laid out skills objectives and mechanisms for each IS staff member to remedy any skill gaps. One IS manager criticized the resulting "sense of entitlement" among employees who assumed that the company was responsible for their ongoing employment, and would guide their career path. She criticized this belief as being especially prevalent among "the entrenched people," including Insureco's older employees:

Many of the older employees are just waiting, looking toward retirement. They expect that the company should train them on company time, rather than showing initiative themselves. They have the `send-me-to-a-class' mentality.... But the young people, they are going out, buying their own PCs, eating this stuff up.

Other respondents explained that such a "sense of entitlement" was the natural outcome of working in a stable company within a bureaucratic industry (insurance) that had long been regulated. Several respondents noted that such complacent employee attitudes would serve as obstacles to change - regardless of the level of resources that Insureco dedicated to implementing client/server development - or any other innovation. Ironically, the huge resource investment represented by Insureco's large Technical Training staff and facility was perceived as partly to blame for these complacent attitudes, since these training resources were the hallmark of Insureco's emphasis on top-down planning, control, and formalized implementation approaches. This philosophy that management would plan and oversee any change in a top-down fashion was perceived to exacerbate employees' lack of self-determination or responsibility for their careers, to foster an attitude of dependence. Some respondents complained that this created a "do-it-to-me" view of change management and a "send-me-to-a-class" mentality toward their own career development and personal growth.

Despite Insureco's structured, ambitious, and generously-funded efforts to implement client/server development, respondents also criticized this approach as too strongly focused on providing "skills training" rather than on "educating" IS professionals more broadly for the future challenges. One manager, in particular, argued that the 21 st century work environment would require changes to the roles and mindset of IS professionals, and that formal training in any specific technology would do little to prepare them for the magnitude of this transformation:

We need to rely more on our own people's ability to take the initiative, to do the reading on their own. That's the other issue -- the culture here. People will not do things on their own. They are sitting there, asking [management] "what are you doing for me?"... Reskilling here has been very dependent upon the company doing things. We are trying to change that mindset, to help people to see "you need to take the initiative too." No one reads trade journals here or attends any professional networking [opportunities] here. If you talked to people here, they wouldn't know what the Internet is.

So, there is not that self-education that needs to take place.... I am not blaming people. I'm saying that this is the culture at Insureco, and change management is the toughest thing. Trying to get people to change: that's our biggest hurdle right now. It's not getting people to learn C++, but trying to figure our how we can get them to understand how they can do things - all the time - differently.

Despite the training and development activities that IS managers were required to complete, some of these managers admitted their skepticism that the required changes to Insureco's culture and work processes would occur quickly, if ever. Some faulted the inertia of middle management and their resistance to change, which respondents blamed on middle managers trying to protect their own interests. One IS employee described the resistance to change as:

... like trying to turn around the Queen Mary in Boston Harbor. It isn't going to be easy... How do you get the bottleneck -- which is sometimes the manager - to do that? Sometimes the answer is that you have to remove the manager to get rid of the bottleneck.

Summary of Insureco Organizational Context and Implementation Strategy

In general, Insureco is a firm that has been conservative in its use of IT, but with the adoption of client/server development, is seeking to transform the skills, processes, roles, and culture of system development. These considerable changes to employees' roles and skills were envisioned by senior IS managers as part of the client/server implementation, and included increasing employees' business knowledge and interpersonal skills, and improving their relationship with business users. Client/server development was envisioned as the springboard to radical transformation of what IS employees know and do, and in terms of how they add value to the business. These planned changes in the IS department occurred against a backdrop that featured even more ambitious corporate-level objectives for transforming this staid insurance firm into a more agile, competitive financial services leader. These objectives represent substantial challenges, and the success of client/server development as a technology innovation was being evaluated, in part, based on progress toward achieving these broader objectives in the IS division and in the business units.

Nearly all IS employees attended training classes and learned the mechanics of client/server development, according to records provided by staff from the Technical Training department. Each of the decentralized IS divisions had successfully implemented one or more client/server applications during the time period of this study. However, with regard to the broader, transformational objectives of changing IS employees' roles to become externally focused, customer-oriented, and "consultative," progress has been more problematic. In fact, the Director of Technical Training 8 who was the champion for the grand design of Insureco's Reskilling '95, including all training/ HR components of client/server implementation, was extremely frustrated with the minimal progress that had been achieved in terms of changing the processes and culture of system development at Insureco. She attributed this lack of progress to middle- and senior-management resistance to change. In summary, while all six IS divisions comprising Insureco's IS function had indeed delivered one or more working client/server applications (a product innovation in terms of the technology that IS delivers to business units), there were disparate views regarding whether the intended objectives for client/server development and Reskilling '95 had been achieved (a process innovation in terms of how Insureco develops software). Subsequent follow-up with the Director of Technical Training revealed an ongoing pessimism regarding the lack of progress in changing IS employees' perceived roles from being "application programmers" to becoming more consultative "technology solutions providers."

Despite the fact that Insureco was implementing a technology innovation and was seeking to substantially innovate its business processes related to systems development, they followed a topdown implementation approach that was not particularly innovative - sending IS staff to training classes - but one that was well-suited to its formalized culture, available training resources, and prior history for implementing change in a topdown manner. Despite the lack of progress in implementing broader role changes for IS employees, Insureco appears to be successful in achieving the more limited objectives of deploying client/server technology and training its IS employees to produce functional client/server systems.

Discussion and Integration

The implementation of client/server development at Insureco was managed in a structured, topdown fashion - what some might describe as a textbook example of coordinated planning and execution. While there is insufficient space here to describe how Insureco's implementation approach differed from that observed in the other research sites, differences in the level of management support, resource commitment, and assumptions about how to attain a reskilled IS workforce with client/server development expertise were substantial, and these differences in implementation strategy are important to understanding the outcomes achieved in the other sites (Gallivan, 1996; 1997; 2001). It is important to underscore that identifying these implementation differences, through use of the constant comparative method across multiple case study sites (Strauss & Corbin, 1990) was critical to identifying the themes in Table 2. By analyzing these differences across firms, this helped hone in on themes that were critical in explaining the processes and outcomes at Insureco - a technique known as theoretical replication (Yin, 1994). A review of the themes in Table 2 suggests that the attributes they represent can exert one of several possible effects on the Insureco's implementation outcomes, including some factors exerting one effect on the early stages of assimilation (initiation and adoption) versus a different effect on the later stages (adaptation, acceptance, routinization, and infusion).

* Some attributes facilitated all stages of innovation assimilation,

* Some attributes constrained all stages of innovation assimilation,

* Some attributes facilitated early stages of innovation assimilation, while constraining later progress,

* Some attributes exerted mixed effects on assimilation, due to their interaction with other factors.

This discussion will analyze these eight themes and relate them to the broader constructs in Figure 4. Once Insureco's managers made the primary adoption decision to migrate its software development activities to client/server development, the firm pursued an implementation strategy that was very much consistent with its context and culture. Since the field study did not address the primary innovation adoption process, which had already occurred when the study began in 1993, this discussion focuses on the "Secondary Adoption and Organizational Assimilation Processes" comprising the center of Figure 4. The sections below evaluates the important attributes of Insureco's context, culture, and implementation approach that influenced its outcomes, and classifies each of the eight themes into one of the following constructs in Figure 4 - managerial interventions, subjective norms, and facilitating conditions.

Attributes that Facilitate All Stages of Assimilation

Two aspects of Insureco's implementation approach were perceived to facilitate implementation of client/server development, corresponding to Themes A and B in Table 2.

Managerial Interventions

Theme A. Strong and clearly-communicated messages of top management support for an innovation may facilitate all stages of innovation assimilation - including both early stages (e.g., initiation and adoption) and later stages (adaptation, acceptance, routinization, and infusion).

* Theme B. High levels of resources committed may facilitate all stages of innovation assimilation.

These attributes acknowledge the strong top management support that was communicated to all participants in the initiative as well as heavy resource commitment to the initiative. These factors influenced secondary adopter's perceptions of management's commitment to this initiative and provided necessary resources for managers to drive implementation in a top-down manner through structured planning sessions, focus groups, and skills assessments workshops. In fact, with regard to management communication practices, Insureco was the only one of the four firms studied that explicitly characterized its implementation of client/server development as an "initiative" - one which they clearly labeled as Reskilling '95 (later changed to Reskilling 2000), and significant resources from both the CIO and Human Resources departments.

Strong and clearly communicated messages of management support for the initiative is an example of a managerial intervention, as is a high level of resource commitment to the project. While the high levels of resources committed were a byproduct of management's strong support for the initiative, each factor should be considered separately, in terms of its effect on innovation assimilation. High resource levels do not always accompany management support for an innovation and, in some cases, may exist in the absence of strong management support for the innovation. For example, another field site (Chemco) that pursued a very different implementation strategy than Insureco, demonstrated strong management support for client/server development without committing significant resources to their initiative (Gallivan, 1997).

While these positive attributes described above (clearly-communicated messages of top management support and high resource levels) both served to facilitate Insureco's Reskilling '95 initiative, the discussion below suggests that the underlying context which gave rise to these positive attributes also created an environment that undermined the likelihood of Insureco achieving many of its objectives - particularly the changes in work processes and organizational culture. Attributes that Facilitate Early Stages of Assimilation (but not necessarily later stages) This section identifies Themes C and D as critical for understanding innovation assimilation and classifies them as follows:

Subjective Norms:

* Theme C. A strong, top-down, bureaucratic organizational culture may facilitate early stages of innovation assimilation (i.e., innovation initiation and adoption), however such a bureaucratic culture may constrain later stages of innovation assimilation (i.e., postadoption stages, such as adaptation and infusion).

Managerial Interventions:

* Theme D. Highly centralized planning and oversight of an organizational initiative may facilitate early stages of innovation assimilation, however, such centralized planning and oversight may constrain later stages of assimilation.

Insureco has a strong, top-down, bureaucratic organizational culture, as shown by many respondents' comments. First, the firm competes in an industry (insurance) that has traditionally been very bureaucratic, slow to change, and has also been a technology laggard rather than an early adopter of new technologies, compared to other industries (Henderson & Lentz, 1996). Despite the fact that Insureco decentralized some system development functions to the business units prior to this study, there were still strong elements of centralization within the IS division. This is demonstrated, in part, by the substantial size of the remaining "corporate" (centralized) IS functions, accounting for 40% of total IS headcount (see Table 3). In addition, one of the centralized IS divisions (Corporate Information Systems) played a very strong role of planning infrastructure, setting technical standards, and enforcing them - a set of roles that exerted considerable influence and control over Insureco's implementation of Reskilling '95.

While the term "bureaucratic" often suggests negative connotations, there are some positive aspects associated with it. Being "bureaucratic" may mean that an organization plans thoroughly, commits the necessary resources from the top, is attuned to detail, and follows through on its commitments. All of these positive attributes are reflected in Insureco's approach to implementing client/server development. Consistent with the firm's bureaucratic and partially-centralized organizational structure, oversight of the client/server development initiative was managed with both centralized and decentralized elements. Insureco was the only field site where IS managers perceived of client/server development as a formal "initiative," and this contrasted dramatically with the implementation approach in other research sites - where the level of senior management planning and oversight ranged from moderate to none. In this regard Insureco's centralized, bureaucratic approach for managing Reskilling `95 was an asset, since it was well-funded and deliberately managed. As a result, Insureco progressed much further in adopting client/server development broadly across the firm - at least for the early assimilation stages - than did some of the other firms studied.

While the bureaucratic organizational culture at Insureco ensured a high level of structure, resources, and follow-through to its implementation effort, this also posed some obstacles for achieving many of the changes required to fully exploit the benefits of client/server development (i.e., infusion). The culture at Insureco, in addition to being bureaucratic, was paternalistic - that is, employees expected that the corporation would take care of them - which included charting a course for each employee's career development, and providing the necessary training classes. While the generous slack resources available to Reskilling '95 were a blessing in many ways, they also served to perpetuate an employee culture of dependence on corporate training that was inconsistent with the stated objective of employees taking charge of their own careers and their need to initiate new habits of ongoing learning. These issues are further discussed in the next section.

Attributes that Constrain All Stages of Assimilation

This section identifies Themes E and F and categorizes them as follows:

Subjective Norms

Theme E. Cultural norms that reinforce that the locus of responsibility for ongoing learning and career development resides with the organization may constrain later stages of assimilation (as occurred at Insureco). Conversely, cultural norms that reinforce that the locus of responsibility for ongoing learning and career development resides with the individual taking the initiative may facilitate later stages of assimilation (as occurred at other field sites).

* Theme F. Cultural norms that reinforce a narrow definition of employees' job roles may constrain innovation assimilation (i.e., "I am an application programmer") whereas cultural norms that reinforce a broader definition of employees' job roles facilitate innovation assimilation (i.e., I provide technology support for business initiatives").

The paternalistic culture at Insureco conveyed a sense of job security - but also reinforced employees' beliefs that the firm would take care of them. This sense of entitlement unfortunately led to a subjective norm regarding organizational change, whereby employees assumed a relatively passive role in their "do-it-to-me" notions of change management. IS employees expected that the company was responsible for providing whatever resources and direction it would take for them to become successful client/server developers - such as creating three specialized curriculum tracks for client/server training courses, providing skills assessment workshops, offering time off to attend training, etc. Thus, the underlying cultural belief that the firm was ultimately responsible for employees' career development inhibited achieving many of the desired benefits of Reskilling '95. Such cultural beliefs and expectations, in turn, shaped another subjective norm about the limited importance of individual employees taking initiative. In short, there were several managerial interventions taken at Insureco which made it possible to initiate the early stages of client/server development (strong management support, high resource levels, centralized planning and support), yet which had undesirable side-effects of sending mixed messages to Insureco's IS staff and, consequently, reducing the likelihood of fully assimilating the innovation.

Another subjective norm that impeded the outcomes of Insureco's initiative were the fairly narrow role perceptions held by some IS employees of being "an application programmer" only. This role perception limited employees' sense of responsibility for addressing and resolving problems that might occur beyond the level of software code. For example, one manager described how some mainframe application programmers perceived their job duties as restricted to writing software application code, and as a result, such employees believed that problems arising from computer hardware, operating systems, networks, or interactions among these components were "not part of their job description." Employees who framed their job roles in such a narrow manner had difficulty accepting the broader set of responsibilities that deploying, supporting, and trouble-shooting client/server systems entailed.

Creating and supporting successful client/server systems depends on successful synergy among an array of technology components (not limited to application software alone), and full assimilation of the benefits of client/server development necessitates such a broader framing of employees' job roles. Since Insureco's IS staff was perceived as "not very customer-oriented" - that is, more focused on technology itself than its potential value to the business, then any innovation which required them to broaden their roles to work more closely with users was a challenge to those employees who held these narrow role perceptions. Table 4 summarizes the traditional roles of software developers and the new roles that are enabled by client/server development. While closer working relationships between IS and user departments are not inherently mandated by client/server technology, new approaches, such as rapid prototyping and iterative user feedback are nevertheless facilitated by client/server development. Furthermore, according to some authorities (Vaskevitch, 1993), such changes in work processes and relationships among developers and users are essential to achieving the benefits of using client/server development. Thus, for those IS departments, such as Insureco, which lacked a history of close working relationship between the IS department and users, unless IS employees already perceived their job roles in broader terms - or were flexible to adapt to these new roles - these such a traditional, narrow view of software developers' roles would inhibit the firm's ability to fully assimilate client/server development.

Attributes that Exert Mixed Effects on Assimilation (due to interaction with other factors)

The last two themes identified in Table 2, themes G and H, have a more complex relationship with innovation assimilation at Insureco, compared to the prior themes.

Either Facilitating or Constraining Conditions

* Theme G. High job security may serve as either a facilitator or a constraint for employees' motivation to adapt to the changes in work processes associated with an innovation, depending on interactions with individual attributes. Job security thus moderates the relationship between individual attributes and later stages of assimilation.

* Theme H. Individual attributes will not influence early stages of assimilation (e.g., adoption) under an authority adoption scenario, however, they will affect later stages of assimilation since they influence employees' willingness and ability to adapt to changes in work processes associated with the innovation. Attributes that may facilitate such adaptation include high levels of personal innovativeness, personal resilience, and tolerance of ambiguity. Attributes that may constrain adaptation include low levels of these attributes, plus longer job tenure or higher seniority.

While job security at Insureco was identified as an important factor - especially since few firms offered such high job security during the economic recession of the early 1990s, a high level of job security by itself did not appear to be directly related to respondents' innovation adoption behavior. While some respondents perceived high job security as potentially undermining employees' motivation to keep their skills up-to-date (because they were guaranteed a job at Insureco regardless), others suggested that high levels of job security provided a cushion or buffer that freed employees to experiment with an innovation, without fear that potential mistakes could cost them their jobs. Thus, although job security at Insureco was universally regarded as high, it would be too simplistic to generalize about this factor as either a direct facilitator or a constraint upon employees' assimilation behavior. Job security does matter, however, in that it may interact with the employee's own internal motivation or willingness to innovate in shaping adoption behavior and related outcomes. I argue that job security, as moderated by specific individual attributes, may have a facilitating or constraining effect on employees' assimilation behavior (rather than a direct effect by itself).

Several Insureco respondents suggested that employees' age and level of seniority in the company were relevant to their willingness to learn client/server development. For example, some respondents perceived that older employees and those near retirement lacked the motivation to learn and adapt. Curiously, such statements regarding the negative influence of age or seniority were common at Insureco, but not at the other field study sites whose cultures stressed the importance of individual initiative. While age and higher seniority may serve as constraints upon innovative behavior for some older IS professionals at Insureco, it is difficult to generalize about their influence more broadly. This apparent influence of greater seniority or age on employees' innovative behavior may be a by-product of Insureco's bureaucratic culture, combined with high job security. Specifically, when job security is high, employees who are willing to innovate - to try new things can be more comfortable doing so, since the risk of failure is low. Conversely, in a bureaucratic organizational culture such as Insureco, however, employees who resist change can do so without fear of reprisals, since they know that their jobs are secure. The preceding analysis is not to suggest that all older or more senior employees at Insureco resisted change or were incapable of learning client/server development or adapting to new work processes, but some Insureco respondents nevertheless perceived these attributes to be higher liabilities. While there are likely to be individual differences that facilitate (or constrain) innovation assimilation, this negative influence of seniority and age appear to be specific to these other attributes that were present at Insureco - high job security and a bureaucratic corporate culture that has previously valued stability rather than innovation.

Furthermore, respondents suggested other individual differences as determinants of employees' willingness to adopt a technology innovation and adapt to changes in work processes and roles. These attributes included psychological and cognitive style constructs such as personal innovativeness (Agarwal & Prasad, 1998), personal resilience (Conner, 1992; 1998), and tolerance for ambiguity (MacDonald, 1970). While this paper has not reviewed the literature on individual differences pertaining to innovation adoption, their influence on employees' willingness and ability to adapt to change is discussed elsewhere (Agarwal & Prasad, 1998; Nambisan, Agarwal Tanniru,1999; Karahanna & Agarwal, 2000; Gallivan, 1995; 1997). Respondents at Insureco and other field sites perceived employees' demographic and cognitive style attributes as important influences on their secondary adoption and assimilation behaviors. It is likely, however, that under a contingent, authority innovation adoption scenario, these individual differences will manifest themselves at the later stages of assimilation -- when employees are expected to adapt to changes in work processes - rather than in the early assimilation stages, when they are told to adopt the innovation. For this reason, I believe that individual differences are more likely to affect later - but not earlier - stages of assimilation and, as described above, will interact with contextual factors such as job security.

Summary of Themes that Influence Assimilation of Client Server Development

This section has reviewed eight themes that were derived from analytical induction of the field study data from Insureco (plus three other research sites), and has classified them according to the three factors that intervene between primary and secondary adoption in Figure 4 - managerial interventions, subjective norms, and facilitating conditions. These themes, when superimposed on the general constructs in Figure 4, helps to operationalize these constructs and to provide a level of detail that permits development and testing of formal propositions. To formulate these themes more concretely - as well as to show the complex network of relationships among them, Figure 6 specifies the eight themes, showing their direction of influence (either positive or negative) on innovation assimilation, as well as their direction of influence on each other. Each construct in Figure 6 is labeled to show the "theme" to which it maps in Table 2, and in the above discussion. It is important to note that some of the attributes shown in Figure 6 exert a positive influence on early assimilation stages (i.e., adoption), but a negative influence on later stages (i.e., routinization and infusion).

For example, Insureco's bureaucratic organizational culture has some positive effects on assimilation (Theme C), because it leads to centralized planning and support for change initiatives undertaken by the firm (Theme D). By the same token, however, this bureaucratic culture may reinforce employees' narrow job role definitions (Theme F) and their beliefs that "the company is responsible for learning and career development" (Theme E), both of which, in turn, inhibit the later stages of innovation assimilation. While this discussion section has analyzed the importance of each of the themes depicted in Figure 6, including their direction of influence on innovation assimilation, some constructs are shown as intervening variables that mediate the relationship between other constructs (e.g., narrow job role definitions mediates between bureaucratic organizational culture and later stages of assimilation). Due to space constraints, however, there is insufficient room to explain or justify the specific sequence of constructs and linkages posited in Figure 6. Therefore, the themes appearing in Table 2 and the cause-and-effect relationships that are implied by Figure 6 are offered as propositions for future examination and empirical validation.

Conclusion

This paper has proposed a hybrid framework, which draws its insights from both the literature on individual innovation adoption as well as from process research on organizational implementation. Three primary contributions result from this study. The first contribution is to provide a review of the traditional innovation adoption literature and to document its strengths and limitations with regard to different IT innovation types and adoption contexts. By highlighting areas where the underlying assumptions of these traditional innovation adoption models are either well- or poorly-- suited to the actual context of innovation adoption (Figure 3), this study has described various scenarios where new constructs and models (e.g., absorptive capacity) are needed to complement traditional frameworks. Second, this paper proposes a hybrid process/factor model (Shaw & Jarvenpaa, 1997) that combines some constructs from traditional individual adoption models with features of process and stage research models of organizational-level implementation (Markus & Robey 1988; Prescott & Conger, 1995). In creating such a hybrid framework, spanning levels of analysis and containing both factors and events, I suggest a complex and, hopefully, a more realistic framework that can explain the interplay among organizational context variables, attributes of managers' implementation strategies, and other characteristics that, in aggregate, shape assimilation processes and outcomes (as shown in Figures 4 and 6).

The third contribution this paper offers is a rich description of one organization implementing client/server development - an important technology innovation that has now diffused into most organizations and yet an innovation that has received little attention from academic IS researchers. The results of this longitudinal field study offer a useful complement to the few survey-based studies that have examined the implementation objectives of many firms choosing to adopt client/server development, yet whose results have been limited to descriptive analyses of their goals and observed benefits (ChengalurSmith & Duchessi, 1998; 1999). This study helps to fill in the gaps that intervene between managerial goal-setting for an innovation and evaluation of its benefits by examining the processes that link objectives with outcomes. As with other qualitative research studies, this study and the framework that I present are valuable to the extent that they serve four objectives (Walsham, 1995), namely to: (1) develop new concepts, (2) generate new theory, (3) allow specific implications to be drawn, and (4) contribute rich insight.

Given that the goal of this study was theory development rather than theory-testing, the multiple case study approach employed here best meets these objectives - that is, to provide rich data with which to illustrate the initial research framework (Figure 4), and to flesh out the details in order to identify specific propositions for future validation. The case study method helps to focus on the role of the organization's history and context, as they influence both processes and outcomes, and can serve to delineate the temporal nature of the change processes. Since this very approach to in-depth, multiple informant research methods has been advocated by several scholars in their critique of traditional innovation adoption frameworks (Rogers, 1983; Fichman, 1992; Tornatzky & Klein, 1982), the case study method employed here serves as a useful bridge to developing new concepts and generating new theory. In doing so, the approach followed here achieves the goals advocated by Rogers (1983, p. 358), when he said that researchers should:

... follow a multiple respondent data-gathering design... in which interview, archival and other data are gathered [to] ... permit greater insight in tracing the nature of the innovation process in each organization.... The researcher learns more about less, rather than less about more. Given our present rather limited understanding of innovation in organizations, the indepth approach of process research is more appropriate.

While the theoretical framework proposed above incorporates some constructs previously suggested in both the individual adoption and organizational implementation literatures, it is the synthesis of these constructs that is novel, and thus requires additional validation. While this framework appears to be a useful lens for illustrating the events and themes that emerged as critical to Insureco's implementation processes, the possibility exists that other important events or themes may have been overlooked, or perhaps certain themes could have been classified differently than I have done here. While additional case studies stemming from this same research project will also be used to further validate and refine this framework (Gallivan, 1996), it is also hoped that researchers who study other contemporary technological innovations of the 21 st century (e.g., Java programming, virtual teams, and E-commerce) will apply this framework to their own field study research data and, in turn, evaluate, critique, and suggest modifications to the framework, as necessary.

While the theoretical framework is illustrated by using it to analyze the rich case detail from one field study, further evaluation of the framework are necessary. Figures 4 and 6 are offered as generalizable frameworks that seek to explain the processes and factors that influence contingent, authority innovations adoption in organizations. The nature of generalization sought by case studies is somewhat different than that of survey studies - and has been labeled analytic generalization (Yin, 1994; Orlikowski, 1993) or deductive idiographic generalization (Baskerville, 1996; Baskerville & Lee, 1999), rather than statistical generalization. While the events occurring at Insureco are not alleged to be statistically representative of other firms implementing client/server development, generalization is sought in terms of theory - specifically, the constructs and relationships among them Win, 1994). The objective is to generalize to theoretical concepts and patterns that capture the critical variables underlying the observed events, and to offer these concepts and patterns to practitioners and researchers as a useful formulation that may be extended to other scenarios. While the theory suggested in Figures 4 and 6 is generalizable - that is, it is capable of being generalized to other firms and to other innovations (Baskerville & Lee, 1999), it has not yet been generalized - that is, applied and shown to represent the factors and events that characterize implementation of authority-based innovation decisions in other firms. The actual steps to employ this generalizable framework and evaluate whether it adequately generalizes to other settings lies in ongoing and future research - both in the current program of research on innovation adoption and implementation and in the work of other innovation researchers.