Decision-aiding tools in innovative product development contexts

Abstract

The complexity and uncertainty that exist in New Product Development (NPD) processes require a comprehensive approach to deal with a problem that involves people, technology and organisations. An effective approach should integrate tools that facilitate communication, the interpretation of different individual visions and collective problem structuring with tools that analytically study the process activities of NPD. This paper presents the results of a study that began from an observation of the phenomena involved in an NPD process and from the analysis of some tools from different domains (Product Lifecycle Management, Management Science/Operation Research, and Knowledge Management). The analysis of the benefits and drawbacks of the tools suggested a general framework, the Hybrid Approach, for the systematic integration of tools, from different perspectives, where typological decision-aiding situations are recognised and modelled and where context and communication in design are considered.

1 Introduction

New Product Development (NPD) processes are characterised by numerous elements of complexity, and firms face various challenges to manage them (Adler 1995; Brown and Eisenhardt 1995; Ettlie 1995). New competition mechanisms have modified products and processes, such that products are technologically more complex and demanded to have quicker time-to-market and higher reliability levels. Processes must be more flexible and should be re-engineered and composed of the lowest possible number of operations.

These new features of products and processes have caused profound changes in organisations. They have led to new forms of cooperation and coordination among communities with highly specialised technologies and have defined complex networks of firms that are involved in common innovative processes. Because of the close link with innovative processes and its inter-functional and multidisciplinary features, NPD processes require tools and methods to acquire and structure the essential knowledge elements that can help face innovative situations.

These problems entail paying extra attention to NPD processes and call for new research in NPD management to update and adapt methods and tools for this new industrial demand. From an academic point of view, numerous contributions have been developed to define models of NPD processes (for a review, see Ulrich and Eppinger 2004), and numerous studies have studied the effective management of NPD projects or analysed problems such as “design co-ordination” (Whitfield et al. 2002) and knowledge management (Schilling 2005) in design. From a industrial practice viewpoint, new management perspectives on new product development processes, such as Knowledge Management (KM) and Product Lifecycle Management (PLM), with their IT support systems (i.e., PDM, EKMS, etc.), are viewed as the way to assist firms support NPD processes (Baxter et al. 2007; Sharma 2005).

In this paper, the elements of complexity of NPD processes in innovative contexts are studied by considering decision situations. In particular, different “Contexts of Action” (CoA) (Norese and Ostanello 1988), which are recurring sequences of supporting activities with a unique objective, are instantiated in NPD processes. These CoA focus on specific operative or cognitive purposes that require different support tools.

This work does not study project tasks or outcomes, nor does it define new systems for information management. It starts from an analysis of phenomena involved in NPD processes to define a systematic approach to NPD management that matches, in each specific phase of the NPD process, the design-decision needs or objectives and the support tools. The approach integrates different perspectives and diverse support tools from different domains (Engineering Design, Knowledge Management, and Management Science/Operation Research), by considering the specific operative or cognitive purposes of the tools.

Three ideas are considered together in the paper: (1) a decision perspective on NPD by using a Hybrid Approach (HA); (2) the integration of different domains and consequently the integration of different tools and (3) the contextualization of tools that support design activities in relation to the activity specific objectives.

By considering that the paper proposes a decision perspective on NPD, really, also Krishnan and Ulrich (2001) consider the decisions made in the NPD process (but before Marples 1961) and explicitly declare that these decisions involve different academic fields. However, the HA does not consider simple decisions but real decision processes and the problem solving processes involved, in a logic that is closer to the one proposed in the industrial design literature (Archer 1984, see also Cross and Roozemburg 1992). These problem solving processes call far diverse support tools that have diverse purposes and can be categorized in relation to the activity specific objectives.

Literature provides diverse attempts of characterizing the variety of design methods according to specific characteristics (e.g. Birkhofer et al. 2002a; Birkhofer 2008), such as generalised steps of problem solving (Lindemann 2005) or specific objectives (Jones 1970). The HA, however, describes a “general-purpose” framework for the integration of different tools, and it proposes different tool configurations, including tools for decision-aiding and for engineering design activities.

Bearing in mind the idea of integration, many efforts have been made to integrate different tools: STEP models for concurrent engineering or simultaneous engineering and agile design/manufacturing (e.g., Finger et al. 1993; Coates et al. 1993; Reich et al. 1999) or for software applications, (such as Service Oriented Architecture, Shenfiels and Fleming 2005), among others. In contrast to them, the HA focuses on information management but does not describe a specific tool configuration or a specific DSS. It instead focuses on the decision context of design and the variety of decision-making processes to effectively integrate different tools that originate from different fields into an integrated framework.

Additional literature presents methods that consider integrating diverse disciplines and business practices; some of these methods support concept generation (Hari et al. 2004; Presley et al. 2000; Ziv-Av and Reich 2005) and some even consider resource constraints (Fung et al. 2003; Reich and Levy 2004). Konda et al. (1992), in particular, recommend that design methods need to be contextually evaluated as part of creating a “shared memory”. Shared memory (in its horizontal aspects) requires meanings shared among multiple disciplines, groups and members. The attention on the context and the integration of different disciplines in a shared memory define some similarities with the HA. Yet, the HA augments these studies by proposing a way of analysing and reasoning in the decision context to effectively integrate different tools into an integrated framework where tools for communication, uncertainty reduction, and decision making are particularly relevant.

This paper has a theoretical character, but the practical experience has been matured in supporting design activities of real projects, in which decision-aiding tools, integrated with more traditional engineering design tools, have been significant (e.g. Macramè in Montagna and Norese 2008; Multicriteria analysis in Norese et al. 2007). Among them, Montagna and Norese (2008) represents the first complete description of a HA application for supporting the NPD management in a firm of the Italian automotive industry. All these experiences have induced the author to analyze in this paper all the NPD phases, in order to understand how to apply the HA in each NPD phase.

Section 2 deals with a detailed study of the NPD environment. The ISO 9001 and ISO TR 14062 norms represent the reference for the NPD phases in the paper. The considered phases are Planning, Concept Design, Detailed Design, Testing, Production Launch, and Product Review. The HA, the systematic “general framework,” and some of its modules, that represent different typological situations, are presented in Sect. 3. The method for identifying decision processes and decision-aiding situations in the NPD process is necessary for the collocation of NPD phases in the general framework and for the HA application. This study is carried out systematically in Sects. 4 and 5. The HA application, the identification of some useful tools for each phase and their integration possibilities, are discussed in Sect. 6. Managerial implications and conclusions are provided in the final two sections of the paper.

2 The elements of complexity of the NPD process

