Printer Friendly

Designing cost-competitive technology products through cost management.

SYNOPSIS: As manufacturing innovations spread throughout leading organizations, product development becomes a more important source of competitive advantage. Within product development, cost management receives increasing attention. To date, cost management in new product development focuses primarily on target costing, a management practice used inside the product development process by the development team. Although this practice is appropriate for products competing mainly on costs, it presents several limitations when factors such as technology, time-to-market, or customer needs are more pressing. Based on observations from a field study of product development cost practices in high-technology firms and evidence from field studies described elsewhere, this paper identifies alternative practices to manage costs during product development. These alternative practices that facilitate cost management around the projects rather than managing costs inside product development projects are: parallel cost management teams, modular design for cost, clearly defined cost management strategies and cost policies, and product portfolio planning. Companies in our sample use them to manage costs during product development, when cost management is most effective, but still keep the attention of development teams focused on the critical success factors of time-to-market, technology, and customer needs.

INTRODUCTION

A significant portion of the profits that a product generates over its life is determined before the product reaches the market (Wheelwright and Clark 1992; Yli-Renko et al. 2001). During the product development stage, the organization designs the features that (1) give the product an edge over competing offerings and (2) affect the costs that will shape profit margins. Product design significantly affects the revenue side--technological performance, customer appeal, and timely market introduction--before the first unit is sold. The cost side follows a similar pattern; as a rule of thumb, 80 percent of the costs are engineered in during product development (Blanchard 1978; Cooper and Slagmulder 1997).

This paper examines practices other than target costing that high-technology companies use to manage costs during product development and provides tentative explanations for the desirability of these practices. These practices manage costs during product development but around the development team rather than inside it as target costing does. Following Young's (1999) classification of field research, the paper also intends to "raise new research questions."

Moving cost management efforts from the production stage to the product development stage translates into larger profits because cost reduction advantages accrue from the first unit. It also enables companies to deploy R & D resources to more innovative ideas, instead of modifying existing designs to reduce costs. Unless new knowledge about the technology or the market is gathered or new components become available, cost reduction projects after product introduction can be interpreted as quality problems (Anderson and Sedatole 1998; Carr and Tyson 1992). These cost reduction efforts can be compared to the costs associated with the rework of finished goods in manufacturing settings (Cole 1998). Finally, managing costs during the development stage--while the design is still fluid--is usually easier and cheaper than after the product is introduced (Ulrich and Eppinger 2000). Thus, managing costs during product development emerges as an important process to increase the profitability of future products. But product development projects face competing demands, and in some instances, focusing the attention of team members on product costs during product development does not generate the highest return.

DIFFICULTIES IN MANAGING COSTS DURING PRODUCT DEVELOPMENT

Two forces help explain the difficulty of managing product costs during the development phase. First, technology challenges, fast time-to-market demands, and the complexity of managing knowledge located in different places inside and outside the organization limit the attention that product development teams can devote to cost considerations (Koga 1999). Cost reduction initiatives often get postponed until the product reaches the manufacturing stage, when price pressure from the market and the need to keep attractive margins redirects attention to costs.

The second force is the complexity of modeling the cost impact of product design decisions on shared resources such as logistics, customer support, or quality departments (Cooper and Kaplan 1997). Without appropriate models of cost behavior, design decisions to lower the costs for each particular product may lead to high overall costs for the organization. But sophisticated cost models that encompass these cost externalities, though theoretically possible, are much harder to translate into practice. Figure 1 maps these two forces.

[FIGURE 1 OMITTED]

Target costing (Koga 1999; Ansari and Bell 1997)--the most popular management process to keep the cost element of the profit equation in mind during product development--appears to be more effective when product cost is very important to the success of the product and when modeling cost behavior at the organizational level is simpler. Target costing relies on adequate cost models and demands significant attention to cost criteria. As cost models become more complex and engineers focus their efforts on solving cutting-edge-technology problems under demanding time and budget constraints, the benefits of target costing may be less significant. Table 1 describes the potential limitations that affect target costing as we move out of the lower left corner of Figure 1.

A leading supplier of manufacturing equipment for integrated circuits (chips), one of the companies in our study, illustrates the tension between the importance of cost considerations in product development and the difficulty of managing them during this process. Because the wellspring for the technology of this company is quantum physics, product development teams focus on solving puzzles involving atoms and electrons. In addition, customers demand tight development schedules. When manufacturers develop a new chip, they define a specific date for selecting the equipment used to manufacture the new chip. Meeting this time window is very important and imposes additional pressure on the development team around time-to-market. On top of the technology and time demands, development teams work with limited resources and tight development budgets. Even if cost targets and cost models exist, product costs are not at the top of the engineers' list; customers will pay for having the latest technology on time. But as the product matures and new competitors enter the market, margins erode and reducing costs becomes paramount. Cost reduction teams often discover cost reduction opportunities missed during the development stage that are typically more expensive to pursue at the manufacturing stage.

