The current issue and full text archive of this journal is available at www.emeraldinsight.com/0265-671X.

htm

Failure mode and effects analysis (FMEA) in the context of risk management in new product development
A case study in an automotive company
Andre Segismundo and Paulo Augusto Cauchick Miguel
Department of Production Engineering, Polytechnic School of the University of Sao Paulo USP, Sao Paulo, Brazil
Abstract
Purpose Effectively managing risk is an essential element of successful project management. In this sense, the present study seeks to propose a systematisation of technical risk management through the use of FMEA to optimise the decision making process in new product development (NPD). Design/methodology/approach The methodological approach adopted in this paper is a case study at an automaker in Brazil. Data were gathered from various sources, mostly participant observation and document analysis of two important NPD programmes. The risk management system was described and its inuence on programs development analysed. Findings Results included a reduction in the number of project and test planning loopings as well as a reduced number of prototypes needed to approve product components. In addition, there was a positive inuence on the product development decision-making process, evidenced by better allocation of resources among projects at the programme. Research limitations/implications The study is limited to a single case study which considers two major NPD programmes. Replications among other units of analysis are needed to further validate current ndings. Originality/value This paper is one of the few published studies that report and discuss the FMEA within a broad context of risk analysis. Keywords Failure modes and effects analysis, Decision making, New products, Risk management, Automotive industry, Brazil Paper type Case study

FMEA in the context of risk management 899

Received 3 October 2007 Revised April 2008 Accepted June 2008

1. Introduction In times of increasing global competition, the success of projects becomes more decisive to an organizations business performance. However, many projects still present delays, changes in their scope, failures and, some might be cancelled (Shenhar, 2001). As a general rule, those problems may occur due to inefcient management of project risk. Managing risk has become fundamental to successful project management
The authors acknowledge the cooperation of the company where the study was conducted. Nevertheless, this paper reects only the view of the authors, not the ofcial view of the company. The authors also wish to express their gratitude to the referees who did contribute to the improvement of this article as well as to Ms Ann Puntch for English revision.
International Journal of Quality & Reliability Management Vol. 25 No. 9, 2008 pp. 899-912 q Emerald Group Publishing Limited 0265-671X DOI 10.1108/02656710810908061

IJQRM 25,9

900

(Carbone and Tippett, 2004), however, techniques and tools for risk management that have been developed and used to increase the chances of project success are not yet widespread or generally applied (Kumar, 2002). Project risks may be dened as undesired events that can range from delay, excessive expenditures, and unsatisfactory project results for the organization, society, or environment (Shenhar et al., 2002). According to project management body of knowledge (PMBOK) (PMI, 2004) a project risk is an event or uncertain condition that, if it occurs, produces positive or negative effects on at least one aspect of the project, such as cost, scope, quality, and so on. A risk may have more than one cause, and if so, it may have an impact on more than one dimension of a project. Risks can be identied and grouped into categories (Hillson, 2001), which reect common sources of risk to the project, such as the following (PMI, 2004): technical risks, project management risks, organizational risks, and external risks. Technical risks, which are the focus of the present work, include those that originate in the use of unproven or complex technology or that unrealistic development goals will not be reached. Moreover, they could result from changes in technology during project development. The project management risk category includes risks derived from inappropriate allocation of resources and unrealistic estimates due to poor quality of the project plan. Organizational risks include poor project objectives (with regard to cost, scope, etc.), a lack of prioritisation, or interrupted or misallocated nancial resources. Finally, external risks are those which occur due to changes to the legislation, changes in market trends, working troubles and alterations in the priorities of project sponsors (Carvalho and Rabechini, 2005). These denitions of project risk can be considered reasonably clear and concise, although technical risks of a system or part of it are usually well known and there is a wide base of information about its manners of failure (Pate-Cornell, 2002). However, risk management is in its infancy and more efforts are necessary in application, training, development of tools and research on this subject. Shenhar (2001) adds that project management and risk management methodologies cannot be standardised for all kinds of projects, but must be adapted to the nature of the goals and uncertainties of each project. Some studies suggest models (frameworks) specic to managing risks in information technology projects (Kumar, 2002), in the distribution of electric energy (Perobelli, 2004), and in identifying technical risks in the development of new products (Kaplan et al., 2001; Carbone and Tippett, 2004). These are generally based on concepts of qualitative risks analysis generated by the utilisation of failure mode and effects analysis (FMEA). FMEA is one of the most widespread methods used in NPD to aid in determining priorities for technical risks in the management process by identifying project weak points, and as a consequence, optimising the use of NPD resources, mostly during the testing phase (Pate-Cornell, 2002; Maddoxx, 2005). There are several publications that deal with FMEA. Kumar (2002) proposes a framework for managing risks based on research in nance of the real options theory in comparison with the FMEA, while Carbone and Tippett (2004) propose an extension of the traditional FMEA, where the risk priority number (RPN) is modied slightly for use in the environment. Kaplan et al. (2001) develops a proposal based on the concept of FMEA, hazard and operations analysis and event and fault trees. The author suggests a renement to the set of triplets denition, which removes the specic set of scenarios,

