Aligning Software Processes with Strategy

44
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: [email protected] Linda Levine Software Engineering Institute Pittsburgh, PA Email: [email protected] Balasubramaniam Ramesh Georgia State University Atlanta, GA Email: [email protected] Jan Pries-Heje The IT University of Copenhagen Copenhagen, Denmark Email: [email protected] Richard Baskerville Georgia State University Atlanta, GA Email: [email protected] April 15, 2006 * Contact author for this paper. Do not cite, quote, copy or distribute without permission of the authors

description

 

Transcript of Aligning Software Processes with Strategy

Page 1: Aligning Software Processes with Strategy

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: [email protected]

Linda Levine Software Engineering Institute

Pittsburgh, PA Email: [email protected]

Balasubramaniam Ramesh

Georgia State University Atlanta, GA

Email: [email protected]

Jan Pries-Heje The IT University of Copenhagen

Copenhagen, Denmark Email: [email protected]

Richard Baskerville

Georgia State University Atlanta, GA

Email: [email protected]

April 15, 2006

* Contact author for this paper.

Do not cite, quote, copy or distribute without permission of the authors

Page 2: Aligning Software Processes with Strategy

ii

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.

Page 3: Aligning Software Processes with Strategy

Aligning Software Processes with Strategy 1 2

Abstract 3 4 Although increasing evidence suggests that superior performance requires alignment between 5

firms’ strategies and production processes, it is not known if such alignment is relevant for 6

software development processes. This study breaks new ground by examining how firms align 7

their software processes, products, and strategies in Internet application development. Drawing 8

upon the literatures in strategy, operations management, and information systems, we identify 9

four dimensions that influence alignment – the business unit strategy, the level of product 10

customization, the level of process customization, and the volume of customers. To examine how 11

these dimensions are synchronized, we conducted detailed case studies of Internet application 12

development in nine varied firms including both start-ups and established “brick and mortar” 13

companies. Our analyses reveal that the firms in our study do use differing processes for Internet 14

application development, and that many of the firms match their software process choices to 15

product characteristics, customer volume, and business unit strategies. We develop concept maps 16

for the firms that are in alignment to illustrate how managers configure specific product and 17

process dimensions. We also offer potential explanations for why some firms are misaligned 18

such as: attempting to execute incompatible strategies, the lack of coordination between 19

marketing and production strategies, the too rapid expansion of process scope, and inflexible 20

barriers to rapid adaptation of process. Our study contributes detailed insights into how software 21

processes are customized to complement different types of product requirements and strategies. 22

23 Key Words: Software Process; Product-Process Matrix, Internet Application Development; 24 Software Development Strategy; Competitive Strategy; Contingency Theory. 25 26 ISRL Categories: FAUF, FBUF, FCUF, DA09. 27

Page 4: Aligning Software Processes with Strategy
Page 5: Aligning Software Processes with Strategy

1

Aligning Software Processes with Strategy 1 2

INTRODUCTION 3 4

In operations management, there is general agreement that sustainable world-class 5

performance requires internal consistency between firms’ strategies and their manufacturing 6

operations (Krajewski and Ritzman 2005). Consistency means that the selection of strategies 7

such as cost leadership or differentiation influences decisions on product priorities (such as cost, 8

time, and quality), and that these priorities in turn guide decisions on production processes (Hill 9

2001). In information systems (IS), there is a notion that a firm’s information technology (IT) 10

strategy should be aligned with its other strategies. For example, value chain analysis (Porter and 11

Millar 1985) aligns information systems to a firm’s primary and secondary activities. More 12

recently, Grover and Malhotra (1999) link IS to manufacturing operations; Weill and Broadbent 13

(1998) show how firms align their IT infrastructure decisions with their strategies; Sabherwal 14

and Chan (2001) examine how the alignment between business and IT strategy impacts firm 15

performance; and Sabherwal et al. (2003) model the alignment between the strategy and 16

structure of the firm and its IT function. While these and other studies have described various 17

components of alignment between firm strategies and IS, the focus of this literature has been 18

more macro, i.e., strategies are aligned to information systems, structure of the IT organization, 19

overall IT strategy, or to IT architecture. To the best of our knowledge, there are few studies that 20

have examined how software development processes are aligned with different strategies. 21

By software development processes, we refer to the activities, methods, practices, and 22

transformations that are used to develop and maintain software (Paulk, et al. 1993, p. 20). 23

Decisions on software development processes include choices relating to team organization and 24

staffing, methodologies, techniques, tools, and architecture. Using one standard approach to 25

software development can be less costly, leverage economies of scale, and simplify project 26

Page 6: Aligning Software Processes with Strategy

2

management, knowledge transfer, and performance measurement. However, given the many 1

approaches to software development, it may not always be effective for firms to standardize on 2

one approach for all projects. Indeed, researchers and software development specialists have 3

suggested the potential performance benefits of process customization (Deck 2001). For 4

example, a study of software firms by Nidumolu and Knotts (1998) reveals that the 5

customizability of software development processes can significantly influence competitive 6

performance. Process customization or tailoring involves adapting, particularizing or selecting 7

certain (often standard or “best practice”) software processes to fit the needs of specific 8

organizations or projects. Examples include Motorola, where software development methods are 9

tailored at the industry, organization and project levels (Fitzgerald, et al. 2003) and IBM, where 10

work product descriptions are used to configure a software process to a particular project and 11

make decisions about process sequencing and phasing (Cameron 2002). However, despite the 12

potential benefits of process tailoring, there has been little research that provides insights into 13

how such customizing occurs, in terms of aligning software processes with business strategies. 14

The objective of our study is to fill some of this void by examining whether and how 15

software development processes are fit to strategies. Three levels of strategy can be distinguished 16

in a firm: corporate, business unit, and functional (Kotha and Orne 1989; Wheelwright 1984). 17

We identify firms’ business unit strategies as an important basis for selecting software processes. 18

This basis is consistent with the idea in operations management that strategic and production 19

decisions are interrelated. At the corporate level, managers define the businesses in which the 20

firm operates and allocate resources to those businesses. At the business unit level, managers 21

specify the scope and strategy of each business unit and define how the business unit strategy 22

relates to the corporate strategy. Specifying the business unit strategy requires choosing the 23

product-, market- and service sub-segments to be addressed by the unit. Thus, it is at the business 24

Page 7: Aligning Software Processes with Strategy

3

unit that the basis of competitive advantage (cost leadership or product differentiation) is defined 1

(Kotha and Orne 1989, Wheelwright 1984). These choices give the business unit a broader or 2

narrower product line than its principal competitors. Having made those choices, managers must 3

then decide at the functional level whether to produce the product or service with a process that 4

permits a high degree of flexibility but is labor-intensive and usually has relatively higher costs 5

or a process that is more standard and automated with relatively lower costs. A key argument is 6

that process choices must be consistent with business unit strategies for the firm to be productive 7

and effective (Brown and Blackmon 2005; Kotha and Orne 1989; Wheelwright 1984). 8

Strategy, product and process alignment is salient in Internet application development. An 9

Internet application is software that allows its users to execute business logic using a universal, 10

client-server browser architecture (Conallen 2000). Business to consumer Internet applications, 11

such as web-based retailing systems, directly interface with customers and constitute (or directly 12

support) the product or service “bundle” offered to them. Because these Internet applications and 13

their associated services are revenue-generating and must directly satisfy customers’ 14

requirements (Porra 2000), the software and development processes may reflect the nuances of a 15

firm’s business unit strategy. For example, the principal architect of salesforce.com describes 16

how competitive advantage for online businesses relates to Internet application development 17

choices such as resource sharing, multi-tier clustering, and application customization (Jacobs 18

2005). Resource sharing facilitates economies of scale and pay-as-you-go pricing; multi-tier 19

clustering allows an online service provider to more easily scale up and grow the business; and 20

application customization can differentiate the provider from other providers. Other examples are 21

provided by Heim and Sinha (2002) who describe how the web-based retailer Baltimore Coffee 22

and Tea (www.baltcoffee.com) supports a “Service Mart” or “assemble to order” strategy by 23

programming dynamic scripts in an Internet shopping cart system to sell more than 1,000 24

Page 8: Aligning Software Processes with Strategy

4

varieties of coffee and tea. This is contrasted with a “Service Kiosk” or “make to stock” strategy 1

implemented using static HTML technologies to provide identical experiences to all customers. 2

Thus, we address the following question in this study: are software processes aligned with 3

firms’ business unit strategies in Internet application development, and if so, how? Answering 4

this question increases understanding of how firms develop Internet applications to address 5

specific requirements by relying on different types of software development practices. If the 6

alignment of firms’ business unit, product and process strategies leads to sustained high 7

performance, it is important to understand whether and how this alignment occurs, particularly in 8

the expanding world of Internet application development. We next draw upon the literatures in 9

strategy, operations management, and information systems to identify the dimensions that 10

influence process, product and business unit strategy alignment. 11

THEORETICAL BACKGROUND 12

Strategy and Strategic Positioning 13

There are several schools of thought with respect to strategy (Minzberg, et al. 1998; Eden 14

and Ackermann 1998). Among the various strategy schools, the Positioning school is most 15

consistent with our objective of understanding how firms align their Internet application 16

development processes with their business unit strategies.1 Among the positioning approaches to 17

strategy development, we draw on Porter’s competitive forces model (1980). Other prominent 18