“Complexity” means different things to different people, and it is used in myriad ways (Thomson et al. 2005); it is surely an everyday term in engineering. The concept of complexity is not entirely clear, and it often implies the following attributes: a phenomenon that consists of many parts, many relationships/interactions among the parts and combined effects that are not easily predicted and may often be novel (Corning 1998). One known mathematical complexity theory is “Kolmogorov complexity” or “algorithmic complexity” (Kolmogorov 1965; Cover and Thomas 2006). It measures the information content of individual objects but is limited to objects that can be mathematically modelled or turned into algorithms. In this case, complexity was treated in terms of an absolute measure. Only some contributions have defined complexity in the context of their respective fields of research (Lewin 1994), or largely connected to the subjectivity of the observer (Lewin 1994; Corning 1998). In axiomatic design, Suh (1999) stresses that complexity is defined only relative to what it is trying to achieve and/or wants to know. Also in this case, complexity is considered related to uncertainty and to the information content in design that must be mathematically modelled. Moreover, Product development often has been declared complex and frequently has been described as an exercise in information processing (Adler 1995; Allen 1977; Clark and Fujimoto 1991; Eppinger 1991; Tatikonda and Rosenthal 2000). Many models were studied to manage its complexities (e.g. Stewards 1981; Eppinger 1991; Eppinger et al. 1994). However, the impossibility of associating complete mathematical models to this process makes it infeasible to evaluate design processes only with quantitative concepts. The relevance of organizational and social processes in considering the NPD complexities is carefully described in Subrahmanian et al. (1993).

If the objective is identifying the elements of complexity of the NPD process, the link between complexity and uncertainty must be investigated. Uncertainty and complexity are strictly related because they observe the relationship between a system and its behaviour. Complex behaviour does not always arise in a complex system, and a simple system does not always present simple behaviour; simple systems may display unexpectedly complex behaviour, reflecting some underlying uncertainty. Moreover, uncertainty is an issue of decision-making processes, and some authors (Duffy et al. 1995) have identified it as an issue that determines complexity in design within a team environment, where the management of decision processes is more difficult and heavily impacts on design performance.

Uncertainty in a process can be initially defined as ‘the difference between the amount of information required to perform a task and the amount of information already possessed by the organization’ (Galbraith 1977, p. 36). A more uncertain task implies the greater quantity and quality of information processing required during the task’s activity to generate necessary knowledge to complete the task (Galbraith 1977). In some cases, this definition of uncertainty is insufficient. Friend (1989) identified three typologies of uncertainty (which will be constantly used throughout the paper), but only one typology refers to the lack of information. Uncertainties (UE) in the operating Environment can be dealt with using responses of a mostly technical nature (such as surveys, investigations or cost estimations). Uncertainties (UV) pertaining to guiding Values may be present when organisational structures result from strategic choices. They demand more political answers such as exercising objective clarification or consultation programmes among people. Finally, uncertainty (UR) that pertains to Related decision fields are present when a major stakeholder is not involved in the decision-making process. This last uncertainty typology demands answers in terms of the exploration of the structural relationships between the decision currently in view and others that appear to be interconnected.

Different elements can determine uncertainty in the NPD process; in this paper, the elements considered mainly relate to:

• The economic and technological environmental conditions in which the firm operates;

• The products’ rate of innovation;

• The features associated with each process phase; and

• The organisational context of the NPD process.

Considering the economic and technological environmental conditions in which the firm operates, some authors (Tatikonda and Rosenthal 2000) distinguish between external and internal characteristics of technical development; for them, external characteristics do not include the newness of the technical development. Some other authors, in the specific area of engineering design, focus on concepts such as technology familiarity (Adler 1995; McDonough and Barczak 1992; Meyer and Utterback 1995; Helfat and Raubitschek 2000) or market familiarity (Lynn and Akgun 1998; Souder and Song 1998; Chen et al. 2005). One could think that all of these elements, above all the external ones, ‘give little sense of a project’s technological challenges or project execution concerns’ (Tatikonda and Rosenthal 2000). On the contrary, in this paper, these environmental conditions are considered relevant because they define the most uncertain elements on guiding values (UV), influence the design goals, and are mainly present in the early stages of the NPD.

Considering the product innovation rate, many definitions are present in the literature. Each of them is focused on different aspects: product or processes (Utterback and Abernathy 1975), competence enhancing or competence destroying (Tushman and Anderson 1990), sustaining or disruptive (Christensen and Rosenbloom 1995), among others. The Henderson and Clark (1990) taxonomy considers the aspects related to technologies and configurations of product components. By this taxonomy, four innovation typologies emerge (modular, incremental, architectural and radical) that can be related to different uncertainty levels. Innovations that do not need changes in terms of technology or in the product configuration are called “incremental” and employ both pre-existing technological knowledge and architecture. When innovations change technologies but do not change the product architecture, they are called “modular” and induce local changes in the required knowledge but not in the architecture. Innovations that use known technologies but modify the product architecture are known as “architectural” they change the product’s internal organisation to a great extent. The last typology is represented by “radical” innovations, where the product’s technology or architecture changes and knowledge, competence and organisation are discussed. Radical innovations are certainly rare and represent the most uncertain situations in the complexity space.

NPD processes and their phases are intrinsically different in terms of uncertainty. It is intuitive that some stages are more uncertain than others. The early stages, for instance are considered to be more uncertain than phases at the end of the NPD process, where all the technical decisions are already made. In fact, the uncertainty level of each NPD phase is related to the decision process of the phase, and it is not completely true that as the design progresses, uncertainty diminishes. This assumption is true only if uncertainty is considered as a pure lack of information; the presence of UR and UV uncertainties, as defined by Friend (1989), in NPD processes makes some advanced phases of NPD processes uncertain as the initial phases. The Planning phase, for instance, is characterised by several elements of uncertainty that determine “unstructured situations” due to new technologies, customers’ needs, competitors and organisational targets and values. The Concept design phase is characterised by some of the uncertainty elements that are partially solved in the Planning phase and some that are still active, such as uncertainties connected to customers’ preferences or to mistakes in the design process. On the other hand, the Production Launch is again characterised by several elements of uncertainty because the market response and production planning objectives and needs (UE, UV) are still not known.

The last element that determines uncertainty is the organisational context. The communication absence situation, for instance, is the most chaotic and uncertain. Communication, in fact, is the basis of coordination, cooperation and collaboration in organisational activities: if it is not, all of the other conditions fall apart. Institutions in charge of coordination are sometimes present in the firms, but there is no careful management of information on operating activities among the work groups, and the coordination of the activities is therefore more difficult. These situations are therefore characterised by uncertainties concerning the elements of information and the information sources. Where communication and coordination exist, cooperation and collaboration are possible, but UR (e.g., procedures are unclear) or UV (e.g., lack of shared goals) uncertainties can be present within teams. This fourth dimension is extremely important because it is responsible for the presence of procedural and organisational problems in the NPD process. Tiwana and Ramesh (2001) in particular identify specific problems due to organisational reasons:

• The lack of shared understanding (SU) in diversely structured ad-hoc teams,

• The loss of process knowledge (PK) and skill synergy (LS) due to team fluidity,

