G:\MISQ\2006\December 2006\Slaughter.wpd - Semantic Scholar

Slaughter et al./Aligning Software Processes with Strategy

RESEARCH ARTICLE

ALIGNING SOFTWARE PROCESSES WITH STRATEGY1 By:

Sandra A. Slaughter David A. Tepper School of Business Carnegie Mellon University Tech & Frew Streets Pittsburgh, PA 15213 U.S.A. [email protected] Linda Levine Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 U.S.A. [email protected] Balasubramaniam Ramesh Computer Information Systems Department Georgia State University Atlanta, GA 30303 U.S.A. [email protected] Jan Pries-Heje The IT University of Copenhagen Rued Langgaards Vej 7 DK-2300 Copenhagen S DENMARK [email protected]

1

Ron Weber was the accepting senior editor for this paper. Fran Ackerman was the associate editor. Rob Austin and Srinarayan Sharma served as reviewers. The third reviewer chose to remain anonymous.

Richard Baskerville Computer Information Systems Department Georgia State University Atlanta, GA 30303 U.S.A. [email protected]

Abstract Although increasing evidence suggests that superior performance requires alignment between firms’ strategies and production processes, it is not known if such alignment is relevant for software development processes. This study breaks new ground by examining how firms align their software processes, products, and strategies in Internet application development. Drawing upon the literatures in strategy, operations management, and information systems, we identify four dimensions that influence alignment: the business unit strategy, the level of product customization, the level of process customization, and the volume of customers. To examine how these dimensions are synchronized, we conducted detailed case studies of Internet application development in nine varied firms including both start-ups and established “brick and mortar” companies. Our analyses reveal that the firms in our study do use differing processes for Internet application development, and that many of the firms match their software process choices to product characteristics, customer volume, and business unit strategies. We develop concept maps for the firms that are in alignment to illustrate how managers configure specific product and process dimensions. We also offer potential explanations for why some firms are misaligned, such as attempting to execute incompatible strategies, the lack of coordination between marketing and production strategies, the too rapid expansion of process scope, and inflexible barriers to rapid adaptation

MIS Quarterly Vol. 30 No. 4, pp. 891-918/December 2006

891


of process. Our study contributes detailed insights into how software processes are customized to complement different types of product requirements and strategies. Keywords: Software process, product–process matrix, Internet application development, software development strategy, competitive strategy, contingency theory

Introduction In operations management, there is general agreement that sustainable world-class performance requires internal consistency between firms’ strategies and their manufacturing operations (Krajewski and Ritzman 2005). Consistency means that the selection of strategies such as cost leadership or differentiation influences decisions on product priorities (such as cost, time, and quality), and that these priorities in turn guide decisions on production processes (Hill 2001). In information systems, there is a notion that a firm’s information technology strategy should be aligned with its other strategies. For example, value chain analysis (Porter and Millar 1985) aligns information systems to a firm’s primary and secondary activities. More recently, Grover and Malhotra (1999) link IS to manufacturing operations; Weill and Broadbent (1998) show how firms align their IT infrastructure decisions with their strategies; Sabherwal and Chan (2001) examine how the alignment between business and IT strategy impacts firm performance; and Sabherwal et al. (2003) model the alignment between the strategy and structure of the firm and its IT function. While these and other studies have described various components of alignment between firm strategies and IS, the focus of this literature has been more macro, that is, strategies are aligned to information systems, structure of the IT organization, overall IT strategy, or to IT architecture. To the best of our knowledge, there are few studies that have examined how software development processes are aligned with different strategies. By software development processes, we refer to the activities, methods, practices, and transformations that are used to develop and maintain software (Paulk et al. 1993, p. 20). Decisions on software development processes include choices relating to team organization and staffing, methodologies, techniques, tools, and architecture. Using one standard approach to software development can be less costly, leverage economies of scale, and simplify project management, knowledge transfer, and performance measurement. However, given the many approaches to software development, it may not always be effective for firms to standardize on one approach for all projects. Indeed, researchers and software

892

MIS Quarterly Vol. 30 No. 4/December 2006

development specialists have suggested the potential performance benefits of process customization (Deck 2001). For example, a study of software firms by Nidumolu and Knotts (1998) reveals that the customizability of software development processes can significantly influence competitive performance. Process customization or tailoring involves adapting, particularizing, or selecting certain (often standard or “best practice”) software processes to fit the needs of specific organizations or projects. Examples include Motorola, where software development methods are tailored at the industry, organization, and project levels (Fitzgerald et al. 2003), and IBM, where work product descriptions are used to configure a software process to a particular project and make decisions about process sequencing and phasing (Cameron 2002). However, despite the potential benefits of process tailoring, there has been little research that provides insights into how such customizing occurs, in terms of aligning software processes with business strategies. The objective of our study is to fill some of this void by examining whether and how software development processes are fit to strategies. Three levels of strategy can be distinguished in a firm: corporate, business unit, and functional (Kotha and Orne 1989; Wheelwright 1984). We identify firms’ business unit strategies as an important basis for selecting software processes. This basis is consistent with the idea in operations management that strategic and production decisions are interrelated. At the corporate level, managers define the businesses in which the firm operates and allocate resources to those businesses. At the business unit level, managers specify the scope and strategy of each business unit and define how the business unit strategy relates to the corporate strategy. Specifying the business unit strategy requires choosing the product, market, and service subsegments to be addressed by the unit. Thus, it is at the business unit that the basis of competitive advantage (cost leadership or product differentiation) is defined (Kotha and Orne 1989, Wheelwright 1984). These choices give the business unit a broader or narrower product line than its principal competitors. Having made those choices, managers must then decide at the functional level whether to produce the product or service with a process that permits a high degree of flexibility but is labor-intensive and usually has relatively higher costs or a process that is more standard and automated with relatively lower costs. A key argument is that process choices must be consistent with business unit strategies for the firm to be productive and effective (Brown and Blackmon 2005; Kotha and Orne 1989; Wheelwright 1984). Strategy, product, and process alignment are salient in Internet application development. An Internet application is software that allows its users to execute business logic using


a universal, client-server browser architecture (Conallen 2000). Business to consumer Internet applications, such as web-based retailing systems, directly interface with customers and constitute (or directly support) the product or service “bundle” offered to them. Because these Internet applications and their associated services are revenue-generating and must directly satisfy customers’ requirements (Porra 2000), the software and development processes may reflect the nuances of a firm’s business unit strategy. For example, the principal architect of salesforce.com describes how competitive advantage for online businesses relates to Internet application development choices such as resource sharing, multi-tier clustering, and application customization (Jacobs 2005). Resource sharing facilitates economies of scale and pay-asyou-go pricing; multi-tier clustering allows an online service provider to more easily scale up and grow the business; and application customization can differentiate the provider from other providers. Other examples are provided by Heim and Sinha (2002) who describe how the web-based retailer Baltimore Coffee and Tea (www.baltcoffee.com) supports a “service mart” or “assemble to order” strategy by programming dynamic scripts in an Internet shopping cart system to sell more than 1,000 varieties of coffee and tea. This is contrasted with a “service kiosk” or “make to stock” strategy implemented using static HTML technologies to provide identical experiences to all customers.

their business unit strategies.2 Among the positioning approaches to strategy development, we draw on Porter’s (1980) competitive forces model Other prominent models in this school including the Miles and Snow (1978) typologies or theories that emphasize firms’ capabilities such as the resource-based view (Wade and Hulland 2004), dynamic capabilities approach (Teece et al. 1997) or core competency theory (Prahalad and Hamel 1990) are less suited to our objectives as none has clear implications for how particular strategies can be matched with particular processes. In contrast, in Porter’s view of strategy, operational activities are the basic units of competitive advantage. According to Porter (1996), strategy involves the creation of a unique and valuable position for a firm, using a distinctive mix of activities: “the essence of strategy is in the activities—choosing to perform activities differently or to perform different activities than rivals” (p. 64). However, operational effectiveness alone, claims Porter, is insufficient for long-term competitive success. This is especially true in the world of the Internet: “Because the Internet tends to weaken industry profitability without providing proprietary operational advantages, it is more important than ever for companies to distinguish themselves through strategy” (Porter 2001, p. 63).3 Thus, the importance of strategic positioning in creating sustainable competitive advantage is highlighted.

Thus, we address the following question in this study: are software processes aligned with firms’ business unit strategies in Internet application development, and if so, how? Answering this question increases understanding of how firms develop Internet applications to address specific requirements by relying on different types of software development practices. If the alignment of firms’ business unit, product, and process strategies leads to sustained high performance, it is important to understand whether and how this alignment occurs, particularly in the expanding world of Internet application development. We next draw upon the literatures in strategy, operations management, and information systems to identify the dimensions that influence process, product, and business unit strategy alignment.

According to Porter (1980), strategic positioning can emerge from one of two generic strategies: cost leadership or differentiation. These strategies are implemented at the business unit level (Kotha and Orne 1989; Wheelwright 1984). The strategies are “generic” because they are neither firm nor industry dependent. A business unit’s strategy can be applied either market-wide or in a focused market segment (Porter 1980; Ward and Griffiths 1996). A cost leadership strategy is followed when the business unit produces standard products or services that are offered to many customers without significant tailoring to particular customer needs. A business unit pursuing this strategy achieves cost leadership when it can produce its products or services at the lowest cost. In contrast, a differentiation strategy is followed when a business unit strives to serve most or all of the idiosyncratic needs of particular customers, often at a premium price.

Theoretical Background

2

Strategy and Strategic Positioning There are several schools of thought with respect to strategy (Eden and Ackermann 1998; Minzberg et al. 1998). Among the various strategy schools, the positioning school is most consistent with our objective of understanding how firms align their Internet application development processes with

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. 3

Some disagree with Porter’s premise about the strategic implications of the Internet (e.g., Tapscott 2001; Tapscott et al. 2000).


893


Table 1. Product and Process Choices, Competitive Priorities, and Competitive Strategy Product Choices:

Process Choices: Job Shop

Low-Volume, Low Standardization, One of a Kind

Multiple Products, Low Volume

Few Major Products, Higher Volume

High-Volume, High Standardization, Commodity

V V

Batch Flow

V

Assembly Line

V

Continuous Flow Competitive Priorities:

Custom Design Fast Reaction Flexibility

Competitive Strategy:

Differentiation

Custom Design Fast Reaction Flexibility Quality Control

Dependability Efficiency Standardized Design Volume Production

Dependability Efficiency Standardized Inputs Economies of Scale

Cost Leadership

Adapted from Hayes and Wheelwright 1984, p. 216. Optimal alignment of process choices to competitive strategy and product choices is along the left-to-right diagonal in the matrix, indicated by “V’s.”