models in this school including the Miles and Snow typologies (1978) or theories that emphasize 19

firms’ capabilities such as the resource-based view (Wade and Hulland 2004), dynamic 20

capabilities approach (Teece, et al. 1997) or core competency theory (Prahalad and Hamel 1990) 21

are less suited to our objectives as none has clear implications for how particular strategies can 22

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.

Page 9: Aligning Software Processes with Strategy

5

be matched with particular processes. In contrast, in Porter’s view of strategy, operational 1

activities are the basic units of competitive advantage. According to Porter (1996), strategy 2

involves the creation of a unique and valuable position for a firm, using a distinctive mix of 3

activities: “… the essence of strategy is in the activities – choosing to perform activities 4

differently or to perform different activities than rivals” (p. 64). However, operational 5

effectiveness alone, claims Porter, is insufficient for long-term competitive success. This is 6

especially true in the world of the Internet: “Because the Internet tends to weaken industry 7

profitability without providing proprietary operational advantages, it is more important than ever 8

for companies to distinguish themselves through strategy” (Porter 2001, p. 63).2 Thus, the 9

importance of strategic positioning in creating sustainable competitive advantage is highlighted. 10

According to Porter, strategic positioning can emerge from one of two generic strategies: cost 11

leadership or differentiation (Porter 1980). These strategies are implemented at the business unit 12

level (Kotha and Orne 1989; Wheelwright 1984). The strategies are “generic” because they are 13

neither firm nor industry dependent. A business unit’s strategy can be applied either market-wide 14

or in a focused market segment (Porter 1980; Ward and Griffeths 1996). A cost leadership 15

strategy is followed when the business unit produces standard products or services that are 16

offered to many customers without significant tailoring to particular customer needs. A business 17

unit pursuing this strategy achieves cost leadership when it can produce its products or services 18

at the lowest cost. In contrast, a differentiation strategy is followed when a business unit strives 19

to serve most or all of the idiosyncratic needs of particular customers, often at a premium price. 20

Further, Porter (1996) argues that to sustain the competitive advantage achieved through 21

strategic positioning, firms must create an “alignment” between their operational activities and 22

strategies. Alignment means that firms choose activities and structures that complement their 23

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

Page 10: Aligning Software Processes with Strategy

6

strategies (Farjoun 2002). Alignment is important because individual activities in firms can often 1

affect each other in ways that either strengthen or diminish their joint effects. When activities 2

mutually reinforce each other and are consistent with the firm’s strategies, competitors cannot 3

easily imitate them. Although not always in agreement with Porter, other strategists have 4

emphasized the importance of complementarities between firms’ activities and strategies. For 5

example, Venkatraman (2000) notes that effective strategizing requires firms competing on the 6

Internet to consider issues of operations, resources, and infrastructure together as interrelated 7

decisions, rather than in isolation. This highlights the importance of aligning firms’ operational 8

activities and strategies. However, the strategy literature does not provide much specific 9

guidance on how to tailor operational processes to align with particular strategies. 10

Aligning Manufacturing Processes with Strategy 11

The product-process matrix developed by Hayes and Wheelwright (1979a, 1984) is a central 12

framework in operations management that links competitive priorities to manufacturing product 13

and process choices (Table 1). As shown in Table 1, the product-process choices in the matrix 14

are aligned with Porter’s generic strategies of cost leadership and differentiation. This alignment 15

is done at the business unit level (Kotha and Orne 1989; Wheelwright 1984). From the 16

perspective of operations, the relevant strategy concerns the products to be manufactured (or the 17

services to be delivered) by the business unit. The business unit strategy determines the 18

important product characteristics that are, in turn, aligned with process choices (Kotha and Orne 19

1989). A differentiation strategy is consistent with high product variety, low volume and an 20

informal “job shop” process for manufacturing. A job shop process involves the production of 21

unique or custom-made products, each of which requires a different set or sequence of processes. 22

Scheduling is uncertain, with frequent adjustments to facilitate quick response to changes in 23

customer and market tastes. The process is flexible in terms of products produced, flow paths 24

Page 11: Aligning Software Processes with Strategy

7

followed, and resources used. There is a high dependence on skilled labor. When products have 1

more common or standard elements, and there is more volume, a “batch” process can be used. 2

The batch process resembles the job shop, but is more structured with more emphasis on quality 3

control. At the other end of the continuum, homogenous products with large volumes are 4

consistent with a cost leadership strategy and can be manufactured using “assembly line” or 5

“continuous flow” processes. The assembly line involves the assembly of standard components 6

in a sequential process. The process is less flexible than the job shop or batch processes and uses 7

standard procedures, tools, and systems. There is less dependence on highly skilled labor. The 8

continuous flow process also uses standard procedures, tools, and systems, and is highly 9

automated and capital intensive. It is the most inflexible process. 10

Table 1 11 Product and Process Choices, Competitive Priorities, and Competitive Strategy 12

Product Choices: Process Choices:

Low-Volume, Low Standardization,

One of a Kind

Multiple Products, Low Volume

Few Major Products, Higher Volume

High-Volume, High Standardization,

Commodity Job Shop XXXX

Batch Flow XXXX Assembly Line XXXX

Continuous Flow XXXX Competitive Priorities: Custom Design

Fast Reaction Flexibility

Custom Design Fast Reaction

Flexibility Quality Control

Dependability Efficiency

Standardized Design Volume Production

Dependability Efficiency

Standardized Inputs Economies of Scale

Competitive Strategy: Differentiation Cost Leadership Adapted from Hayes and Wheelwright, 1984, p. 216. Optimal alignment of process choices to competitive 13 strategy and product choices is along the left-to-right diagonal in the matrix, indicated by “XXXX’s”. 14 15 A fundamental premise of the product-process framework is that, for optimal performance, a 16

process must trade off product customization, volume, and production efficiency. That is, a firm 17

should lie along the left-to-right diagonal of the matrix (see the “XXXX’s” in Table 1). This premise 18

derives from the theory of production economics, and specifically, the concepts of economies of 19

scale (Varian 2002) and economies of scope (Panzar and Willig 1977; 1981). Scale economies 20

relate the efficiency (cost) of production to the volume of the product produced; economies of 21

Page 12: Aligning Software Processes with Strategy

8

scale exist when productivity increases with increasing production volume, and diseconomies 1

exist when the volume of production is larger than the most efficient scale size. Economies of 2

scope exist when, even though a firm is producing different products, there are common inputs 3

and processes that can be shared across the products. Diseconomies of scope exist when inputs 4

and processes differ for the products produced. In the product-process framework, the 5

implication is that increasing product variety leads to many production complications and 6

confusions such as more diverse process flows, more complex scheduling requirements, a greater 7

need for planning and control, and wider skill requirements, all of which reduce production 8

efficiency. Customized or tailored processes are seen as facilitating the production of highly 9

customized products when volume is low, but are not as efficient as standard processes that 10

produce a standard product when volume is high. 11

Based on economies of scale and scope in production, a differentiation strategy is aligned 12

with a high level of product and process customization and a low volume of production; in 13

contrast, a cost leadership strategy aligns with high levels of product and process standardization 14

and a high volume of production (Kotha and Orne 1989). It is important to note that in the 15

product-process matrix, product and process choices are not viewed as binary. Rather, these 16

alternatives are viewed along a continuum, allowing for intermediate levels of product and 17

process customization and volume. 18

Although created over two decades ago, the matrix is still influential today. The framework 19

has been empirically validated in manufacturing industries (Safizadeh, et al. 1996). It has also 20

been applied to process industries, service industries and product development activities, 21

including banking services (Huete and Roth 1988), engineering and consulting (Aranda 2002), 22

and electronic business-to-consumer service operations (Heim and Sinha 2001). In IS, the matrix 23

has been used to understand how different IS applications support manufacturing operations 24

Page 13: Aligning Software Processes with Strategy

9

(Kathuria, et al. 1999). Recently, researchers have proposed updates to the matrix (Ahmad and 1

Schroeder 2002) to accommodate the capabilities for mass customization offered by innovations 2

in technology, product design, and managerial practices that allow firms to operate in cells of the 3

matrix previously deemed non-optimal. 4

Product-Process Alignment in Internet Application Development 5

Although the product-process matrix provides insights in manufacturing, can it be used to 6

understand software development? Clearly, the process type metaphors (“job shop,” “batch,” 7

“assembly line,” and “continuous flow”) are more relevant to manufacturing than software 8

development. Also, the “product” is not a physical good (an automobile or computer chip), but 9

rather is an Internet application and the associated services that are bundled with it and sold 10

directly to customers. However, if the economic concepts and theories underlying the framework 11

are relevant for software development, the matrix may shed light on how Internet application 12

development processes are aligned with business unit strategies. 13

In contrast to manufacturing, software development is an intellectual activity that is perhaps 14

more akin to research and development than to the production of physical goods. Software 15

development does not require significant investments in plants and machinery, nor does it require 16

raw materials and supplies. Most costs are for labor; the initial costs of development are 17

substantial, but over the software life cycle, the costs to support the application dominate 18

(Banker, et al. 1998). Indeed, in a strict sense, the costs of production in software development 19

are negligible because the primary costs incurred are those required to develop the first “copy” of 20

the software, and the costs to replicate this copy are essentially zero (Shapiro and Varian 1998). 21

Thus, the “volume of production” is not as relevant, per se, to software development. 22