THE DESIGN OF THE FIELD STUDY

The conclusions presented in this paper come mostly from two sequential field research studies that investigated 12 divisions of seven companies in the medical devices industry and eight computer hardware companies. Target costing may be of limited application in a diverse set of industries where product development emphasizes objectives other than costs, and modeling cost behavior is complex. We chose to focus on high-technology firms because their characteristics suggest the need for alternative cost management practices in product development to complement or replace target costing. The paper also relies on field research reports published in the product development and cost management literatures.

The first study pursued two objectives: (1) to identify new management accounting practices, especially how companies addressed the tension between the importance of product costs and the need to focus attention on technology, time-to-market, and customer needs; and (2) to gather detailed information on the design and use of management accounting systems in product development. We chose the medical devices industry because product development is at the core of company strategy in this industry and consumes a significant amount of resources. Accordingly, we expected product development processes to be well thought out.

We selected the initial sample from the population of medical devices companies with sales over $300 million both in Europe and the United States. Twelve divisions from seven companies participated in the field research. At each division, we interviewed an average of five managers, including product development, marketing, and support functions--finance, business development, and supply chain--and ranging from functional vice presidents to product development project leaders. The interview protocol comprised open-ended questions, and we asked clarification questions as needed. We transcribed the interviews soon after each company visit, based on the extensive notes taken during the interviews. As part of the transcription process, we highlighted ideas and patterns that emerged during the interviews. Each interview lasted 60 to 90 minutes. We followed up the interviews with telephone calls to clarify any remaining questions.

The second field study targeted companies in the computer hardware industry that we also selected for the importance of product development and diversity of products. We expected this industry to confirm some of the trends already identified in the field visits to medical devices companies and potentially to unveil new management practices. We selected the sample of eight companies from among companies affiliated with a university research center, mostly large companies with sales of over $1 billion. We used an interview process similar to the one used in the medical devices industry. Overall, the sample includes information on more than 30 medical devices' product development projects and 15 computer hardware projects. However, even though we used specific projects as examples during the interviews, the unit of analysis is the division or company for a total of 20 business units in this study.

At the end of each interview and at the end of the project, we studied the evidence to identify patterns in the use of cost management practices in product development. We use company names whenever the information is publicly available or the company agreed to have its name identified.

FOCUSING ATTENTION ON MANAGING COSTS DURING PRODUCT DEVELOPMENT

From a cost management perspective, the challenge that technology companies in our sample face is not a lack of knowledge about cost reduction. The challenge is how to incorporate cost criteria during the development stage without excessively shifting the development team's attention to cost and away from objectives perceived to be more critical--the dimension captured in the Y-axis in Figure 1. In particular, technology performance, time-to-market, and development budgets are more important than product cost for the development team. Companies rarely kill projects because they do not meet product cost targets; even if cost estimates are significantly above expectations, the additional costs typically translate into a higher price that customers willingly pay if the technology is satisfactory. Moreover, project managers' rewards are based on delivering technology on time and only, to a lesser extent, on product cost.

During one of our interviews at a computer hardware company, the manager of a department in charge of reducing costs of existing products described an example of this challenge. A cost reduction project involved redesigning the cooling subsystem of one of the products. The current design used 17 parts. Operating under time pressure and resource constraints, the designer solved the design problem in order to quickly move to the next task. Once the product reached the manufacturing stage, the cost reduction team simplified the subsystem down to a single part, at one-ninth the cost of the previous subsystem, with faster lead-time and higher quality. This company possessed needed cost reduction knowledge but incorporated it after the development phase.

Because the product is very technology intensive, this company focuses the product development team's attention on technology, not on cost management. However, the benefits of cost reduction knowledge could be enhanced if applied before the product reaches the manufacturing stage. Our research identifies two approaches to manage the tension that emerges between (1) moving cost reduction opportunities into product development and (2) keeping the development team focused on the product's critical success factors. The effectiveness of these two practices comes from leveraging the knowledge of different organizational members so that they focus their attention where they can get the highest return on their knowledge. They accomplish this objective by managing costs outside the development team and around it through support teams, rather than by enhancing cost consciousness within the development team.

Parallel Cost Management Teams

Companies typically apply cost reduction expertise at the manufacturing stage or in the core of product development cross-functional teams by the assigning cost reduction specialists to these teams (Hertenstein and Platt 2000). When debating trade-offs in the development of a project, cost experts act as gatekeepers to enhance the visibility of cost considerations. They also help the development team use cost models, such as activity-based-costing models, to interpret the cost implications of its decisions. They seek to shift the team's attention toward costs. The role of parallel cost management teams differs from having a cost expert on the core product development cross-functional team. Cost reduction specialists in parallel cost management teams work outside but alongside the product development team, rather than inside. Their main objective is to redesign for cost as early as possible in the product's life cycle, without shifting the attention of the core development team away from the critical technology, market, and speed criteria.