• The repetition of mistakes (RM) and the reinvention of solutions (RS) due to the inaccessibility of existing design knowledge,

• Versioning inconsistencies (IV),

• The inaccuracy of decisions for leadership changes (LC) or lack of shared goals stemming from non stated assumptions (UA).

An approach that supports a systemic perspective for the acquisition and structuring of knowledge elements, able to induce new knowledge representations to be created and proposed in communication contexts, could mitigate problems and support NPD processes (as can be seen in Table 1). Aspects of this are apparent in the applications that follow C–K theory (Hatchuel and Weil 2009).

Table 1 HA application in the NPD contests

This approach must be supported by an integrated perspective whose focus is on external and internal environments at decision and operative levels, which could be useful for companies. This multilevel analysis would allow acquiring and structuring knowledge elements that are useful to reduce complexity and uncertainty; activating learning mechanisms on critical aspects; and finding solution opportunities in decision processes. Each described action needs different tools and, for this, an integration of different methods, tools and technology in a decision-aiding procedure is the natural consequence of the approach.

Reich et al. (1999) developed an infrastructure called n-dim, whose approach consists of a diverse set of tools and methods borrowed from a wide range of disciplines according to the context being studied, which can be composed in different ways to match the complexity of design contexts and work. This paper emphasises this perspective and the information management activities in engineering design, but it also highlights the need for methods and tools that investigate the decision context of design and the variety of decision-making processes that comprise uncertainty reduction in engineering design situations.

3 The hybrid approach (HA)

The Hybrid Approach (HA) declares to provide a method of analysing and reasoning in decision contexts to effectively integrate different tools derived from different fields in an integrated framework, where tools for communication, uncertainty reduction, and decision making are particularly relevant. Specifically, the HA, starting from the analysis of decision processes, uses tools that facilitate communication, the interpretation of different individual problem definitions and the collective problem structuring. This means integrating tools from fields, usually known as “soft” Operation Research and Management Science, with others from fields, such as Engineering design.

This work particularly focuses on the perspective of an analyst supporting a decision activity (see also for this theme, Boland 1978). The proposed method aims to synthesise the right steps that bring him to the definition of a satisfactory solution. This consists of a careful abstraction process that starts by considering the main process to which the supporting activities are applied. As Fig. 1 shows, the ‘main process’ to which the HA is applied, in this paper, is the generic NPD process. The ‘analyst’s technical work’ runs in parallel to the main process, and the HA, with its four steps, is included in it.

Fig. 1

Application steps of the Hybrid Approach

The methodology’s four steps (summarised in Table 5 with the analysis results) guide the analyst’s activities during the work and can be described as:

• STEP1: The identification of decision moments in the NPD. The actors, the organisation and the environment in which the decision is made must be represented; the nature of the constraints that make the decision difficult and the operative processes must be described.

• STEP2: The identification of decision processes in the NPD. The model proposed by Mintzberg et al. (1976) is used as the main reference to define the typologies of decision processes on the individuated decision moments.

• STEP3: The paths and the main typologies of the decision-aiding processes in order to adapt the Hybrid Approach to NPD are identified in this step. Any decision-support process is oriented to face a specific decision problem, whose characteristics determine the nature and purpose of the aid to be provided and therefore the activities and procedures to be performed. Different technical actions characterised as the sub-activities of the support process permit the achievement of technical needs or, on the contrary, can recall the activation of other related technical actions.

• STEP4: Different technical actions that focus on specific cognitive, operational and organisational purposes require specific support tools. In this step, the integration of the diverse tools and perspectives takes place.

These four steps of the Hybrid Approach are justified by three main needs that result from the analysis of the author experience matured in the Operation Research and Decision-Aiding domains:

• The need for investigation into the decision and/or operational context (i.e., the “Context Understanding”) to structure the problem and the information context and to describe processes and their evolutions, among other tasks. From this investigation, specific problem situations, their main complexities and the imperative needs for the analysts emerge. STEP1 and 2 arise from this need.

• The need for the identification of the right tools in relation to the different purposes. STEP3 faces this need.

• The need for the integration of different perspectives and tools. This need involves the forth step of each application but also represents the final objective of the approach.

When someone faces a new problem, or when a decision-aiding intervention is activated, context must be understood. The focus on context is present in many disciplines (Dey et al. 2005) and in particular some approaches to design (i.e., n-dim approach, Reich et al. 1999) emphasise modelling and the use of contexts. Konda et al. (1992), in particular, recommend that design methods be contextually evaluated by using “shared memory”. This paper considers context as the decision, organisational and operational contexts.

Deeper knowledge on decision, organisational, operational contexts will result in a clearer and more complete modelling of the core problem. However, that means that the technology, the people and the organisation must be taken into account together and that the need for a clear and complete modelling of the problematic situation involves two specific issues:

• The breaking down of the problematic situation into the relevant aspects.

• The use of new tools because classical tools (optimisation methods, statistical tools, etc.) on their own are insufficient to face a problem that involves technology, people and organisations.

Several methodologies or tools have been proposed in the literature, but few of them (for example, n-dim has a perspective similar to the HA) were created (or are normally used) to deal with a complex problem situation from all of the useful points of view. In order to capture all of the useful elements for modelling the problem situation, a sequence of different technical actions is needed and can be faced by the integrated use of different tools. The integration has to occur among tools that are carriers of different perspectives and points of view. Like the horizontal shared memory of Konda et al. (1992), which provides different perspectives and addresses the sharing of meanings between individuals who are separated by disciplines, experience, culture, etc., this HA condition aims to provide the global reading of the context and all the technological, organisational and social aspects are considered.

In light of this, the combined use of many tools is a direct consequence of the need for a complete understanding of the problem situation. In fact, another relationship that has an inverse effect exists: the need for the conscious use of tools leads to the careful modelling of the problem situation. Reasoning on decision and operative situations or recognising and limiting their elements of complexity are essential conditions for a consistent approach, for the identification and the correct use of a tool and, if needed, for an intelligent integration of different supporting tools (Norese and Ostanello 1988; Montagna and Norese 2008). Most of tools and methodologies, in fact, have benefits as well as limits and can be utilised in different situations, but not in all (see e.g., Reich 2010). Sometimes a tool has to be excluded a priori; sometimes it can be used, but only after a context analysis that defines the applicability conditions. The directions for use of the same tool, moreover, differ in relation to the problematic situations. Each situation, understood in relation to the decision/operative context, induces the identification of a sequence of different technical actions. That explains the need of a third intermediate step (decision-aiding identification) before the forth step. Only the clear definition of the needed technical actions can be translated into a sequence (often, nonlinear) and synthesis of different tools.