found by any of the theory of scenario structuring (TSS) methods, from the denition of risk and casts it, instead, as an approximation to the true set of scenarios that is native to the problem at hand and not affected by the TSS method used. Planning and managing new product development (NPD) projects, or a portfolio of projects can be classied as a complex decision-making process. This classication includes non-structured problems or can vary from a medium to high degree of uncertainty and complexity. However, the criteria for decision-making are not xed a priori (Shimizu, 2006). Hence, it is very important to consider risk management as a support for the decision-making process. To make the right decisions, it is necessary to pay attention to the particularities of each organization, such as its degree of risk acceptance and its corporative standards for risk management. It is in this context that this paper analyzes the role of FMEA in the process of risk management in decision-making during the NPD process in an automotive company. More specically, it aims to systematise and utilise technical risks through the use of the FMEA tool to optimise the decision-making process in NPD. Other specic issues that motivate this study are: . To get a more detailed and individual analysis of each possible mode of failure. This analysis would make it possible to obtain the weight (relevance) of each failure mode as well as provide a deeper understanding of the required corrective actions. . To start the identication of risks during the conceptual phase, thus facilitating taking more effective actions to minimise the impact of failures on the project as early as possible. . To permit risk analysis to be applied to a whole vehicle, and not just to its sub-systems and components, by considering the risk value both to the internal customer (project manager) and to the external customer (users). To achieve the papers objectives and explain its motivations, the text is structured as follows. Section 2 discusses concepts of risk analysis and FMEA, while section 3 presents the research methods used in this work. Sections 4 and 5 show, respectively, the concept of technical risks with FMEA, the process of decision-making, and the rst results from the company studied. Section 6 shows other relevant results and the conclusions are presented in section 7, followed by the references. 2. Theory of risks analysis and FMEA FMEA is one of the most used techniques in project engineering risk analysis to identify possible modes of failure and to predict their effects and relevance (Maddoxx, 2005). It allows potential product problems to be identied before they reach the nal customer (Puente et al., 2002). The previous authors add that the effects of failures on the complete system can be studied and effective control decisions can be taken with respect to either the product (design FMEA or DFMEA) or the process (process FMEA or PFMEA). When applying FMEA, each component is examined to identify possible failures. Three measures are considered (Maddoxx, 2005): the probability of failure occurrence (O), the impact or severity of the failure (S ), and the capacity to detect failure before it occurs (D). The multiplication of these measures generates the RPN.

FMEA in the context of risk management 901

IJQRM 25,9

902