Nevertheless, there are still important parallels between manufacturing and software 23

development in terms of the economics of the processes. In fact, there is a line of research in IS 24

Page 14: Aligning Software Processes with Strategy

10

that models software development as an economic production process (Kriebel and Raviv 1980; 1

Banker et al. 1991; Banker et al. 1998). From this perspective, inputs including labor (the 2

developers) and capital (tools and techniques) are used to create outputs such as software code. 3

Although the “production process” in software development is knowledge work, it can be 4

relatively structured and repetitive (Kemerer 1992). For example, computer-aided software 5

engineering tools, programming languages, and development methodologies can be used in a 6

repetitive way across projects. Sufficient repetition allows software developers to learn from 7

experience (Sacks 1994). Thus, scale economies can occur within a large software project or 8

across a set of related projects because developers can learn and become more efficient as one or 9

more tasks are repeated. Economies can also occur because investments in overhead activities 10

that facilitate project performance such as project management, configuration management, 11

testing, and quality control can be spread over a larger base (Slaughter et al. 1998). For example, 12

the costs to set up sophisticated testing environments and databases can be recovered in a 13

sufficiently large project or set of projects. 14

There can also be diseconomies of scale in software development. As project size increases, 15

certain aspects increase such as the complexity of interface requirements, the difficulty of testing 16

and validating requirements, and the number of communication paths between developers. As a 17

result, productivity eventually decreases with project size (Brooks 1995). Although the volume 18

of production (number of copies produced) is not as relevant to software development 19

economics, the volume of customers or users is. More customers increase the likelihood that the 20

application will be used in different contexts and that different requirements will emerge. If 21

sufficient numbers of customers have different requirements, the firm may have to either create 22

different versions of the application for different customers or develop one complicated, feature-23

rich application (“bloatware”) where any one customer uses only a small subset of the features. 24

Page 15: Aligning Software Processes with Strategy

11

The costs of coding, testing and validating such customized applications can be substantial. Even 1

if customers have similar needs, applications that will be used by a large number of customers 2

may require specialized coding and testing processes to ensure that the software will work 3

appropriately in a high-use situation. This is particularly true in an Internet environment where 4

thousands or even millions of users may use an application on any day (Jacobs 2005). 5

This discussion suggests that software development costs do relate to the degree of 6

customization of the application and of the development process as well as to aspects of volume 7

such as the number of customers. Thus, there may be sufficient similarities between software 8

development and manufacturing in terms of their underlying economics that would make it 9

advantageous to use the product-process matrix (at least ex ante) as a frame for our study and as 10

a lens to examine our research question: how are products and processes aligned with business 11

unit strategies in software development? That is, do business units with a differentiation strategy 12

develop customized Internet applications, each for a small number of customers and therefore 13

also use tailored development processes? Do other business units with a cost leadership strategy 14

develop standardized Internet applications, each for a large number of customers and therefore 15

also use standard development processes? 16

METHODOLOGY 17

To examine these questions, we conducted detailed case studies of the strategies, products, 18

and Internet application development processes in the business units of nine varied firms. Case 19

studies are ideal for research such as ours, that investigates “how” or “why” questions with a 20

focus on contemporary issues like Internet application development processes. Case studies are 21

also well suited for studying real-life events over which the researcher has little or no control, 22

like organizational strategic directions (Yin 1994). Case studies can be used in critical, 23

interpretive or positivist frameworks, although the positivist framework is the most common 24

Page 16: Aligning Software Processes with Strategy

12

(Dubé and Paré 2003). As positivist sociological research methods, case studies have been 1

characterized as natural experiments (Lee 1989a) in which researchers explore the relationships 2

between events and constructs post hoc. Like many other such positivist case studies, we do not 3

invoke the scientific language of hypothesis testing, but we do make controlled observations, 4

leverage multiple data sources, employ deductive logic, and use cross-case comparisons and 5

multiple analysis methods to promote replicability and confidence in the validity of our findings 6

(Lee 1989a, 1989b). In line with the recommendations for improving positivist case studies in IS 7

(Dubé and Paré 2003), we provide details about the rigor in our data collection and analysis 8

procedures. In the next sections, we describe our research sites, data collection and coding. 9

Research Sites 10

The firms in our study range in size from 20 employees to more than 100,000 employees and 11

are in different industries such as financial services, insurance, business services, courier 12

services, transportation, media and telecommunications. All firms have significant Internet 13

application development efforts: some are start-ups while others are “brick and mortar” firms 14

with separate Internet application development units. In each firm, the Internet applications 15

developed directly interface with customers and are part of the product or service “bundle” 16

offered to them. From the perspective of research design, our focus on one type of task (Internet 17

application development) is important because it reduces error variance in the results. While all 18

firms conduct Internet application development, their industries, products, and customers are 19

different. This variation is also a crucial aspect of our research design: since our objective is to 20

discern varied patterns of alignment of product and process strategies in Internet application 21

development, we need to consider a broad range of potential strategies. Table 2 provides a brief 22

description of each firm in the study. To protect the anonymity of the firms, we assigned 23

Page 17: Aligning Software Processes with Strategy

13

pseudonyms that reflect each firm’s primary Internet applications (products/services): Predict, 1

Utility, Incubate, Index, HR, Travel, Insure, Deliver, and Telecom. 2

Table 2: Description of Firms in Study 3 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.

Energy and Communication.

Offers B2B software-based forecasting

tools.

Mid-1990s. 20

employees.

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 prices via Internet buying pools for

customers buying utility services.

Late 1990s. 35

employees.

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.

Late 1990s. 55

employees.

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. Offers software

indexing and searching tools on

the Internet.

Mid 1990s. 80

employees.

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 Services. Provides

HR applications and services via the

Internet.

Mid 1990s. >100

employees.

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 mid-1990s. 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.

Tele-communications. Offers web-based

telecommunications services.

Before 1950 >50,000

employees

Six: Senior Manager, Project Manager,

Q/A Manager, Q/A Specialist, Web

Developers

Page 18: Aligning Software Processes with Strategy

14

Data Collection and Coding 1

Our unit of analysis is the business unit that develops and markets the firm’s Internet 2

applications.3 We conducted semi-structured interviews with managerial and technical personnel 3

at each firm to elicit details relating to the business unit strategy and the major dimensions of the 4

product-process matrix. Key informants included senior managers, product managers, project 5

managers, Internet application developers and quality assurance specialists. The informants were 6

carefully selected to provide the best source of information; thus, we directed questions 7

concerning strategy, products, and customers (i.e., “what Internet applications/services are 8

produced”) to senior managers, and questions about Internet application development processes 9

(i.e., “describe the tools you use to develop Internet applications”) to project managers, 10

developers and quality assurance specialists. We also included questions on organizational and 11

interviewee demographics to obtain a more complete understanding of the firms and individuals 12

interviewed.4 In all, as shown in Table 2, we interviewed 45 individuals in the business units of 13

the nine firms. 14

Interviews with each informant were typically two hours in length, and site visits usually 15

lasted at least four hours. The interviews were conducted by two or three researchers on the 16

team; one researcher concentrated on interviewing, while the other(s) took short hand notes using 17

laptop computers. Immediately after an interview, the notes were written out in full text, and 18

transcripts were integrated and reviewed by all of the researchers conducting the interview. 19

Having multiple investigators is an advantage in a case study because their different perspectives 20

and insights add objectivity and enhance the potential for creative and novel contributions 21

(Eisenhardt 1989). The transcripts from the interviews yielded more than 100 pages of single-22

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

Page 19: Aligning Software Processes with Strategy

15

spaced text. The interview data were complemented with secondary data about each firm’s 1

business unit strategies and other characteristics (revenues, employees, and company history) 2

that were obtained from the firms’ web sites and from publicly available information such as 3

annual financial reports or press releases. Using multiple sources of evidence is a key tactic to 4

increase construct validity in case studies and helps mitigate the potential for bias (Yin 1994). 5

For example, a manager’s description of the firm’s business unit strategy could be compared 6

with the description of the strategy on the firm’s website. 7

To guide our operationalization and coding of the four theoretical constructs determining 8

alignment (business unit strategy, the level of product customization, the level of process 9

customization, and the volume of customers) we referenced the literature on the product-process 10

framework (Safizadeh, et al. 1996; Ahmad and Schroeder 2002; Aranda 2002) and on business 11

strategy (Ward and Griffiths 1996; Porter 2001, 1980) to develop rules and procedures for 12

coding each construct.5 We identified the business unit strategy by applying the coding rules to 13

the interview statements from senior managers and publicly available information about the firm. 14

A cost leadership strategy was coded for business units that endeavored to beat competitors by 15

producing goods or services at the lowest cost, and a differentiation strategy was coded for 16

business units that sought to achieve competitive advantage by creating a product or service that 17

is unique and usually offered at a premium price (Ward and Griffiths 1996; Porter 1980). An 18

independent coder rated each firm’s business unit strategy based upon what the business unit was 19

actually doing, i.e., the unit’s strategy-in-use. In our coding, we were aware of the potential for 20

differences in the stated versus actual business unit strategies, and therefore considered multiple 21

kinds of information (interview transcripts from multiple informants, annual reports, web sites, 22

press releases, etc.) to help identify and corroborate the actual strategies-in-use executed by the 23

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}}}

Page 20: Aligning Software Processes with Strategy

16

