Aligning Software Processes with Strategy


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Aligning Software Processes with Strategy

  1. 1. Aligning Software Processes with Strategy Sandra A. Slaughter* David A. Tepper School of Business Carnegie Mellon University Tech & Frew Streets Pittsburgh, PA Phone: (412) 268-2308 Fax: (412) 268-7345 Email: Linda Levine Software Engineering Institute Pittsburgh, PA Email: Balasubramaniam Ramesh Georgia State University Atlanta, GA Email: Jan Pries-Heje The IT University of Copenhagen Copenhagen, Denmark Email: Richard Baskerville Georgia State University Atlanta, GA Email: April 15, 2006 * Contact author for this paper. Do not cite, quote, copy or distribute without permission of the authors
  2. 2. Aligning Software Processes with Strategy Acknowledgements We thank the Software Industry Center at Carnegie Mellon University for providing financial support for this project. We gratefully acknowledge the research assistance of Uma Mutharason and Jeff Roberts at Carnegie Mellon University for their assistance with the data coding described in this paper. Biographies of Authors Sandra Slaughter is an Associate Professor in the David A. Tepper School of Business at Carnegie Mellon University. Her research focuses on productivity and quality improvement in the development and maintenance of information systems and on effective management of information technology professionals. She has published articles in leading research journals including Information Systems Research, Management Science, MIS Quarterly, Communications of the ACM, and IEEE Transactions on Software Engineering. She serves as a senior editor for Information Systems Research and Production and Operations Management and serves or has served on the editorial boards of MIS Quarterly, Management Science, Organization Science, Journal of the Association for Information Systems, and the Journal of Database Management. She is a member of the ACM, and is active in ICIS, ICSE, WISE, and the Academy of Management. Linda Levine is a senior member of the technical staff at the Software Engineering Institute. She researches the diffusion of software technologies and change management, knowledge integration and transfer, acquisition of software intensive systems, agile software development and reasoning and communication. Her work has appeared in a wide range of journals such as IEEE Computer, IEEE Software, Information Systems Journal, Michigan Telecommunications and Technology Law Review, Scandinavian Journal of Information Systems, and University of San Francisco Law Review. Levine holds a Ph.D. from Carnegie Mellon University. She is a member of the IEEE Computer Society, Association for Information Systems, National Communication Association, and cofounder and vice chair of IFIP Working Group 8.6 on Diffusion, Transfer and Implementation of Information Technology. Balasubramaniam Ramesh is Professor of Computer Information Systems at Georgia State University. His research work has appeared in several leading conferences and journals including the IEEE Transactions on Software Engineering, JAIS, Annals of Software Engineering, Communications of the ACM, IEEE Computer, IEEE Software, IEEE Internet Computing, IEEE Intelligent Systems, Decision Support Systems. His research interests include supporting complex organizational processes such as requirements management and traceability with decision support systems, knowledge management, data mining and e-services. His work has been funded by several grants from leading government and private industry sources such as the NSF, DARPA, ONR, ARL and Accenture. Jan Pries-Heje is an Associate Professor at The IT University of Copenhagen. His research specializes in organizational and managerial aspects of IT development, such as software process improvement, software engineering, and – most recently – development of internet and Web applications. He has published in these areas in journals like Annals of Software Engineering, Journal of Accounting Management and Information Technology, The Data Base for Advances in Information Systems and the European Journal of Information Systems. He is the Danish national representative to IFIP Technical Committee 8 (TC 8) on Information Systems, and Secretary for TC 8 since 1999. Finally he is a member of the ACM, IEEE and the Danish Computer Society. Richard L. Baskerville is Professor of Information Systems and chairman in the Department of Computer Information Systems, College of Business Administration, Georgia State University. His research specializes in security of information systems, methods of information systems design and development, and the interaction of information systems and organizations. His interests in methods extend to qualitative research methods. Baskerville is the author of many articles in scholarly journals, practitioner magazines, and edited books. His editorial service includes the editorial boards of The Information Systems Journal, MIS Quarterly, and The European Journal of Information Systems. ii
  3. 3. 1 Aligning Software Processes with Strategy 2 3 Abstract 4 5 Although increasing evidence suggests that superior performance requires alignment between 6 firms’ strategies and production processes, it is not known if such alignment is relevant for 7 software development processes. This study breaks new ground by examining how firms align 8 their software processes, products, and strategies in Internet application development. Drawing 9 upon the literatures in strategy, operations management, and information systems, we identify 10 four dimensions that influence alignment – the business unit strategy, the level of product 11 customization, the level of process customization, and the volume of customers. To examine how 12 these dimensions are synchronized, we conducted detailed case studies of Internet application 13 development in nine varied firms including both start-ups and established “brick and mortar” 14 companies. Our analyses reveal that the firms in our study do use differing processes for Internet 15 application development, and that many of the firms match their software process choices to 16 product characteristics, customer volume, and business unit strategies. We develop concept maps 17 for the firms that are in alignment to illustrate how managers configure specific product and 18 process dimensions. We also offer potential explanations for why some firms are misaligned 19 such as: attempting to execute incompatible strategies, the lack of coordination between 20 marketing and production strategies, the too rapid expansion of process scope, and inflexible 21 barriers to rapid adaptation of process. Our study contributes detailed insights into how software 22 processes are customized to complement different types of product requirements and strategies. 23 24 Key Words: Software Process; Product-Process Matrix, Internet Application Development; 25 Software Development Strategy; Competitive Strategy; Contingency Theory. 26 27 ISRL Categories: FAUF, FBUF, FCUF, DA09.
  4. 4. 1 Aligning Software Processes with Strategy 2 3 INTRODUCTION 4 5 In operations management, there is general agreement that sustainable world-class 6 performance requires internal consistency between firms’ strategies and their manufacturing 7 operations (Krajewski and Ritzman 2005). Consistency means that the selection of strategies 8 such as cost leadership or differentiation influences decisions on product priorities (such as cost, 9 time, and quality), and that these priorities in turn guide decisions on production processes (Hill 10 2001). In information systems (IS), there is a notion that a firm’s information technology (IT) 11 strategy should be aligned with its other strategies. For example, value chain analysis (Porter and 12 Millar 1985) aligns information systems to a firm’s primary and secondary activities. More 13 recently, Grover and Malhotra (1999) link IS to manufacturing operations; Weill and Broadbent 14 (1998) show how firms align their IT infrastructure decisions with their strategies; Sabherwal 15 and Chan (2001) examine how the alignment between business and IT strategy impacts firm 16 performance; and Sabherwal et al. (2003) model the alignment between the strategy and 17 structure of the firm and its IT function. While these and other studies have described various 18 components of alignment between firm strategies and IS, the focus of this literature has been 19 more macro, i.e., strategies are aligned to information systems, structure of the IT organization, 20 overall IT strategy, or to IT architecture. To the best of our knowledge, there are few studies that 21 have examined how software development processes are aligned with different strategies. 22 By software development processes, we refer to the activities, methods, practices, and 23 transformations that are used to develop and maintain software (Paulk, et al. 1993, p. 20). 24 Decisions on software development processes include choices relating to team organization and 25 staffing, methodologies, techniques, tools, and architecture. Using one standard approach to 26 software development can be less costly, leverage economies of scale, and simplify project 1
  5. 5. 1 management, knowledge transfer, and performance measurement. However, given the many 2 approaches to software development, it may not always be effective for firms to standardize on 3 one approach for all projects. Indeed, researchers and software development specialists have 4 suggested the potential performance benefits of process customization (Deck 2001). For 5 example, a study of software firms by Nidumolu and Knotts (1998) reveals that the 6 customizability of software development processes can significantly influence competitive 7 performance. Process customization or tailoring involves adapting, particularizing or selecting 8 certain (often standard or “best practice”) software processes to fit the needs of specific 9 organizations or projects. Examples include Motorola, where software development methods are 10 tailored at the industry, organization and project levels (Fitzgerald, et al. 2003) and IBM, where 11 work product descriptions are used to configure a software process to a particular project and 12 make decisions about process sequencing and phasing (Cameron 2002). However, despite the 13 potential benefits of process tailoring, there has been little research that provides insights into 14 how such customizing occurs, in terms of aligning software processes with business strategies. 15 The objective of our study is to fill some of this void by examining whether and how 16 software development processes are fit to strategies. Three levels of strategy can be distinguished 17 in a firm: corporate, business unit, and functional (Kotha and Orne 1989; Wheelwright 1984). 18 We identify firms’ business unit strategies as an important basis for selecting software processes. 19 This basis is consistent with the idea in operations management that strategic and production 20 decisions are interrelated. At the corporate level, managers define the businesses in which the 21 firm operates and allocate resources to those businesses. At the business unit level, managers 22 specify the scope and strategy of each business unit and define how the business unit strategy 23 relates to the corporate strategy. Specifying the business unit strategy requires choosing the 24 product-, market- and service sub-segments to be addressed by the unit. Thus, it is at the business 2
  6. 6. 1 unit that the basis of competitive advantage (cost leadership or product differentiation) is defined 2 (Kotha and Orne 1989, Wheelwright 1984). These choices give the business unit a broader or 3 narrower product line than its principal competitors. Having made those choices, managers must 4 then decide at the functional level whether to produce the product or service with a process that 5 permits a high degree of flexibility but is labor-intensive and usually has relatively higher costs 6 or a process that is more standard and automated with relatively lower costs. A key argument is 7 that process choices must be consistent with business unit strategies for the firm to be productive 8 and effective (Brown and Blackmon 2005; Kotha and Orne 1989; Wheelwright 1984). 9 Strategy, product and process alignment is salient in Internet application development. An 10 Internet application is software that allows its users to execute business logic using a universal, 11 client-server browser architecture (Conallen 2000). Business to consumer Internet applications, 12 such as web-based retailing systems, directly interface with customers and constitute (or directly 13 support) the product or service “bundle” offered to them. Because these Internet applications and 14 their associated services are revenue-generating and must directly satisfy customers’ 15 requirements (Porra 2000), the software and development processes may reflect the nuances of a 16 firm’s business unit strategy. For example, the principal architect of describes 17 how competitive advantage for online businesses relates to Internet application development 18 choices such as resource sharing, multi-tier clustering, and application customization (Jacobs 19 2005). Resource sharing facilitates economies of scale and pay-as-you-go pricing; multi-tier 20 clustering allows an online service provider to more easily scale up and grow the business; and 21 application customization can differentiate the provider from other providers. Other examples are 22 provided by Heim and Sinha (2002) who describe how the web-based retailer Baltimore Coffee 23 and Tea ( supports a “Service Mart” or “assemble to order” strategy by 24 programming dynamic scripts in an Internet shopping cart system to sell more than 1,000 3
  7. 7. 1 varieties of coffee and tea. This is contrasted with a “Service Kiosk” or “make to stock” strategy 2 implemented using static HTML technologies to provide identical experiences to all customers. 3 Thus, we address the following question in this study: are software processes aligned with 4 firms’ business unit strategies in Internet application development, and if so, how? Answering 5 this question increases understanding of how firms develop Internet applications to address 6 specific requirements by relying on different types of software development practices. If the 7 alignment of firms’ business unit, product and process strategies leads to sustained high 8 performance, it is important to understand whether and how this alignment occurs, particularly in 9 the expanding world of Internet application development. We next draw upon the literatures in 10 strategy, operations management, and information systems to identify the dimensions that 11 influence process, product and business unit strategy alignment. 12 THEORETICAL BACKGROUND 13 Strategy and Strategic Positioning 14 There are several schools of thought with respect to strategy (Minzberg, et al. 1998; Eden 15 and Ackermann 1998). Among the various strategy schools, the Positioning school is most 16 consistent with our objective of understanding how firms align their Internet application 17 development processes with their business unit strategies.1 Among the positioning approaches to 18 strategy development, we draw on Porter’s competitive forces model (1980). Other prominent 19 models in this school including the Miles and Snow typologies (1978) or theories that emphasize 20 firms’ capabilities such as the resource-based view (Wade and Hulland 2004), dynamic 21 capabilities approach (Teece, et al. 1997) or core competency theory (Prahalad and Hamel 1990) 22 are less suited to our objectives as none has clear implications for how particular strategies can 1 The Positioning school considers strategy formation as a rational, top-down process where managers position a firm to respond to or take advantage of conditions in the firm’s external environment. It is prescriptive, and considers managers as rational actors making decisions to optimize firms’ outcomes. This is consistent with the view in this paper that managers analyze the environment and make rational decisions to enhance outcomes. Other strategy schools may be more descriptive, and consider strategy as more emergent or negotiable. 4
  8. 8. 1 be matched with particular processes. In contrast, in Porter’s view of strategy, operational 2 activities are the basic units of competitive advantage. According to Porter (1996), strategy 3 involves the creation of a unique and valuable position for a firm, using a distinctive mix of 4 activities: “… the essence of strategy is in the activities – choosing to perform activities 5 differently or to perform different activities than rivals” (p. 64). However, operational 6 effectiveness alone, claims Porter, is insufficient for long-term competitive success. This is 7 especially true in the world of the Internet: “Because the Internet tends to weaken industry 8 profitability without providing proprietary operational advantages, it is more important than ever 9 for companies to distinguish themselves through strategy” (Porter 2001, p. 63).2 Thus, the 10 importance of strategic positioning in creating sustainable competitive advantage is highlighted. 11 According to Porter, strategic positioning can emerge from one of two generic strategies: cost 12 leadership or differentiation (Porter 1980). These strategies are implemented at the business unit 13 level (Kotha and Orne 1989; Wheelwright 1984). The strategies are “generic” because they are 14 neither firm nor industry dependent. A business unit’s strategy can be applied either market-wide 15 or in a focused market segment (Porter 1980; Ward and Griffeths 1996). A cost leadership 16 strategy is followed when the business unit produces standard products or services that are 17 offered to many customers without significant tailoring to particular customer needs. A business 18 unit pursuing this strategy achieves cost leadership when it can produce its products or services 19 at the lowest cost. In contrast, a differentiation strategy is followed when a business unit strives 20 to serve most or all of the idiosyncratic needs of particular customers, often at a premium price. 21 Further, Porter (1996) argues that to sustain the competitive advantage achieved through 22 strategic positioning, firms must create an “alignment” between their operational activities and 23 strategies. Alignment means that firms choose activities and structures that complement their 2 Some disagree with Porter’s premise about the strategic implications of the Internet (e.g., Tapscott 2001; Tapscott, et al. 2000). 5
  9. 9. 1 strategies (Farjoun 2002). Alignment is important because individual activities in firms can often 2 affect each other in ways that either strengthen or diminish their joint effects. When activities 3 mutually reinforce each other and are consistent with the firm’s strategies, competitors cannot 4 easily imitate them. Although not always in agreement with Porter, other strategists have 5 emphasized the importance of complementarities between firms’ activities and strategies. For 6 example, Venkatraman (2000) notes that effective strategizing requires firms competing on the 7 Internet to consider issues of operations, resources, and infrastructure together as interrelated 8 decisions, rather than in isolation. This highlights the importance of aligning firms’ operational 9 activities and strategies. However, the strategy literature does not provide much specific 10 guidance on how to tailor operational processes to align with particular strategies. 11 Aligning Manufacturing Processes with Strategy 12 The product-process matrix developed by Hayes and Wheelwright (1979a, 1984) is a central 13 framework in operations management that links competitive priorities to manufacturing product 14 and process choices (Table 1). As shown in Table 1, the product-process choices in the matrix 15 are aligned with Porter’s generic strategies of cost leadership and differentiation. This alignment 16 is done at the business unit level (Kotha and Orne 1989; Wheelwright 1984). From the 17 perspective of operations, the relevant strategy concerns the products to be manufactured (or the 18 services to be delivered) by the business unit. The business unit strategy determines the 19 important product characteristics that are, in turn, aligned with process choices (Kotha and Orne 20 1989). A differentiation strategy is consistent with high product variety, low volume and an 21 informal “job shop” process for manufacturing. A job shop process involves the production of 22 unique or custom-made products, each of which requires a different set or sequence of processes. 23 Scheduling is uncertain, with frequent adjustments to facilitate quick response to changes in 24 customer and market tastes. The process is flexible in terms of products produced, flow paths 6
  10. 10. 1 followed, and resources used. There is a high dependence on skilled labor. When products have 2 more common or standard elements, and there is more volume, a “batch” process can be used. 3 The batch process resembles the job shop, but is more structured with more emphasis on quality 4 control. At the other end of the continuum, homogenous products with large volumes are 5 consistent with a cost leadership strategy and can be manufactured using “assembly line” or 6 “continuous flow” processes. The assembly line involves the assembly of standard components 7 in a sequential process. The process is less flexible than the job shop or batch processes and uses 8 standard procedures, tools, and systems. There is less dependence on highly skilled labor. The 9 continuous flow process also uses standard procedures, tools, and systems, and is highly 10 automated and capital intensive. It is the most inflexible process. 11 Table 1 12 Product and Process Choices, Competitive Priorities, and Competitive Strategy Product Choices: Low-Volume, Multiple Products, Few Major Products, High-Volume, Low Standardization, Low Volume Higher Volume High Standardization, Process Choices: One of a Kind Commodity Job Shop X Batch Flow X Assembly Line X Continuous Flow X Competitive Priorities: Custom Design Custom Design Dependability Dependability Fast Reaction Fast Reaction Efficiency Efficiency Flexibility Flexibility Standardized Design Standardized Inputs Quality Control Volume Production Economies of Scale Competitive Strategy: Differentiation Cost Leadership 13 Adapted from Hayes and Wheelwright, 1984, p. 216. Optimal alignment of process choices to competitive 14 X strategy and product choices is along the left-to-right diagonal in the matrix, indicated by “X’s”. 15 16 A fundamental premise of the product-process framework is that, for optimal performance, a 17 process must trade off product customization, volume, and production efficiency. That is, a firm 18 X should lie along the left-to-right diagonal of the matrix (see the “X’s” in Table 1). This premise 19 derives from the theory of production economics, and specifically, the concepts of economies of 20 scale (Varian 2002) and economies of scope (Panzar and Willig 1977; 1981). Scale economies 21 relate the efficiency (cost) of production to the volume of the product produced; economies of 7
  11. 11. 1 scale exist when productivity increases with increasing production volume, and diseconomies 2 exist when the volume of production is larger than the most efficient scale size. Economies of 3 scope exist when, even though a firm is producing different products, there are common inputs 4 and processes that can be shared across the products. Diseconomies of scope exist when inputs 5 and processes differ for the products produced. In the product-process framework, the 6 implication is that increasing product variety leads to many production complications and 7 confusions such as more diverse process flows, more complex scheduling requirements, a greater 8 need for planning and control, and wider skill requirements, all of which reduce production 9 efficiency. Customized or tailored processes are seen as facilitating the production of highly 10 customized products when volume is low, but are not as efficient as standard processes that 11 produce a standard product when volume is high. 12 Based on economies of scale and scope in production, a differentiation strategy is aligned 13 with a high level of product and process customization and a low volume of production; in 14 contrast, a cost leadership strategy aligns with high levels of product and process standardization 15 and a high volume of production (Kotha and Orne 1989). It is important to note that in the 16 product-process matrix, product and process choices are not viewed as binary. Rather, these 17 alternatives are viewed along a continuum, allowing for intermediate levels of product and 18 process customization and volume. 19 Although created over two decades ago, the matrix is still influential today. The framework 20 has been empirically validated in manufacturing industries (Safizadeh, et al. 1996). It has also 21 been applied to process industries, service industries and product development activities, 22 including banking services (Huete and Roth 1988), engineering and consulting (Aranda 2002), 23 and electronic business-to-consumer service operations (Heim and Sinha 2001). In IS, the matrix 24 has been used to understand how different IS applications support manufacturing operations 8
  12. 12. 1 (Kathuria, et al. 1999). Recently, researchers have proposed updates to the matrix (Ahmad and 2 Schroeder 2002) to accommodate the capabilities for mass customization offered by innovations 3 in technology, product design, and managerial practices that allow firms to operate in cells of the 4 matrix previously deemed non-optimal. 5 Product-Process Alignment in Internet Application Development 6 Although the product-process matrix provides insights in manufacturing, can it be used to 7 understand software development? Clearly, the process type metaphors (“job shop,” “batch,” 8 “assembly line,” and “continuous flow”) are more relevant to manufacturing than software 9 development. Also, the “product” is not a physical good (an automobile or computer chip), but 10 rather is an Internet application and the associated services that are bundled with it and sold 11 directly to customers. However, if the economic concepts and theories underlying the framework 12 are relevant for software development, the matrix may shed light on how Internet application 13 development processes are aligned with business unit strategies. 14 In contrast to manufacturing, software development is an intellectual activity that is perhaps 15 more akin to research and development than to the production of physical goods. Software 16 development does not require significant investments in plants and machinery, nor does it require 17 raw materials and supplies. Most costs are for labor; the initial costs of development are 18 substantial, but over the software life cycle, the costs to support the application dominate 19 (Banker, et al. 1998). Indeed, in a strict sense, the costs of production in software development 20 are negligible because the primary costs incurred are those required to develop the first “copy” of 21 the software, and the costs to replicate this copy are essentially zero (Shapiro and Varian 1998). 22 Thus, the “volume of production” is not as relevant, per se, to software development. 23 Nevertheless, there are still important parallels between manufacturing and software 24 development in terms of the economics of the processes. In fact, there is a line of research in IS 9
  13. 13. 1 that models software development as an economic production process (Kriebel and Raviv 1980; 2 Banker et al. 1991; Banker et al. 1998). From this perspective, inputs including labor (the 3 developers) and capital (tools and techniques) are used to create outputs such as software code. 4 Although the “production process” in software development is knowledge work, it can be 5 relatively structured and repetitive (Kemerer 1992). For example, computer-aided software 6 engineering tools, programming languages, and development methodologies can be used in a 7 repetitive way across projects. Sufficient repetition allows software developers to learn from 8 experience (Sacks 1994). Thus, scale economies can occur within a large software project or 9 across a set of related projects because developers can learn and become more efficient as one or 10 more tasks are repeated. Economies can also occur because investments in overhead activities 11 that facilitate project performance such as project management, configuration management, 12 testing, and quality control can be spread over a larger base (Slaughter et al. 1998). For example, 13 the costs to set up sophisticated testing environments and databases can be recovered in a 14 sufficiently large project or set of projects. 15 There can also be diseconomies of scale in software development. As project size increases, 16 certain aspects increase such as the complexity of interface requirements, the difficulty of testing 17 and validating requirements, and the number of communication paths between developers. As a 18 result, productivity eventually decreases with project size (Brooks 1995). Although the volume 19 of production (number of copies produced) is not as relevant to software development 20 economics, the volume of customers or users is. More customers increase the likelihood that the 21 application will be used in different contexts and that different requirements will emerge. If 22 sufficient numbers of customers have different requirements, the firm may have to either create 23 different versions of the application for different customers or develop one complicated, feature- 24 rich application (“bloatware”) where any one customer uses only a small subset of the features. 10
  14. 14. 1 The costs of coding, testing and validating such customized applications can be substantial. Even 2 if customers have similar needs, applications that will be used by a large number of customers 3 may require specialized coding and testing processes to ensure that the software will work 4 appropriately in a high-use situation. This is particularly true in an Internet environment where 5 thousands or even millions of users may use an application on any day (Jacobs 2005). 6 This discussion suggests that software development costs do relate to the degree of 7 customization of the application and of the development process as well as to aspects of volume 8 such as the number of customers. Thus, there may be sufficient similarities between software 9 development and manufacturing in terms of their underlying economics that would make it 10 advantageous to use the product-process matrix (at least ex ante) as a frame for our study and as 11 a lens to examine our research question: how are products and processes aligned with business 12 unit strategies in software development? That is, do business units with a differentiation strategy 13 develop customized Internet applications, each for a small number of customers and therefore 14 also use tailored development processes? Do other business units with a cost leadership strategy 15 develop standardized Internet applications, each for a large number of customers and therefore 16 also use standard development processes? 17 METHODOLOGY 18 To examine these questions, we conducted detailed case studies of the strategies, products, 19 and Internet application development processes in the business units of nine varied firms. Case 20 studies are ideal for research such as ours, that investigates “how” or “why” questions with a 21 focus on contemporary issues like Internet application development processes. Case studies are 22 also well suited for studying real-life events over which the researcher has little or no control, 23 like organizational strategic directions (Yin 1994). Case studies can be used in critical, 24 interpretive or positivist frameworks, although the positivist framework is the most common 11
  15. 15. 1 (Dubé and Paré 2003). As positivist sociological research methods, case studies have been 2 characterized as natural experiments (Lee 1989a) in which researchers explore the relationships 3 between events and constructs post hoc. Like many other such positivist case studies, we do not 4 invoke the scientific language of hypothesis testing, but we do make controlled observations, 5 leverage multiple data sources, employ deductive logic, and use cross-case comparisons and 6 multiple analysis methods to promote replicability and confidence in the validity of our findings 7 (Lee 1989a, 1989b). In line with the recommendations for improving positivist case studies in IS 8 (Dubé and Paré 2003), we provide details about the rigor in our data collection and analysis 9 procedures. In the next sections, we describe our research sites, data collection and coding. 10 Research Sites 11 The firms in our study range in size from 20 employees to more than 100,000 employees and 12 are in different industries such as financial services, insurance, business services, courier 13 services, transportation, media and telecommunications. All firms have significant Internet 14 application development efforts: some are start-ups while others are “brick and mortar” firms 15 with separate Internet application development units. In each firm, the Internet applications 16 developed directly interface with customers and are part of the product or service “bundle” 17 offered to them. From the perspective of research design, our focus on one type of task (Internet 18 application development) is important because it reduces error variance in the results. While all 19 firms conduct Internet application development, their industries, products, and customers are 20 different. This variation is also a crucial aspect of our research design: since our objective is to 21 discern varied patterns of alignment of product and process strategies in Internet application 22 development, we need to consider a broad range of potential strategies. Table 2 provides a brief 23 description of each firm in the study. To protect the anonymity of the firms, we assigned 12
  16. 16. 1 pseudonyms that reflect each firm’s primary Internet applications (products/services): Predict, 2 Utility, Incubate, Index, HR, Travel, Insure, Deliver, and Telecom. 3 Table 2: Description of Firms in Study Firm Pseudonym, Industry, When Number Capsule Case Description Products & Founded, Interviewed, Services Size Roles Predict: Creates weather derivatives based on customer demand. Energy and Mid-1990s. Three: VP Utility companies who are interested in learning about their Communication. 20 Operations, Project customers’ consumption habits purchase the weather derivatives. Offers B2B software- employees. Manager, Software Because the firm is able to create a unique and specialized based forecasting Developer product, it is able to dominate a niche in the energy industry. tools. Utility: Three entrepreneurs founded in late 1990s. The firm’s Utilities. Offers low Late 1990s. Six: CEO, VP business model recognizes the benefits of purchasing utility prices via Internet 35 Technology, services in large quantities and passing along the lower prices to buying pools for employees. Marketing Research customers. The firm offers an online buying pool for customers to customers buying Director, CIO, buy services like electricity, phone, and water at a discount. utility services. Developers Incubate: Founded in late 1990’s. Creates electronic commerce Across Industries. Late 1990s. Four: Director, Chief sites for brick-and-mortar companies. The firm also develops how Helps Brick & Mortar 55 Financial Officer, the client’s brand name and brand image will be personified on the companies develop employees. Chief Operations web. This differentiated strategy allows the firm to set itself apart customized web Officer, Developer from the countless number of web development companies. sites and presence. Index: Founded in mid-1990s by two entrepreneurs. Has grown to Film and Television. Mid 1990s. Four: Project over 80 employees. Provides its clients with the technology for Offers software 80 Manager, marketing searching and indexing videos via the Internet. Because it offers indexing and employees. specialist, senior web such a specialized product, the customer base is extremely searching tools on developer, Q/A limited. However, trying to expand market offerings. the Internet. specialist HR: Offers services for managing and communicating human Administrative Mid 1990s. Seven: Project resources, employee benefits and payroll information. The Services. Provides >100 Manager, Architect, systems it creates reduce the administrative costs of its clients. To HR applications and employees. User Interface differentiate from the other human resource solution providers, the services via the Design, Web firm has focused its efforts solely on small to medium sized firms. Internet. Developers Travel: Established in early 1990s by affiliates of a major Transportation and Early 1990s. Six: Senior Manager, transportation company. Provides all travel arrangements for its Tourism. Offers >1,000 Project Manager, clients, mid-sized corporations. Because the firm focuses on travel applications employees Q/A Manager, Lead corporate travel, it can better understand the needs of its clients and services to firms Developers, Web and can build lasting relationships with them. via the Internet. Developers Insure: One of the top insurance companies in the United States. Insurance. Offers Before 1950. Three: Human Offers various types of insurance such as automobile, motorcycle software-based >100,000 Resources Manager, watercraft, etc. Successfully launched a website in mid-1990s, insurance services employees Internet Site where customers can get quotes or buy insurance online. via Internet to Manager, Internet individuals and firms. Site Developer Deliver: One of the top express delivery providers in the United Transportation and Before 1950. Six: CIO, Senior States. With e-commerce gaining popularity, the firm plays a Logistics. Offers >100,000 Manager, Project significant role in the delivering of products to end-consumers. In software-based employees Manager, Architect, response to the increase of home-users, launched a website in logistics services on Senior Developer, mid-1990s. The website offers functionality such as the ability for the Internet. Web Developer customers to track their packages on-line. Telecom: Provides IT solutions for a large telecommunication Tele- Before 1950 Six: Senior Manager, provider. Major part of IT was outsourced 18 months prior to our communications. >50,000 Project Manager, visit. But most of the IT personnel had been transitioned to the Offers web-based employees Q/A Manager, Q/A outsourcing vendor and the unit studied was working with the telecommunications Specialist, Web same products and technology as before the outsourcing. services. Developers 13
  17. 17. 1 Data Collection and Coding 2 Our unit of analysis is the business unit that develops and markets the firm’s Internet 3 applications.3 We conducted semi-structured interviews with managerial and technical personnel 4 at each firm to elicit details relating to the business unit strategy and the major dimensions of the 5 product-process matrix. Key informants included senior managers, product managers, project 6 managers, Internet application developers and quality assurance specialists. The informants were 7 carefully selected to provide the best source of information; thus, we directed questions 8 concerning strategy, products, and customers (i.e., “what Internet applications/services are 9 produced”) to senior managers, and questions about Internet application development processes 10 (i.e., “describe the tools you use to develop Internet applications”) to project managers, 11 developers and quality assurance specialists. We also included questions on organizational and 12 interviewee demographics to obtain a more complete understanding of the firms and individuals 13 interviewed.4 In all, as shown in Table 2, we interviewed 45 individuals in the business units of 14 the nine firms. 15 Interviews with each informant were typically two hours in length, and site visits usually 16 lasted at least four hours. The interviews were conducted by two or three researchers on the 17 team; one researcher concentrated on interviewing, while the other(s) took short hand notes using 18 laptop computers. Immediately after an interview, the notes were written out in full text, and 19 transcripts were integrated and reviewed by all of the researchers conducting the interview. 20 Having multiple investigators is an advantage in a case study because their different perspectives 21 and insights add objectivity and enhance the potential for creative and novel contributions 22 (Eisenhardt 1989). The transcripts from the interviews yielded more than 100 pages of single- 3 Some firms have a separate business unit that develops Internet applications, and that unit was the focus of our study. Other firms have only one business unit, and Internet application development is conducted in that unit. Telecom’s Internet application development was managed as a separate business unit by the outsourcing vendor because it was a major client. 4 The complete interview protocol is in the appendix for this paper located at: {{{JAN DEGROSS}}}. 14
  18. 18. 1 spaced text. The interview data were complemented with secondary data about each firm’s 2 business unit strategies and other characteristics (revenues, employees, and company history) 3 that were obtained from the firms’ web sites and from publicly available information such as 4 annual financial reports or press releases. Using multiple sources of evidence is a key tactic to 5 increase construct validity in case studies and helps mitigate the potential for bias (Yin 1994). 6 For example, a manager’s description of the firm’s business unit strategy could be compared 7 with the description of the strategy on the firm’s website. 8 To guide our operationalization and coding of the four theoretical constructs determining 9 alignment (business unit strategy, the level of product customization, the level of process 10 customization, and the volume of customers) we referenced the literature on the product-process 11 framework (Safizadeh, et al. 1996; Ahmad and Schroeder 2002; Aranda 2002) and on business 12 strategy (Ward and Griffiths 1996; Porter 2001, 1980) to develop rules and procedures for 13 coding each construct.5 We identified the business unit strategy by applying the coding rules to 14 the interview statements from senior managers and publicly available information about the firm. 15 A cost leadership strategy was coded for business units that endeavored to beat competitors by 16 producing goods or services at the lowest cost, and a differentiation strategy was coded for 17 business units that sought to achieve competitive advantage by creating a product or service that 18 is unique and usually offered at a premium price (Ward and Griffiths 1996; Porter 1980). An 19 independent coder rated each firm’s business unit strategy based upon what the business unit was 20 actually doing, i.e., the unit’s strategy-in-use. In our coding, we were aware of the potential for 21 differences in the stated versus actual business unit strategies, and therefore considered multiple 22 kinds of information (interview transcripts from multiple informants, annual reports, web sites, 23 press releases, etc.) to help identify and corroborate the actual strategies-in-use executed by the 5 Coding details and examples of coded data for each of the theoretical constructs are in the appendix for this paper located at: {{{JAN DEGROSS}}} 15
  19. 19. 1 firms’ business units for their Internet-based products. The coder also evaluated information 2 about each business unit’s major competitors, and coded the competitors’ strategies to determine 3 whether the unit’s positioning vis á vis its competitors agreed with the coded strategy. For 4 example, Predict is coded as a differentiator: its business unit provides unique services to each 5 customer and charges a premium price for these services. Utility is coded as a cost leader: its 6 business unit offers customers the lowest prices for commodity products and services by forming 7 online buying pools. As a final check of the coding, the first author also coded each firm’s 8 business unit strategy and compared the coding with that of the independent coder. There were 9 no disagreements between coders in the coding of firms’ business unit strategies. 10 The interview transcripts were the primary basis for the coding of the level of product 11 customization and the level of process customization. We developed the coding rules for each of 12 these constructs from the product-process literature (Safizadeh, et al. 1996; Ahmad and 13 Schroeder 2002; Aranda 2002) and adapted them to suit an Internet application development 14 context. For example, Predict’s “product” is a bundle of an Internet-based application and 15 services: the firm offers software tools, analyses of historical data, and advice to help utility 16 companies forecast the future energy demand of their customers. An independent coder and the 17 first author of this paper read statements in the transcripts relating to product customization and 18 process customization and coded the levels of each of these constructs. The level of product 19 customization refers to the extent to which a firm’s business unit customizes its Internet 20 application/service bundle by creating unique features to meet the needs of each customer. A 21 high level of product customization was coded when the business unit offered a unique Internet 22 application/service bundle to each customer, and a low level of product customization was coded 23 when the business unit offered a standard Internet application/service bundle to many customers. 24 The level of process customization refers to the extent to which a firm’s business unit tailors its 16
  20. 20. 1 Internet application development process for each customer. A high level of process 2 customization was coded when the business unit tailored or adapted the development process for 3 each application or customer while a low level of process customization was coded when the 4 business unit used a standard development process. For example, for Predict, the level of product 5 customization is high because a different application is created for each utility company served. 6 The level of process customization is also high for Predict, because the development process is 7 adapted for each utility company to accommodate the nuances of each utility’s historical data 8 and legacy systems. Although the coders initially disagreed on the coding of two of eighteen 9 items, after discussion and reference to the transcripts, the coders mutually agreed upon all of the 10 final coding assignments for these constructs for each firm’s business unit. 11 Finally, the volume of customers refers to the number of customers who have purchased the 12 Internet application/service bundle. We obtained actual figures about the number of customers 13 for the Internet applications from interviews and company documentation.6 14 ANALYSIS AND RESULTS 15 We used a mixed methods data analysis approach (Tashakkori and Teddlie 1998) in which 16 we first qualitatively analyzed the coded data to visually discern patterns of product-process 17 alignment and to group business units with similar patterns together. We then quantitized the 18 coded data and performed a cluster analysis and a discriminant analysis to confirm and further 19 analyze the patterns and groups identified by the qualitative analysis. This mixed methods 20 approach offers several advantages. As Tashakkori and Teddlie (1998) have argued, the use of 21 multiple methods helps to triangulate and confirm the findings, providing more confidence in the 22 conclusions reached. In addition, using both qualitative and quantitative methods affords the 23 opportunity to leverage the benefits of each method and can enrich the insights obtained. 6 The figures on customer volume are in the appendix for this paper located at: {{{JAN DEGROSS}}} 17
  21. 21. 1 Following the approach for cross-case qualitative analysis recommended by Miles and 2 Huberman (1984) and Yin (1994), we used pattern matching to identify similar types of 3 alignments of strategy-, customer-, product- and process dimensions across the firms’ business 4 units. The analysis involved the use of four different spreadsheets (one for each theoretical 5 construct) in which the coded data for each business unit were placed in one or more cells of the 6 unit’s particular column in the spreadsheet. We then sorted the columns of each spreadsheet so 7 that the firms’ business units were ordered from left to right by business unit strategy 8 (differentiator to cost leader), level of product customization (high to low), level of process 9 customization (high to low), and volume of customers (small to large). This enabled us to 10 visually identify patterns of alignment across constructs, to compare patterns across units, and to 11 group units with similar patterns together. For example, we observed that the business units of 12 Predict and Incubate both followed differentiator strategies and used development processes that 13 were highly customized while those of Utility and Insure both followed cost leader strategies and 14 used more standard development processes. The cross-case analysis suggested three different 15 groups of alignment patterns. One group included business units that were cost leaders with more 16 standardized products and processes; another group included business units that were 17 differentiators with more customized products and processes; and the third group included 18 business units with intermediate levels of product and process customization. 19 Our quantitative analysis leveraged cluster analysis and discriminant analysis (McLachlan 20 2004).7 Cluster analysis was used to identify groups of similar business units and to corroborate 21 the groups identified from the qualitative analysis, and discriminant analysis was used to provide 22 further corroboration of the groups and to help understand similarities and differences across 23 units and groups. We quantitized the text-based codes for business unit strategy, level of process 7 Given the number of firms in our study, the quantitative analyses should be considered descriptive and are intended to support, complement and enhance the qualitative analyses. 18
  22. 22. 1 customization, and level of product customization for each firm, transformed customer volume 2 using the natural logarithm, and input the transformed values into the analyses.8 A hierarchical 3 cluster analysis distinguished three clusters.9 The clusters were similar to those we discovered in 4 the qualitative analysis, supporting the groups of alignment patterns identified. 5 We then used discriminant analysis (McLachlan 2004) to further analyze the data. 6 Discriminant analysis identifies the fewest functions that are needed to cluster similar 7 observations and to discriminate between dissimilar observations. A discriminant function is a 8 latent variable representing a linear combination of the independent variables (in our analysis, 9 the strategy, product, process and customer variables). We specified three clusters, ex ante, in the 10 discriminant analysis using the cluster assignment for each firm’s business unit from the 11 hierarchical cluster analysis. The discriminant analysis generated two functions that 12 discriminated between the three clusters. The first function explained 98.9% of the variation 13 between clusters, and the second function explained the remaining 1.1% of the variation between 14 clusters. The functions are both statistically significant (at p < 0.01) in discriminating between 15 clusters, and each of the individual independent variables differs significantly (all at p < 0.01) in 16 mean by cluster. It is possible to interpret each discriminant function by considering its 17 correlations with each of the four independent variables. We interpreted Discriminant Function 1 18 as representing “business unit / product strategy” as it correlates significantly with business unit 19 strategy (0.812), level of product customization (-0.812) and volume of customers (0.511). 20 Discriminant Function 2 seems to capture “process strategy” as it is correlated significantly only 21 with level of process customization (-0.953). We then used each discriminant function to 22 generate a set of discriminant scores for each firm’s business unit, graphed in Figure 1. 8 Values of “high”, “medium”, or “low” were assigned “1”, “2”, or “3”, respectively. A differentiation strategy was assigned a “1”, cost leadership a “3”, and intermediate a “2”. The volume of customers was transformed as it is not normally distributed. 9 The cluster analysis used the between groups linkage method and the squared Euclidean distance measure. The Calinski / Harabasz pseudo-F index (1974) suggested that three clusters provide the most distinct clustering. 19
  23. 23. 1 Figure 1: Graph of Firms’ Discriminant Scores 3 process strategy: highly standardized 2.5 TELECOM 2 Group #2 1.5 business unit/product strategy: business unit/product strategy: highly customized/differentiator/ highly standardized/cost leader/ low volume 1 high volume Group Center HR 0.5 Group #3 Group #1 UTILITY INCUBATE TRAVEL 0 INSURE -9.0 -8.0 -7.0 -6.0 -5.0 -4.0 -3.0 -2.0 -1.0 .0 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 Group Center -0.5 Group Center PREDICT INDEX -1 DELIVER -1.5 process strategy: highly customized -2 2 In Figure 1, the “x” axis represents the scores generated by Discriminant Function 1 (the 3 business unit / product strategy). Business units farther to the right on the “x” axis have more 4 standardized products and are cost leaders in a large market. Business units farther to the left on 5 the “x” axis have more customized products and are differentiators in a small market. The “y” 6 axis represents the scores generated by Discriminant Function 2 (the process strategy). Business 7 units closer to the top of the graph use more standardized processes while business units closer to 8 the bottom use more customized processes. Figure 1 also shows three distinct groups of business 9 units where each group represents a particular alignment pattern. The group assignments were 10 checked using the discriminant functions to predict each unit’s group assignment, and then the 11 prediction was compared with the unit’s original assignment from the cluster analysis. In our 12 study, the discriminant analysis matched the group assignments for each business unit as 100% 13 of the units were correctly classified (predicted assignment = original assignment); this provides 14 further support for the groups of alignment patterns we identified in the qualitative analysis. As 20
  24. 24. 1 shown in Figure 1, Predict, Incubate and Index are in Group #1. Figure 1 also suggests that 2 Predict and Incubate are more similar in their patterns of strategy-product-process alignment 3 than Index. Still, Figure 1 indicates that Index’s pattern of alignment is more like Predict’s and 4 Incubate’s than the other business units in the other groups. The other two groups can be 5 interpreted similarly, suggesting that Telecom and Deliver are most unlike the other units in their 6 respective groups. In addition, comparing group centers suggests that Groups 1 and 3 are most 7 dissimilar as their respective group average scores are the farthest apart. 8 We then drew radial graphs (Figure 2) to visualize how each firm aligned its business unit 9 strategy, level of product customization, level of process customization and customer volume.10 10 Each graph shows the numeric rating for each firm’s business unit on each of the four theoretical 11 dimensions. A business unit is in alignment when the values for all dimensions are equal, i.e., the 12 level of differentiation in business unit strategy matches the level of customization in product 13 and process, and the volume of customers. For example, Predict is in alignment as all 14 dimensions have the same value (“1”). A business unit is out of alignment when the values for all 15 dimensions are not equal. For example, Deliver is out of alignment because its level of process 16 customization (“2”) does not equal the value of the other dimensions (“3”). The radial graphs 17 also reflect the levels of differentiation in business unit strategy, product and process, and the 18 volume of customers. Values of “1” reflect a highly differentiated strategy, customized products 19 and processes, and a low volume of customers while values of “3” reflect a cost leadership 20 strategy, more standardized products and processes, and a high volume of customers; values of 21 “2” reflect intermediate levels of these dimensions. To discern whether alignment varies across 22 groups, we arranged each radial graph into its “assigned” group from the analyses. 23 10 To draw the radial graphs, we transformed customer volume such that a small number of customers (< 1,000) was assigned a “1”, medium (> 1,000 and < 100,000) a “2”, and large (> 100,000) a “3”. The groups were inductively determined from the data and confirmed by a hierarchical cluster analysis. 21
  25. 25. 1 Figure 2: Strategy-Product-Process Alignment for each Business Unit by Group 2 3 4 Group #1: Highly Customized level of process level of process level of process standardization standardization standardization 3 3 3 2 2 PREDICT 2 INCUBATE INDEX 1 1 1 cost leadership level of product cost leadership level of product cost leadership 0 level of product 0 0 strategy standardization strategy standardization strategy standardization customers supported customers supported customers supported 5 6 7 8 9 Group #2: Intermediate level of process level of process level of process standardization standardization standardization 3 3 3 2 2 HR TRAVEL TELECOM 2 1 1 1 cost leadership 0 level of product cost leadership level of product cost leadership level of product 0 0 strategy standardization strategy standardization strategy standardization customers supported customers supported customers supported 10 11 12 13 14 Group #3: Highly Standardized level of process level of process standardization standardization level of process 3 3 standardization 3 2 UTILITY 2 INSURE DELIVER 2 1 1 cost leadership level of product cost leadership level of product 0 0 cost leadership level of product strategy standardization strategy standardization 1 strategy standardization customers supported customers supported customers supported 15 16 22
  26. 26. 1 Comparing the radial graphs in Figure 2 by group shows that the business units in Group #1 2 are the most highly differentiated; the business units in Group #3 are the most standardized; and 3 the business units in Group #2 have intermediate levels of differentiation. This suggests that the 4 business units have distinct patterns of alignment for their business unit strategies, products and 5 processes. Figure 2 also shows that six of the nine business units in the firms in our study do 6 align their strategies as predicted. The radial graphs for Predict and Incubate in Group #1 7 suggest that they pursue differentiation strategies, have highly customized products and 8 development processes, and relatively small volumes of customers. At the other end of the 9 extreme in Group #3, Insure and Utility pursue a cost leadership strategy, and have more 10 standard products and development processes, and a larger volume of customers. The strategies 11 used by HR and Travel in Group #2 reflect intermediate levels of differentiation in business unit 12 objectives, product characteristics and Internet application development processes. The 13 respective customer volumes are larger than those of Predict and Incubate, but smaller than 14 those of Insure and Utility. Figure 2 also shows that Index, Telecom and Deliver are “out of 15 alignment” in that some aspect of their business unit strategies, products, processes or customer 16 volumes does not align as expected. We integrate and interpret these results in the Discussion. 17 DISCUSSION 18 Overall, we find that the dynamics of the product-process framework are relevant in software 19 development as software process choices are aligned with product characteristics, customer 20 volume, and business unit strategies for many of the firms. However, some units are not in 21 alignment. We first examine how units that are in alignment configure detailed dimensions of 22 their products and processes. We then consider the business units that are misaligned. 23
  27. 27. 1 Business Units in Alignment 2 Consistent with the product-process framework, for the business units in alignment, a 3 customized development process is used when the volume of customers is small, and there are 4 highly differentiated needs. A more standard development process is used when there are 5 sufficient common needs that applications can be developed to serve a larger number of 6 customers. To provide a deeper understanding of how the business units align elements of their 7 products and processes, we use Concept Maps. Concept maps organize and represent concepts 8 (events or objects) and their inter-relationships in a particular domain or context (Novak 1998). 9 Relationships between concepts are associative. Concept maps were originally developed to help 10 understand how children learn. Recently, concept maps have been used to conduct qualitative 11 data analysis (Daley 2004) where the researcher draws the concept map, and uses it to visually 12 identify themes and patterns, display linkages, and facilitate cross group or site comparisons. 13 Following the approach suggested by Daley (2004) and the techniques developed by Novak 14 (1998), we developed concept maps to visually represent concepts for the business units in 15 alignment. Consistent with the literature on concept mapping, we created concept maps with the 16 broader, more inclusive concepts at the top of the hierarchy, connecting with other more detailed 17 concepts below. Given our goals of evaluating alignment between business unit, product and 18 process strategies, we deductively identified the main concept categories and their associations 19 based on the primary aspects of the product-process matrix: (1) Customer Requirements relate to 20 Product characteristics; (2) Products are developed using Process elements; (3) Development 21 Process is using People related process elements; (4) Development Process is using Practices 22 related process elements; (5) Development Process is using Architecture related process 23 elements; and (6) Process Elements relate to Outcomes. We further refined the development 24 process category using software development reference models, such as the CMM to help 24
  28. 28. 1 identify people-related, practices-related and architecture-related concepts. We also referenced 2 the ISO standard for software quality (ISO 9126) to help identify outcomes concepts. Then, we 3 analyzed the interview transcripts to surface the detailed concepts within each category or sub- 4 category. For example, team role diversity and scalability emerged as concepts from the 5 interview transcripts in response to questions on people-related process choices and on 6 outcomes, respectively. Team role diversity refers to the number of different roles on an Internet 7 application development team. Scalability indicates whether the Internet application architecture 8 can be scaled for high volume usage.11 9 In the following sections, we present and discuss concept maps for two groups of business 10 units: those using a highly customized Internet application development process and those using 11 a more standard process (Groups #1 and #3 in Figure 1, respectively). We also provide examples 12 of business units that are using each of these development processes. Finally, we present and 13 discuss an overall concept map that illustrates the general concepts and associations between 14 product and process alignment in Internet application development. 15 Concept Map for the Highly Customized Development Process. Figure 3 depicts the concept 16 map for a highly customized Internet application development process that is used by business 17 units pursuing a differentiation strategy. This concept map is exemplified by Predict. Predict 18 targets a small set of utility customers who have unique and particular requirements. Each utility 19 transmits historical data on energy consumption patterns, and Predict develops a customized, 20 business-to-business Internet-based application for each utility to forecast future consumption 21 patterns. Because the data and requirements are quite different for each utility, Predict must 22 develop a different application for each utility, often using a different development process: “We 23 have about 150 utility customers. The companies each send us their energy consumption data. And, we provide 11 A brief explanation and example of each concept identified in the concept mapping analysis are documented in the appendix for this paper located at: {{[JAN DEGROSS}}} 25
  29. 29. 1 them with an analysis and prediction of future energy needs. But, the data feeds in and out are unstable... we are 2 dealing with each customer’s antiquated legacy systems...If we ever had something that worked the same way twice 3 – that would be stability. We have about 150 different development processes” (Senior Manager, Predict). 4 Figure 3: Concept Map of Highly Tailored Development Process c u s to m e rs have a re h e te ro g e n e o u s re q u ire m e n ts fe w re la te to re la te s to h ig h v a rie ty o f p ro d u c t fe a tu re s a re d e v e lo p e d u s in g ta ilo re d d e v e lo p m e n t p ro c e s s is u s in g is u s in g is u s in g p e o p le p ra c tic e s a rc h ite c tu re is w o rk o n a re a re a re has a re c u s to m d e s ig n e d s m a ll te a m s g u ru s p ro to typ in g m any phases little re u s e re la te s to re la te to little c o d e re u s e re la te s to re la te to re la te s to re la te to re la te s to o u tc o m e s o u tc o m e s o u tc o m e s a re a re a re a re a re h ig h fle x ib ility a re p o o r s c a la b ility a re lo n g le a rn in g lo n g c yc le tim e lo w fo rm a lity little le g a c y a re c u rv e s in te g ra tio n lo w p e rv a s iv e n e s s little k n o w le d g e tra n s fe r 5 6 There is a reliance on gurus because to serve customers in Predict’s unique market niche 7 requires specialized knowledge of the particular utility and the utility’s data and systems as well 8 as complex skill sets including advanced statistics and financial engineering. The development 9 process also requires the use of small teams of specialists. The use of gurus makes it difficult to 10 transfer knowledge, and the learning curve for new employees is steep and long. There is almost 11 no reuse of software code; in fact Predict uses redundant coders, i.e., two developers 12 independently code each application for each customer. This is done to minimize errors and bias 26
  30. 30. 1 in the consumption prediction models developed. The software code is discarded if there are 2 mistakes or problems: “We throw away and re-build for each customer. We’re very adaptive, which is stressful 3 on employees who don’t adapt” (Senior Manager, Predict). Prototyping is used to understand user 4 requirements. Custom architecture design, limited reuse of design artifacts, and little legacy 5 integration also characterize this mode of development. 6 Concept Map for the Highly Standardized Development Process. Figure 4 shows the 7 concept map for the more standardized Internet application development process that is used by 8 business units pursuing a cost leadership strategy. Utility typifies this concept map. Utility uses 9 the Internet to organize customers into large buying pools and facilitate low cost purchase of 10 services such as electricity, natural gas, home security, and health insurance. There are sufficient 11 standard features across the buying pools that the business unit can standardize its Internet 12 applications and reuse software across the different market segments: “We are always making 13 generalizations across the vertical markets even though there are different products, different markets and different 14 interfaces. The whole reuse perspective goes across the verticals…. We retrofit good features, repeating one across 15 the others… our development strategy is to standardize and reuse software across vertical markets…” (Manager, 16 Utility). The commonalities amongst its customers and products enable Utility to use a standard 17 development process, and in fact, the unit leverages the traditional, sequential waterfall approach 18 to software development, albeit at “Internet speed”: “We use the ‘staircase’ method to develop. Internet 19 speed development is very similar to traditional development – we still need to gather requirements, there’s a life 20 cycle. But, the response time is much quicker. The process is like a ‘quick waterfall’” (Project Manager, Utility). 21 Because the software features and processes are more standard and can be reused across market 22 segments, there is less need for specialized knowledge, and less reliance on gurus: “Some wear 23 multiple hats. Project leaders could be from technology, business or operations, and there isn’t always someone 24 tagged as the ‘leader’” (Project Manager, Utility). The software architecture plays a critical role in 27
  31. 31. 1 standardizing and reusing applications across market segments: “We have designed a three tier 2 architecture (presentation layer, application layer, database layer). The objective is to make an open, modular and 3 scalable architecture. Because there is a vision, it allows us to create good technologies that are scalable. We can 4 easily ratchet up or down in the scale” (Manager, Utility). Short cycle times, and high scalability, 5 robustness and portability also characterize this mode of development. 6 Figure 4: Concept Map of Highly Standardized Development Process c u s to m e rs have a re hom ogeneous m any re q u ire m e n ts in c re a s e n e e d fo r r e la te to lo w v a rie ty o f re la te s to p ro d u c t fe a tu re s m a y r e q u ir e a r e d e v e lo p e d u s in g e a s y c u s to m iz a tio n s ta n d a rd d e v e lo p m e n t p ro c e s s is u s in g is u s in g is u s in g p e o p le p ra c tic e s a rc h ite c tu re has are a re have are has w a te rfa ll are m o d u la r d e s ig n a re g e n e ra lis ts fe w ro le s c o d e re u s e fe w p h a s e s h ig h re u s e r e la te s to r e la te s to r e la te to C O TS use r e la te s to re la te to re la te s to r e la te s to r e la te to o u tc o m e s o u tc o m e s o u tc o m e s are are are a re a re lo w fle x ib ility a re a re h ig h s c a la b ility ro b u s tn e s s are s h o rt le a rn in g h ig h fo rm a lity are s h o rt c y c le tim e are c u rv e s h ig h p o rta b ility h ig h p e rv a s iv e n e s s h ig h k n o w le d g e s o m e le g a c y tra n s fe r & re -u s e in te g ra tio n 7 8 Concept Map for Product-Process Alignment. We further abstracted the elements in the 9 concept maps to create a more general concept map of product and process alignment in Internet 10 application development (Figure 5). As shown in Figure 5, the level of requirements diversity 11 relates to the variety of product features, and together with the volume of demand for 12 requirements influences the type of development process selected. 28