The general framework of the HA (as described in Montagna and Norese 2008 and shown in Fig. 2) explains the sequence of supporting activities in an application of the HA that can be executed by the analyst. Initially, the application of the HA is possible only through the indication of a specific problem situation and its main complexities that emerge from the decision (i.e., decision moments and processes are individuated, STEP1 and STEP2) and/or from the operational context (i.e., decision-aiding processes are identified, STEP3). The imperative needs for technical action are used to define strategic priorities, and this discernment determines the “contexts of action” (CoA) and the expected results. CoA are recurring sequences of different activities that can be aggregated by a unique objective. Focusing on specific operative or cognitive and sometimes also political–organisational finalities, they call for different support tools from different fields and perspectives (STEP4).

Fig. 2

The general Hybrid-Approach framework

In general, there are only four main objectives when an analyst acts—Identification, Structuring, Development and Control—which define the four main Contexts of Action, labelled Id, Str, Dv and Contr, respectively (Norese and Ostanello 1988). The CoAs can develop at a Communicative Level (CL), a Technical Level (TL) or a Technical and Communicative Level (T/C L). If the communicative level is prevalent, the Id, Str, Dv and Contr contexts of action are labelled Com\Id, Com\Str, Com\Dv and Com\Contr.

As shown in Fig. 2, the communicative level is prevalent in the first phase of the analyst’s work because of the need for activities performed by the problem owner aimed at identifying the complexity elements, structuring the problem situation and analysing the decision and the operational context. The Technical Level (TL) or the Technical and Communicative Level (T/C L) can both be present at the subsequent steps. That depends on the imperative needs that emerge and which are used to instantiate different HA applications.

The main perspectives and the imperative needs that result from the preliminary structuring of the problem situation define different typological situations. Therefore, the dotted module changes in relation to the presence/absence of specific contexts of action in the decision-aiding process (and also in the application of the HA) and brings about three different typologies (Montagna 2007), which are illustrated in Fig. 3.

Fig. 3

Hybrid-Approach application typologies

The presence of Development CoAs (Dv and Com\Dv) defines the first typology of an application of the Hybrid Approach. It is defined as the Formalisation and Choice of known solutions. A typical instance is the application of the Hybrid Approach to some NPD Testing phase situations, where the testing activities are aimed at evaluating specific product and process features. In the second typology of a Hybrid Approach application, the Development and Structuring CoAs are prevalent (Com\Str, Dv, Com\Dv), and the application is defined as Multidimensional Problem solving. A typical instance is the application of the Hybrid Approach to the Product Review phase. The integration of all the knowledge elements, concerning the old and new aspects of the product and process, and the tracing of the decision paths (where abandoned or interrupted decisions are also outlined and metadata concerning decisions are managed) can be the problem dimensions. The last typology is Decision Problem Structuring, which occurs when strategies, obtained through a synthesis of different points of view and correlated decisions, must be developed to face a contingent decision situation (as in the first phase of the NPD process). Uncertainties that make the decision difficult are always present in these situations, and the ‘decision problem-structuring’ imperative requires identification and structuring activities (Com\Id, Com\Str) for the uncertainty analysis and the control or the development of compatible strategies and the selection of the best ones (Com\Dv).

Each context of action is also structurally determined by the presence of specific elementary activities, named routines, (Ri, as shown in Fig. 3), which the Hybrid Approach classifies as identification (R1), structuring (R2), control (R3), development (R4) and communication (R5). The ambiguity of the naming between the routines and the CoAs is due to the fact that sometimes it can result in the difficulty of tracing the limit of the importance of an activity inside a process: it can represent just a small task of a procedure, or it can grow until it takes on the significance of a decision context or a phase. Of course, each context must involve activities that allow a fast implementation of the objective, namely identification activity (R1) in the context of Id, structuring (R2) in the corresponding Str context, and so on. Nevertheless, R1 activity should not necessarily be performed only in the context of identification; it should also be possible for it to be carried out in other contexts and combined with other activities. It is possible to have, for example, an identification (R1) of information sources available in the organisation, followed by a check of their reliability and usability of the data available (R3), which take place in a context of structuring (Str) the operational solution to be adopted. The degree to which the different activities/procedures are linked to the main contexts of action (CoA) in which they are included and how CoAs, in turn, constitute the sub-processes of the main decision and decision-aiding process will be explained in detail in Sect. 4.

The different typological situations shown in Fig. 3 represent modules of the general framework. This approach has been applied in a complete way in some situations (e.g., Montagna and Vittone 2008; Montagna and Norese 2008; Norese and Montagna 2008; Norese et al. 2007). In these situations (as probably in every complex one) more modules were needed in the decision-aiding work, and the work was described using more modules (as in Fig. 4, which describes a case of HA application). Feedback is naturally included in the general schema. The sequence of the CoA and of their R_i activities is often not linear because several iterative cycles might be necessary and it is not easy to estimate the required time for this approach.

Fig. 4

A Hybrid Approach application

4 HA application STEPS1 and 2: identification of decision moments and decision processes

The identification of decision moments represents the first step of the analyst’s work. NPD can be defined as a process that includes many generic “decision points”, such as defined by Krishnan and Ulrich (2001). Moreover, some contributions concerning the NPD decision process (e.g., Urban and Hauser 1993) and the definition of the critical decision points in the NPD process (i.e., Büyüközkan and Feyzioğlu 2004) exist.

In this work, the critical decision points in the NPD process are mainly the moments in which the design process requires the application of operative tools to conceive, select or modify:

• The functional model or component set of the product or the process, or

• Procurement or distribution arrangements and the project schedule.

The actors, the system in which the decision is made, and the uncertainty elements that characterise the decision must also be represented. Additionally, the nature of the organizational constraints that cause the operative complexity must be carefully studied. This means for instance, understanding if marketing competences are involved in the concept definition or only the design team is entirely in charge of this activity, as well analyzing in detail the strategic value of the developed products in relation to company objectives and product portfolio.

This need for a detailed description and for informative elements explains the need for a good knowledge of the NPD process and activities. It is necessary to identify in detail the downstream and upstream activities of a decision moment to contextualise decision processes in the main NPD process. All information elements (goals, controls, input, output, etc.) related to activities must be used to define the problem situations of each decision problem. This phase can be re-iterated every time the decision problem changes.

The main activities of the NPD process are defined by the ISO 9001 norms in general and by the ISO TR 14062 norm if a lifecycle perspective is preferred. However, IDEF-0 can be used to make a process model with all activities, relationships, constraints, interactions and information elements, among others. This choice is motivated by the importance the tool gives to the environmental definition and to the description of the system characteristics and by the ability of IDEF-0 to analyze very complex systems with a standard language, ensuring the homogeneity of the model outputs. The IDEF-0 analysis has led, in some cases, to a validated descriptive model of the NPD process, which resulted in all of the process phases and actors and the decision system. As an example, the results of the Planning phase analysis are shown in Fig. 5 and Table 2.

Fig. 5

Phase I—planning phase

Table 2 Phase I—planning phase

For each activity of the described NPD phases, in order to label and analyse decision moments are used:

