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.

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 cross-functionally, 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.

Polaroid Corp.'s Captiva instant camera is also the result of a Concurrent Engineering approach, as a result of which Polaroid was able to make literally hundreds of working prototypes. Throughout the process, development was handled by cross-functional teams.

To be successful with Concurrent Engineering, companies should initially:
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:
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.

Find out more about the product lifecycle in
Products2019: A project to map and blueprint the flow and management of products across the product lifecycle: Ideation; Definition; Realisation; Support of Use; Retirement and Recycling


Copyright 1998 by John Stark