Further, Porter (1996) argues that to sustain the competitive advantage achieved through strategic positioning, firms must create an “alignment” between their operational activities and strategies. Alignment means that firms choose activities and structures that complement their strategies (Farjoun 2002). Alignment is important because individual activities in firms can often affect each other in ways that either strengthen or diminish their joint effects. When activities mutually reinforce each other and are consistent with the firm’s strategies, competitors cannot easily imitate them. Although not always in agreement with Porter, other strategists have emphasized the importance of complementarities between firms’ activities and strategies. For example, Venkatraman (2000) notes that effective strategizing requires firms competing on the Internet to consider issues of operations, resources, and infrastructure together as interrelated decisions, rather than in isolation. This highlights the importance of aligning firms’ operational activities and strategies. However, the strategy literature does not provide much specific guidance on how to tailor operational processes to align with particular strategies.

Aligning Manufacturing Processes with Strategy The product–process matrix developed by Hayes and Wheelwright (1979b, 1984) is a central framework in operations management that links competitive priorities to manufacturing product and process choices (Table 1). As shown in Table 1, the product–process choices in the matrix are aligned with

894


Porter’s generic strategies of cost leadership and differentiation. This alignment is done at the business unit level (Kotha and Orne 1989; Wheelwright 1984). From the perspective of operations, the relevant strategy concerns the products to be manufactured (or the services to be delivered) by the business unit. The business unit strategy determines the important product characteristics that are, in turn, aligned with process choices (Kotha and Orne 1989). A differentiation strategy is consistent with high product variety, low volume, and an informal “job shop” process for manufacturing. A job shop process involves the production of unique or custom-made products, each of which requires a different set or sequence of processes. Scheduling is uncertain, with frequent adjustments to facilitate quick response to changes in customer and market tastes. The process is flexible in terms of products produced, flow paths followed, and resources used. There is a high dependence on skilled labor. When products have more common or standard elements, and there is more volume, a “batch” process can be used. The batch process resembles the job shop, but is more structured with more emphasis on quality control. At the other end of the continuum, homogenous products with large volumes are consistent with a cost leadership strategy and can be manufactured using “assembly line” or “continuous flow” processes. The assembly line involves the assembly of standard components in a sequential process. The process is less flexible than the job shop or batch processes and uses standard procedures, tools, and systems. There is less dependence on highly skilled labor. The continuous flow process also uses standard procedures, tools, and systems, and is highly automated and capital intensive. It is the most inflexible process.


A fundamental premise of the product–process framework is that, for optimal performance, a process must trade off product customization, volume, and production efficiency. That is, a firm should lie along the left-to-right diagonal of the matrix (see the “V’s” in Table 1). This premise derives from the theory of production economics, and specifically, the concepts of economies of scale (Varian 2002) and economies of scope (Panzar and Willig 1977, 1981). Scale economies relate the efficiency (cost) of production to the volume of the product produced; economies of scale exist when productivity increases with increasing production volume, and diseconomies exist when the volume of production is larger than the most efficient scale size. Economies of scope exist when, even though a firm is producing different products, there are common inputs and processes that can be shared across the products. Diseconomies of scope exist when inputs and processes differ for the products produced. In the product– process framework, the implication is that increasing product variety leads to many production complications and confusion such as more diverse process flows, more complex scheduling requirements, a greater need for planning and control, and wider skill requirements, all of which reduce production efficiency. Customized or tailored processes are seen as facilitating the production of highly customized products when volume is low, but are not as efficient as standard processes that produce a standard product when volume is high. Based on economies of scale and scope in production, a differentiation strategy is aligned with a high level of product and process customization and a low volume of production; in contrast, a cost leadership strategy aligns with high levels of product and process standardization and a high volume of production (Kotha and Orne 1989). It is important to note that in the product–process matrix, product and process choices are not viewed as binary. Rather, these alternatives are viewed along a continuum, allowing for intermediate levels of product and process customization and volume. Although created over two decades ago, the matrix is still influential today. The framework has been empirically validated in manufacturing industries (Safizadeh et al. 1996). It has also been applied to process industries, service industries, and product development activities, including banking services (Huete and Roth 1988), engineering and consulting (Aranda 2002), and electronic business-to-consumer service operations (Heim and Sinha 2001). In IS, the matrix has been used to understand how different IS applications support manufacturing operations (Kathuria et al. 1999). Recently, researchers have proposed updates to the matrix (Ahmad and Schroeder 2002) to accommodate the capabilities for mass customization offered by innovations in technology, product design, and managerial practices that allow firms to operate in cells of the matrix previously deemed nonoptimal.

Product–Process Alignment in Internet Application Development Although the product–process matrix provides insights in manufacturing, can it be used to understand software development? Clearly, the process type metaphors (job shop, batch, assembly line, and continuous flow) are more relevant to manufacturing than software development. Also, the product is not a physical good (an automobile or computer chip), but rather is an Internet application and the associated services that are bundled with it and sold directly to customers. However, if the economic concepts and theories underlying the framework are relevant for software development, the matrix may shed light on how Internet application development processes are aligned with business unit strategies. In contrast to manufacturing, software development is an intellectual activity that is perhaps more akin to research and development than to the production of physical goods. Software development does not require significant investments in plants and machinery, nor does it require raw materials and supplies. Most costs are for labor; the initial costs of development are substantial, but over the software life cycle, the costs to support the application dominate (Banker et al. 1998). Indeed, in a strict sense, the costs of production in software development are negligible because the primary costs incurred are those required to develop the first “copy” of the software, and the costs to replicate this copy are essentially zero (Shapiro and Varian 1998). Thus, the “volume of production” is not as relevant, per se, to software development. Nevertheless, there are still important parallels between manufacturing and software development in terms of the economics of the processes. In fact, there is a line of research in IS that models software development as an economic production process (Banker et al. 1991; Banker et al. 1998; Kriebel and Raviv 1980). From this perspective, inputs including labor (the developers) and capital (tools and techniques) are used to create outputs such as software code. Although the “production process” in software development is knowledge work, it can be relatively structured and repetitive (Kemerer 1992). For example, computer-aided software engineering tools, programming languages, and development methodologies can be used in a repetitive way across projects. Sufficient repetition allows software developers to learn from experience (Sacks 1994). Thus, scale economies can occur within a large software project or across a set of related projects because developers can learn and become more efficient as one or more tasks are repeated. Economies can also occur because investments in overhead activities that facilitate project performance such as project management, configuration management, testing, and quality control can be spread over a larger base (Slaughter et al. 1998). For example, the


895


costs to set up sophisticated testing environments and databases can be recovered in a sufficiently large project or set of projects. There can also be diseconomies of scale in software development. As project size increases, certain aspects increase such as the complexity of interface requirements, the difficulty of testing and validating requirements, and the number of communication paths between developers. As a result, productivity eventually decreases with project size (Brooks 1995). Although the volume of production (number of copies produced) is not as relevant to software development economics, the volume of customers or users is. More customers increase the likelihood that the application will be used in different contexts and that different requirements will emerge. If sufficient numbers of customers have different requirements, the firm may have to either create different versions of the application for different customers or develop one complicated, feature-rich application (“bloatware”) where any one customer uses only a small subset of the features. The costs of coding, testing, and validating such customized applications can be substantial. Even if customers have similar needs, applications that will be used by a large number of customers may require specialized coding and testing processes to ensure that the software will work appropriately in a high-use situation. This is particularly true in an Internet environment where thousands or even millions of users may use an application on any day (Jacobs 2005). This discussion suggests that software development costs do relate to the degree of customization of the application and of the development process as well as to aspects of volume such as the number of customers. Thus, there may be sufficient similarities between software development and manufacturing in terms of their underlying economics that would make it advantageous to use the product–process matrix (at least ex ante) as a frame for our study and as a lens to examine our research question: how are products and processes aligned with business unit strategies in software development? That is, do business units with a differentiation strategy develop customized Internet applications, each for a small number of customers and therefore also use tailored development processes? Do other business units with a cost leadership strategy develop standardized Internet applications, each for a large number of customers and therefore also use standard development processes?

Methodology To examine these questions, we conducted detailed case studies of the strategies, products, and Internet application

896


development processes in the business units of nine varied firms. Case studies are ideal for research such as ours, that investigates how or why questions with a focus on contemporary issues such as Internet application development processes. Case studies are also well suited for studying real-life events over which the researcher has little or no control, such as organizational strategic directions (Yin 1994). Case studies can be used in critical, interpretive, or positivist frameworks, although the positivist framework is the most common (Dubé and Paré 2003). As positivist sociological research methods, case studies have been characterized as natural experiments (Lee 1989a) in which researchers explore the relationships between events and constructs post hoc. Like many other such positivist case studies, we do not invoke the scientific language of hypothesis testing, but we do make controlled observations, leverage multiple data sources, employ deductive logic, and use cross-case comparisons and multiple analysis methods to promote replicability and confidence in the validity of our findings (Lee 1989a, 1989b). In line with the recommendations for improving positivist case studies in IS (Dubé and Paré 2003), we provide details about the rigor in our data collection and analysis procedures. In the next sections, we describe our research sites, data collection, and coding.

Research Sites The firms in our study range in size from 20 employees to more than 100,000 employees and are in different industries such as financial services, insurance, business services, courier services, transportation, media, and telecommunications. All firms have significant Internet application development efforts: some are start-ups while others are “brick and mortar” firms with separate Internet application development units. In each firm, the Internet applications developed directly interface with customers and are part of the product or service bundle offered to them. From the perspective of research design, our focus on one type of task (Internet application development) is important because it reduces error variance in the results. While all firms conduct Internet application development, their industries, products, and customers are different. This variation is also a crucial aspect of our research design: since our objective is to discern varied patterns of alignment of product and process strategies in Internet application development, we need to consider a broad range of potential strategies. Table 2 provides a brief description of each firm in the study. To protect the anonymity of the firms, we assigned pseudonyms that reflect each firm’s primary Internet applications (products/services): Predict, Utility, Incubate, Index, HR, Travel, Insure, Deliver, and Telecom.


Table 2. Description of Firms in Study Firm Pseudonym, Capsule Case Description

Industry, Products & Services

When Founded, Size

Number Interviewed, Roles

Predict: Creates weather derivatives based on customer demand. Utility companies who are interested in learning about their customers’ consumption habits purchase the weather derivatives. Because the firm is able to create a unique and specialized product, it is able to dominate a niche in the energy industry.

Mid-1990s. Energy and communication. Offers 20 B2B software-based employees. forecasting tools.

Three: VP Operations, Project Manager, Software Developer

Utility: Three entrepreneurs founded in late 1990s. The firm’s business model recognizes the benefits of purchasing utility services in large quantities and passing along the lower prices to customers. The firm offers an online buying pool for customers to buy services like electricity, phone, and water at a discount.

Utilities. Offers low Late 1990s. prices via Internet 35 buying pools for employees. customers buying utility services.

Six: CEO, VP Technology, Marketing Research Director, CIO, Developers

Incubate: Founded in late 1990’s. Creates electronic commerce sites for brick-and-mortar companies. The firm also develops how the client’s brand name and brand image will be personified on the web. This differentiated strategy allows the firm to set itself apart from the countless number of web development companies.

Across Industries. Helps brick & mortar companies develop customized web sites and presence.

Four: Director, Chief Financial Officer, Chief Operations Officer, Developer