• The concepts of ‘Decision areas’, in which the important elements for the decision can be defined;

• The three typologies of uncertainties (UE, UV and UR described previously in Sect. 1) that afflict the decision;

• The “exploration options” that can be studied for the uncertainty reduction (Friend 1989).

Decision moments, located inside the activities of the main process, are always associated with decision processes.

Consequently, in addition to this first step of analysis (whose results are shown in the first three columns of Table 3), in the second step of the HA, the decision processes proposed by Mintzberg et al. (1976) are used as the main reference to define the typologies of decision processes on the individuated decision moment. By considering his studies, it is possible to distinguish three main decision processes: the Selection/Choice processes that are the simpler decision processes and consider existing problem solutions, Development¹ processes that are aimed at the construction of problem solutions in relation to clear objectives, and the Unstructured decision process, that are Strategic decision processes where problem solution must be constructed above and beyond a structuring activity of unclear objectives. This classification associated to NPD decision moments is shown in Table 3. Note that the decisional processes mentioned are the representative of these NPD phases but could also involve other processes; for example, a simple analysis could involve development process in generating appropriate model for the product being analyzed.

Table 3 Decision processes in the NPD Process

In the first NPD phase, the company must succeed in strategically defining a new product. It therefore must make decisions in terms of positioning the product on a market, in terms of the product’s characteristics (so that it appears to be different from the other contenders) and in terms of the level of innovation (product design and engineering, production processes, innovative technologies, etc.). In light of this, the design team will have to make design decisions to generate new ideas and will have to select, develop and test the more promising ones in order to respect the development and production costs and satisfy the customers in a timely manner. The elements of uncertainty of this phase are mainly related, within the company, to organisational goals (UV) that greatly limit the design choices in terms of times, costs, resources and, outside the company, to the choices made by competitors (UR), and they are also related to the customers’ preferences (UE). Uncertainty in the work of the design team associated with new technologies (UE) and legal norms (UE) are also present. These uncertainties can limit the design choices to a great extent in terms of materials, technologies and production processes. This first phase, which is the most strategic and according to which all the other decisions will be conditioned, can be associated to decision processes for unstructured situations.

In the Concept Design phase, the team will have to make design decisions for the selection of the first design solutions and the definition of concepts. The design team will also have to make decisions concerning the engineering of the product and the concept of the production process. All project management decisions must also be taken into account in this phase. The elements of uncertainty in this phase concern customer evaluations (UE). They cannot be considered solved until the concept is evaluated in terms of product functionality and in relation to design specifics. Among the three typological processes, the Development (for the concept definition phase) and Selection (for the selection of the design solutions) processes are the most exemplary of the Concept Design phase.

The third NPD phase is characterised by design decisions as well as managerial decisions aimed at planning and managing the activities and coordinating the work group. The design decisions involve a detailed definition of the product and the components, the careful dimensioning of the shapes, and the definition of the tolerances. The materials are chosen, and the possible production processes and test modalities are defined. Such decisions must result in the definition of the processes and the production systems in detail. The important parameters for each production operation, the technologies and the equipment that must be used, the process layout and the logistic system are consequently fixed. The decisions of a managerial nature are made with respect to the cost analysis of the product in consideration of the previewed budget. Possible planning reviews and risk analysis must be taken into account. The elements of uncertainty of this phase can be associated with the effects of the design decisions in the previous phases and to the design decisions of other design teams (UR). Uncertainties concerning the product and process design (UE) relatively the specifics will be solved in the Testing phase. In this phase the uncertainties (UE, UR) concern the plan and cost adherence that obviously depend on exogenous factors.These uncertainties can partially be solved by monitoring and control activities. Again, in this case, as for phase II, it is possible to associate the Development process with the Detail Design and the Selection process with the selection and choice of solution activities and the monitoring and control of the other activities.

The fourth NPD phase aims at testing the quality of the logistics, production and administrative flows. The decisions are connected to the homologation and certification of the product, to the process start up and to the certification of the entire system (product/process). Testing obviously involves creating a plan of actions that minimizes the cost of the tests, minimizing the remaining product risk, minimizing remaining uncertainties. The elements of uncertainty of this phase concern the product and process (UE) and the decisions made by the certifying authorities (UR). The decision process in this phase is Selection.

The Production Launch phase decisions concern the service associated with the product and the production planning. Customers’ requirements and the market reaction to the launching of the new product are the main uncertainties of this phase (UE). In such a phase, as in the Planning phase, decisions can be influenced by unclear organisational goals (UV) about production plans and competitor and partner decisions (UR) (i.e., concerning the service that has to be associated with the product). Structured actions for understanding market answers to the new product and for benchmarking can help to partially solve some of these uncertainties. Such a phase is again strategic, as the entire product lifecycle will be conditioned by these decisions, and the decision process for unstructured situations is the reference.

Product Review phase decisions concern the definition of the product design changes. Such a phase is extremely strategic because it is the beginning of a new product cycle. It is similar to the first phase of the NPD process and has the same uncertainties and decision processes, but the enormous store of information (the customers’ preferences become requirements for changes in the product), experience and knowledge derived from the past lifecycle distinguishes it from the first one. The evaluation of the product in the whole life cycle defines the indispensable exploratory option for the solution of such uncertainties in a situation that is partially structured. Again, the decision process for unstructured situations is the reference.

5 HA application STEP3: identification of decision-aiding processes

Once the decision processes are individuated, the problematic situation is clearer. Only at this moment can the analyst define which support activities can be performed to solve the problem situation.

Decision-aiding processes can then be defined in the third step of HA. The Decision-Aiding Map (Norese and Ostanello 1988) is used in the literature on Decision-Aiding to identify typologies of the decision-aiding processes and is here used for the phase-by-phase application of HA to NPD. This map links different activities/procedures to the main Contexts of Action. The CoAs constitute the sub-processes of the main analyst’s work process. The aim of these technical actions may be reached or not reached. If the aim is not reached, other technical actions are needed. The Decision-Aiding Map can help trace the sequence of these CoAs while the analyst moves from one context to another.

The map is divided into four quadrants that represent the four different typological operative situations in which the analyst can work. He can work inside the organisation or not, alone or with the problem owner. The analyst can work alone, in or outside the organization. If he works alone in the organization, he works by using the company information system. The “problem owner” can be easily identified by a single person or by more actors within the organisation. The presence or not of the problem owner define the political-organizational dimension. In this way, four situations, as shown in Fig. 6, result. By moving from one CoA to another, the analyst often moves from one quadrant to another. The path covered by the analyst is the profile that develops in the quadrants of the map. For instance, Fig. 6 shows the analyst that works alone, performing structuring, and control activities in a Structuring CoA. This can happen when analyst works on previously collected information. After that in order to verify the validity of his work he passes to a Control CoA. This validation needs a control activity but might also need the identification of new (previously missing) informative elements from the organization information system.

