Definition of Concurrent Engineering

one at a time. We refer to this method as stepwise feature introduction. Introducing a new feature may destroy some already existing features, so the method must allow us to check that old features are preserved when adding a new feature to the system.

Also, because the software is being built bottom-up, there is a danger that we get into a blind alley: some new feature cannot be introduced in a proper way because of the way earlier features have been built. Therefore, we need to be able to change the structure of (or refactor) the software when needed (Back 2002).

3.1.5 Concurrent Product Development

An important characteristic and primum mobile of NMP product development is the concurrency that can be seen everywhere in the organisation. The core idea of concurrent product development is to propagate the concurrency throughout the organisation and in different levels of product design (Cleetus 1992b). NMP has understood and efficiently implemented this idea. Entire projects work concurrently in order to launch new products in different market areas according to product roadmaps. For each project, the actual product development, sales and production units work concurrently targeting for the same launch day (Lindén 1999). Inside each project, all R&D is done concurrently aiming strictly for the same project milestones. Even inside design teams, sometimes multi-site teams, the product design details are finished concurrently between different team members.

Lindén, research director at Nokia, theorizes (1999) that in a multi-site virtual organisation in principle it is possible to optimize the efficiency of product development concurrency: the work that is started in Japan in the morning, can be continued in Europe or USA when the day goes on. The negative effect of continuous work transfer would be the increased need for job control and coordination while swapping the tasks between teams. Control and job organisation are unproductive tasks that do not contribute to actual product development (Järvinen 1999).

(Oxnevad 2001). There are two widely referred definitions of CE, both having focus on the customer. The "original" of Winner et al. (1988) and the improved of Cleetus (1992).

Concurrent engineering is a systematic approach to integrated development of a product, and its related processes. It emphasises the response to customer expectations and embodies team values of cooperation, trust and sharing. This is done in such a manner that decision making proceeds with large intervals of parallel working by all life-cycle perspectives, synchronised by comparatively brief exchanges to produce consensus (Winner et al. 1988).

Cleetus (1992) proposes an improved definition for CE by considering what is actually involved in practising it:

Concurrent engineering is a systematic approach to integrated development that emphasises response to customer expectations and embodies team values of cooperation, trust and sharing in such a manner that decision making proceeds with large intervals of parallel working by all life-cycle perspectives early in the process, synchronized by comparatively brief exchanges to produce consensus.

The definitions do not give explicit guidance on applying CE. Thus, CE can be applied in many ways because it is basically a collection of methods, tools and work practices (Heikkinen 1997).

Cleetus⁷ writes:

CE is a way of thinking about any problem, from its definition to is solution, and though all its principles may not have a prominent application in every problem, still it is worth thinking about any problem and keep on asking the questions that a knowledge of CE would prompt you to ask.

The components of CE can be divided to three categories (Winner et al. 1988, Pawar and Sharifi 1994):

1. Engineering Support Initiatives (Human Factors). These include usage of multi-disciplinary teams, organisational considerations, management support and commitment, availability of skilled people and training, customer focus, and management of the design process.

2. Computer Based Support Initiatives are intended to allow the product development teams to work as effectively as possible.

3. Formal Methods are needed to increase discipline and visibility of the development process.

Heikkinen notes that the key to the CE approach is in the introduction of product teams:

Members of the team are drawn from all business functions:

marketing, sales, different engineering disciplines, production, after-sales support and quality. Team members meet regularly, and consider the life-cycle of a product at all stages of development. This means that each function can start its work at the earliest possible time, with many activities that were

7 Personal correspondence, 10.12. 2001.

traditionally carried out in sequence now being executed concurrently.

CE outcome (product) can be material (such as mobile phones) or immaterial (software).

However, CE is highly applicable in such product development where the final product consists of multiple integrated technologies or engineering outcomes, for example integrated software, hardware and mechanics.

By default, CE has focus on the customer. The definition sets the design team’s goal in terms of customer satisfaction, rather than in achieving, for example, company proprietary standards.

Still, all formal attempts to define CE fail to explain how it actually helps in responding to qualitative customers' expectations, such as fulfilling user needs. Current research documentation does not give evidence, with one exception (Chao 1993), that, for example, CE enables better implementation of user requirements or that customers really have participated CE product development. However, there is evidence that customer satisfaction issues are handled before and after CE process (Valjus 1994), but not during it.

The main objective of CE is to decrease product development time. The secondary objectives are to decrease costs and to provide quality of use (Winner et al. 1988). However, CE can also be applied to such development projects that do no have “users”. Decreased product development time is obtained by dividing work to smaller entities that can proceed in parallel instead of advancing sequentially, and by decreasing the amount of research work in the project, hence focusing on the actual implementation. Decreased costs are a consequence of development time savings, better teamwork and the capability to avoid costly reworks (Pennell et al. 1989).

CE requires but also stimulates efficient communication between development teams.

According to Boland and Tenkasi (1995) innovative product and process creation requires the ability to make strong perspectives within a community, and the ability to take the perspective of another into account.

Though CE improves some aspects of product development, it does not come without problems.

The documented problems of CE are related on managing the work:

- difficulties in effective management of teams, team member's limited knowledge, cost of maintaining teams (O'Grady and Young 1991),

- large scale design project is difficult to manage as a whole (Kusiak and Park 1990),

- "missing piece in the puzzle of concurrent engineering is management" (Blackburn et al.

1996).

- there is complicated interaction among concurrent processes and products that may be updated concurrently (Aoyama 1993).

- some activities need to be performed sequentially, i.e. they cannot be split to parallel tasks.

- an activity or a component may have many relations or dependencies to other activities or components. This can be problematic especially in multi-site development.

CE in multi-site organisation is a paradox. On the one hand, CE enables multi-site product development by dividing the work on concurrent entities, but on the other hand multi-site development by definition doesn't encourage for teamwork:

- CE supports process and job allocation to entities that can be handled independently.

- multi-site product development requires process and job allocation to independent entities.

- CE requires efficient communication between development teams.

- multi-site product development decreases communication between remote teams. Increased physical distance decreases communication.