Index: Founded in mid-1990s by two entrepreneurs. Has grown to over 80 employees. Provides its clients with the technology for searching and indexing videos via the Internet. Because it offers such a specialized product, the customer base is extremely limited. However, trying to expand market offerings.

Film and television. Mid 1990s. Offers software 80 indexing and searching employees. tools on the Internet.

Four: Project Manager, marketing specialist, senior web developer, Q/A specialist

HR: Offers services for managing and communicating human resources, employee benefits and payroll information. The systems it creates reduce the administrative costs of its clients. To differentiate from the other human resource solution providers, the firm has focused its efforts solely on small to medium sized firms.

Administrative Mid 1990s. Services. Provides HR >100 applications and employees. services via the Internet.

Seven: Project Manager, Architect, User Interface Design, Web Developers

Travel: Established in early 1990s by affiliates of a major transportation company. Provides all travel arrangements for its clients, mid-sized corporations. Because the firm focuses on corporate travel, it can better understand the needs of its clients and can build lasting relationships with them.

Transportation and Tourism. Offers travel applications and services to firms via the Internet.

Early 1990s. >1,000 employees

Six: Senior Manager, Project Manager, Q/A Manager, Lead Developers, Web Developers

Insure: One of the top insurance companies in the United States. Offers various types of insurance such as automobile, motorcycle watercraft, etc. Successfully launched a website in mid-1990s, where customers can get quotes or buy insurance online.

Insurance. Offers software-based insurance services via Internet to individuals and firms.

Before 1950. >100,000 employees

Three: Human Resources Manager, Internet Site Manager, Internet Site Developer

Deliver: One of the top express delivery providers in the United States. With e-commerce gaining popularity, the firm plays a significant role in the delivering of products to end-consumers. In response to the increase of home-users, launched a website in mid1990s. The website offers functionality such as the ability for customers to track their packages on-line.

Transportation and Logistics. Offers software-based logistics services on the Internet.

Before 1950. >100,000 employees

Six: CIO, Senior Manager, Project Manager, Architect, Senior Developer, Web Developer

Telecom: Provides IT solutions for a large telecommunication provider. Major part of IT was outsourced 18 months prior to our visit. But most of the IT personnel had been transitioned to the outsourcing vendor and the unit studied was working with the same products and technology as before the outsourcing.

Telecommunications. Offers web-based telecommunications services.

Before 1950 >50,000 employees

Six: Senior Manager, Project Manager, Q/A Manager, Q/A Specialist, Web Developers

Late 1990s. 55 employees.


897


Data Collection and Coding Our unit of analysis is the business unit that develops and markets the firm’s Internet applications.4 We conducted semi-structured interviews with managerial and technical personnel at each firm to elicit details relating to the business unit strategy and the major dimensions of the product–process matrix. Key informants included senior managers, product managers, project managers, Internet application developers, and quality assurance specialists. The informants were carefully selected to provide the best source of information; thus, we directed questions concerning strategy, products, and customers (i.e., what Internet applications/services are produced?) to senior managers, and questions about Internet application development processes (i.e., describe the tools you use to develop Internet applications) to project managers, developers, and quality assurance specialists. We also included questions on organizational and interviewee demographics to obtain a more complete understanding of the firms and individuals interviewed.5 In all, as shown in Table 2, we interviewed 45 individuals in the business units of the nine firms. Interviews with each informant were typically 2 hours in length, and site visits usually lasted at least 4 hours. The interviews were conducted by two or three researchers on the team; one researcher concentrated on interviewing, while the other(s) took short notes using laptop computers. Immediately after an interview, the notes were written out in full text, and transcripts were integrated and reviewed by all of the researchers conducting the interview. Having multiple investigators is an advantage in a case study because their different perspectives and insights add objectivity and enhance the potential for creative and novel contributions (Eisenhardt 1989). The transcripts from the interviews yielded more than 100 pages of single-spaced text. The interview data were complemented with secondary data about each firm’s business unit strategies and other characteristics (revenues, employees, and company history) that were obtained from the firms’ web sites and from publicly available information such as annual financial reports or press releases. Using multiple sources of evidence is a key tactic to increase construct validity in case studies and helps mitigate the potential for bias (Yin 1994). For example, a manager’s description of the firm’s business

4

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.

unit strategy could be compared with the description of the strategy on the firm’s web site. To guide our operationalization and coding of the four theoretical constructs determining alignment (business unit strategy, the level of product customization, the level of process customization, and the volume of customers), we referenced the literature on the product–process framework (Ahmad and Schroeder 2002; Aranda 2002; Safizadeh et al. 1996) and on business strategy (Porter 2001, 1980; Ward and Griffiths 1996) to develop rules and procedures for coding each construct.6 We identified the business unit strategy by applying the coding rules to the interview statements from senior managers and publicly available information about the firm. A cost leadership strategy was coded for business units that endeavored to beat competitors by producing goods or services at the lowest cost, and a differentiation strategy was coded for business units that sought to achieve competitive advantage by creating a product or service that is unique and usually offered at a premium price (Porter 1980; Ward and Griffiths 1996). An independent coder rated each firm’s business unit strategy based upon what the business unit was actually doing (i.e., the unit’s strategy-in-use). In our coding, we were aware of the potential for differences in the stated versus actual business unit strategies, and therefore considered multiple kinds of information (interview transcripts from multiple informants, annual reports, web sites, press releases, etc.) to help identify and corroborate the actual strategies-in-use executed by the firms’ business units for their Internet-based products. The coder also evaluated information about each business unit’s major competitors, and coded the competitors’ strategies to determine whether the unit’s positioning vis-à-vis its competitors agreed with the coded strategy. For example, Predict is coded as a differentiator: its business unit provides unique services to each customer and charges a premium price for these services. Utility is coded as a cost leader: its business unit offers customers the lowest prices for commodity products and services by forming online buying pools. As a final check of the coding, the first author also coded each firm’s business unit strategy and compared the coding with that of the independent coder. There were no disagreements between coders in the coding of firms’ business unit strategies. The interview transcripts were the primary basis for the coding of the level of product customization and the level of process customization. We developed the coding rules for each of these constructs from the product–process literature

6 5

The complete interview protocol is in Apendix A.

898


Coding details and examples of coded data for each of the theoretical constructs are in Appendix B.


(Ahmad and Schroeder 2002; Aranda 2002; Safizadeh et al. 1996) and adapted them to suit an Internet application development context. For example, Predict’s “product” is a bundle of an Internet-based application and services: the firm offers software tools, analyses of historical data, and advice to help utility companies forecast the future energy demand of their customers. An independent coder and the first author of this paper read statements in the transcripts relating to product customization and process customization and coded the levels of each of these constructs. The level of product customization refers to the extent to which a firm’s business unit customizes its Internet application/service bundle by creating unique features to meet the needs of each customer. A high level of product customization was coded when the business unit offered a unique Internet application/service bundle to each customer, and a low level of product customization was coded when the business unit offered a standard Internet application/service bundle to many customers. The level of process customization refers to the extent to which a firm’s business unit tailors its Internet application development process for each customer. A high level of process customization was coded when the business unit tailored or adapted the development process for each application or customer while a low level of process customization was coded when the business unit used a standard development process. For example, for Predict, the level of product customization is high because a different application is created for each utility company served. The level of process customization is also high for Predict, because the development process is adapted for each utility company to accommodate the nuances of each utility’s historical data and legacy systems. Although the coders initially disagreed on the coding of 2 of 18 items, after discussion and reference to the transcripts, the coders mutually agreed upon all of the final coding assignments for these constructs for each firm’s business unit. Finally, the volume of customers refers to the number of customers who have purchased the Internet application/ service bundle. We obtained actual figures about the number of customers for the Internet applications from interviews and company documentation.7

Analysis and Results We used a mixed methods data analysis approach (Tashakkori and Teddlie 1998) in which we first qualitatively analyzed the coded data to visually discern patterns of product–process

alignment and to group business units with similar patterns together. We then quantitized the coded data and performed a cluster analysis and a discriminant analysis to confirm and further analyze the patterns and groups identified by the qualitative analysis. This mixed methods approach offers several advantages. As Tashakkori and Teddlie (1998) have argued, the use of multiple methods helps to triangulate and confirm the findings, providing more confidence in the conclusions reached. In addition, using both qualitative and quantitative methods affords the opportunity to leverage the benefits of each method and can enrich the insights obtained. Following the approach for cross-case qualitative analysis recommended by Miles and Huberman (1984) and Yin (1994), we used pattern matching to identify similar types of alignments of strategy, customer, product, and process dimensions across the firms’ business units. The analysis involved the use of four different spreadsheets (one for each theoretical construct) in which the coded data for each business unit were placed in one or more cells of the unit’s particular column in the spreadsheet. We then sorted the columns of each spreadsheet so that the firms’ business units were ordered from left to right by business unit strategy (differentiator to cost leader), level of product customization (high to low), level of process customization (high to low), and volume of customers (small to large). This enabled us to visually identify patterns of alignment across constructs, to compare patterns across units, and to group units with similar patterns together. For example, we observed that the business units of Predict and Incubate both followed differentiator strategies and used development processes that were highly customized while those of Utility and Insure both followed cost leader strategies and used more standard development processes. The cross-case analysis suggested three different groups of alignment patterns. One group included business units that were cost leaders with more standardized products and processes; another group included business units that were differentiators with more customized products and processes; and the third group included business units with intermediate levels of product and process customization. Our quantitative analysis leveraged cluster analysis and discriminant analysis (McLachlan 2004).8 Cluster analysis was used to identify groups of similar business units and to corroborate the groups identified from the qualitative analysis, and discriminant analysis was used to provide further corroboration of the groups and to help understand similarities and differences across units and groups. We quantitized the text8

7

The figures on customer volume are presented in Table B1 (Appendix B).

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.


899


3

process strategy: highly standardized 2.5

TELECOM 2 Group #2

1.5

business unit/product strategy:

business unit/product strategy:

highly standardized/cost leader/

highly customized/differentiator/ 1

low volume

high volume Group Center

HR

Group #1 INCUBATE -9.0

-8.0

-7.0

Group #3

0.5

UTILITY INSURE

0 TRAVEL -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

PREDICT

Group Center

INDEX -1

DELIVER

-1.5

process strategy: highly customized -2

Figure 1. Graph of Firms’ Discriminant Scores