firms’ business units for their Internet-based products. The coder also evaluated information 1

about each business unit’s major competitors, and coded the competitors’ strategies to determine 2

whether the unit’s positioning vis á vis its competitors agreed with the coded strategy. For 3

example, Predict is coded as a differentiator: its business unit provides unique services to each 4

customer and charges a premium price for these services. Utility is coded as a cost leader: its 5

business unit offers customers the lowest prices for commodity products and services by forming 6

online buying pools. As a final check of the coding, the first author also coded each firm’s 7

business unit strategy and compared the coding with that of the independent coder. There were 8

no disagreements between coders in the coding of firms’ business unit strategies. 9

The interview transcripts were the primary basis for the coding of the level of product 10

customization and the level of process customization. We developed the coding rules for each of 11

these constructs from the product-process literature (Safizadeh, et al. 1996; Ahmad and 12

Schroeder 2002; Aranda 2002) and adapted them to suit an Internet application development 13

context. For example, Predict’s “product” is a bundle of an Internet-based application and 14

services: the firm offers software tools, analyses of historical data, and advice to help utility 15

companies forecast the future energy demand of their customers. An independent coder and the 16

first author of this paper read statements in the transcripts relating to product customization and 17

process customization and coded the levels of each of these constructs. The level of product 18

customization refers to the extent to which a firm’s business unit customizes its Internet 19

application/service bundle by creating unique features to meet the needs of each customer. A 20

high level of product customization was coded when the business unit offered a unique Internet 21

application/service bundle to each customer, and a low level of product customization was coded 22

when the business unit offered a standard Internet application/service bundle to many customers. 23

The level of process customization refers to the extent to which a firm’s business unit tailors its 24

Page 21: Aligning Software Processes with Strategy

17

Internet application development process for each customer. A high level of process 1

customization was coded when the business unit tailored or adapted the development process for 2

each application or customer while a low level of process customization was coded when the 3

business unit used a standard development process. For example, for Predict, the level of product 4

customization is high because a different application is created for each utility company served. 5

The level of process customization is also high for Predict, because the development process is 6

adapted for each utility company to accommodate the nuances of each utility’s historical data 7

and legacy systems. Although the coders initially disagreed on the coding of two of eighteen 8

items, after discussion and reference to the transcripts, the coders mutually agreed upon all of the 9

final coding assignments for these constructs for each firm’s business unit. 10

Finally, the volume of customers refers to the number of customers who have purchased the 11

Internet application/service bundle. We obtained actual figures about the number of customers 12

for the Internet applications from interviews and company documentation.6 13

ANALYSIS AND RESULTS 14

We used a mixed methods data analysis approach (Tashakkori and Teddlie 1998) in which 15

we first qualitatively analyzed the coded data to visually discern patterns of product-process 16

alignment and to group business units with similar patterns together. We then quantitized the 17

coded data and performed a cluster analysis and a discriminant analysis to confirm and further 18

analyze the patterns and groups identified by the qualitative analysis. This mixed methods 19

approach offers several advantages. As Tashakkori and Teddlie (1998) have argued, the use of 20

multiple methods helps to triangulate and confirm the findings, providing more confidence in the 21

conclusions reached. In addition, using both qualitative and quantitative methods affords the 22

opportunity to leverage the benefits of each method and can enrich the insights obtained. 23

6 The figures on customer volume are in the appendix for this paper located at: {{{JAN DEGROSS}}}

Page 22: Aligning Software Processes with Strategy

18

Following the approach for cross-case qualitative analysis recommended by Miles and 1

Huberman (1984) and Yin (1994), we used pattern matching to identify similar types of 2

alignments of strategy-, customer-, product- and process dimensions across the firms’ business 3

units. The analysis involved the use of four different spreadsheets (one for each theoretical 4

construct) in which the coded data for each business unit were placed in one or more cells of the 5

unit’s particular column in the spreadsheet. We then sorted the columns of each spreadsheet so 6

that the firms’ business units were ordered from left to right by business unit strategy 7

(differentiator to cost leader), level of product customization (high to low), level of process 8

customization (high to low), and volume of customers (small to large). This enabled us to 9

visually identify patterns of alignment across constructs, to compare patterns across units, and to 10

group units with similar patterns together. For example, we observed that the business units of 11

Predict and Incubate both followed differentiator strategies and used development processes that 12

were highly customized while those of Utility and Insure both followed cost leader strategies and 13

used more standard development processes. The cross-case analysis suggested three different 14

groups of alignment patterns. One group included business units that were cost leaders with more 15

standardized products and processes; another group included business units that were 16

differentiators with more customized products and processes; and the third group included 17

business units with intermediate levels of product and process customization. 18

Our quantitative analysis leveraged cluster analysis and discriminant analysis (McLachlan 19

2004).7 Cluster analysis was used to identify groups of similar business units and to corroborate 20

the groups identified from the qualitative analysis, and discriminant analysis was used to provide 21

further corroboration of the groups and to help understand similarities and differences across 22

units and groups. We quantitized the text-based codes for business unit strategy, level of process 23

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.

Page 23: Aligning Software Processes with Strategy

19

customization, and level of product customization for each firm, transformed customer volume 1

using the natural logarithm, and input the transformed values into the analyses.8 A hierarchical 2

cluster analysis distinguished three clusters.9 The clusters were similar to those we discovered in 3

the qualitative analysis, supporting the groups of alignment patterns identified. 4

We then used discriminant analysis (McLachlan 2004) to further analyze the data. 5

Discriminant analysis identifies the fewest functions that are needed to cluster similar 6

observations and to discriminate between dissimilar observations. A discriminant function is a 7

latent variable representing a linear combination of the independent variables (in our analysis, 8

the strategy, product, process and customer variables). We specified three clusters, ex ante, in the 9

discriminant analysis using the cluster assignment for each firm’s business unit from the 10

hierarchical cluster analysis. The discriminant analysis generated two functions that 11

discriminated between the three clusters. The first function explained 98.9% of the variation 12

between clusters, and the second function explained the remaining 1.1% of the variation between 13

clusters. The functions are both statistically significant (at p < 0.01) in discriminating between 14

clusters, and each of the individual independent variables differs significantly (all at p < 0.01) in 15

mean by cluster. It is possible to interpret each discriminant function by considering its 16

correlations with each of the four independent variables. We interpreted Discriminant Function 1 17

as representing “business unit / product strategy” as it correlates significantly with business unit 18

strategy (0.812), level of product customization (-0.812) and volume of customers (0.511). 19

Discriminant Function 2 seems to capture “process strategy” as it is correlated significantly only 20

with level of process customization (-0.953). We then used each discriminant function to 21

generate a set of discriminant scores for each firm’s business unit, graphed in Figure 1. 22

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.

Page 24: Aligning Software Processes with Strategy

20

Figure 1: Graph of Firms’ Discriminant Scores 1

In Figure 1, the “x” axis represents the scores generated by Discriminant Function 1 (the 2

business unit / product strategy). Business units farther to the right on the “x” axis have more 3

standardized products and are cost leaders in a large market. Business units farther to the left on 4

the “x” axis have more customized products and are differentiators in a small market. The “y” 5

axis represents the scores generated by Discriminant Function 2 (the process strategy). Business 6

units closer to the top of the graph use more standardized processes while business units closer to 7

the bottom use more customized processes. Figure 1 also shows three distinct groups of business 8

units where each group represents a particular alignment pattern. The group assignments were 9

checked using the discriminant functions to predict each unit’s group assignment, and then the 10

prediction was compared with the unit’s original assignment from the cluster analysis. In our 11

study, the discriminant analysis matched the group assignments for each business unit as 100% 12

of the units were correctly classified (predicted assignment = original assignment); this provides 13

further support for the groups of alignment patterns we identified in the qualitative analysis. As 14

-2

-1.5

-1

-0.5

0

0.5

1

1.5

2

2.5

3

-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

PREDICT

INCUBATE

INDEX

Group Center

HR

TRAVEL

Group Center

TELECOM

Group Center

DELIVER

INSURE

UTILITYGroup #1

Group #2

Group #3

process strategy:highly customized

process strategy: highly standardized

business unit/product strategy:highly customized/differentiator/low volume

business unit/product strategy:highly standardized/cost leader/high volume

Page 25: Aligning Software Processes with Strategy

21

shown in Figure 1, Predict, Incubate and Index are in Group #1. Figure 1 also suggests that 1

Predict and Incubate are more similar in their patterns of strategy-product-process alignment 2

than Index. Still, Figure 1 indicates that Index’s pattern of alignment is more like Predict’s and 3

Incubate’s than the other business units in the other groups. The other two groups can be 4

interpreted similarly, suggesting that Telecom and Deliver are most unlike the other units in their 5

respective groups. In addition, comparing group centers suggests that Groups 1 and 3 are most 6

dissimilar as their respective group average scores are the farthest apart. 7

We then drew radial graphs (Figure 2) to visualize how each firm aligned its business unit 8

strategy, level of product customization, level of process customization and customer volume.10 9

Each graph shows the numeric rating for each firm’s business unit on each of the four theoretical 10

dimensions. A business unit is in alignment when the values for all dimensions are equal, i.e., the 11

level of differentiation in business unit strategy matches the level of customization in product 12

and process, and the volume of customers. For example, Predict is in alignment as all 13

dimensions have the same value (“1”). A business unit is out of alignment when the values for all 14