In one of our sample companies, the parallel cost team leader participates in the periodic core development team project meetings. The objective is to identify cost reduction opportunities that the parallel cost team can start working on. Cost experts in the parallel cost team use their expertise in reviewing the designs of pieces outside the critical path of the development project. Thus, the parallel cost management team becomes familiar with the product development project by participating in review meetings and being in the information loop of the project. But they perform their work outside the core of the product development team while incorporating their cost reduction knowledge during product development.

Parallel cost management teams report to the department in charge of cost reduction--typically engineers supported by the accounting office--where the teams functionally belong and where they gather their expertise. The challenge for parallel cost management teams is to open a communication channel with the core development team and to identify the parts and processes where they can most profitably use their knowledge. Although this requires an understanding of the cost savings for the specific parts, it is equally important to know how these parts interact with the rest of the product. We identified various implementations of this practice in six of our 20 business units.

Modular Design For Cost

Modular design is another approach to managing costs during product development without shifting the attention of the product development team away from critical success factors. The operations literature proposes modularity as a way to increase product offerings without increasing the number of products developed (Baldwin and Clark 2000; Schilling 2000). This literature also highlights the associated economies of scale and scope on direct costs. From a management accounting perspective, modularity has the advantage of keeping manufacturing complexity down. Although this translates into lower support costs, such as manufacturing scheduling, we emphasize a different application of modularity critical to managing cost during product development. This application calls for developing modules that are not core to product performance outside the development project, where costs can receive adequate attention. Modularity for costs has the following advantages for cost management:

* the product development team need not concentrate on these non-core modules;

* the team focuses on key technology systems where it adds the most value; and

* modules are designed outside the high-pressure development process and emphasize cost reduction.

A chip manufacturing equipment supplier in our study used modularity to redesign the dry pumps that create the vacuum required for a manufacturing process environment free of impurities. Compared to other systems in chip manufacturing equipment, the company understood pump technology much better, time was not as critical, and costs were higher in the priority list. Because the newly designed pumps reduced costs of installation--construction, ducts, cables, pipes, and reduced power requirements--and increased quality, they significantly reduced total cost of ownership. The modular design approach allowed the self-contained pump development team to adjust its priorities to the critical success factors for pumps. The main objective of using modularity to redesign the pumps was not to offer a broader product line--the most common objective of modularity--but to allow the design team to put more effort into reducing costs.

The newly designed pumps became a common component in most of the company's products, and enter product development as fully designed standard modules. The teams developing new chip manufacturing equipment can now take the pump as given, without spending time designing it or comparing offers from different suppliers. Moreover, when new chip manufacturing equipment moves into production, the fact that cost reduction opportunities for pumps are already realized eliminates the need for resources dedicated to reducing pump costs during the manufacturing stage.

Using modularity to reduce costs may not always achieve the best design for a particular product if the module is over-designed so it can be shared among various products. But not having an optimal design may not be a significant loss. If the development team designed the module, then the result would likely be a "good enough" design for the product at hand rather than the best design. Having a "good enough" design allows attention to be devoted to more demanding modules. In most cases, externally designed non-core modules are at least as good as the "good enough" design. Modularity brings cost management into product development without imposing it on the development team, but by working around this team. Although we encountered modularity to some extent in all the business units in the sample, only eight of them purposefully used modularity to focus development attention on cost.

MANAGING THE COSTS OF SHARED RESOURCES IN PRODUCT DEVELOPMENT

The cost management practices introduced in the previous section address the Y-axis in Figure 1 by freeing up product development team attention from cost considerations while still managing costs in the development phase. Turning now to the other challenge represented by the X-axis, we examine how companies influence design decisions to incorporate the complexity of managing indirect costs. These costs reflect the value of shared resources such as manufacturing planning, logistics, quality control, and product handling. Over time, these costs have become a more significant proportion of a company's total costs and they prove difficult to manage (Cooper and Kaplan 1997).

Because indirect costs are affected by component-sustaining, product-sustaining, and process-sustaining cost drivers, their level is the combined result of independent product design decisions. Through their effect on indirect costs, design decisions impose cost externalities on other products. The development teams making these decisions typically do not have the perspective, information, or time to consider costs at a company-wide level. This perspective is only available at the business-unit level. To implement this broader view, business unit managers replace some cost management decisions and responsibilities previously embedded in the individual product development projects with policies aimed at all product development projects. Again, the objective is to manage costs around product development teams rather than by raising the cost consciousness inside these teams.