based codes for business unit strategy, level of process customization, and level of product customization for each firm, transformed customer volume using the natural logarithm, and input the transformed values into the analyses.9 A hierarchical cluster analysis distinguished three clusters.10 The clusters were similar to those we discovered in the qualitative analysis, supporting the groups of alignment patterns identified. We then used discriminant analysis (McLachlan 2004) to further analyze the data. Discriminant analysis identifies the fewest functions that are needed to cluster similar observations and to discriminate between dissimilar observations. A discriminant function is a latent variable representing a linear combination of the independent variables (in our analysis, the 9

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. 10

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.

900


strategy, product, process, and customer variables). We specified three clusters, ex ante, in the discriminant analysis using the cluster assignment for each firm’s business unit from the hierarchical cluster analysis. The discriminant analysis generated two functions that discriminated between the three clusters. The first function explained 98.9 percent of the variation between clusters, and the second function explained the remaining 1.1 percent of the variation between clusters. The functions are both statistically significant (at p < 0.01) in discriminating between clusters, and each of the individual independent variables differs significantly (all at p < 0.01) in mean by cluster. It is possible to interpret each discriminant function by considering its correlations with each of the four independent variables. We interpreted discriminant function 1 as representing “business unit/product strategy” as it correlates significantly with business unit strategy (0.812), level of product customization (–0.812), and volume of customers (0.511). Discriminant function 2 seems to capture “process strategy” as it is correlated significantly only with level of process customization (–0.953). We then used each discriminant function to generate a set of discriminant scores for each firm’s business unit, graphed in Figure 1.


In Figure 1, the x-axis represents the scores generated by Discriminant function 1 (the business unit/product strategy). Business units farther to the right on the x-axis have more standardized products and are cost leaders in a large market. Business units farther to the left on the x-axis have more customized products and are differentiators in a small market. The y-axis represents the scores generated by discriminant function 2 (the process strategy). Business units closer to the top of the graph use more standardized processes while business units closer to the bottom use more customized processes. Figure 1 also shows three distinct groups of business units where each group represents a particular alignment pattern. The group assignments were checked using the discriminant functions to predict each unit’s group assignment, and then the prediction was compared with the unit’s original assignment from the cluster analysis. In our study, the discriminant analysis matched the group assignments for each business unit as 100 percent of the units were correctly classified (predicted assignment = original assignment); this provides further support for the groups of alignment patterns we identified in the qualitative analysis. As shown in Figure 1, Predict, Incubate, and Index are in group #1. Figure 1 also suggests that Predict and Incubate are more similar in their patterns of strategy–product–process alignment than Index. Still, Figure 1 indicates that Index’s pattern of alignment is more like Predict’s and Incubate’s than the other business units in the other groups. The other two groups can be interpreted similarly, suggesting that Telecom and Deliver are most unlike the other units in their respective groups. In addition, comparing group centers suggests that groups 1 and 3 are most dissimilar as their respective group average scores are the farthest apart. We then drew radial graphs (Figure 2) to visualize how each firm aligned its business unit strategy, level of product customization, level of process customization, and customer volume.11 Each graph shows the numeric rating for each firm’s business unit on each of the four theoretical dimensions. A business unit is in alignment when the values for all dimensions are equal (i.e., the level of differentiation in business unit strategy matches the level of customization in product and process, and the volume of customers). For example, Predict is in alignment as all dimensions have the same value (1). A business unit is out of alignment when the values for all dimensions are not equal. For example, Deliver

11

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.

is out of alignment because its level of process customization (2) does not equal the value of the other dimensions (3). The radial graphs also reflect the levels of differentiation in business unit strategy, product and process, and the volume of customers. Values of 1 reflect a highly differentiated strategy, customized products and processes, and a low volume of customers while values of 3 reflect a cost leadership strategy, more standardized products and processes, and a high volume of customers; values of 2 reflect intermediate levels of these dimensions. To discern whether alignment varies across groups, we arranged each radial graph into its “assigned” group from the analyses. Comparing the radial graphs in Figure 2 by group shows that the business units in group #1 are the most highly differentiated; the business units in group #3 are the most standardized; and the business units in group #2 have intermediate levels of differentiation. This suggests that the business units have distinct patterns of alignment for their business unit strategies, products, and processes. Figure 2 also shows that six of the nine business units in the firms in our study do align their strategies as predicted. The radial graphs for Predict and Incubate in group #1 suggest that they pursue differentiation strategies, have highly customized products and development processes, and have relatively small volumes of customers. At the other end of the extreme in group #3, Insure and Utility pursue a cost leadership strategy, have more standard products and development processes, and have a larger volume of customers. The strategies used by HR and Travel in group #2 reflect intermediate levels of differentiation in business unit objectives, product characteristics, and Internet application development processes. The respective customer volumes are larger than those of Predict and Incubate, but smaller than those of Insure and Utility. Figure 2 also shows that Index, Telecom, and Deliver are “out of alignment” in that some aspect of their business unit strategies, products, processes, or customer volumes does not align as expected. We integrate and interpret these results in the next section.

Discussion Overall, we find that the dynamics of the product–process framework are relevant in software development as software process choices are aligned with product characteristics, customer volume, and business unit strategies for many of the firms. However, some units are not in perfect alignment. We first examine how units that are in alignment configure detailed dimensions of their products and processes. We then consider the business units that are misaligned.


901


Group #1: Highly Customized level of process standardization

level of process standardization

2

PREDICT

0

3

2

INCUBATE

2

INDEX

1

1

cost leadership strategy


3

3

level of product standardization


1


0

customers supported



0

customers supported

customers supported

Group #2: Intermediate level of process standardization


HR

2

0

3

TELECOM

2

TRAVEL

2

1

1



3

3



1


0

customers supported


customers supported

0


customers supported

Group #3: Highly Standardized level of process standardization



3

3

3

UTILITY

2

INSURE

2


0

DELIVER

1

1



customers supported


0


customers supported

2

1


customers supported

Figure 2. Strategy–Product–Process Alignment for Each Business Unity by Group

Business Units in Alignment Consistent with the product–process framework, for the business units in alignment, a customized development process is used when the volume of customers is small, and there are highly differentiated needs. A more standard development process is used when there are sufficient common needs that applications can be developed to serve a larger number of customers. To provide a deeper understanding of how the business units align elements of their products and processes,

902


we use concept maps. Concept maps organize and represent concepts (events or objects) and their interrelationships in a particular domain or context (Novak 1998). Relationships between concepts are associative. Concept maps were originally developed to help understand how children learn. Recently, concept maps have been used to conduct qualitative data analysis (Daley 2004) where the researcher draws the concept map, and uses it to visually identify themes and patterns, display linkages, and facilitate cross group or site comparisons.


