1.3 Concurrent Engineering and the Cross-Discipline Team

[ Team LiB ]

1.3 Concurrent Engineering and the Cross-Discipline Team The way in which engineering and product development work is organized has undergone major changes in recent years. Much of this change has been aimed at eliminating the inefficiencies associated with stepwise development, where intermediate products are handed off to next-phase workers, who may have to do extensive rework to correct misunderstandings. Concurrent engineering, cross-discipline teams, cross-functional teams, integrated product teams (IPTs), and Integrated Product and Process Development (IPPD) all represent ways to address this problem and apply the necessary expertise at the appropriate time throughout the product or service life cycle. In practice, this trend means that designers and customers work with manufacturers, testers, and users to support the manufacturing organization in developing requirements. It has also been described as having "everyone at the table," implying that all critical stakeholders support all phases of product or service development.[9] [9] Of course, anything can be overdone. Programs with integrated product teams numbering in the hundreds can experience their own distinctive communication problems. Understandably, the concept of concurrency has redefined the nature of organizational structure and development. It requires an enhanced management competency for dealing with "gray areas" and ambiguity, which is not easy for many managers, who are perhaps more versed in dealing with tangible facts and figures. The general acceptance and rapid deployment of cross-discipline or cross-functional teams in the engineering world has also proved a thorny issue for process improvement. The concept of functional departments, each with its own processes under its own control, strongly clashes with the highly interactive work style associated with cross-discipline teams. To date, discrete process-improvement models have not effectively supported the "mixing bowl" environment of concurrent engineering. If the hardware engineering department is using one improvement model, the software developers a second, and the outsourcing and contracts departments yet a third, problems are inevitable. Separate "stovepipe"[10] models offer little chance of improving the processes used by a cross-discipline team, where every member is an actor in most of the processes and the separation between the disciplines has gone the way of the Berlin Wall. [10] Stovepipe processes are usually organized by discipline and do not include the interfaces between those organizations. Cross-discipline teams use integrated processes that are matched more closely to the ebb and flow of the life cycle than are the strict stages of classical development. They take advantage of evolutionary development approaches and innovative design techniques. Attempting to apply the discipline-specific models to such processes is analogous to requiring members of a jazz trio to strictly play their individual parts. Of course it's possible�but the outcome is not very satisfying. What is needed is a model that not only integrates the disciplines, but also integrates the processes themselves and supports effective work among various stakeholders, functional personnel, and management.

[ Team LiB ]