INTRODUCTION The concurrent engineering method is still a relatively new design management system, but has had the opportunity to mature in recent years to become a well-defined systems approach towards optimizing engineering design cycles . Because of this, concurrent engineering has garnered much attention from industry and has been implemented in a multitude of companies, organizations and universities, most notably in the aerospace industry. The basic premise for concurrent engineering revolves around two concepts. The first is the idea that all elements of a product‟s life-cycle, from functionality, producibility, assembly, testability, maintenance issues, environmental impact and finally disposal and recycling, should be taken into careful consideration in the early design phases
. The second concept
is that the preceding design activities should all be occurring at the same time, or concurrently. The overall goal being that the concurrent nature of these processes significantly increases productivity and product quality, aspects that are obviously important in today's fast-paced market
. This philosophy is key to the success of concurrent
engineering because it allows for errors and redesigns to be discovered early in the design process when the project is still in a more abstract and possibly digital realm. By locating and fixing these issues early, the design team can avoid what often become costly errors as the project moves to more complicated computational models and eventually into the physical realm . As mentioned above, part of the design process is to ensure that the entire product's life cycle is taken into consideration. This includes establishing user requirements, propagating early conceptual designs, running computational models, creating physical prototypes and eventually manufacturing the product. Included in the process is taking into full account funding, work force capability and time, subject areas that are extremely important factors in the success of a concurrent engineering system. As before, the extensive use of forward planning allows for unforeseen design problems to be caught early so that the basic conceptual design can be altered before actual physical production commences. The amount of money that can be saved by doing this correctly has proven to be significant and is generally the deciding factor for companies moving to a concurrent design framework . One of the most important reasons for the huge success of concurrent engineering is that by definition it redefines the basic design process structure that was common place for decades.
This was a structure based on a sequential design flow, sometimes called the „Waterfall Model‟ . Concurrent engineering significantly modifies this outdated method and instead opts to use what has been termed an iterative or integrated development method
difference between these 2 methods is that the „Waterfall‟ method moves in a completely linear fashion by starting with user requirements and sequentially moving forward to design, implementation and additional steps until you have a finished product. The problem here is that the design system does not look backwards or forwards from the step it is on to fix possible problems. In the case that something does go wrong, the design usually must be scrapped or heavily altered. On the other hand, the iterative design process is more cyclic in that, as mentioned before, all aspects of the life cycle of the product are taken into account, allowing for a more evolutionary approach to design design processes can be seen graphically in Figure 1.
. The difference between the two
Fig. 1 – “Waterfall” or Sequential Development Method vs. Iterative Development Method A significant part of this new method is that the individual engineer is given much more say in the overall design process due to the collaborative nature of concurrent engineering. Giving the designer ownership plays a large role in the productivity of the employee and quality of the product that is being produced. This stems from the fact that people given a sense of gratification and ownership over their work tend to work harder and design a more robust product, as opposed to an employee that is assigned a task with little say in the general process . By making this sweeping change, many organizational and managerial challenges arise that must be taken into special consideration when companies and organizations move towards such a system. From this standpoint, issues such as the implementation of early design reviews, enabling communication between engineers, software compatibility and opening the design process up to allow for concurrency creates problems of its own
. Similarly, there
must be a strong basis for teamwork since the overall success of the method relies on the ability of engineers to effectively work together. Often this can be a difficult obstacle, but is something that must be tackled early to avoid later problems . Similarly, now more than ever, software is playing a huge role in the engineering design process. Be it from CAD packages to finite element analysis tools, the ability to quickly and easily modify digital models to predict future design problems is hugely important no matter what design process you are using. However, in concurrent engineering software‟s role becomes much more significant as the collaborative nature must take into the account that each engineers design models must be able to „talk‟ to each other in order to successfully utilize the concepts of concurrent engineering.
VARIOUS DEFINITIONS: Several definitions of concurrent engineering are in use. The first one is used by the Concurrent Design Facility (ESA): “
Concurrent Engineering (CE) is a systematic approach to integrated product development that emphasizes the response to customer expectations. It embodies team values of co-operation, trust and sharing in such a manner that decision making is by consensus, involving all perspectives in parallel, from the beginning of the product life cycle. ”
The second one is by Pennell and Winner, 1989: “
Concurrent Engineering is a systematic approach to the integrated, concurrent design of products and their related processes, including, manufacturing and support. This approach is intended to cause the developers from the very outset to consider all elements of the product life cycle, from conception to disposal, including cost, schedule, quality and user requirements.
ORIGIN AND BENEFITS: Exploring a technical design and management methodology through the investigation of its history may not be the intuitive path for most engineers, yet by locating concurrent engineering (CE) within its historical context it provides a more grounded understanding of the topic than could be gained through a different approach. Concurrent engineering and the ideas which define it constitute a systematic means of utilizing multi-disciplinary design teams, specific tools and techniques to overcome the intrinsic and institutional limitations associated with the design process. Concurrent engineering is fundamentally the acknowledgment of the necessity of communication among all the parties involved with the development, design, production and other aspects of a product‟s total life. It is primarily the failure to ensure sufficient inter-disciplinary communication and cooperation, as the design environment evolved, which caused sequential engineering to arise in the post Second World War period. By 1980, the combined factors of global competition, technological evolution and the severe limitations of widespread sequential engineering management practice collimated in a breakdown in American design methodology. This crisis in design methodology forced the reintroduction of earlier design methodologies along with the development of new techniques and tools to meet the added challenges of the modern design environment. This paper will begin by defining CE, then the author will consider CE‟s historical foundation, the evolution of the design environment which created the need CE was developed to fill and finally the reinvention, modernization and adaptation of CE as it has risen in prominence over during the recent past.
Concurrent Engineering - which is sometimes called Simultaneous Engineering or Integrated Product Development (IPD) - was defined by the Institute for Defense Analysis (IDA) in its December 1988 report 'The Role of Concurrent Engineering in Weapons System Acquisition' as a systematic approach to the integrated, concurrent design of products and their related processes, including manufacture and support. This approach is intended to cause the developers, from the outset, to consider all elements of the product life cycle from conception through disposal, including quality, cost, schedule, and user requirements.
Concurrent Engineering is not a quick fix for a company's problems and it's not just a way to improve Engineering performance. It's a business strategy that addresses important company resources. The major objective this business strategy aims to achieve is improved product
development performance. Concurrent Engineering is a long-term strategy, and it should be considered only by organizations willing to make up front investments and then wait several years for long-term benefits. It involves major organizational and cultural change.
The problems with product development performance that Concurrent Engineering aims to overcome are those of the traditional serial product development process in which people from different departments work one after the other on successive phases of development.
In traditional serial development, the product is first completely defined by the design engineering department, after which the manufacturing process is defined by the manufacturing engineering department, etc. Usually this is a slow, costly and low-quality approach, leading to a lot of engineering changes, production problems, product introduction delays, and a product that is less competitive than desired.
Concurrent Engineering brings together multidisciplinary teams, in which product developers from different functions work together and in parallel from the start of a project with the intention of getting things right as quickly as possible, and as early as possible.
A cross-functional team might contain representatives of different functions such as systems engineering, mechanical engineering, electrical engineering, systems producibility, fabrication producibility, quality, reliability and maintainability, testability, manufacturing, drafting and layout, and program management.
Sometimes, only design engineers and manufacturing engineers are involved in Concurrent Engineering. In other cases, the cross-functional teams include representatives from purchasing, marketing, production, quality assurance, the field and other functional groups. Sometimes customers and suppliers are also included in the team.
In the Concurrent Engineering approach to development, input is obtained from as many functional areas as possible before the specifications are finalized. This results in the product development team clearly understanding what the product requires in terms of mission performance, environmental conditions during operation, budget, and scheduling.
Multidisciplinary groups acting together early in the workflow can take informed and agreed
decisions relating to product, process, cost and quality issues. They can make trade-offs between design features, part manufacturability, assembly requirements, material needs, reliability issues, serviceability requirements, and cost and time constraints. Differences are more easily reconciled early in design.
Getting the design correct at the start of the development process will reduce downstream difficulties in the workflow. The need for expensive engineering changes later in the cycle will be reduced. Concurrent Engineering aims to reduce the number of redesigns, especially those resulting from post-design input from support groups. By involving these groups in the initial design, fewer iterations will be needed. The major iterations that do occur will occur before the design becomes final. The overall time taken to design and manufacture a new product can be substantially reduced if the two activities are carried out together rather than in series. The reductions in design cycle time that result from Concurrent Engineering invariably reduce total product cost.
APPLICATIONS AND EXAMPLES: Concurrent Engineering provides benefits such as reduced product development time, reduced design rework, reduced product development cost and improved communications. Examples from companies using Concurrent Engineering techniques show significant increases in overall quality, 30-40% reduction in project times and costs, and 60-80% reductions in design changes after release.
The implementation of Concurrent Engineering addresses three main areas: people, process, and technology. It involves major organizational changes because it requires the integration of people, business methods, and technology and is dependent on cross-functional working and teamwork rather than the traditional hierarchical organization. One of the primary people issues is the formation of teams. Collaboration rather than individual effort is standard, and shared information is the key to success. Team members must commit to working crossfunctionally, be collaborative, and constantly think and learn. The role of the leader is to supply the basic foundation and support for change, rather than to tell the other team members what to do. Training addressed at getting people to work together in teams plays an important role in the successful implementation of Concurrent Engineering.
An example of the use of Concurrent Engineering can be found in General Electric's Aircraft Engines Division's approach for the development of the engine for the new F/A-18E/F. It used several collocated, multi-functional design and development teams to merge the design and manufacturing process. The teams achieved 20% to 60% reductions in design and procurement cycle times during the full-scale component tests which preceded full engine testing. Problems surfaced earlier and were dealt with more efficiently than they would have been with the traditional development process. Cycle times in the design and fabrication of some components have dropped from an estimated 22 weeks to 3 weeks.
Another example concerns Boeing's Ballistic Systems Division where Concurrent Engineering was used in 1988 to develop a mobile launcher for the MX missile and was able to reduce design time by 40% and cost by 10% in building the prototype.
PROBLEMS FACED IN CONCURRENT ENGINEERING: Firms seeking competitive advantage to increase market share, profit, and growth have turned to concurrent development to speed the introduction of new products and beat their competitors to market. Despite some successes, implementing concurrent development has proven difficult for many organizations. Implementation failure is not unique to concurrent development. Similar failures plague firms seeking to implement a wide range of process improvement tools such as TQM, reengineering, and diverse best practices in product development . The hallmark of these failures is a mismatch between the technical, organizational, and dynamic complexity of the process and the mental models of the managers responsible for them, mental models that lead to inappropriate organizational structures, policies,and decisions. Studies of human decision making show that our mental models of complex systems are often simplistic and unreliable. Our ability to understand the unfolding impacts of our decisions is poor. Our mental models tend to have narrow boundaries and short time horizons: We find it difficult to incorporate interactions and feedbacks that cut across traditional functional disciplinary, or academic boundaries. We take actions that make sense from our short-term and local perspectives, but, due to our imperfect Appreciation of complexity, often feed back to hurt us in the long run.Many explanations have been suggested for the concurrent development implementation challenge.Backhouse and Brookes  suggest implementation fails due to mismatches among a development organization‟s people, controls, tools, processes, and structure,and the organization‟s need for efficiency, focus,incremental change, radical innovation, and proficiency.Other researchers focus on organizational issues ,personnel selection [14,33], personnel characteristics , and information transfer [9,21].Unfortunately, many existing theories treat either the structure of development processes without regard to behavioral issues (e.g., [2,11,18,22]) or focus on development team or participant characteristics without considering the process structure (e.g., [14,20]). We argue that improving the effectiveness of concurrent development requires models that explicitly account for interactions and feedbacks among technical, organizational, and behavioral features of the development process. In this paper we develop a formal dynamic model to explore interactions of concurrent process structure with the behavioral decision processes of the actors in the system.
The 90% Syndrome: The „„90% syndrome‟‟ is a common concurrent development problem in which a project reaches about 90% completion according to the original schedule but then stalls, finally finishing after about twice the original project duration has elapsed. The syndrome is common in industries including software, construction, consumer electronics, and semiconductors [1,10,19]. Our fieldwork with a leading semiconductor maker provides a typical example. Figure 1 contrasts the planned and actual progress of ASIC (Application Specific Integrated Circuit) development projects we call Python (top) and Rattlesnake (bottom). Python remained close to the original schedule through week 20 and was 73% complete by the original deadline. Progress then slowed from 1.8% per week to 0.9% per week, and the project was ultimately completed 77% late (week 69vs. 39). Rattlesnake was worse: Reported progress rises to 79% by the original deadline (week 34) but two unplanned iterations delay completion until over twice the original scheduled duration (81 vs. 34 weeks).Unplanned iterations and slow late-stage progress are typical of the 90% syndrome. To investigate the interaction of physical and information processes with managerial decision-making we built a dynamic model of concurrent development processes, described in , in this issue.
HOW TO IMPLEMENT CONCURRENT ENGINEERING TECHNOLOGY ?: To be successful with Concurrent Engineering, companies should initially:
compare themselves to their best competitors (i.e. benchmark) develop metrics identify potential performance improvements and targets develop a clear Vision of the future environment get top management support get cross-functional endorsement develop a clear Strategy to attain the envisioned environment get top management support get cross-functional endorsement develop a detailed implementation plan get top management support get cross-functional endorsement
Concurrent Engineering is a business strategy, not a quick fix. It will take many years to implement. If management doesn't have the time or budget to go through the above steps, then it is unlikely that Concurrent Engineering will be implemented.
Many companies have problems introducing Concurrent Engineering. Warning signs include:
unwillingness to institutionalize Concurrent Engineering maintenance of traditional functional reward systems maintenance of traditional reporting lines no training in teamwork unrealistic schedules no changes in relationships with vendors a focus on computerization rather than process improvement
To make Concurrent Engineering a real success, all the necessary information concerning products, parts and processes, has to be available at the right time. A lot of partially-released information has to be exchanged under tightly controlled conditions. EDM/PDM enables
Concurrent Engineering by allowing users, whether in small teams or enterprise-wide groups, to access, distribute, store, and retrieve information from a variety of sources. EDM/PDM systems give engineers and project managers access and release control over projects and drawings, as well the ability to track them.
Making Concurrent Engineering a success is really a management issue. If management doesn't get it right then it's not going to matter much whether EDM/PDM is used or not. On the other hand, EDM/PDM can provide valuable support to a successful implementation of Concurrent Engineering.