Case Study: Concurrent Engineering

Concurrent Engineering has been used by many corporations since 1980 as a tactic to plan a new product in integrative manner. It is a system of designing and developing products, in which the dissimilar stages operate simultaneously, rather than consecutively. Traditional product development system which has a very little synchronization between diverse functions and absence of product life cycle perspectives is replaced using Concurrent Engineering. Concurrent Engineering not only gives the opportunity for creating new products in least time, but at the same time helps in upholding the highest quality at lowest conceivable price.
Case study: Space Mission Assessment and Design. Pre-Phase-A assessment studies were carried

Concurrent engineering is used in order to ensure the design process converges on an optimised result. The process began with a few meetings involving experts such as customers, team leader and system engineers so as to polish and formalise the task necessities, to define the limitations and to evaluate the resources essential in order to accomplish the study objectives. It is an iterative method that addresses every feature of the system design in a swift and comprehensive fashion. By using Concurrent Engineering, it reduces the risk of improper or contradictory design assumptions, as each key decision is debated and decided cooperatively. The customer along with the other specialists are invited to participate in all sessions, so as to contribute to the preparation of the study norms, answer queries from the team, and follow the progress of the design. The sessions are conducted in an accommodation that encompasses a design room, as, a meeting room and project support office space. The layout is designed to simplify the design process, the interaction and the participation of the experts. The experts with most recurrent interactions and positioned close to each other for the smooth functioning of the system. Videoconferencing gear is mounted to allow team members to contribute in each session from their distant locations. The first session basically begins with customer presenting the mission necessities and restraints to the team and in the following sessions, each expert presents his solution and a baseline is retained and the associated values logged in a common database. The key factor is to have a process that is independent on the path followed. At any stage is must be possible to take and alternative path and the process should not be blocked by deficiency of data or choices. An