This section examines four different management practices identified during our research that companies use to manage cost externalities in the development stage:

* cost management strategy,

* parts commonality,

* process commonality, and

* product platforms.

These practices differ significantly from applying activity-based costing to product development. The purpose of activity-based costing is to give development teams sophisticated cost models that allow them to consider the cost trade-offs of their design decisions. Table 2 describes the limitations of cost models for product development. But the four practices examined here are not intended for individual product development teams to make trade-offs. Instead, the company manages costs by creating boundaries (Simons 1994) for design decisions to which individual product development teams must adhere. The relevance of these practices to management accounting is not only economies of scale and scope, but also their impact upon shared resources and the need to adopt a business-unit perspective on cost management in product development. Although this paper focuses on costs, additional advantages of parts commonality, process commonality, and platform planning include faster time-to-market and more efficient product development (Robertson and Ulrich 1998).

A European company in the medical devices industry sample exemplifies the limitations of having a product rather than a business-unit perspective. The company was one of the early entrants in a new market for medical imaging systems, and technology leadership allowed it to quickly gain a commanding position. As the market matured, customers demanded values other than improved performance in image quality. Some customers valued price, while others found image quality to be satisfactory and valued product features unrelated to image quality. After listening closely to their customers' changing needs, the company developed for each new segment a targeted product with its own components, its own suppliers, and its own supply chain. This ability to react to new demands helped the company maintain market leadership, but the cost of maintaining the complexity of its product line made it vulnerable to the entry of focused competitors with simpler cost structures. Once these competitors entered the market, the company incurred losses.

Defining a Cost Management Strategy

One important way of managing cost during the development stage focuses the search for cost reduction opportunities. But even if every person in the company actively explores new ideas on how product design can reduce the costs in their department, the end result may not be lower costs. Without a focus, product development teams may pursue too many competing "wish lists." Defining a cost strategy at the business level that cuts across individual projects helps to focus cost reduction initiatives around key themes. Companies formulate cost strategies after carefully evaluating the processes that run through the value chain--involving both suppliers and customers--and their relationship to the business strategy.

Quantum (now Maxtor), a company in our study that develops and sells disk drives, illustrates this approach. In this industry, gross margins can be less than 20 percent and price is a key competitive dimension. Once the product reaches the market, impeccable execution in manufacturing and distribution becomes the rule of the game. Therefore, managing product costs and costs throughout the supply chain becomes critical.

In 2000, Quantum developed a clear cost management strategy around supply chain streamlining, with the objective of reducing its complexity and saving costs. The old supply chain started at the manufacturing partner in Japan that shipped disk drives to four logistics sites around the world. At these sites a large percentage of drives needed minor adjustments such as configuring the hardware, labels, and repackaging. Quantum stored customer-specific products either at the logistics site or in a third-party warehouse close to the customer site before shipping them to customers. To be successful, the new supply chain required redesigned products common to all customers that could be shipped directly from the manufacturing partner to customers without costs for configuring, handling, and storing activities. Any customization would occur at the customers' premises. The new supply chain not only saved costs, but also made some of Quantum competitors' competencies obsolete. In particular, a competitor's ability to customize products cheaply through flexible manufacturing became irrelevant if customers used standardized products, actually enhancing Quantum's manufacturing strategy of producing low-cost standardized products. Managers used a simple formula to communicate the new strategy--"opening a box costs X dollars"--that highlighted the need to eliminate the steps in the supply chain that customized the disk drive. The company worked with customers to design a standard product that fully met their needs, carefully analyzed the existing supply chain to understand how to avoid "opening a box," and translated the new requirements into product designs.

Ideas on how to redesign products to build this new supply chain came mainly from people familiar with the existing supply chain. One of the ideas involved redesigning the "jumper setting" that configured the disk drive to behave as a "master" or "slave" drive. The current product design required employees at the logistics sites to take the disk drive out of the box, adjust the jumper, and repack the product in the box. Supply chain managers worked closely with engineers to design a software solution to select the configuration and avoid manually adjusting the jumper. Cost implications of this solution went beyond the cost savings of one less jumper and the savings of avoiding one configuration task. The most important result was the new supply chain that fully avoided logistic sites and shipped disk drives directly from the manufacturer to the customer.

This case emphasizes two relevant issues: (1) the importance of having a clear cost management strategy that people throughout the company can relate to, and (2) the notion that cost reductions require a company-wide perspective that individual product development teams may not have. Without an overall vision, development teams chase different "design for" cost objectives and ignore reducing particular support costs that can only be accomplished with an overall effort. This overall vision allows a coordinated search for cost reduction opportunities by people throughout the company who understand the processes and can translate cost reduction opportunities into product design. The challenge from a strategy design perspective remains to identify themes that can lead to significant cost reductions and from a strategy implementation perspective becomes communicating, measuring, and acting on these themes to capitalize on them. Three of the business units in our sample effectively used the cost strategies described here to manage costs during product development.