Fig. 6

The Decision-Aiding Map

The flow chart representation proposed by the HA framework uses the same process descriptions of this map. They are two different representations of the same thing. The only difference is that this second representation is more synthetic and visual, while the HA is more descriptive and detailed. Moreover, the HA representation enables easier identification of the three typological processes (Formalisation and Choice of Known Solutions, Multidimensional Problem Solving, Decision Problem Structuring, as shown in Fig. 3). Therefore, given a decision-aiding process, with the HA description, it is easier to identify to which typology it corresponds. The different CoAs and the decision-aiding processes, in support of the decision processes of the NPD process, are summarised in Table 4 together with their specific application domain.

Table 4 The contexts of action and decision-aiding processes of the NPD process

In the first NPD phase, identifiable CoAs are related to a decision-aiding process that aids the entire Mintzberg decision process for unstructured situations. All the possible CoAs (Id, Str, Ctr, Dv, Com) can thus be identified. In particular, the Identification context (Id) is aimed at recognising customers’ points of view and preferences, new technology possibilities and law references in order to partially solve the uncertainties that constrain the firm’s decisions in this phase. The Structuring context (Str) is aimed at defining each aspect of the decision problem, clearing confusing elements for the firm and structuring informative elements that are useful to define an operative model (i.e., customers’ points of view and preferences must be structured to define a focus). The Development context (Dv) can support the generation of ideas, and the Control Context (Ctr) is useful to verify, evaluate and validate any element that results from the development of the decision-aiding process (i.e., results that are partial or final, definitive or temporary, etc.). The Communication context (Com) is activated together with the problem owner, with the decision and organisational structure and with the informative sources. The presence of the Identification context (Id) determines that the decision-aiding typology for the first phase is “Decision Problem Structuring”.

If the decision process in the Concept Design phase is characterised by Development and Selection, the contexts of actions must aid these decision processes. The Structuring context (Str) of informative elements and problem dimensions and the Development context (Dv) used to define a model in order to test and evaluate primitive ideas are useful for the definition of the product features (as per specifications), the alternative solution development and the final concept evaluation. The Control contexts (Ctr) have similar objectives as those of the first phase, while the Communication context (Com), activated together with the design team, is aimed at supporting interactions among designers and the knowledge modelling activities to manage interactions. In this phase, two different decision-aiding processes can be individuated, Multidimensional Problem Solving, Formalisation and Choice of Known Solutions. In the concept definition phase, in fact, designers are able to formulate the problem, but the possible solution alternatives are not available or are partial and have to be developed. The Choice process can aid the concept selection or the test phases.

As in the second phase, and for the same reasons, the main CoAs in the third phase are Development and Control. The Dv context aids Detailed Design and the engineering activities of the product, components and assemblies. It also aids process definition and project resource planning. The third phase is characterised by the need to overcome differences between the perspectives and the points of view in the NPD teams. The different knowledge domains and the operators have to be integrated in a coordinated and collaborative environment. This matter defines one dimension of the problem and the prevailing importance of the communication context in the Multidimensional Problem solving process. The process of the Formalisation and Choice of known solutions is motivated by the presence of the design decision, which has to be aided.

The decision process in the Testing phase can be modelled by the Formalisation and Choice of known solutions. In this case, a higher structuring level of the problem is present, and the product and process characteristics set should be individuated. The Development and Control contexts are the main CoA needed to define the testing and evaluation model.

The Production phase is again strategic and, for this reason, technical actions are needed in this phase in order to identify and structure (Id, Str) informative elements concerning market response to the new product (pilot line) and to define a model (Dv) for the choice of different production plans. The control context (Ctr) has similar aims, as the other phases and the communication context (Com) can be activated to aid the individual decisions of the problem owner or multiple decisions with the actors in the supply chain. The Decision-aiding process used is Decision Problem Structuring.

The Product Review phase is extremely strategic, but a large store of information, experience and knowledge derived from the previous analysed lifecycle (i.e., customer preferences become product modification requirements), is present. As the identification context of the Decision Problem Structuring process is not needed, a Multidimensional Problem-solving process is sufficient to aid this strategic decision process.

6 HA application STEP4: integration of the different tools from different knowledge domains

With the described mechanism, each HA application allows the comprehension of decision processes and the identification of the supporting activities or processes—the CoAs—needed in the work. The CoAs, focusing on specific objectives, call for different support tools that are available in different fields. In this way, the HA application constitutes the framework for the integration of tools from different perspectives.

Engineering Design, Product Lifecycle Management (PLM) and Knowledge Management (KM) fields obviously provide NPD-oriented perspectives and offer tools to support NPD activities. The integration of these tools with those provided by Management Science/Operation Research and Decision-Aiding domains, as recalled, step by step, by the different CoAs, defines further analytical opportunities and support.

The technology challenges can be dealt with using tools and systems proposed by Engineering Design, Product Lifecycle Management and Knowledge Management fields, while organisational problems can be faced with tools and methods proposed by the Knowledge Management (again), Operation Research, or Decision-Aiding fields.

The literature on Knowledge Management in design examines how knowledge can be integrated into complex technology and product development settings (Baxter et al. 2007) to define possible new product architectures. The literature on knowledge reuse studies how the development of innovative solutions can be facilitated (Baxter et al. 2007; Majchrzak et al. 2004) through past experiences. It examines how a firm’s current knowledge enables not only more effective design and development but also more effective strategic management of design and development (Schilling 2005; Nonaka and Takeuchi 1995). It emphasises the need for new competences to flexibly coordinate firm networks in continuous processes of NPD (Sanchez 1996). KM tools support explicit knowledge management or implicit/tacit knowledge management. The first ones (Knowledge Based Systems, Knowledge Management System, etc.) sustain explicit knowledge representation in specific “knowledge domains” and its analysis or use. The second kind of tools [e.g., boundary objects (Boland and Tenkasi 1995; Subrahmanian et al. 2003) or knowledge connection models (Popovic 2004)], support individuals in their “knowledge activities” and allow the codification of tacit knowledge in explicit knowledge.

The tools of the MS/OR and Decision-Aiding domains can be usefully used in NPD contexts and, as an infrastructure, act as a bridge between information, knowledge and decisions. Some tools can be used to identify the nature of the problem, the operational or decision context and the possible operative approaches. Methods for the identification of data structures (statistical/mathematical methods), models for the identification of the elements of the system (continuous and discrete simulation models), and tools for the identification of actor’s action spaces and roles are present. Some problem structuring methods (see, for instance, the most famous, which are proposed in Rosenhead 1989) can structure the elements of complexity of the problem, while others can structure the elements of the process (e.g., SADT/IDEF). Tools for solution development (mathematical programming methods, heuristics, etc.) or for the development of common solutions in groups (e.g., Structured Group Management techniques such as DELPHI, the Nominal Group Technique, Social Judgement Analysis) are also present in the MS/OR domains. Evaluation tools (cost/benefit analysis, Analytic Hierarchy Process, Outranking Methods, etc.) or techniques for the control of acquired or elaborated information (qualitative or quantitative validation) can support the management aspects of NPD processes.

