Because of network externalities, the success of a software product may depend in part on the size of its installed base and its conformance to industry standards. This research builds a hedonic model to determine the effects of network externalities, standards, intrinsic features and a time trend on microcomputer spreadsheet software prices. When data for a sample of products during the 19871992 time period were analyzed using this model, four main results emerged: 1) Network externalities, as measured by the size of a product's installed base, significantly increased the price of spreadsheet products: a one percent increase in a product's installed base was associated with a 0.75% increase in its price. 2) Products which adhered to the dominant standard, the Lotus menu tree interface, commanded prices which were higher by an average of 46%. 3) Although nominal prices increased slightly during this time period, quality-adjusted prices declined by an average of 16% per year. 4) The hed...

This paper presents the findings of an empirical study into two organizations' experiences with the adoption and use of CASE tools over time. Using a grounded theory research approach, the study characterizes the organizations' experiences in terms of processes of incremental or radical organizational change. These findings are used to develop a theoretical framework for conceptualizing the organizational issues around the adoption and use of these tools--issues that have been largely missing from contemporary discussions of CASE tools. The paper thus has important implications for research and practice. Specifically, the framework and findings suggest that in order to account for the experiences and outcomes associated with CASE tools, research- ers should consider the social context of systems development, the intentions and actions of key players, and the implementation process followed by the organization. Similarly, the paper suggests that practitioners will be better able to manage their organizations' experiences with CASE tools if they understand that such implementations involve a process of organizational change over time and not merely the installation of a new technology.

Accepted for publication in

The burden of organizational learning surrounding software process innovations (SPIs)—and complex organizational technologies in general—creates a "knowledge barrier" that inhibits diffusion. Paul Attewell has suggested that many organizations will defer adoption until knowledge barriers have been sufficiently lowered; however, this leaves open the question of which organizations should be more likely to innovate, even in face of high knowledge barriers. It is proposed here that organizations will innovate in the presence of knowledge barriers when the burden of organizational learning is effectively lower, either because much of the required know-how already exists within the organization, or because such knowledge can be acquired more easily or more economically. Specifically, it is hypothesized that organizations will have a greater propensity to initiate and sustain the assimilation of SPIs when they have a greater scale of activities over which learning costs can be spread (learning-related scale), more extensive existing knowledge related to the focal innovation (related knowledge), and a greater diversity of technical knowledge and activities (diversity). An empirical study using data on the assimilation of object-oriented programming languages (OOPLs) by 608 IT organizations strongly confirmed the importance of the three hypothesized factors in explaining the assimilation of OOPLs.

Introduction The task of deciding when and how to innovate is not an easy one. Consider the following managerial quandaries: . A CIO has joined a firm that lags in the adoption of emerging information technologies. He wonders: just how innovative should this firm be going forward, and what can be done to position it to be more willing and able to assume the challenge of early adoption? . A VP of marketing resides in a firm that generally leads in IT innovation, and must decide whether to endorse the immediate adoption of a particular innovation with major implications for marketing strategy. She wonders: are her firm's needs in this area and "readiness" to adopt sufficient to justify taking the lead with this specific innovation? If so, how should the assimilation process be managed? . A product manager must design a deployment strategy for an innovative software development tool. He wonders: how fast can this technology diffu

Abstract not found

The extent of organizational innovation with IT, an important construct in the IT innovation literature, has been measured in many different ways. Some measures are more narrowly focused while others aggregate innovative behaviors across a set of innovations or across stages in the assimilation lifecycle within organizations. There appear to be some significant tradeoffs involving aggregation. More aggregated measures can be more robust and generalizable and can promote stronger predictive validity, while less aggregated measures allow more context-specific investigations and can preserve clearer theoretical interpretations. This article begins with a conceptual analysis that identifies the circumstances when these tradeoffs are most likely to favor aggregated measures. It is found that aggregation should be favorable when: (1) the researcher's interest is in general innovation or a model that generalizes to a class of innovations, (2) antecedents have effects in the same direction in all assimilation stages, (3) characteristics of organizations can be treated as constant across the innovations in the study, (4) characteristics of innovations can not be treated as constant across organizations in the study, (5) the set of innovations being aggregated includes substitutes or moderate complements, and (6) sources of noise in the measurement of innovation may be present. The article then presents an empirical study using data on the adoption of software process technologies by 608 US based corporations. This study—which had circumstances quite favorable to aggregation—found that aggregating across three innovations within a technology class more than doubled the variance explained compared to single innovation models. Aggregating across assimilation stages had a slight positive effect on predictive validity. Taken together, these results provide initial confirmation of the conclusions from the conceptual analysis regarding the circumstances favoring aggregation.

Abstract not found

The cognitive activities performed by systems designers during systems development include problem understanding, problem decomposition and solution speci"cation. One aspect of object-oriented (OO) approaches to system design that appeals to many adopting organizations is the purported naturalness, i.e. the consistency of OO approaches with these cognitive activities of problem solving. Essentially, OO aims to abstract components of the problem of system development to a high level that parallels problem solving in the world the system represents. In other words, knowing how a problem is solved in the real world informs one about how the OO system solves the problem. Thus, the OO development process and the resulting OO model are believed to be consistent with innate cognitive activities and consistent with the problem/real world, respectively. A cognitive mapping method was used to ask graduate students experienced with OO techniques about their perceptions of what is complex (di$cult to understand) about OO systems. Their responses include a set of concepts, categories of similar concepts and cognitive maps that reveal what they believe is di$cult about using OO techniques. Evaluating these perceptions in terms of the cognitive activities of system design reveals problem decomposition was perceived as the activity that caused the most di$culties related to learning OO techniques. Problem understanding was the goal of the participants, while the solution activity ranked lower in importance but contained many issues essential to systems development and in#uenced problem understanding.

This paper reports from an effort to engineer an object-oriented method for analysis and design of computer systems. The effort was governed by a paradigm for learning methods rather than a paradigm for working with methods. We discuss this paradigm by exploring three issues involved in method engineering: (1) the relation between learning the method and working with the method; (2) the role of principles, patterns, and guidelines in explaining the method; and (3) the relation between concepts for reflection and modeling and concrete representations used to create texts and diagrams.