Parts Commonality

Another approach that brings cost considerations into product development relies on common parts and processes. Activity-based costing theory indicates that complexity leads to higher amounts of shared resources and higher indirect costs. If products share common parts, complexity can be substantially reduced. Commonality appears in the operations literature and 15 companies in our sample experimented with parts commonality to some extent.

Compared to cost management strategies, commonality avoids the search process to reduce costs by implementing cost reduction through a coordinated management of the product line. Commonality also differs from modular design for cost. The primary objective of modular design for cost is to move the design of subsystems out of larger projects that have different design priorities to better manage the development teams' attention. Commonality calls for sharing to reduce complexity. Companies implement commonality through design policies affecting common parts (Fisher et al. 1999; Hillier 2000) and common processes (Lee and Tang 1997). These policies set limits on the alternatives that development teams can consider. Although commonality is not as precise as a full-fledged activity-based cost model, it may be more effective in moving cost considerations to the development phase.

IBM provides a good illustration of a company that uses parts commonality to achieve cost savings across products (Carbone 1999). The company viewed moving to fewer parts as a way of reducing costs. Because commonality depends on the interplay of hundreds of design decisions, it could only be implemented as a company-wide effort. Management formulated policies for using common parts across products and mapped out convergence plans to move subsequent generations of products toward more parts and subassemblies commonality. These policies also supported IBM's centralized purchasing structure initiative. Within this structure, 17 commodity councils selected parts and suppliers for all divisions inside IBM, including such items as memories, microprocessors, and monitors. The councils combined the requirements of all divisions and negotiated long-term contracts. Development teams could use parts from the parts list that commodity councils had approved; a team that wanted a part not on this list had to get the approval of the commodity council. Obtaining unique "nonlisted" parts became costly to the team in attention and paperwork, and represented implicit "taxes" on the teams that used them.

Cost Management Advantages

Parts commonality has several advantages from a cost management perspective. Direct effects include economies associated with larger volumes, better terms and prices from suppliers, preferred priorities in case of parts' shortages, fewer assets tied up in inventory, and lower initial investments for tooling and other fixed costs of production. The increased volume associated with a common part also justifies greater investment in developing and refining the part. But large savings also accrue from reducing shared resources. Fewer parts simplify the logistics of incoming products, increase manufacturing flexibility, simplify administrative processes, and facilitate post-sale service.

Parts commonality probably best illustrates the need for a broad view of cost management. Such a policy would never happen at the level of individual projects; why would a design team specify a part from another product if a new part better meets its needs? The common part may be more expensive and overspecified for a particular product. Individual development teams do not have the perspective or incentives required to coordinate these cost reduction policies.

Impact on Product Development

Parts commonality also illustrates how cost management implicitly enters into product development, restricting the alternatives open to the team rather than explicitly using complex cost models. Parts commonality creates constraints within which development of individual products takes place. A smaller set of alternatives may also simplify the development teams' search and decision processes. Moreover, the available parts were thoroughly reviewed and do not require team effort to insure their quality and the reliability of their suppliers. But the risk of any policy that mandates focus lies in limiting the alternatives and the flexibility that innovation requires. Moreover, parts commonality may limit the possibilities for asking premium prices for high-end products that contain many of the same parts as low-end products (Desai et al. 2001; Fisher et al. 1999).

An alternative approach that drives the same behavior calls for artificially increasing the cost of unique parts. Cost allocation procedures that allocate a higher percentage of support costs to unique parts can achieve this. The fact that unique parts appear more expensive discourages product development teams from including them.

Celestica, a contract manufacturer in the computer industry, illustrates another approach to implementing parts commonality that involves OEM customers. The company implemented parts commonality and the use of fewer preferred suppliers with an explicit management initiative. Again, the underlying idea involved a set of parts selected and administered centrally that designers at their OEM customers--OEMs who outsource their manufacturing to Celestica--could access when deciding which parts to use. Celestica made the information available through a web-based information system with up-to-date information about parts. The information system supplied not only technical specifications, but also feedback about preferences, current and future availability (end-of-life situations), lead-time, quality, and costs. It also measured the percentage of parts chosen from the company's preferred parts database to monitor the progress of the program. Through this program, Celestica intended to reduce costs across the product line, to introduce new products faster, and to improve quality and timely delivery.

Process Commonality