Table 5 proposes a synthesis scheme. Phase-by-phase decision-making processes, CoAs, and their domain and decision-aiding processes are described. This scheme presents a view of different perspectives that can be integrated in NPD processes with the HA logic. Each tool has been inserted, CoA by CoA, in relation to operative objectives, features and integration possibilities. This logic allows one tool to be inserted into more than one CoA if more use possibilities are legitimated. Similarly, they can be collocated in different perspectives if they can be considered intermediate between two disciplines (e.g., developed by one and usually used by the other).

Table 5 Tools and methodologies from different perspectives in the HA framework for the NPD process (the list that corresponds to the numbers in the table can be found in the Appendix)

The list of tools or families of tools that correspond to the numbers in Table 5 is in the Appendix. The aim is not the definition of an exhaustive list of tools but rather the identification of tools (or families of tools) and methods that can be considered more combinative in respect to their operative objectives and characteristics. The tools and methods can belong to very different fields. In some cases, they derive from the Engineering Design, while in other cases, the application of other domains’ methods or tools to NPD processes is usual and accepted, and in some other cases, the tool application is proposed by a particular contribution. In the first two cases, there is no reference near the tool/method name; in the last case, the authors of the tool/method or the application to NPD processes are reported. When the family of tools is extremely large (e.g., Real Options Valuation (ROV) methods or Graph Theory Diagrams), the reference is omitted. When the tool/method application is a proposal, or very few applications are present in the literature, it is underlined.

7 HA in practice

This approach has been applied in a complete way in some situations. The common element in these occasions was addressing inter-disciplinary problems with multiple, heterogeneous, distributed systems that are embedded in networks at multiple levels and multiple domains.

In Montagna and Norese (2008), the HA was applied in a firm that designs and produces electronic transducers. In this case, the need was a formal control mechanism for the firm product development process. The need of a control mechanism was born in order to support those decisions that were closely connected to the NPD strategic scope. Analysis of the NPD process (in order to develop the required control mechanism) resulted in many people involved, from different organizational areas, and some uncertainties pertaining to guiding values (UV). In that case, very simple tools were enough to solve the present uncertainties; interviews and the IDEF0 method were used in Id, Str and Dev CoA, then integrated with the more usual Management Accounting tools.

A similar problem was faced in Montagna and Vittone (2008) in a Franco-Italian company operating in the aerospace industry. Again the project for a control mechanism in support of the NPD process was under way for process improvement and for the management of collaboration among the multiple participants. The application of tools from MS/OR, in that case, was for the comprehension (Id and Str. CoAs) of the communication and decisional mechanisms.

Norese and Montagna (2008) described an intervention in a collective project, challenging the possibility of producing an innovative hydrogen fuelled light aircraft. The NPD process was in a Concept phase and the main technical decisions were on the product architecture. There, the critical points individuated by the NPD team were the uncertainties related to the consequences of making or buying decisions, in terms of time, cost and risk. Moreover they denounced that information were not shared and often not present in the context in which the project developed. The authors were invited to participate in order to analyze the uncertainties; facilitate communication, coordination and decision-making (i.e., support project management). In that case, decision-aiding tools were used to face uncertainties and complexities of these multi-actor decision processes. In particular MACRAME was used in Dev and Ctr CoAs; and then integrated with Microsoft Project. That was made in order to elaborate and represent alternative solutions, to collectively evaluate and choose, as well as creating a communication space for the project.

Norese et al. (2007) describes the approach applied once more in a company operating in the aerospace industry. In that case, the product was complex and again different engineering disciplines were involved. Multidisciplinary interaction and design coordination were difficult. The complexity of the product and of the associated mission (even though the problem was formulated in a simplified form and limited to few sub-systems) made it practically impossible to tackle the whole engineering problem as a Mathematical-programming problem (in particular only with the Multidisciplinary Optimisation). The Strategic Choice Approach was applied there with its SW STRAD, in Str and Dev CoAs in order to face with the problem structuring needs, and an ELECTRE method in a Dev CoA for choosing the sixteen alternatives individuated.

8 Summary and conclusions

In general, the HA can be applied to different problematic situations that need diverse technical aid.

This work is based on the conviction that knowledge of products and processes can be managed and used by Knowledge Management, Operation Research/Management Science tools to mitigate many NPD problems. It aims to emphasise information management activities in Engineering Design, but it also intends to highlight the need for approaches investigating the decision context of design and the variety of decision-making processes in engineering design situations. The decision perspective proposed in the paper, in fact, can be useful to solve problems incurred in contexts when different actors are involved and where different viewpoints must be taken into account, as in innovation processes (like in Legardeur et al. 2010).

The Hybrid Approach (HA) is the proposal of a new use of tools that sometimes are old and very simple but always focused on a decision perspective. The HA proposed here represents a way of analysing and reasoning in the decision context to effectively integrate different tools to support engineering design activities in an integrated framework, where tools for communication, uncertainty reduction, and decision making are particularly relevant.

In the international research context, the HA does not contrast with the System Engineering perspective, which proposes a better and more complete effort for the initial identification of a problem (system requirements, design goals, etc.) and an appropriate analysis effort to ensure the effectiveness of decision making in the NPD process. The HA is also aligned with those research contributions that propose the integration of different tools and consider the central role of communication and knowledge sharing in engineering design (i.e., the n-dim approach, Reich et al. 1999; shared memory, Konda et al. 1992), but it does not describe a specific tool configuration or a specific DSS. In this sense, the HA is aligned with integrated methods (Hari et al. 2004; Presley et al. 2000) to generate solutions, to promote new original ideas, to integrate solutions, and to find a way to reach a full consensus about the decisions, even though it focuses on the decision context of design and the variety of decision-making processes that comprise uncertainty reduction in engineering design.

Similar to the use of the HA in NPD processes, the HA could be used to identify tools for different industrial situations to address diverse problems. For example, through the use of soft system methodology (Chekland 1981) or other perspectives, the HA can aid the identification of actors and their roles in negotiation mechanisms in addition to the definition of virtual entities such as strategies, and organisational uncertainties. These elements can be very useful in tactical behaviours for firms that, for instance, operate in supply chains or networks of firms. Moreover, the HA could help to identify some other tools, such as STRAD (Friend 1989) or AHP (Saaty 1980), for aiding policy design in terms of the evaluation of market mechanisms and planning strategies, among other tasks.