dimensions are not equal. For example, Deliver is out of alignment because its level of process 15

customization (“2”) does not equal the value of the other dimensions (“3”). The radial graphs 16

also reflect the levels of differentiation in business unit strategy, product and process, and the 17

volume of customers. Values of “1” reflect a highly differentiated strategy, customized products 18

and processes, and a low volume of customers while values of “3” reflect a cost leadership 19

strategy, more standardized products and processes, and a high volume of customers; values of 20

“2” reflect intermediate levels of these dimensions. To discern whether alignment varies across 21

groups, we arranged each radial graph into its “assigned” group from the analyses. 22

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.

Page 26: Aligning Software Processes with Strategy

22

Figure 2: Strategy-Product-Process Alignment for each Business Unit by Group 1 2 3

Group #1: Highly Customized 4

5 6 7

8 Group #2: Intermediate 9

10 11 12 13

Group #3: Highly Standardized 14

15 16

0

1

2

3

level of process standardization

level of product standardization

customers supported

cost leadership strategy

PREDICT

0

1

2

3

level of process standardization

level of product standardization

customers supported

cost leadership strategy

INCUBATE

0

1

2

3

level of process standardization

level of product standardization

customers supported

cost leadership strategy

HR

0

1

2

3

level of process standardization

level of product standardization

customers supported

cost leadership strategy

TRAVEL

0

1

2

3

level of process standardization

level of product standardization

customers supported

cost leadership strategy

UTILITY

0

1

2

3

level of process standardization

level of product standardization

customers supported

cost leadership strategy

INSURE

1

2

3

level of process standardization

level of product standardization

customers supported

cost leadership strategy

DELIVER

0

1

2

3

level of process standardization

level of product standardization

customers supported

cost leadership strategy

INDEX

0

1

2

3

level of process standardization

level of product standardization

customers supported

cost leadership strategy

TELECOM

Page 27: Aligning Software Processes with Strategy

23

Comparing the radial graphs in Figure 2 by group shows that the business units in Group #1 1

are the most highly differentiated; the business units in Group #3 are the most standardized; and 2

the business units in Group #2 have intermediate levels of differentiation. This suggests that the 3

business units have distinct patterns of alignment for their business unit strategies, products and 4

processes. Figure 2 also shows that six of the nine business units in the firms in our study do 5

align their strategies as predicted. The radial graphs for Predict and Incubate in Group #1 6

suggest that they pursue differentiation strategies, have highly customized products and 7

development processes, and relatively small volumes of customers. At the other end of the 8

extreme in Group #3, Insure and Utility pursue a cost leadership strategy, and have more 9

standard products and development processes, and a larger volume of customers. The strategies 10

used by HR and Travel in Group #2 reflect intermediate levels of differentiation in business unit 11

objectives, product characteristics and Internet application development processes. The 12

respective customer volumes are larger than those of Predict and Incubate, but smaller than 13

those of Insure and Utility. Figure 2 also shows that Index, Telecom and Deliver are “out of 14

alignment” in that some aspect of their business unit strategies, products, processes or customer 15

volumes does not align as expected. We integrate and interpret these results in the Discussion. 16

DISCUSSION 17

Overall, we find that the dynamics of the product-process framework are relevant in software 18

development as software process choices are aligned with product characteristics, customer 19

volume, and business unit strategies for many of the firms. However, some units are not in 20

alignment. We first examine how units that are in alignment configure detailed dimensions of 21

their products and processes. We then consider the business units that are misaligned. 22

Page 28: Aligning Software Processes with Strategy

24

Business Units in Alignment 1

Consistent with the product-process framework, for the business units in alignment, a 2

customized development process is used when the volume of customers is small, and there are 3

highly differentiated needs. A more standard development process is used when there are 4

sufficient common needs that applications can be developed to serve a larger number of 5

customers. To provide a deeper understanding of how the business units align elements of their 6

products and processes, we use Concept Maps. Concept maps organize and represent concepts 7

(events or objects) and their inter-relationships in a particular domain or context (Novak 1998). 8

Relationships between concepts are associative. Concept maps were originally developed to help 9

understand how children learn. Recently, concept maps have been used to conduct qualitative 10

data analysis (Daley 2004) where the researcher draws the concept map, and uses it to visually 11

identify themes and patterns, display linkages, and facilitate cross group or site comparisons. 12

Following the approach suggested by Daley (2004) and the techniques developed by Novak 13

(1998), we developed concept maps to visually represent concepts for the business units in 14

alignment. Consistent with the literature on concept mapping, we created concept maps with the 15

broader, more inclusive concepts at the top of the hierarchy, connecting with other more detailed 16

concepts below. Given our goals of evaluating alignment between business unit, product and 17

process strategies, we deductively identified the main concept categories and their associations 18

based on the primary aspects of the product-process matrix: (1) Customer Requirements relate to 19

Product characteristics; (2) Products are developed using Process elements; (3) Development 20

Process is using People related process elements; (4) Development Process is using Practices 21

related process elements; (5) Development Process is using Architecture related process 22

elements; and (6) Process Elements relate to Outcomes. We further refined the development 23

process category using software development reference models, such as the CMM to help 24

Page 29: Aligning Software Processes with Strategy

25

identify people-related, practices-related and architecture-related concepts. We also referenced 1

the ISO standard for software quality (ISO 9126) to help identify outcomes concepts. Then, we 2

analyzed the interview transcripts to surface the detailed concepts within each category or sub-3

category. For example, team role diversity and scalability emerged as concepts from the 4

interview transcripts in response to questions on people-related process choices and on 5

outcomes, respectively. Team role diversity refers to the number of different roles on an Internet 6

application development team. Scalability indicates whether the Internet application architecture 7

can be scaled for high volume usage.11 8

In the following sections, we present and discuss concept maps for two groups of business 9

units: those using a highly customized Internet application development process and those using 10

a more standard process (Groups #1 and #3 in Figure 1, respectively). We also provide examples 11

of business units that are using each of these development processes. Finally, we present and 12

discuss an overall concept map that illustrates the general concepts and associations between 13

product and process alignment in Internet application development. 14

Concept Map for the Highly Customized Development Process. Figure 3 depicts the concept 15

map for a highly customized Internet application development process that is used by business 16

units pursuing a differentiation strategy. This concept map is exemplified by Predict. Predict 17

targets a small set of utility customers who have unique and particular requirements. Each utility 18

transmits historical data on energy consumption patterns, and Predict develops a customized, 19

business-to-business Internet-based application for each utility to forecast future consumption 20

patterns. Because the data and requirements are quite different for each utility, Predict must 21

develop a different application for each utility, often using a different development process: “We 22

have about 150 utility customers. The companies each send us their energy consumption data. And, we provide 23

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}}}

Page 30: Aligning Software Processes with Strategy

26

them with an analysis and prediction of future energy needs. But, the data feeds in and out are unstable... we are 1

dealing with each customer’s antiquated legacy systems...If we ever had something that worked the same way twice 2

– that would be stability. We have about 150 different development processes” (Senior Manager, Predict). 3

Figure 3: Concept Map of Highly Tailored Development Process 4

5 There is a reliance on gurus because to serve customers in Predict’s unique market niche 6

requires specialized knowledge of the particular utility and the utility’s data and systems as well 7

as complex skill sets including advanced statistics and financial engineering. The development 8

process also requires the use of small teams of specialists. The use of gurus makes it difficult to 9

transfer knowledge, and the learning curve for new employees is steep and long. There is almost 10

no reuse of software code; in fact Predict uses redundant coders, i.e., two developers 11

independently code each application for each customer. This is done to minimize errors and bias 12

cus tom ers

few

haveare

h igh varie ty o fp roduc t fea tu res

are developed using

re la tes to

peop le practices arch itec tu re

sm all team s gurus

outcom es

long lea rn ingcu rves

little know ledgetrans fe r

are

a re

re la te tore la te to

w ork ona re

is us ing

p ro to typ ing

little code reuse

m any phases

areare

a re

outcom es

re la tes tore la tes to

re la te to

h igh flex ib ility

low fo rm a litylong cyc le tim e

low pe rvas iveness

are

are

are

are

is us ingis us ing

cus tom des igned

little reuse

outcom es

re la tes tore la tes to

poor sca lab ility

little legacyin tegra tion

are

a re

heterogeneousrequ irem en ts

re la te to

ta ilo red deve lopm ent p rocess

is

has

Page 31: Aligning Software Processes with Strategy

27

in the consumption prediction models developed. The software code is discarded if there are 1

mistakes or problems: “We throw away and re-build for each customer. We’re very adaptive, which is stressful 2

on employees who don’t adapt” (Senior Manager, Predict). Prototyping is used to understand user 3

requirements. Custom architecture design, limited reuse of design artifacts, and little legacy 4

integration also characterize this mode of development. 5

Concept Map for the Highly Standardized Development Process. Figure 4 shows the 6

concept map for the more standardized Internet application development process that is used by 7

business units pursuing a cost leadership strategy. Utility typifies this concept map. Utility uses 8

the Internet to organize customers into large buying pools and facilitate low cost purchase of 9

services such as electricity, natural gas, home security, and health insurance. There are sufficient 10

standard features across the buying pools that the business unit can standardize its Internet 11

applications and reuse software across the different market segments: “We are always making 12

generalizations across the vertical markets even though there are different products, different markets and different 13