Forces similar to the ones behind parts commonality drive process commonality, but the focus is on using common processes to reduce shared resources. Quantum's redesign of the testing procedure illustrates how process redesign impacts process commonality. Initially, Quantum used different testing procedures to address its customers' different requirements. This array of testing procedures created complexity at the process level--two units of the same product became "different" because they met different testing standards--and each one had its own supply chain. To achieve process commonality, Quantum designed a single testing process that took into account the most demanding conditions from all of its customers. This common testing procedure simplified the testing process, reduced complexities at the inventory management level, and imposed tighter product specifications during product development

Hewlett-Packard provides another good example of process commonality (Feitzinger and Lee 1997; Lee and Billington 1995). Its DeskJet printer required a customized power supply for one European country. Although the Singapore plant could execute more cheaply, the company decided to postpone customization and modify the printer at the European country's logistics site. Despite higher direct costs--the printer had to be unpacked, modified, and repacked--process commonality allowed lower logistic costs and the company retained the flexibility to move a standard product across different markets as demand shifted. Commonality is an important concept that most companies in our sample had experience with, and four of these purposefully increased process commonality through new product development to reduce the costs of shared resources.

Product-Platform Planning

Design decisions have cost implications beyond the current product mix; they also affect the cost structure of follow-up products, including line extensions and platforms. Thus, the complexity of modeling cost behavior increases when future products come into the cost management process. Product-platform planning takes into account the cost effects of today's design decisions on future costs. A product platform is a product architecture that allows components, processes, and knowledge to be shared across a set of products (Robertson and Ulrich 1998). A careful platform planning process seeks to develop distinctively different models from a common platform. Product-platform planning envisions the future product portfolio and the future cost implications of today's decisions. One medical devices company in our study used this approach to manage the interaction between the costs of different generations of products. After crafting its technology and market strategies, the company formulated road maps describing how to incorporate technologies in future product generations through platforms and extensions. Linked to these roadmaps were plans and targets that described how subsequent generations of products would share designs and parts to reduce development time and shared costs.

Developing an initial platform requires costly short-term design decisions to accommodate future products. For example, the initial platform may include an overdesigned power source to allow future products to offer a larger set of features. Careful product portfolio planning can leverage the design policies described in previous sections. Companies not only share these policies--modular designs, cost strategies, and parts and process commonality--among current products, but they also apply these policies to new product generations. Although almost all the companies in our study reused parts of their product designs in future product generations, only four explicitly planned this in an attempt to reduce costs over time.

Philips Consumer Electronics (CE) used platforms to reduce costs over product generations. To reduce complexity and take advantage of synergies over time, the division based new television sets on one of three standard printed circuit board (PCB) architectures addressing high-, medium-, and low-end segments, and built each new television set around one of these three architectures. The division kept the PCB architecture constant across products and only customized peripheral modules and components--like the size of the screen and the shape of control buttons and external box--to the needs of the particular product. Such a platform strategy provided several advantages:

* reduce cost and time for new product development,

* reinforce cost advantages associated with commonality and modularity, and

* support larger initial investments for the design of the three standard architectures.

To achieve these advantages, the design of the standard architectures required flexibility, achieved by over-engineering the architectures for a particular product to allow products with different features to be based on the same architecture. Philips also implemented a commonality policy where engineers could only select components from a database of preferred components rated on four dimensions: price, functionality, applicability, and environment.

CONCLUSIONS AND FUTURE RESEARCH

Decisions made during product development determine a significant proportion of product costs. This paper examines practices that bring cost criteria into product development without shifting too much attention to cost considerations or developing complex cost models. The cost management practices discussed here address the tension between focusing on technological innovation, product performance, time-to-market, and designing cost-effective products. These practices address the challenge of moving cost concerns up front in a way that is consistent with product development priorities.

Target costing, the main technique proposed to manage costs during product development, was not frequently used in the companies studied. Perhaps target costing forces cost criteria inside the development stage and redirects the development team's attention toward achieving cost targets. Development teams' attention is the scarcest resource in product development, and in projects where technology, time-to-market, or demanding customer needs are critical to a product's success, shifting attention to cost may not be the best course of action. Target costing in product development also requires cost models that reflect the economics of direct as well as shared resources. Such cost models may be hard to develop and to use in complex and uncertain environments.

The paper raises important questions for future research. First, are the cost management practices presented in the paper complements or supplements to target costing? If they are complements, then how does target costing interact with these other practices? Second, Figure 1 predicts that two factors drive the use of the various approaches to cost management in product development: (1) the importance of criteria other than product costs and (2) the difficulty of modeling the cost behavior of shared resources. The two hypotheses underlying this figure require further research. The first hypothesizes that target costing is more appropriate for companies that stress cost considerations and can easily model their cost behavior. The second hypothesizes the need for alternative cost practices when the opposite circumstances exist. In addition, we do not know how cost management takes place when only one of the dimensions in Figure 1 is at a high level. A further research question asks whether the use of alternative practices for cost management yields cost models expected to be simpler than those found in target costing.
TABLE 1 Limitations of Target Costing in High-Technology Industries