An accepted drawback of this approach is that the tools have to be logically and operationally compatible, but, in general, cannot be transformed into an automatic and computerised system. The sequence of the activities is often non-linear, as several cycles might be necessary, and a logical synthesis of the activities that the tools enable is closely related to the specific context of action and decision. Reasoning about a problem context is essential for the choice and correct use of tools and their intelligent integration. The relationships between decision and operative contexts have to be analysed in relation to different decision support situations and integrated into the general framework. The automatic treatment of this element is not simple and could make the decision support poor.

Future research steps consist of further validation of the methodology. This work could result in the completion of Table 5 with the identification of further tools (from different perspectives) for each context. Then, not all the perspectives present tools for each CoA. The search for new tools and methodologies that can fill these gaps could represent a future step in this work. Finally, the idea of using the HA as explanatory tool to study why some projects break down, could indicate future application domains.

Appendix: list of tools (or families of tools) proposed in Table 5

• 1. Real Options Valuation (ROV) methods

• 2. Portfolio Management methods (Cooper et al. 2001)

• 3. “Score card” Method (Cooper et al. 2001)

• 4. “Roadmap” Method (Hunt et al. 2004)

• 5. Strategic choice Approach (STRAD) (Friend 1989)

• 6. Focus Group Methods (Kontio et al. 2004)

• 7. Experiential Interviews Techniques (Griffin and Hauser 1996)

• 8. Kano Model (Clausing 1994)

• 9. Empathic Design Methods (Dahan and Hauser 2001)

• 10. Contextual Inquiry Techniques (Holtzblatt and Beyer 1993)

• 11. Metaphor Elicitation Technique (ZMET) (Zaltman 1997)

• 12. Kansei Analysis Method (Dahan and Hauser 2001)

• 13. The Mind of the Market (Dahan and Hauser 2001)

• 14. “Means-End Chain” (Gutman 1982) or “Value-Systems” (Rokeach 1973) Methods (Dahan and Hauser 2001)

• 15. Affinity Diagrams or K-J Analysis Methods (Mizuno 1988)

• 16. Customer-based Needs-Grouping Methods (Griffin and Hauser 1993)

• 17. Web-based Methods (Dahan and Hauser 2001)

• 18. Soft System Methodology (SSM) (Chekland 1981) (Presley et al. 2000)

• 19. Analytic Hierarchy Process (Saaty 1980) (Thomas 1993; Presley et al. 2000)

• 20. Quality Function Deployment (QFD) Method

• 21. Function Analysis System Technique (FAST) Diagrams

• 22. Brainstorming (Dahan and Hauser 2001)

• 23. Morphological Analysis Technique (Dahan and Hauser 2001)

• 24. Group Sessions Method (Dahan and Hauser 2001)

• 25. Forced Relationships Method (Dahan and Hauser 2001)

• 26. Six Hats Method (Dahan and Hauser 2001)

• 27. Inventive Templates Technique (Goldenberg et al. 1999a, b)

• 28. Lead users Method (Von Hippel 1986)

• 29. Set-based Design Method (Ward et al. 1995)

• 30. Subjective objective system (Ziv-Av and Reich 2005)

• 31. Synthesis by morphology (Hari et al. 2004)

• 32. Controlled Convergence Method (Pugh 1990)

• 33. Value Engineering method

• 34. 33b. Conjoint Analysis and Web-based Conjoint Analysis Methods (Dahan and Hauser 2001)

• 35. Cost-benefit Analysis Method

• 36. Multi Criteria Decision Analysis methods (e.g., ELECTRE methods (Roy 1996)

• 37. Freehand drawings

• 38. Computer Aided Design (CAD) systems

• 39. Computer Aided Manufacturing (CAM) systems

• 40. Computer Aided Engineering (CAE) systems

• 41. Structured Analysis and Design Technique (SADT)

• 42. Simulation and Combinatorial Methods (Loch et al. 2001)

• 43. Virtual Prototyping Models

• 44. Rapid Prototyping Methods and tools

• 45. Assembly Modelling Techniques

• 46. Multi-objective Optimization Methods

• 47. Collaborative Optimization Methods (CO) (Norese et al. 2007)

• 48. Group technology Approaches

• 49. Graph theory Diagrams

• 50. Virtual Manufacturing Techniques

• 51. Rapid Manufacturing Methods and tools

• 52. Computer-aided Production Engineering (CAPE) or Computer Aided Production Planning (CAPP) systems

• 53. Structured Group Management techniques (Thomas 1993)

• 54. Gantt Charts

• 55. Critical Path Diagrams and PERT Diagrams

• 56. Action Plans or Time tables

• 57. Projects IN Controlled Environments (PRINCE2) Methodology (Rashid and Ismail 2007)

• 58. Activity Based Management (ABM) or Activity Based Costing (ABC) Methods

• 59. Risk Management Methods and techniques

• 60. Failure Modes and Effects Analysis (FMEA) methodology

• 61. EDM (Engineering Data Management), PDM (Product Data Management), PIM (Product Information Management), TDM (Technical Data Management), eBOP (Electronic Bill of Processes) systems

• 62. Tools or systems for visualisation without file format changes (i.e., JT)

• 63. Tools or systems for data exchange with different formats (i.e., Intermediate data exchange formats)

• 64. Tools or systems for data exchange with meta-formats

• 65. MS COM/DCOM, CORBA e J2EE technologies

• 66. IGES, VDA-FS, STEP-ISO 10303 etc.

• 67. Open Standard, Open Source and Peer to Peer communications tools

• 68. Design Structure Matrix

• 69. Cooperative Distributed Problem Solving Methods (Durfee et al. 1989)

• 70. Agent-based Approaches (Madhusudan 2005)

• 71. Collaborative Knowledge Management Systems (Tiwana and Ramesh 2001)

• 72. Shared Mental Models (Cannon-Bowers et al. 1993)

• 73. Boundary objects (Boland and Tenkasi 1995)

• 74. Product Range Models (Costa and Young 2001)

• 75. Knowledge Connection Models (Popovic 2004)

• 76. Mintzberg Model (Mintzberg et al. 1976)

• 77. Trial/Repeat Analysis Method (Dahan and Hauser 2001)

• 78. Recursive Analysis Method (Dahan and Hauser 2001)

• 79. Econometric methods (Pringle et al. 1982)

• 80. Pre-Test-Market Models (Urban and Katz 1983)

• 81. Preference Distribution Models (Hauser and Shugan 1983)

• 82. PZB Model (Parasuraman et al. 1985)

• 83. SERVQUAL Model (Parasuraman et al. 1988)

• 84. Two Way Model (Schvaneveldt et al. 1991)

• 85. Lot sizing algorithms and techniques

• 86. Dynamic Lot sizing algorithms and techniques

• 87. Statistical Inventory Models

• 88. Multi-period Models

• 89. Aggregate Production Planning

• 90. Heuristic algorithms and techniques

• 91. MRP systems

• 92. MRPII systems

• 93. ERP systems

• 94. Integrated Management Systems (IMS)

• 95. JIT techniques (e.g., Kanban techniques)

• 96. Scheduling Algorithms