Your SlideShare is downloading. ×
Aligning Software Processes with Strategy
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Aligning Software Processes with Strategy

589
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
589
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
18
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Aligning Software Processes with Strategy Sandra A. Slaughter* David A. Tepper School of Business Carnegie Mellon University Tech & Frew Streets Pittsburgh, PA Phone: (412) 268-2308 Fax: (412) 268-7345 Email: sandras@andrew.cmu.edu Linda Levine Software Engineering Institute Pittsburgh, PA Email: ll@sei.cmu.edu Balasubramaniam Ramesh Georgia State University Atlanta, GA Email: bramesh@gsu.edu Jan Pries-Heje The IT University of Copenhagen Copenhagen, Denmark Email: jph@itu.dk Richard Baskerville Georgia State University Atlanta, GA Email: baskerville@acm.org April 15, 2006 * Contact author for this paper. Do not cite, quote, copy or distribute without permission of the authors
  • 2. Aligning Software Processes with Strategy Acknowledgements We thank the Software Industry Center at Carnegie Mellon University for providing financial support for this project. We gratefully acknowledge the research assistance of Uma Mutharason and Jeff Roberts at Carnegie Mellon University for their assistance with the data coding described in this paper. Biographies of Authors Sandra Slaughter is an Associate Professor in the David A. Tepper School of Business at Carnegie Mellon University. Her research focuses on productivity and quality improvement in the development and maintenance of information systems and on effective management of information technology professionals. She has published articles in leading research journals including Information Systems Research, Management Science, MIS Quarterly, Communications of the ACM, and IEEE Transactions on Software Engineering. She serves as a senior editor for Information Systems Research and Production and Operations Management and serves or has served on the editorial boards of MIS Quarterly, Management Science, Organization Science, Journal of the Association for Information Systems, and the Journal of Database Management. She is a member of the ACM, and is active in ICIS, ICSE, WISE, and the Academy of Management. Linda Levine is a senior member of the technical staff at the Software Engineering Institute. She researches the diffusion of software technologies and change management, knowledge integration and transfer, acquisition of software intensive systems, agile software development and reasoning and communication. Her work has appeared in a wide range of journals such as IEEE Computer, IEEE Software, Information Systems Journal, Michigan Telecommunications and Technology Law Review, Scandinavian Journal of Information Systems, and University of San Francisco Law Review. Levine holds a Ph.D. from Carnegie Mellon University. She is a member of the IEEE Computer Society, Association for Information Systems, National Communication Association, and cofounder and vice chair of IFIP Working Group 8.6 on Diffusion, Transfer and Implementation of Information Technology. Balasubramaniam Ramesh is Professor of Computer Information Systems at Georgia State University. His research work has appeared in several leading conferences and journals including the IEEE Transactions on Software Engineering, JAIS, Annals of Software Engineering, Communications of the ACM, IEEE Computer, IEEE Software, IEEE Internet Computing, IEEE Intelligent Systems, Decision Support Systems. His research interests include supporting complex organizational processes such as requirements management and traceability with decision support systems, knowledge management, data mining and e-services. His work has been funded by several grants from leading government and private industry sources such as the NSF, DARPA, ONR, ARL and Accenture. Jan Pries-Heje is an Associate Professor at The IT University of Copenhagen. His research specializes in organizational and managerial aspects of IT development, such as software process improvement, software engineering, and – most recently – development of internet and Web applications. He has published in these areas in journals like Annals of Software Engineering, Journal of Accounting Management and Information Technology, The Data Base for Advances in Information Systems and the European Journal of Information Systems. He is the Danish national representative to IFIP Technical Committee 8 (TC 8) on Information Systems, and Secretary for TC 8 since 1999. Finally he is a member of the ACM, IEEE and the Danish Computer Society. Richard L. Baskerville is Professor of Information Systems and chairman in the Department of Computer Information Systems, College of Business Administration, Georgia State University. His research specializes in security of information systems, methods of information systems design and development, and the interaction of information systems and organizations. His interests in methods extend to qualitative research methods. Baskerville is the author of many articles in scholarly journals, practitioner magazines, and edited books. His editorial service includes the editorial boards of The Information Systems Journal, MIS Quarterly, and The European Journal of Information Systems. ii
  • 3. 1 Aligning Software Processes with Strategy 2 3 Abstract 4 5 Although increasing evidence suggests that superior performance requires alignment between 6 firms’ strategies and production processes, it is not known if such alignment is relevant for 7 software development processes. This study breaks new ground by examining how firms align 8 their software processes, products, and strategies in Internet application development. Drawing 9 upon the literatures in strategy, operations management, and information systems, we identify 10 four dimensions that influence alignment – the business unit strategy, the level of product 11 customization, the level of process customization, and the volume of customers. To examine how 12 these dimensions are synchronized, we conducted detailed case studies of Internet application 13 development in nine varied firms including both start-ups and established “brick and mortar” 14 companies. Our analyses reveal that the firms in our study do use differing processes for Internet 15 application development, and that many of the firms match their software process choices to 16 product characteristics, customer volume, and business unit strategies. We develop concept maps 17 for the firms that are in alignment to illustrate how managers configure specific product and 18 process dimensions. We also offer potential explanations for why some firms are misaligned 19 such as: attempting to execute incompatible strategies, the lack of coordination between 20 marketing and production strategies, the too rapid expansion of process scope, and inflexible 21 barriers to rapid adaptation of process. Our study contributes detailed insights into how software 22 processes are customized to complement different types of product requirements and strategies. 23 24 Key Words: Software Process; Product-Process Matrix, Internet Application Development; 25 Software Development Strategy; Competitive Strategy; Contingency Theory. 26 27 ISRL Categories: FAUF, FBUF, FCUF, DA09.
  • 4. 1 Aligning Software Processes with Strategy 2 3 INTRODUCTION 4 5 In operations management, there is general agreement that sustainable world-class 6 performance requires internal consistency between firms’ strategies and their manufacturing 7 operations (Krajewski and Ritzman 2005). Consistency means that the selection of strategies 8 such as cost leadership or differentiation influences decisions on product priorities (such as cost, 9 time, and quality), and that these priorities in turn guide decisions on production processes (Hill 10 2001). In information systems (IS), there is a notion that a firm’s information technology (IT) 11 strategy should be aligned with its other strategies. For example, value chain analysis (Porter and 12 Millar 1985) aligns information systems to a firm’s primary and secondary activities. More 13 recently, Grover and Malhotra (1999) link IS to manufacturing operations; Weill and Broadbent 14 (1998) show how firms align their IT infrastructure decisions with their strategies; Sabherwal 15 and Chan (2001) examine how the alignment between business and IT strategy impacts firm 16 performance; and Sabherwal et al. (2003) model the alignment between the strategy and 17 structure of the firm and its IT function. While these and other studies have described various 18 components of alignment between firm strategies and IS, the focus of this literature has been 19 more macro, i.e., strategies are aligned to information systems, structure of the IT organization, 20 overall IT strategy, or to IT architecture. To the best of our knowledge, there are few studies that 21 have examined how software development processes are aligned with different strategies. 22 By software development processes, we refer to the activities, methods, practices, and 23 transformations that are used to develop and maintain software (Paulk, et al. 1993, p. 20). 24 Decisions on software development processes include choices relating to team organization and 25 staffing, methodologies, techniques, tools, and architecture. Using one standard approach to 26 software development can be less costly, leverage economies of scale, and simplify project 1
  • 5. 1 management, knowledge transfer, and performance measurement. However, given the many 2 approaches to software development, it may not always be effective for firms to standardize on 3 one approach for all projects. Indeed, researchers and software development specialists have 4 suggested the potential performance benefits of process customization (Deck 2001). For 5 example, a study of software firms by Nidumolu and Knotts (1998) reveals that the 6 customizability of software development processes can significantly influence competitive 7 performance. Process customization or tailoring involves adapting, particularizing or selecting 8 certain (often standard or “best practice”) software processes to fit the needs of specific 9 organizations or projects. Examples include Motorola, where software development methods are 10 tailored at the industry, organization and project levels (Fitzgerald, et al. 2003) and IBM, where 11 work product descriptions are used to configure a software process to a particular project and 12 make decisions about process sequencing and phasing (Cameron 2002). However, despite the 13 potential benefits of process tailoring, there has been little research that provides insights into 14 how such customizing occurs, in terms of aligning software processes with business strategies. 15 The objective of our study is to fill some of this void by examining whether and how 16 software development processes are fit to strategies. Three levels of strategy can be distinguished 17 in a firm: corporate, business unit, and functional (Kotha and Orne 1989; Wheelwright 1984). 18 We identify firms’ business unit strategies as an important basis for selecting software processes. 19 This basis is consistent with the idea in operations management that strategic and production 20 decisions are interrelated. At the corporate level, managers define the businesses in which the 21 firm operates and allocate resources to those businesses. At the business unit level, managers 22 specify the scope and strategy of each business unit and define how the business unit strategy 23 relates to the corporate strategy. Specifying the business unit strategy requires choosing the 24 product-, market- and service sub-segments to be addressed by the unit. Thus, it is at the business 2
  • 6. 1 unit that the basis of competitive advantage (cost leadership or product differentiation) is defined 2 (Kotha and Orne 1989, Wheelwright 1984). These choices give the business unit a broader or 3 narrower product line than its principal competitors. Having made those choices, managers must 4 then decide at the functional level whether to produce the product or service with a process that 5 permits a high degree of flexibility but is labor-intensive and usually has relatively higher costs 6 or a process that is more standard and automated with relatively lower costs. A key argument is 7 that process choices must be consistent with business unit strategies for the firm to be productive 8 and effective (Brown and Blackmon 2005; Kotha and Orne 1989; Wheelwright 1984). 9 Strategy, product and process alignment is salient in Internet application development. An 10 Internet application is software that allows its users to execute business logic using a universal, 11 client-server browser architecture (Conallen 2000). Business to consumer Internet applications, 12 such as web-based retailing systems, directly interface with customers and constitute (or directly 13 support) the product or service “bundle” offered to them. Because these Internet applications and 14 their associated services are revenue-generating and must directly satisfy customers’ 15 requirements (Porra 2000), the software and development processes may reflect the nuances of a 16 firm’s business unit strategy. For example, the principal architect of salesforce.com describes 17 how competitive advantage for online businesses relates to Internet application development 18 choices such as resource sharing, multi-tier clustering, and application customization (Jacobs 19 2005). Resource sharing facilitates economies of scale and pay-as-you-go pricing; multi-tier 20 clustering allows an online service provider to more easily scale up and grow the business; and 21 application customization can differentiate the provider from other providers. Other examples are 22 provided by Heim and Sinha (2002) who describe how the web-based retailer Baltimore Coffee 23 and Tea (www.baltcoffee.com) supports a “Service Mart” or “assemble to order” strategy by 24 programming dynamic scripts in an Internet shopping cart system to sell more than 1,000 3
  • 7. 1 varieties of coffee and tea. This is contrasted with a “Service Kiosk” or “make to stock” strategy 2 implemented using static HTML technologies to provide identical experiences to all customers. 3 Thus, we address the following question in this study: are software processes aligned with 4 firms’ business unit strategies in Internet application development, and if so, how? Answering 5 this question increases understanding of how firms develop Internet applications to address 6 specific requirements by relying on different types of software development practices. If the 7 alignment of firms’ business unit, product and process strategies leads to sustained high 8 performance, it is important to understand whether and how this alignment occurs, particularly in 9 the expanding world of Internet application development. We next draw upon the literatures in 10 strategy, operations management, and information systems to identify the dimensions that 11 influence process, product and business unit strategy alignment. 12 THEORETICAL BACKGROUND 13 Strategy and Strategic Positioning 14 There are several schools of thought with respect to strategy (Minzberg, et al. 1998; Eden 15 and Ackermann 1998). Among the various strategy schools, the Positioning school is most 16 consistent with our objective of understanding how firms align their Internet application 17 development processes with their business unit strategies.1 Among the positioning approaches to 18 strategy development, we draw on Porter’s competitive forces model (1980). Other prominent 19 models in this school including the Miles and Snow typologies (1978) or theories that emphasize 20 firms’ capabilities such as the resource-based view (Wade and Hulland 2004), dynamic 21 capabilities approach (Teece, et al. 1997) or core competency theory (Prahalad and Hamel 1990) 22 are less suited to our objectives as none has clear implications for how particular strategies can 1 The Positioning school considers strategy formation as a rational, top-down process where managers position a firm to respond to or take advantage of conditions in the firm’s external environment. It is prescriptive, and considers managers as rational actors making decisions to optimize firms’ outcomes. This is consistent with the view in this paper that managers analyze the environment and make rational decisions to enhance outcomes. Other strategy schools may be more descriptive, and consider strategy as more emergent or negotiable. 4
  • 8. 1 be matched with particular processes. In contrast, in Porter’s view of strategy, operational 2 activities are the basic units of competitive advantage. According to Porter (1996), strategy 3 involves the creation of a unique and valuable position for a firm, using a distinctive mix of 4 activities: “… the essence of strategy is in the activities – choosing to perform activities 5 differently or to perform different activities than rivals” (p. 64). However, operational 6 effectiveness alone, claims Porter, is insufficient for long-term competitive success. This is 7 especially true in the world of the Internet: “Because the Internet tends to weaken industry 8 profitability without providing proprietary operational advantages, it is more important than ever 9 for companies to distinguish themselves through strategy” (Porter 2001, p. 63).2 Thus, the 10 importance of strategic positioning in creating sustainable competitive advantage is highlighted. 11 According to Porter, strategic positioning can emerge from one of two generic strategies: cost 12 leadership or differentiation (Porter 1980). These strategies are implemented at the business unit 13 level (Kotha and Orne 1989; Wheelwright 1984). The strategies are “generic” because they are 14 neither firm nor industry dependent. A business unit’s strategy can be applied either market-wide 15 or in a focused market segment (Porter 1980; Ward and Griffeths 1996). A cost leadership 16 strategy is followed when the business unit produces standard products or services that are 17 offered to many customers without significant tailoring to particular customer needs. A business 18 unit pursuing this strategy achieves cost leadership when it can produce its products or services 19 at the lowest cost. In contrast, a differentiation strategy is followed when a business unit strives 20 to serve most or all of the idiosyncratic needs of particular customers, often at a premium price. 21 Further, Porter (1996) argues that to sustain the competitive advantage achieved through 22 strategic positioning, firms must create an “alignment” between their operational activities and 23 strategies. Alignment means that firms choose activities and structures that complement their 2 Some disagree with Porter’s premise about the strategic implications of the Internet (e.g., Tapscott 2001; Tapscott, et al. 2000). 5
  • 9. 1 strategies (Farjoun 2002). Alignment is important because individual activities in firms can often 2 affect each other in ways that either strengthen or diminish their joint effects. When activities 3 mutually reinforce each other and are consistent with the firm’s strategies, competitors cannot 4 easily imitate them. Although not always in agreement with Porter, other strategists have 5 emphasized the importance of complementarities between firms’ activities and strategies. For 6 example, Venkatraman (2000) notes that effective strategizing requires firms competing on the 7 Internet to consider issues of operations, resources, and infrastructure together as interrelated 8 decisions, rather than in isolation. This highlights the importance of aligning firms’ operational 9 activities and strategies. However, the strategy literature does not provide much specific 10 guidance on how to tailor operational processes to align with particular strategies. 11 Aligning Manufacturing Processes with Strategy 12 The product-process matrix developed by Hayes and Wheelwright (1979a, 1984) is a central 13 framework in operations management that links competitive priorities to manufacturing product 14 and process choices (Table 1). As shown in Table 1, the product-process choices in the matrix 15 are aligned with Porter’s generic strategies of cost leadership and differentiation. This alignment 16 is done at the business unit level (Kotha and Orne 1989; Wheelwright 1984). From the 17 perspective of operations, the relevant strategy concerns the products to be manufactured (or the 18 services to be delivered) by the business unit. The business unit strategy determines the 19 important product characteristics that are, in turn, aligned with process choices (Kotha and Orne 20 1989). A differentiation strategy is consistent with high product variety, low volume and an 21 informal “job shop” process for manufacturing. A job shop process involves the production of 22 unique or custom-made products, each of which requires a different set or sequence of processes. 23 Scheduling is uncertain, with frequent adjustments to facilitate quick response to changes in 24 customer and market tastes. The process is flexible in terms of products produced, flow paths 6
  • 10. 1 followed, and resources used. There is a high dependence on skilled labor. When products have 2 more common or standard elements, and there is more volume, a “batch” process can be used. 3 The batch process resembles the job shop, but is more structured with more emphasis on quality 4 control. At the other end of the continuum, homogenous products with large volumes are 5 consistent with a cost leadership strategy and can be manufactured using “assembly line” or 6 “continuous flow” processes. The assembly line involves the assembly of standard components 7 in a sequential process. The process is less flexible than the job shop or batch processes and uses 8 standard procedures, tools, and systems. There is less dependence on highly skilled labor. The 9 continuous flow process also uses standard procedures, tools, and systems, and is highly 10 automated and capital intensive. It is the most inflexible process. 11 Table 1 12 Product and Process Choices, Competitive Priorities, and Competitive Strategy Product Choices: Low-Volume, Multiple Products, Few Major Products, High-Volume, Low Standardization, Low Volume Higher Volume High Standardization, Process Choices: One of a Kind Commodity Job Shop X Batch Flow X Assembly Line X Continuous Flow X Competitive Priorities: Custom Design Custom Design Dependability Dependability Fast Reaction Fast Reaction Efficiency Efficiency Flexibility Flexibility Standardized Design Standardized Inputs Quality Control Volume Production Economies of Scale Competitive Strategy: Differentiation Cost Leadership 13 Adapted from Hayes and Wheelwright, 1984, p. 216. Optimal alignment of process choices to competitive 14 X strategy and product choices is along the left-to-right diagonal in the matrix, indicated by “X’s”. 15 16 A fundamental premise of the product-process framework is that, for optimal performance, a 17 process must trade off product customization, volume, and production efficiency. That is, a firm 18 X should lie along the left-to-right diagonal of the matrix (see the “X’s” in Table 1). This premise 19 derives from the theory of production economics, and specifically, the concepts of economies of 20 scale (Varian 2002) and economies of scope (Panzar and Willig 1977; 1981). Scale economies 21 relate the efficiency (cost) of production to the volume of the product produced; economies of 7
  • 11. 1 scale exist when productivity increases with increasing production volume, and diseconomies 2 exist when the volume of production is larger than the most efficient scale size. Economies of 3 scope exist when, even though a firm is producing different products, there are common inputs 4 and processes that can be shared across the products. Diseconomies of scope exist when inputs 5 and processes differ for the products produced. In the product-process framework, the 6 implication is that increasing product variety leads to many production complications and 7 confusions such as more diverse process flows, more complex scheduling requirements, a greater 8 need for planning and control, and wider skill requirements, all of which reduce production 9 efficiency. Customized or tailored processes are seen as facilitating the production of highly 10 customized products when volume is low, but are not as efficient as standard processes that 11 produce a standard product when volume is high. 12 Based on economies of scale and scope in production, a differentiation strategy is aligned 13 with a high level of product and process customization and a low volume of production; in 14 contrast, a cost leadership strategy aligns with high levels of product and process standardization 15 and a high volume of production (Kotha and Orne 1989). It is important to note that in the 16 product-process matrix, product and process choices are not viewed as binary. Rather, these 17 alternatives are viewed along a continuum, allowing for intermediate levels of product and 18 process customization and volume. 19 Although created over two decades ago, the matrix is still influential today. The framework 20 has been empirically validated in manufacturing industries (Safizadeh, et al. 1996). It has also 21 been applied to process industries, service industries and product development activities, 22 including banking services (Huete and Roth 1988), engineering and consulting (Aranda 2002), 23 and electronic business-to-consumer service operations (Heim and Sinha 2001). In IS, the matrix 24 has been used to understand how different IS applications support manufacturing operations 8
  • 12. 1 (Kathuria, et al. 1999). Recently, researchers have proposed updates to the matrix (Ahmad and 2 Schroeder 2002) to accommodate the capabilities for mass customization offered by innovations 3 in technology, product design, and managerial practices that allow firms to operate in cells of the 4 matrix previously deemed non-optimal. 5 Product-Process Alignment in Internet Application Development 6 Although the product-process matrix provides insights in manufacturing, can it be used to 7 understand software development? Clearly, the process type metaphors (“job shop,” “batch,” 8 “assembly line,” and “continuous flow”) are more relevant to manufacturing than software 9 development. Also, the “product” is not a physical good (an automobile or computer chip), but 10 rather is an Internet application and the associated services that are bundled with it and sold 11 directly to customers. However, if the economic concepts and theories underlying the framework 12 are relevant for software development, the matrix may shed light on how Internet application 13 development processes are aligned with business unit strategies. 14 In contrast to manufacturing, software development is an intellectual activity that is perhaps 15 more akin to research and development than to the production of physical goods. Software 16 development does not require significant investments in plants and machinery, nor does it require 17 raw materials and supplies. Most costs are for labor; the initial costs of development are 18 substantial, but over the software life cycle, the costs to support the application dominate 19 (Banker, et al. 1998). Indeed, in a strict sense, the costs of production in software development 20 are negligible because the primary costs incurred are those required to develop the first “copy” of 21 the software, and the costs to replicate this copy are essentially zero (Shapiro and Varian 1998). 22 Thus, the “volume of production” is not as relevant, per se, to software development. 23 Nevertheless, there are still important parallels between manufacturing and software 24 development in terms of the economics of the processes. In fact, there is a line of research in IS 9
  • 13. 1 that models software development as an economic production process (Kriebel and Raviv 1980; 2 Banker et al. 1991; Banker et al. 1998). From this perspective, inputs including labor (the 3 developers) and capital (tools and techniques) are used to create outputs such as software code. 4 Although the “production process” in software development is knowledge work, it can be 5 relatively structured and repetitive (Kemerer 1992). For example, computer-aided software 6 engineering tools, programming languages, and development methodologies can be used in a 7 repetitive way across projects. Sufficient repetition allows software developers to learn from 8 experience (Sacks 1994). Thus, scale economies can occur within a large software project or 9 across a set of related projects because developers can learn and become more efficient as one or 10 more tasks are repeated. Economies can also occur because investments in overhead activities 11 that facilitate project performance such as project management, configuration management, 12 testing, and quality control can be spread over a larger base (Slaughter et al. 1998). For example, 13 the costs to set up sophisticated testing environments and databases can be recovered in a 14 sufficiently large project or set of projects. 15 There can also be diseconomies of scale in software development. As project size increases, 16 certain aspects increase such as the complexity of interface requirements, the difficulty of testing 17 and validating requirements, and the number of communication paths between developers. As a 18 result, productivity eventually decreases with project size (Brooks 1995). Although the volume 19 of production (number of copies produced) is not as relevant to software development 20 economics, the volume of customers or users is. More customers increase the likelihood that the 21 application will be used in different contexts and that different requirements will emerge. If 22 sufficient numbers of customers have different requirements, the firm may have to either create 23 different versions of the application for different customers or develop one complicated, feature- 24 rich application (“bloatware”) where any one customer uses only a small subset of the features. 10
  • 14. 1 The costs of coding, testing and validating such customized applications can be substantial. Even 2 if customers have similar needs, applications that will be used by a large number of customers 3 may require specialized coding and testing processes to ensure that the software will work 4 appropriately in a high-use situation. This is particularly true in an Internet environment where 5 thousands or even millions of users may use an application on any day (Jacobs 2005). 6 This discussion suggests that software development costs do relate to the degree of 7 customization of the application and of the development process as well as to aspects of volume 8 such as the number of customers. Thus, there may be sufficient similarities between software 9 development and manufacturing in terms of their underlying economics that would make it 10 advantageous to use the product-process matrix (at least ex ante) as a frame for our study and as 11 a lens to examine our research question: how are products and processes aligned with business 12 unit strategies in software development? That is, do business units with a differentiation strategy 13 develop customized Internet applications, each for a small number of customers and therefore 14 also use tailored development processes? Do other business units with a cost leadership strategy 15 develop standardized Internet applications, each for a large number of customers and therefore 16 also use standard development processes? 17 METHODOLOGY 18 To examine these questions, we conducted detailed case studies of the strategies, products, 19 and Internet application development processes in the business units of nine varied firms. Case 20 studies are ideal for research such as ours, that investigates “how” or “why” questions with a 21 focus on contemporary issues like Internet application development processes. Case studies are 22 also well suited for studying real-life events over which the researcher has little or no control, 23 like organizational strategic directions (Yin 1994). Case studies can be used in critical, 24 interpretive or positivist frameworks, although the positivist framework is the most common 11
  • 15. 1 (Dubé and Paré 2003). As positivist sociological research methods, case studies have been 2 characterized as natural experiments (Lee 1989a) in which researchers explore the relationships 3 between events and constructs post hoc. Like many other such positivist case studies, we do not 4 invoke the scientific language of hypothesis testing, but we do make controlled observations, 5 leverage multiple data sources, employ deductive logic, and use cross-case comparisons and 6 multiple analysis methods to promote replicability and confidence in the validity of our findings 7 (Lee 1989a, 1989b). In line with the recommendations for improving positivist case studies in IS 8 (Dubé and Paré 2003), we provide details about the rigor in our data collection and analysis 9 procedures. In the next sections, we describe our research sites, data collection and coding. 10 Research Sites 11 The firms in our study range in size from 20 employees to more than 100,000 employees and 12 are in different industries such as financial services, insurance, business services, courier 13 services, transportation, media and telecommunications. All firms have significant Internet 14 application development efforts: some are start-ups while others are “brick and mortar” firms 15 with separate Internet application development units. In each firm, the Internet applications 16 developed directly interface with customers and are part of the product or service “bundle” 17 offered to them. From the perspective of research design, our focus on one type of task (Internet 18 application development) is important because it reduces error variance in the results. While all 19 firms conduct Internet application development, their industries, products, and customers are 20 different. This variation is also a crucial aspect of our research design: since our objective is to 21 discern varied patterns of alignment of product and process strategies in Internet application 22 development, we need to consider a broad range of potential strategies. Table 2 provides a brief 23 description of each firm in the study. To protect the anonymity of the firms, we assigned 12
  • 16. 1 pseudonyms that reflect each firm’s primary Internet applications (products/services): Predict, 2 Utility, Incubate, Index, HR, Travel, Insure, Deliver, and Telecom. 3 Table 2: Description of Firms in Study Firm Pseudonym, Industry, When Number Capsule Case Description Products & Founded, Interviewed, Services Size Roles Predict: Creates weather derivatives based on customer demand. Energy and Mid-1990s. Three: VP Utility companies who are interested in learning about their Communication. 20 Operations, Project customers’ consumption habits purchase the weather derivatives. Offers B2B software- employees. Manager, Software Because the firm is able to create a unique and specialized based forecasting Developer product, it is able to dominate a niche in the energy industry. tools. Utility: Three entrepreneurs founded in late 1990s. The firm’s Utilities. Offers low Late 1990s. Six: CEO, VP business model recognizes the benefits of purchasing utility prices via Internet 35 Technology, services in large quantities and passing along the lower prices to buying pools for employees. Marketing Research customers. The firm offers an online buying pool for customers to customers buying Director, CIO, buy services like electricity, phone, and water at a discount. utility services. Developers Incubate: Founded in late 1990’s. Creates electronic commerce Across Industries. Late 1990s. Four: Director, Chief sites for brick-and-mortar companies. The firm also develops how Helps Brick & Mortar 55 Financial Officer, the client’s brand name and brand image will be personified on the companies develop employees. Chief Operations web. This differentiated strategy allows the firm to set itself apart customized web Officer, Developer from the countless number of web development companies. sites and presence. Index: Founded in mid-1990s by two entrepreneurs. Has grown to Film and Television. Mid 1990s. Four: Project over 80 employees. Provides its clients with the technology for Offers software 80 Manager, marketing searching and indexing videos via the Internet. Because it offers indexing and employees. specialist, senior web such a specialized product, the customer base is extremely searching tools on developer, Q/A limited. However, trying to expand market offerings. the Internet. specialist HR: Offers services for managing and communicating human Administrative Mid 1990s. Seven: Project resources, employee benefits and payroll information. The Services. Provides >100 Manager, Architect, systems it creates reduce the administrative costs of its clients. To HR applications and employees. User Interface differentiate from the other human resource solution providers, the services via the Design, Web firm has focused its efforts solely on small to medium sized firms. Internet. Developers Travel: Established in early 1990s by affiliates of a major Transportation and Early 1990s. Six: Senior Manager, transportation company. Provides all travel arrangements for its Tourism. Offers >1,000 Project Manager, clients, mid-sized corporations. Because the firm focuses on travel applications employees Q/A Manager, Lead corporate travel, it can better understand the needs of its clients and services to firms Developers, Web and can build lasting relationships with them. via the Internet. Developers Insure: One of the top insurance companies in the United States. Insurance. Offers Before 1950. Three: Human Offers various types of insurance such as automobile, motorcycle software-based >100,000 Resources Manager, watercraft, etc. Successfully launched a website in mid-1990s, insurance services employees Internet Site where customers can get quotes or buy insurance online. via Internet to Manager, Internet individuals and firms. Site Developer Deliver: One of the top express delivery providers in the United Transportation and Before 1950. Six: CIO, Senior States. With e-commerce gaining popularity, the firm plays a Logistics. Offers >100,000 Manager, Project significant role in the delivering of products to end-consumers. In software-based employees Manager, Architect, response to the increase of home-users, launched a website in logistics services on Senior Developer, mid-1990s. The website offers functionality such as the ability for the Internet. Web Developer customers to track their packages on-line. Telecom: Provides IT solutions for a large telecommunication Tele- Before 1950 Six: Senior Manager, provider. Major part of IT was outsourced 18 months prior to our communications. >50,000 Project Manager, visit. But most of the IT personnel had been transitioned to the Offers web-based employees Q/A Manager, Q/A outsourcing vendor and the unit studied was working with the telecommunications Specialist, Web same products and technology as before the outsourcing. services. Developers 13
  • 17. 1 Data Collection and Coding 2 Our unit of analysis is the business unit that develops and markets the firm’s Internet 3 applications.3 We conducted semi-structured interviews with managerial and technical personnel 4 at each firm to elicit details relating to the business unit strategy and the major dimensions of the 5 product-process matrix. Key informants included senior managers, product managers, project 6 managers, Internet application developers and quality assurance specialists. The informants were 7 carefully selected to provide the best source of information; thus, we directed questions 8 concerning strategy, products, and customers (i.e., “what Internet applications/services are 9 produced”) to senior managers, and questions about Internet application development processes 10 (i.e., “describe the tools you use to develop Internet applications”) to project managers, 11 developers and quality assurance specialists. We also included questions on organizational and 12 interviewee demographics to obtain a more complete understanding of the firms and individuals 13 interviewed.4 In all, as shown in Table 2, we interviewed 45 individuals in the business units of 14 the nine firms. 15 Interviews with each informant were typically two hours in length, and site visits usually 16 lasted at least four hours. The interviews were conducted by two or three researchers on the 17 team; one researcher concentrated on interviewing, while the other(s) took short hand notes using 18 laptop computers. Immediately after an interview, the notes were written out in full text, and 19 transcripts were integrated and reviewed by all of the researchers conducting the interview. 20 Having multiple investigators is an advantage in a case study because their different perspectives 21 and insights add objectivity and enhance the potential for creative and novel contributions 22 (Eisenhardt 1989). The transcripts from the interviews yielded more than 100 pages of single- 3 Some firms have a separate business unit that develops Internet applications, and that unit was the focus of our study. Other firms have only one business unit, and Internet application development is conducted in that unit. Telecom’s Internet application development was managed as a separate business unit by the outsourcing vendor because it was a major client. 4 The complete interview protocol is in the appendix for this paper located at: {{{JAN DEGROSS}}}. 14
  • 18. 1 spaced text. The interview data were complemented with secondary data about each firm’s 2 business unit strategies and other characteristics (revenues, employees, and company history) 3 that were obtained from the firms’ web sites and from publicly available information such as 4 annual financial reports or press releases. Using multiple sources of evidence is a key tactic to 5 increase construct validity in case studies and helps mitigate the potential for bias (Yin 1994). 6 For example, a manager’s description of the firm’s business unit strategy could be compared 7 with the description of the strategy on the firm’s website. 8 To guide our operationalization and coding of the four theoretical constructs determining 9 alignment (business unit strategy, the level of product customization, the level of process 10 customization, and the volume of customers) we referenced the literature on the product-process 11 framework (Safizadeh, et al. 1996; Ahmad and Schroeder 2002; Aranda 2002) and on business 12 strategy (Ward and Griffiths 1996; Porter 2001, 1980) to develop rules and procedures for 13 coding each construct.5 We identified the business unit strategy by applying the coding rules to 14 the interview statements from senior managers and publicly available information about the firm. 15 A cost leadership strategy was coded for business units that endeavored to beat competitors by 16 producing goods or services at the lowest cost, and a differentiation strategy was coded for 17 business units that sought to achieve competitive advantage by creating a product or service that 18 is unique and usually offered at a premium price (Ward and Griffiths 1996; Porter 1980). An 19 independent coder rated each firm’s business unit strategy based upon what the business unit was 20 actually doing, i.e., the unit’s strategy-in-use. In our coding, we were aware of the potential for 21 differences in the stated versus actual business unit strategies, and therefore considered multiple 22 kinds of information (interview transcripts from multiple informants, annual reports, web sites, 23 press releases, etc.) to help identify and corroborate the actual strategies-in-use executed by the 5 Coding details and examples of coded data for each of the theoretical constructs are in the appendix for this paper located at: {{{JAN DEGROSS}}} 15
  • 19. 1 firms’ business units for their Internet-based products. The coder also evaluated information 2 about each business unit’s major competitors, and coded the competitors’ strategies to determine 3 whether the unit’s positioning vis á vis its competitors agreed with the coded strategy. For 4 example, Predict is coded as a differentiator: its business unit provides unique services to each 5 customer and charges a premium price for these services. Utility is coded as a cost leader: its 6 business unit offers customers the lowest prices for commodity products and services by forming 7 online buying pools. As a final check of the coding, the first author also coded each firm’s 8 business unit strategy and compared the coding with that of the independent coder. There were 9 no disagreements between coders in the coding of firms’ business unit strategies. 10 The interview transcripts were the primary basis for the coding of the level of product 11 customization and the level of process customization. We developed the coding rules for each of 12 these constructs from the product-process literature (Safizadeh, et al. 1996; Ahmad and 13 Schroeder 2002; Aranda 2002) and adapted them to suit an Internet application development 14 context. For example, Predict’s “product” is a bundle of an Internet-based application and 15 services: the firm offers software tools, analyses of historical data, and advice to help utility 16 companies forecast the future energy demand of their customers. An independent coder and the 17 first author of this paper read statements in the transcripts relating to product customization and 18 process customization and coded the levels of each of these constructs. The level of product 19 customization refers to the extent to which a firm’s business unit customizes its Internet 20 application/service bundle by creating unique features to meet the needs of each customer. A 21 high level of product customization was coded when the business unit offered a unique Internet 22 application/service bundle to each customer, and a low level of product customization was coded 23 when the business unit offered a standard Internet application/service bundle to many customers. 24 The level of process customization refers to the extent to which a firm’s business unit tailors its 16
  • 20. 1 Internet application development process for each customer. A high level of process 2 customization was coded when the business unit tailored or adapted the development process for 3 each application or customer while a low level of process customization was coded when the 4 business unit used a standard development process. For example, for Predict, the level of product 5 customization is high because a different application is created for each utility company served. 6 The level of process customization is also high for Predict, because the development process is 7 adapted for each utility company to accommodate the nuances of each utility’s historical data 8 and legacy systems. Although the coders initially disagreed on the coding of two of eighteen 9 items, after discussion and reference to the transcripts, the coders mutually agreed upon all of the 10 final coding assignments for these constructs for each firm’s business unit. 11 Finally, the volume of customers refers to the number of customers who have purchased the 12 Internet application/service bundle. We obtained actual figures about the number of customers 13 for the Internet applications from interviews and company documentation.6 14 ANALYSIS AND RESULTS 15 We used a mixed methods data analysis approach (Tashakkori and Teddlie 1998) in which 16 we first qualitatively analyzed the coded data to visually discern patterns of product-process 17 alignment and to group business units with similar patterns together. We then quantitized the 18 coded data and performed a cluster analysis and a discriminant analysis to confirm and further 19 analyze the patterns and groups identified by the qualitative analysis. This mixed methods 20 approach offers several advantages. As Tashakkori and Teddlie (1998) have argued, the use of 21 multiple methods helps to triangulate and confirm the findings, providing more confidence in the 22 conclusions reached. In addition, using both qualitative and quantitative methods affords the 23 opportunity to leverage the benefits of each method and can enrich the insights obtained. 6 The figures on customer volume are in the appendix for this paper located at: {{{JAN DEGROSS}}} 17
  • 21. 1 Following the approach for cross-case qualitative analysis recommended by Miles and 2 Huberman (1984) and Yin (1994), we used pattern matching to identify similar types of 3 alignments of strategy-, customer-, product- and process dimensions across the firms’ business 4 units. The analysis involved the use of four different spreadsheets (one for each theoretical 5 construct) in which the coded data for each business unit were placed in one or more cells of the 6 unit’s particular column in the spreadsheet. We then sorted the columns of each spreadsheet so 7 that the firms’ business units were ordered from left to right by business unit strategy 8 (differentiator to cost leader), level of product customization (high to low), level of process 9 customization (high to low), and volume of customers (small to large). This enabled us to 10 visually identify patterns of alignment across constructs, to compare patterns across units, and to 11 group units with similar patterns together. For example, we observed that the business units of 12 Predict and Incubate both followed differentiator strategies and used development processes that 13 were highly customized while those of Utility and Insure both followed cost leader strategies and 14 used more standard development processes. The cross-case analysis suggested three different 15 groups of alignment patterns. One group included business units that were cost leaders with more 16 standardized products and processes; another group included business units that were 17 differentiators with more customized products and processes; and the third group included 18 business units with intermediate levels of product and process customization. 19 Our quantitative analysis leveraged cluster analysis and discriminant analysis (McLachlan 20 2004).7 Cluster analysis was used to identify groups of similar business units and to corroborate 21 the groups identified from the qualitative analysis, and discriminant analysis was used to provide 22 further corroboration of the groups and to help understand similarities and differences across 23 units and groups. We quantitized the text-based codes for business unit strategy, level of process 7 Given the number of firms in our study, the quantitative analyses should be considered descriptive and are intended to support, complement and enhance the qualitative analyses. 18
  • 22. 1 customization, and level of product customization for each firm, transformed customer volume 2 using the natural logarithm, and input the transformed values into the analyses.8 A hierarchical 3 cluster analysis distinguished three clusters.9 The clusters were similar to those we discovered in 4 the qualitative analysis, supporting the groups of alignment patterns identified. 5 We then used discriminant analysis (McLachlan 2004) to further analyze the data. 6 Discriminant analysis identifies the fewest functions that are needed to cluster similar 7 observations and to discriminate between dissimilar observations. A discriminant function is a 8 latent variable representing a linear combination of the independent variables (in our analysis, 9 the strategy, product, process and customer variables). We specified three clusters, ex ante, in the 10 discriminant analysis using the cluster assignment for each firm’s business unit from the 11 hierarchical cluster analysis. The discriminant analysis generated two functions that 12 discriminated between the three clusters. The first function explained 98.9% of the variation 13 between clusters, and the second function explained the remaining 1.1% of the variation between 14 clusters. The functions are both statistically significant (at p < 0.01) in discriminating between 15 clusters, and each of the individual independent variables differs significantly (all at p < 0.01) in 16 mean by cluster. It is possible to interpret each discriminant function by considering its 17 correlations with each of the four independent variables. We interpreted Discriminant Function 1 18 as representing “business unit / product strategy” as it correlates significantly with business unit 19 strategy (0.812), level of product customization (-0.812) and volume of customers (0.511). 20 Discriminant Function 2 seems to capture “process strategy” as it is correlated significantly only 21 with level of process customization (-0.953). We then used each discriminant function to 22 generate a set of discriminant scores for each firm’s business unit, graphed in Figure 1. 8 Values of “high”, “medium”, or “low” were assigned “1”, “2”, or “3”, respectively. A differentiation strategy was assigned a “1”, cost leadership a “3”, and intermediate a “2”. The volume of customers was transformed as it is not normally distributed. 9 The cluster analysis used the between groups linkage method and the squared Euclidean distance measure. The Calinski / Harabasz pseudo-F index (1974) suggested that three clusters provide the most distinct clustering. 19
  • 23. 1 Figure 1: Graph of Firms’ Discriminant Scores 3 process strategy: highly standardized 2.5 TELECOM 2 Group #2 1.5 business unit/product strategy: business unit/product strategy: highly customized/differentiator/ highly standardized/cost leader/ low volume 1 high volume Group Center HR 0.5 Group #3 Group #1 UTILITY INCUBATE TRAVEL 0 INSURE -9.0 -8.0 -7.0 -6.0 -5.0 -4.0 -3.0 -2.0 -1.0 .0 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 Group Center -0.5 Group Center PREDICT INDEX -1 DELIVER -1.5 process strategy: highly customized -2 2 In Figure 1, the “x” axis represents the scores generated by Discriminant Function 1 (the 3 business unit / product strategy). Business units farther to the right on the “x” axis have more 4 standardized products and are cost leaders in a large market. Business units farther to the left on 5 the “x” axis have more customized products and are differentiators in a small market. The “y” 6 axis represents the scores generated by Discriminant Function 2 (the process strategy). Business 7 units closer to the top of the graph use more standardized processes while business units closer to 8 the bottom use more customized processes. Figure 1 also shows three distinct groups of business 9 units where each group represents a particular alignment pattern. The group assignments were 10 checked using the discriminant functions to predict each unit’s group assignment, and then the 11 prediction was compared with the unit’s original assignment from the cluster analysis. In our 12 study, the discriminant analysis matched the group assignments for each business unit as 100% 13 of the units were correctly classified (predicted assignment = original assignment); this provides 14 further support for the groups of alignment patterns we identified in the qualitative analysis. As 20
  • 24. 1 shown in Figure 1, Predict, Incubate and Index are in Group #1. Figure 1 also suggests that 2 Predict and Incubate are more similar in their patterns of strategy-product-process alignment 3 than Index. Still, Figure 1 indicates that Index’s pattern of alignment is more like Predict’s and 4 Incubate’s than the other business units in the other groups. The other two groups can be 5 interpreted similarly, suggesting that Telecom and Deliver are most unlike the other units in their 6 respective groups. In addition, comparing group centers suggests that Groups 1 and 3 are most 7 dissimilar as their respective group average scores are the farthest apart. 8 We then drew radial graphs (Figure 2) to visualize how each firm aligned its business unit 9 strategy, level of product customization, level of process customization and customer volume.10 10 Each graph shows the numeric rating for each firm’s business unit on each of the four theoretical 11 dimensions. A business unit is in alignment when the values for all dimensions are equal, i.e., the 12 level of differentiation in business unit strategy matches the level of customization in product 13 and process, and the volume of customers. For example, Predict is in alignment as all 14 dimensions have the same value (“1”). A business unit is out of alignment when the values for all 15 dimensions are not equal. For example, Deliver is out of alignment because its level of process 16 customization (“2”) does not equal the value of the other dimensions (“3”). The radial graphs 17 also reflect the levels of differentiation in business unit strategy, product and process, and the 18 volume of customers. Values of “1” reflect a highly differentiated strategy, customized products 19 and processes, and a low volume of customers while values of “3” reflect a cost leadership 20 strategy, more standardized products and processes, and a high volume of customers; values of 21 “2” reflect intermediate levels of these dimensions. To discern whether alignment varies across 22 groups, we arranged each radial graph into its “assigned” group from the analyses. 23 10 To draw the radial graphs, we transformed customer volume such that a small number of customers (< 1,000) was assigned a “1”, medium (> 1,000 and < 100,000) a “2”, and large (> 100,000) a “3”. The groups were inductively determined from the data and confirmed by a hierarchical cluster analysis. 21
  • 25. 1 Figure 2: Strategy-Product-Process Alignment for each Business Unit by Group 2 3 4 Group #1: Highly Customized level of process level of process level of process standardization standardization standardization 3 3 3 2 2 PREDICT 2 INCUBATE INDEX 1 1 1 cost leadership level of product cost leadership level of product cost leadership 0 level of product 0 0 strategy standardization strategy standardization strategy standardization customers supported customers supported customers supported 5 6 7 8 9 Group #2: Intermediate level of process level of process level of process standardization standardization standardization 3 3 3 2 2 HR TRAVEL TELECOM 2 1 1 1 cost leadership 0 level of product cost leadership level of product cost leadership level of product 0 0 strategy standardization strategy standardization strategy standardization customers supported customers supported customers supported 10 11 12 13 14 Group #3: Highly Standardized level of process level of process standardization standardization level of process 3 3 standardization 3 2 UTILITY 2 INSURE DELIVER 2 1 1 cost leadership level of product cost leadership level of product 0 0 cost leadership level of product strategy standardization strategy standardization 1 strategy standardization customers supported customers supported customers supported 15 16 22
  • 26. 1 Comparing the radial graphs in Figure 2 by group shows that the business units in Group #1 2 are the most highly differentiated; the business units in Group #3 are the most standardized; and 3 the business units in Group #2 have intermediate levels of differentiation. This suggests that the 4 business units have distinct patterns of alignment for their business unit strategies, products and 5 processes. Figure 2 also shows that six of the nine business units in the firms in our study do 6 align their strategies as predicted. The radial graphs for Predict and Incubate in Group #1 7 suggest that they pursue differentiation strategies, have highly customized products and 8 development processes, and relatively small volumes of customers. At the other end of the 9 extreme in Group #3, Insure and Utility pursue a cost leadership strategy, and have more 10 standard products and development processes, and a larger volume of customers. The strategies 11 used by HR and Travel in Group #2 reflect intermediate levels of differentiation in business unit 12 objectives, product characteristics and Internet application development processes. The 13 respective customer volumes are larger than those of Predict and Incubate, but smaller than 14 those of Insure and Utility. Figure 2 also shows that Index, Telecom and Deliver are “out of 15 alignment” in that some aspect of their business unit strategies, products, processes or customer 16 volumes does not align as expected. We integrate and interpret these results in the Discussion. 17 DISCUSSION 18 Overall, we find that the dynamics of the product-process framework are relevant in software 19 development as software process choices are aligned with product characteristics, customer 20 volume, and business unit strategies for many of the firms. However, some units are not in 21 alignment. We first examine how units that are in alignment configure detailed dimensions of 22 their products and processes. We then consider the business units that are misaligned. 23
  • 27. 1 Business Units in Alignment 2 Consistent with the product-process framework, for the business units in alignment, a 3 customized development process is used when the volume of customers is small, and there are 4 highly differentiated needs. A more standard development process is used when there are 5 sufficient common needs that applications can be developed to serve a larger number of 6 customers. To provide a deeper understanding of how the business units align elements of their 7 products and processes, we use Concept Maps. Concept maps organize and represent concepts 8 (events or objects) and their inter-relationships in a particular domain or context (Novak 1998). 9 Relationships between concepts are associative. Concept maps were originally developed to help 10 understand how children learn. Recently, concept maps have been used to conduct qualitative 11 data analysis (Daley 2004) where the researcher draws the concept map, and uses it to visually 12 identify themes and patterns, display linkages, and facilitate cross group or site comparisons. 13 Following the approach suggested by Daley (2004) and the techniques developed by Novak 14 (1998), we developed concept maps to visually represent concepts for the business units in 15 alignment. Consistent with the literature on concept mapping, we created concept maps with the 16 broader, more inclusive concepts at the top of the hierarchy, connecting with other more detailed 17 concepts below. Given our goals of evaluating alignment between business unit, product and 18 process strategies, we deductively identified the main concept categories and their associations 19 based on the primary aspects of the product-process matrix: (1) Customer Requirements relate to 20 Product characteristics; (2) Products are developed using Process elements; (3) Development 21 Process is using People related process elements; (4) Development Process is using Practices 22 related process elements; (5) Development Process is using Architecture related process 23 elements; and (6) Process Elements relate to Outcomes. We further refined the development 24 process category using software development reference models, such as the CMM to help 24
  • 28. 1 identify people-related, practices-related and architecture-related concepts. We also referenced 2 the ISO standard for software quality (ISO 9126) to help identify outcomes concepts. Then, we 3 analyzed the interview transcripts to surface the detailed concepts within each category or sub- 4 category. For example, team role diversity and scalability emerged as concepts from the 5 interview transcripts in response to questions on people-related process choices and on 6 outcomes, respectively. Team role diversity refers to the number of different roles on an Internet 7 application development team. Scalability indicates whether the Internet application architecture 8 can be scaled for high volume usage.11 9 In the following sections, we present and discuss concept maps for two groups of business 10 units: those using a highly customized Internet application development process and those using 11 a more standard process (Groups #1 and #3 in Figure 1, respectively). We also provide examples 12 of business units that are using each of these development processes. Finally, we present and 13 discuss an overall concept map that illustrates the general concepts and associations between 14 product and process alignment in Internet application development. 15 Concept Map for the Highly Customized Development Process. Figure 3 depicts the concept 16 map for a highly customized Internet application development process that is used by business 17 units pursuing a differentiation strategy. This concept map is exemplified by Predict. Predict 18 targets a small set of utility customers who have unique and particular requirements. Each utility 19 transmits historical data on energy consumption patterns, and Predict develops a customized, 20 business-to-business Internet-based application for each utility to forecast future consumption 21 patterns. Because the data and requirements are quite different for each utility, Predict must 22 develop a different application for each utility, often using a different development process: “We 23 have about 150 utility customers. The companies each send us their energy consumption data. And, we provide 11 A brief explanation and example of each concept identified in the concept mapping analysis are documented in the appendix for this paper located at: {{[JAN DEGROSS}}} 25
  • 29. 1 them with an analysis and prediction of future energy needs. But, the data feeds in and out are unstable... we are 2 dealing with each customer’s antiquated legacy systems...If we ever had something that worked the same way twice 3 – that would be stability. We have about 150 different development processes” (Senior Manager, Predict). 4 Figure 3: Concept Map of Highly Tailored Development Process c u s to m e rs have a re h e te ro g e n e o u s re q u ire m e n ts fe w re la te to re la te s to h ig h v a rie ty o f p ro d u c t fe a tu re s a re d e v e lo p e d u s in g ta ilo re d d e v e lo p m e n t p ro c e s s is u s in g is u s in g is u s in g p e o p le p ra c tic e s a rc h ite c tu re is w o rk o n a re a re a re has a re c u s to m d e s ig n e d s m a ll te a m s g u ru s p ro to typ in g m any phases little re u s e re la te s to re la te to little c o d e re u s e re la te s to re la te to re la te s to re la te to re la te s to o u tc o m e s o u tc o m e s o u tc o m e s a re a re a re a re a re h ig h fle x ib ility a re p o o r s c a la b ility a re lo n g le a rn in g lo n g c yc le tim e lo w fo rm a lity little le g a c y a re c u rv e s in te g ra tio n lo w p e rv a s iv e n e s s little k n o w le d g e tra n s fe r 5 6 There is a reliance on gurus because to serve customers in Predict’s unique market niche 7 requires specialized knowledge of the particular utility and the utility’s data and systems as well 8 as complex skill sets including advanced statistics and financial engineering. The development 9 process also requires the use of small teams of specialists. The use of gurus makes it difficult to 10 transfer knowledge, and the learning curve for new employees is steep and long. There is almost 11 no reuse of software code; in fact Predict uses redundant coders, i.e., two developers 12 independently code each application for each customer. This is done to minimize errors and bias 26
  • 30. 1 in the consumption prediction models developed. The software code is discarded if there are 2 mistakes or problems: “We throw away and re-build for each customer. We’re very adaptive, which is stressful 3 on employees who don’t adapt” (Senior Manager, Predict). Prototyping is used to understand user 4 requirements. Custom architecture design, limited reuse of design artifacts, and little legacy 5 integration also characterize this mode of development. 6 Concept Map for the Highly Standardized Development Process. Figure 4 shows the 7 concept map for the more standardized Internet application development process that is used by 8 business units pursuing a cost leadership strategy. Utility typifies this concept map. Utility uses 9 the Internet to organize customers into large buying pools and facilitate low cost purchase of 10 services such as electricity, natural gas, home security, and health insurance. There are sufficient 11 standard features across the buying pools that the business unit can standardize its Internet 12 applications and reuse software across the different market segments: “We are always making 13 generalizations across the vertical markets even though there are different products, different markets and different 14 interfaces. The whole reuse perspective goes across the verticals…. We retrofit good features, repeating one across 15 the others… our development strategy is to standardize and reuse software across vertical markets…” (Manager, 16 Utility). The commonalities amongst its customers and products enable Utility to use a standard 17 development process, and in fact, the unit leverages the traditional, sequential waterfall approach 18 to software development, albeit at “Internet speed”: “We use the ‘staircase’ method to develop. Internet 19 speed development is very similar to traditional development – we still need to gather requirements, there’s a life 20 cycle. But, the response time is much quicker. The process is like a ‘quick waterfall’” (Project Manager, Utility). 21 Because the software features and processes are more standard and can be reused across market 22 segments, there is less need for specialized knowledge, and less reliance on gurus: “Some wear 23 multiple hats. Project leaders could be from technology, business or operations, and there isn’t always someone 24 tagged as the ‘leader’” (Project Manager, Utility). The software architecture plays a critical role in 27
  • 31. 1 standardizing and reusing applications across market segments: “We have designed a three tier 2 architecture (presentation layer, application layer, database layer). The objective is to make an open, modular and 3 scalable architecture. Because there is a vision, it allows us to create good technologies that are scalable. We can 4 easily ratchet up or down in the scale” (Manager, Utility). Short cycle times, and high scalability, 5 robustness and portability also characterize this mode of development. 6 Figure 4: Concept Map of Highly Standardized Development Process c u s to m e rs have a re hom ogeneous m any re q u ire m e n ts in c re a s e n e e d fo r r e la te to lo w v a rie ty o f re la te s to p ro d u c t fe a tu re s m a y r e q u ir e a r e d e v e lo p e d u s in g e a s y c u s to m iz a tio n s ta n d a rd d e v e lo p m e n t p ro c e s s is u s in g is u s in g is u s in g p e o p le p ra c tic e s a rc h ite c tu re has are a re have are has w a te rfa ll are m o d u la r d e s ig n a re g e n e ra lis ts fe w ro le s c o d e re u s e fe w p h a s e s h ig h re u s e r e la te s to r e la te s to r e la te to C O TS use r e la te s to re la te to re la te s to r e la te s to r e la te to o u tc o m e s o u tc o m e s o u tc o m e s are are are a re a re lo w fle x ib ility a re a re h ig h s c a la b ility ro b u s tn e s s are s h o rt le a rn in g h ig h fo rm a lity are s h o rt c y c le tim e are c u rv e s h ig h p o rta b ility h ig h p e rv a s iv e n e s s h ig h k n o w le d g e s o m e le g a c y tra n s fe r & re -u s e in te g ra tio n 7 8 Concept Map for Product-Process Alignment. We further abstracted the elements in the 9 concept maps to create a more general concept map of product and process alignment in Internet 10 application development (Figure 5). As shown in Figure 5, the level of requirements diversity 11 relates to the variety of product features, and together with the volume of demand for 12 requirements influences the type of development process selected. 28
  • 32. 1 Figure 5: Concept Map of Product-Process Alignment c u s to m e rs have have re q u ire m e n ts re q u ire m e n ts d iv e rs ity dem and re la te s to v a rie ty o f re la te s to p ro d u c t fe a tu re s a re d e v e lo p e d u s in g ty p e o f d e v e lo p m e n t p ro c e s s is u s in g is u s in g is u s in g p e o p le p ra c tic e s a rc h ite c tu re have a re has have a re has ty p e o f a re o n m e th o d o lo g y ty p e a re e x p e rtis e a re # & sequence d e s ig n ty p e e x te n t o f ro le d iv e rs ity e x te n t o f of phases re u s e c o d e re u s e te a m s iz e e x te n t o f re la te s to re la te s to re la te to re la te s to re la te s to C O T S use re la te s to re la te s to re la te s to re la te s to o u tc o m e s o u tc o m e s o u tc o m e s a re a re a re a re fle x ib ility a re a re s c a la b ility ro b u s tn e s s a re a re le n g th o f fo rm a lity a re c yc le tim e a re le a rn in g c u rv e p o rta b ility p e rv a s iv e n e s s e x te n t o f k n o w le d g e e x te n t o f le g a c y tra n s fe r & re -u s e in te g ra tio n 2 3 The process choices relate to the people, practices and architecture used in development. The 4 type of expertise on a team (specialists versus generalists) is influenced by the variety and scale 5 of use of product features. When customer requirements are more standard or can be generalized, 6 less specialized knowledge is required as developers can follow the standard design and can 7 reuse existing code. Thus, teams of generalists can be used. In contrast, when customer 8 requirements are highly differentiated, more specialized knowledge is required, and there is more 9 reliance on “gurus”. Similarly, the practices followed are also shaped by these factors. When 10 product features are standardized, software can be readily reused across products, but when 11 product features are customized, there may not be sufficient commonalities to enable code reuse. 29
  • 33. 1 Prototyping (not a standard waterfall process) may be needed to discover customers’ unique 2 needs. Finally, when customer requirements can be generalized across markets or products, a 3 modular architecture can be designed to be robust, scalable and portable. Process characteristics 4 further define associated outcomes. The extent of knowledge transfer and reuse relates to people- 5 related practices such as the use of specialists or generalists, and team role diversity and size. 6 Similarly, the length of the learning curve is associated with the same choices, e.g., the more 7 specialized the knowledge requirements and skill sets, the longer the learning curve for new 8 hires. For development process, the flexibility, formality, pervasiveness and cycle time of the 9 process are associated with the type of development methodology, the number and sequence of 10 phases, reuse of software code, and use of off-the-shelf components and tools. For example, code 11 reuse and parallel development facilitate short cycle times. Finally, the portability, scalability 12 and robustness of the architecture relate to specific practices such as use of modular architecture 13 frameworks and tools, and design reuse. 14 Business Units Out of Alignment 15 16 While many business units in our study are “in alignment”, three are “out of alignment”. To 17 determine precisely why these units are misaligned is beyond the scope of this study. 18 Nevertheless, we can draw upon the literatures motivating this study to suggest why the units 19 may be misaligned. According to Porter (1980), when a business unit tries to be both a cost 20 leader and a differentiator in the same market or when a business unit switches between these 21 strategies over time, it can become “stuck in the middle”. The basic strategies are incompatible 22 because cost leadership focuses on cost advantages of production (being the low cost producer 23 for a given level of quality) while differentiation focuses on satisfying unique customer needs 24 and de-emphasizing price (often generating a higher than average price). Since successfully 25 executing each of the basic strategies involves different resources, strengths, organizational 30
  • 34. 1 arrangements and managerial styles, it is unlikely that a business unit can realize both strategies. 2 Even if a business unit can achieve both strategies in the same market, it risks projecting a 3 confusing image to the customer and can fail to attain the benefits from either. 4 Being stuck in the middle may describe, in part, what is happening at Index. Founded by 5 computer scientists, the firm’s focus historically was on technological product innovation. In the 6 past, the firm’s business unit was a differentiator and used highly-tailored development 7 processes, customizing its products to the unique needs of a few major customers. However, 8 since Index has started offering its products on the Internet, there has been pressure to shift its 9 strategy to appeal to a broader range of customers in new markets and bring in greater revenues. 10 This shift has generated some confusion in the unit’s strategic direction: “We said we needed to be 11 present on the Internet. From then on we have changed the focus on customers, markets, and what products we are 12 selling. Lately there is more churn, changing focus of products, the market we want to be in” (Manager, Index). 13 The changes in Index’s business unit strategy are not fully reflected in its software product and 14 development process strategies. The radial graph for Index in Figure 2 shows that although the 15 business unit strategy reflects an intermediate level of differentiation as the firm tries to 16 commoditize its products, the product and development process strategy continue to reflect high 17 levels of customization: “We provide everything from turnkey solutions to custom solutions. Customers can give 18 us a crate of "X" and say, do whatever you have to with this. Or we may be asked to put together a complete 19 configuration that the customers can use with their own content. Other customers are in between. There are also 20 variations in the types of products and services...” (Manager, Index). 21 The product-process literature also suggests why business units can be misaligned. 22 According to Hayes and Wheelwright (1984, 1979b) the product-process matrix reflects the 23 alignment (or misalignment) of a firm’s competitive priorities, products and processes at a point 24 in time. Thus, a misaligned business unit may be in transition. However, Hayes and Wheelwright 31
  • 35. 1 assert that being in transition should be temporary. Business units that are misaligned are less 2 efficient and effective because marketing and production are pursuing different objectives, and 3 the unit cannot leverage economies of scale. Alignment (being “on the diagonal”) should thus be 4 the steady-state condition. So, why do business units move “on” or “off” the diagonal of the 5 matrix? Hayes and Wheelwright (1979b) offer an organizational learning explanation that relates 6 to the theories of March (1991). March developed the concept of balancing exploration and 7 exploitation as strategies for organizational learning. Exploration involves searching, 8 experimentation, developing variation, taking risks, and discovering new knowledge. 9 Exploration strategies develop variation, and the returns are usually uncertain. In contrast, 10 exploitation involves selection, refinement, production, and efficiency. Exploitation strategies 11 refine existing knowledge, and the returns are usually certain. In the product-process matrix, 12 business units that move down (but on) the diagonal are leveraging both exploration- and 13 exploitation-based learning in a balanced way within their existing markets. The units are 14 exploiting the learning curve to become more efficient in their processes, but are maintaining 15 some flexibility to respond to market changes, and are also innovating their products. 16 Business units that innovate the product more than the process (are above the diagonal) can 17 follow dynamic market movements quickly, but at the cost of reduced process efficiency. One 18 issue here is that a unit can get trapped if it tries to innovate existing products to appeal to new 19 markets. At first this strategy may work, but eventually the unit’s existing process will not be 20 able to accommodate the added scale and complexity of new products without additional 21 investment. The unit may then have to innovate the process, but to recoup the investment it has 22 to pursue additional markets, and this requires more product innovation, and starts the cycle all 23 over again. This may also describe what is happening at Index. Despite pressures for 24 commoditization, the business unit’s products have not matured into a commodity that appeals to 32
  • 36. 1 a large enough number of customers: “We tried to have one product for all segments... but when they see the 2 product, the customers came back and said, ‘this is cool but we like this other feature too’. And then we get extra 3 requirements for features. It is hard to say no to customers” (Manager, Index). Thus, the unit cannot adopt 4 a more standardized process because there are too few similarities among the features of the 5 various products. As a result, Index devotes resources to innovate the product, searching for a 6 variation that will appeal to a large enough customer volume to begin exploiting the product and 7 standardize a process to compete in a moderately differentiated marketplace. 8 A related, but somewhat different phenomenon may be driving misalignment at Deliver. 9 Deliver is a brick and mortar company with a cost leadership strategy in the business unit that is 10 implementing a web-based interface for its standard applications. In the jargon of the product- 11 process matrix, the company is expanding the scope of its process through forward integration by 12 connecting its applications directly to its customers via the Internet. One potential issue is that 13 expanding process scope can result in producing a product that is not consistent with existing 14 product lines and processes in other business units: “Our business strategy is not clearly aligned with our 15 application development strategy. For example, we may develop an application which may end up cannibalizing 16 market share from another product” (Manager, Deliver). The business unit uses a more ad-hoc process 17 than has been used in the past for software development, and this process is misaligned with the 18 business unit’s cost leadership strategy as shown in Figure 2. A particular problem for Deliver is 19 the lack of a coherent, standard and modular architecture for its Internet applications: “There is no 20 end-to-end view of the system and no time for thinking through the architecture. It’s really messy and it doesn’t scale 21 up. The architecture is changing constantly – it is very fluid and dynamic” (Architect, Deliver). Instead, 22 developers rely on wrappers (“glue code”) to link together disparate software components in an 23 ad-hoc fashion. This process contributes to a lack of portability and scalability in the 24 architecture, critical concerns given Deliver’s large volume of customers. 33
  • 37. 1 Business units that innovate the process more than the product (are below the diagonal) push 2 the process toward standardization and can realize the fastest learning rates by exploiting process 3 efficiencies. However, the process can become inflexible and difficult to modify. This may 4 explain why Telecom is out of alignment. As shown in Figure 2, Telecom is misaligned because 5 its standardized process does not fit with its business unit strategy. This misalignment may be 6 ascribed, at least in part, to the fact that Internet application development was outsourced from 7 Telecom. To leverage economies of scale across engagements, outsourcing vendors often use a 8 standard methodology (Levina and Ross 2003). The outsourcing vendor for Telecom also 9 attempted to implement a standard methodology. However, because Telecom is a major client, 10 the vendor created a separate business unit for Telecom’s IT projects, and that unit was working 11 in a specialized industry with somewhat unique needs. The unit’s developers were struggling to 12 use the standard development process for new Internet applications: “The technology is so visual, it is 13 easy for end users to picture what they want. But, each person wants something different… so, even though we have 14 an overall methodology, it can be difficult to standardize processes” (Relationship Manager, Telecom). In an 15 example of adaptive exploitation, the developers tailored the standard methodology and adopted 16 a more flexible assembly approach, decoupling the standard processes, using parallel 17 development, and reusing standard architecture frameworks and designs where appropriate. 18 CONCLUDING REMARKS 19 This study addresses an important issue for businesses in the 21st century: how should work 20 processes that create knowledge products be aligned with business strategies in a competitive 21 environment transformed by new technologies. This issue is particularly salient in software 22 development because software is a valuable and well-defined example of a knowledge product. 23 Software development can test and challenge the general theories derived from the experience of 24 making physical products. Indeed, there is a long tradition of considering software development 34
  • 38. 1 from the perspective of manufacturing (e.g., TQM and CMM, software factories, component- 2 based development) and of applying theories and frameworks (like the product-process matrix) 3 from manufacturing to examine and understand software development issues. 4 A central insight of our study is that, consistent with the product-process matrix, software 5 process does depend on how a firm competes, and especially on competitive choices relating to 6 product variety. The variety of product requirements may be crucial in determining the type of 7 software processes that can be deployed. Business units in the firms we studied such as Predict 8 (with its 150 different development processes) and Index (with its struggles to commoditize its 9 product) clearly reflect the challenges encountered in achieving consistent development 10 processes when the applications developed are highly customized. This suggests a tension 11 between the costs and benefits of software customization. On the one hand, customizing a 12 software product can attract new customers and can distinguish a firm from its competitors. On 13 the other hand, it may be more costly to customize than to standardize. One may question 14 whether these cost differences are as significant for software development. Software is intangible 15 and more easily adapted than a physical product. Also, software processes may be more 16 adaptable than manufacturing processes bound by machinery, raw materials and physical plants. 17 Finally, technologies such as agile methods and modular architectures may make it less costly to 18 customize and adapt development processes. Nevertheless, two firms in our study chose to 19 standardize their development processes and Internet applications (Utility and Insure). One firm 20 (Index) aspired to standardize its Internet applications, and another (Telecom) tried to leverage 21 the corporate standard development methodology even if it was not best suited to a particular 22 engagement. This implies that customizing products and processes is not “free” in software 23 development. An important direction for future research is to examine the economics of software 35
  • 39. 1 customization, and particularly over the software life cycle, as the costs of supporting highly 2 customized applications may be even more significant than the development costs. 3 Our study contributes to the IS literature by offering detailed configurations of software 4 development processes that can be aligned with certain types of business unit strategies, 5 supported by empirical evidence from case studies. The IS strategy literature has examined 6 alignment at a more macro level. However, given the many choices for software development 7 and the notion that “one size may not fit all” projects (Shenhar 2001), it is important to examine 8 alignment decisions at a more micro or operational level. But, like any empirical study, ours has 9 some limitations. We have focused on whether and how firms align their business unit strategies, 10 software applications and development processes. This enabled us to provide detailed insights 11 into the ways in which different dimensions are matched. However, our cross-sectional research 12 design did not allow us to examine why business units are misaligned and what are the 13 consequences. Future studies should investigate alignment decisions over time as markets, 14 products, and processes mature. In addition, research is needed to discern the performance 15 consequences of alignment or misalignment. Finally, we have studied alignment in Internet 16 application development contexts. This focused research design constitutes a control in our 17 study; however, our findings may be limited to Internet application development. It is possible 18 that our results could generalize to other software development contexts, especially where the 19 applications developed are tightly linked to the customer and are part of the bundle offered to the 20 customer. No single study is definitive; thus, the external validity of our results can be 21 strengthened by future research on alignment between software development and business 22 strategies in other application domains and development contexts. 23 REFERENCES 24 Ahmad, S., Schroeder, R., “Refining the Product-Process Matrix,” International Journal of 25 Operations and Production Management, (22:1), 2002, 103-124. 36
  • 40. 1 2 Aranda, D. “Relationship Between Operations Strategy and Size in Engineering Consulting 3 Firms,” International Journal of Service Industry Management, (13:3-4), 2002, 263-285. 4 5 Banker, R., Datar, S., Kemerer, C. ”A Model to Evaluate Variables Impacting the Productivity of 6 Software Maintenance Projects,” Management Science, (37:1), 1991, 1-18. 7 8 Banker, R., Davis, G., Slaughter, S. ”Software Development Practices, Software Complexity and 9 Software Maintenance Performance,” Management Science, (44:4), 1998, 433-450. 10 11 Brooks, F. The Mythical Man Month, (Anniversary ed.), Reading, MA: Prentice-Hall, 1995. 12 13 Brown, S., Blackmon, K. “Aligning Manufacturing Strategy and Business-Level Competitive 14 Strategy in New Competitive Environments,” Journal of Management Studies, (42:4), 2005, 15 793-815. 16 17 Calinski, T., Harabasz, J. “A Dendrite Method for Cluster Analysis,” Communications in 18 Statistics, (3), 1974, 1-27. 19 20 Cameron, J. “Configurable Development Processes,” Communications of the ACM, (45:3), 2002, 21 72-77. 22 23 Conallen, J. Building Web Applications with UML, Addison-Wesley, Boston, MA, 2000. 24 25 Daley, B. “Using Concept Maps in Qualitative Research,” in Proc. of the First Int. Conference on 26 Concept Mapping, A. Cañas, J. Novak, F. González, Eds., Pamplona, Spain, 2004. 27 28 Deck, M. “Managing Process Diversity While Improving your Practices,” IEEE Software, May- 29 June, 2001, 21-27. 30 31 Dubé, L., Paré, G. ”Rigor in Information Systems Positivist Case Research: Current Practices, 32 Trends, and Recommendations,” MIS Quarterly, (27:4), 2003, 597-635. 33 34 Eden, C., Ackermann, F. Making Strategy: The Journey of Strategic Management, Sage, 1998. 35 36 Eisenhardt, K. “Building Theories from Case Study Research,” Academy of Management 37 Review, (14:4), 1989, 532-550. 38 39 Farjoun, M. “Towards an Organic Perspective on Strategy,” Strategic Management Journal, 40 (23:7), 2002, 561-594. 41 42 Fitzgerald, B., Russo, N., O’Kane, T. “Software Development Method Tailoring at Motorola,” 43 Communications of the ACM, (46:4), 2003, 65-70. 44 45 Grover, V., Malhotra, M. “A Framework for Examining the Interface between Operations and 46 Information Systems,” Decision Sciences, (30:4), Fall 1999, 901-920. 47 37
  • 41. 1 Hayes, R., Wheelwright, S. Restoring our Competitive Edge: Competing through Manufacturing, 2 Wiley, New York, 1984. 3 4 Hayes, R., Wheelwright, S. “Link Manufacturing Process and Product Life Cycles,” Harvard 5 Business Review, (57:1), 1979a, 133-140. 6 7 Hayes, R., Wheelwright, S. “The Dynamics of Process-Product Life Cycles,” Harvard Business 8 Review, (57:2), 1979b, 127-136. 9 10 Heim, G., Sinha, K. “A Product-Process Matrix for Electronic B2C Operations: Implications for 11 the Delivery of Customer Value,” Journal of Service Research, (3:4), 2001, 286-299. 12 13 Heim, G., Sinha, K. “Service Process Configurations in Electronic Retailing,” Production and 14 Operations Management, (11:1), 2002, 54-74. 15 16 Hill, T. Manufacturing Strategy, MacMillan, New York, 2001. 17 18 Huete, L., Roth, A. “The Industrialization and Span of Retail Banks’ Delivery Systems,” 19 International Journal of Operations and Production Management, (8:3), 1988, 46-86. 20 21 Jacobs, D. “Enterprise Software as Service,” Queue, July/August, 2005, 36-42. 22 23 Kathuria, R., Anandarajan, M., Igbaria, M., “Linking IT Applications with Manufacturing 24 Strategy,” Decision Sciences, (30:4), 1999, 959-991. 25 26 Kemerer, C. ”How the Learning Curve affects Case Tool Adoption,” IEEE Software, (9:3), 1992, 27 23-28. 28 29 Kothe, S., Orne, D. “Generic Manufacturing Strategies: A Conceptual Synthesis,” Strategic 30 Management Journal, (10:3), 1989, 211-231. 31 32 Krajewski, L., Ritzman, L. Operations Management, 7th ed., Prentice-Hall, Englewood Cliffs, 33 NJ, 2005. 34 35 Kriebel, C., Raviv, A. ”An Economics Approach to Modeling the Productivity of Computer 36 Systems,” Management Science, (26:3), 1980, 297-311. 37 38 Lee, A. ”Case Studies as Natural Experiments,” Human Relations, (42:2), 1989a, 117-137. 39 40 Lee, A. ”A Scientific Methodology for MIS Case Studies,” MIS Quarterly, (13:1), 1989b, 33-50. 41 42 Levina, N., Ross, J. “From the Vendor's Perspective: Exploring the Value Proposition in IT 43 Outsourcing," MIS Quarterly (27:3), 2003, 331-364. 44 45 March, J. ”Exploration and Exploitation in Organizational Learning,” Organization Science, 46 (2:1), 1991, 71-87. 47 38
  • 42. 1 McLachlan, G. Discriminant Analysis and Statistical Pattern Recognition, Wiley-Interscience, 2 New York, 2004. 3 4 Miles, R., Snow, C. Organizational Strategy, Structure, and Process, McGraw-Hill, New York, 5 1978. 6 7 Miles, M., Huberman, A. Qualitative Data Analysis: An Expanded Sourcebook, 2nd ed., Sage 8 Publications, Beverly Hills, CA, 1984. 9 10 Mintzberg, H., Ahlstrand, B., Lampel, J. Strategy Safari: A Guided Tour Through the Wilds of 11 Strategic Management. Prentice Hall, London, 1998. 12 13 Nidumolu, S., Knotts, G. ”Effects of Customizability and Reusability on Perceived Process and 14 Competitive Performance of Software Firms,” MIS Quarterly, (22:2), 1998, 105-137. 15 16 Novak, J. Learning, creating and using knowledge: Concept Maps™ as facilitative tools in 17 schools and corporations. Mahwah, NJ: Lawrence Erlbaum Associates, 1998. 18 19 Panzar, J., Willig, R. ”Economies of Scope,” American Economic Review, (71:2), 1981, 268-272. 20 21 Panzar, J., Willig, R. ”Economies of Scale in Multi-output Production,” Quarterly Journal of 22 Economics, (91), 1977, 481-493. 23 24 Paulk, M., Curtis, B., Chrissis, M., Weber, C. “Capability Maturity Model, Version 1.1,” IEEE 25 Software, (10:4), 1993, 18-27. 26 27 Porra, J. ”Electronic Commerce Internet Strategies and Business Models,” Information Systems 28 Frontiers, (1:4), 2000, 389-399. 29 30 Porter, M. “Strategy and the Internet,” Harvard Business Review, (79:3), 2001, 63-78. 31 32 Porter, M. “What is Strategy?” Harvard Business Review, (74:6), 1996, 61-78. 33 34 Porter, M. Competitive Strategy: Techniques for Analyzing Industries and Competitors, New 35 York: Free Press, 1980. 36 37 Porter, M., Millar, V. “How Information Gives you Competitive Advantage,” Harvard Business 38 Review, (63:4), 1985, 149-160. 39 40 Pralahad, C., Hamel, G. “The Core Competence of the Corporation,” Harvard Business Review, 41 (68:3), 1990, 79-91. 42 43 Sabherwal, R., Chan, Y. “Alignment between Business and IS Strategies: A Study of 44 Prospectors, Analyzers, and Defenders,” Information Systems Research, (12:1), 2001, 11-33. 45 46 Sabherwal, R., Hirschheim, R., Goles, T. “The Dynamics of Alignment: Insight From a 47 Punctuated Equilibrium Model,” In R. Galliers and D. Leidner (eds.) Strategic Information 48 Management, 3rd ed., Butterworth Heinemann, 2003. 39
  • 43. 1 2 Sacks, M. On-the-job learning in the software industry, Westport, CT: Quorum Books, 1994. 3 4 Safizadeh, M., Ritzman, L., Sharma, D., Wood, C. “An Empirical Analysis of the Product- 5 Process Matrix,” Management Science, (42:11), 1996, 1576-1591. 6 7 Shapiro, C., Varian, H. Information Rules: A Strategic Guide to the Network Economy, Harvard 8 Business School Press, Boston, MA, 1999. 9 10 Shenhar, A. “One Size Does Not Fit All Projects: Exploring Classical Contingency Domains,” 11 Management Science, (47:3), 2001, 394-414. 12 13 Slaughter, S., Harter, D., Krishnan, M. “Evaluating the Cost of Software Quality,” 14 Communications of the ACM, (41:8), 1998, 67-73. 15 16 Tapscott, D. "Rethinking Strategy in a Networked World (or Why Michael Porter is Wrong 17 about the Internet)", Strategy+Business, 3rd Quarter, 2001, http://www.strategy-business.com. 18 19 Tapscott, D., Ticoll, D. Lowy, A. Digital Capital: Harnessing the Power of Business Webs, 20 Harvard Business School Press, Boston, MA, 2000. 21 22 Tashakkori, A., Teddlie, C. Mixed Methodology: Combining Qualitative and Quantitative 23 Approaches, Thousand Oaks, CA: Sage, 1998. 24 25 Teece, D., Pisano, G., Shuen, A., “Dynamic Capabilities and Strategic Management,” Strategic 26 Management Journal, (18:7), 1997, 509-533. 27 28 Varian, H., Intermediate Microeconomics: A Modern Approach, 6th ed., W. Norton, 2002. 29 30 Venkatraman, N. “Five Steps to a dot.com Strategy: How to Find your Footing on the Web,” 31 Sloan Management Review, (41:3), 2000, 15-28. 32 33 Wade, M., Hulland, M., “The Resource-based View and Information Systems Research: Review, 34 Extension and Suggestions for Future Research,” MIS Quarterly, (28:1), 2004, 107-142. 35 36 Ward, J., Griffiths, P. Strategic Planning for Information Systems, Wiley, New York, 1996. 37 38 Weill, P., Broadbent, M. Leveraging the New Infrastructure: How Market Leaders Capitalize on 39 Information Technology, Harvard Business School Press, Boston, MA, 1998. 40 41 Wheelwright, S. “Manufacturing Strategy: Defining the Missing Link,” Strategic Management 42 Journal, (5:1), 1984, 77-91. 43 44 Yin, R. Case Study Research: Design and Methods, 2nd ed., Sage, Thousand Oaks, CA, 1994. 40

×