Target costing has significant advantages in stable industries such as
the camera industry, characterized by short product life cycles, clearly
established price points, well-understood technology, and where product
costs are key to profitability. Target costing encourages designers to
seek innovative alternatives to reduce product costs (Koga and Davila
1999). However, the advantages of target costing become liabilities in
high-technology industries. Here are the potential limitations:
* Target costing focuses attention on cost drivers and away from
  revenue drivers
  Revenue drivers like time-to-market, technology, or understanding
  evolving customer needs become much more relevant than product cost
  drivers in high-technology industries. Because target costing happens
  within the development process, the attention of the development team
  shifts to product costs and away from the critical success factors.
* Target costing is too time consuming
  When time-to-market and technology are key to profitability, product
  development teams have neither the time nor the attention span to
  identify alternatives, estimate their cost impact, and choose the one
  that minimizes costs. Rather, the team looks for an alternative that
  solves the problem at hand and quickly moves to the next problem. The
  idea is not to find the best solution, but simply to find a solution.
* Target costing is too linear and bureaucratic
  Executing target costing requires formal procedures that assess
  customer needs, determine target price, define target cost, break
  perceived value down to subsystems and components to come up with
  allowable cost per part, and apply value reengineering techniques to
  achieve target cost. While iterating these stages is common, the
  process becomes too bureaucratic and linear for product development
  projects where cost is not the main driver.
* Target costing is too detailed
  An effective target costing process requires complex cost models
  including activity-based costing and life cycle costing techniques
  (Ansari and Bell 1997) to capture the entire value chain (Cooper and
  Yoshikawa 1994; Cooper and Slagmulder 1999). In fast-moving
  environments, these models may reflect current processes and not the
  future processes required for product development decisions. These
  models may also be quite inaccurate given the uncertainty of high-
  technology environments. Moreover, learning how to interpret them
  requires significant development team time. This elaborate system can
  be too detailed for development teams that need a rough guide rather
  than a hard cost target.

TABLE 2 Limitations of Cost Modeling in High-Technology Industries

Cost models map the full impact of product design on the economics of
the company. Although these models are most informative for mature
industries with stable processes, the models have several limitations
when used for product development in high-technology industries.
* Cost models are frequently limited to manufacturing costs
  Cost models useful for managing indirect costs must address
  manufacturing costs (bill of materials and direct manufacturing costs
  are typically the only costs captured) as well as support costs (such
  as environmental, R & D, logistics, financing, and service costs).
  Product design decisions impact support costs in complex ways because
  of component-sustaining, product-sustaining, and process-sustaining
  cost drivers.
* Cost models are frequently limited to resources inside the company
  Cost models that can fully capture the economics of the product must
  adopt a value-chain perspective that allows making trade-offs between
  costs in different parts of the value chain from suppliers to
  customers (Handfield et al. 1999; Hergert and Morris 1989), leading to
  overall cost savings for all parties involved (Shields and Young
  1991).
* Developing cost models is time (and resource) consuming
  Modeling manufacturing costs, support costs, life cycle costs, and
  interorganizational costs requires a deep understanding of the
  economics of the firm. It also requires a careful analysis to
  understand the behavior of costs and the selection of cost drivers.
  Finally, it requires a rich information system that can feed the data
  to estimate costs.
* Cost models reflect the present, not the future
  Cost models reflect the current economics of the firm. However,
  product development teams need to have cost models of how the company
  will look when the product is introduced. This difficulty becomes
  especially acute when innovation is not incremental and the economics
  of new products diverge widely from the status quo.
* Cost models have to be learned
  Estimating cost during product development and measuring the cost
  impact of design choices require far more capabilities than most
  costing systems currently offer. But even if they are available, then
  understanding how the cost model works requires time. Most product
  development teams do not have the expertise or the time to learn the
  mechanics of the cost models.
* Cost models may shift attention away from the key success factors
  Even when the cost models are well designed and the development team
  understands them, they require attention to the detriment of
  technology or time-to-market.


We thank Ken Koga, George Foster, and two anonymous reviewers for helpful comments.

Submitted: November 2002

Accepted: September 2003

Editor's Note: Jim Largay served as the editor of this manuscript.

REFERENCES

Anderson, S. W., and K. Sedatole. 1998. Designing quality into products: The use of accounting data in new product development. Accounting Horizons 12 (3): 213-233.

Ansari, S. L., and J. Bell. 1997. Target Costing: The Next Frontier in Strategic Cost Management. New York, NY: McGraw-Hill/Irwin.