interfaces. The whole reuse perspective goes across the verticals…. We retrofit good features, repeating one across 14

the others… our development strategy is to standardize and reuse software across vertical markets…” (Manager, 15

Utility). The commonalities amongst its customers and products enable Utility to use a standard 16

development process, and in fact, the unit leverages the traditional, sequential waterfall approach 17

to software development, albeit at “Internet speed”: “We use the ‘staircase’ method to develop. Internet 18

speed development is very similar to traditional development – we still need to gather requirements, there’s a life 19

cycle. But, the response time is much quicker. The process is like a ‘quick waterfall’” (Project Manager, Utility). 20

Because the software features and processes are more standard and can be reused across market 21

segments, there is less need for specialized knowledge, and less reliance on gurus: “Some wear 22

multiple hats. Project leaders could be from technology, business or operations, and there isn’t always someone 23

tagged as the ‘leader’” (Project Manager, Utility). The software architecture plays a critical role in 24

Page 32: Aligning Software Processes with Strategy

28

standardizing and reusing applications across market segments: “We have designed a three tier 1

architecture (presentation layer, application layer, database layer). The objective is to make an open, modular and 2

scalable architecture. Because there is a vision, it allows us to create good technologies that are scalable. We can 3

easily ratchet up or down in the scale” (Manager, Utility). Short cycle times, and high scalability, 4

robustness and portability also characterize this mode of development. 5

Figure 4: Concept Map of Highly Standardized Development Process 6

7 Concept Map for Product-Process Alignment. We further abstracted the elements in the 8

concept maps to create a more general concept map of product and process alignment in Internet 9

application development (Figure 5). As shown in Figure 5, the level of requirements diversity 10

relates to the variety of product features, and together with the volume of demand for 11

requirements influences the type of development process selected. 12

c u s to m e rs

m a n y

h av e a re

a re d ev e lo pe d u s ing

re la tes to

p e o p le p ra c tic e s

g e n e ra lis ts fe w ro le s

o u tco m e s

sh o rt le a rn in gcu rve s

h ig h k n o w le d g etra n s fe r & re -u s e

a re

a re

re la te tore la te to

a reha ve

is us ing

a re

a rea re

o u tc o m e s

re la te s to

re la te s to re la te to

lo w fle x ib ility

s h o rt c yc le tim e

h ig h p e rva s ive n e s s

a re

a re

a re

a re

is us ingis us ing

m o d u la r d e s ig n

h ig h re u s e

o u tc om e s

re la te s tore la te s to

h ig h s c a la b ility

are

h om o g e n e o u sre q u ire m e n ts

re la te to

h a s

ha s

e a s y cu s to m iz a tio n

lo w va rie ty o fp ro d u c t fe a tu re s

inc re as e n ee d fo r

m a y req u ire

s ta n d a rd d e ve lo p m e n t p ro c e s s

a rc h ite c tu re

h ig h fo rm a lity

are

h ig h p o rta b ility

ro b u s tn e ss

are

a re

so m e le g a c yin te g ra tio n

a re

re la tes toC O T S u s e

c o d e re u s e fe w p h a s e s

w a te rfa ll

Page 33: Aligning Software Processes with Strategy

29

Figure 5: Concept Map of Product-Process Alignment 1

2 The process choices relate to the people, practices and architecture used in development. The 3

type of expertise on a team (specialists versus generalists) is influenced by the variety and scale 4

of use of product features. When customer requirements are more standard or can be generalized, 5

less specialized knowledge is required as developers can follow the standard design and can 6

reuse existing code. Thus, teams of generalists can be used. In contrast, when customer 7

requirements are highly differentiated, more specialized knowledge is required, and there is more 8

reliance on “gurus”. Similarly, the practices followed are also shaped by these factors. When 9

product features are standardized, software can be readily reused across products, but when 10

product features are customized, there may not be sufficient commonalities to enable code reuse. 11

cus tom ers

requ irem en tsdem and

have have

are deve loped us ing

re la tes to

ro le d ive rs ity

leng th o flea rn ing cu rve

exten t o f know ledgetrans fe r & re -use

are

are

re la tes tore la tes to

havehave

is us ing

a re

a rea re

ou tcom es

re la tes to

re la tes to

re la te to

fle x ib ility

cyc le tim e

pervas iveness

are

a re

a re

a re

is us ingis us ing

ou tcom es

re la tes tore la tes to

sca lab ility

are

requ irem entsd ive rs ity

re la tes to

hashas

va rie ty o fp roduc t fea tu res

type o f de ve lopm en t p rocess

a rch itec tu re

fo rm a lity

are

portab ility

robus tness

area re

exten t o f legacyin teg ra tion

are

re la tes to

exten t o fC O T S use

ex tent o fcode reuse

# & sequenceo f phases

m ethodo logy type

peop le

ou tcom es

team s ize

re la tes to

a re ontype o f

expertise

p rac tices

ex ten t o freuse

des ign type

Page 34: Aligning Software Processes with Strategy

30

Prototyping (not a standard waterfall process) may be needed to discover customers’ unique 1

needs. Finally, when customer requirements can be generalized across markets or products, a 2

modular architecture can be designed to be robust, scalable and portable. Process characteristics 3

further define associated outcomes. The extent of knowledge transfer and reuse relates to people-4

related practices such as the use of specialists or generalists, and team role diversity and size. 5

Similarly, the length of the learning curve is associated with the same choices, e.g., the more 6

specialized the knowledge requirements and skill sets, the longer the learning curve for new 7

hires. For development process, the flexibility, formality, pervasiveness and cycle time of the 8

process are associated with the type of development methodology, the number and sequence of 9

phases, reuse of software code, and use of off-the-shelf components and tools. For example, code 10

reuse and parallel development facilitate short cycle times. Finally, the portability, scalability 11

and robustness of the architecture relate to specific practices such as use of modular architecture 12

frameworks and tools, and design reuse. 13

Business Units Out of Alignment 14 15

While many business units in our study are “in alignment”, three are “out of alignment”. To 16

determine precisely why these units are misaligned is beyond the scope of this study. 17

Nevertheless, we can draw upon the literatures motivating this study to suggest why the units 18

may be misaligned. According to Porter (1980), when a business unit tries to be both a cost 19

leader and a differentiator in the same market or when a business unit switches between these 20

strategies over time, it can become “stuck in the middle”. The basic strategies are incompatible 21

because cost leadership focuses on cost advantages of production (being the low cost producer 22

for a given level of quality) while differentiation focuses on satisfying unique customer needs 23

and de-emphasizing price (often generating a higher than average price). Since successfully 24

executing each of the basic strategies involves different resources, strengths, organizational 25

Page 35: Aligning Software Processes with Strategy

31

arrangements and managerial styles, it is unlikely that a business unit can realize both strategies. 1

Even if a business unit can achieve both strategies in the same market, it risks projecting a 2

confusing image to the customer and can fail to attain the benefits from either. 3

Being stuck in the middle may describe, in part, what is happening at Index. Founded by 4

computer scientists, the firm’s focus historically was on technological product innovation. In the 5

past, the firm’s business unit was a differentiator and used highly-tailored development 6

processes, customizing its products to the unique needs of a few major customers. However, 7

since Index has started offering its products on the Internet, there has been pressure to shift its 8

strategy to appeal to a broader range of customers in new markets and bring in greater revenues. 9

This shift has generated some confusion in the unit’s strategic direction: “We said we needed to be 10

present on the Internet. From then on we have changed the focus on customers, markets, and what products we are 11

selling. Lately there is more churn, changing focus of products, the market we want to be in” (Manager, Index). 12

The changes in Index’s business unit strategy are not fully reflected in its software product and 13

development process strategies. The radial graph for Index in Figure 2 shows that although the 14

business unit strategy reflects an intermediate level of differentiation as the firm tries to 15

commoditize its products, the product and development process strategy continue to reflect high 16

levels of customization: “We provide everything from turnkey solutions to custom solutions. Customers can give 17

us a crate of "X" and say, do whatever you have to with this. Or we may be asked to put together a complete 18

configuration that the customers can use with their own content. Other customers are in between. There are also 19

variations in the types of products and services...” (Manager, Index). 20

The product-process literature also suggests why business units can be misaligned. 21

According to Hayes and Wheelwright (1984, 1979b) the product-process matrix reflects the 22

alignment (or misalignment) of a firm’s competitive priorities, products and processes at a point 23

in time. Thus, a misaligned business unit may be in transition. However, Hayes and Wheelwright 24

Page 36: Aligning Software Processes with Strategy

32

assert that being in transition should be temporary. Business units that are misaligned are less 1

efficient and effective because marketing and production are pursuing different objectives, and 2

the unit cannot leverage economies of scale. Alignment (being “on the diagonal”) should thus be 3

the steady-state condition. So, why do business units move “on” or “off” the diagonal of the 4

matrix? Hayes and Wheelwright (1979b) offer an organizational learning explanation that relates 5

to the theories of March (1991). March developed the concept of balancing exploration and 6

exploitation as strategies for organizational learning. Exploration involves searching, 7

experimentation, developing variation, taking risks, and discovering new knowledge. 8

Exploration strategies develop variation, and the returns are usually uncertain. In contrast, 9

exploitation involves selection, refinement, production, and efficiency. Exploitation strategies 10

refine existing knowledge, and the returns are usually certain. In the product-process matrix, 11

business units that move down (but on) the diagonal are leveraging both exploration- and 12