Although FMEA prioritises more critical failures, it also requires an analysis of each component of a system and this might be time consuming for the available resources (Trammell et al., 2004). Moreover, other criticisms of FMEA are (Puente et al., 2002): . risk evaluation using RPN cannot always be assessed by detection (D); . there is no exact rule to determine the probability of occurrence (O) and detection (D ); . calculation of the RPN based on the three measures may also be distorted. While the probability of non detection and its respective scores follow a linear function, the relationship between the probability of failure occurrence and its score is not necessary linear; . different scores for O and D can result in the same RPN, despite the risks involved being completely different; and . the RPN is not an effective measure of proposals for improvements. Another criticism of FMEA is that it is necessary to manage risks associated with failures more broadly, such as possible delays in the project life cycle, changes to the scope and budget, and so on. These are not considered within the FMEA context (Segismundo and Cauchick Miguel, 2006). FMEA itself does not represent a method for risk management and its analysis should be integrated into the impacts on price, goals, costs, etc. (Trammell et al., 2004). Additionally, one of the biggest risks that occur in projects currently using FMEA is when the team nishes working on a certain phase of the project and immediately moves on to the next (Pollock, 2005), usually delegating responsibility for implementing improvement actions to the quality management group. A few authors have recently developed proposals with a more integrated vision of technical risk management and its impact (e.g. Puente et al., 2002; Trammell et al., 2004; Carbone and Tippett, 2004 to name but a few. Trammell et al. (2004) propose an integrated hybrid model that uses the strengths of hazard and operability analysis (HazOp) and FMEA to identify failure modes and priority rank risks, and layers of protection analysis to evaluate and apply effective controls. The authors claim that this may bring many advantages, such as better identication of customer specications, reduction of costs for launching new products (e.g. re-design and modications are avoided and many tests can be eliminated), increased product and process quality and reliability, leading to more safety and responsibility in the manufacturing process, as well as increased customer satisfaction. Their model is based on a process of risk management that identies the system priorities relevant to the analysis, and does a follow up of RPN over time as a function of risk tolerance by the decision maker. Puente et al. (2002) propose the adoption of a decision support system based on FMEA, which permits prioritisation of actions not only as a function of RPN, but also using a scale of priorities dened by the decision maker. The main contribution of those authors is the division of the RPN into nine intervals that supports decision-making concerning risk criticality. Carbone and Tippett (2004) propose a sort of extension of conventional FMEA which considers the cost and price dimensions involved in the project in order to adapt the conventional FMEA technique to a project approach. The main common issue of those studies is the extension of the FMEA as an

adaptation to a new or wider environment of application, or improving its outputs to optimise the information for decision-making. In this sense, it is believed that a more integrated vision of the risk management process, as well its sub-processes, is an issue fundamental to project success, as earlier identied by Shenhar et al. (2002) and Carbone and Tippett (2004). The most recent version of the PMBOK (PMI, 2004) states that the project risk management process involves identication, analysis, response, monitoring, control and planning of risk management. The objectives of risk management are to increase the probability and the impact of positive events and to reduce negative events in the project (PMI, 2004). Therefore, it considers the allocation of engineering resources and decision-making in project development (Pate-Cornell, 2002). Carbone and Tippett (2004), however, argue that many authors in the area of risk management and even the PMBOK make some mistakes when they dene certain aspects of risk management. For example, in the discussion about tools and techniques for qualitative risk analysis, the PMBOK (PMI, 2004) misunderstands the terms impact and consequences of risk, where the impact is dened as the effect on project objectives if the risk event occurs (PMI, 2004). The RPN can also be dened as Risk Score (PMI, 2004) or Severity of Risks (Graves, 2000), which can easily be confused with the concept of the severity index (S) used to estimate risk in FMEA analysis. These arguments show that there are opportunities for further studies on FMEA within the context of broader risk management. Having presented some concepts related to risk management and FMEA, the attention is turned to the methodological issues of this work, followed by their results and discussion. 3. Research methods This work uses case-based research as its methodological approach, following the guidelines in the literature (Yin, 1994; Voss et al., 2002). The rationale is due various aspects of the research such as the importance of the context (i.e. within the NPD process), the nature of variables (predominantly qualitative in nature), and the approach to data collection and analysis. The company was selected by one of the authors, based on its history in developing new products, the current importance of risk management in NPD, and accessibility of data. Data was obtained mostly through document analysis (secondary data) for the NPD projects for the past 4 years. An important company strategic programme (called the Alpha Programme) was carried out in this period; Alpha programme preceded the current Beta Program. Therefore, secondary data from Alpha Program were selected and collected with regard to its importance to the NPD process. These included technical reports, schedules, and bench and vehicle test reports. In addition, the rst set of data available for the Beta Program was also used (it is worth mentioning that this programme is still in an initial phase in the product life cycle). Other available variables were used as well including the number of prototypes, the number of iterations (or loopings) in the project and tests plans, and the number of failures during the Alpha Program warranty period. Primary data were also considered in the study. A few non-structured interviews with professionals involved with NPD were also conducted (at the operational and managerial levels). It is important to mention that one of authors worked at the company, acting as a participant observer.

FMEA in the context of risk management 903

IJQRM 25,9

904

The company is part of a large international automotive organization, which produces trucks and cars. The main business units for NPD, located in Brazil, include those for truck development, bus development and the development of components for the markets of Brazil, Latin America, South Africa and the Middle East. Typical company NPDs include both platform (normally a solution that represents a product family, with a high degree of innovation) and derivative projects (i.e. adaptations of existing products, normally with a low degree of innovation). This typology is in accordance of literature (e.g. Clark and Wheelwright, 1993). During recent years, the company has consolidated the implementation of a local technology centre for developing new products. This enables the automaker to design and launch truck and bus platforms as well as components (engines, spindles, and components for a number of industrial applications). The technology centre employs over 500 people. The product development process was created at its headquarters and is based on ten stages and gates. It uses a framework similar to Coopers stage-gates (Cooper, 1993) but requirements for advanced product quality planning (APQP) are also considered. The gate decision meetings are based on a number of criteria in a document called the delivery fullment list. This document considers costs, quality and performance objectives including risk analysis. The company has been using FMEA in new product projects since 1989.Risk management has been used since 2005 with the Beta Program as pilot. Project management is based on concepts and areas of knowledge proposed by the PMBOK (PMI, 2004) and the companys NPD rates a maturity level 2 (basic) on the project management maturity scale proposed by the PMMM Project Management Maturity Model (Carvalho and Segismundo, 2006). 4. Technical risk management using FMEA The company adopted the concept shown in Figure 1 to its more recent (Beta) strategic program. Basically, a general structural design failure mode and effects analysis (DFMEA) was developed considering a generic vehicle. This structural DFMEA, called the Master DFMEA, has the following levels of detail: vehicle level, systems level (i.e. cabin, chassis, motor, etc.) and the subsystems level (i.e. cab-in-white, cab internal features, external design, frame rail, cross-members, tanks, etc.). For each system, the primary function and rst and secondary possible failure modes are detailed. It also employees special features related to safety and the legislation that are important

Figure 1. Master DFMEA and its correlation with specic projects

for a vehicle. Each new project has to refer to the Master DFMEA in order to decide which specic DFMEAs make sense to be developed. For example, when the scope of project A is known, the Master DFMEA is checked to decide which and how many DFMEAs are necessary for the new project, and this serves as a reference data basis for each NPD project. Principal characteristics and advantages of integrated risk management based on DFMEA are (Maddoxx, 2005): . the automatic generation of a list of all special characteristics related to safety; . a solid data base to assist in making decisions about which, and how many, systems and sub systems of a project need DFMEAs; and . an opportunity for an integrated vision of the new project (from the initial phases) to guide the allocation of effort and resources. The company realised the need to integrate these concepts to dene which DFMEAs would be necessary for a specic project and to monitor risks during project progress. A macro diagram of the integrated management of technical risks for a specic project n in NPD is shown in Figure 2. The main inputs (upper part of the diagram in Figure 2) are the experience of engineers and data from validation tests and eld failures (warranty) of similar products which have already been launched. To perform the DFMEA, these three inputs are structured using a check-list to quantify the values for failure probability (O), impact (or severity) on the customer (S ), and the capacity of the testing mechanisms and simulations to detect a possible failure (D). Other important inputs are the system or parts reliability goals (normally described in a technical specication handbook) and the possible failure modes already documented in the Master DFMEA. The main outputs are the continuous updating of the Master DFMEA itself (based on the experience gained from project n), specic DFMEAs generated for the project n, and test planning as a consolidation of all actions planned for the project n DFMEAs. Later on, at the testing phase, follow-up management reports about risks during the

FMEA in the context of risk management 905

Figure 2. Risk management system macro-diagram

IJQRM 25,9

906

project (comparing predicted and actual risks) are developed. These are also an important output of the risk management system. The macro-diagram shown in Figure 2 can be detailed through a complete data ow represented in Figure 3. After determining which systems, subsystems or components are relevant to the realisation of a DFMEA (Figure 1), the DFMEA is started by determining possible modes and effects of failures and their causes. A group of

Figure 3. Workow of the technical risks management process in the company

engineers determine the values for O, S and D during the DFMEA process, with the help of the check-list document, resulting in a RPN for each cause of failure. The RPN values are divided into three bands: green (acceptable risk, no action needed); yellow (moderate risk, at least one action is needed) and red (high risk, one or more actions are necessary), aimed at minimising one of the criticisms by Puente et al. (2002). To accomplish this, all yellow and red risks have their actions periodically and systematically monitored by PDCA (Plan, Do, Check and Act) cycle until they reach an acceptable level and the system is considered approved for the manufacturing and assembly processes. This monitoring occurs monthly, however this does not mean that the tracking of all types of failures occurs on that time basis. The monthly report works as a vertical cut in time to make it possible to write a managerial report. The risk (RPN) is calculated by (as in a conventional DFMEA): RPNi Oi S i Di 1

FMEA in the context of risk management 907

where RPNi, average RPN of the system, subsystem or component i; Oi, probability of occurrence or possible modes of failure of the system, subsystem or components i; Si, impact or severity noted by the customer in the subsystem or components i, if a preventable failure occurs; Di, detection, or the effectiveness of tests or simulations in detecting a failure. The variables (O, S, and D) are dened by a scoring system that the risk management system attributes to the engineers when they answer the questions on the check-list. The calculation is based on a weighted average of the variables, related to the importance that the system administrator may assign for each action to minimise the risk (e.g. re-design, simulation, bench tests, accelerated vehicle tests and vehicle tests by the client.). For example: . Possible actions to decrease risk through detection (range from: 10 very bad to 0 excellent). . Bench pre-tests (factor n) y n. . Without vehicle tests (factor an) z a n. . Vehicle durability tests (factor bn) w b n. where y, z and w are weights that the system administrator gives to balance each action. Factors n, a n and b n represent the system internal weight for each different action to minimise the risk. The administrator has no access to factors n. The relationship between the factors n is not necessary linear. Therefore: Di y n z an w bn n an bn 2

The calculation of S and O occurs at the same way as D, respecting their respective variables and factors of weight. To calculate the risk to the entire vehicle, a quality inuence factor (QIF) is used. The QIF represents the importance of each system, subsystem and component to the basic truck functionality from the customer point of view (equation (3)). The calculation is made using the weighted average of each system, subsystem and component risk and QIF.

IJQRM 25,9

RPNvehicle RPNsystem i QFIsystem i RPNsystem i1 QFIsystem i1 RPNsystem QFIsystem i QFIsystem i1 QFIsystem n

n

QFIsystem n 3

908

The QIF Factor can be input by the user from the historical information that the master FMEA provides (attributed by the data base administrator). More details can be found in Segismundo and Cauchick Miguel (2006). 5. Findings The company studied has corporate standards for technical risk management during NPD based on the utilisation of FMEA, presented earlier in Section 4. The RPN is presented in three possible categories: the risk can be rated acceptable, between 1 and 64 (in the green zone); medium, between 65 and 343 (in the yellow zone), or high, between 344 and 1,000 (in the red zone). The risk zones are obtained by multiplication of the variables O, S and D. Each factor varies from 1 to 10 and the limits of the zones are 4 (for the green zone) and 7 (for the yellow zone). A function for risk evolution can be associated to each action plan generated by the DFMEA. This can decrease in a linear fashion, starting to fall from the beginning or decrease rapidly only when activities terminate. This represents RPN evolution throughout the duration of the actions. For example, the hours, cycles or distance accumulated by a prototype during its simulation tests, make the risk decrease gradually in a linear function in relation to the planned value. Other kinds of actions cause a reduction in the RPN only after their conclusion, for example, after applying a nite element analysis (FEA). With regard to the possible actions described above, just three possible functions were programmed in order to simplify the system. Figure 4 shows the three kinds of distributions that it is possible to work out for the risk management system. Once all the necessary DFMEAs for a project are done, including their respective action plans for risk reduction, the follow-up phase begins. In this phase of the project, the risk management system can generate risk diagrams and lists, as shown in Figures 5 to 7. Figure 5 shows the risk evolution for a single component (tanks brackets related to the system fuel tank). The risk evolution (planned) is shown by the line that decreases following the arrangement of the three functions shown in Figure 4, according to the different types of planned actions. In other words, the decreasing risk is a combination of many actions during a specic month (bench tests, durability tests

Figure 4. Risk evolution functions for a planned course of positive actions

FMEA in the context of risk management 909

Figure 5. Subsystem risk evolution

Figure 6. Total average risk evolution of a project

and, sometimes, re-design). The addition of the risk decrease of each action allows us to obtain the planned curve. The target is to reach the green zone (between 0 and 64 in Figure 5). The bars represent the real risk evolution at the end of each month (month i ). The light grey bars means that the risk has developed as planned, and the dark grey bars means that the risk has not reached the target for the month i. In the latter case, the problem should be analysed and a new plan must be discussed and implemented. Figure 6 shows the total average risk of project n for a single subsystem, similarly to Figure 5. In this case, the project n represents the Beta Program, where the RPN is calculated using the average risk of each system, subsystem and components multiplied by the QIF (section 4). The gure demonstrates that the Beta Program has a plan that considers a risk reduction between 230 and 130, which is not sufcient to

IJQRM 25,9

910

Figure 7. Evolution of the number of components per risk zone

achieve the risk green zone for this component. The plan mentioned above can be represented by the combination of the planned actions and the necessary resources allocation, for example, planning bench tests and vehicle tests in parallel to accelerate tests results, or just to re-design the component. This kind of information can aid the decision-making process, where top management could either accept the risk or, for example, reallocate resources from other, lower-risk projects in order to achieve a better situation for the Beta Program. Figure 7 shows the total number of systems, subsystems and components for each risk zone (green, yellow and red) and the evolution over eight months. For the Beta Program, for example, of a total of 45 systems and subsystems, 8 were in the red zone, 27 in the yellow zone and 10 in the green zone in April. If all action plans occur as planned, by October only two components will remain in the red zone. Thus, different follow-ups give the managerial NPD team an overview of the progress of the projects technical risks. Hence, it is possible to take faster and more effective decisions related to human, economic and physical resources allocation, using such techniques as bench tests, facilities optimisation, equipment measurements, etc. as suggested by Trammell et al. (2004). 6. Other relevant results and next steps Firstly, it can be said that utilising technical risk management based on FMEA is a fundamental part of the product development decision-making process. This is currently well accepted by users (engineers and technicians) and internal customers involved in decision-making (project managers, functional managers, and directors of the product development department). This is evident from its broad utilisation for all new product projects; and the fact that the rst results are being discussed in a weekly forum. The pilot project (Beta Program) is at the beginning of its life cycle and yet it is possible to observe that the use of FMEA-based risk management has optimised the project and tests planning loopings (by about 15 per cent), by focusing on actions to minimise the risk of failures that could result in project delay or lesser quality, for example, increased bench

tests instead of some vehicle tests. By using risk management, planned pre testing resulted in a 35 per cent decrease in the need for vehicle prototypes. With respect to failures during the warranty period of the previous product (Alfa Program), only 24 per cent had a risk analysis process performed during the development phase. This emphasises the importance of risk management and a continuous improvement process in order to optimise the development process. Improved product quality and lower warranty costs are expected to result from this optimization. These are the next steps of this study. In addition, a quantitative analysis of the eld results (in the warranty period) of the pilot program compared to a program that has not used the technical risk management concept is planned. This proposal would give a more consistent basis to validate (or not) the effectiveness of the current proposal. 7. Conclusions First, it may be considered that the present study provides a contribution, with limitations on its ability to be generalised, to the research on risk management. The results indicate that this application of FMEA and the continuous monitoring of its action plans, with an integrated view of risks by NPD senior management, is one of the main supports for decision making during NPD. In this sense, it is possible to conclude that the research has achieved its main proposition, by systematising FMEA in risk analysis, mainly by monitoring how the risks evolve for each project, at a level which collaborates with and optimises the decision-making process. Of course, there is a need for more information to validate this study in the automotive industry. However, more time is needed to obtain more representative eld results from the pilot program (Beta Program), which will be analysed in a future study. The present study makes a potential contribution to the study of risk by analysing the role of FMEA, one of the most widely disseminated techniques for assessing technical risks in the broader context of risk management. Results point to this application as one of the main supports for decision making during NPD. Despite these limitations, the rst results discussed in the previous sections demonstrate a certain advance in improving the decision-making process based on risk analysis. This is illustrated by the comparative evolution between the planned and actual RPN for each system, subsystem and components per risk zone. Moreover, comparing the Alfa and Beta Programs, reductions in development loopings and the number of prototypes were observed in the rst development phases of the Beta Program. This evidence, despite the limitations of the study, shows a possible positive inuence of the risk management concept on the decision-making process during NPD, optimising resource allocation in the Beta Program. Future studies will include a statistical validation of the inuence of technical risk management on the product development decision-making process.
References Carbone, T.A. and Tippett, D.D. (2004), Project risk management using the project risk FMEA, Engineering Management Journal, Vol. 16 No. 4, pp. 28-35. Carvalho, M.M. and Rabechini, R. (2005), Building Skills for Managing Projects: Theory & Cases, Atlas, Sao Paulo (in Portuguese). Carvalho, M.M. and Segismundo, A. (2006), Maturity in project management: comparative analysis of three business units of the automobile industry, Proceedings of the National Conference on Production Engineering, Fortaleza, RN, Brazil (in Portuguese).

FMEA in the context of risk management 911

IJQRM 25,9

912

Clark, K.B. and Wheelwright, S.C. (1993), Managing New Product and Process Development, The Free Press, New York, NY. Cooper, R. (1993), Winning at New Products: Accelerating the Process Form Idea to Launch, Perseus Books, Cambridge. Graves, R. (2000), Qualitative risk assessment, PM Network, Vol. 14 No. 10, pp. 61-6. Hillson, D. (2001), Extending the Risk Process to Manage Opportunities, PMI Europe, Berlin. Kaplan, S., Haimes, Y.Y. and Lambert, J.H. (2001), Fitting hierarchical holographic modelling into the theory of scenario structuring and a resulting renement to the quantitative denition of risk, Risk Analysis, Vol. 21 No. 5, pp. 807-19. Kumar, R.L. (2002), Managing risks in IT projects: an options perspective, Information & Management, Vol. 40 No. 1, pp. 63-74. Maddoxx, M.E. (2005), Error apparent, Industrial Engineer, Vol. 37 No. 5, pp. 40-4. Pate-Cornell, E. (2002), Finding and xing systems weaknesses: probabilistic methods and applications of engineering risk analysis, Risk Analysis, Vol. 22 No. 2, pp. 319-34. Perobelli, F.F.C. (2004), A model for managing risks in non-nancial institutions: application at the Brazilian electric energy distribution sector, PhD thesis, FEA, University of Sao Paulo USP, Sao Paulo. PMI (2004), A Guide to the Project Management Body of Knowledge PMBOK Guide, PMI, Upper Darby, PA. Pollock, S. (2005), Create a simple framework to validate FMEA performance, ASQ Six Sigma Forum Magazine, Vol. 4 No. 4, pp. 27-34. Puente, J., Pino, R., Priore, P. and Fuente, D. (2002), A decision support system for applying failure mode and effects analysis, The International Journal of Quality & Reliability Management, Vol. 19 No. 1, pp. 137-50. Segismundo, A. and Cauchick Miguel, P.A. (2006), Managing risks in projects: a proposal from an initial integrated concept for the product development phase study in an automotive company, Proceedings of the XIV International Symposium of Automotive Engineering, Sao Paulo, Brazil (in Portuguese). Shenhar, A.J. (2001), One size does not t all projects: exploring classical contingency domains, Management Science, Vol. 47 No. 3, pp. 394-414. Shenhar, A.J., Raz, T. and Dvir, D. (2002), Risk management, project success, and technological uncertainty, R&D Management, Vol. 32 No. 2, pp. 101-9. Shimizu, T. (2006), Decision in Organizations, 2nd ed., Atlas, Sao Paulo (in Portuguese). Trammell, S.R., Lorenzo, D.K. and Davis, B.J. (2004), Integrated hazard analysis: using the strengths of multiple methods to maximize the effectiveness, Professional Safety, Vol. 49 No. 5, pp. 29-37. Voss, C., Tsikriktsis, N. and Frohlich, M. (2002), Case research in operations management, International Journal of Operations and Productions Management, Vol. 22 No. 2, pp. 195-219. Yin, R. (1994), Case Study Research, Sage, New York, NY. Corresponding author Paulo Augusto Cauchick Miguel can be contacted at: paulo.miguel@poli.usp.br To purchase reprints of this article please e-mail: reprints@emeraldinsight.com Or visit our web site for further details: www.emeraldinsight.com/reprints