Baldwin, C. Y., and K. B. Clark. 2000. Design Rules. Volume 1: The Power of Modularity. Cambridge, MA: MIT Press.

Blanchard, B. S. 1978. Design and Manage to Life-Cycle Cost. Portland, OR: M/A Press.

Carbone, J. 1999. Reinventing purchasing wins the medal for BIG BLUE. Purchasing: 38-41.

Carr, L. P., and T. Tyson. 1992. Planning quality cost expenditures. Management Accounting 74 (4): 52-56.

Cole, R. E. 1998. Learning from the quality movement: What did and didn't happen and why? California Management Review 41 (1): 43-73.

Cooper, R., and T. Yoshikawa. 1994. Interorganizational cost management systems: The case of Tokyo-Yokohama-Kamakura supplier chain. International Journal of Production Economics 37: 51-62.

______, and R. S. Kaplan. 1997. Cost and Effect: Using Integrated Cost Systems to Drive Profitability and Performance. Cambridge, MA: Harvard Business School Press.

______, and R. Slagmulder. 1997. Target Costing and Value Engineering. Portland, OR: Productivity Press.

______, and ______. 1999. Supply Chain Development for the Lean Enterprise: Interorganizational Cost Management. Portland, OR: Productivity Press.

Desai, P., S. Kekre, S. Radhakrishnan, and K. Srinivasan. 2001. Product differentiation and commonality in design: Balancing revenue and cost drivers. Management Science 47 (1): 37-51.

Feitzinger, E., and H. L. Lee. 1997. Mass customization at Hewlett-Packard: The power of postponement. Harvard Business Review 75 (1): 116-121.

Fisher, M. L., K. Ramdas, and K. Ulrich. 1999. Component sharing in the management of product variety: A study of automotive braking systems. Management Science 45 (3): 297-315.

Handfield, R. B., G. L. Ragatz, K. J. Petersen, and R. M. Monczka. 1999. Involving suppliers in new product development. California Management Review 42 (1): 59-82.

Hergert, M., and D. Morris. 1989. Accounting data for value chain analysis. Strategic Management Journal 10 (2): 175-188.

Hertenstein, J. H., and M. B. Platt. 2000. Performance measures and management control systems in new product development. Accounting Horizons 14 (3): 303-324.

Hillier, M. S. 2000. Component commonality in multiple-period assemble-to-order systems. IIIE Transactions 32 (8): 755-766.

Koga, K. 1999. Determinants of effective product cost management during product development: Opening the black box of target costing. Ph.D. dissertation, Harvard Business School.

______, and T. Davila. 1999. What is the role of performance goals in product development? A study of Japanese camera manufacturers. In Dynamic Strategic Resources: Development, Diffusion and Integration, edited by M. A. Hitt, P. Clifford, R. D. Nixon, and K. P. Coyne. New York, NY: John Wiley & Sons.

Lee, H. L., and C. Billington. 1995. The evolution of supply-chain-management models and practice at Hewlett-Packard. Interfaces 25 (5): 42-63.

______, and C. S. Tang. 1997. Modeling the costs and benefits of delayed product differentiation. Management Science 43 (1): 40-53.

Robertson, D., and K. Ulrich. 1998. Planning for product platforms. Sloan Management Review 39 (4): 19-31.

Schilling, M. A. 2000. Toward a general modular systems theory and its application to interfirm product modularity. Academy of Management Review 25 (2): 312-334.

Shields, M. D., and S. M. Young. 1991. Managing product life cycle costs: An organizational model. Journal of Cost Management: 39-52.

Simons, R. 1994. Levers of Control: How Managers Use Innovative Control Systems to Drive Strategic Renewal. Boston, MA: Harvard Business School Press.

Ulrich, K. T., and S. D. Eppinger. 2000. Product Design and Development. Boston, MA: Irwin/McGraw-Hill.

Wheelwright, S. C., and K. B. Clark. 1992. Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency, and Quality. New York, NY: The Free Press.

Yli-Renko, H., E. Autio, and H. Saipenza. 2001. Social capital, knowledge acquisitions, and knowledge exploitation in young technology-based firms. Strategic Management Journal 22 (6/7): 587-613.

Young, S. M. 1999. Field research methods in management accounting. Accounting Horizons 13 (1): 76-84.

Antonio (Tony) Davila is an Assistant Professor at Stanford University and Marc Wouters is a Professor at the University of Twente.

Corresponding author: Tony Davila

Email: adavila@stanford.edu
COPYRIGHT 2004 American Accounting Association
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2004 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Davila, Antonio (Tony); Wouters, Marc
Publication:Accounting Horizons
Date:Mar 1, 2004
Words:7607
Previous Article:The information content of royalty income.
Next Article:Empirical evidence on recent trends in pro forma reporting.

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters