Real SCM Challenges. Real SCM Experts. Real SCM Solutions.™
|
Real SCM Challenges. Real SCM Experts. Real SCM Solutions.™ |
|
HOME
|
DESIGN MANAGEMENT
|
 |
Individuals behave differently than teams do, and cultural aspects of an organization do not necessarily reinforce either team formation or team strategy. In many cases, individual goals and measurables vary amongst team members with no clear link to the goals of their team [1]. |
|
Often decisions made by a team cannot be implemented without upper management, who ultimately holds the power to implement cross-functional solutions [2]. |
|
The movement of information within an organization is critical to the goals of product development. If information is not available, or if it is not transmitted in a timely manner, then development efforts can easily be crippled [3]. Many delays in product development consist of waiting time for information from various team members or other contributing sources. |
|
Engineering organizations are functional in nature. That is to say, individuals with similar skills are grouped together to perform a common function. Such organizations have persisted through to today, and they experience conflict using a team-based approach to product development [4, 5]. |
Having discussed the potential issues with a team approach, two questions arise: (1) under what circumstances is a team approach appropriate, and (2) is there a viable alternative to a team approach?
Addressing question 1, assume product development success is measured by time-to-market. Published accounts conclude that cross-functional teams reduce development time only when used to address problems involving high uncertainty or risk. Teams, however, have little or no effect in reducing time-to-market of products that carry low risk [6, 7]. Many product development efforts involve customizing existing technology to meet a set of customer specific requirements (i.e. weight, cost, size, etc.). This type of development effort carries lower risk than innovation, and as such presents a case where the team approach may be replaced with an alternative.
Looking now at question 2, any alternative product development strategy must preserve the existing key enablers for success and be subject to similar measurement schemes for evaluation and improvement. An alternative product development method must align with the strategic focus of an engineering organization. It must recognize the nature of decision-making. It must be congruent with the prevailing learning model. Above all, unique solutions must be pursued based on the critical success factors that exist for the product.
As an example, assume that an organization exists that engages in product development activity independent of innovation centers (R & D or concept development efforts); assume that the strategic focus of the organization is mass customization; assume that the organization is product-focused and has a functional structure. In this set of circumstances an individual-based model may be appropriate. Such an individual could be titled a 'concurrent engineer' (CE) or something similar. In this scenario, the CE would need to be the center of information flow. A product-focused organization generates large amounts of information. In a functional organization, such information is housed in database management systems that are not accessible to all working level employees. Access, however, is not the solution. Access to a large amount of information does not lead to successful decision-making. What is needed is an individual who is able to gather and interpret information in terms of the organization’s priorities. Being the locus of product information will also alleviate information lags in product development.
Another required attribute of a CE is that s/he be the final decision-maker with regard to the product. Being the center of information flow gives the CE the unique perspective on all different functional areas. In contrast to functional areas that are driven by their own goals, the CE is able to trade-off alternatives in a way that avoids individual functional desires and takes a more overall approach to product development [1]. This approach lends legitimacy to the CE's decisions and makes it easier to implement cross-functional action since there is no perceived loyalty to any one functional area.
In addition to the decision-making role and being the center of information flow, it is important to describe the actual skill-base that a CE should possess in this case. Looking at the traditional team approach, employees from product engineering, manufacturing, marketing, and quality typically comprise concurrent engineering teams [2]. If an individual then is to become the replacement for the team, it is essential that the individual be knowledgeable about the product, the related manufacturing processes, business considerations, and quality tools and disciplines. This breadth of knowledge ensures that designs are competitive and that the CE is equipped for the required decision-making [1].
Having laid out the CE as an individual, it is important to note that this product development model neither devalues, nor preempts the necessity of collaboration. In any concurrent engineering project, collaboration is a key to success [1, 3, 8]. Even in the absence of a team, there is a need for collaboration because of the simple fact that interaction is necessary to obtain information from customers, suppliers, and relevant functional expert. This aids in the decision-making process and provides the basis for learning that ultimately reinforces itself and allows information experts to focus on information quality.
This scenario presents just one of many situations where team-based product development may not be a viable strategy. Organizations must manage their product portfolios and foster the specific development model that best fits each product. This will continue to be a challenging task, and will definitely lead to the discovery of new competitive advantages in a knowledge economy.
REFERENCES:
[1] Salomone, Thomas A. What Every
Engineer Should Know About Concurrent Engineering Marcel Dekker, Inc., New
York ©1995.
2] Parsaei, Hamid R., and William G. Sullivan, ed. Concurrent Engineering –
Contemporary Issues and Modern Design Tools Chapman & Hall, London © 1993
[3] Prasad, Biren Concurrent Engineering Fundamentals Vol. I: Integrated
Product and Process Organzation Prentice-Hall, Inc., New Jersey ©1996
[4] Clark, Kim B. and Steven C. Wheelwright Managing New Product and Process
Development, The Free Press, New York, ©1993
[5] Prasad, Biren Concurrent Engineering Fundamentals Vol. II: Integrated
Product Development Prentice-Hall, Inc., New Jersey ©1997.
[6] Gerwin, Donald, and Nicholas J. Barrowman “An Evaluation of Research on
Integrated Product Development.” Management Science, Volume 48, No. 7,
2002.
[7] Koufteros, Xenophon, et al “Concurrent Engineering and Its Consequences.”
Journal of Operations Management, No. 19, 2001.
[8] Carter, Donald E. and Barbara S. Baker Concurrent Engineering – The
Product Development Environment for the 1990s Addison-Wesley, Massachusetts
©1992.
|
Copyright © 2004 LeanSCM llc. All rights reserved. Legal Statement. |