exploitation-based learning in a balanced way within their existing markets. The units are 13

exploiting the learning curve to become more efficient in their processes, but are maintaining 14

some flexibility to respond to market changes, and are also innovating their products. 15

Business units that innovate the product more than the process (are above the diagonal) can 16

follow dynamic market movements quickly, but at the cost of reduced process efficiency. One 17

issue here is that a unit can get trapped if it tries to innovate existing products to appeal to new 18

markets. At first this strategy may work, but eventually the unit’s existing process will not be 19

able to accommodate the added scale and complexity of new products without additional 20

investment. The unit may then have to innovate the process, but to recoup the investment it has 21

to pursue additional markets, and this requires more product innovation, and starts the cycle all 22

over again. This may also describe what is happening at Index. Despite pressures for 23

commoditization, the business unit’s products have not matured into a commodity that appeals to 24

Page 37: Aligning Software Processes with Strategy

33

a large enough number of customers: “We tried to have one product for all segments... but when they see the 1

product, the customers came back and said, ‘this is cool but we like this other feature too’. And then we get extra 2

requirements for features. It is hard to say no to customers” (Manager, Index). Thus, the unit cannot adopt 3

a more standardized process because there are too few similarities among the features of the 4

various products. As a result, Index devotes resources to innovate the product, searching for a 5

variation that will appeal to a large enough customer volume to begin exploiting the product and 6

standardize a process to compete in a moderately differentiated marketplace. 7

A related, but somewhat different phenomenon may be driving misalignment at Deliver. 8

Deliver is a brick and mortar company with a cost leadership strategy in the business unit that is 9

implementing a web-based interface for its standard applications. In the jargon of the product-10

process matrix, the company is expanding the scope of its process through forward integration by 11

connecting its applications directly to its customers via the Internet. One potential issue is that 12

expanding process scope can result in producing a product that is not consistent with existing 13

product lines and processes in other business units: “Our business strategy is not clearly aligned with our 14

application development strategy. For example, we may develop an application which may end up cannibalizing 15

market share from another product” (Manager, Deliver). The business unit uses a more ad-hoc process 16

than has been used in the past for software development, and this process is misaligned with the 17

business unit’s cost leadership strategy as shown in Figure 2. A particular problem for Deliver is 18

the lack of a coherent, standard and modular architecture for its Internet applications: “There is no 19

end-to-end view of the system and no time for thinking through the architecture. It’s really messy and it doesn’t scale 20

up. The architecture is changing constantly – it is very fluid and dynamic” (Architect, Deliver). Instead, 21

developers rely on wrappers (“glue code”) to link together disparate software components in an 22

ad-hoc fashion. This process contributes to a lack of portability and scalability in the 23

architecture, critical concerns given Deliver’s large volume of customers. 24

Page 38: Aligning Software Processes with Strategy

34

Business units that innovate the process more than the product (are below the diagonal) push 1

the process toward standardization and can realize the fastest learning rates by exploiting process 2

efficiencies. However, the process can become inflexible and difficult to modify. This may 3

explain why Telecom is out of alignment. As shown in Figure 2, Telecom is misaligned because 4

its standardized process does not fit with its business unit strategy. This misalignment may be 5

ascribed, at least in part, to the fact that Internet application development was outsourced from 6

Telecom. To leverage economies of scale across engagements, outsourcing vendors often use a 7

standard methodology (Levina and Ross 2003). The outsourcing vendor for Telecom also 8

attempted to implement a standard methodology. However, because Telecom is a major client, 9

the vendor created a separate business unit for Telecom’s IT projects, and that unit was working 10

in a specialized industry with somewhat unique needs. The unit’s developers were struggling to 11

use the standard development process for new Internet applications: “The technology is so visual, it is 12

easy for end users to picture what they want. But, each person wants something different… so, even though we have 13

an overall methodology, it can be difficult to standardize processes” (Relationship Manager, Telecom). In an 14

example of adaptive exploitation, the developers tailored the standard methodology and adopted 15

a more flexible assembly approach, decoupling the standard processes, using parallel 16

development, and reusing standard architecture frameworks and designs where appropriate. 17

CONCLUDING REMARKS 18

This study addresses an important issue for businesses in the 21st century: how should work 19

processes that create knowledge products be aligned with business strategies in a competitive 20

environment transformed by new technologies. This issue is particularly salient in software 21

development because software is a valuable and well-defined example of a knowledge product. 22

Software development can test and challenge the general theories derived from the experience of 23

making physical products. Indeed, there is a long tradition of considering software development 24

Page 39: Aligning Software Processes with Strategy

35

from the perspective of manufacturing (e.g., TQM and CMM, software factories, component-1

based development) and of applying theories and frameworks (like the product-process matrix) 2

from manufacturing to examine and understand software development issues. 3

A central insight of our study is that, consistent with the product-process matrix, software 4

process does depend on how a firm competes, and especially on competitive choices relating to 5

product variety. The variety of product requirements may be crucial in determining the type of 6

software processes that can be deployed. Business units in the firms we studied such as Predict 7

(with its 150 different development processes) and Index (with its struggles to commoditize its 8

product) clearly reflect the challenges encountered in achieving consistent development 9

processes when the applications developed are highly customized. This suggests a tension 10

between the costs and benefits of software customization. On the one hand, customizing a 11

software product can attract new customers and can distinguish a firm from its competitors. On 12

the other hand, it may be more costly to customize than to standardize. One may question 13

whether these cost differences are as significant for software development. Software is intangible 14

and more easily adapted than a physical product. Also, software processes may be more 15

adaptable than manufacturing processes bound by machinery, raw materials and physical plants. 16

Finally, technologies such as agile methods and modular architectures may make it less costly to 17

customize and adapt development processes. Nevertheless, two firms in our study chose to 18

standardize their development processes and Internet applications (Utility and Insure). One firm 19

(Index) aspired to standardize its Internet applications, and another (Telecom) tried to leverage 20

the corporate standard development methodology even if it was not best suited to a particular 21

engagement. This implies that customizing products and processes is not “free” in software 22

development. An important direction for future research is to examine the economics of software 23

Page 40: Aligning Software Processes with Strategy

36

customization, and particularly over the software life cycle, as the costs of supporting highly 1

customized applications may be even more significant than the development costs. 2

Our study contributes to the IS literature by offering detailed configurations of software 3

development processes that can be aligned with certain types of business unit strategies, 4

supported by empirical evidence from case studies. The IS strategy literature has examined 5

alignment at a more macro level. However, given the many choices for software development 6

and the notion that “one size may not fit all” projects (Shenhar 2001), it is important to examine 7

alignment decisions at a more micro or operational level. But, like any empirical study, ours has 8

some limitations. We have focused on whether and how firms align their business unit strategies, 9

software applications and development processes. This enabled us to provide detailed insights 10

into the ways in which different dimensions are matched. However, our cross-sectional research 11

design did not allow us to examine why business units are misaligned and what are the 12

consequences. Future studies should investigate alignment decisions over time as markets, 13

products, and processes mature. In addition, research is needed to discern the performance 14

consequences of alignment or misalignment. Finally, we have studied alignment in Internet 15

application development contexts. This focused research design constitutes a control in our 16

study; however, our findings may be limited to Internet application development. It is possible 17

that our results could generalize to other software development contexts, especially where the 18

applications developed are tightly linked to the customer and are part of the bundle offered to the 19

customer. No single study is definitive; thus, the external validity of our results can be 20

strengthened by future research on alignment between software development and business 21

strategies in other application domains and development contexts. 22

REFERENCES 23

Ahmad, S., Schroeder, R., “Refining the Product-Process Matrix,” International Journal of 24 Operations and Production Management, (22:1), 2002, 103-124. 25

Page 41: Aligning Software Processes with Strategy

37

1 Aranda, D. “Relationship Between Operations Strategy and Size in Engineering Consulting 2 Firms,” International Journal of Service Industry Management, (13:3-4), 2002, 263-285. 3 4 Banker, R., Datar, S., Kemerer, C. ”A Model to Evaluate Variables Impacting the Productivity of 5 Software Maintenance Projects,” Management Science, (37:1), 1991, 1-18. 6 7 Banker, R., Davis, G., Slaughter, S. ”Software Development Practices, Software Complexity and 8 Software Maintenance Performance,” Management Science, (44:4), 1998, 433-450. 9 10 Brooks, F. The Mythical Man Month, (Anniversary ed.), Reading, MA: Prentice-Hall, 1995. 11 12 Brown, S., Blackmon, K. “Aligning Manufacturing Strategy and Business-Level Competitive 13 Strategy in New Competitive Environments,” Journal of Management Studies, (42:4), 2005, 14 793-815. 15 16 Calinski, T., Harabasz, J. “A Dendrite Method for Cluster Analysis,” Communications in 17 Statistics, (3), 1974, 1-27. 18 19 Cameron, J. “Configurable Development Processes,” Communications of the ACM, (45:3), 2002, 20 72-77. 21 22 Conallen, J. Building Web Applications with UML, Addison-Wesley, Boston, MA, 2000. 23 24 Daley, B. “Using Concept Maps in Qualitative Research,” in Proc. of the First Int. Conference on 25 Concept Mapping, A. Cañas, J. Novak, F. González, Eds., Pamplona, Spain, 2004. 26 27 Deck, M. “Managing Process Diversity While Improving your Practices,” IEEE Software, May-28 June, 2001, 21-27. 29 30 Dubé, L., Paré, G. ”Rigor in Information Systems Positivist Case Research: Current Practices, 31 Trends, and Recommendations,” MIS Quarterly, (27:4), 2003, 597-635. 32 33 Eden, C., Ackermann, F. Making Strategy: The Journey of Strategic Management, Sage, 1998. 34 35 Eisenhardt, K. “Building Theories from Case Study Research,” Academy of Management 36 Review, (14:4), 1989, 532-550. 37 38 Farjoun, M. “Towards an Organic Perspective on Strategy,” Strategic Management Journal, 39 (23:7), 2002, 561-594. 40 41 Fitzgerald, B., Russo, N., O’Kane, T. “Software Development Method Tailoring at Motorola,” 42 Communications of the ACM, (46:4), 2003, 65-70. 43 44 Grover, V., Malhotra, M. “A Framework for Examining the Interface between Operations and 45 Information Systems,” Decision Sciences, (30:4), Fall 1999, 901-920. 46 47

Page 42: Aligning Software Processes with Strategy

38

Hayes, R., Wheelwright, S. Restoring our Competitive Edge: Competing through Manufacturing, 1 Wiley, New York, 1984. 2 3 Hayes, R., Wheelwright, S. “Link Manufacturing Process and Product Life Cycles,” Harvard 4 Business Review, (57:1), 1979a, 133-140. 5 6 Hayes, R., Wheelwright, S. “The Dynamics of Process-Product Life Cycles,” Harvard Business 7 Review, (57:2), 1979b, 127-136. 8 9 Heim, G., Sinha, K. “A Product-Process Matrix for Electronic B2C Operations: Implications for 10 the Delivery of Customer Value,” Journal of Service Research, (3:4), 2001, 286-299. 11 12 Heim, G., Sinha, K. “Service Process Configurations in Electronic Retailing,” Production and 13 Operations Management, (11:1), 2002, 54-74. 14 15 Hill, T. Manufacturing Strategy, MacMillan, New York, 2001. 16 17 Huete, L., Roth, A. “The Industrialization and Span of Retail Banks’ Delivery Systems,” 18 International Journal of Operations and Production Management, (8:3), 1988, 46-86. 19 20 Jacobs, D. “Enterprise Software as Service,” Queue, July/August, 2005, 36-42. 21 22 Kathuria, R., Anandarajan, M., Igbaria, M., “Linking IT Applications with Manufacturing 23 Strategy,” Decision Sciences, (30:4), 1999, 959-991. 24 25 Kemerer, C. ”How the Learning Curve affects Case Tool Adoption,” IEEE Software, (9:3), 1992, 26 23-28. 27 28 Kothe, S., Orne, D. “Generic Manufacturing Strategies: A Conceptual Synthesis,” Strategic 29 Management Journal, (10:3), 1989, 211-231. 30 31 Krajewski, L., Ritzman, L. Operations Management, 7th ed., Prentice-Hall, Englewood Cliffs, 32 NJ, 2005. 33 34 Kriebel, C., Raviv, A. ”An Economics Approach to Modeling the Productivity of Computer 35 Systems,” Management Science, (26:3), 1980, 297-311. 36 37 Lee, A. ”Case Studies as Natural Experiments,” Human Relations, (42:2), 1989a, 117-137. 38 39 Lee, A. ”A Scientific Methodology for MIS Case Studies,” MIS Quarterly, (13:1), 1989b, 33-50. 40 41 Levina, N., Ross, J. “From the Vendor's Perspective: Exploring the Value Proposition in IT 42 Outsourcing," MIS Quarterly (27:3), 2003, 331-364. 43 44 March, J. ”Exploration and Exploitation in Organizational Learning,” Organization Science, 45 (2:1), 1991, 71-87. 46 47

Page 43: Aligning Software Processes with Strategy

39

McLachlan, G. Discriminant Analysis and Statistical Pattern Recognition, Wiley-Interscience, 1 New York, 2004. 2 3 Miles, R., Snow, C. Organizational Strategy, Structure, and Process, McGraw-Hill, New York, 4 1978. 5 6 Miles, M., Huberman, A. Qualitative Data Analysis: An Expanded Sourcebook, 2nd ed., Sage 7 Publications, Beverly Hills, CA, 1984. 8 9 Mintzberg, H., Ahlstrand, B., Lampel, J. Strategy Safari: A Guided Tour Through the Wilds of 10 Strategic Management. Prentice Hall, London, 1998. 11 12 Nidumolu, S., Knotts, G. ”Effects of Customizability and Reusability on Perceived Process and 13 Competitive Performance of Software Firms,” MIS Quarterly, (22:2), 1998, 105-137. 14 15 Novak, J. Learning, creating and using knowledge: Concept Maps™ as facilitative tools in 16 schools and corporations. Mahwah, NJ: Lawrence Erlbaum Associates, 1998. 17 18 Panzar, J., Willig, R. ”Economies of Scope,” American Economic Review, (71:2), 1981, 268-272. 19 20 Panzar, J., Willig, R. ”Economies of Scale in Multi-output Production,” Quarterly Journal of 21 Economics, (91), 1977, 481-493. 22 23 Paulk, M., Curtis, B., Chrissis, M., Weber, C. “Capability Maturity Model, Version 1.1,” IEEE 24 Software, (10:4), 1993, 18-27. 25 26 Porra, J. ”Electronic Commerce Internet Strategies and Business Models,” Information Systems 27 Frontiers, (1:4), 2000, 389-399. 28 29 Porter, M. “Strategy and the Internet,” Harvard Business Review, (79:3), 2001, 63-78. 30 31 Porter, M. “What is Strategy?” Harvard Business Review, (74:6), 1996, 61-78. 32 33 Porter, M. Competitive Strategy: Techniques for Analyzing Industries and Competitors, New 34 York: Free Press, 1980. 35 36 Porter, M., Millar, V. “How Information Gives you Competitive Advantage,” Harvard Business 37 Review, (63:4), 1985, 149-160. 38 39 Pralahad, C., Hamel, G. “The Core Competence of the Corporation,” Harvard Business Review, 40 (68:3), 1990, 79-91. 41 42 Sabherwal, R., Chan, Y. “Alignment between Business and IS Strategies: A Study of 43 Prospectors, Analyzers, and Defenders,” Information Systems Research, (12:1), 2001, 11-33. 44 45 Sabherwal, R., Hirschheim, R., Goles, T. “The Dynamics of Alignment: Insight From a 46 Punctuated Equilibrium Model,” In R. Galliers and D. Leidner (eds.) Strategic Information 47 Management, 3rd ed., Butterworth Heinemann, 2003. 48

Page 44: Aligning Software Processes with Strategy

40

1 Sacks, M. On-the-job learning in the software industry, Westport, CT: Quorum Books, 1994. 2 3 Safizadeh, M., Ritzman, L., Sharma, D., Wood, C. “An Empirical Analysis of the Product-4 Process Matrix,” Management Science, (42:11), 1996, 1576-1591. 5 6 Shapiro, C., Varian, H. Information Rules: A Strategic Guide to the Network Economy, Harvard 7 Business School Press, Boston, MA, 1999. 8 9 Shenhar, A. “One Size Does Not Fit All Projects: Exploring Classical Contingency Domains,” 10 Management Science, (47:3), 2001, 394-414. 11 12 Slaughter, S., Harter, D., Krishnan, M. “Evaluating the Cost of Software Quality,” 13 Communications of the ACM, (41:8), 1998, 67-73. 14 15 Tapscott, D. "Rethinking Strategy in a Networked World (or Why Michael Porter is Wrong 16 about the Internet)", Strategy+Business, 3rd Quarter, 2001, http://www.strategy-business.com. 17 18 Tapscott, D., Ticoll, D. Lowy, A. Digital Capital: Harnessing the Power of Business Webs, 19 Harvard Business School Press, Boston, MA, 2000. 20 21 Tashakkori, A., Teddlie, C. Mixed Methodology: Combining Qualitative and Quantitative 22 Approaches, Thousand Oaks, CA: Sage, 1998. 23 24 Teece, D., Pisano, G., Shuen, A., “Dynamic Capabilities and Strategic Management,” Strategic 25 Management Journal, (18:7), 1997, 509-533. 26 27 Varian, H., Intermediate Microeconomics: A Modern Approach, 6th ed., W. Norton, 2002. 28 29 Venkatraman, N. “Five Steps to a dot.com Strategy: How to Find your Footing on the Web,” 30 Sloan Management Review, (41:3), 2000, 15-28. 31 32 Wade, M., Hulland, M., “The Resource-based View and Information Systems Research: Review, 33 Extension and Suggestions for Future Research,” MIS Quarterly, (28:1), 2004, 107-142. 34 35 Ward, J., Griffiths, P. Strategic Planning for Information Systems, Wiley, New York, 1996. 36 37 Weill, P., Broadbent, M. Leveraging the New Infrastructure: How Market Leaders Capitalize on 38 Information Technology, Harvard Business School Press, Boston, MA, 1998. 39 40 Wheelwright, S. “Manufacturing Strategy: Defining the Missing Link,” Strategic Management 41 Journal, (5:1), 1984, 77-91. 42 43 Yin, R. Case Study Research: Design and Methods, 2nd ed., Sage, Thousand Oaks, CA, 1994. 44