Following the approach suggested by Daley (2004) and the techniques developed by Novak (1998), we developed concept maps to visually represent concepts for the business units in alignment. Consistent with the literature on concept mapping, we created concept maps with the broader, more inclusive concepts at the top of the hierarchy, connecting with other more detailed concepts below. Given our goals of evaluating alignment between business unit, product and process strategies, we deductively identified the main concept categories and their associations based on the primary aspects of the product–process matrix: (1) customer requirements relate to product characteristics; (2) products are developed using process elements; (3) development process is using people related process elements; (4) development process is using practices related process elements; (5) development process is using architecture related process elements; and (6) process elements relate to outcomes. We further refined the development process category using software development reference models, such as the CMM™ to help identify people-related, practices-related, and architecture-related concepts. We also referenced the ISO standard for software quality (ISO 9126) to help identify outcomes concepts. Then, we analyzed the interview transcripts to surface the detailed concepts within each category or subcategory. For example, team role diversity and scalability emerged as concepts from the interview transcripts in response to questions on peoplerelated process choices and on outcomes, respectively. Team role diversity refers to the number of different roles on an Internet application development team. Scalability indicates whether the Internet application architecture can be scaled for high volume usage.12 In the following sections, we present and discuss concept maps for two groups of business units: those using a highly customized Internet application development process and those using a more standard process (groups #1 and #3 in Figure 1, respectively). We also provide examples of business units that are using each of these development processes. Finally, we present and discuss an overall concept map that illustrates the general concepts and associations between product and process alignment in Internet application development. Concept Map for the Highly Customized Development Process Figure 3 depicts the concept map for a highly customized Internet application development process that is used by

12

A brief explanation and example of each concept identified in the concept mapping analysis are documented in Appendix C.

business units pursuing a differentiation strategy. This concept map is exemplified by Predict. Predict targets a small set of utility customers who have unique and particular requirements. Each utility transmits historical data on energy consumption patterns, and Predict develops a customized, business-to-business Internet-based application for each utility to forecast future consumption patterns. Because the data and requirements are quite different for each utility, Predict must develop a different application for each utility, often using a different development process. We have about 150 utility customers. The companies each send us their energy consumption data. And, we provide them with an analysis and prediction of future energy needs. But, the data feeds in and out are unstable....we are dealing with each customer’s antiquated legacy systems....If we ever had something that worked the same way twice —that would be stability. We have about 150 different development processes (Senior Manager, Predict). There is a reliance on gurus because to serve customers in Predict’s unique market niche requires specialized knowledge of the particular utility and the utility’s data and systems as well as complex skill sets including advanced statistics and financial engineering. The development process also requires the use of small teams of specialists. The use of gurus makes it difficult to transfer knowledge, and the learning curve for new employees is steep and long. There is almost no reuse of software code; in fact Predict uses redundant coders (i.e., two developers independently code each application for each customer). This is done to minimize errors and bias in the consumption prediction models developed. The software code is discarded if there are mistakes or problems. We throw away and re-build for each customer. We’re very adaptive, which is stressful on employees who don’t adapt” (Senior Manager, Predict). Prototyping is used to understand user requirements. Custom architecture design, limited reuse of design artifacts, and little legacy integration also characterize this mode of development. Concept Map for the Highly Standardized Development Process Figure 4 shows the concept map for the more standardized Internet application development process that is used by business units pursuing a cost leadership strategy. Utility typifies this concept map. Utility uses the Internet to organize customers into large buying pools and facilitate low-cost pur-


903


customers have are

heterogeneous requirements

few

relate to relates to

high variety of product features are developed using

tailored development process is using

is using

is using

people

practices

architecture is

work on

small teams

are

are

are

gurus

prototyping

many phases

little reuse relates to

little code reuse

relate to relate to

relates to

outcomes

relates to relate to

relates to

outcomes

outcomes

are

are

high flexibility

are

long learning curves

are

are

are

long cycle time

are

has

custom designed

are

poor scalability

low formality

are

little legacy integration

low pervasiveness little knowledge transfer

Figure 3. Concept Map of Highly Tailored Development Process

chase of services such as electricity, natural gas, home security, and health insurance. There are sufficient standard features across the buying pools that the business unit can standardize its Internet applications and reuse software across the different market segments. We are always making generalizations across the vertical markets even though there are different products, different markets, and different interfaces. The whole reuse perspective goes across the verticals….We retrofit good features, repeating one across the others…our development strategy is to standardize and reuse software across vertical markets (Manager, Utility).

904


The commonalities amongst its customers and products enable Utility to use a standard development process, and in fact, the unit leverages the traditional, sequential waterfall approach to software development, albeit at “Internet speed.” We use the “staircase” method to develop. Internet speed development is very similar to traditional development—we still need to gather requirements, there’s a life cycle. But, the response time is much quicker. The process is like a “quick waterfall” (Project Manager, Utility). Because the software features and processes are more standard and can be reused across market segments, there is less need for specialized knowledge, and less reliance on gurus.


customers have

are

homogeneous requirements

many increase need for

relate to

low variety of product features

relates to may require

easy customization

are developed using

standard development process is using

people

architecture

practices

are

has

are have

generalists

is using

is using

waterfall

few roles

are are

relate to

outcomes

relates to relate to

relates to

outcomes

outcomes

are

are

low flexibility

are

short learning curves

are

are

are

short cycle time

high reuse relates to

COTS use

relates to

has

modular design few phases

code reuse relates to

relate to

are

are

high scalability

robustness

high formality are

are

are

high portability

high pervasiveness high knowledge transfer & reuse

some legacy integration

Figure 4. Concept Map of Highly Standardized Development Process

Some wear multiple hats. Project leaders could be from technology, business or operations, and there isn’t always someone tagged as the “leader” (Project Manager, Utility). The software architecture plays a critical role in standardizing and reusing applications across market segments. We have designed a three tier architecture (presentation layer, application layer, database layer). The objective is to make an open, modular and scalable architecture. Because there is a vision, it allows us to create good technologies that are scalable. We can easily ratchet up or down in the scale (Manager, Utility).

Short cycle times, and high scalability, robustness, and portability also characterize this mode of development.

Concept Map for Product–Process Alignment We further abstracted the elements in the concept maps to create a more general concept map of product and process alignment in Internet application development. As shown in Figure 5, the level of requirements diversity relates to the variety of product features, and together with the volume of demand for requirements influences the type of development process selected.


905


customers have

have

requirements diversity

requirements demand

relates to

variety of product features

relates to

are developed using

type of development process is using

people

are

have

methodology type

are on

has

team size relates to

# & sequence of phases

are

extent of COTS use

relates to

relates to

has

are

are

extent of code reuse

role diversity

relates to

relate to

flexibility

relates to relates to

are

are

are are

formality

cycle time

are

scalability

are

are

extent of reuse

outcomes

outcomes

outcomes

design type

relates to

relates to

length of learning curve

architecture

practices

have

type of expertise

is using

is using

are

robustness are

are

portability

pervasiveness extent of knowledge transfer & reuse

extent of legacy integration

Figure 5. Concept Map of Product–Process Alignment

The process choices relate to the people, practices, and architecture used in development. The type of expertise on a team (specialists versus generalists) is influenced by the variety and scale of use of product features. When customer requirements are more standard or can be generalized, less specialized knowledge is required as developers can follow the standard design and can reuse existing code. Thus, teams of generalists can be used. In contrast, when customer requirements are highly differentiated, more specialized knowledge is required, and there is more reliance on gurus. Similarly, the practices followed are also shaped by these factors. When product features are standardized, software can be readily

906


reused across products, but when product features are customized, there may not be sufficient commonalities to enable code reuse. Prototyping (not a standard waterfall process) may be needed to discover customers’ unique needs. Finally, when customer requirements can be generalized across markets or products, a modular architecture can be designed to be robust, scalable, and portable. Process characteristics further define associated outcomes. The extent of knowledge transfer and reuse relates to people-related practices such as the use of specialists or generalists, and team role diversity and size. Similarly, the length of the learning curve is associated with the same choices (e.g., the more


specialized the knowledge requirements and skill sets, the longer the learning curve for new hires). For the development process, the flexibility, formality, pervasiveness, and cycle time of the process are associated with the type of development methodology, the number and sequence of phases, reuse of software code, and use of off-the-shelf components and tools. For example, code reuse and parallel development facilitate short cycle times. Finally, the portability, scalability, and robustness of the architecture relate to specific practices such as use of modular architecture frameworks and tools, and design reuse.

Business Units Out of Alignment While many business units in our study are “in alignment,” three are “out of alignment.” To determine precisely why these units are misaligned is beyond the scope of this study. Nevertheless, we can draw upon the literatures motivating this study to suggest why the units may be misaligned. According to Porter (1980), when a business unit tries to be both a cost leader and a differentiator in the same market or when a business unit switches between these strategies over time, it can become “stuck in the middle.” The basic strategies are incompatible because cost leadership focuses on cost advantages of production (being the low cost producer for a given level of quality) while differentiation focuses on satisfying unique customer needs and de-emphasizing price (often generating a higher than average price). Since successfully executing each of the basic strategies involves different resources, strengths, organizational arrangements, and managerial styles, it is unlikely that a business unit can realize both strategies. Even if a business unit can achieve both strategies in the same market, it risks projecting a confusing image to the customer and can fail to attain the benefits from either. Being stuck in the middle may describe, in part, what is happening at Index. Founded by computer scientists, the firm’s focus historically was on technological product innovation. In the past, the firm’s business unit was a differentiator and used highly tailored development processes, customizing its products to the unique needs of a few major customers. However, since Index has started offering its products on the Internet, there has been pressure to shift its strategy to appeal to a broader range of customers in new markets and bring in greater revenues. This shift has generated some confusion in the unit’s strategic direction. We said we needed to be present on the Internet. From then on we have changed the focus on customers, markets, and what products we are selling.

Lately there is more churn, changing focus of products, the market we want to be in (Manager, Index). The changes in Index’s business unit strategy are not fully reflected in its software product and development process strategies. The radial graph for Index in Figure 2 shows that although the business unit strategy reflects an intermediate level of differentiation as the firm tries to commoditize its products, the product and development process strategies continue to reflect high levels of customization. We provide everything from turnkey solutions to custom solutions. Customers can give us a crate of "X" and say, do whatever you have to with this. Or we may be asked to put together a complete configuration that the customers can use with their own content. Other customers are in between. There are also variations in the types of products and services (Manager, Index). The product–process literature also suggests why business units can be misaligned. According to Hayes and Wheelwright (1979a, 1984) the product–process matrix reflects the alignment (or misalignment) of a firm’s competitive priorities, products, and processes at a point in time. Thus, a misaligned business unit may be in transition. However, Hayes and Wheelwright assert that being in transition should be temporary. Business units that are misaligned are less efficient and effective because marketing and production are pursuing different objectives, and the unit cannot leverage economies of scale. Alignment (being “on the diagonal”) should thus be the steady-state condition. So, why do business units move “on” or “off” the diagonal of the matrix? Hayes and Wheelwright (1979a) offer an organizational learning explanation that relates to the theories of March (1991). March developed the concept of balancing exploration and exploitation as strategies for organizational learning. Exploration involves searching, experimentation, developing variation, taking risks, and discovering new knowledge. Exploration strategies develop variation, and the returns are usually uncertain. In contrast, exploitation involves selection, refinement, production, and efficiency. Exploitation strategies refine existing knowledge, and the returns are usually certain. In the product–process matrix, business units that move down (but on) the diagonal are leveraging both exploration-based and exploitation-based learning in a balanced way within their existing markets. The units are exploiting the learning curve to become more efficient in their processes, but are maintaining some flexibility to respond to market changes, and are also innovating their products.


907


Business units that innovate the product more than the process (are above the diagonal) can follow dynamic market movements quickly, but at the cost of reduced process efficiency. One issue here is that a unit can get trapped if it tries to innovate existing products to appeal to new markets. At first this strategy may work, but eventually the unit’s existing process will not be able to accommodate the added scale and complexity of new products without additional investment. The unit may then have to innovate the process, but to recoup the investment it has to pursue additional markets, and this requires more product innovation, and starts the cycle all over again. This may also describe what is happening at Index. Despite pressures for commoditization, the business unit’s products have not matured into a commodity that appeals to a large enough number of customers. We tried to have one product for all segments... but when they see the product, the customers came back and said, “this is cool but we like this other feature too.” And then we get extra requirements for features. It is hard to say no to customers (Manager, Index). Thus, the unit cannot adopt a more standardized process because there are too few similarities among the features of the various products. As a result, Index devotes resources to innovate the product, searching for a variation that will appeal to a large enough customer volume to begin exploiting the product and standardize a process to compete in a moderately differentiated marketplace. A related but somewhat different phenomenon may be driving misalignment at Deliver. Deliver is a brick and mortar company with a cost leadership strategy in the business unit that is implementing a web-based interface for its standard applications. In the jargon of the product–process matrix, the company is expanding the scope of its process through forward integration by connecting its applications directly to its customers via the Internet. One potential issue is that expanding process scope can result in producing a product that is not consistent with existing product lines and processes in other business units. Our business strategy is not clearly aligned with our application development strategy. For example, we may develop an application which may end up cannibalizing market share from another product (Manager, Deliver). The business unit uses a more ad hoc process than has been used in the past for software development, and this process is misaligned with the business unit’s cost leadership strategy as shown in Figure 2. A particular problem for Deliver is the

908


lack of a coherent, standard and modular architecture for its Internet applications. There is no end-to-end view of the system and no time for thinking through the architecture. It’s really messy and it doesn’t scale up. The architecture is changing constantly—it is very fluid and dynamic (Architect, Deliver). Instead, developers rely on wrappers (“glue code”) to link together disparate software components in an ad hoc fashion. This process contributes to a lack of portability and scalability in the architecture, critical concerns given Deliver’s large volume of customers. Business units that innovate the process more than the product (are below the diagonal) push the process toward standardization and can realize the fastest learning rates by exploiting process efficiencies. However, the process can become inflexible and difficult to modify. This may explain why Telecom is out of alignment. As shown in Figure 2, Telecom is misaligned because its standardized process does not fit with its business unit strategy. This misalignment may be ascribed, at least in part, to the fact that Internet application development was outsourced from Telecom. To leverage economies of scale across engagements, outsourcing vendors often use a standard methodology (Levina and Ross 2003). The outsourcing vendor for Telecom also attempted to implement a standard methodology. However, because Telecom is a major client, the vendor created a separate business unit for Telecom’s IT projects, and that unit was working in a specialized industry with somewhat unique needs. The unit’s developers were struggling to use the standard development process for new Internet applications. The technology is so visual, it is easy for end users to picture what they want. But, each person wants something different…so, even though we have an overall methodology, it can be difficult to standardize processes (Relationship Manager, Telecom). In an example of adaptive exploitation, the developers tailored the standard methodology and adopted a more flexible assembly approach, decoupling the standard processes, using parallel development, and reusing standard architecture frameworks and designs where appropriate.

Concluding Remarks This study addresses an important issue for businesses in the 21st century: how should work processes that create knowl-


edge products be aligned with business strategies in a competitive environment transformed by new technologies. This issue is particularly salient in software development because software is a valuable and well-defined example of a knowledge product. Software development can test and challenge the general theories derived from the experience of making physical products. Indeed, there is a long tradition of considering software development from the perspective of manufacturing (e.g., TQM and CMM, software factories, component-based development) and of applying theories and frameworks (like the product–process matrix) from manufacturing to examine and understand software development issues. A central insight of our study is that, consistent with the product–process matrix, software process does depend on how a firm competes, and especially on competitive choices relating to product variety. The variety of product requirements may be crucial in determining the type of software processes that can be deployed. Business units in the firms we studied such as Predict (with its 150 different development processes) and Index (with its struggles to commoditize its product) clearly reflect the challenges encountered in achieving consistent development processes when the applications developed are highly customized. This suggests a tension between the costs and benefits of software customization. On the one hand, customizing a software product can attract new customers and can distinguish a firm from its competitors. On the other hand, it may be more costly to customize than to standardize. One may question whether these cost differences are as significant for software development. Software is intangible and more easily adapted than a physical product. Also, software processes may be more adaptable than manufacturing processes bound by machinery, raw materials, and physical plants. Finally, technologies such as agile methods and modular architectures may make it less costly to customize and adapt development processes. Nevertheless, two firms in our study chose to standardize their development processes and Internet applications (Utility and Insure). One firm (Index) aspired to standardize its Internet applications, and another (Telecom) tried to leverage the corporate standard development methodology even if it was not best suited to a particular engagement. This implies that customizing products and processes is not “free” in software development. An important direction for future research is to examine the economics of software customization, and particularly over the software life cycle, as the costs of supporting highly customized applications may be even more significant than the development costs. Our study contributes to the IS literature by offering detailed configurations of software development processes that can be

aligned with certain types of business unit strategies, supported by empirical evidence from case studies. The IS strategy literature has examined alignment at a more macro level. However, given the many choices for software development and the notion that “one size may not fit all” projects (Shenhar 2001), it is important to examine alignment decisions at a more micro or operational level. But, like any empirical study, ours has some limitations. We have focused on whether and how firms align their business unit strategies, software applications and development processes. This enabled us to provide detailed insights into the ways in which different dimensions are matched. However, our crosssectional research design did not allow us to examine why business units are misaligned and the consequences. Future studies should investigate alignment decisions over time as markets, products, and processes mature. In addition, research is needed to discern the performance consequences of alignment or misalignment. Finally, we have studied alignment in Internet application development contexts. This focused research design constitutes a control in our study; however, our findings may be limited to Internet application development. It is possible that our results could generalize to other software development contexts, especially where the applications developed are tightly linked to the customer and are part of the bundle offered to the customer. No single study is definitive; thus, the external validity of our results can be strengthened by future research on alignment between software development and business strategies in other application domains and development contexts.

Acknowledgments We thank the Software Industry Center at Carnegie Mellon University for providing financial support for this project. We gratefully acknowledge Uma Mutharason and Jeff Roberts at Carnegie Mellon University for their assistance with the data coding described in this paper. The authors are also grateful to the senior editor, associate editor, and reviewers who provided helpful comments and suggestions on earlier versions of this manuscript.

References Ahmad, S., and Schroeder, R. “Refining the Product–Process Matrix,” International Journal of Operations and Production Management (22:1), 2002, pp. 103-124. Aranda, D. “Relationship Between Operations Strategy and Size in Engineering Consulting Firms,” International Journal of Service Industry Management (13:3-4), 2002, pp. 263-285. Armstrong, D. “Causal Mapping: A Discussion and Demonstration,” Chapter 2 in Causal Mapping for Research in Information Technology, V. Narayanan and D. Armstrong (eds.), Idea Group Publishing, Hershey, PA, 2005, pp. 20-45.


909


Banker, R., Datar, S., and Kemerer, C. ”A Model to Evaluate Variables Impacting the Productivity of Software Maintenance Projects,” Management Science (37:1), 1991, pp. 1-18. Banker, R., Davis, G., and Slaughter, S. ”Software Development Practices, Software Complexity and Software Maintenance Performance,” Management Science (44:4), 1998, pp. 433-450. Brooks, F. The Mythical Man Month (Anniversary ed.), PrenticeHall, Reading, MA, 1995. Brown, S., and Blackmon, K. “Aligning Manufacturing Strategy and Business-Level Competitive Strategy in New Competitive Environments,” Journal of Management Studies (42:4), 2005, pp. 793-815. Calinski, T., and Harabasz, J. “A Dendrite Method for Cluster Analysis,” Communications in Statistics (3), 1974, pp. 1-27. Cameron, J. “Configurable Development Processes,” Communications of the ACM (45:3), 2002, pp. 72-77. Conallen, J. Building Web Applications with UML, AddisonWesley, Boston, MA, 2000. Daley, B. “Using Concept Maps in Qualitative Research,” in Proceedings of the First International Conference on Concept Mapping, A. Cañas, J. Novak, and F. González (eds.), Universidad Pública de Navarra, Spain, September 14-17, 2004, pp. 191-197. Deck, M. “Managing Process Diversity While Improving Your Practices,” IEEE Software, May-June, 2001, pp. 21-27. Dubé, L., and Paré, G. “Rigor in Information Systems Positivist Case Research: Current Practices, Trends, and Recommendations,” MIS Quarterly (27:4), 2003, pp. 597-635. Eden, C., and Ackermann, F. Making Strategy: The Journey of Strategic Management, Sage Publications, Thousand Oaks, CA, 1998. Eisenhardt, K. “Building Theories from Case Study Research,” Academy of Management Review (14:4), 1989, pp. 532-550. Farjoun, M. “Towards an Organic Perspective on Strategy,” Strategic Management Journal (23:7), 2002, pp. 561-594. Fitzgerald, B., Russo, N., and O’Kane, T. “Software Development Method Tailoring at Motorola,” Communications of the ACM (46:4), 2003, pp. 65-70. Grover, V., and Malhotra, M. “A Framework for Examining the Interface between Operations and Information Systems,” Decision Sciences (30:4), Fall 1999, pp. 901-920. Hayes, R., and Wheelwright, S. “The Dynamics of Process-Product Life Cycles,” Harvard Business Review (57:2), 1979a, pp. 127-136. Hayes, R., and Wheelwright, S. “Link Manufacturing Process and Product Life Cycles,” Harvard Business Review (57:1), 1979b, pp. 133-140. Hayes, R., and Wheelwright, S. Restoring our Competitive Edge: Competing through Manufacturing, Wiley, New York, 1984. Heim, G., and Sinha, K. “A Product–Process Matrix for Electronic B2C Operations: Implications for the Delivery of Customer Value,” Journal of Service Research (3:4), 2001, pp. 286-299. Heim, G., and Sinha, K. “Service Process Configurations in Electronic Retailing,” Production and Operations Management (11:1), 2002, pp. 54-74. Hill, T. Manufacturing Strategy, MacMillan, New York, 2001.

910


Huete, L., and Roth, A. “The Industrialization and Span of Retail Banks’ Delivery Systems,” International Journal of Operations and Production Management (8:3), 1988, pp. 46-86. Jacobs, D. “Enterprise Software as Service,” Queue, July/August, 2005, pp. 36-42. Kathuria, R., Anandarajan, M., and Igbaria, M. “Linking IT Applications with Manufacturing Strategy,” Decision Sciences (30:4), 1999, pp. 959-991. Kemerer, C. ”How the Learning Curve Affects Case Tool Adoption,” IEEE Software (9:3), 1992, pp. 23-28. Kotha, S., and Orne, D. “Generic Manufacturing Strategies: A Conceptual Synthesis,” Strategic Management Journal (10:3), 1989, pp. 211-231. Krajewski, L., and Ritzman, L. Operations Management (7th ed.), Prentice-Hall, Englewood Cliffs, NJ, 2005. Kriebel, C., and Raviv, A. ”An Economics Approach to Modeling the Productivity of Computer Systems,” Management Science (26:3), 1980, pp. 297-311. Lee, A. “Case Studies as Natural Experiments,” Human Relations (42:2), 1989a, pp. 117-137. Lee, A. “A Scientific Methodology for MIS Case Studies,” MIS Quarterly (13:1), 1989b, pp. 33-50. Levina, N., and Ross, J. “From the Vendor’s Perspective: Exploring the Value Proposition in IT Outsourcing,” MIS Quarterly (27:3), 2003, pp. 331-364. March, J. “Exploration and Exploitation in Organizational Learning,” Organization Science (2:1), 1991, pp. 71-87. McLachlan, G. Discriminant Analysis and Statistical Pattern Recognition, Wiley-Interscience, New York, 2004. Miles, M., and Huberman, A. Qualitative Data Analysis: An Expanded Sourcebook (nd ed.), Sage Publications, Beverly Hills, CA, 1984. Miles, R., and Snow, C. Organizational Strategy, Structure, and Process, McGraw-Hill, New York, 1978. Mintzberg, H., Ahlstrand, B., and Lampel, J. Strategy Safari: A Guided Tour Through the Wilds of Strategic Management, Prentice Hall, London, 1998. Nidumolu, S., and Knotts, G. “Effects of Customizability and Reusability on Perceived Process and Competitive Performance of Software Firms,” MIS Quarterly (22:2), 1998, pp. 105-137. Novak, J. Learning, Creating and Using Knowledge: Concept Maps™ as Facilitative Tools in Schools and Corporations, Lawrence Erlbaum Associates, Mahwah, NJ, 1998. Panzar, J., and Willig, R. “Economies of Scale in Multi-output Production,” Quarterly Journal of Economics (91), 1977, pp. 481-493. Panzar, J., and Willig, R. “Economies of Scope,” American Economic Review (71:2), 1981, pp. 268-272. Paulk, M., Curtis, B., Chrissis, M., and Weber, C. “Capability Maturity Model, Version 1.1,” IEEE Software (10:4), 1993, pp. 18-27. Porra, J. “Electronic Commerce Internet Strategies and Business Models,” Information Systems Frontiers (1:4), 2000, pp. 389-399. Porter, M. Competitive Strategy: Techniques for Analyzing Industries and Competitors, Free Press, New York, 1980.


Porter, M. “Strategy and the Internet,” Harvard Business Review (79:3), 2001, pp. 63-78. Porter, M. “What Is Strategy?” Harvard Business Review (74:6), 1996, pp. 61-78. Porter, M., and Millar, V. “How Information Gives You Competitive Advantage,” Harvard Business Review (63:4), 1985, pp. 149-160. Pralahad, C., and Hamel, G. “The Core Competence of the Corporation,” Harvard Business Review (68:3), 1990, pp. 79-91. Sabherwal, R., and Chan, Y. “Alignment between Business and IS Strategies: A Study of Prospectors, Analyzers, and Defenders,” Information Systems Research (12:1), 2001, pp. 11-33. Sabherwal, R., Hirschheim, R., and Goles, T. “The Dynamics of Alignment: Insight From a Punctuated Equilibrium Model,” in Strategic Information Management (3rd ed.), R. Galliers and D. Leidner (eds.), Butterworth Heinemann, Amsterdam, 2003, pp. 311-346. Sacks, M. On-the-Job Learning in the Software Industry, Quorum Books, Westport, CT, 1994. Safizadeh, M., Ritzman, L., Sharma, D., and Wood, C. “An Empirical Analysis of the Product–Process Matrix,” Management Science (42:11), 1996, pp. 1576-1591. Shapiro, C., and Varian, H. Information Rules: A Strategic Guide to the Network Economy, Harvard Business School Press, Boston, 1999. Shenhar, A. “One Size Does Not Fit All Projects: Exploring Classical Contingency Domains,” Management Science (47:3), 2001, pp. 394-414. Slaughter, S., Harter, D., and Krishnan, M. “Evaluating the Cost of Software Quality,” Communications of the ACM (41:8), 1998, pp. 67-73. Tapscott, D. “Rethinking Strategy in a Networked World (or Why Michael Porter Is Wrong About the Internet),” Strategy+Business, Third Quarter, 2001 (available online at http://www.strategy-business.com). Tapscott, D., Ticoll, D., and Lowy, A. Digital Capital: Harnessing the Power of Business Webs, Harvard Business School Press, Boston, 2000. Tashakkori, A., and Teddlie, C. Mixed Methodology: Combining Qualitative and Quantitative Approaches, Sage Publications, Thousand Oaks, CA, 1998. Teece, D., Pisano, G., and Shuen, A. “Dynamic Capabilities and Strategic Management,” Strategic Management Journal (18:7), 1997, pp. 509-533. Tregoe, B., and Zimmerman, J. Top Management Strategy: What it Is and How to Make it Work, Simon and Schuster, New York, 1983. Varian, H. Intermediate Microeconomics: A Modern Approach (6th ed.), W. W. Norton & Company, New York, 2002. Venkatraman, N. “Five Steps to a dot.com Strategy: How to Find your Footing on the Web,” Sloan Management Review (41:3), 2000, pp. 15-28. Wade, M., and Hulland, M. “The Resource-Based View and Information Systems Research: Review, Extension, and Suggestions for Future Research,” MIS Quarterly (28:1), 2004, pp. 107-142.

Ward, J., and Griffiths, P. Strategic Planning for Information Systems, Wiley, New York, 1996. Weill, P., and Broadbent, M. Leveraging the New Infrastructure: How Market Leaders Capitalize on Information Technology, Harvard Business School Press, Boston, 1998. Wheelwright, S. “Manufacturing Strategy: Defining the Missing Link,” Strategic Management Journal (5:1), 1984, pp. 77-91. Yin, R. Case Study Research: Design and Methods (2nd ed.), Sage Publications, Thousand Oaks, CA, 1994.

About the 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 a professor of Computer Information Systems at Georgia State University. His research work has appeared in several leading conferences and journals including IEEE Transactions on Software Engineering, JAIS, Annals of Software Engineering, Communications of the ACM, IEEE Computer, IEEE Software, IEEE Internet Computing, IEEE Intelligent Systems, and 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.


911


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 including Annals of Software Engineering, Journal of Accounting Management and Information Technology, The Data Base for Advances in Information Systems, and European Journal of Information Systems. He is the Danish national representative to IFIP Technical Committee 8 (TC 8) on Information Systems, and has served as Secretary for TC 8 since 1999. He is a member of ACM, IEEE, and the Danish Computer Society.

Richard L. Baskerville is a 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.

Appendix A Interviews Each firm was the object of a detailed case study involving a visit to the firm’s business unit in which Internet application development was conducted. Key informants included senior managers (such as CEOs, CIOs, and vice presidents of major functional units like Finance and Marketing), product managers, project managers, Internet application developers, and quality assurance specialists. The informants were carefully selected to provide the best source of information; thus, we directed questions concerning business unit strategy, products, and customers to senior managers, and questions concerning Internet application development processes to project managers, developers, and quality assurance specialists. The interview protocol is shown in Table A1. Questions were chosen to elicit information about the different dimensions of strategy–product– process alignment (e.g., business unit strategy, customer, product, and process) and to obtain background information about each business unit and interviewee. In every firm’s business unit, we interviewed several managers and several technical specialists. We also supplemented interview data with secondary data collected from the firms’ web sites, annual reports, and articles in the press. Using multiple sources of evidence is a key tactic to increase construct validity in case studies and helps mitigate the potential for bias (Yin 1994). For example, a manager’s description of the firm’s business unit strategy could be compared with the description of the strategy on the firm’s web site or in the annual report. We did not find discrepancies between the interviewees’ statements and the secondary data; nor did we find discrepancies in the statements of different interviewees at each firm. Interviews with each informant were typically about 2 hours in length, and site visits usually lasted at least 4 hours. The interviews were conducted by two or three researchers on the team; one researcher concentrated on interviewing while the other(s) took short notes using laptop computers. Immediately after the interviews, the notes were written out in full text, and transcripts were integrated and reviewed by all of the researchers conducting the interview. As noted by Eisenhardt (1989), having multiple investigators is an advantage in a case study because their different perspectives and insights add objectivity and enhance the potential for creative and novel contributions. A total of 45 informants across all of the firms’ business units were interviewed. The transcripts from the interviews with informants in each business unit resulted in about 6 to 8 single-spaced pages of text, yielding more than 100 pages of single-spaced text for all interviews.

912



Table A1. Interview Protocol 1. Organizational Demographics • organization structure? layers of management? organization chart? • how created? business unit created as part of a larger organization? • how staffed? current staffing level? target level? turnover rate? staff moved here? • backgrounds of staff (new to industry versus experienced people)? • concerns about growth? about downsizing? • recent restructuring? 2. Interviewee Demographics • background (education and experience)? • current role? other roles at this organization? at other organizations? 3. Product, Business Unit Strategy and Customer Related Issues • what Internet software products/services produced? • individual products or clearly identified product lines or families? • main focus or function of the products? • maintaining existing products? building new? • most important quality dimensions for your Internet products/services and processes? • difference in customer demands for quality? • any relationship between product quality and product maturity? • common product architecture or design? is it adequate? • how much design and architectural work do you do? is it sufficient? • use components off-the-shelf or parts developed by others vendors? or do development in house? • how do you introduce new software applications for the Internet? 4. Process Related Issues (Practices and Architecture) • life cycle phase? development method different for front-end and back-end applications? • are you using any lite or agile methods? (e.g., XP or Scrum) • traditional principles working? new practices? • do you tailor processes? how? what do you take into account? • outsourcing? • incremental development? gradually evolved or maintained? • how do you develop scaleable systems? • is maintaining Internet products different? concerns about modification? • how do you integrate your systems with legacy systems? (e.g., interfaces between existing systems) • strategy for integrating components? critical issues in integrating these components and maintaining them? • how do you manage interdependencies between projects, products and people? • are people working on multiple projects simultaneously? • officially sanctioned methodologies, environment, platform or tools? • security standards that protect your systems? how are they implemented in your development? • solutions or patterns that work for you? noticeable constraints? • QA processes used for Internet development? 5. Process Related Issues (People) • staffing a typical project? size? mix of skills? type of person hired? • what roles? do people play the same roles from project to project (experts)? • where are team members located? colocation? • coordination mechanisms and tools? integration mechanisms and tools? • how is knowledge transferred? mechanisms, tools? • how do you capture knowledge? where does it come from? training? education, experience? • how do you manage teams that grow? that shrink? • anything unique about physical environment (building, workspace)?


913


Appendix B Coding We have drawn upon the positioning school of strategy, and Porter’s model of strategy in particular in conceptualizing and coding business unit strategy. 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 school is consistent with our view that managers analyze the environment and make rational decisions to enhance outcomes. Other strategy schools such as the learning or power schools are more descriptive, and consider strategy as more emergent or negotiable, and thus are not as well suited to our objectives. Miles and Snow (1978) offer typologies that match firms’ competitive strategies to the rate of change in the external environment. However, these typologies were not designed to align strategy and operational processes and do not provide guidance on what kinds of processes are best suited to different strategy types. Prahalad and Hamel’s (1990) core competency theory, the resource-based view of strategy (reviewed in Wade and Hulland 2004), and the dynamic capabilities approach (Teece et al. 1997) emphasize the importance of capabilities for strategic advantage; however, these theories do not provide guidance into what types of capabilities best suit particular strategies. Porter’s model of strategy has the most direct implications for arrangements of operational activities in firms’ business units. Table B1 shows the coding rules for business unit strategy and provides examples of a cost leadership strategy and a differentiation strategy from Porter’s model of strategy. In coding each firm’s business unit strategy, we considered that a strategy is often not a simple, onedimensional definition of its direction but rather may be laced with inconsistencies and disintegrative aspects that can be unworkable in practice. This complexity is embodied in the distinction between the stated or espoused strategy pronounced explicitly by management and the working strategy or strategy-in-use that emerges to drive decisions and actions (Mintzberg et al. 1998). The espoused strategy is the declared strategy to which the firms’ actors appeal in order to explain their actions while the strategy-in-use is more implicit and can be detected by studying the decisions and actions of the firm’s members (Tregoe and Zimmerman 1983). In our coding, we were aware of the potential for differences in the firm’s stated versus actual business unit strategies, and therefore considered multiple kinds of information (interview transcripts from multiple informants, annual reports, web sites, press releases, etc.) to help us identify and corroborate the actual strategies-in-use executed by the firms’ business units for their Internet-based products. Although our focus was each firm’s Internet application development unit, we did not discern differences in the Internet application development business unit strategies and the firms’ overall corporate strategies An independent coder reviewed the interview transcripts and documentation for the business unit of each firm in our study and rated each unit’s strategy-in-use as either cost leadership or differentiation based upon the characterizations of these strategy types and the descriptions of what the firm’s Internet application development business unit was actually doing. To help validate the coding, the coder also evaluated information about each business unit’s major competitors, and coded the competitors’ strategies to determine whether the unit’s positioning vis à vis its competitors agreed with the coded strategy. For example, if a firm’s business unit described actions taken to follow a cost leadership strategy, the competitors’ strategic positioning was considered relative to the unit’s to see whether the unit was truly pursuing cost leadership. As a final check of the coding, the first author of this paper also coded each firm’s business unit strategy and compared the coding with that of the independent coder; there was total agreement in the coding. Note that some firms’ business unit strategies reflected neither “pure” cost leadership, nor “pure” differentiation, but somewhere in between. For example, the unit differentiated products across segments of customers rather than across each customer. We classified such a business unit strategy as intermediate between cost leadership and differentiation. Alignment in the product–process matrix allows for intermediate levels of differentiation. Table B2 shows the constructs, coding rules, and examples of coded statements from the transcripts for the coding of the level of product customization and level of process customization. An independent coder and the first author of this paper separately coded the levels of each of these constructs as low, medium, or high for each firm’s business unit, based on the coding rules. Although the coders initially disagreed on 2 of the 18 items coded (there are a total of 18 items coded because 2 constructs— the level of product customization and the level of process customization—are coded for 9 business units), after discussion and reference to the transcripts, the coders mutually agreed upon all of the final coding assignments. Table B3 shows the number of customers who have purchased each business unit’s web-based applications and services. Information on the number of customers was obtained from interview transcripts and/or secondary data about the firm’s business unit (such as annual reports, web sites, or press releases).

914



Table B1. Coding Examples for Business Unit Strategy Strategy Description

Example

Cost Leadership Strategy: the objective is to beat competitors by producing goods or services at the lowest cost. Producing products or services at the lowest cost enables the firm to charge a lower price than its competitors while maintaining similar, if not higher profit margins. Usually, because differentiation of a product or service is costly, the products offered by a cost-leader have a low level of product differentiation. Because of the low differentiation, the costleader’s products do not appeal to specific market segments but rather to the average users across a large customer base.

Utility’s objective is to offer its customers the lowest prices for commodity products and services (such as electricity, natural gas, telephone, home security, gasoline) by forming online buying pools. In order to offer the lowest price, Utility tries to form the largest buying pools possible. Utility also keeps its costs low by reusing service offerings across the different buying pools. The services are not tailored to individual customers. Utility has numerous competitors in the form of the utilities themselves that can directly offer discounted prices to their own customers.

Differentiation Strategy: the goals and objectives are to achieve a competitive advantage by creating a product or service that customers believe to be unique. Usually, a firm that adopts a differentiated strategy is able to charge a premium price for its goods or services. A price higher than industry prices can be charged because the firm is able to satisfy a customer’s needs in a way that its competitors cannot. By charging higher than average prices, the firm can enjoy excess revenues and an advantage over its competitors.

Predict offers a unique service to its customers (major utilities). Each utility sends Predict its own data on its consumers’ historical utility usage. Based on the data for each utility, Predict creates individualized software models and provides unique predictions of usage for each utility’s consumers. Predict charges a premium for model accuracy, and pays a penalty if mistakes are made. At present, Predict has no known competitors.

Table B2. Coding Examples for Product and Process Customization Construct:

Level of Product Customization

Level of Process Customization

Definition

The extent to which a business unit customizes or tailors its Internet application/service bundle to meet the unique needs of different customers.

The extent to which a business unit customizes, tailors or adapts its Internet application development process.

Coding Rules

High : The business unit offers a unique or different Internet application product/service bundle to each customer.

High: The development process is frequently tailored (adapted). The process tailoring may be based on the customer’s needs or environment. The process may be described as “evolving” but it is not clear what is the end result or there is no sense of convergence to a standard solution.

Low: The business unit offers a standard Internet application product/service bundle that has relatively little tailoring of features to different customers.

Low: A standard, similar or consistent development process is used with relatively little adaptation or modification or tailoring.

High: We are an Internet company with a product twist. We have a product that allows you to create a product you can put on the Internet. A lot of companies say: I need these three features, then I will buy. There is no one average customer. We provide everything from turnkey solutions to custom solutions. Customers can give us a crate of “X” and say, do whatever you have to with this. Or we may be asked to put together a complete configuration with hardware/ software that the customers can use with their own content. Other customers are in between. There are also variations in the types of products and services.” {Index}

High: “We haven't decided to focus on any one market. Meaning there is not one master. But we need the money coming in. So we take up work from different markets. However, this gives problems for development. As the customer base increases, support needs increase. Types of markets affect development. Number of customers affects support. A lot of customer requests are in the form of changes or adjustments of existing features and capabilities. We have to fit and adjust our process.” {Index}

Low: “Our product is the web site. Via our web site, we provide a buying pool for electricity choice, natural gas, telephone, home security, wireless, gasoline, health insurance (only to businesses). Product lines could be the different vertical markets we're in (electric, gas, water, etc.). A reuse perspective goes across the verticals. We retrofit good features, repeating one across the others.” {Utility}

Low: “Development cycles last from 2 to 15 days. We use the staircase method to develop which allows us to have such short development times. The strategy is to standardize and reuse software across vertical markets. We have a 3 tier architecture (presentation layer, application layer, database layer). The objective is to make an open, modular, scalable and generalized architecture.” {Utility}

Some Examples of Coded Statements


915


Table B3. Coding for Customer Volume Firm

Volume of Customers

Coded Statements

Incubate

18

“The existing portfolio includes 18 companies.”

Index

70

“Our customer base is rapidly growing at 70 organizations within the education, corporate, government and healthcare markets...”

Predict

150

“We have about 150 big utility companies - that's our target market.”

HR

1,200

“We have only one database that maintains all the data for all of our 1200 plus clients.”

Telecom

1,200

“The {redacted} system will be in use by 1200 customers.”

Travel

21,100

Utility

357,000

Deliver

1,800,000

Insure

11,000,000

“We serve 21,100 travel agencies and corporate customers.” “We have 357,000 customers.” “ The company delivers packages each business day for 1.8 million shipping customers.” “We have 11 million customers for our insurance products.”

Appendix C Concept Maps Description and Examples Concept maps are tools for organizing and representing events or objects and their interrelationships in a particular domain or context (Novak 1998). Each concept is designated with a label. The relationship between two concepts in a concept map is referred to as a proposition; propositions connect concepts to form a meaningful statement. Relationships between concepts are associative. For example, “trees” and “leaves” are concepts. “Have” expresses an association between trees and leaves, and by connecting the two concepts forms the proposition: “trees have leaves.” In the educational setting, concept maps are used by students to represent or organize their knowledge of a particular topic (Novak 1998). Like causal maps (Armstrong 2005), concept maps can be drawn by individuals to illustrate their cognition or understanding of a domain. Unlike causal maps, there is no notion of causality in a concept map. Another important difference between concept maps and causal maps is that in concept maps, the concepts are represented hierarchically, with the most general and inclusive concepts at the top, and the more specific, less general concepts arranged hierarchically underneath. In causal maps, the concepts are drawn in a network, with linkages usually flowing from left to right. Daley (2004) suggests that researchers can use concept maps to illustrate many different kinds of qualitative data such as interview transcripts and other documents. In addition, Daley notes that researchers can use concept maps to represent qualitative data at different levels of analysis. For example, a researcher could create a concept map for one research subject based on the transcript from an interview with that subject. Alternatively, a researcher could create a concept map for an entire research site based on transcripts from interviews with employees, company reports, memos, and other documents relevant to that site. The researcher could then use the concept maps for a cross-site analysis. Or, a researcher could create a concept map to represent all of the qualitative data collected in an entire research project. Table C1 shows the detailed concepts from our concept mapping analysis, organized by major concept type for customer, product, processes, and outcomes, and provides a brief explanation and example of each concept from the interview transcripts. Consistent with the literature on concept mapping, we created the concept maps for our study with the broader, more inclusive concepts at the top of the hierarchy, connecting with other, more detailed concepts. Given our goals of evaluating alignment between business unit, product, and process strategies, we deductively identified the main concept categories and their inter-linkages based on the primary dimensions of the product–process matrix: customer requirements – {relate to} – product features – {are developed using} – process choices – {relate to} – outcomes. We then further refined the development process choices concept category using software development reference models, such as the CMM, to identify the people-related, practices-related, and architecture-related concept subcategories. We also drew upon the dimensions defined in the ISO

916



standard for software product quality (ISO 9126) to refine the outcomes concept category into concept subcategories such as portability. Then, we analyzed the interview transcripts to surface the detailed concepts within each concept category or concept subcategory. For example, team role diversity is a concept that emerged from the interview transcripts in response to questions on people-related process choices. Scalability is a concept that emerged from the interview transcripts in response to questions on outcomes.

Table C1. Concepts and Examples for Concept Maps Customer: Requirements-Related Requirements Diversity

The extent to which customer requirements are unique or common: “A lot of companies say: I need these three features, then I will buy. There is no one average customer.” {Index}

Requirements Demand

The level of demand for particular requirements: “We have only one database that maintains all the data for all of our 1200 clients. So updates are to one database, not one for each client.” {ManageHR}

Product: Feature-Related Variety of Product Features

The level of product customization: “The whole reuse perspective goes across the verticals (markets)…. We retrofit good features, repeating one across the others.” {Utility}

Process: People-Related Team Role Diversity

The number of different roles on a team: “The company has defined various roles for people assigned to a project: requirements, design, testing, production support, etc… Each project also has one manager, some consultants and several junior analysts.” {Telecom}

Team Size

The average number of people on a team: “The team is about six people and varied a little bit over time. For most of the development intensive period we had six people.” {Telecom}

Type of Expertise on Team

Whether team members are “specialists” or “generalists”: “People move continuously to different projects and roles. Now tools make it easy to do multiple roles and there’s a blurring of lines for roles.” {Deliver}

Process: Practice-Related Use of Off-the-Shelf Products

Whether off-the-shelf software and/or tools are used to develop the product: “The tools that are available for web development already do a lot of things that we had to develop in the traditional environments, e.g., authentication, encryption, servlets, jsp…” {Telecom}

Phases in Development Cycle

The number of different phases in the development life cycle: “The development method used in our projects has several phases: planning, analysis, design, detailed design, development, formal testing, implementation and Q/A at the end of each phase.” {Telecom}

Methodology Type

What development method(s) is(are) used to develop the product: “We use the staircase method to develop... the process is like a quick waterfall.” {Utility}

Software Reuse

Whether there is any reuse of software code: “Our strategy is to standardize and reuse software across vertical markets.” {Utility}

Parallel Development

Is the product developed sequentially or in parallel: “We have three teams working in parallel: User Interface prototypes, Developers code, Q/A writes test plans.” {HR}

Process: Architecture-Related Design Type

Whether and how the architecture is designed: “We have a 3 tier architecture. Our objective is to make an open, modular and scalable architecture.” {Utility}

Design Reuse

Whether there is any reuse of architecture or design artifacts: “We focus on the ‘glue’ in the architecture blueprint. The higher level process of creating glue is repeatable.” {Incubate}


917


Table C1. Concepts and Examples for Concept Maps (Continued) Outcomes Length of Learning Curve

How long it takes a new hire to become productive: “I’ve been here 9 months and I still feel new. You need to understand the whole before changing anything…that’s a problem with new employees at this company, it seems to take a long time.” {Predict}

Extent of Knowledge Transfer/Reuse

The nature and number of mechanisms for knowledge transfer: “Guru1 and Guru2 are the only knowledge transfer mechanisms. People ask them.” {Index}

Flexibility

Ease with which development process can be adapted: “I believe our process is project dependent. Our processes are dynamic enough to just skip a phase. In a pure content project for example we may skip the architecture phase.” {Deliver}

Formality

Extent to which the development process has been defined and documented: “We have a 3000 page document on how to develop systems.” {Telecom}

Pervasiveness

Extent to which the development process is used by others in the firm: “It is a company wide standard.” {Telecom}. Extent to which the development process is used by others in the firm: “We have a global standard” {Company responsible for outsourcing at Telecom}

Cycle Time

The length of time between product releases on average: ”We release new versions every 2 to 15 days.” {Utility}

Portability

Whether the architecture is portable across platforms, languages, etc.: “We cannot use the last five versions of Java as we need to maintain interoperability with the backend.” {Deliver}

Scalability

Whether the architecture can be scaled for high usage: “We have issues with scalability. The architecture doesn’t scale up. It’s hard to predict the volume.” {Deliver}

Robustness

Whether the architecture is robust or brittle: “Our architecture is very robust in nature which minimizes the downtime of our website. We spend a lot on marketing; having the site down is unacceptable.” {Utility}

Extent of Legacy Integration

Whether the product is integrated with legacy systems: “Everything we do is tied together due to the (legacy) backend we need to work with.” {Deliver}

918
