Design and Validation of a Comprehensive Model for Risk

Design and validation of a comprehensive model for risk-assessment in product development Amalgamation of Risk Management Standards as a Blueprint for Management of Risk in product development

Dipl.-Ing. Rainer Vieregge

A thesis submitted in partial fulfilment of the requirements for the degree of

Doctor of Philosophy in Electrical Engineering

Approved Dissertation Committee

Prof. Dr. Werner Bergholz Professor of Electrical Engineering Jacobs University Bremen Prof. Jens Froese Professor of Logistics Jacobs University Bremen Prof. Dr. Julia Bendul Professor of Logistics Jacobs University Bremen Prof. Dr. Wilfried Lux Professor of Financial Management and Controlling University of Applied Sciences St. Gallen (CH) Dipl.-Chem. Dr. Bernd Siemensmeyer Centre of Competence Accessories & Consumables Dräger Safety AG & Co. KGaA

Date of Defense: January 12th, 2016

Computer Science & Electrical Engineering

0 Statutory Declaration

Statutory Declaration

(Declaration on Authorship of a Dissertation)

I, Rainer Vieregge, hereby declare, under penalty of perjury, that I am aware of the consequences of a deliberately wrongly submitted affidavit, in particular the punitive provisions of § 156 an § 161 of the Criminal Code (up to 1 year imprisonment or a fine at delivering a negligent or 3 years or a fine at a knowingly false affidavit).

Furthermore, I declare that I have written this PhD thesis independently, unless where clearly stated otherwise. I have used only the sources, the data and the support that I have clearly mentioned.

This PhD thesis has not been submitted for conferral of degree elsewhere.

Bremen, June 06th, 2017

Signature ______

Page 3 of 163

0 Abbreviations

Abbreviations

AIAG Automotive Industry Action Group

AS Australian Standard

CMMI Capability Maturity Model Integration

CPk Process Capability Index

CRS customer requirement specification [Lastenheft]

D Detectability (E Entdeckung)

DGQ Deutsche Gesellschaft für Qualität

DPEA Deutscher Project Excellence Award

DRAM Dynamic Random Access Memory

EFQM European Foundation for Quality Management

ETA Expected Time of Arrival

FMEA Failure Mode and Effect Analysis

GPM Gesellschaft für Projektmanagement

ICV Internationaler Controller Verein eV

IGC International Group of Controlling

ILEP Initiative Ludwig-Erhard-Preis

IM:PULS IM Impact P Plan (Planen) U Do (Umsetzung) L Check (Lernen) S Act (Stabilisieren)

ITRS Technology Roadmap for Semiconductors

MIL Military Standard

NDP New Product Development Process

Page 5 of 163 0 Abbreviations

NZS New Zealand Standard

O Occurrence (A Auftreten)

PDCA Plan – Do – Check – Act (Deming Cycle)

PR Project Review

PTA Planned Time of Arrival

QFD Quality Function Deployment

QM Quality Management

R&D Research & Development

RADAR Results Approach Deployment Assessment Review

RM Risk Management

RPF Risk Priority Figure (RBZ Risiko Bewertungs Zahl [SxO])

RPN Risk Priority Number (RPZ Risiko Prioritäts Zahl [SxOxD])

S Severity (B Bedeutung)

SPC Statistical Process Control

SPICE Software Process Improvement and Capability Determination

TC Technical Committee

TRM Technical Risk Management

TRS technical requirement specification [Pflichtenheft]

TQM Total Quality Management

USP Unique Selling Proposition

VDA Verband der Automobilindustrie

Page 6 of 163 0 Abbreviations

VDI-GSP Verein Deutscher Ingenieure - Gesellschaft Systementwicklung und Pro- jektgestaltung

Page 7 of 163

0 Glossary

Glossary

Potential Effect(s) of Failure: „Effect(s), which may be caused by the occurrence of a potential failure. The consequences can be for one of the following operations (internal customers) or the end customer experience (external customer).“

Severity: „The degree of severity of the Potential Effect(s) of Failure. Failures appear with serious consequences as high risk, i.e. with a high ranting number for the risk (rating value). “

Cause: „Potential cause for failure. “

Occurrence: „Probability of the occurrence of the potential cause. Frequent occurrence appears to be risky, i.e. it is assigned a high-risk number (rating value)“

Object: The term "object" is used for all the concrete items in a development project: samples, project planning, prototyping, costing, risk analysis, etc.

Maturity: The term maturity is commonly described in terms of the ability of an organization or of a particular method or action.

Quality: DGQ: „Realisierte Beschaffenheit einer Einheit bezüglich der Qualitätsforder- ung“- „Implemented Characteristics of a unit with respect to the quality requirements“ ISO 9000: „Grad, in dem ein Satz inhärenter Merkmale Forderungen erfüllt“ - “Degree to which a set of inherent characteristics fulfills requirements” Fachkreis „Qualität & Controlling“: „Qualität ist der Grad der Erfüllung von Vereinbarungen (Forderungen) und Erwartungen“ (Wünschen) bezüglich Merkmalen, Terminen und Kosten“- „Quality is the degree of fulfillment of agreements (requirements) and expectations (wishes) with respect to characteristics, deadlines and cost“

Control Board (Dräger 2012, page 15): The Control Board is - if necessary - a committee from the project sponsor that takes over for the project, the project management tasks and responsibilities of the project principal. The members of

Page 9 of 163 0 Glossary

the Control Board are selected so that they represent the most important people and groups involved in the project. The project manager will inform the members of the Control Board regularly about the current status of the project, so they can react in time in case of deviations from the project plan. The Con- trol Board is the first escalation path for the project manager (except for Project Change Request, 7.4).

Complexity vs. Complicatedness: The main difference is the following: Assuming that an item or issue is complex, one needs to research / learn something new or innovative or understand the issues in order to overcome the issue and take the appropriate corrective actions. When an item or an issue is complicated, it requires "only" extended efforts to cope with, all based on existing knowledge.

Risk: The word "risk" appears in several languages Arabic: "Gift, random and unexpected, but some luck" Ancient Greek: "root, Cliff" Chinese: "probability of danger" Italian (15th century): "danger, risk"; Italian from older. ris (i) co, actually "cliff (which a vessel is circumnavigating)"

Page 10 of 163 0 Table of figures

Table of figures

Figure 1: List of risks ...... 27 Figure 2: Risk evaluation – initial – expected after corrective action – after corrective action ...... 27 Figure 3: Stage Gate Process at Dräger Safety (Dräger 2012) ...... 28 Figure 4: Exemplary risk categories and classification of technical risks (Wißler 2005, page 25) ...... 34 Figure 5: Toyota – start up and pre-production cost depending on Quality Function Deployment (QFD) (Sullivan, Lawrence P. 1986) ...... 40 Figure 6: Reduction in the early fail rate of central processing units (CPUs) at Intel over 2 decades (Crook, D.L. 1990, page 2-11): ...... 41 Figure 7: Reduction of ramp up times for the successive generation of Dynamic Random Access Memories (DRAMs) ...... 42 Figure 8: Relationships between the risk management principles, framework and process (ISO 31000, 2009)...... 46 Figure 9: Classification regarding the research method and description of relatively recent academic papers relevant for this thesis ...... 47 Figure 10: Economic relevant quality (English text – see list above) ...... 51 Figure 11: Deming Cycle ...... 52 Figure 12: RADAR of the EFQM model – illustration of the context between RADAR and Deming Cycle ...... 53 Figure 13: IM:PULS model ...... 54 Figure 14: Cost per failure along product life cycle (Pfeiffer, T. 2010) ...... 55 Figure 15: The KANO model (extended) ...... 57 Figure 16: Mean percentage change in the performance of the award-winning companies compared to the comparison companies for (Boulter, L. et al. 2005) ..... 60 Figure 17: cost estimation regarding defect prevention and failure cost for changes (DGQ 2008) ...... 63 Figure 18: Examples for functional requirement categories (in terms of severity). The format is derived from an Excel tool which has been developed as part of this project which will be introduced later and which serves to reduce the administrative overhead to the proposed tool for product development risk management...... 69

Page 11 of 163 0 Table of figures

Figure 19: Examples for non-functional categories ...... 70 Figure 20: Explanation of used wording (Figure 19) ...... 70 Figure 21: Fill-in of Kano-Classification ...... 85 Figure 22: Marking the USPs ...... 86 Figure 23: Functional / non-functional requirements (see also “3.5 Value Analysis “) ...... 86 Figure 24: Magic Triangle (Saatweber 2011) ...... 89 Figure 25: Influence to reduce development time (Saatweber 2011, page 53) ...... 90 Figure 26: Process “New Product Development” at Dräger Safety AG (Dräger 2012, 2.2) (previous version) ...... 91 Figure 27: Modification of the Product Development at Dräger Safety to improve the risk management of the existing development process ...... 92 Figure 28: How to determine topics for “Technology strategic”...... 93 Figure 29: Matrix (Spread sheet tool) for risk evaluation at the research phase (requirements) ...... 94 Figure 30: Matrix (Excel sheet) for risk evaluation at Research Phase (technology) 95 Figure 31: Evaluation of risk for technology ...... 96 Figure 32: Level of risk regarding customer requirements...... 97 Figure 33: Risk factors of a concept, according to the Master Thesis of Al Ghussein 2015 ...... 97 Figure 34: Evaluation of risk for each concept ...... 98 Figure 35: Evaluation of one concept (extract) ...... 99 Figure 36: Risk matrix for identification of corrective action(s) (Kamiske, G. F. et al. 2012, page 702) ...... 100 Figure 37: Dynamical matrix for concept evaluation (example) ...... 101 Figure 38: Phases of the NDP / integration of NDP into Stage-Gate-Process (Dräger 2012) ...... 102 Figure 39: Definition & Design Phase as a part of NDP (extract of Figure 38) ...... 102 Figure 40: Transfer of the Concept Matrix content into the FMEA form ...... 103 Figure 41: Transformation the Concept Matrix into the FMEA form ...... 104 Figure 42: V-Model along the Dräger NDP-Process (Dräger 2011) ...... 105 Figure 43: FMEA model to evaluate risk, incl. detection ...... 106

Page 12 of 163 0 Table of figures

Figure 44: Verification / validation planning ...... 106 Figure 45: Standard table for detection scores 1…10 ...... 107 Figure 46: Dräger Safety Checklist “Kick-off” ...... 110 Figure 47: Product maturity, incl. goal for each quality gate (PR1 … PR5) ...... 111 Figure 48: DRÄGER Alcotest 7510: “The Dräger Alcotest® 7510 represents the market’s most advanced evidential breath tester. It is specifically designed for Law- Enforcement’s road-side screening and evidential breath test applications in conjunction with the Dräger Mobile Printer.” ...... 113 Figure 49: Matrix for the determination of technology ...... 114 Figure 50: Evaluation of concept 1 (RPF (average) = 40,3) ...... 114 Figure 51: Evaluation of concept 2 (RPF (average) = 52,8) ...... 115 Figure 52: Total evaluation of RPF (detailed; figure 1 of 2) ...... 116 Figure 53: Total evaluation of RPF (detailed; figure 2 of 2) ...... 116 Figure 54: Transfer of evaluation of RPF into FMEA form (just severity and occurrence) ...... 117 Figure 55: FMEA form and recommended actions to reduce risk [RPF] ...... 118 Figure 56: FMEA, including evaluation of severity, occurrence and detection ...... 119 Figure 57: Complete evaluation, incl. corrective action for aspects RPN > 125 ..... 120 Figure 58: Dräger Alcotest 3820 photo and short description of the functionality as downloaded from the Dräger website ...... 131 Figure 59: Oxygen Self Rescuers Oxy 3000 photo and short description of the functionality as downloaded from the Dräger website ...... 132 Figure 60: Gas detection X-am 7000 (previous version) photo and short description of the functionality as downloaded from the Dräger website ...... 133 Figure 61: Some facts about Dräger ...... 151 Figure 62: Risk management is important due to application ...... 152 Figure 63: Risk management is important due to application ...... 152 Figure 64: Risk management is important due to application ...... 153 Figure 65: Risk management is important due to application ...... 153 Figure 66: Concept Phase – Example: Building a House (1/4) ...... 154 Figure 67: Concept Phase – Example: Building a House (2/4) ...... 154 Figure 68: Concept Phase – Example: Building a House (3/4) ...... 155

Page 13 of 163 0 Tables

Figure 69: Concept Phase – Example: Building a House (4/4) ...... 155 Figure 70: Flowchart of product development: risk evaluation for technology (E:= makes decision, D:= execution, M:= contribution, I:= to be informed) ...... 156 Figure 71: Flowchart of product development: concept determination ...... 157 Figure 72: Flowchart of product development: FMEA – risk evaluation ...... 157 Figure 73: New Product Development Process (Dräger, German) ...... 159 Figure 74: Feedback from users (1/2) ...... 160 Figure 75: Feedback from users (2/2) ...... 161

Tables

Table 1: Table of papers for discussion (1/2)...... 37 Table 2: Table of papers for discussion (2/2)...... 38 Table 3: Extract of Literature Analysis; Method´s Impact to Use ...... 43 Table 4: Overview to what degree the main 4 demands of ISO 9001 for risk management mentioned above can be addressed by each of the relevant quality management and engineering techniques used in technology development and industrial production ...... 47 Table 5: Methods, models and systems as inputs to the risk management tool for product development, the core objective of this thesis ...... 73 Table 6: used sources ...... 76 Table 7: generic approach for "severity" and “occurrence” (AIAG 2008) ...... 80 Table 8: Example for risk by maturity of technology (occurrence) ...... 81 Table 9: Risk by maturity of technology (occurrence) - decoded ...... 82 Table 10: Example for risk by maturity of technology (severity) ...... 83 Table 11: Risk to market success (severity) – decoded ...... 84 Table 12: Comparison of “RAPIDO“ and the concept of this thesis ...... 128 Table 13: Evaluation of Percentage RPF < 25 for the Dräger Alcotest 3820 ...... 131 Table 14: Evaluation of Percentage RPF < 25 ...... 132 Table 15: Evaluation of Percentage RPF < 25 ...... 133 Table 16: Evaluation of Percentage RPF < 25 ...... 134

Page 14 of 163 0 Abstract

Abstract

Shorter development time of new products and a shift from complicatedness to complexity (see Glossary: complex vs. complicated) requires new thinking in product development.

To handle this trend there is a need for a better and more comprehensive knowledge of risks and challenges in product development. There are a number of risk evaluation methods available focused on different goals; e.g. project management, products, organization.

The scope of this thesis is not to add another new method to the market but to create a practical approach handling risks and challenges in product development in a more comprehensive and integrated manner. All activities in this method, from the technology roadmap to the start of production, are based on common and approved methods; e.g. Failure Mode and Effect Analysis (FMEA), Value Analysis, Kano model.

The objectives are reducing lead-time in product development and to make scheduling more manageable. To reduce the lead-time a new and modified approach of the FMEA method is used. To increase the efficiency of the method, without any appreciable decrease of the effectiveness, risks, evaluated by severity and occurrence will omitted from further consideration below a certain threshold level.

A further increase of effectiveness and efficiency is expected from the strategy that the technique is based on common and approved methods, to initiate the method with a “flying start” and also to reduce the employee’s resistance against new methods.

This thesis was carried out in cooperation with Dräger Safety, Lübeck, to set up a method for practical use which can be validated in practice.

This thesis is structured into 4 sections:

1. Basic principles of risk management 2. Description of structure and behavior of risk management handling in product development

Page 15 of 163 0 Abstract

3. Exemplary validation of the new risk evaluation in the context of the product development environment at Dräger Safety (in extract) 4. Discussion and outlook

Keyword: Product development, risk evaluation, FMEA

Page 16 of 163 0 Abstrakt

Abstrakt

Die immer kürzen Entwicklungszeiten neuer Produkte und der Wechsel von kompli- zierten zu komplexen Produkten zwingt zu einem neuen Denken in der Produktent- wicklung.

Um diesem Trend begegnen zu können, bedarf es einer immer besser werdenden Kenntnis von Risiken und Chancen in der Produktentwicklung. Die Methoden zur Risi- kobestimmung sind vielfältig und verfolgen teilweise ganz unterschiedliche Zielstellun- gen; z.B. Projektmanagement, Produkte, Organisationen.

In dieser Arbeit soll keine neue Methode hinzugefügt werden, sondern vielmehr ein praktischer Ansatz zum Umgang mit Risiken in der Produktentwicklung aufgezeigt werden. Dabei beruhen alle Schritte, von der Technologie-Roadmap bis hin zum Produk- tionsstart, auf bekannten und bewährten Methoden, wie z.B. Fehler-Möglichkeits- und Einflussanalyse (FMEA), Wertanalyse, Kano-Modell.

Ziel dieser Arbeit ist es, die Durchlaufzeiten von Produktentwicklungen planbar zu ma- chen und die Durchlaufzeiten zu reduzieren. Letzteres geschieht durch einen neuen Ansatz in der Risikobetrachtung mittels der FMEA-Methode. Es werden dabei Risiken, die eine bestimmte Schwelle bezüglich Wahrscheinlichkeit und Ausmaß nicht über- schreiten, nicht im vollen Rahmen der vorgeschlagenen weiterverfolgt, was letztend- lich zu einer höheren Effizienz der Produktentwicklung führt.

Sowohl die Steigerung der Effizienz als auch die Steigerung der Effektivität beruht auf der Auswahl bewährter Methoden, um zum einen die Hemmschwelle der betroffenen Mitarbeiter gegenüber neuen Methoden zu senken und andererseits beherrschte Me- thoden zum Einsatz zu bringen.

Die Anwendung der entwickelten neuartigen und umfassenden Methode ist in Zusam- menarbeit mit der Firma Dräger Safety, Lübeck, diskutiert, umgesetzt und validiert wor- den.

Die Thesis gliedert sich in vier Hauptteile:

1. Grundlagen zum Risiko-Management

Page 17 of 163 0 Abstrakt

2. Aufbaubeschreibung und Handlungsanweisungen zum Umgang mit dem Ri- siko-Management in der Produktentwicklung 3. Validierung der Vorgehensweise exemplarisch an einer Entwicklung (auszugs- weise) der Firma Dräger Safety 4. Diskussion der Ergebnisse und Ausblick.

Keywords: Produktentwicklung, Risikobestimmung, FMEA

Page 18 of 163 0 Contents

Contents

Statutory Declaration ...... 3

Abbreviations ...... 5

Glossary ...... 9

Table of figures ...... 11

Tables ...... 14

Abstract ...... 15

Abstrakt ...... 17

Contents ...... 19

1 Motivation and Problem Description ...... 23

1.1 General consideration regarding the differentiation between research and development ...... 23

1.2 Origin and History of Risk Management...... 24

1.3 Introduction to the current situation of Risk Management in Product Development ...... 25

1.4 Risk Management Objectives in Product Development ...... 29

1.5 Detailed problem description for Risk Management in product development. 32

1.6 Overview on the relevant literature ...... 36

1.7 Research Gaps and the objectives for this PhD project ...... 43

2 Risk Management ...... 45

2.1 General ...... 45

2.2 Targeted Field of Application of the results of this thesis in projects ...... 47

3 Theoretical background and common practice for risk management in product development...... 49

3.1 TQM as a tool for risk management ...... 49

3.1.1 The IM:PULS model ...... 51

Page 19 of 163 0 Contents

3.1.2 The Kano model ...... 55

3.1.3 The EFQM model for Excellence ...... 57

3.1.4 Potential TQM- / EFQM-Disadvantages (Critique by Kamiske)...... 61

3.1.5 FMEA ...... 62

3.2 Normative Risk Management ...... 65

3.3 DPEA as a tool for Project Excellence ...... 66

3.4 Technical Risk Management Perception ...... 67

3.5 Value Analysis ...... 68

3.6 Summary ...... 71

4 Overall approach to the risk management process developed in this thesis .... 75

5 Quantification of Risk Scoring for Technical Product Development Risk assessment ...... 77

5.1 FMEA – the extension ...... 77

5.2 Assessment Scoring ...... 78

5.3 Generic approach ...... 80

6 Risk assessment tool for continuous monitoring of product development risk . 81

6.1 Potential cause in product development ...... 81

6.2 Risks in product development: Effect of failure to meet external requirements ...... 83

6.3 Classification of customer, legal, market = external requirements ...... 85

6.4 Risks in product development: Effect of failure related to internal scenarios and/or requirements ...... 87

7 The Risk Management Model: Complete Design demonstarted ...... 89

7.1 Starting Point for Development of the model and application of the model at Dräger Safety ...... 89

7.2 Optimization along the New Product Development Process ...... 92

7.3 Risk evaluation for technology ...... 93

Page 20 of 163 0 Contents

7.3.1 Customer / market requirements ...... 94

7.3.2 Technology and / or components ...... 95

7.4 Concept determination ...... 96

7.4.1 Actual situation ...... 97

7.4.2 Method for concept determination ...... 98

7.4.3 Selection of the optimum concepts ...... 99

7.5 Risk determination after kick-off – Definition and Design Phase ...... 102

7.5.1 Transformation of Concept Matrix into FMEA form ...... 103

7.5.2 Characterizing the risk by the additional factor detection ...... 104

7.6 From Detection to Verification-Validation-Planning ...... 105

8 Project Maturity ...... 109

8.1 Quality Gates ...... 109

8.1.1 Project Maturity ...... 109

8.1.2 Product Maturity ...... 111

9 Validation of the concept ...... 113

9.1 Determination of technology ...... 113

9.2 Selection of the best concept ...... 114

9.3 Risk evaluation for the selected concept ...... 115

10 Discussion, Conclusions and Outlook ...... 121

10.1 Approach to the Discussion ...... 121

10.2 Discussion of claims A and B (see 1.6): ...... 121

10.3 Actual situation: Research on Risk Management in the Engineering and Technology Context ...... 126

10.4 Feedback from users...... 129

10.5 Work reduction ...... 130

10.6 Conclusions and Outlook ...... 134

Page 21 of 163 0 Contents

10.6.1 Using the solution for software development ...... 135

10.6.2 Project application: fulfilment of project goals (project-audit) ...... 135

10.6.3 Maturity of project environment in a given company (DPEA) ...... 136

10.6.4 Maturity of organizational the environment (EFQM) ...... 136

10.6.5 Steering Committee ...... 137

11 Bibliography ...... 139

11.1 Literature ...... 139

11.2 Standards ...... 148

11.3 Internet sources ...... 149

12 Appendix ...... 151

12.1 DRÄGER at focus ...... 151

12.2 Evaluation score in connection with choosing the best concept ...... 154

12.3 Flowcharts of risk management processes ...... 156

12.4 New Product Development Process at Dräger ...... 158

12.5 Feedback from users...... 160

12.6 Acknowledgment ...... 162

Page 22 of 163 1 Motivation and Problem Description

1 Motivation and Problem Description

1.1 General consideration regarding the differentiation between research and development

The objective of this PhD project has been the development of an innovative risk management analysis tool for the context of technical product development. This means that the project is an engineering research and development project, which includes the following aspects:

1. Identification of risk management methodologies from the micro and macroeco- nomic sciences, the organizational sciences and last but not least from engineering. These most important methods that have been identified as potentially useful for the development of the risk management tool are: a. Monte Carlo simulation b. Real Options Theory c. Fuzzy Logic / Control Theory d. Expected Utility Theory e. Game Theory f. Failure Modes and Effects Analysis (FMEA) The criteria for the suitability of one or more of these methods (or parts of the methods) are derived from the specified goals for the envisaged risk management tool for product development:

1. "Product Maturity": quantifiable, reproducible maturity metrics in projects to assess the probability for the fulfilment of product development goals 2. "Project / Product": method for the differentiation between project and product (portfolio) risks 3. "Corrective Action": corrective actions based on the additional organizational and product portfolio risks 4. "Everyday Business": easily "operationalized", i.e. it should be applicable in everyday business In addition to such tools to analyse risks, the aspect of risk assessment in the context of the organization and the decision process for the disposition of risks needs to be researched in the relevant scientific literature. The following are regarded as the potentially most relevant theories for this decision step in the risk management process

Page 23 of 163 1 Motivation and Problem Description

• Prospect-Theory • Principal-Agent-Theory • Normal-Accident-Theory.

1.2 Origin and History of Risk Management

As the starting point of this PhD project, a need to improve risk management in product development is perceived. Before going into more details why this is necessary and why there is a research gap, we first consider the origin of the term risk.

The origin of the definition of “risk” is not entirely clear. One can find many similar words in the Arabic und Italian area (Vieregge / Haberl 2008):

Arabic: “rizq – gift, accident and unforeseen, but certain fortune”

Old Greek: “root, cliff”

Chinese: “probability of hazard”

Italian (15. Century): “risco, rischio – hazard and venture”

The first basic scientific investigation on the todays “risk” was done by Pierre-Simon Laplace (1749-1827) and was published under the title “hasard” (Vieregge/ Haberl 2008). The French word “hasard” is commonly translated into the german / english words Glück (engl. fortune), Risiko (risk), Zufall (accident), Chance (chance), Fügung (destiny) etc., depending on the circumstances, one each of those terms may be the most appropriate.

Pierre-Simon Laplace described risk as the product of “benefit or harm” and the probability of these incidents. Therefore, we still define risk as a mathematical formulation: risk = (probability for occurrence) x (average consequence)

This leads to the general definition: “Instance of possibility or chance of meeting danger, suffering loss or injury, etc.” (Dictionary 1970)

This general definition of risk is the starting point for a more concrete risk definition in the context of this work, while it should be noted that different branches of sciences

Page 24 of 163 1 Motivation and Problem Description

define risk in different ways to fit the specific context. An overview of common other risk definitions is given by Vanini 2012, page 8. Most of the definitions are regarding special aspects, e.g. for organizations, such as financial success or sustainability. The definition of IGC / ICV is relatively general and is considered most useful for this thesis, since in our experience it fits the situation in an industrial development project rather well.

“The combination of occurrence and the magnitude of deviations from a planned target, mostly a financial target”

The Laplace definition of risk is also found in the fundamental work of A. Kuhlmann “Einführung in die Sicherheitswissenschaft”:

risk = probability x extent of damage (Kuhlmann 1981; page 10; 2.5)

In this work, the approach for a quantification of risk is based on a technique termed Failure Modes and Effects Analysis (FMEA) (Chrysler, Ford, GM 2008). The detailed description of the method is given in chapter 3.1.5. In this method, the more general term “combination” in the above definition is replaced by the mathematical operator multiplication of the two risk measures, in accordance with the definition of Kuhlmann (Kuhlmann 1981).

For this thesis, the definition of risk is consistent with definitions in the risk management standard ISO 31000:

Risk as per ISO 31000: "Effect of uncertainty on objectives"

Potential effects (of failure): Extent of damage – potential loss

Potential cause (of failure): Cause of damage – probability of occurrence

1.3 Introduction to the current situation of Risk Management in Product Development

To develop the concept of risk assessment and management in product development, we have to consider the salient features of product development.

Page 25 of 163 1 Motivation and Problem Description

Product development usually is carried out in projects, which are limited in time and resources, with specific project goals (as opposed to continuous activities). Projects do not always succeed, this is a general experience (Stern 2012). Thus, in recent years, a large amount of capital has been wasted, apparently caused by insufficient project management: Berlin airport, Elbe Philharmonic Hall, to name just two well- known examples, in which significant risks associated with those projects have materialized.

It may be surmised that such outcomes are at least partially because developments are becoming more complex and obviously are no longer manageable with the usual practice.

In the "traditional" project management, now in the specific context of product development, it has been the primary concern that a new product has the desired functionality and project management has been focused almost exclusively on the technical aspects (Vieregge / Haberl 2008, page 30, 5.2). In addition to the technical development goal (= quality), cost and development time (Scope - Time - Cost) have to be anchored as equally important goals in project management. The three aspects form the so-called magic triangle (see Figure 24) of project management (triple constraint); the time component of today is becoming increasingly important. Back in 2005, the BMW Production Director spoke of a planned reduction in development time for new models from 60 to 30 months (Netzzeitung 2005). In consequence, risk for a project has to include technical, time and cost risks.

To determine the risks that can arise in a project, there are a variety of established methods (Bartholomäus 2008). Two of the most common methods are (Zentis et al. 2011):

• FMEA - Failure Mode and Effect Analysis, as briefly mentioned before

• Risk matrix of the project work. (see Figure 2)

In this work, the FMEA method for the determination of technical risks will be used. The risk matrix, in combination with a risk mitigation program, has been used for the visualization of various types of risks, i.e. we will aim to consider all types of risk.

Page 26 of 163 1 Motivation and Problem Description

The risk matrix is an easy handling tool to identify risks. It is applicable in all situations where risks are expected. It starts with the gathering of risky situations (Figure 1), will be evaluated in a simple manner. This leads to a level of risk (Figure 2). If it is found to be too high, corrective actions should be initiated. After realization, the evaluation of the improved situation gives a picture of the new risk level.

Violation of existing Inition Kind of risk Significant effect Risk occurrence Risk severity Risk level law

very low very high medium medium medium medium high very high very high

Figure 1: List of risks

Risk level at initial Expected risk level after Risk level after corrective Initial evaluation Evaluation after corrective action evaluation correctiv action action > > = =

y very very very y very very t t i i r high 1 0 1 2 0 high 4 high 0 r high 0 0 0 0 0 high 0 e e v v e e s s high 2 2 0 0 2 high 1 high 3 high 0 0 0 0 0 high 0

medium 0 0 1 0 0 medium 6 medium 3 medium 1 1 1 0 0 medium 5

low 3 4 0 0 0 low 4 low 5 low 4 2 1 2 0 low 5

very very very very very low 0 3 0 0 0 low 6 low 8 low 1 4 2 0 0 low 9

very low low medium high very high very low low medium high very high

occurrence => occurrence =>

Figure 2: Risk evaluation – initial – expected after corrective action – after corrective action In the assessment of project risks, the usual procedure is to compare planned with actual progress at predefined breakpoints, frequently termed quality gates. At these Project Gates / the Project Reviews (PR) is based on checklists (Dräger 2012) in most cases, to assess the estimated target fulfilment percentage.

Page 27 of 163 1 Motivation and Problem Description

Figure 3: Stage Gate Process at Dräger Safety (Dräger 2012) Project gates are a kind of condensation point for information regarding the status of the project and the associated risks. This information “condensation” naturally has the “side-effect” that the extent of size of the risk (quantified e.g. by the product of the extent and the probability) is insufficiently transparent and that the evaluation is hardly reproducible, neither in most cases traceable. Moreover, the distinction between the various types of risk, project, product, and organizational (and as a consequence financial) risks, are rarely possible or even perceived, and to the best of the authors knowledge, not assessed in a systematic manner. This makes the overall assessment of the risk of product development incomplete and therefore inaccurate and unreliable; furthermore, it may complicate or prevent the identification of necessary corrective actions.

This means that there is need to improve the situation, and that there is a research gap regarding the development and validation of an appropriate risk management tool for product development which takes into account all types or dimensions of risk associated with product development.

To improve this unsatisfactory situation, it is necessary to refine the assessment of risks in product development in such a manner, that it is more transparent, more reproducible and traceable and that it facilitates derivation of corrective actions to mitigate unacceptable risks.

Page 28 of 163 1 Motivation and Problem Description

The following section describes well-known and industry practiced standardized approaches of quality management, which will be adapted and then used in this project to develop a new more comprehensive and traceable / transparent risk management procedure to be used in product development.

1.4 Risk Management Objectives in Product Development

As the first step to systematically developing a tool for comprehensive risk management, as described at the end of section 1.2, the first step is to examine topics of project goals in detail, in particular the process of defining the project goals. It will turn out that the first risk is already encountered in this preparatory phase of a project, which to our knowledge has been largely neglected so far in the literature:

The DIN 69901-5:2009-01 defines project management as „Gesamtheit von Führungs- aufgaben, -organisation, -techniken und -mitteln für die Initiierung, Definition, Planung, Steuerung und den Abschluss von Projekten.“ (DIN 69901-5:2009) ("totality of the management of tasks, of the organization or techniques and of resources for the initiation, definition, planning, control and completion of projects")

The product development has the goal of developing an outcome that meets the objectives of the technical specifications (which describes the quality (set of characteristics) of the new product) for that particular product in the planned time and for the planned cost.

Following this general definition, so the first risk surfaces before the actual development has started. The transition from the customer requirement specification (CRS) to the technical requirement specification (TRS) poses a significant risk in itself: If the "voice of the customer" (Kamiske 2012, page 717) cannot be fully taken into account or the interpretation of the customer / market trends leads in the wrong direction, an inappropriate TRS constitutes risk for product development from the very beginning. Accordingly, a careful initiation of a project is a first important goal of the project management, which starts with a diligent “translation” of the CRS to the TRS. The success of the project, the achievement of the project objectives is subsequently largely dependent on the tools used and the manner of control during this initial step and not only

Page 29 of 163 1 Motivation and Problem Description

on the appropriate project management during the course of the actual product development. The newly developed risk management tool will include the often-neglected preparatory step in product development.

For the actual product development process, once the product development project has been started, there are “good practice” offers from established organizations, which we will examine for useful features to be integrated into the comprehensive risk management tool. The most common “good practice prescriptions have been developed and are offered by the following organizations:

• Project Management Institute (PMI, American) • Office of Government Commerce (OGC, English) • International Project Management Association (IPMA, international; in Ger- many: German Project management organization GPM)

A further source of well-established source of information are national and international standards which can serve as guidelines how the project specifications and project management may be structured:

• DIN 69900:2009-01 "Projektmanagement - Netzplantechnik; Beschreibungen und Begriffe“ (project management, network planning, descriptions and terms) • DIN 69901-1:2009-01 “Projektmanagement - Projektmanagementsysteme - Teil 1: Grundlagen“ (basics) • DIN 69901-2:2009-01 “Projektmanagement - Projektmanagementsysteme - Teil 2: Prozesse, Prozessmodell“ (processes, process model) • DIN 69901-3: :2009-01 “Projektmanagement - Projektmanagementsysteme - Teil 3: Methoden“ (methods) • DIN 69901-4:2009-01 “Projektmanagement - Projektmanagementsysteme - Teil 4: Daten, Datenmodell“ (data, data model) • DIN 69901-5:2009-01 “Projektmanagement - Projektmanagementsysteme - Teil 5: Begriffe“ (terms) • ISO 10006:2003-06 “Quality management systems - Guidelines for quality management in projects” • ISO 21500:2012-09 “Guidance on project management”

Page 30 of 163 1 Motivation and Problem Description

The proposed models / prescriptions have in common that they segment a project into discrete steps and define the timelines for each step. Each of the steps contains specific tasks and often certain standardized methods have to be used (Dräger 2012, 2.2). At the end of each phase are milestones (also termed quality gates) provided at which the current status / progress of the project has to be assessed. According to the result of that assessment a decision will have to be reached with 3 potential outcomes:

i. Continue the project, ii. Stop the project, iii. Continue the project, but with corrective action(s).

It is common practice that the risk of a possible failure at each of the milestones is “mechanically” assessed using predefined checklists. The output from the review is usually the following:

If all the items in the checklist fulfilled, it results in the conclusion that the risk of project failure is low. This can, however, be absolutely misleading, as will be shown below.

If one or more of the checkpoints are not met, then actions (stop of project or corrective measures) due to high identified risk(s) are needed.

In this procedure, it is not unlikely (as in will be explained below), that the actual root cause of the deviation from the project plan is not recognized, or at least not obvious.

In addition to this method of risk assessment by check points a general "Risk Mitiga- tion" procedure is also a common procedure in many organizations. To this end, all recognized / suspected problems are entered into a list (Dräger 2010, 7) and classified according to their impact on the project goal(s) and the probability of occurrence, i.e. a risk profile is determined. The representation of the distribution of risk is based on a risk matrix (Dräger 2010, 7). The initiation of corrective actions to minimize risk / avoidance is intended to improve the risk profile; in this mitigation process, it is defined which risk levels up to a certain date / quality gate are still acceptable.

Page 31 of 163 1 Motivation and Problem Description

1.5 Detailed problem description for Risk Management in product development

As explained before, within the practice of project management, it is necessary is to establish the basic framework for a more comprehensive and reproducible risk management process, which goes significantly beyond what has been practice so far. Tak- ing into account the requirements of the standards ISO 31000 for risk management and ISO 9001 for quality management systems, this must include the qualifications of project staff to be conversant with risk management methods. This aspect will be significant in the selection of the methods integrated into the risk management process, since the methods have to be simple enough to be understood and practiced by non- academic personnel.

In addition to an improved risk assessment methodology, another aspect has to be considered, which according to the author’s experience and various authors (Richter 2015, page 5; Völz 2010, page 1) has been neglected so far: the difference between a complicated and a complex problem, both of which can result in risks to product development: Most problems (not only in product development) are not only complicated but also more and more complex in nature, due to a large part due to the glob- alization of markets.

"Complex problems are difficult because they take surprising turns. .... " (Wohland 2007). According to Wohland and Wiemeyer, today’s industrial environment and product development is about mastering the complexity of projects, not the complicatedness. Complicatedness of a task or object in this definition results from a mismatch between a person’s knowledge and the individual features of the task / object. A complicated problem is not complex; it just needs sufficient knowledge to become “easy”. By contrast, a complex problem (or system) has many potential outcomes due to mul- titude of independent internal and external factors and impacts, and they require decisions at successive points in time, in spite of the fact that the outcome is difficult to predict. For a more detailed elucidation of the difference between complicatedness and complexity the reader is referred to (Wohland 2007, page 90).

Page 32 of 163 1 Motivation and Problem Description

It is judged in a critical analysis of the usual types of project management shows that the complicatedness of a project is at the center of attention, and that the complexity receives relatively little attention:

Project complicatedness can be dealt with by a checklist. Project complexity cannot be dealt with in an adequate manner when using a checklist for assessment of the current situation of the project. The decision is then "go" or "no go", especially as the ticking off a checklist focuses attention on the completion of tasks and not on the actual complexity of the situation. A further complication is, that the completion of checklists pro- motes "in the box thinking" which results in missing the bigger picture, in particular the organizational context in which the project is embedded (which can lead to interactions, such as e.g. bottlenecks in terms of resources needed in several projects at the same time), and the market structure and the existing project portfolio.

Due to the global exposure of product development, the project management method which will be developed in this work will not only from the technical risks, but rather take into account the additional risks that result from the organization (organizational / operational structure), the project management itself (as embedded in the organizational structure) and from the impact of the development results within the product portfolio, which is connected, among other implication, to market risks. All this is in turn embedded in a global environment which is the main cause for the increase of complexity, which according to the author’s perception are particularly important in the context of the organizational and product portfolio risk aspects. In other words, it is the maturity of the organization and the maturity of the product or the product portfolio in the market which have to be assessed within the context of product development risk management, an exclusive focus on technical risks regarding the achievement of the desired TRS neglects significant risk aspects. Such a “tunnel vision”, according to ISO 31 000 is clearly unacceptable.

Regarding the assessment of the maturity of an organization in terms of product development, this can be in many cases, based on a certification of the system by an accredited certifier in accordance with recognized standards for quality management systems (e.g. ISO 9001 (in 2011, more than 1 Million companies worldwide had a QM-

Page 33 of 163 1 Motivation and Problem Description

System certified by this standard), or ISO/TS 16949). As mentioned earlier, the industry uses the predominantly the FMEA method to determine the technical risk (Zentis et al. 2011), the usual project risk management is about the method of risk mitigation and checklists employed at the quality gates and used for improvement.

All the methods described, except the FMEA, have in common that they only make a qualitative statement, based on the expected risk. In this thesis, we will therefore develop a method to assess also the organizational risks in a more quantitative and therefore traceable and reproducible way.

A major problem that often occurs in the product development is the discrepancy between the planned objectives for the project costs and project times and the development goals and the actual results. Therefore, the risk aspects cost, development time and potential deviation from original technical goals have to be factored into the comprehensive risk management tool to be developed.

In the dissertation of Wißler (Wißler 2005, page 24) the sum of all project risks (cost, time, quality) is included / fudged into the technical risk (see Figure 4). This approach only takes the perspective of the maturity of the product to be developed and is therefore far too narrow for the objective of this work.

Technical risks Project risks

e.g.

scheduling risk

cost risk

quality risk

Figure 4: Exemplary risk categories and classification of technical risks (Wißler 2005, page 25)

Page 34 of 163 1 Motivation and Problem Description

In line with our assumption that pure technical risk assessment is not sufficient, the study results of the Fraunhofer Institute for Production Technology IPT, RWTH Aa- chen, (Zentis et al. 2011, page 71) make two significant statements on technical risk management for the scope of this work:

• “Größte Herausforderung ist die Integration des Risiko-Managements in die be- stehenden Organisationsstrukturen.“ (Zentis et al. 2011, page 71) (The biggest challenge is the integration of risk management into the existing organizational structures.) • “Die eindeutige Beschreibung von Risiken ist die größte Herausforderung der Risikokommunikation.“ (Zentis 2011, page 42) (The unique description of risks is the biggest challenge of risk communication.)

In a research project of the "Association for Project Management" (Gesellschaft für Projektmanagement GPM) (Spang 2009, page 32), the fields of action for the advance- ment of project management, which point in the same direction as this project, have been discussed. With respect to the objective of the present work, two statements are essential:

1. „In der internationalen Forschung gehört das Risikomanagement zu den am häufigsten thematisierten PM-Elementen. Bei den Anwendern rangiert es je- doch nicht unter den Top 5 PM-Elementen der zufriedenen praktischen Anwen- dung. Im Gegenteil, es besteht der Bedarf an Neu- bzw. Weiterentwicklung ent- sprechender PM-Werkzeuge und Tools und der Bedarf an grundlegender For- schung.“ (Spang 2009, page 32 (In the international research, risk management is one of the most commonly investigated PM elements. However, it is not ranked by users to be among the top 5 PM elements which are fully satisfactory in their practical application. On the contrary, there is a need for development of additional PM tools and a need for fundamental research.) 2. "Die Inhalte der vorhandenen Literatur zum Thema Risikomanagement sind für die Anwender nicht zufriedenstellend bearbeitet. Für das PM-Element Risiko- management besteht Forschungsbedarf.“ (Spang 2009, page 32) (The contents of the existing literature on risk management are not satisfactory for the users. For the PM-element risk management further research is needed.)

Page 35 of 163 1 Motivation and Problem Description

For completeness, we mention that software development has a special role in project management. The common risk assessment tool for software development in our opinion are very inconvenient (CMMI) (Giebler 2010, page 83) and / or determines the risk indirectly by the maturity of the processes used (SPICE) (Wagner / Rittemann 2011, page 1 ff.).

1.6 Overview on the relevant literature

According to a metastudy (Porananond, D. 2013) (Table 1, Table 2), in which about 1600 publications until 2012 have been analyzed within the context of risk management in research and development and in strategy management, about 160 papers have been assessed to be of sufficient quality and relevance to be analyzed by in this PhD project in more detail. Based on this initial filter, a search has been carried ot for more recent papers and selected other relevant documents which deal with risk management, not necessarily applied to R&D.

Further narrowing down the number of papers for a detailed discussion, I focus on 58 papers. All papers were checked for relevance to this thesis. The discussion is structured with the help of table Table 1, Table 2, in which each of the papers is represented in one line, and the columns list 3 main categories for the papers:

1. Scope including risk identification 2. Risk Analysis methods 3. Risk Disposition / mitigation / reduction

Each of these main categories are subdivided into several subcategories. As the last column, one or two content highlights are mentioned.

Page 36 of 163 1 Motivation and Problem Description

no. Publication Scope including Risk Identification Risk Analysis Quality/ Project Organi- cost / Market FMEA Analytical Game Th expecte control Real Monte Carlo, mentioned in Techno zation time Hirarchy utility charts, fuzzy Options Baysian N this thesis logy process theory logic Theory etc

Porananond yes yes yes yes ? yes yes yes yes yes yes yes 2013

yes, yes Hosseini 2014 yes yes yes yes RFMEA Porananond yes yes yes yes yes yes 2014 yes, yes Carbone 2004 yes yes RFMEA yes, Hillson 2006 yes yes strateg Seyedhoseini yes yes 2009 Seyedhoseini yes yes 2009 Marmier 2012 yes yes

yes Koivu 2014 yes yes Laurent 2012 yes Hassanzadeh 2012 yes Badri 2012 yes yes yes FMECA, petrinet & yes Profit 2014 Petri simulation yes Gourc 2006 yes own math Abrahamsen yes yes 2012 yes Takalo 2014 service qu. yes Hu 2012 yes yes Aven 2006 de Azevedo yes yes yes Degen 2010 yes Kutsch 2005 yes yes yes Oehmen 2010 yes yes yes yes value Arundachawat yes yes yes yes 2012 Mourato 2011 yes yes Mastroianni yes yes yes yes yes RFMEA 2011 Ab Rahman 2015 yes Hamza 2009 yes Cetindamar yes yes 2013 yes Kaplan 2001 yes Kujawski 2002

yes Alhassan 2013 yes yes yes

Huchzermeier yes yes 2001 yes McNeil 2005 financ RM Hampe 2015 Sanchez 2009 yes Hillson 2005 yes yes Hossen 2015 Bonnal 2002 yes yes Renn 2008 Schmitt 2011 yes yes yes? yes iFMEA Cooper 2014 yes Summer 2000 environ Sherer 1995 yes yes m. Gunther yes yes McGrath 2004 Murray-Webster yes yes 2010 yes Verdu 2012 yes

yes Hughes 2009 yes Murray-Webster 2010 Adner 2002 yes

Murray-Webster yes yes 1999 Murray-Webster yes yes 1997 yes Benaroch 2002 yes Segismundo yes yes yes yes 2008 Cagno 2008 Marques 2010 Hillson 2003 Jonen 2007 Hadi-Vencheh yes yes 2012

yes Zhang 2011 yes yes

Table 1: Table of papers for discussion (1/2)

Page 37 of 163 1 Motivation and Problem Description

no. Publication Risk Disposition/mitigation/reduction blue type=lietrature review treatment ISO own process comment mentioned in of critical 31 000 this thesis risk more knowledge to support the risk mgmt process than a Mainly literature reviews Porananond yes yes yes new theory, existing tools are too complicated for users 2013

RPN and RS scatter plots, 2 case studies yes Hosseini 2014 yes ?

Porananond case study food industry FMEA based yes yes 2014 case study electronics industry yes Carbone 2004

tactical vs strategic threats Hillson 2006 Seyedhoseini equal weight risk analysis and risk response yes 2009 Seyedhoseini same paper as D06 yes 2009 decision support system satellite development, Marmier 2012 yes complicated math, software tool yes Koivu 2014 yes supply chain, mainly process risks analyzed FMEA based Laurent 2012 portugiesisch Hassanzadeh risk from human factor, case study Ski resort yes 2012 yes Badri 2012 yes focus on safety gaps supply chain risks yes Profit 2014 yes

yes Gourc 2006 französisch, sehr theoretisch Abrahamsen Environmental risks focus yes yes 2012 yes Takalo 2014 yes bank in Iran case study yes Hu 2012 yes far too theoretical and complicated Aven 2006 theoretical discussion about risks de Azevedo portugiesisch FMEA based yes Degen 2010 yes Kutsch 2005 Interviews in the IT industry lean product development MIT good literature review Mainly literature reviews yes Oehmen 2010 yes Yes return vs risk FMEA based Arundachawat Thesis on the reduction of design rework FMEA based yes des. Rew. Red 2012 Proceedings quality in education, one paper on risk Mourato 2011 yes management in H E Mastroianni Master Thesis 4 case studies! yes yes 2011 Ab Rahman SPC for SMEs, development not mentioned 2015 yes Hamza 2009 yes SPC for man hours cost to alert to risks in development FMEA based Cetindamar Chapter 6 and 12 relevant but very theoretical yes 2013 yes Kaplan 2001 hologr model Holographic modelling, very theoretical FMEA based mathematical paper on risk reaction according to risk vs FMEA based Kujawski 2002 yes risk reaction benefit Master thesis with case study medical company, claims FMEA based yes Alhassan 2013 yes yes comprehensive model Huchzermeier mathematical treatment, general not very practical real options theory yes math tool 2001 yes McNeil 2005 Financial risk management history, mathematical Info from consultant, relation risk in ISO 9001 and ISO Hampe 2015 yes 31000 Sanchez 2009 Review paper risk managments in projects, very general yes, Comprehensive lit review, emphasis on RM standards Mainly literature reviews yes Hillson 2005 others Hossen 2015 very general risk in transport Bonnal 2002 yes general life cycle model, not practical Renn 2008 advertisement for risk book Schmitt 2011 innovation function modelling, too complicated Cooper 2014 book on ISO 31000 and IEC.. On RM in projects Risks in implementing ERP according to existing business Mainly literature reviews yes Summer 2000 processes Risks in software developemennt Sherer 1995

Gunther Real options an pharmaceutical R&D very theoretical real options theory yes McGrath 2004 Murray-Webster holistic planning and control of R&D projects, very real options theory yes 2010 theoretical claim to improve innovation by real options theory, very real options theory yes Verdu 2012 theoretical optimum vendor selection based on mathematical tool to real options theory yes Hughes 2009 TRL and RETh connect real options to technological readiness level Murray-Webster Risk and human behavior, very general real options theory 2010 limits of applicability of real options, very general, real options theory Adner 2002 depends on company strategy Murray-Webster real option applied to failure, very theoretical real options theory yes 1999 Murray-Webster real options theory and technological positioning, very real options theory yes 1997 theoretical yes Benaroch 2002 real options applied to risks iin IT system invest real options theory Segismundo well structured from automotive with case study FMEA based yes yes 2008 Cagno 2008 risk cube very general treatment with risk cube model FMEA based Marques 2010 3D Performance multidimensional process performance metric FMEA based Hillson 2003 yes RBS Consultant paper on Risk breakdown structure FMEA based Jonen 2007 semantic analysis of the term risk FMEA based Hadi-Vencheh Data Envelope analysis applied to FMEA FMEA based yes data envel An. 2012 general investigation of RM and Future technology analysis yes Zhang 2011 RM & FTA

Table 2: Table of papers for discussion (2/2)

Page 38 of 163 1 Motivation and Problem Description

With the help of the table the following objectives A) – D) regarding the advantages and merits of the proposed method can be substantiated.

A: This PhD project targets to be comprehensive work in terms of scope for risk identification (technical, project, organization, cost, time, market) and the use of standardized risk analysis and risk mitigation and risk management (FMEA, EFQM model, Qual- ity function deployment) tools, including fulfilling the prescriptions of the risk management standards ISO 31000. This is an important aspect to minimize training efforts and is also important for application in globally operating companies.

B: The method has to be simple and pragmatic enough to be applied in a corporate and / or public service environment, where non-academic personnel has to be able to perform the tasks.

C: The proposed method must identify relevant risk aspects about

• technical, project, • organizational, cost and • market aspects and employ an easy to handle and effective risk analysis and risk disposition / mitigation based on those detailed inputs (compared to methods that do not employ standardized QM tools but heavily rely on interviews, unstructured expert input amalgamation, surveys and other non-standardizes and / or more complicated methods).

Although most of those methods (as discussed above) employ more rigorous mathematical or other evaluation tools for risk analysis and mitigation than the rather simple FMEA tool, this, according to general industrial experience, must not lead to less reliable results.

D: A number of papers which are similar (but not as comprehensive in the scope of their risk identification) as the present work, present case studies which underpin that the generalization of the results from this project which is embedded in the Dräger company are generalizable.

Page 39 of 163 1 Motivation and Problem Description

The conclusion so far is that none of the papers from the scientific or technical literature describe a risk management process in product development which comes anywhere near the features A) – D) for a more comprehensive risk management method for projects.

As the next step towards developing the approach for the risk management tool we consider some specific quality engineering tools which we consider potentially useful components for our methodology:

The first methodology to be considered is related to the problem of transformation of the customer requirements into technical requirements. The standard method for this process is termed quality function deployment (QFD) (Sullivan, Lawrence P. 1986):

At Toyota, the introduction of QFD has led to an amazing reduction in the incidence of process changes needed during the ramp-up phase from R&D to pilot and mass production. In other words, the method has been very effective to identify and mitigate risks associated with the development of new motor cars. As will become clearer later, one reason for this apparent success of the method is the fact that a systematic translation exists for the customer requirements to the technical requirements, which quan- tifies the degree of “fidelity” of the translation, and at the same time takes into account the existing technology capabilities of the company.

Figure 5: Toyota – start up and pre-production cost depending on Quality Function Deployment (QFD) (Sullivan, Lawrence P. 1986)

Page 40 of 163 1 Motivation and Problem Description

Another technology area in which technical risk management by QM tools has also been used for at least 3 decades is microelectronics (Bergholz, Chapter 9 in Y. Yoshida and G. Langouche Editors, “Defects and Impurities in Silicon Materials - An introduction to atomic-level silicon engineering”, Springer Japan, in print Dec. 2015). Suitable defect engineering in connection with identified potential risks has led to amazing re- ductions in the early fail rate and the long-term reliability for central processing unit production by the Intel company:

Figure 6: Reduction in the early fail rate of central processing units (CPUs) at Intel over 2 decades (Crook, D.L. 1990, page 2-11):

a) Early fail rate measured in defective CPUs per one million CPUs in the first 1000h of operation b) Long term failure rate, measured in fit (1 fit= 1 failure per 109h hours of operation) The reduction of both types of failures by more than a factor of 100 or more over 20 years, in spite of more and more complex processes and a factor of 1000 higher number of individual devices in one CPU is truly amazing. It means that the most difficult risks in new product development, namely reliability risks have been reduced by at least two orders of magnitude.

Page 41 of 163 1 Motivation and Problem Description

Another instructive example how such tools have improved technical risk management is from a case study reported by Infineon Technologies in 2007 during an ITRS conference in Annecy in France in 2007. After initial DRAM development, unidentified technical risks have to be eliminated during the ramp-up and mass production phase, which manifests itself in initially suboptimal functional yields. The reduction in the time needed to ramp up to full function yields for successive DRAM generations is shown in Figure 7. Again, the tenfold acceleration of ramp up could not have happened without continuous improvement in risk management in the development of new products mainly by QM methodologies. These are, among others, the stringent application of the FMEA methodology and process management by statistical process control (SPC) control, which characterizes the process capability and ensures that the respective process is stable, including an “early warning” if the process becomes unstable due to special causes (Deming, 2000).

Figure 7: Reduction of ramp up times for the successive generation of Dynamic Random Access Memories (DRAMs) Many similar results for such improvements in technical risk management by QM methods can be found in the open literature (in addition to those in company internal documents, Source: W. Bergholz, private communication)

Page 42 of 163 1 Motivation and Problem Description

1.7 Research Gaps and the objectives for this PhD project

Product Project / Corrective Everyday Method Comment Maturity Product Action Business Monte Carlo Simulation is normally used in case of Monte Carlo Simulation - - o - Mathematical Problems and for Production Flow Analysis

Real Options Theory mainly used for Investment Real Options Theory + - + - Decisions

Control Charts are used for Statistical Process Control / Control Charts / Fuzzy Logic o o + o Fuzzy Logic in the Automatic Control Engineering Field

Expected Utility Theory for Non-technological Expected Utility Theory o - + - Application

Expected Utility Theory for Non-technological Game Theory o - + - Application

Analytical Hierarchy Analytical Hierarchy Process is used for Decision Making o - + - Process Support

Technical Risk Estimation for Design of new Products / FMEA + o + + new Processes

Research Objective + + + + Risk Estimation Concept in Product Development

"Product Maturity": quantifiable, reproducible maturity metrics in projects to assess the probability for the fulfilment of product development goals "Project / Product": method for the differentiation between project and product (portfolio) risks "Corrective Action": corrective actions on the basis of the additional organizational and product portfolio risks "Everyday Business": easily "operationalized", i.e. it should be applicable in everyday business

Table 3: Extract of Literature Analysis; Method´s Impact to Use From the current state of risk management in product development as described above, there are four "Research Gaps" which constitute the development objectives for this PhD project:

1. Creating a quantifiable, reproducible maturity metrics in projects to assess the probability for the fulfilment of product development goals (or rather the risk of non-fulfilment). The main difference to the assessment at discrete time points (based on the clearing of the quality gates / checklists, including go / no go decisions at quality gates) is that a quantified assessment of the overall project risk is to be enabled by the metrics. In addition, there is to be a definition of a maturity assessment of intermediate levels of product development, not only at the times of the quality gates, hence the level of maturity will allow a statement on the potential risk at any time during the project.

Page 43 of 163 1 Motivation and Problem Description

2. Establish a method for the differentiation between project and product (portfolio) risks. 3. Develop a process to derive necessary corrective actions on the basis of the additional organizational and product portfolio risks. 4. The methodology should be easily "operationalized", i.e. it should be applicable in everyday business, i.e. the extra “overhead” of work should not be excessive.

Page 44 of 163 2 Risk Management

2 Risk Management

2.1 General

Over the last decades, risk management has assumed a higher and higher relevance for the manufacturing and service industries. However, risk awareness and risk mitigation are not new. The earliest sources for risk management date from 400 b.c. (Ro- meike 2013, page 19). The first systematic risk mitigation activities were implemented at and with nautical insurance.

It was not until 2011 that an international standard which dealt with a systematic risk management (suitable for inclusion into a management system) was published by the ISO standard development organization in Geneva: The ISO 31000:2009 Risk management – Principles and guidelines.

Remarkably, the term “risk“ never appeared in the consecutive ISO 9001 editions until the 2015 revision was published. The terms used which can be seen nearest to risk were preventive actions to reduce the probability of defects or problems.

In the 2015 revision of ISO 9001, the development of plans to manage risks were stip- ulated. It is noteworthy that in this context the application of the standard ISO 31000 is not mandatory.

The assessment of risks and opportunities in the context of ISO 9001:2001 are within the context of (Koubek 2015)

1. Meeting the objectives concerning the customer demands and customer satisfaction 2. Enhancement of results concerning new products, new production or other processes, new markets etc. 3. Prevention or reduction of defect rates, complaints, loss of customers etc. 4. Improvement of indicators and performance for new products, services and processes Depending on the degree of complexity and type of organization, different kinds of tools for risk management may be mandated.

The ISO 31000 standard describes risk management in a comparatively general and generic way, which has ultimately been derived from the Deming cycle.

Page 45 of 163 2 Risk Management

Figure 8: Relationships between the risk management principles, framework and process (ISO 31000, 2009) In this PhD project, the focus is not on the ISO 31000 standard since it is too general for a meaningful direct application to the management of technical risks. Rather, the actual quality management and engineering tools routinely used in connection with the prevention or mitigation of risks are the main inputs and “guidelines” for the development of the comprehensive risk management technique in connection the development of technical products.

Value IM:PULS DPEA KANO FMEA USP Analysis PDCA EFQM 1. Meeting the targets regarding customer demands     and expectations 2. Enhancing the targeted objectives, with respect to      new products, new pro-cesses, new markets, etc. 3. Prevention or reduction of errors, customer    complaints, customer loss etc. 4. Improvement of performance indicators and results   regarding products, services, processes etc.

Page 46 of 163 2 Risk Management

Table 4: Overview to what degree the main 4 demands of ISO 9001 for risk management mentioned above can be addressed by each of the relevant quality management and engineering techniques used in technology development and industrial production 2.2 Targeted Field of Application of the results of this thesis in projects

Risk as an "Effect of uncertainty on objectives" is to be found where people deal with goals or objectives. They have to care about the consequences of their decision making. This is regarding the negative risk of a decision or the positive risk (opportunity). However, frequently often people consider only the negative aspects of risk. It is re- markable that according to the ISO 9001:2015 standard for QM systems and according to ISO 31000 it is mandatory to consider both the negative and positive aspects of risk.

A study of 182 relevant academic papers published between 2002 and August 2012 (Porananond, D. 2013) was performed to identify literature to project risk management. The result is shown in Figure 9.

Research Method Description No. of papers

Descriptive Describe various expect, theory and tools for 48 risk assessment and risk management

Empirical Survey, interview, case study, experimental, 68 exploratory based on empirical use and industrial case

Conceptual Propose conceptual frame work, model and 51 technique for risk management

Literature Review Reviewing of research paper and past study 15

Figure 9: Classification regarding the research method and description of relatively recent academic papers relevant for this thesis With some of the results of those papers, and based on the algorithm of ISO 31000, this thesis is focused on a practical use, covering the potential maturity of:

• the product, • the project management and • the organization.

The result of this thesis should be:

Page 47 of 163 2 Risk Management

• portable or transferable, • relevant and • beneficial for the users.

Page 48 of 163 3 Theoretical background and common practice for risk management in product development

3 Theoretical background and common practice for risk management in product development

To address the research objective namely to integrate the risks of the organization in the project risk management in this study, we mainly use in methods that have been developed in the context of quality management, as these have a direct link to technology development and are proven in industry practice.

By contrast, the organizational development literature which is more psychologically or economically oriented work will not be our primary source, since the practical experience is far less developed (if at all) in comparison to the decades long and world-wide experience with quality management and total quality management methods (in this context also consider examples from various quality-sensitive high tech industries, which have been mentioned above). Nevertheless, selected aspects of management and organizational science literature will be considered for potential usefulness at the appropriate stages of this thesis.

3.1 TQM as a tool for risk management

The most frequently used quality tool is to establish a quality management system based on the international standard ISO 9001, which has been adopted by more than a million organizations so far (2014: 1.138.155 (ISO 2015, page 1)). While the standard ISO 9001 provides the requirements for a quality management system, the information how this can be implemented is documented in the international standard ISO 9004 (ISO 9004:2009-11).

In addition to the standard ISO 9004, in which such organizational issues are considered as a relative minor add-on to the technical focus, our main source will be the 3 most commonly used practice-oriented models for comprehensive quality management (also called Total Quality Management TQM: the Japanese Deming Prize, the US Malcolm Baldridge Award (GWU 1993, sheet 1) and the European EFQM model (Vieregge et al. 2014, page 19 ff.)), all of which provide a holistic view of an organization including ALL aspects, in particular technical, logistic, organizational and eco-

Page 49 of 163 3 Theoretical background and common practice for risk management in product development nomic facets. Here, the term quality is understood in a very broad sense (i.e. in particular, the quality of management), to achieve a high level of performance for all these aspects through continuous improvement and via a system of closed feedback loops is the primary aim and principle of TQM. Through this analysis, the conflicting targets regarding between "quality - cost - time" (Kamiske, G. F. et al. 2012) are in a way resolved since experience has shown that a judicious application of QM methods can improve quality, reduce the cost and development / cycle time simultaneously.

ISO 9000’s (ISO 9000:2015-09) definition of quality is “degree to which a set of inherent characteristics fulfils requirement”. Often, these characteristics are hard facts or specification intervals for technical parameters which describe the performance of a product. However, customer requirements and desires are much more than the fulfilment of specification. As worked out in a task force of DGQ (Deutsche Gesellschaft für Qualität) and ICV (Internationaler Controller Verein), quality has to be “economically relevant”. As described in the statement, the “Economic Relevant Quality” (Vieregge et al. 2014) is a dynamic balance of an organization in terms of:

1. Fulfilment of Specification: Quality (ISO 9000:2015-09) degree to which a set of inherent characteristics fulfils requirement” 2. Boundary: The extent to which people expect this quality from the product and feel that they can only obtain it from the company that plans the development of that product 3. Confidence: To what extent do the people believe that the promised quality is proven in practice? 4. Desire: How important is this quality for the people? 5. Singularity: How many other suppliers can potential customers find? 6. Solvency: Is their willingness to pay for the product due to the perceived unique- ness and are prospective customers actually able to afford the product? 7. Profitability commensurate: Is there enough income after subtraction of all cost for a sustainable business development, including, provision for risk, capital costs and production and marketing of the required quality?

Page 50 of 163 3 Theoretical background and common practice for risk management in product development

1. Erfüllung von Spezifikationen

Qualität gem. ISO-9000 Grad, in dem ein Satz inhärenter Merkmale Forderungen erfüllt. 7. Rentabilitätsanspruch 2. Abgrenzung

Was müssen wir für fremde Leistungen bezahlen Inwiefern rechnen die Menschen und wieviel verbleibt uns für Zukunftssicherung, diese Qualität uns zu und sehen sich Risikovorsorge, Kapitalkosten sowie Erzeugung außerstande, ohne Tausch selber in deren Besitz zu gelangen?. und Vermarktung der geforderten Qualität? wirtschaftlich 6. Zahlungsfähigkeit relevante 3. Vertrauen Qualität In welchem Maße glauben uns Welche Kooperations- und Zahlungsbereit- die Menschen, dass die schaft erzeugt die wahrgenommene versprochene Qualität sich in Einzigartigkeit bei den Menschen und sind ihrer Praxis bewährt? sie fähig, sie tatsächlich zu leisten?

5. Einzigartigkeit 4. Begehrlichkeit

Wieviel weitere Anbieter dieser Welche Bedeutung hat Qualität können die Menschen mit diese Qualität für die vergleichbarem Aufwand finden? Menschen?

Figure 10: Economic relevant quality (English text – see list above) This implies that product development has to fulfil all openly communicated customer requirements, and desires, including those that have not been communicated. In other words, all the aspects listed to constitute the “economic relevant quality” have to be addressed, in particular in the development of the technical requirement specification TRS.

To elucidate how QM and TQM methods can serve to achieve these goals in practice, in the following subsection one of the fundamental principles of QM and TQM, namely closed feedback control is explained:

3.1.1 The IM:PULS model The core of QM and TQM is the principle of closed feedback loops or closed loop control, rather than open loop control, which is often met in practical project management. This has been termed by the pioneers of QM, William Edwards Deming, as the PDCA cycle (Figure 11), or as it has been renamed by the community, as the Deming cycle.

Page 51 of 163 3 Theoretical background and common practice for risk management in product development

Figure 11: Deming Cycle Closed loop control is an engineering principle, where the difference between the targeted output (or outcome) and the actual output in a process (or e.g. the output of an electrical circuit) is measured, and the difference is fed back to the input in a way that the difference is made smaller, ideally becomes zero (in technical terms, the feedback is negative, the opposite sign of the deviation, to minimize the deviation).

So, in the context of project management, the initial input to the process is the plan (approach) to achieve a desired goal, then the actual implementation takes place (Do), subsequently the difference between the planned and the actual result is assessed (Check), and finally a corrective action via suitable feedback to the input is initiated, to decrease the difference between desired and achieved outcome.

Critical examination on Deming´s cycle (Kamiske, G. F. et al. 2012 page 130) (plan- do-check-act) reveal that there are two important aspects missing:

• What is the exact procedure to define the goals / the planned outcome at the beginning of the Deming loop? • Step 3 “check” is defined as collecting data, analyzing and control. But the main point is not explicitly addressed: learning through the next iteration of the control loop

The amendment of these missing aspects has been implemented in the RADAR-logic of the EFQM-model (Vieregge et al. 2014).

Page 52 of 163 3 Theoretical background and common practice for risk management in product development

Learning and new objectives set

Set objectives to Result be achieved

Approach Act Plan Assessing and Plan improving Check Do Assessment & Refinement Do Deployment

Figure 12: RADAR of the EFQM model – illustration of the context between RADAR and Deming Cy- cle The RADAR starts with “results” to give the initial and continuous orientation regarding desired results or targets) during the whole process. To illustrate more clearly, a quote from Alice in Wonderland and a practical example are given. “If you have no destination all routes fit!” Arranging a meeting in Tokyo, first of all time and place will be agreed on. During the flight from Munich to Tokyo the expected arrival time is to be consistent with the planned meeting time, that is the target. To decide about increasing or de- creasing speed during flight, at least 2 indicators are necessary: average speed and remaining time. In terms of RADAR:

• R: Set the scope • A: Plan to get there (A=approach, i.e. the method or process) in time, namely the planned time of arrival (PTA) has to fit the agreed meeting time, so the flight schedule is arranged accordingly • D: During the actual flight (D=deployment) the expected time of arrival (ETA) is continuously calculated • A & R: feedback of the EAT to the flight schedule and refinement of the flight schedule to make ETA equal to PTA

The arrival in Tokyo for the meeting will be on time – because the transit was planned and operated (by continuous comparison of desired and expected outcome (=expected time of arrival ETA) and adjustment of the speed as necessary) as described.

Page 53 of 163 3 Theoretical background and common practice for risk management in product development

So, to continue the reasoning in connection with the RADAR systematics, to ensure that the results of the process reflect the real needs and are achieved in an efficient and effective way, additional reflection is needed for the step “learn”:

• What was planned and was it systematic? • What and how has it been executed? • Are the results based on our assumption during planning (or just a coincidence with favorable circumstance, i.e. just luck)? • Are the results within the expected limits, or were the objectives met?

The proposed way proposed by Mäder and Vieregge (Vieregge et al. 2015) to remedy the shortcomings of the Deming cycle is to rename the Deming cycle as IM:PULS.

Figure 13: IM:PULS model IM: => Impetus

P => Planen (plan)

U => Umsetzen (realize)

L => Lernen (learn)

S => Stabilisieren (stabilization)

The result of this approach is that the desired goals are achieved and that continuous improvement via the “learn” is achieved during multiple iterations of the feedback loop.

The relevance of the proposed IM:PULS amendments to the Deming cycle for product development (within the scope of this PhD project) is the following: As indicated in Figure 14, the cost for changes in product development (i.e. corrective actions initiated

Page 54 of 163 3 Theoretical background and common practice for risk management in product development by the feedback loop) increases exponentially with the time (Pfeiffer, T. 2010). There- fore, it is important to set the targets with due care (the input to the development process) and to find necessary changes (=cost and time risks) through continuous learning as early as possible.

Figure 14: Cost per failure along product life cycle (Pfeiffer, T. 2010) Using IM:PULS as a preventive tool for early risk detection, it can be anticipated that it will serve to save money, time and that it will result in an increase of the quality of the new product.

3.1.2 The Kano model More specifically, we now return to the question, how to transform the customer requirements into an appropriate technical specification as effectively and efficiently as possible. In the IM:PULS model, the importance defining the input to a process has been emphasized. In the specific context of product development, the starting point are the customer requirements. In practice, these are typically researched und specified by product management, which are the first input for the development of the planned output of the product development process, the TRS. In this process, the concept of economic relevant quality has to be taken into account.

A common QM tool to systematically translate (like language A into language B) the customer requirements into the technical implementation has been developed by Kano.

Kano created a model to divide the customer requirements into 3 main categories:

Page 55 of 163 3 Theoretical background and common practice for risk management in product development

“Performance – Simply stated, these are the requirements the customers are able to articulate and are at the top of their minds when evaluating options. They are the most visible of the model’s requirements and the better they are implemented the more satisfaction they bring to the user / customer of the product. Conversely, the worse they are implemented, the more dissatisfaction they create. Kano originally called these “One-Dimensional” because the better you ex- ecute these the more satisfaction from the customer you get, a more appropriate and common word is proportional satisfiers.

Basic – Simply stated, these are the requirements that the customers expect and which are taken for granted. If done well, customers are just neutral, but when done poorly, customers are very dissatisfied. Kano originally called these “Must-be’s” because they are the requirements that must be included and are the price of entry into a market.

Excitement – Simply stated, these are the requirements that are unexpected and create pleasant surprises or delights. These are typically innovations designed into the new product. They delight the customer when there, but do not cause any dissatisfaction when missing because the customer never expected them in the first place. Kano originally called these “Attractive or Delighters” because that’s exactly what they do.” (Kano model 2015)

This consideration will be especially helpful in the product development process clas- sifying the requirement into important or less important, in particular with respect to the criteria described in the context of “economic relevant quality”. It provides a technique to identify the most relevant customer requests and desires. This will ensure that the risk to develop the “wrong” product is mitigated.

Page 56 of 163 3 Theoretical background and common practice for risk management in product development

Figure 15: The KANO model (extended) 3.1.3 The EFQM model for Excellence One of the additional risks normally neglected in risk management in the context of product development (as mentioned in section 1) is the organizational risk. To assess such risks, it is necessary to analyze the company in a suitable manner for organizational risks. For a comprehensive assessment of the company´s organizational risk potential, i.e. maturity, the EFQM model as one of the 3 mainstream TQM models is chosen in the context of this project, since it is closest to the Im:PULS concept mentioned earlier.

The additional rationale behind this choice is the kind of “validation” of such models in practice (in preference to concepts from the recent scientific management literature). For this work, the most recent of the three mainstream TQM model is used because it is rated as the most advanced of the models. This is judged on the grounds that it could therefore build on the experience of the two previously developed models (the Deming Prize and the Malcom Baldridge Award (GWU 1993)), and is being revised at regular

Page 57 of 163 3 Theoretical background and common practice for risk management in product development intervals in a defined process with the participation of experts from industry and academia in order to convert to the latest scientific findings into the model (current as of 2013).

Before actually applying the model in this work, the basics will briefly be explained highlighting aspects which are particularly conducive for addressing the research tasks:

The EFQM model was originally developed in 1987 as a foundation of leading Euro- pean companies, with participation from industry and academia. As "EFQM Excellence Model": (EFQM 2012), it is now a recognized basis for determining the maturity of organizations. It uses the "Fundamental Concepts of Excellence", the "EFQM Excel- lence Model" and "RADAR" methodology already mentioned above.

EFQM is, as already stated, one model of several similar models which all aspire to cover all aspects of an organization in terms of quality, among other things the quality of top management. Its unique advantage compared to all other models, in our opinion, is the RADAR logic (which is a scoring algorithm which covers both WHAT has been achieved by an organization (the results) and HOW this has been achieved (i.e. the enabling processes). The maturity of an organization is ”measured” by the RADAR method, the assessment is quantitative and reproducible, and, more important serves as a "guide" to focus areas for improvement.

The EFQM Excellence Model has e.g. been used in in German Quality Award, the "Ludwig-Erhard Preis" for many times to date (ILEP e.V. 2012).

The basic concepts of the EFQM model are described now, they highlight important aspects in connections with organizational risks, in the words of the EFQM organization, they are necessary “to achieve sustainable success / excellence (EFQM 2012):

• Achieving Balanced Results (in terms of long and short term perspectives, and in terms of the 4 stakeholder groups customers, employees, owners and society at large) • Adding Value for Customers • Leading with Vision, Inspiration & Integrity

Page 58 of 163 3 Theoretical background and common practice for risk management in product development

• Managing by Processes • Succeeding through people • Nurturing Creativity & Innovation • Building Partnership • Taking Responsibility for a Sustainable Future

The concepts “Managing by Processes” is the most relevant for this work, certainly adding value for Customers and Nurturing Creativity and Innovation and Taking Re- sponsibility for a Sustainable Future also are more relevant than the other concepts.

For a quantitative evaluation of an organization and identifying strengths and areas of improvement, the organization is assessed according to the following “criteria” of the EFQM-Excellence-Model

5 enabler criteria: leadership, strategy, people, resources and processes, and 4 results criteria; customer, people, society and business results. The application of the criteria and sub-criteria (not listed here) provides a kind of template / structure for a review of the activities and relationship among the activities and what the organization achieves the maturity level is, by the construction of the model, dependent on the interaction between actions (enablers) and results.

RADAR-Logic

The RADAR logic offers a systematic approach and an algorithm to analyze quantita- tively the performance and the process quality of an organization, improvement potentials can be derived directly from the evaluation scores.

Since the feedback principle is integrated into the RADAR process, including the requirements that all relevant aspects have to be considered, the identification of areas of improvement delivers and the level of scoring per enabler criterion are all a helpful output to assess the maturity of the organization.

To support this statement, we briefly summarize the benefits of using the EFQM model and the validity of the EFQM model and the dependability of results derived from it, as demonstrated in several scientific studies, the results of which are briefly summarized in the following.

Page 59 of 163 3 Theoretical background and common practice for risk management in product development

In a study at the University of Leicester (UK) (Boulter, L. et al. 2005) the surmised positive effects of the utilization of the EFQM model have been studied. A comparison of companies which had received awards in EFQM competitions with competitors in a similar business field, demonstrated improved performance of the former companies in many indicators, in Figure 16 the average in increase of share prices is shown to be faster for the EFQM active companies.

Mean % Growth in Share Value

140 126 120

100 90 84 80 60 60 35 40 34 19 16 20

0 Year 0 Year 1 Year 2 Year 3

Award Winning Companies Comparison Companies

Figure 16: Mean percentage change in the performance of the award-winning companies compared to the comparison companies for (Boulter, L. et al. 2005)

The increase of shareholder value is considered a particularly relevant aspect to the scope of this thesis: To achieve this result, the organization must have had an effective risk management in product development. This results in the proverbial prevention instead of cure. As a result, a better performance of product development – cost of non- quality will decrease to an acceptable level, and ultimately better financial performance reflected in the share price.

An EFQM-organization is to provide clear processes and precise instructions for activities. These aspects will lead to a base for success in terms of risk detection, risk mitigation and risk avoidance. As a result, the organization will reduce risk in terms of cost of non-quality, time to market and not controlled process conditions.

Page 60 of 163 3 Theoretical background and common practice for risk management in product development

Before finally concluding that the EFQM tool will be instrumental for the assessment of organizational risks, we consider the critical remarks of G. F. Kamiske, one of the most cited German scientists for quality engineering and quality management.

3.1.4 Potential TQM- / EFQM-Disadvantages (Critique by Kamiske) A critical review of the EFQM model has been published by Kamiske (Kamiske, G. F. et al. 2012, page 48), some of the less desirable aspects identified by him are:

1. "Special corporate culture has to be implemented and is a pre-requisite for success " 2. „Long and time-consuming implementation process “ 3. „Perfectionism (as mandated by the model) is not always possible and useful” 4. „No concrete implementation model “

The questions to be answered within the context of this project (and before its application) are, whether the criticism is justified in general, and with special consideration of risk management and if so, whether it affects the suitability of the model for the application in risk management in product development.

In our practical experience and knowledge, this criticism does not appear to be well- justified, for the following reasons:

As the starting point, we consider the central goal of the EFQM model: "Excellent management and excellent business results, determination of the strengths and areas for improvement through self-evaluation“ (Kamiske, G. F. et al. 2012, page 623).

In line with this prescription, the EFQM is not a model, according to which a particular structure and process organization can be constructed like a machine from the blue print, describing it in detail. So, there no narrow prescription regarding the structure of the organization, neither the corporate culture. The real benefit of the model, in our understanding and practical experience is, that it offers the opportunity to make a quantified assessment based on the grid of the 9 criteria which provide a comprehensive and balanced assessment of the organization, with all the strengths and improvement potentials. So, also arguments 2 and 3 are judged to be not valid, if the model and the

Page 61 of 163 3 Theoretical background and common practice for risk management in product development guiding overall principle are implemented with pragmatism and common sense. With reference to argument 4, the model is not meant to be a blue print how to design an organization, it rather is intended to function like a microscope which sharpens the view in dealing with all aspects of the organization. That sustainable improvement must be accompanied by a change in culture and is a protracted process is almost common sense, can be regarded as an additional and intentional positive side-effect, and is certainly not a disadvantage.

Thus, this “high resolution” analysis capability of the RADAR scheme for the maturity of an organization is the main motivation to use the model in an adapted form for the construction of the product development risk management to embrace the risks which result from the organization.

3.1.5 FMEA The FMEA method is well known as a risk estimating tool in technology in production. FMEA is a pragmatic procedure based on simple principles, standardized procedures and common sense rather than 100% stringent mathematics. It is a reliability analyzing and engineering tool, which is based on a risk estimation according and risk assessment as prescribed in the ISO 31000 standard:

Risk Priority Figure: (RPF)

= {extent of damage or impact => effect of failure(s) (severity)} x {probability of cause (occurrence)}

This approach is supplemented by the probability to detect the nonconformity before launching a product or a process (and, most importantly, will result in a second risk metric, the risk priority number, as will be explained below). This kind of risk evaluation using the risk priority figure is normally used in the assurance and financial field and is focused on “restriction of undesirable pattern of events” (Vieregge R. 2008).

The FMEA is originally a preventive / proactive method to estimate the reliability of a product or (production) process. As indicated in Figure 17, it is very helpful in meeting project goals at particular cost when using FMEA at a very early stage (compare also

Page 62 of 163 3 Theoretical background and common practice for risk management in product development

Figure 14). 85% of all failures occur during the planning and development phase. Thereby prevention is necessary at the early beginning of product design.

Figure 17: cost estimation regarding defect prevention and failure cost for changes (DGQ 2008) The first documented implementation of the FMEA concept is from November 19th, 1949, when the U.S. military released the standard MIL-P-1629 “Failure Mode Effects and Criticality Analysis”. Due to the observed positive effects, nowadays the FMEA method is a standard for the automotive and semiconductor industry. It is required by all automotive OEMs for their suppliers along the supply chain. Therefore, the FMEA process is described in several consortia standards, e.g.:

• VDA (Verband der Automobilindustrie) - Band 4: „Produkt- und Prozess-FMEA“ • QS 9000 (Big Three (U.S./AIAG) Ford, General Motors, Chrysler): “Potential Failure Mode and Effects Analysis” • DGQ (Deutsche Gesellschaft für Qualität) - Band 13-11: „FMEA - Fehlermög- lichkeits- und Einflussanalyse“

The FMEA is normally used when the design concept of a new product (before the detailed design process is initiated) or production process is planned and before any resources are used for realization of “hardware”.

The evaluation for the reliability of a designed product or production process is quantified in a similar manner, based on the risk priority figure in simple manner by assigning

Page 63 of 163 3 Theoretical background and common practice for risk management in product development risk numbers in 3 “dimensions” (rather than 2), the product of the 3 numbers of which is called the risk priority number:

Risk (RPN) = {potential effect(s) of failure (severity)} x {potential cause(s) (occurrence)} x {current process controls (detectability)}

So, the only difference to the risk priority figure is that that figure is multiplied by another characteristic number, which characterizes how easy it is to detect that the risk has materialized. Risk management in the spirit of the FMEA method is “avoidance / prevention of undesirable events” (Vieregge, R. 2008). Thus, the FMEA risk estimation is based on the basic risk estimation (RPF = S x O) followed by an investigation of causes and possible early detection of failure causes, hence the detectability is considered to be an important aid to mitigate the risk. So, the FMEA method is extended by a third factor, the third as a measure for the probability finding the root cause so it can be prevented before it occurs by suitable counter measures.

The transition from the qualitative discussion of risks with their subjective observations and assessments towards a reproducible method is performed by a scaling of the three individual risk dimensions (severity, occurrence, detection) in standardized and relatively well reproducible manner. In the QM literature, there are a number of standard ways to do this. All of them have in common that a strong risk is associated with "10" and an almost negligible risk with "1", and that the steps in between are defined by statements about the nature of the risk. Although mathematically not exact, this classification has been proven to be extremely useful, efficient and effective for many decades. It is a tool for FMEA-teams to provide a common standardized base for the risk evaluation.

Especially the evaluations tables are very useful as a guidance how to rate the risks. Thereby the score can be traced back and is relatively well reproducible (subject to an acceptable uncertainty).

The principle of fixed standardize evaluation tables is used in this thesis when applied to the proposed risk assessment method.

Page 64 of 163 3 Theoretical background and common practice for risk management in product development

How to evaluate potential risks in detail will be explained in chapter Assessment Scor- ing.

3.2 Normative Risk Management

Before we start to integrate the concepts of the EFQM model in the product development risk management, we briefly review the established risk management procedures other than the FMEA, with the intention to add useful elements of those procedures to our risk management tool:

Risk management in relation to financial risks is an established, albeit not uncontro- versial methodology, a step towards an improvement can be the application of the relatively new ISO 31000 standard. A generally accepted and comprehensive system employed for risk management for companies and organizations did not exist before 1995. A standard that was in effect in Australia and New Zealand (AS / NZS 4360:2004) was used my many companies from all parts of the world. Remarkably, and based on this apparent need for a global standard, an initiative was launched to create a globally applicable ISO standard. Based on the national Australian Standard an ISO Technical Committee (TC 262) developed a global risk management standard. The comparatively large number of participating countries (33) is an indicator how much such a standard was in demand In November 2009, the risk management standard ISO 31000 (ISO 31000:2009-11) was published. Due to this well-organized development process based on both extensive practical experience and inputs from industry and academia, we consider ISO 31000 as a kind of gold standard for risk management.

The standard is intended for organizations of all sizes, which can achieve their goals and thus are subject to risks. This naturally includes the risks that may result from development projects, therefore the risk management process to be developed in this project must be consistent with the standard, and I consider it instrumental in the design of the process, since the process described in that standard represents the ag- gregated experience of many organizations and experts, and it has proven to be useful in practice:

Page 65 of 163 3 Theoretical background and common practice for risk management in product development

The ISO 31000 standard is constructed so that the organization is provided with a guideline for a more proactive risk assessment. The essential steps in are based on and are in accordance with the PDCA cycle to Deming (Kamiske, G. F. et al. 2012):

• Plan: Design of framework for managing risk • Do: Implementation of the risk management process and the framework • Check: Monitoring and review of the framework to manage risks • Act: Continual improvement of the framework

It is noteworthy that, according to this standard, the use of risk management seeks a balance between the risks associated with the negative and positive effects, not to avoid risks by all means, as already briefly alluded to earlier. This aspect is particularly relevant in the context of development projects, in which it is especially important that the opportunities that are associated with the risks are in a balanced ratio.

So, in the context of this work, the ISO 31000 describes the overall process of risk management in a very general manner, embedded into this will be the FMEA mythol- ogy as the key tool for risk assessment (which is one of the steps in the generic risk management process template of ISO 31000).

3.3 DPEA as a tool for Project Excellence

The next common tool to be considered in the development of an improved risk management method for product development are standard methods to manage projects.

In this context, a relevant and practical tool in the context of the development of a risk management system in the design has been developed by the Society for Process Management (GPM) and published (GPM 2009):

Remarkably, this DPEA (Deutscher Project Excellence Award) model has been developed based on the EFQM excellence model. It aims to evaluate ex post already completed projects. The assessment is consistent with the basic structure of the EFQM model, both the action (enabler) -as well as the results aspects of the project.

Page 66 of 163 3 Theoretical background and common practice for risk management in product development

Similar to the RADAR algorithm, an analysis is carried out, which leads to a final evaluation score. This score is a measure how the projects compare to a project excellence scale created by scores obtained in benchmark studies.

The score will be one of the key figures for management to review the maturity of the of project management system.

The essential ideas of the DPEA will also be integrated into our proposed risk management model.

3.4 Technical Risk Management Perception

In this section, we investigate, whether technical risk management is perceived as beneficial in practice. The technical risk management has developed into a separate discipline in product development. Unlike the monetary / financial risk management, technical risk management in engineering studies is not very prominent, an indicator for this is a comparison of the number of search entries for both terms (Scholar.Google, 14/11/2015: "financial risk management" => 21.900, "technical risk management" => 997 entries). The difference is even more drastic in scholar google

Technical risk management is defined as the preventive concept to assure product- and process quality; a typical method in is the FMEA mentioned before (Zentis et al. 2011, page 12). The FMEA model is described in 3.1.5 “FMEA” and constitutes the central method for this thesis.

To discuss technical risk management beyond the FMEA concept, we first consider a study / survey by the Fraunhofer Institute IPT (Zentis et al. 2011, page 25) has listed as targets of the technical risk management:

1. "Financial stability of the company" (58.7%) 2. "Early prevention of production planning and product fault already in the development process" (55.9%) 3. "Compliance with laws, standards or guidelines" (29.2%)

As detailed in the context of the FMEA description, it is apparent that the application of the FMEA method can be expected to results in those benefits.

Page 67 of 163 3 Theoretical background and common practice for risk management in product development

According to the survey, proactive use of the technical risk management results in significant benefits for product development (Zentis et al. 2011, page 28): The benefits were perceived as “low” by less than 20% of the respondents, i.e. the vast majority of respondents subjectively perceived the benefits of technical risk management

• Very low (1.1%) • Low (6,7%) • Rather low (17,3%) • Rather high (31.3%) • High (34,1%) • Very high (9.5%)

By the positive impact of Technical Risk Management to the product development this method will have to be a core aspect of this thesis, amended by other risk management aspects.

3.5 Value Analysis

Going beyond the pure technical risks, we now come back to the question of the risk involved in connection with the TRS and the CRS.

To describe and to analyze the market potential (and the potential market risks) of a product (e.g. with reference to the economically relevant quality, see above) it is indis- pensable to reliably research the requirements Customer Requirement Specification CRS. The outcome of this section will to identify practical levers to reduce the market risk.

In the first step, Value Analysis prescribes to split the requirements into two categories:

• Functional requirements • Non-functional requirements

In the definition of Value Analysis, “function” is “each single outcome of the object – operation, purpose, task etc.” (VDI-GSP 1995)

Page 68 of 163 3 Theoretical background and common practice for risk management in product development

So, risk mitigation requires the reliable determination of the required functionalities – what is the purpose of this product? These functionalities can be described in a standardized way:

• 1 noun (the object) and • 1 verb (what will happen with the object – active / passive)

e.g. A car is designed to move people – it´s a function

Secondly it is of interest how this functionality has to be performed: How is its functionality implemented – this question leads to the non-functional requirement which is a kind of boundary condition.

e.g. A car should have a lifetime of more than 150.000 km – it is a boundary condition or non-functional requirement

To develop a comprehensive compilation of the function and non-function requirements, the following fundamental categories shown in Figure 18 and Figure 19 are proposed to be used. The completeness of these proposed lists has to be validated by application in concrete projects. It is certain that improvement potentials will be found, i.e. categories have to be added / modified or deleted when the proposed is developed further.

Technologie oder Komponenten / technology or components / TRS [A] vs. Kunden- oder Marktanforderungen / Customer- or market requirements / CRS [B]

Functional Requirement What should the product provide to the user? [B] 7 Functional Requirement Which services should be provided? [B] 7 Functional Requirement Input - Processing - Output [B] 7 Functional Requirement Behaviour in certain situations? [B] 7

Figure 18: Examples for functional requirement categories (in terms of severity). The format is derived from an Excel tool which has been developed as part of this project which will be introduced later and which serves to reduce the administrative overhead to the proposed tool for product development risk management.

Page 69 of 163 3 Theoretical background and common practice for risk management in product development

Technologie oder Komponenten / technology or components / TRS [A] vs. Kunden- oder Marktanforderungen / Customer- or market requirements / CRS [B]

Non-Functional Requirements Reliability [B] 7 Non-Functional Requirements Look & Feel [B] 7 Non-Functional Requirements Useability [B] 7 Non-Functional Requirements Performance / Efficiency [B] 7 Non-Functional Requirements Operation / Environmental Conditions [B] 7 Non-Functional Requirements Maintainability / Alterability [B] 7 Non-Functional Requirements Portingability / Transferability [B] 7 Non-Functional Requirements Safety Requirements [B] 7 Non-Functional Requirements Correctness [B] 7 Non-Functional Requirements Flexability [B] 7 Non-Functional Requirements Scalability [B] 7 Non-Functional Requirements Approval [B] 7

Figure 19: Examples for non-functional categories

Portability Transfer to similar products / exchangeable

Correctness Reliability of measuring results

Flexibility Multi use of the product

Approval e.g. according to national regulations

Figure 20: Explanation of used wording (Figure 19) The author’s personal experience of more than 100 FMEA-facilitations is that risk evaluation often ends up with a long inefficient discussion about functionalities. It is often a mixing of functional requirements (what should be done?) and boundary conditions (how should it be done?). To separate these requirements, value analysis has been found to very helpful to avoid such inefficiencies by clear definitions and exact wording. Furthermore, it is natural to expect that the resulting CRS will be improved in quality and clarity.

Page 70 of 163 3 Theoretical background and common practice for risk management in product development

There are three perceived benefits from this method for the proposed risk management tool (VDI-GSP 1995):

1. Clear differentiation between functional and non-functional / solution-related requirements 2. Instrumental to building a product architecture by functionalities 3. Simple standardized description of the functions by a noun and a verb

When describing the functionality of a new product, it must be clear which functions are needed to operate the product and which functions are restrictions (non-functional) for use? Value Analysis requires to clarify:

• What is the function for? => functional requirements • How is the function performed? => non-functional / solution-related requirements / boundary conditions

Using these basic definitions from the beginning of constraint triangle “cost – time – quality” is expected to be affected in a positive manner.

So, value analysis can be assumed to deliver clear definitions of product requirements so they can be integrated into the proposed risk management tool in an efficient manner.

3.6 Summary

The following table summarizes the systems / methods which will have be integrated into the construction of the improved product development risk assessment process and tool that is proposed, implemented (via an excel spreadsheet) and validated in this PhD project:

Page 71 of 163 3 Theoretical background and common practice for risk management in product development

System [Sy] / Type Method [Me] / Used characteristic Contribution Model [Mo]

Me Total Quality Man- Coverage of all company Inclusion and of all rele- agement [TQM] sections and members vant Quality Manage- ment tools

Me IM:PULS Control and feedback of ac- Control and feedback of tivities – improved version activities and pro- of the PDCA-concept cesses, improvement of the input and learning

Mo Kano-model Classification of customer improved determination requirements of the CRS Me

Mo European Founda- RADAR evaluation proce- Determination of the tion for Quality dure level of maturity of prod- Management uct development depart- [EFQM] ment and other organization parts involved in the product development process

Me Failure Mode and Reliability assessment; rat- Determination of the Effect Analysis ing scheme for risks product maturity, project [FMEA] maturity by application of SPC, quasi continuous assessment of the development status

Sy Risk Management Basic concept for risk man- Guideline/template for according to ISO agement approach to the tech- 31000 [RM] nical risk management

Page 72 of 163 3 Theoretical background and common practice for risk management in product development

Sy Deutscher Project Evaluation procedure for Level of maturity of pro- Excellence Award ??? ject management [DPEA]

Sy Technical Risk Basic approach to technical Focus on and applica- Management [TRK] risk management tion to our technical risk management concept

Me Value Analysis [VA] Definition of functionalities Differentiation between functional and boundary condition / non-functional requirements

Table 5: Methods, models and systems as inputs to the risk management tool for product development, the core objective of this thesis

Page 73 of 163

4 Overall approach to the risk management process developed in this thesis

4 Overall approach to the risk management process developed in this thesis

Up to this point, the foundations for developing the new more comprehensive and integrated risk management model and process have been covered. The methods, models, systems listed above can be viewed as “unit processes” (like the constituents of a technical production process), the model and method to be developed now is the anal- ogy of an integrated or complete process.

Risk evaluation should cover different aspects in product development, regarding environmental risk, usability, technology, design, safety (Bahr, N.J. 2014), supply chain etc.

In addition to such either very general or frequently very selective concepts, i.e. the unsatisfactory situation regarding risk management in product development in the literature, the second more concrete starting point of this thesis has been provided by the Dräger company, which will also be used to validate the tool developed in this project:

The intention of this thesis was to develop a practical solution for product development not only in theory (i.e. well anchored in theory), but it should also be suitable for daily business, and manageable by non-academic staff. Dräger Safety, a company in the field of gas detection and personal protection is a generally acknowledged manufacturer of innovation products. To fulfil market and customer requirements Dräger Safety is operating an extensive product development commensurate with the potential product risks and the high development investment requirements.

As a result of an analysis of past development projects, the project control boards at Dräger Safety came to the conclusion that the product development process:

• Caused unplanned and unacceptable delays for the start of production • Frequently missed financial goals • Failed to reliably meet all customer / market requirements

Page 75 of 163 4 Overall approach to the risk management process developed in this thesis

Therefore, the management of R&D launched a project to redesign the product development process to obtain higher efficiency and effectiveness in the “New Product De- velopment Process – NDP”.

The process had to be fitted into the company wide swim lane-format process-landscape (Dräger 2012).

In addition to the scientific and technical literature, and the corporate information systems of the Dräger company, more sources have been used as inputs for this thesis, an overview is given in the following table.

Desk research Field research Corporate- Literature Internet Online Expert Case brochure Corporation info x x Method x x x x x Market x x x Technology x x x x x

Table 6: used sources

Page 76 of 163 5 Quantification of Risk Scoring for Technical Product Development Risk assessment

5 Quantification of Risk Scoring for Technical Product De- velopment Risk assessment

The general method of risk assessment has already been described in section “3.1.5 FMEA”. Here these ideas are developed further now and will lead up to the new concept of technical risk assessment.

Risk assessment, by definition, is the quantification of risk. As mentioned before, it often is only performed on a qualitative basis or a quantifiable value is the result. Risk on a qualitative basis only is hardly reproducible because the risk is rated by personal experience and know-how. The go / no go assessment in quality gates has the char- acter of such a qualitative scale and is therefore unsatisfactory, and by inference, this cannot result in a more suitable metric to judge as to acceptance or rejection of a project.

To meet the requirement for traceability and reproducibility of quantifiable risk assessment, it is instrumental to define scores to describe / calculate potential risk, potential effects, and potential causes, as already mentioned and proposed in Table 7, in standardized tables.

There are different approaches to implement standardized risk rating scales. One of these is defined and practiced in the FMEA technique, which will be described in the following section in sufficient detail so it can serve as the basis for the proposed risk assessment tool.

5.1 FMEA – the extension

The traditional quantitative risk determination is normally used in the bank and insurance field. The purpose of risk assessment is to limit undesirable consequences of unplanned incidences to an acceptable extent.

By contrast, the FMEA model is mainly applied in the technological industries. The purpose of risk assessment is to proactively avoid unreliable products or processes by covering all perceived risks for failure and establishing a metric which of the risks to

Page 77 of 163 5 Quantification of Risk Scoring for Technical Product Development Risk assessment mitigate by additional measures to an acceptable size. So, FMEA is targeting at comprehensive assessment of potential causes of failure and defines a third factor for risk determination / assessment, which is not used in the financial and insurance methodology detection.

This lead to two distinct metrics for risk assessment which will form the core of the risk management tool:

Risk Priority Figure: (RPF)

= {extent of damage or impact => effect of failure(s) (severity)}

x {probability of cause (occurrence)}

Risk Priority Number (RPN)

= {potential effect(s) of failure (severity)}

x {potential cause(s) (occurrence)}

x {current process controls (detectability)}

5.2 Assessment Scoring

As explained before, the reliability of the product and the production process has to be determined by mapping effects, causes and detection into a scale which is repeatable and reproducible.

It is internationally agreed, that a scale from 1 to 10 is helpful range to calculate risk / reliability (AIAG 2008, VDA Band 4 2011):

1 – very low risk

10 – very high risk.

This convention is applicable to all three aspects of reliability of a given situation or technical product.

Each aspect of the calculation is defined as:

Potential effect – measured as “severity [s]” of the extent of damage

Page 78 of 163 5 Quantification of Risk Scoring for Technical Product Development Risk assessment

Potential cause – measured as probability of “occurrence [o]” of potential cause

Detection - measured as probability of “detection [d]” of potential cause

The reliability is quantified via the “risk priority number [RPN]” calculated as the product of:

RPN = [s] x [o] x [d]

[s], [x] or [d] = 1 … 10 leads RPN into a range of RPN = 1 … 1.000

Obviously, the higher the RPN, the lower the reliability and vice versa, so the reliability correlates with the inverse of the RPN.

To support a reproducible determination of the appropriate score, it is common to develop standardized assessment table. The table of the automotive industry (AIAG 2008) are generally accepted for technical use, and is a representative example of a standardized scale.

Using the IM:PULS model applied to the FMEA process, the process within the framework of the risk assessment model can be described as follows:

IM: Create a stable design for the new product / for the new production process

P: What has to be evaluated (process or product)? Which product / part or process has to be taken under evaluation? What about the maximum acceptable risk? Qualifi- cation needed in evaluation (team)?

U: Set up the architecture of product design / set up production flow plan; analyze of design (potential effects, potential causes, and detections); estimate the risk priority number (RPN).

L: Compare actual value with the acceptable limits. Identify the cause for the actual deviation. Identify all unacceptable RPN scores.

S: Define corrective actions to solve the cause of the problems, rate the new con- stellation, including the lessons learned (with reference to U:).

Page 79 of 163 5 Quantification of Risk Scoring for Technical Product Development Risk assessment

This IM:PULS-routine will be used throughout for all stages of the risk assessment process to enhance traceability and reproducibility of the risk assessment process.

5.3 Generic approach

Common wording is the base for creating a reproducibility and repeatability of RPF / RPN scores. Worldwide accepted FMEA standards (VDA, QS 9000, Bosch etc.) have been summarized by Vieregge / Haberl (Vieregge, R. 2008) to a unique table for “severity” and “occurrence” and are used in the proposed risk management method:

[S] Severity / Bedeutung / CRS [O] Occurrence / Auftreten / TRS [B] Severity of Effect on Product [A] Likelihood of Failure

1 Keine Auswirkung No effect 1 Sehr selten Very low

2 Belästigung Annoyance 2 Selten Low

3 Belästigung Annoyance 3 Selten Low

4 Belästigung Annoyance 4 Mäßig Moderate Ausfall oder Loss or Degradation of 5 Verschlechterung von 5 Mäßig Moderate Secondary Function Sekundärfunktion Ausfall oder Loss or Degradation of 6 Verschlechterung von 6 Mäßig Moderate Secondary Function Sekundärfunktion Ausfall oder Loss or Degradation of 7 Verschlechterung von 7 Oft High Primary Function Primärfunktion Ausfall oder Loss or Degradation of 8 Verschlechterung von 8 Oft High Primary Function Primärfunktion Verletzung von Failure to Meet Safety 9 Sicherheits- / gesetzli- and / or Regulatory 9 oft High cher Bestimmungen Requirements

Verletzung von Failure to Meet Safety 10 Sicherheits- / gesetzli- and / or Regulatory 10 Sehr oft Very High cher Bestimmungen Requirements

Table 7: generic approach for "severity" and “occurrence” (AIAG 2008) It has to be emphasized that this approach does not give an absolute accuracy of the risk priority number, but it results in relative accuracy, which will match the purpose for technical risk assessment. These two tables will be the basis for the following development of the risk management tool, which is the centerpiece of this thesis.

Page 80 of 163 6 Risk assessment tool for continuous monitoring of product development risk

6 Risk assessment tool for continuous monitoring of product development risk

In this chapter the generic quantification of potential effects and causes will be translated into concrete terms and wording in the context of product development.

6.1 Potential cause in product development

To assess the probability for a cause of failure it is necessary to translate the generic standardized wording for the FMEA technique into common product development terms. In this vein, the risk is characterized by the maturity of:

• The applied product technology • the used components / modules (subassemblies)

For example:

Generic assessment (s. Table 7): a score of 10 means => “Very high”

Product development interpretation:

10 Sehr oft Very High

Am Markt / in der Wissenschaft neue, nicht beherrschte Technologie 0

1 Technology at theoretical level

n i

Table 8: Example for risk by maturity of technology (occurrence) The total proposed translation for the score range from 1 to 10 is as follows:

Page 81 of 163 6 Risk assessment tool for continuous monitoring of product development risk

[O] Occurrence / Auftreten / TRS [O] Occurrence / Auftreten / TRS [A] [A] Likelihood of Failure Likelihood of Failure

1 Sehr selten Very low 6 Mäßig Moderate

d Technologie ist beherrscht und bewährt; Anbieter am Markt mit Anwendungserfahrung e t

a geringe Reklamationen aus dem Feld There are vendors providing technology with n i 0

Technology is under controlled Conditions; 0 application experience m 5

e l n i e

marginal claims from the market

1 e r u l i a F

2 Selten Low 7 Oft High Technologie in Großserie angewandt 0

0 Anbieter am Markt mit theoretischer

0 Technology is applied at mass production . Technologiekenntnis, ohne 0 0 0

0 Anwendungserfahrung 0 . 1

n Vendors available with know how, but i

n i 1 without application experience 1

3 Selten Low 8 Oft High

Technologie in anderen Produkten bereits Erste Pilotanwendungen vorhanden 0 0 angewandt Pilot application known 0 . 0 5 0 Technology is applied for serial production 0 n i

1 n i

4 Mäßig Moderate 9 Oft High

Technologie im eigenen Hause beherrscht Technologie noch im wissenschaftlichen

0 Stadium 0 Technology is under controlled conditions for 0 . 0 Technology is at academic level 0

internal production 2

1 n

n i 1

5 Mäßig Moderate 10 Sehr oft Very High

Technologie im eigenen Haus bekannt Am Markt / in der Wissenschaft neue, nicht beherrschte Technologie 0 technology is known in-house 0 0 1

0 Technology at theoretical level

. n i 2

n i

> 1

Table 9: Risk by maturity of technology (occurrence) - decoded The score reflects the stability of the process / design by using the percentage of non- conforming parts / the sustainability of the used technology measured in percent or the

Page 82 of 163 6 Risk assessment tool for continuous monitoring of product development risk

cpk value, a metric used in statistical process control (Wittmann / Bergholz, 2016, page 71ff).

6.2 Risks in product development: Effect of failure to meet external requirements

The extent of damage during product development is mainly determined by missing to meet:

• Customer requirements • Market requirements / regulations • Legal regulations

Due to these circumstances, the effect of failure has to be translated into the specific wording regarding customer / market / legal regulations.

For example:

Generic assessment (s. Table 7): a score of 10 means => “Failure to Meet Safety and / or Regulatory Requirements”

Product development interpretation:

Verletzung von Failure to Meet Safety 10 Sicherheits- / gesetzli- and / or Regulatory cher Bestimmungen Requirements Gefährdung, Verstoß gegen Gesetze, Gefahr für Leib und Leben Danger, effecting legal regulations, danger to life or physical condition

Table 10: Example for risk by maturity of technology (severity) The complete standardize table for evaluation of the effect of failure is presented below:

Page 83 of 163 6 Risk assessment tool for continuous monitoring of product development risk

[S] Severity / Bedeutung / CRS [S] Severity / Bedeutung / CRS [B] Severity of Effect on Product [B] Severity of Effect on Product Ausfall oder Loss or Degradation of 1 Keine Auswirkung No effect 6 Verschlechterung von Secondary Function Sekundärfunktion Bedeutung äußerst gering, keinerlei Mittlere funktionelle Beeinträchtigung, Beeinträchtigung Verlust einer Komfort- oder Zusatzfunktion No impact to customer Middle severity, lost of comfort options

Ausfall oder 2 Belästigung Annoyance Loss or Degradation of 7 Verschlechterung von Primary Function Bedeutung sehr gering, lediglich optische Primärfunktion Beeinträchtigung, Kaum erkennbare Bedeutung groß, funktionelle Beeinträchtigung verminderte Primärfunktion Aussehens- oder Geräuschentwicklung High severity, fuctional interference Marginal severity, marginal impact on appearance and noise

3 Belästigung Annoyance 8 gravierend serious

Bedeutung gering, keine funktionelle Bedeutung groß, funktionelle Beeinträchtigung, Geringfügige Aussehens- Beeinträchtigung oder Sicherheitsmängel oder Geräuschbeeinträchtigung High severity, impact to vital function, safety Minor severity, no impact to function, little aspects impact to appearance and noise

Verletzung von Failure to Meet Safety 4 Belästigung Annoyance 9 Sicherheits- / gesetzli- and / or Regulatory cher Bestimmungen Requirements Bedeutung mittel, optische oder geringe Schwerwiegende funktionelle funktionelle Beeinträchtigung Aussehens- Beeinträchtigung und Sicherheitsmängel oder Geräuschproblem High severity, impact to vital function Middle severity, little impact to function, apperance and noise

Ausfall oder Loss or Degradation of Verletzung von Failure to Meet Safety 5 Verschlechterung von 10 Sicherheits- / gesetzli- and / or Regulatory Secondary Function Sekundärfunktion cher Bestimmungen Requirements Bedeutung mittel, geringe bis mittlere Gefährdung, Verstoß gegen Gesetze, Gefahr funktionelle Beeinträchtigung, Minderung für Leib und Leben Danger, effecting legal regulations, danger to einer Komfort- oder Zusatzfunktion life or physical condition Middel severity, little to middle impact to function, reduction of comfort options

Table 11: Risk to market success (severity) – decoded

Page 84 of 163 6 Risk assessment tool for continuous monitoring of product development risk

6.3 Classification of customer, legal, market = external requirements

Such external requirements, defined by the customer / legal / market conditions and usually compiled and structured by the product management department should be categorized, aligned to the potential for solutions and the consequences in case of non-conformities. Here the construct of Kano is used. The three important categories we chose to propose are:

• Performance / proportional satisfiers: features by which to benchmark own and competitor´s products which generate “proportional” customer satisfaction. • Basic: it is a must, the customer perceives only the missing requirement nega- tively, no positive perception if the requirements are met. • Excitement: Not a required feature but incentivizing the customer to purchase, thus creating new demand.

In the excel tool for risk assessment the inputs are according to the Kano-model based classification (Figure 21).

Figure 21: Fill-in of Kano-Classification Product management often define unique selling propositions / unique selling point [USP]. These characteristics are highlighted to create an advantage against competitor’s products. USPs should be focused on because they enhance the market position and commercial success. This fact is reflected in the risk assessment model (see Fig- ure 21, Figure 22).

Page 85 of 163 6 Risk assessment tool for continuous monitoring of product development risk

Figure 22: Marking the USPs Using the definition of Value Analysis, the requirement derived and categorized using the Kano systematics, the functionality will be allocated to the categories:

• Functional requirements • Non-functional / solution-related requirements

Figure 23: Functional / non-functional requirements (see also “3.5 Value Analysis “) When completely filled in, various discussions about the customer / market requirements are finalized and “embedded” in the excel tool, in this manner the first essential inputs to the tool are completed. Risk associated with external requirements have been covered.

How the risks associated with internal requirements are treated, is described in the next sections.

Page 86 of 163 6 Risk assessment tool for continuous monitoring of product development risk

6.4 Risks in product development: Effect of failure related to internal scenarios and / or requirements

The next obvious question is: What can cause the potential failure modes based on internal causes? If the

• Technology for manufacturing the product is not under controlled conditions (i.e. cpk value significantly below 1.67, the generally accepted limit for a process under control) (Wittmann / Bergholz 2016, page 71ff) or • a module or component of the product has no stable design,

these shortcomings can result in a product with high potential risk. Therefore, the probability of cause is a question of controlled technology and / or non-robust design.

If the cause for the failure mode is identified and if there is some likelihood that the problems can be addressed in acceptable time at acceptable cost, the company has the opportunity to influence the market success and thus mitigate the risk associated with the development of the of the product at a very early stage of the value chain i.e. before or during the development process.

The requirements are normally determined by the general market situation and / or by the promises made in advertising the new product.

Page 87 of 163

7 The Risk Management Model: Complete Design demonstrated

7 The Risk Management Model: Complete Design demonstrated

7.1 Starting Point for Development of the model and application of the model at Dräger Safety

In the preceding sections the design ideas and integrated principles for the risk management model have been described. In this section, it is described how the model is applied in a real corporate environment, in the context of this PhD project, at the Dräger Safety company.

As the first step, the situation before the model has been analyzed as described below:

As briefly mentioned in a previous section, the R&D-process was not working satisfac- torily. A high “slip rate” for time and cost was perceived. Just the quality of the design was not effected.

Figure 24: Magic Triangle (Saatweber 2011) Before start the description how to apply the risk management tool as a potential solution to the perceived shortcomings of the development process, it is in order to discuss solutions from a wider perspective first.

Risk evaluation is a team approach. Therefore, the team should include members of all involved departments in the value adding chain, e.g. product management, R&D, production, sales. The necessity can be rationalized from a study of Fraunhofer IAO: the integration of ALL relevant departments gives the best benefit reducing development time (see Figure 25).

Page 89 of 163 7 The Risk Management Model: Complete Design demonstrated

Frühes Einbinden der (relevanten) Abteilungen 68,4 % (Integration of (relevant) departments at an early stage)

Effectives Projektmanagement 52,9 % (effective project management)

Intensive Planung 46,3 % (Intensive planning)

Pragmatismus statt Over-Engineering 39,0 (Pragmatism instead of over engineering)

Gute Kommunikation 27,9 % (good communication)

Parallelisierung des Konstruktionsprozesses 26,5 % (Simultaneous engineering)

Figure 25: Influence to reduce development time (Saatweber 2011, page 53) The result of this research (Figure 25) can indicate a starting point for improving the situation of risk management in the context of technical development. The development process is described in some detail:

At the initiation of the project manager was officially announced as late as at the Kick- off. All feasibility studies, research and development etc. which happened before this official announcement were performed without the project manager and without cen- tralized project management. Thus, the project manager very likely does not have the complete information of test results, the circumstances of tests and other details, thus he has a lack of knowledge and context.

Therefore, as a remedy to the situation, an additional quality gate called “PR 0,5” was created in between Kick-off and PR 1 in the established development process, see Figure 39. The purpose of this inserted step was to ”freeze” the Customer Requirement Specification (CRS) to avoid cost increase and development time deviations in the development projects.

Page 90 of 163 7 The Risk Management Model: Complete Design demonstrated

Figure 26: Process “New Product Development” at Dräger Safety AG (Dräger 2012, 2.2) (previous version)

Page 91 of 163 7 The Risk Management Model: Complete Design demonstrated

7.2 Optimization along the New Product Development Process

As part of the complete product development process, set up by Dräger, it is considered that there are mainly three significant points of interest where risk determination can support decisions (see Figure 27):

1. Starting the research phase, it has to be clear which technology will be pursued for future products 2. At the end of the concept phase it has to decided which design concept will be the base for the rest of the project 3. Starting the product development, it is essential to know the maturity level of product

All decisions can be supported by the risk proposed evaluation method.

All new phases of the NDP are summarized in Figure 3 / Figure 26, the 3 decision points are highlighted as star-symbols in 1, 2, and 3. In the following sections, the added process steps are explained in detail.

Figure 27: Modification of the Product Development at Dräger Safety to improve the risk management of the existing development process

Page 92 of 163 7 The Risk Management Model: Complete Design demonstrated

7.3 Risk evaluation for technology

As mentioned several times, developing a new product, the technology applied should be at an acceptable level of risk for quality, cost and anticipated development time. To ensure this, planning for future technologies should be and is often managed by a technology and technique roadmap-tool to fix the necessary new technologies and the prospective date at which the technologies are to be launched. Based on the maturity of technology the investment (time, money) will vary.

The risk evaluation will start with the input of Product Management. They define the future requirements from markets / customers split into functional and non-functional requirements (see 3.5 Value Analysis).

On the other hand, R&D / Development, submit their technologies to fulfil the functionalities. It is obvious that a technology with a high maturity (as e.g. characterized by the cpk values for the technology in production) will lead to a lower risk and that a requirement with a high potential negative impact to market success will end in a high-risk level. This logic is visualized in Figure 27 / Figure 28.

Figure 28: How to determine topics for “Technology strategic”

Page 93 of 163 7 The Risk Management Model: Complete Design demonstrated

At this stage, there is no need for detection yet (see 5 Quantification of Risk Scoring for Technical Product Development), thus the risk at this stage is best characterized by the RPF metric.

7.3.1 Customer / market requirements In this section, the details of the process regarding customer and market requirements are described:

Product Management delivers customer / market requirements based on market research or other field survey methods. As explained before, to obtain useable input for risk analysis the requirements should be split into functional and non-functional requirements. The wording should be by a noun and a verb (see 3.5 “Value Analysis”).the description the functions should be categorized into:

1. FA:= functional requirement / NFA:= non-functional requirement (3.5 Value Analysis) 2. Ba:= basic; Le:= performance; Be:= excitement (3.1.2 The Kano model) 3. USP:= is this requirement planned as a Unique Selling Proposition?

This consideration is intended to make all involved parties aware this distinction for a reliable analysis of the market / customer needs.

Technologie oder Komponenten / technology or components / TRS [A] Function 1 Function 2 Function 3 vs. Kunden- oder Marktanforderungen / Customer- or market requirements / CRS [B] 3 4 5 FA Ba x 8 x 24 NFA Le 8 x 24 x 32 x 40 Be x 8 1 8 6 8 x 24 2 8 8 3 8 8

8 gravierend serious Bedeutung groß, funktionelle Potential effect – measured as “severity [s]” Beeinträchtigung oder Sicherheitsmängel High severity, impact to vital function, safety of the extent of damage aspects

Figure 29: Matrix (Spread sheet tool) for risk evaluation at the research phase (requirements)

Page 94 of 163 7 The Risk Management Model: Complete Design demonstrated

These categories will help R&D or development department to select the most suitable technology to meet customer´s demands and expectations.

For risk estimation, each functional requirement will be scored in terms of SxO (Table 11).

7.3.2 Technology and / or components R&D or development department has to respond to and ultimately meet the customer´s needs by technology and / or components out of company´s portfolio. The type of technology depends on the Kano categories and if the functional requirement is a USP.

3 selten rarely Potential cause – measured as probability Technologie in anderen Produkten bereits of “occurrence [o]” of potential cause angewandt Technology is applied for serial production

Figure 30: Matrix (Excel sheet) for risk evaluation at Research Phase (technology) The evaluation is based on Table 9.

The next step in the quantitative evaluation of the RPF is to take into account where a customer requirement is or will be influenced by technology.

As an illustration, consider the following arbitrary example: It has been decided that the product of medium risks (S and O larger or equal to 5), so RPF > 25 or if O > 7 the risk is unacceptable and must lead to additional activities to lower the risk, e.g. by a feasibility study, research into the technology, application tests etc. to reduce the risk score RPF to 25 or below, or the score for occurrence O to 6 or below.

Page 95 of 163 7 The Risk Management Model: Complete Design demonstrated

Technologie oder Komponenten / technology or components / TRS [A] Function 1 Function 2 Function 3 Function 4 Function 5 Function 6 vs. Kunden- oder Marktanforderungen / Customer- or market requirements / CRS [B] 3 4 5 6 7 8 FA Ba x Customer / market requirement 1 8 x 24 NFA Le 8 x 24 x 32 x 40 Be x 8 8 6 8 x 24 8 8 8 8

"Customer / market requirement 1" will Risk to high; Risk to high; be effected by "Function 1" => marked S x O > 25 O > 7

Figure 31: Evaluation of risk for technology Generally speaking, all activities for a high score level have to be listed and risk mitigation measures have to be scheduled in the technology road map. Technology with an accepted risk level after risk mitigation will be integrated into technology portfolio. Technologies where the risk score cannot be lowered by any means are not acceptable.

7.4 Concept determination

After the research phase and before the actual product development phase, a concept (determination) phase is implemented as part of the new development process. Based on customer needs and controlled technology, several product concepts will be generated. Once this has been done, the task of the project management is to decide for the most suitable solution for the best market success. The advantage of “benchmarking” several product concepts (e.g. by the QFD technique) at such an early phase is that the cost incurred by carrying out the assessment process at this stage is still very low, so the evaluation of several concepts can be done at little extra cost (compared to the total cost of the complete development). At the same time, the decision for the concept is taken on a much better information base. (One could also argue that all concepts are real options at such an early stage, in framework of real options theory, also see the discussion section).

As part of the proposed risk management process, the rule has been created, that all used technologies should perform with occurrence below 7. Otherwise the technology is assessed not to have the necessary maturity for a successful product development.

Page 96 of 163 7 The Risk Management Model: Complete Design demonstrated

7.4.1 Actual situation A redesign of the concept phase of the development process was done in 2014 / 2015. The goals (Dräger 2015, sheet 4) for the project:

• Optimized Concept Phase Process to improve o product scope definition & customer value coverage o market & technology risk-reduction o time-to-market

As part of the redesign of the development process at Dräger, a Master-thesis, entitled “Risk in the Concept Phase of Product Development“, was published (Al-Ghussein 2015).

This thesis analyses several, mostly internal risks, and scores the risk qualitative with “high”, “medium” and “low”.

Figure 32: Level of risk regarding customer requirements.

Figure 33: Risk factors of a concept, according to the Master Thesis of Al Ghussein 2015

Page 97 of 163 7 The Risk Management Model: Complete Design demonstrated

Using such scores results in a comparison of the concepts to identify the best solution under the aspect of risk management.

7.4.2 Method for concept determination The approach of this thesis is to determine risk as a result of customer / market needs and the available technologies, i.e. a more comprehensive treatment of risk.

Therefore, the risk estimation for concept comparison is similar to the one for technology risk. It is also a risk (RPF) which is calculated without the detection aspect. It´s the same reason as for technology risk.

For the concept determination, the risk will be evaluated by the effect of failure(s) [severity] and cause of failure(s) [occurrence]:

RPF = S x O

The evaluation of detection is not relevant at this stage (see 5 “Quantification of Risk Scoring for Technical Product Development”).

Figure 34: Evaluation of risk for each concept

Page 98 of 163 7 The Risk Management Model: Complete Design demonstrated

Figure 35: Evaluation of one concept (extract) 7.4.3 Selection of the optimum concepts The choice of the best concept, based on risk management (i.e. a subsection of the QFD technique), can be done in several ways:

• Comparison of total RPF average • Static matrix of severity / occurrence • Dynamic matrix of severity / occurrence

The comparison of the total Risk Figure (RPF) of each concept is the most obvious and easiest method way to obtain a result. The detailed determination of each RPF but would be necessary for decision. Thereby this kind of analysis strategy is not very efficient.

The literature, e.g. Gerd F. Kamiske (Kamiske, G. F. et al. 2012, page 702), offers a matrix where fields of:

• Immediate action • No compelling need for action, appropriate measure necessary • No action are defined in a risk matrix.

Page 99 of 163 7 The Risk Management Model: Complete Design demonstrated

10 9 ]

O 8 [

c 7 n e

r 6 u c

c 5 O 4 3 2 1 12345678910 Severity [S] No action

No compelling need for action, appropriate measure necessary Immediate action

Figure 36: Risk matrix for identification of corrective action(s) (Kamiske, G. F. et al. 2012, page 702) One indicator is proposed to be the percentage of “no action”, “no compelling need …” and “immediate action” in relation to the total number of RPF evaluations.

green = 90; yellow = 60; red = 50 => total = 200

green = 45%; yellow = 30%; red = 25%

Another potential indicator is: “no action” is rated with “1”, “no compelling need …” with 3 and “immediate action” with 10. The second method is easy to be determined and to compare.

green = 90; yellow = 60; red = 50 => total = 200

green = 90; yellow = 180; red = 500 => total = 770

The dynamic matrix is a moving target which is adapted the development process, as knowledge increases. It starts with a target value for number of green, red and red quadrant in the matrix of severity and occurrence. The question behind this method:

Page 100 of 163 7 The Risk Management Model: Complete Design demonstrated

“How reliable should the final design be?” In the author´s professional FMEA modera- tions the following percentages have turned out to be useful in practice:

green = 80% of all evaluations

yellow = 15%

red = 5%

Such practice is taking into account the complexity and intricacy of development processes.

Occurence [O]

12345678910

1 0

2 0

3 0

4 1 2 1 16

5 0

6 0

7 1 1 1 1 28

8 0

9 0

10 0 Severity [S] 0 0 6 0 0 0 7161810 Target Actual Actual [%] min. 80% 0 0% max. 15% 1 14% max. 5% 6 86%

Figure 37: Dynamical matrix for concept evaluation (example) At the end, the risk evaluation provides an indicator to guide management decisions. Depending on the situation, it is conceivable that the board decides either for a lower risk, or on the contrary for a riskier concept, due to a higher potential market success. If the decision is made in this way, it constitutes an informed decision, and everybody is aware of a higher risk in terms of time, money and perhaps quality of the new product.

Page 101 of 163 7 The Risk Management Model: Complete Design demonstrated

7.5 Risk determination after kick-off – Definition and Design Phase

The technology is controlled, the concept for the product has been decided – as the next step the transition into the New Product Development Process (NDP) is started with a formal kick-off.

Figure 38: Phases of the NDP / integration of NDP into Stage-Gate-Process (Dräger 2012) The area of interest for the thesis is the “Definition & Design Phase”.

Figure 39: Definition & Design Phase as a part of NDP (extract of Figure 38) The scope of this phase is to define / to plan:

• The project extent • The Customer Requirement Specification (CRS) • The Technical Requirement Specification (TRS) • The time scale • The budget (finance) • The product concept

Page 102 of 163 7 The Risk Management Model: Complete Design demonstrated

This phase will end up with Gate 5 / PR1-milestone. The project team commit themselves of the project targets and the control board will release the agreed resources. Now, all further project chances need a formal chance request.

It is the main objective and purpose of my thesis that the product concept is clearly defined, and has been decided upon in a well-informed manner, and that, no technical / functional risk [occurrence] is O > 7. This means, that the FMEA can start from the kick-off on. May be there are some necessary adjustments in the product concept to reduce risk. This has to be verified with respect to the CRS if the occurrence has any impact. The product requirements will be frozen at Gate 4 / PR 0,5.

The next steps after kick-off are the following: The matrix of the chosen concept has to be transferred into the FMEA systematic. Risk evaluation for technology and concept was just “to limit undesirable consequences of unplanned incidences” [see 5.1] now with the FMEA philosophy there is a turn of attention “to proactively avoid undesirable incidences” [see 5.1]. Therefore, from this point onwards, the factors “severity” and “occurrence” have to be augmented by “detection”. The question behind this factor is: “How can we detect potential failure mode” before the product specification is fixed and released. This can happen related to the potential failure cause or to the potential failure mode.

7.5.1 Transformation of Concept Matrix into FMEA form Concept Matrix FMEA form funtional requirement  potential failure mode S [severity]  S [severity] function  potential cause O [occurence]  O [occurence]

Figure 40: Transfer of the Concept Matrix content into the FMEA form It is an essential component part of the proposed tool that only risky items (RPF = S x O > 25) are transferred into the FMEA form. By this limitation, the FMEA team will focus only on relevant aspects which can become serious risk for product success. All concept evaluations at a low risk level will be eliminated for FMEA analysis from this stage onwards.

Page 103 of 163 7 The Risk Management Model: Complete Design demonstrated

Thus, the efficiency of the risk assessment by FMEA will be reduced significantly and potential frustration of the team members analyzing “peanuts” is reduced.

Technologie oder Komponenten / technology or components / TRS [A] Function 1.1 Function 1.2 vs. Component 1 Kunden- oder Marktanforderungen / Customer- or market [A] 5 3 requirements / CRS [B] FA What should the product provide to the user? [B] RPF 25 30 22 FA Ba Customer / market requirement 1 4 x 20 FA Be x Customer / market requirement 2 8 x 40 x 24 FA Ba Customer / market requirement 3 3 FA Le Customer / market requirement 4 5 x 15 FA Be x Customer / market requirement 5 9 x 27

RPF > 25 mögliche Fehlerfolge B möglicher Fehler RPZ mögliche Fehlerursache Vermeidungsmaßnahmen A Potential Effect(s) of Failure S Potential Failure Mode RPN Potential Cause(s) Preventive Actions O < > AA_1 0 Bedeutung groß, funktio- Customer / market Funtion 1.1 nelle Beeinträchtigung oder requirement 2 Sicherheitsmängel 8 nvb 5 High severity, impact to vital function Bedeutung groß, Customer / market Funtion 1.2 funktionelle requirement 5 Beeinträchtigung oder Sicherheitsmängel 9 nvb 3 High severity, impact to vital function, safety aspects

Figure 41: Transformation the Concept Matrix into the FMEA form Now the actual technical FMEA process starts.

7.5.2 Characterizing the risk by the additional factor detection Too high at risks will affect the market success of the new product. Therefore, a risk analysis and mitigation process is needed, the central theme of this thesis. The failure mode effect [severity] cannot be changed at this stage anymore because it is immanent to the customer requirements. The risk of failure cause is given by the maturity of the applied technology, it can be improved, but with considerable effort and with a time lag. Thus, a third aspect is desirable: How can we detect the potential cause or the failure mode itself before the product specification will be frozen?

During product development two types of testing of the product are implemented:

1. Verification: This kind of testing gives the answer to “Has the product been constructed and built, right?” This covers all tests versus the internal specifications (TRS).

Page 104 of 163 7 The Risk Management Model: Complete Design demonstrated

2. Validation: This kind of testing gives the answer to “Has the right product been constructed and built?” and covers all tests versus the customer / market requirements (CRS).

The V-Model by Böhm (Wallmüller, E. 2011) gives a visualization about the use of verification and validation. It is mainly used in the field of software development but this idea can also be used in the product development process due to the same project structure and content (see Figure 42).

In the NDP-Process, verification will take place along the development phase, validation is carried out after the product is accepted by verification. Validation results will point out, that the product fulfils customer / market requirements.

Figure 42: V-Model along the Dräger NDP-Process (Dräger 2011) 7.6 From Detection to Verification-Validation-Planning

To reduce risk by detection, it is the question how to connect this concept to verification or validation testing. Going back to the definition of failure cause, the characteristic for failure cause is the functionality of the chosen technology, which is documented in the TRS. Testing against the TRS is connected to verification.

Page 105 of 163 7 The Risk Management Model: Complete Design demonstrated

First the potential failure modes connected to the CRS are considered: Testing against the potential failure mode (customer / market requirements) it is a test regarding the CRS. Here we talk about validation:

• To reduce the risk of failure, cause a detection by verification is needed • To reduce the risk for potential failure mode a detection by validation is needed

This way of detection provides a systematic way to generate the verification / validation planning. Testing now depends on the expected risk and not on the general question “What should be tested?”.

mögliche Fehlerfolge B möglicher Fehler RPZ mögliche Fehlerursache Vermeidungsmaßnahmen A Entdeckungsmaßnahmen E Potential Effect(s) of Failure S Potential Failure Mode RPN Potential Cause(s) Preventive Actions O Current Design Controls D

< > AA_1 2 Bedeutung groß, funktio- Customer / market Funtion 1.1 Verification 1 nelle Beeinträchtigung oder requirement 2 Sicherheitsmängel 8 120 5 3 High severity, impact to vital function Bedeutung groß, Customer / market Funtion 1.2 Validation 1 funktionelle requirement 5 Beeinträchtigung oder Sicherheitsmängel 9 108 3 4 High severity, impact to vital function, safety aspects

Figure 43: FMEA model to evaluate risk, incl. detection

g Prüfungsmethode obere Toleranz g n n n u o n i r u t o Testing Method Nominal Upper Tolerance Dokumentation i e r a i t e z c i a i i f f d d i i Merkmal Nominal untere Toleranz Documentation i i l l r r a a e e

V V V V Characteristic Lower Tolerance x Verification 1 10,0 mm 10,01 testform b Thickness 9,99 x Validation 1 99,83 HV 10 testform a Durability

Figure 44: Verification / validation planning When the tests are defined, they have to be scored to estimate the total risk:

RPN = severity [S] x occurrence [O] x detection [D]

Page 106 of 163 7 The Risk Management Model: Complete Design demonstrated

[D] Detection [D] Detection [E] Likelihood of Detection by Design Control [E] Likelihood of Detection by Design Control

1 Almost Certain 6 Low

Fehlerursache oder Fehlerart kann nicht ; e l auftreten, da sie durch Konstruktionslösungen b Produktprüfung / Validierung nach dem d a n n c o - a

i (z. B. bewährtes Designstandard, Best Practice i Designfreeze und vor dem Start mit l t h e p n c z

e oder übliches Material usw.) vollständig p n e Degrationstest (Subsystem oder Systemtest v a e u

e r t a r verhindert wird. l F nach Abbauprüfung, z. B. Funktionskontrolle). o

o n n

t e

Failure cause or failure mode cannot occur g r i n

r Product verification / validation after design s u o o l i i e i t

because it is fully prevented through design r

a freeze and prior to launch with degration D c p F e t t

solutions (e.g., proven design standard, best s

e testing (Subsystem or system testing after o D practice or common material, etc.) P degradation test, e.g., function check).

2 Very High 7 Very Low Designanalyse / Entdeckungsmaßnahme

haben eine starke Erkennungsfähigkeit; Die o Produktprüfung / Validierung nach dem t

d r e

o Designfreeze und vor dem Start mit Test

t virtuelle Analyse (z. B. CAE, FEA etc.) ist in i r a l p e hohem Maße mit tatsächlichen oder Versagen (Subsystem oder Systemtests bis r d r n o zum Ausfall, Prüfung von Systeminteraktionen

erwarteten Betriebsbedingungen vor dem a C

h e -

c z etc.).

s Designfreeze korreliert. n i e s e u r y

a Product verification / validation after design l Design analysis / detection controls have a l F

a n n strong detection capability; Virtual Analysis freeze and prior to launch with test to failure g A i

l s a (e.g. CAE, FEA, etc.) is highly correlated with e testing (Subsystem or system testing until u D t r t

i failure occurs, testing of system interactions,

actual or expected operating conditions prior s V o

to design freeze. P etc.).

8 Remote 3 High

Produktvalidierung (Zuverlässigkeitsprüfung,

o Produktprüfung / Validierung nach dem t

r e Entwicklungs- oder Validierungstests) vor dem Designfreeze und vor dem Start mit Pass- / Fall- z o i e r e

Designfreeze unter Verwendung von p r

Tests (Subsystem oder Systemprüfung mit F d

Degradationstests (z. B. Datentrends, vorher / n n Akzeptanzkriterien wie Fahr- und Handling, a g

i h e s nachher Werten usw.) c

z Versandbewertung etc.). e n e D

Product validation (reliability testing, e u r

a Product verification / validation after design o l F t

r development or validation tests) prior to n freeze and prior to launch with pass / fall o g i i r design freeze using degradation testing (e.g., s P

e testing (Subsystem or system testing with D

data trends, before / after values, etc.) t acceptance criteria such as ride and handling, s o

P shipping evaluation, etc.). 4 Moderately High

Produktvalidierung (Zuverlässigkeitsprüfung, 9 Very Remote

e Entwicklung- oder Validierungstests) vor dem z e e

r Designfreeze unter Verwendung von Test auf e Designanalyse / Entdeckungsmaßnahmen F g

a n Ausfall (z. B. bis Lecks, Ausbeute, Risse usw.) t haben eine schwache Erkennungsfähigkeit. g s i

s Product validation (reliability testing, y e

n Die virtuelle Analyse (z. B. CAE, FEA, etc.) ist D a

development or validation tests) prior to t o nicht mit den erwarteten tatsächlichen a t

t r

design freeze using test to failure (e.g., until c

o Betriebsbedingungen korreliert. i e r t P leaks, yields, cracks, etc.) e Design analysis / detction controls have a d

t weak detection capability; Vitual Analysis (e.g.

y l

e CAE, FEA, etc.) is not correlated to expected k i l

5 Moderate

t actual operating conditions. o N Produktvalidierung (Zuverlässigkeitsprüfung, Entwicklungs- oder Validierungstests) vor dem 10 Almost Impossible e z Designfreeze mit Pass- / Fall-Tests (z. B. e e r

F Akzeptanzkriterien für Leistung, Keine aktuellen Entdeckungsmaßnahmen; n g Funktionsprüfungen usw.) i

n y nicht erkennen oder nicht analysiert. s t e o i

Product validation (reliability testing, i t n D

No current design control; cannot detect or is c u o e t

t development or validation tests) prior to t r not analyzed. r e o o d p i design freeze using pass / fall testing (e.g., r p o P o

acceptance criteria for performance, function N checks, etc.)

Figure 45: Standard table for detection scores 1…10

Page 107 of 163 7 The Risk Management Model: Complete Design demonstrated

The risk limit for the RPF has been defined earlier at RPF > 25, in line with this “philosophy” the RPN limit will be set at > 125. This limit is generally agreed in the FMEA community. There are some deviations from this limit by Automotive TIER1 suppliers, e.g. Bosch (RPN = 96; no written specification of this exists, but we chose to conform with the mainstream method).

So, if RPN > 125 the risk must be mitigated. Whilst the value for severity is predeter- mined by the customer / market, only the evaluation for the maturity of technology (occurrence) or the detection can be optimized at this stage.

Occurrence can be reduced by choosing an alternative more mature technology or improving an existing technology (which as a rule at this stage a more costly and time- consuming alternative) or the better alternative is to identify problems by early detection. Thus, the risk as measured by the RPN is reduced in a more timely and cost efficient manner.

Page 108 of 163 8 Project Maturity

8 Project Maturity

8.1 Quality Gates

8.1.1 Project Maturity As to be seen in Figure 26: Process “New Product Development” at Dräger Safety AG (Dräger 2012, 2.2), the product development is split into several well-defined phases. It is reiterated that the phases are separated by so called quality gates where the product development is halted and the results are reviewed against the project goals.

Page 109 of 163 8 Project Maturity

Figure 46: Dräger Safety Checklist “Kick-off”

Page 110 of 163 8 Project Maturity

If most of the criteria are rated as “OK”, the project will continue. Otherwise the control board has to decide for corrective actions regarding: cost, time, quality. This is reflect- ing the project maturity. An example is given in Figure 46.

8.1.2 Product Maturity At started above, the severity of a specific failure mode cannot be influenced or reduced by the design of a product, since the severity depends on the customer / market requirements. Thereby the product maturity can only be influenced by the occurrence and the detection of the failure mode.

Occurence [O]

12345678910

1 0

2 0

3 0

4 1 2 1 16

5 0

6 0

7 1 1 1 1 28

8 0

9 0

10 0 Detection [D] 0 0 6 0 0 0 7161810 Target PR1 PR2 PR3 PR4 PR5 Act Actual min. 90% 25% 50% 70% 80% 90% 0 11% max. 10% 50% 35% 25% 15% 10% 1 1% max. 0% 25% 15% 5% 5% 0% 6 0%

Figure 47: Product maturity, incl. goal for each quality gate (PR1 … PR5) Thus, the goals for each quality gate can be set up at the kick-off meeting at the beginning of the product development. The “go” for the project is now the fulfilment of the project criteria and the product maturity, as visualized in Figure 47.

Page 111 of 163

9 Validation of the concept

In the context of validation, the step “determination of technology” is demonstrated for the example of an alcohol tester using the breathed-out air (“breathalyzer”), or Alco Screener. For further clarification of the product in the context of this thesis, the Dräger description for the product is reproduced below:

9.1 Determination of technology

The determination of technology is demonstrated for an alcohol screening device.

Figure 48: DRÄGER Alcotest 7510: “The Dräger Alcotest® 7510 represents the market’s most advanced evidential breath tester. It is specifically designed for Law-Enforcement’s road-side screening and evidential breath test applications in conjunction with the Dräger Mobile Printer.”

For the Dräger Alcotest model it is absolutely necessary, that the display is readable in practically all situations. Therefore, product management has classified readability as a USP for the next product generation. Three technologies have been available at the time of development of the product.

Page 113 of 163 9 Validation of the concept

Backlight (fix); Backlight adjustable, Technologie oder Komponenten / technology or components / TRS [A] Backlight (fix) contrast adjustable contrast adjustable vs. Kunden- oder Marktanforderungen / Customer- or market requirements / CRS [B] 4 2 8 Instrument read-out should be ensured at extrem lighting NFA Le x 6 x 24 x 12 x 48 conditions (bright, dark)

r o f n

t s o i h n n t c , s o o k s i g i n r t t n n r i o c t u i u e d f t u d n g h z s n d i p n e t y t t e n e o l a o o d n a

c r h b e e

s t

n a m w t c r p r i c d f a u e ä a e i t o s s r Z e r o h f g f

e l s i t r u r l y n y a n n o a m r r e m o i a g v r o H e m e i d o e t

e c s s v v t n o i e n n

f r n a e - B

e o

t o e g c w d r n

s e t n l r o e o e s ß l i u f n e n g l o o e i d o l k d r p

m i n e , n n t G p n o o

y c e u i a t o

m n t u i i i i s s w

r r t k i i d

n a e e e e n o i y i y a c d v n l r n u i t g g g g i l f a n e e p

o o o o o e t s p l l l l e l l

l e t i m t t p a r f o o o o e e s h P u l a

n e s o n n n n c

l u r e d t e l h h r r t h h n t e r d t d o c c c c h h a t i i s l e e e e i e e r e e n m T T i b M V M s T T s E P 4 6 2 8

Figure 49: Matrix for the determination of technology This method can also be used for components instead of a complete technology. If doing so a certain number of customer- / market requirements can be affected.

9.2 Selection of the best concept

In Figure 50 and Figure 51, the risk assessment for both concepts are displayed, as determined by the project team. In the following section, the selection process is explained:

Functional Requirement Which services should be provided? [B] 6 x 24 x 30 x 36 x 42 2 0 Functional Requirement Input - Processing - Output [B] 8 x 32 x 40 x 48 x 56 3 0 Functional Requirement Behaviour in certain situations? [B] 6 4 0 Non-Functional Requirements Reliability [B] 6 x 24 x 30 x 36 x 42 5 0 Non-Functional Requirements Look & Feel [B] 7 x 28 x 35 x 42 x 49 Non-Functional Requirements Useability [B] 6 2 2 2 2 48 Non-Functional Requirements Performance / Efficiency [B] 9 x 36 x 45 7 1 1 1 1 28 Non-Functional Requirements Operation / Environmental Conditions [B] 9 x 45 x 63 8 2 2 2 2 64 Non-Functional Requirements Maintainability / Alterability [B] 9 1 2 1 36 Non-Functional Requirements Portingability / Transferability [B] Non-Functional Requirements Safety Requirements [B] 10 1 1 20 Non-Functional Requirements Correctness [B] Severity [S] Non-Functional Requirements Flexability [B] 0 0 0 28403042 0 0 0 Target Actual Actual [%] Non-Functional Requirements Scalability [B] min. 80% 0 0% Non-Functional Requirements Boundary Conditions [B] max. 15% 0 0% Non-Functional Requirements Approval [B] 10 x 40 x 50 max. 5% 17 100%

Figure 50: Evaluation of concept 1 (RPF (average) = 40,3)

Page 114 of 163 9 Validation of the concept

Occurence [O] Technologie oder Komponenten / technology or components / TRS [A] Housing Energy supply Maintenance Display vs. 12345678910 Kunden- oder Marktanforderungen / Customer- or market requirements / CRS [B] [A] 8 [A] 6 [A] 6 [A] 8 1 0 Functional Requirement What should the product provide to the user? [B] 8 x 64 x 48 x 48 x 64 Functional Requirement Which services should be provided? [B] 6 x 48 x 36 x 36 x 48 2 0 Functional Requirement Input - Processing - Output [B] 8 x 64 x 48 x 48 x 64 3 0 Functional Requirement [B] 6 Behaviour in certain situations? 4 0 Non-Functional Requirements Reliability [B] 6 x 48 x 36 x 36 x 48 5 0 Non-Functional Requirements Look & Feel [B] 7 x 56 x 42 x 42 x 56 Non-Functional Requirements Useability [B] 6 4 4 48 Non-Functional Requirements Performance / Efficiency [B] 9 x 72 x 54 7 2 2 28 Non-Functional Requirements Operation / Environmental Conditions [B] 9 x 54 x 72 8 4 4 64 Non-Functional Requirements Maintainability / Alterability [B] 9 2 2 36 Non-Functional Requirements Portingability / Transferability [B] Non-Functional Requirements Safety Requirements [B] 10 1 1 20 Non-Functional Requirements Correctness [B] Severity [S] Non-Functional Requirements Flexability [B] 0 0 0 0 0 7801040 0 Target Actual Actual [%] Non-Functional Requirements Scalability [B] min. 80% 0 0% Non-Functional Requirements Boundary Conditions [B] max. 15% 0 0% Non-Functional Requirements Approval [B] 10 x 80 x 60 max. 5% 10 100%

Figure 51: Evaluation of concept 2 (RPF (average) = 52,8) 9.3 Risk evaluation for the selected concept

Due to the high number of requirements for the screener, a suitable subset of customer requirements was chosen to prove the proposed method.

At a first step, all customer / market requirements have to be linked if the functionality will influence the requirement (marked with an “x”; e.g. “breath alcohol value printed” and “Energy supply: durability”).

If RPF [= occurrence x severity] is above the agreed level of RPF>25, the risk evaluation will continue with the objective of mitigation, otherwise it is on an acceptable value, and the risk evaluation is terminated.

The evaluation shows 81 values of 123 [=65,9%] higher than 25. This leads to a reduction for further investigation of 42 values.

Page 115 of 163 9 Validation of the concept

Alarm low Measuring at low Accu Technologie oder Komponenten / technology or components / TRS [A] Housing Design Stability Weight Handling Size Energy supply Durability Stable current battery temperature exchangeable vs. Kunden- oder Marktanforderungen / Customer- or market requirements / CRS [B] [A] 4 7 3 5 6 7 [A] 5 3 4 5 6 3

Functional Requirement What should the product provide to the user? [B] 8 x 32 48 x 40 24 40 48 FA Le level of breath alcohol indicated 8 x 48 x 24 x 40 x 48 Functional Requirement Which services should be provided? [B] 6 x 24 21 42 49 x 30 15 20 25 15 FA Ba x breath alcohol value printed 5 x 15 x 20 x 25 FA Ba mouth piece chanceable 7 x 21 x 42 x 49 FA Ba x breath alcohol value displayed 5 x 15 x 20 x 25 x 15 Functional Requirement Input - Processing - Output [B] 8 x 32 42 x 40 23 31 38 48 24 FA Ba breath specimen accepted 7 x 42 x 21 x 28 x 35 x 42 x 21 FA Le concentration measured 9 x 27 x 36 x 45 x 54 x 27 FA Le level of alcohol indicated 7 x 21 x 28 x 35 Functional Requirement Behaviour in certain situations? [B] 6 FA Ba alarm indicates a positiv alcohol test 7 FA Le user reminded when calibration period is expired 5 Non-Functional Requirements Reliability [B] 6 x 24 17 x 30 17 30 36 NFA Ba x Service life 10 years 5 x 15 x 15 x 25 x 30 NFA Ba x 20.000 cycles in lifetime 5 x 15 x 15 NFA Le failure rate < 0,5% 7 x 21 x 21 x 35 x 42 Non-Functional Requirements Look & Feel [B] 7 x 28 49 x 35 21 28 42 NFA Be x shirt pocket size 7 x 49 x 21 NFA Be modern design 7 x 49 x 21 x 28 x 42 Non-Functional Requirements Useability [B] Non-Functional Requirements Performance / Efficiency [B] 9 x 36 27 x 45 27 45 54 NFA Be x 12 month measuring performance (certified) 9 x 27 x 27 x 45 x 54 Non-Functional Requirements Operation / Environmental Conditions [B] 9 x 45 27 45 NFA Le not condensing (operation at 10 to 100% rel. humidity) 9 x 27 x 45 Non-Functional Requirements Maintainability / Alterability [B] Non-Functional Requirements Portingability / Transferability [B] Non-Functional Requirements Safety Requirements [B] Non-Functional Requirements Correctness [B] Non-Functional Requirements Flexability [B] Non-Functional Requirements Scalability [B] Non-Functional Requirements Boundary Conditions [B] Non-Functional Requirements Approval [B] 10 x 40 70 50 60 70 x 50 30 50 60 NFA Ba CE certificate 10 x 70 x 50 x 60 x 70 x 30 x 50 x 60

Figure 52: Total evaluation of RPF (detailed; figure 1 of 2)

no mainte- firm ware display service display cali- battery opening for Accu status readable at dark readable at alarm for Technologie oder Komponenten / technology or components / TRS [A] Maintenance Display nance required update by user request bration requ. exchance service eng. displayed condition bright condition positive test vs. Kunden- oder Marktanforderungen / Customer- or market requirements / CRS [B] [A] 6 4 6 7 5 4 4 [A] 7 3 4 5 6

Functional Requirement What should the product provide to the user? [B] 8 x 48 40 32 x 56 24 32 40 48 FA Le level of breath alcohol indicated 8 x 40 x 32 x 24 x 32 x 40 x 48 Functional Requirement Which services should be provided? [B] 6 x 36 23 30 35 25 x 42 15 20 25 30 FA Ba x breath alcohol value printed 5 x 20 x 30 x 35 x 15 FA Ba mouth piece chanceable 7 x 28 FA Ba x breath alcohol value displayed 5 x 20 x 30 x 35 x 25 x 15 x 20 x 25 x 30 Functional Requirement Input - Processing - Output [B] 8 x 48 31 46 54 38 x 56 23 28 35 42 FA Ba breath specimen accepted 7 x 28 x 42 x 49 x 35 x 21 FA Le concentration measured 9 x 36 x 54 x 63 x 45 x 27 FA Le level of alcohol indicated 7 x 28 x 42 x 49 x 35 x 21 x 28 x 35 x 42 Functional Requirement Behaviour in certain situations? [B] 6 25 28 35 42 FA Ba alarm indicates a positiv alcohol test 7 x 28 x 35 x 42 FA Le user reminded when calibration period is expired 5 x 25 Non-Functional Requirements Reliability [B] 6 x 36 23 34 35 25 20 20 x 42 21 28 35 42 NFA Ba x Service life 10 years 5 x 20 x 30 x 35 x 25 x 20 x 20 NFA Ba x 20.000 cycles in lifetime 5 x 20 x 30 x 20 NFA Le failure rate < 0,5% 7 x 28 x 42 x 21 x 28 x 35 x 42 Non-Functional Requirements Look & Feel [B] 7 x 42 35 28 x 49 21 28 35 42 NFA Be x shirt pocket size 7 x 21 x 28 x 35 x 42 NFA Be modern design 7 x 35 x 28 Non-Functional Requirements Useability [B] Non-Functional Requirements Performance / Efficiency [B] 9 NFA Be x 12 month measuring performance (certified) 9 Non-Functional Requirements Operation / Environmental Conditions [B] 9 x 63 27 36 45 54 NFA Le not condensing (operation at 10 to 100% rel. humidity) 9 x 27 x 36 x 45 x 54 Non-Functional Requirements Maintainability / Alterability [B] Non-Functional Requirements Portingability / Transferability [B] Non-Functional Requirements Safety Requirements [B] Non-Functional Requirements Correctness [B] Non-Functional Requirements Flexability [B] Non-Functional Requirements Scalability [B] Non-Functional Requirements Boundary Conditions [B] Non-Functional Requirements Approval [B] 10 NFA Ba CE certificate 10

Figure 53: Total evaluation of RPF (detailed; figure 2 of 2) At this stage, the transition of all values with RPF >25 into the FMEA form can be started.

Page 116 of 163 9 Validation of the concept

mögliche Fehlerfolge B möglicher Fehler mögliche Fehlerursache Vermeidungsmaßnahmen A AxB Nr. noac Potential Effect(s) of Failure S Potential Failure Mode Potential Cause(s) Preventive Actions O SxO

1 AA 1 What should the product provide to the user? 11 High severity, impact to vital level of breath alcohol not Housing: Handling 2 function, safety aspects 8 indicated 6 48

Energy supply: stable 3 8 current 5 40 Energy supply: Measuring 4 8 at low temperature 6 48 Maintenance: display cali- 5 8 bration requirements 5 40 Maintenance: battery 6 8 exchange 4 32 Display: readable at dark 7 8 condition 4 32 Display: readable at bright 8 8 condition 5 40 Display: alarm for positive 9 8 test 6 48 10 AA 2 Which services should be provided? Middle severity, little to breath alcohol value not Maintenance: firm ware 11 middle impact to function, 5 printed update by user 6 30 reduction of comfort options Maintenance: display 12 5 service request 7 35 High severity, impact to vital mouth piece not changeable Housing: Handling 13 function 7 6 42 Housing: Size 14 7 7 49 Maintenance: no 15 7 maintenance required 4 28 Middle severity, little to breath alcohol value not Maintenance: firm ware 16 middle impact to function, 5 displayed update by user 6 30 reduction of comfort options Maintenance: display 17 5 service request 7 35 Display: alarm for positive 18 5 test 6 30 19 AA 3 Input - Processing - Output High severity, impact to vital breath specimen not Housing: Handling 20 function 7 accepted 6 42 Energy supply: Alarm low 21 7 battery 4 28 Energy supply: Stable 22 7 current 5 35 Energy supply: Measuring 23 7 at low temperature 6 42 Maintenance: no mainte- 24 7 nance required 4 28 Maintenance: firm ware 25 7 update by user 6 42 Maintenance: display 26 7 service request 7 49 Maintenance: display cali- 27 7 bration requ. 5 35 28 AA 4 Behaviour in certain situations?

Figure 54: Transfer of evaluation of RPF into FMEA form (just severity and occurrence) Based on this transfer, it must be investigated, if there is a possibility to reduce RPF by a certain action to reduce the severity and / or occurrence. If there is a solution and the RPF is now below the risk level of 25, it can be accepted and it further evaluation is not needed.

Page 117 of 163 9 Validation of the concept

B Maßnahme mögliche Fehlerfolge B möglicher Fehler mögliche Fehlerursache Vermeidungsmaßnahmen A AxB x lfd B A RPZ

Nr. noac A Recommended

Potential Effect(s) of Failure S Potential Failure Mode Potential Cause(s) Preventive Actions O SxO r Nr. S O RPN r action(s) o

1 AA 1 What should the product provide to the user? 0 K High severity, impact to vital level of breath alcohol not Housing: Handling 2 function, safety aspects 8 indicated 6 48 48

Energy supply: stable 3 8 current 5 40 40 Energy supply: Measuring 4 8 at low temperature 6 48 48 Maintenance: display cali- 5 8 bration requirements 5 40 40 Maintenance: battery 6 8 exchange 4 32 32 Display: readable at dark 7 8 condition 4 32 32 Display: readable at bright 8 8 condition 5 40 40 Display: alarm for positive redundant system 9 1 8 test 6 48 x 8 2 16 10 AA 2 Which services should be provided? Middle severity, little to breath alcohol value not Maintenance: firm ware 11 middle impact to function, 5 printed update by user 6 30 30 reduction of comfort options Maintenance: display 12 5 service request 7 35 35 High severity, impact to vital mouth piece not changeable Housing: Handling easy use clip 13 2 function 7 6 42 x system 7 3 21 14 7 Housing: Size 7 49 49 Maintenance: no 15 7 maintenance required 4 28 28 Middle severity, little to breath alcohol value not Maintenance: firm ware 16 middle impact to function, 5 displayed update by user 6 30 30 reduction of comfort options Maintenance: display 17 5 service request 7 35 35 Display: alarm for positive 18 5 test 6 30 30 19 AA 3 Input - Processing - Output High severity, impact to vital breath specimen not Housing: Handling 20 function 7 accepted 6 42 42 Energy supply: Alarm low 21 7 battery 4 28 28 Energy supply: Stable 22 7 current 5 35 35 Energy supply: Measuring 23 7 at low temperature 6 42 42 Maintenance: no mainte- 24 7 nance required 4 28 28 Maintenance: firm ware 25 7 update by user 6 42 42 Maintenance: display 26 7 service request 7 49 49 Maintenance: display cali- 27 7 bration requ. 5 35 35 28 AA 4 Behaviour in certain situations?

Figure 55: FMEA form and recommended actions to reduce risk [RPF] For the residual items in the risk analysis with RPF>25, the risk evaluation will be extended by the detection score. The question “Can the cause or the occurrence of the potential failure mode determined before the specification will be finalized?” is raised and scored. The RPF will be supplemented by the RPN (Risk Priority Number). Now the agreed level to take action is RPN > 125.

Page 118 of 163 9 Validation of the concept i B Maßnahme l mögliche Fehlerfolge B möglicher Fehler mögliche Fehlerursache Vermeidungsmaßnahmen A AxB x lfd B A RPF a Entdeckungsmaßnahmen E RPZ

Nr. noac A Recommended V Veri Vali

Potential Effect(s) of Failure S Potential Failure Mode Potential Cause(s) Preventive Actions O SxO r Nr. S O RPF r Current Design Controls D RPN r

action(s) e o V

1 AA 1 What should the product provide to the user? 11 K AA_1 High severity, impact to vital level of breath alcohol not Housing: Handling Usability test 2 function, safety aspects 8 indicated 6 48 48 x 2 96

Energy supply: stable Durability test 3 8 current 5 40 40 x 2 80 Energy supply: Measuring Cold Chamber test 4 8 at low temperature 6 48 48 x 2 96 Maintenance: display cali- Durability test 5 8 bration requirements 5 40 40 x 3 120 Maintenance: battery Handling test 6 8 exchange 4 32 32 x 3 96 Display: readable at dark Usability test 7 8 condition 4 32 32 x 2 64 Display: readable at bright Usability test 8 8 condition 5 40 40 x 2 80 Display: alarm for positive redundant system 9 1 8 test 6 48 x 8 2 16 0 10 AA 2 Which services should be provided? 0 Middle severity, little to breath alcohol value not Maintenance: firm ware alarm for firm ware 11 middle impact to function, 5 printed update by user 6 30 x 2 update 5 4 20 0 reduction of comfort options Maintenance: display Usability test 12 5 service request 7 35 35 x 2 70 High severity, impact to vital mouth piece not changeable Housing: Handling easy use clip 13 3 function 7 6 42 x system 7 3 21 0 Housing: Size Handling test 14 7 7 49 49 x 3 147 Maintenance: no Usability test 15 7 maintenance required 4 28 28 x 2 56 Middle severity, little to breath alcohol value not Maintenance: firm ware alarm for firm ware 16 middle impact to function, 5 displayed update by user 6 30 x 2 update 5 4 20 0 reduction of comfort options Maintenance: display Usability test 17 5 service request 7 35 35 x 2 70 Display: alarm for positive redundant system 18 1 5 test 6 30 x 8 2 16 0 19 AA 3 Input - Processing - Output 0 High severity, impact to vital breath specimen not Housing: Handling Usability test 20 function 7 accepted 6 42 42 x 2 84 Energy supply: Alarm low Usability test 21 7 battery 4 28 28 x 2 56 Energy supply: Stable Durability test 22 7 current 5 35 35 x 2 70 Energy supply: Measuring Cold Chamber test 23 7 at low temperature 6 42 42 x 2 84 Maintenance: no mainte- Usability test 24 7 nance required 4 28 28 x 2 56 Maintenance: firm ware alarm for firm ware 25 2 7 update by user 6 42 x update 5 4 20 0 Maintenance: display Usability test 26 7 service request 7 49 49 x 2 98 Maintenance: display cali- Usability test 27 7 bration requ. 5 35 35 x 2 70 28 AA 4 Behaviour in certain situations?

Figure 56: FMEA, including evaluation of severity, occurrence and detection The mode of detection is classified into the categories verification and validation. Vali- dation is required when the test will be performed fulfilling customer / market requirements [CRS]. In the case of verification, the test will confirm internal specifications [TRS].

If the final score in the FMEA exceeds the critical level of RPN > 125, a corrective action must be defined. Meeting the Quality Gate [PR5] all RPNs should be at an acceptable level.

Page 119 of 163 9 Validation of the concept i r B l Maßnahme r Maßnahme x a

mögliche Fehlerfolge B möglicher Fehler mögliche Fehlerursache Vermeidungsmaßnahmen A AxB lfd B A RPF Entdeckungsmaßnahmen E RPZ o lfd B A E RPZ

Nr. noac A V Veri Vali Recommended K Recommended i

Potential Effect(s) of Failure S Potential Failure Mode Potential Cause(s) Preventive Actions O SxO r Nr. S O RPF r Current Design Controls D RPN Nr. S O D RPN r

action(s) e action(s) o V

Energy supply: stable Durability test 3 8 current 5 40 40 x 2 80 Energy supply: Measuring Cold Chamber test 4 8 at low temperature 6 48 48 x 2 96 Maintenance: display cali- Durability test 5 8 bration requirements 5 40 40 x 3 120 Maintenance: battery Handling test 6 8 exchange 4 32 32 x 3 96 Display: readable at dark Usability test 7 8 condition 4 32 32 x 2 64 Display: readable at bright Usability test 8 8 condition 5 40 40 x 2 80 Display: alarm for positive redundant system 9 1 8 test 6 48 x 8 2 16 0 10 AA 2 Which services should be provided? 0 Middle severity, little to breath alcohol value not Maintenance: firm ware alarm for firm ware 11 middle impact to function, 5 printed update by user 6 30 x 2 update 5 4 20 0 reduction of comfort options Maintenance: display Usability test 12 5 service request 7 35 35 x 2 70 High severity, impact to vital mouth piece not changeable Housing: Handling easy use clip 13 3 function 7 6 42 x system 7 3 21 0 Housing: Size Handling test Check for alternative 14 1 63 7 7 49 49 x 3 147 housing 7 3 3 Maintenance: no Usability test 15 7 maintenance required 4 28 28 x 2 56 Middle severity, little to breath alcohol value not Maintenance: firm ware alarm for firm ware 16 middle impact to function, 5 displayed update by user 6 30 x 2 update 5 4 20 0 reduction of comfort options Maintenance: display Usability test 17 5 service request 7 35 35 x 2 70 Display: alarm for positive redundant system 18 1 5 test 6 30 x 8 2 16 0 19 AA 3 Input - Processing - Output 0 High severity, impact to vital breath specimen not Housing: Handling Usability test 20 function 7 accepted 6 42 42 x 2 84 Energy supply: Alarm low Usability test 21 7 battery 4 28 28 x 2 56 Energy supply: Stable Durability test 22 7 current 5 35 35 x 2 70 Energy supply: Measuring Cold Chamber test 23 7 at low temperature 6 42 42 x 2 84 Maintenance: no mainte- Usability test 24 7 nance required 4 28 28 x 2 56 Maintenance: firm ware alarm for firm ware 25 2 7 update by user 6 42 x update 5 4 20 0 Maintenance: display Usability test 26 7 service request 7 49 49 x 2 98 Maintenance: display cali- Usability test 27 7 bration requ. 5 35 35 x 2 70 28 AA 4 Behaviour in certain situations?

Figure 57: Complete evaluation, incl. corrective action for aspects RPN > 125 This constitutes the final point of the risk evaluation and it is thus finalized.

It is emphasized at this stage, that the risk mitigation at the stage determination of customer / market requirements is critical to success and that the further steps in the risk analysis pave the way to a stable design of the product.

The maturity of the product during the development process can be measured as described in 8.1.2 at each quality gate.

Page 120 of 163 10 Discussion, Conclusions and Outlook

10 Discussion, Conclusions and Outlook

10.1 Approach to the Discussion

The literature survey to identify research gaps and identify useful methods for the development of the comprehensive risk management tool in technical development has identified a significant number of potentially relevant studies. At this stage, the relevance and suitability of the most relevant publication is discussed with reference to the tool described in the preceding sections, and with reference to the requirements for tool set up in the first sections to this thesis.

10.2 Discussion of claims A and B (see 1.6):

To start with it is noted from the entries into Table 1 and Table 2 that, the proposed technique Is the only one (and therefore the first one) that fulfills requirements A and B simultaneously:

The papers (Porananond, D. 2013), (Oehmen, J. 2010), and (Hillson, D. 2005) and are reasonably comprehensive in their scope but they are mainly literature reviews, therefore, they do not lend themselves to application in a practical corporate environment, since they do not describe or apply any of the methods in detail to be instrumental for application in practice. Nevertheless, these papers are instrumental to be reasonably sure that no relevant paper that relates to the subject of this thesis has been missed. The publication by Sumner (Sumner, M. 2000) describes the history and mathematical background for financial risk management, and is also a useful literature review, however with no direct applicability to an organizational R&D environment, since the data gathering and the mathematics would be too time consuming and complicated.

The documents (Huchzermeier, A. 2001), (Gunther McGrath, R.D. 2004), (Murray- Webster, R. et al. 2010), (Verdu, A. et al. 2012), (Hughes, D.R. 2009), (Murray-Web- ster, R. 1999), (Murray-Webster, R. 1997), (Benaroch, M. 2002) all focus on risk management and risk treatment by the real options theory. Therefore, they implicitly cover all aspects relevant for an enterprise including mitigation of risk, and they are therefore “by construction” implicitly integrated into the tool, in the sense of requirement A).

Page 121 of 163 10 Discussion, Conclusions and Outlook

So, it is very doubtful whether any of the papers is suitable in practice, both due to the rather involved mathematics and the relatively general approach to identifying risk, in particular in identifying technology risks most of the papers have little to offer in concrete drill down and systematic identification of risks rooted in the technology of the new products. This does not mean that the method proposed here is at variance with real options theory since it includes identification of alternatives in case of excessive risk, and implicitly fulfills at least some essential features of the real options theory. The method to work out the least risk paths differ, of course. Which one is better in terms risk analysis and risk mitigation will be considered in connection with the detailed discussion of claim C) below.

Similar arguments can be found for the papers (Abrahamsen, E.B. et al. 2012), (Kutsch, E. et al. 2005) and (Cetindamar, D. et al. 2013) which are employing the Ex- pected Utility Theory in connection with risk management. So, similar to the previous case, it is doubted that requirement B) can be fulfilled by the proposed approach to risk management in projects. In the same vein, paper (Badri, A. et al. 2012) which employs the analytical hierarchy process to evaluate occupational and environmental risks in projects cannot fulfill requirement B, but A. An interesting concept introduced in this paper is risk concentration, an alternative method for risk prioritization.

Furthermore, several other mathematical methods are proposed for risk analysis and prioritization, such as the simulation of Petri Net (Profit, A. et al. 2014), Fuzzy Logic (Takalo, S.K. 2014, (Zhang, Z. et al. 2011)) to evaluate the FMEA scores, Baysian Network and/or Montecarlo simulations (Gourc, D. 2006, Hu, Y. 2012), and SPC analysis of risk (Hamza, S.E.A. 2009). It can be assumed that they are, in terms of mathe- matic rigidity an improvement over traditional FMEAs, but again it is doubtful whether they are suitable for routine application in practice (with the exception of (Hamza, S.E.A. 2009)).

There are several papers which have a very similar approach to risk evaluation as this work, namely to evaluate risks by traditional FMEAs ((Porananond, D. 2014), (Koivu, L. 2014), (de Azevedo Degen, E. u.a. 2010), (Oehmen, J. 2010), (ARUNDACHAWAT, P. 2012), (Hamza, S.E.A. 2009), (Kaplan, S. et al. 2001), (Alhassan, I.B. 2013),

Page 122 of 163 10 Discussion, Conclusions and Outlook

(Segismundo, A. et al. 2008), (Hadi-Vencheh, A. et al 2012)). The comprehensiveness of the scope, however varies widely:

• (Koivu, L. 2014) and (de Azevedo Degen, E. u.a. 2010) focus only evaluate technical and quality risks • (Hamza, S.E.A. 2009) only evaluates cost by SPC • (Porananond, D. 2014), (Oehmen, J. 2010), (ARUNDACHAWAT, P. 2012), (Alhassan, I.B. 2013) and (Segismundo, A. et al. 2008) also evaluate project risks • Only one primary research paper, (Porananond, D. 2014), evaluates in addition organizational and market risks in the food industry. Although not from technical development of products, it is regarded as sufficiently close to be relevant for the research questions addressed in this paper.

(Hosseini, M.R. 2014), (Carbone, T.A. 2004) and (Mastroianni, S.A. 2011) employ a slightly more sophisticated FMEA, which they term RFMEA, like this work they consider the risk score (product of severity time occurrence) and the risk priority number (RPN) which in our opinion gives a better focus and therefore prioritization on the really substantial risks, i.e. a better risk prioritization. (Hosseini, M.R. 2014) and (Mastroianni, S.A. 2011) is as comprehensive in the scope as (Porananond, D. 2014), (Carbone, T.A. 2004) does not cover project and organizational risks, but cost and time risks instead.

All of these tools are, in our opinion, relatively easy to use and suitable for practical application.

Discussion of claim C):

The claim that the proposed method identifies potential risk more effectively than methods that do not use standardized QM tools (e.g. the PDCA cycle, FTA, FMEA, QFD, ISO 9001 etc.) is substantiated by the following considerations:

• FMEAs have been found to be certainly effective to identify many technical risks before they actually occur. The proposed quantification using the risk score RPF in

Page 123 of 163 10 Discussion, Conclusions and Outlook

combination with the risk priority number RPN is the centerpiece of the tool developed in this thesis. By construction, the methods cover in detail potential technical risks in a systematic manner. The standardized QM-based identification and risk assessment tools for project management, cost and organization risk also ensures a well-structured, effective and efficient risk identification of potential risks • Using instruments like surveys, (structured or unstructured) interviews, informal expert discussions, other tools rooted in social and economics science are certainly useful too, but we maintain that such methods cannot be neither as effective nor efficient in exploring and prioritizing technical risks, most likely the same is true for project and organizational and cost risks. • Discussion of claim D):

Regarding the last item of this discussion, whether the results and conclusions from the validation of the tool in the Dräger case study be generalized (item C), the case studies in the papers that employ FMEA – based risk analysis and prioritization constitute further evidence that our method can be generalized (with the caveat that the extension to the wide scope and our unique evaluation methods are only proven in one case study so far).

These are in detail:

In a case study for the Swedish medical high tech company Elektra (Alhassan, I.B. 2013) it is proven that an FMEA based risk methodology which employs spreadsheet tools, as in this work, concludes that the model can identify and aggregate individual risks including their visualization of easier risk disposition and prioritization. It is reported that the model had been tested in connection with an ongoing project and it is concluded that it helped to reduce uncertainty regarding the project’s schedule and cost uncertainty. In other words, the model significantly improved risk management for that project. So the finding in (Alhassan, I.B. 2013), in a similar company as the Dräger company provide some evidence that the findings is this project are not a chance event but can be generalized.

Case studies with similar QM based risk management in other industry sectors have been reported:

Page 124 of 163 10 Discussion, Conclusions and Outlook

The publication by Segismundo (Segismundo, A. et al. 2008) is a well-structured case study from the Brazilian automotive industry, another technology area with fierce com- petition regarding quality and cost. For two projects, it could be shown that there was a significant reduction in the number of iterations at the project planning phase (and therefore planning time) and also a reduction in the number of prototypes needed for qualification for production. A further significant result was that resource allocation was improved among different programs.

(Hosseini, M.R. 2014) used the same idea, namely to combine the risk score and the risk priority number RPN and tested it in the Australian industry. It was found that due to better risk analysis and risk prioritization it was possible in the one project it was possible to reduce the number of critical risks from four to zero by the more structured risk management approach than had previously been customary in that company. Sim- ilar encouraging results had also been reported for another project.

A case study in the food industry (Porananond, D. 2014) also came to the conclusion that the new FMEA-based approach led to a better risk management. Another case study in the electronics industry (Carbone, T.A. 2004) also had a positive and encouraging outcome.

Limitations of Research

So, the studies which employed similar techniques for risk management in different industries and different geographical locations (and therefore company cultures) proved that the FMEA and QM based results for risk management is an improvement over relatively unstructured risk management processes.

While this is certainly encouraging, it has to be conceded that the evidence for gener- alizability is still not very strong. Replicas in other industries and for more projects are needed to further validate the proposed approach. In particular, it is expected that the applicability of the success can be affected by the organizational environment of the company under study, likewise the field technology and industry sector can have a significant influence. Also, there may be a significant impact by different cultures in different geographical regions.

Page 125 of 163 10 Discussion, Conclusions and Outlook

10.3 Actual situation: Research on Risk Management in the Engi- neering and Technology Context

By far the most common and most important technique for technical risk assessment in engineering technology is the failure mode and effects analysis (FMEA) (Vieregge 2008). As explained, the technique results in a systematic identification of potential failure of technical items and / or process steps and it includes an assessment of the resulting risks. It is restated, that the assessment is not mathematically stringent, therefore can only be regarded as semi quantitative in the absolute determination of risk. All the same, the method has been used in practice for many decades and has proven its usefulness in ranking different risks. Such a ranking is the basis for decisions where a risk mitigation is needed and where not. An important practical aspect is that the method has to be standardized regarding the assignment of metrics for the risk, which has proven to be possible in practice.

In technology development and production, the FMEA technique has been used both in technology development and in production process technology development in a “stand-alone” manner, i.e. independent of each other.

It has, to the best of our knowledge (both from the technical literature and from industry experience) never been used for the comprehensive integrated development proces- sor, which includes all phases of the technology and associated product development from the first concept phase to the qualification of the first product for mass production.

Since the time of submission of the PhD Thesis and defense in January 2016, a research group of Laboratory for Machine Tools and Production Engineering, RWTH Aa- chen, Fraunhofer Institute for Production Technology IPT, Aachen, and Fach- hochschule Suedwestfalen, Hagen, has published a technique which addresses the risk assessment over the complete product and technology development. Similar to the method developed in this PhD project the maturity of the product and the technology is regularly assessed is the basis for the decision regarding risks and the disposition of identified risks.

Page 126 of 163 10 Discussion, Conclusions and Outlook

A comparison with the technique called “Rapido” reveals that the basic idea ideas are similar: In both techniques, the objective is to provide a risk management and indicators regarding the maturity. However, while the Rapido technique only investigates the risks and maturity at certain development phases, and not during the concept phase, this phase is covered in this project and, constitutes, as argued in previous sections, a very significant risk in addition to the risks that may materialize during the actual development phase. In the tool developed in this project risks and the maturity of both in all phases of the project can be assessed, including the early concept phase.

Another important difference is that the Rapido technique defines a new risk assessment metric which implies additional training, whereas the technique developed in this project uses the standard FMEA, so that no training is needed. Furthermore, it can be safely assumed that since the FMEA is a routine technique which is regularly used in many quality engineering tasks that the results will be more consistent.

More differences are compiled in Table 12.

Summing up, three remarks are in order:

1) Since such a development project for a risk management tool in product development with a similar objective had been initiated in parallel to this PhD project and that it had been funded from public resources, constitutes strong evidence that there must have been a perceived need for such a tool. 2) The direct comparison of the approach of the two techniques shows that the approach is relatively similar, although the two projects were independent of each other, this in our opinion is at least an indicator of the soundness of the approach. 3) Without a direct comparison in one company or even one project any conclusion regarding which technique is the better one is difficult. We judge that a more comprehensive approach (applicability in the concept phase) and using the standard method FMEA as the core risk management has advantages. Whether the alternative risk assessment method in Rapido gives additional or more meaningful insights which would compensate or overcompensate the disadvantages of using a new unfamiliar technique cannot be concluded at this stage.

Page 127 of 163 10 Discussion, Conclusions and Outlook

RAPIDO Thesis Filed of Method for determining the degree of maturity in Method for determining the degree of maturity of Application product development at discrete breakpoints in products in the development process. the development project.

Personnel Costs It is a method by which a group of experts assess The risk is determined by means of the FMEA the risks to meet the requirements of the market / valuation, which is introduced and proven in the customer => Qualification of the participants. majority of companies with their own product development.

The differentiation in the risk assessment (risk = BxA); Only evaluation of the detection E at BxA> 25, reduces the effort in the FMEA work.

Learning This requires the additional introduction of a There is no additional training required, according method, independent of the actual development to the FMEA method. system, including training of the participants.

Integration A risk assessment is carried out by experts outside The degree of maturity is determined by means of the development project. There is not necessarily the evaluation results of the design FMEA. Thus, a reference or link to the design FMEA. the result is directly linked to the FMEA results and can show the level of maturity between the quality gates in real time. Comprehensive Rapido starts only once all the requirements by the The risk assessment can already be applied when assessment of market/customer have been met processing the development roadmap: Which risks in the whole technologies have to be considered for new value chain products - which risks are to be expected.

Validity The assessment is based on new (subjective) Continuous employment with the FMEA and the factors: proven and accepted valuation leads to reliable - significance index (B) results. - uncertainty of prediction - uncertainty of requirement/risk control Software solution A software solution was developed. Software support is currently provided by a “home- made” excel solution.

Robustness of the Technology-independent expert team; With technology trusted team. results Impartiality.

Integrated into the development process - important aspects are not lost.

Table 12: Comparison of “RAPIDO“ and the concept of this thesis

Page 128 of 163 10 Discussion, Conclusions and Outlook

10.4 Feedback from users

This thesis was carried out in close cooperation with Dräger Safety, Lübeck. The quality management as well as the product development were mainly involved. In the discussions, the method was planned, applied, checked and further improved according to the IM: PULS procedure.

At the end of this project, the participants were asked about their perception about the outcome (Original Letter in the appendix of this thesis):

Question to the users at Dräger: Evaluate the benefit of the "Functional Analysis_Validation" tool with regard to the application in the Dräger Safety product development from the point of view of product quality and reliability!

Answers of the users (for original letter, see appendix): • The tool is immediately applicable into the development process, without any preliminary work or training and it fits into the landscape of existing methods without any problems • Integration into the existing tools is possible • The tool support the concept decision o By early consideration of functional and technological risks o By requiring a minimum degree of maturity of the concepts • Documentation of the concept decision • Increase of the FMEA - process efficiency o Implementation of the structure and function analysis o Prioritization of functions during an early project phase o Systematical reduction of work scope by means of risk analysis and thus focusing on the relevant risks is achieved o Reduction of the volume of the tests for the excluded negligible risks

Page 129 of 163 10 Discussion, Conclusions and Outlook

• Outlook o It is expected that further pilot runs in least two new development projects will reveal further potential benefits of the method as well as additional optimization needs o After successful implementation of the additional pilot projects an integration into the existing tool landscape and standards processes will have to be implemented This feedback confirms, that according to the perception of the users the concept of this thesis is a progress in risk management of product development:

• Immediately applicable in the development process without any preliminary work or training • Fits into landscape of existing methods without any problem • Is useful starting in the conception phase (from technology, concept phase to start of production) • Delivers documentation along decisions • Increases the efficiency of the FMEA-process. In the perception of the people involved in this project, the new concept described in this thesis is useful for the daily business in product development and quality assurance.

10.5 Work reduction

One of the defined scopes of this thesis was to reduce the effort in using the FMEA method. The reduction was reached by limiting the evaluation of the detection metric only to those cases where the product RPF (see 5.1) of severity [S] and occurrence [O] is more than 25. This means: work reduction by leaving out the detection evaluation when RPF is below 25.

To quantify the expected improvement of efficiency, 3 product development projects of different maturity level were analyzed in terms of the work reduction. The complete FMEA was analyzed with respect to:

1. How many individual ratings of risks were carried out in total 2. How many individual ratings were scored RPF < 25 (see matrix: yellow / green) 3. Calculation of percentage of results with RPF < 25

Page 130 of 163 10 Discussion, Conclusions and Outlook

Dräger Alcotest 3820

“The Dräger Alcotest® 3820 offers responsible drivers a reliable way to test their breath alcohol and gives them the assurance of being legal to drive. This is ensured by precise measurement technology identical to that used by the police: over 30 million breath alcohol tests a year.

Figure 58: Dräger Alcotest 3820 photo and short description of the functionality as downloaded from the Dräger website

] 10 1 1 1 O [

e c 9 n e r r

u 8 c c O 7 1

6 4 1 1 3

5 1 5 3 7

4 6 1 6 3

3 2 21 3 14 9

2 1 16 1 14 17

1 1 1 12345678910 Severity [S]

Dräger alcotest 3820 56 Percentage <25: 55% 24 # evaluations: 145 65

Table 13: Evaluation of Percentage RPF < 25 for the Dräger Alcotest 3820 55% of ratings need no additional evaluation of detection.

Page 131 of 163 10 Discussion, Conclusions and Outlook

1. Oxygen Self Rescuers Oxy 3000

“Robust and always under control: the oxygen self- rescuers Dräger Oxy® 3000 and 6000 MK II are designed to handle the harshest conditions. The Safety Eye provides an additional level of security: the status window allows the user to assess whether the device is operational within seconds.

Figure 59: Oxygen Self Rescuers Oxy 3000 photo and short description of the functionality as downloaded from the Dräger website ]

O 10 11 [

e c

n 9 e r r u

c 8 c O 7

6 1 1 1

5 1 4 6

4 2 2 10

3 3 8 1 8

2 4 3 2 11

1 1 2 12345678910 Severity [S]

Oxygen Self Rescuers Oxy 3000 10 Percentage <25: 22% 8 # evaluations: 82 64

Table 14: Evaluation of Percentage RPF < 25 22% of ratings need no additional evaluation of detection.

Page 132 of 163 10 Discussion, Conclusions and Outlook

2. Gas detection X-am 8000

“Dräger X-am® 7000 is the solution for the simultaneous and continuous measurement of up to five gases. It is the ideal companion in a variety of applications where the reliable detection of oxygen, toxic and combustible gases and vapors are necessary.

Figure 60: Gas detection X-am 7000 (previous version) photo and short description of the functionality as downloaded from the Dräger website ]

O 10 1 3 [

e c

n 9 e r r u

c 8 c O 7

6 1

5 1 2 1 1

4 2 1 14

3 4 5 5 3 11 1

2 2 8 4 4 29 5 1

1 2 1 4 1 4 12345678910 Severity [S] Gas detection X-am 8000 (first level) 69 Percentage <25: 71% 17 # evaluations: 121 35

Table 15: Evaluation of Percentage RPF < 25

71% of ratings need no additional evaluation of detection.

Page 133 of 163 10 Discussion, Conclusions and Outlook

In addition, evaluations on the next product component level were performed: instrument case, printed circuit board. ] ] O 10 O 10 [ [

e e c c n 9 n 9 e e r r r r u u c 8 c 8 c c O O 7 2 7

6 6

5 2 3 5

4 2 8 4 1

3 4 2 3 2 3 4

2 1 8 2 2 2 4 8

1 1 1 12345678910 12345678910 Severity [S] Severity [S]

X-am 8000 (body) X-am 8000 (conductor board) 10 Percentage <25: 40% 8 Percentage <25: 46% 4 # evaluations: 35 3 # evaluations: 24 21 13

Table 16: Evaluation of Percentage RPF < 25 40% (instrument case) / 46% (printed circuit board) of ratings need no additional evaluation of detection.

The implication of this result is, that the effort for FMEA will be reduced significantly, of the order of a factor of 2 (see 10.4 feedback). Meaningless discussions for topics with low risk are thus avoided. Rather, the discussions remain focused on the critical aspects and substantial risks of product development.

10.6 Conclusions and Outlook

This thesis provides a comprehensive integrated solution for the risk evaluation in product development, which represents a significant improvement in comparison to methods in use or techniques published so far, verification of the methods was achieved by comparison with the specified objectives in the first sections of this thesis.

Page 134 of 163 10 Discussion, Conclusions and Outlook

Evidence has been presented that the method is simple enough to be used in practice, and is effective in determining risks, in particular in the case study carried out. Thus, also the validation of the method has been addressed.

Arguments have been presented that the findings in this thesis can be generalized and transferred to other technologies and industries.

At the same time, the thesis gives rise to a wide range of questions, which should / can be answered by further research work.

To sum up this review of the literature:

To the best of our knowledge, the work laid out in this thesis is the only one that has full coverage of technical, project, organizational, cost / time and market risks in an integrated way. An important tool to ensure this is to employ the EFQM model to both organizational and project risks. The usage of these relatively simple and standardized tools quality tools and models in the ISO 31 000 standard ensures that the proposed method can be operationalized relatively easy.

All the same, important questions / new topics have surfaced and result from this work:

10.6.1 Using the solution for software development The risk evaluation in software development is extremely critical due to its high complexity. It appears likely that the method of this thesis can be adapted for software development:

Severity = Outcome = Customer / Market Requirements for the software application

Occurrence = Maturity of the software modules applied

The RPF indicates the potential risk of the software, also monitored by the RPF-Matrix (see Figure 47).

10.6.2 Project application: fulfilment of project goals (project-audit) In accordance to the auditing system in the company, project audits can be and should be performed on a periodical basis. Depending on the total number of projects the audit

Page 135 of 163 10 Discussion, Conclusions and Outlook

plan should cover a representative sample of projects. They should be performed by trained and experienced auditors. An audit questionnaire aligned to the proposed evaluation method in this thesis is recommended.

A scientific question is to be answered in this context:

• Is there evidence of correlation between audit results and project success? • Furthermore, is the correlation better if the proposed project audit method is used instead of the usual one. • If that is the case, this would constitute validation of the improved project audit concept.

10.6.3 Maturity of project environment in a given company (DPEA) As described in 3.3

DPEA (Deutscher Project Excellence Award, owner: German Society for Project Man- agement) is an accepted method to check the maturity of a project management system. By using a prescribed procedure, the evaluation will result in one numerical value describing the maturity. Performing in a defined frequency, it will show the absolute level (benchmark with other companies available) and the trend from year to year.

The scientific question to be answered: Is there evidence of a correlation between the maturity of the project management system and audit results / the project success?

10.6.4 Maturity of organizational the environment (EFQM) On a higher organizational company-wide level, the EFQM Society provides a screening method to evaluate the maturity of the complete company in all facets. Similar to the DPEA, the evaluation ends up with one value, the Radar scoring as explained in section 3.3 (DPEA as a tool for Project Excellence). An absolute numerical score or level, its trend over the years and as a benchmark is an output of the EFQM method.

The scientific question to be answered: Is there evidence of correlation between the DPEA and the EFQM evaluation, with and without the application of the proposed risk evaluation tool?

Page 136 of 163 10 Discussion, Conclusions and Outlook

10.6.5 Steering Committee How can the projects be controlled in a more effective and efficient manner? The traditional method, as explained in the first sections of this thesis, is by checks lists and / or consensus reached in meetings of the complete Steering Committee. The short- coming of ticking off checklists have been mentioned. Using our proposed tool, the status of the project can be characterized and controlled by agreed indicators. It should be investigated in more detail; which project steering is the best fit for the company.

The scientific question that arises:

What is the best project controlling in terms of efficiency and effectiveness; including indictors for project steering. What has not been investigated in this thesis is e.g. whether the development of the risk indicators over time can be followed up by SPC- like monitoring, and whether the SPC method lends itself to determining when a project is under control (according the Western Electric rules), and if improvements in risk indicators over time are statistically significant, in other words whether they are just chance events or due to a special improvement actions.

Page 137 of 163

11 Bibliography

11.1 Literature

Ab Rahman, M.N. 2015, ‘Statistical process control: Best practices in small and medium Enterprises (D25)’, Maejo Int. J. Sci. Technol. 2015, 9(02), 193-208; doi: 10.14456 / mijst.2015.15

Abrahamsen, E.B. et al. 2012, ‘Why risk acceptance criteria need to be deﬁned by the authorities and not the industry? (D15)’, Reliability Engineering and System Safety 105 (2012) 47–50

Adner, R. et al. 2002, ‘What is not a Real Option: Identifiying Boundaries for the Appli- cation of Real Options to Business Strategy (D48)’, Wharton Business School, Phila- delphia

Al-Ghussein, Ali 2015, ‘Risk in Concept Phase of Product Development’, Masterthesis, Brandenburgische Technische Universität Cottbus / Senftenberg

Alhassan, I.B. 2013 (date of pdf), ‘INTEGRATED MODEL FOR PROJECT RISK & UNCERTAINTY MANAGEMENT (D30)’, Master’s Degree Thesis Project, The Royal Institute of Technology, KTH, Stockholm, Sweden

ARUNDACHAWAT, P. 2012, ‘The Development of Methods to Estimate and Reduce Design Rework (D22)’, Cranfield University School of Applied Sciences PhD. Thesis

Aven, T. 2006, ‘On the Precautionary Principle, in the Context of Different Perspectives on Risk (D18)’, University of Stavanger, Stavanger, Norway de Azevedo Degen, E. et al 2010, ‘PROPOSTA DE UM MÉTODO PARA AVALIAÇÃO DE RISCOS EM FMEA CONSIDERANDO O CUSTO DE OCORRÊNCIA DO MODO DE FALHA (D19)’, XXX ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO. Maturidade e desafios da Engenharia de Produção: competitividade das empresas, condições de trabalho, meio ambiente. São Carlos, SP, Brasil, 12 a15 de outubro de 2010.

Page 139 of 163 11 Bibliography

Deming, W. Edwards, 2000, ‘Out of the crisis’, MIT-CAES, Cambridge (MA), ISBN 978- 0-2625-4115-2

Badri, A. et al. 2012, ‘Proposal of a risk-factor-based analytical approach for integrating occupational health and safety into project risk evaluation (D12)’, Accident Analysis and Prevention 48 (2012) 223– 234

Bahr, N.J. 2014, ‘System Safety Engineering and Risk Assessment: A Practical Ap- proach’, Boca Raton, FL, Taylor & Francis Group, LLC, ISBN 978-1-4665-5160-2

Bartholomäus, Mathias 2006, ‚Möglichkeiten der Visualisierung von Risikobewertun- gen‘, Diplomarbeit, Universität Magdeburg Lehrstuhl für Informatik

Benaroch, M. 2002, ‘Managing Information Technology Investment Risk: A Real Op- tions Perspective (D51)’, Syracuse University, School of Management

Bonnal, P. et al. 2002, ‘The life cycle of technical projects (D37)’, ARTICLE JANUARY 2002; http://www.researchgate.net/publication/230594632

Boulter, L. et al. 2005, ‚Auswirkungen einer wirksamen Implementierung von Excellence-Strategien im Unternehmen auf die Schlüsselleistungsergebnisse‘, The Centre of Quality Excellence, the University of Leicester

Cagno, E. et al. 2008, ‘Dynamic analysis of project risk (D53)’, ARTICLE in INTERNA- TIONAL JOURNAL OF RISK ASSESSMENT AND MANAGEMENT JANUARY 2008

Carbone, T.A. / Tippett, D.D. 2004, ‘Project Risk Management Using the Project Risk FMEA (D04)’, Engineering Management Journal Vol. 16 No. 4 December 2004

Cetindamar, D. et al. 2013, ‘Strategic Planning Decisions in the High Tech Industry (D27)’, Springer Verlag, London, ISBN 978-1-4471-4886-9

Chaudhuri, A. (2013). Supply chain risk assessment during new product development. International Journal of Production Research (Volume 51, Issue 10, 2013)

Cooper, D. 2014, ‘Project Risk Management Guidelines: Managing Risk with ISO 31000 and IEC 62198 (D40)’, ISBN: 978-1-118-82031-5

Page 140 of 163 11 Bibliography

Chrysler, Ford, GM 2008, ‘FMEA – Potential Failure Mode and Effects Analysis’, ISBN 978-1-60534-136-1

Crook, D.L. 1990, ‘Evolution of VLSI reliability engineering’, In Proc. Int. Rel. Symp.

DGQ 2008, ‚FMEA – Fehlermöglichkeits- und Einflussanalyse‘, DGQ, Frankfurt, ISBN 3-410-32276-4

Dictionary 1970, ‚The Advanced Learner´s Dictionary of Current English‘, OXFORD UNIVERSITY PRESS, London

Dräger 2012, ‘New Product Development Process Handbuch / Manual’, Lübeck, V16

Dräger 2010, ‚Reliability Handbuch / Manual‘, Lübeck, V01

Dräger 2011, S. Wagner / S. Rittemann‚ Software-Qualitätssicherung – Strategische Untersuchung (Präsentation)‘, Lübeck

Dräger 2015, O. Harnack, ‘Concept Phase Improvement (Präsentation), Company presentation, Lübeck, March 05th, 2015

EFQM 2012, ‚EFQM EXCELLENCE MODELL‘, Brüssel, ISBN 978-90-5236-671-5

Giebler, M. 2010, ‚Wertsteigerung durch Qualitätsmanagement‘, Kassel University Press GmbH, Kassel, ISBN 978-3-86219-034-8

Evens, D. 2013, ‚Risikointelligenz – Wie wir richtige Entscheidungen treffen‘ Droemer Verlag, München, ISBN 978-3-426-27560-3

Gigerenzer, G. 2013, ‚Risiko – Wie man die richtigen Entscheidungen trifft‘, C. Bertels- mann Verlag, München, ISBN 978-3-570-10103-2

Gourc, D. 2006, ‘Vers un modèle général du risque pour le pilotage et la conduite des activités de biens et de services: Propositions pour une conduite des projets et une gestion des risques integrées (D14)’, Institut National Polytechnique de Toulouse

GPM Deutsche Gesellschaft für Projektmanagement e.V. 2009, ‚ICB - IPMA Compe- tence Baseline - in der Fassung als Deutsche NCB – National Competence Baseline

Page 141 of 163 11 Bibliography

Version 3.0 der PM-ZERT Zertifizierungsstelle der GPM e.V‘, Nürnberg, ISBN 978-3- 924841-41-6

Gunther McGrath, R.D. 2004, ‘Real Options Reasoning and a New Look at the R&D Investment Strategies of Pharmaceutical Firms (D43)’, ARTICLE in STRATEGIC MAN- AGEMENT JOURNAL JANUARY 2004

GWU 1993, ‘The George Washington University’, The comparison of the Deming Prize and the Baldrige Award, Washington D.C.

Hadi-Vencheh, A. et al 2012, ‘Failure Mode and Eﬀects Analysis Using Data Envelop- ment Analysis (D57)’, Int. J. Industrial Mathematics Vol. 4, No. 3, Year 2012 Article ID IJIM-00167,

Hampe, P. 2015, ‚Chance und Risiko – die Revision der ISO 9001 (Präsentation) (D33)‘, VQZ-Bonn e.V. – Zertifizierungsstelle

Hamza, S.E.A. 2009, ‘Monitoring and controlling design process using control charts and process sigma (D26)’, Business Process Management Journal, Vol. 15 Iss 3 pp. 358 - 370

Hassanzadeh, S. et al. 2012, ‘Integration of human factors in project uncertainty management, a decision support system based on fuzzy logic (D11)’, European Safety and Reliability Conference, Sep 2011, Troyes (France), France. pp.661-669, 2011, https://hal.archives-ouvertes.fr/hal-00745283

Hillson, D. 2006, ‘Integrated Risk Management As A Framework For Organisational Success (D05), Originally published as a part of 2006 PMI Global Congress Proceed- ings – Seattle Washington

Hillson, D. 2005, ‘A comparative review of risk management standards (D35)’, ARTI- CLE in RISK MANAGEMENT OCTOBER 2005

Hillson, D. 2003, ‘Research paper: Using a Risk Breakdown Structure in project management (D55)’, HENRYSTEWART PUBLICATIONS 1472–5967 Journal of Facilities Management VOL. 2 NO. 1 PP 85 – 97

Page 142 of 163 11 Bibliography

Hosseini, M.R. 2014, ‘Riskmanagement in research and development (R&D) projects: The case of South Australia (D02)’, http://www.researchgate.net/publication/271705468

Hossen, A. 2015, ‘CONCEPTUALISING RISK AND UNCERTAINTY IN TRANSPORT POLICY (D36)’, 27 - 28th August National University of Ireland/ Galway

Hu, Y. 2012, ‘Intelligent Analysis Model for Outsourced Software Project Risk Using Constraint-based Bayesian Network (D17)’, JOURNAL OF SOFTWARE, VOL. 7, NO. 2, FEBRUARY 2012

Huchzermeier, A. 2001, ‘Project Management Under Risk: Using the Real Options Ap- proach to Evaluate Flexibility in R&D (D31)’, ARTICLE in MANAGEMENT SCIENCE JANUARY 2001

Hughes, D.R. 2009, ‘Evaluating real options for mitigating technical risk in public sector R&D acquisitions (D46)’, ARTICLE in INTERNATIONAL JOURNAL OF PROJECT MANAGEMENT MAY 2009

ILEP e.V. 2012, ‚Deutscher Excellence Preis: Ergebnisband 2012‘, Oberursel

Jonen, A. 2007, ‚Semantische Analyse des Risikobegriffs: Strukturierung der betriebs- wirtschaftlichen Risikodefinitionen und literaturempirische Auswertung (D56)‘. Bei- träge zur Controlling-Forschung, No. 11, Provided in Cooperation with: Technische Universität Kaiserslautern, Lehrstuhl für Unternehmensrechnung und Controlling

Kamiske, G. F. et al. 2012, ‚Handbuch der QM-Methoden‘, Carl Hanser Verlag, Mün- chen, ISBN 978-3-446-42019-9

Kaplan, S. et al. 2001, ‘Fitting Hierarchical Holographic Modelling into the Theory of Scenario Structuring and a Resulting Refinement to Quantitative Definition of Risk (D28)’, Risk Analysis, Vol. 21, No. 5, 2001

Koivu, L. 2014, ‘Measuring supply chain Vulnerability – A case Study (D09)’, Bache- lor´s Thesis Tampere University of Applied Sciences

Page 143 of 163 11 Bibliography

Koubek, Anni et al. 2015, ‚Praxisbuch ISO 9001:2015‘, Carl Hanser Verlag, München, ISBN 978-3-446-44523-9

Kuhlmann, A. 1981, ‚Einführung in die Sicherheitswissenschaft‘, TÜV Rheinland GmbH, Köln, ISBN 3-528-08495-2

Kujawski, E. 2002, ‘Selection of technical risk responses for efficient contingencies (D29)’, Systems Engineering Department Engineering Division Lawrence Berkeley Na- tional Laboratory Berkeley, California 94720

Kutsch, E. et al. 2005, ‘Intervening conditions on the management of project risk: Deal- ing with uncertainty in information technology projects (Kutsch, E. et al. 2005)’, Inter- national Journal of Project Management 23 (2005) 591–599

Laurent, R. et al. 2012, ‘Assessment of the methods FMEA and DRBFM applied in the new product development process of an auto parts manufacturer (Portuguese) (D10)’, Gest. Prod., São Carlos, v. 19, n. 4, p. 841-855, 2012

Marmier, F u.a. 2012, ‚STRATEGIC DECISION-MAKING IN NPD PROJECTS AC- CORDING TO RISK: APPLICATION TO SATELLITES INTEGRATION AND TEST PROJECTS (D08)’, https://hal.archives-ouvertes.fr/hal-00728580

Marques, G. et al. 2010, ‘Multi-criteria performance analysis for decision making in project management (D54)’, International Journal of Project Management 29 (2010) 1057 – 1069

Mastroianni, S.A. 2011, ‘Risk Management among Research and Development Pro- jects (D24)’, A Thesis Presented to the Graduate and Research Committee of Lehigh University in Candidacy for the Degree of Master of Science

McNeil, A.J. et al. 2005, ‚Quantitative Risk Management (D32)’, published by Princeton University Press

Mourato, J.A. 2011, Quality Management System of the Polytechnic Institute of Por- talegre (D23)’, PROCEEDINGS of 3rd International Conference Institutional Strategic Quality Management in Higher Education ISQM 2011 Sibiu, Romania July 14 – 16, 2011

Page 144 of 163 11 Bibliography

Murray-Webster, R. et al. 2010, ‘Risk management reconceived: reconciling economic rationality with behavioural tendencies (D44/D47)’, Journal of Project, Program & Port- folio Management Vol 1 No 1 (2010) 1-16

Murray-Webster, R. 1999, ‘FALLING FORWARD: REAL OPTIONS REASONING AND ENTREPRENEURIAL FAILURE (D49)’, Academy of Management Review, 1999 Vol. 24 No. 1, 13-30

Murray-Webster, R. 1997, ‘A REAL OPTIONS LOGIC FOR INITIATING TECHNOL- OGY POSITIONING INVESTMENTS (D50)’, Academy of Management Review, 1997 Vol. 22 No. 4, 974-996

Oehmen, J. 2010, ‘Risk Management in Lean PD (D21)’ MIT: LAI Paper Series “Lean Product Development for Practitioners”

Pfeiffer, T. / Schmitt, R. 2010, ‘Qualitätsmanagement - Strategien, Methoden, Techni- ken’, Hanser Verlag, München, ISBN 978-3-446-41277-4

Porananond, D. / Thawesaengskulthai, N. 2014, ‘Risk Management for New Product Development Projects in Food Industry (D03), Journal of Engineering, Project, and Production Management 2014, 4(2), 99-113

Porananond, D. / Thawesaengskulthai, N 2013, ‘PROJECT RISK MANAGEMENT FOR NEW PRODUCT DEVELOPMENT (D01)’, Proceedings of the 4th International Conference on Engineering, Project, and Production Management (EPPM 2013)

Profit, A. et al. 2014, ‘MANAGING RISK IN SUPPLY CHAIN: A FRAMEWORK FOR SUPPLY CHAIN RISK MITIGATION ECISION-MAKING (D13)’, 6th International Con- ference on Operations and Supply Chain Management, Bali, 2014

Renn, O. 2008, ‘Risk Governance (D38)’, Taylor & Francis Ltd, London, ISBN 978-1- 84407-292-7

Richter, K. / Rost, J.-M. 2015, ‘Komplexe Systeme‘, S. Fischer Verlag, Frankfurt, ISBN 978-3-59630-305-2

Page 145 of 163 11 Bibliography

Romeike, Frank et al. 2013, ‚Erfolgsfaktor Risiko-Management 3.0‘ Springer Fach- medien, Wiesbaden, ISBN 978-3-8349-3339-3

Saatweber, Jutta 2011, ‘Kundenorientierung durch Quality Function Deployment, Düs- seldorf’, Symposion Publishing GmbH, Düsseldorf, ISBN 978-3-86329-429-8

Sanchez, H. 2009, ‘Risk Management Applied to Projects, Programs, and Portfolios (D34)’, ARTICLE in INTERNATIONAL JOURNAL OF MANAGING PROJECTS IN BUSINESS JANUARY 2009

Schmitt, R. et al. 2011, ‘New Approach for Risk Analysis and Management in Medical Engineering (D39)’, ISBN 978-1-4244-8856-8

Segismundo, A. et al. 2008, ‘Failure mode and effects analysis (FMEA) in the context of risk management in new product Development A case study in an automotive company (D52)’, Polytechnic School of the University of Sa ˜ o Paulo – USP, Sa ˜ o Paulo, Brazil

Seyedhoseini, S.M. / Hate, M.A. 2009, ‘Two-Pillar Risk Management (TPRM): A Ge- neric Project Risk Management Process (D06/D07)’, Transaction E: Industrial Engi- neering Vol. 16, No. 2, pp. 138-148 Sharif University of Technology, December 2009

Sherer, S.A. 1995, ‘The Three Dimensions of Software Risk: Technical, Organiza- tional, and Environmental (D42)’, Proceedings of the 28th Annual Hawaii International Conference on System Sciences - I995

Sommerhoff, B. 2013, ‚Entwicklung eines Transformationskonzeptes für den Beruf Qualitätsmanager‘, Shaker Verlag, Aachen, ISBN 978-3-8440-0890-6

Spang, K., Özcan, S. 2009, ‚GPM-Studie 2008/2009 zum Stand und Trend des Pro- jektmanagements‘, Deutsche Gesellschaft für Projektmanagement e.V. GPM

Sullivan, Lawrence P. 1986, ‘Quality Function Deployment’, Quality progress

Sumner, M. 2000, ‘Risk factors in enterprise-wide/ERP projects (D41)’, School of Busi- ness, Southern Illinois University, Campus Box 1106, Edwardsville, IL 62026, USA

Page 146 of 163 11 Bibliography

Takalo, S.K. 2014, ‘Banking Service Quality appraisal through Failure mode and effect analysis (A Case Study: Central Melli Bank of Rafsanjan) (D16)’, international Journal of Scientific Management and Development Vol.3 (3), 970-976 March (2015)

Vanini, U. 2012, ‚Risikomanagement Grundlagen – Instrumente – Unternehmenspra- xis‘, Schäffer-Poeschel Verlag, Stuttgart, ISBN 978-3-7910-3126-2

VDI-GSP 1995, ‚Wertanalyse: Idee – Methode – System‘, VDI Verlag, Düsseldorf, ISBN 3-18-401432-0

Verdu, A. et al. 2012, ‘The moderating effect of environmental uncertainty on the relationship between real options and technological innovation in hightech firms (D45)’, ARTICLE in TECHNOVATION SEPTEMBER 2012

Vieregge, R. / Haberl, R. 2008 ‚FMEA Was soll´s? Der Frust mit der FMEA und seine Ursachen‘, Shaker Verlag, Aachen, ISBN 978-3-83227-323-1

Vieregge et al. 2014, ‚Controlling und Qualität – Leitfaden für Controlling und Quali- tätsmanagement zur Erzielung wirtschaftlicher Excellence‘, Haufe-Lexware GmbH&Co.KG, Freiburg, ISBN 978-3-648-06313-2

Vieregge, R. / Mäder-Schwarz, H. 2015, ‚Leitbilder - Eine komplexe Zukunftsgestaltung handhabbar gemacht‘, In: TÜV-Media (Hrsg.) "Der Qualitätsmanagement-Berater", Köln, Juni 2015, Kapitel 12201, S. 1-28, ISBN 978-3-8249-1915-4

Völz, H. 2010, ‚Vorlesungsmaterial „Kompliziert – komplex – Komplexität“‘, TU Berlin

Wallmüller, E. 2011, ‘Software Quality Engineering’, Hanser Verlag, München, ISBN 978-3-446-40405-2

Weis, U. 2011, ‚Risikomanagement nach ISO 31000‘, Kissing, WEKA Media GmbH & Co.KG, ISBN 978-3-8276-2967-8

Wittmann, Jürgen, Bergholz, Werner 2016, ‚Introduction to Quality Management in the Semiconductor Industry‘, Charleston (USA), ISBN 978-1-5350-4634-3

Page 147 of 163 11 Bibliography

Wißler, Frank Eugen 2005, ‚Ein Verfahren zur Bewertung technischer Risiken in der Phase der Entwicklung komplexer Serienprodukte‘, Dissertation, Universität Stuttgart Fakultät für Maschinenbau

Wohland, G., Wiemeyer, M. 2007, ‚Denkwerkzeuge der Höchstleister‘, Murmann Ver- lag, Hamburg, ISBN 978-3-86774-020-3

Zentis, T., Czech, A., Prefi, T., Schmitt, R. 2011, ‚Technisches Risikomanagement in produzierenden Unternehmen‘, Apprimus Verlag, Aachen, ISBN 978-3-86359-038-3

Zhang, Z. et al. 2011, ‘Risk prioritization in failure mode and effects analysis under uncertainty (D58)’, Expert Systems with Applications 38 (2011) 206–214

11.2 Standards

AIAG 2008, ‘Potential Failure Mode and Effects Analysis (FMEA)’, 4th Edition

AS/NZS ISO 31000:2009 Risk Management AS / NZS 4360:2004 (supersedes AS/NZS 4360:2004)

ISO 2015, ‘The ISO Survey of Management System Standard Certifications – 2014 Executive summary (http://www.iso.org/iso/iso_survey_execu- tive-summary.pdf, v2014)

ISO 9000:2015-09 2015, ‘Quality management systems - Fundamentals and vocabu- lary’, Beuth Verlag, Berlin

ISO 9001:2015-11 (2015), ‚Qualitätsmanagementsysteme – Anforderungen‘, Berlin, Beuth Verlag

ISO 9004:2009-11 2011, ‚Leiten und Lenken für den nachhaltigen Erfolg einer Organi- sation – Ein Qualitätsmanagementansatz‘, Beuth Verlag, Berlin

ISO 10006:2003-06 “Quality management systems - Guidelines for quality management in projects”

ISO 21500:2012-09 “Guidance on project management”

Page 148 of 163 11 Bibliography

ISO 31000:2009-11, ‚Risikomanagement - Allgemeine Anleitung zu den Grundsätzen und zur Implementierung eines Risikomanagements‘

DIN 69900:2009-01 "Projektmanagement - Netzplantechnik; Beschreibungen und Be- griffe“ (project management, network planning, descriptions and terms)

DIN 69901-1:2009-01 “Projektmanagement - Projektmanagementsysteme - Teil 1: Grundlagen“ (basics)

DIN 69901-2:2009-01 “Projektmanagement - Projektmanagementsysteme - Teil 2: Prozesse, Prozessmodell“ ("processes, process model")

DIN 69901-3: :2009-01 “Projektmanagement - Projektmanagementsysteme - Teil 3: Methoden“ („methods“)

DIN 69901-4:2009-01 “Projektmanagement - Projektmanagementsysteme - Teil 4: Daten, Datenmodell“ („data, data model“)

DIN 69901-5:2009-01 “Projektmanagement - Projektmanagementsysteme - Teil 5: Begriffe“ („terms“)

VDA Band 4 2011; ‚Sicherung der Qualität in der Prozesslandschaft‘

11.3 Internet sources

Stern 2012, ‚…. deutschlands-schlimmste-skandalbauten‘, www.Stern.de

Netzzeitung 2005, ‚BMW will Entwicklungszeiten reduzieren‘, www.Netzzeitung.de philognosie 2008, ‘Complexity vs. Complicatedness’, www.philognosie.net

Kano model 2015, ‘About the Kano Model’, www.kanomodel.com/about-the-kanomodel/

Page 149 of 163

12 Appendix

12.1 DRÄGER at focus

In the following, downloads from the Dräger company website at November 2015 relevant for the context of this thesis will be documented

Figure 61: Some facts about Dräger

Page 151 of 163 12 Appendix

Figure 62: Risk management is important due to application

Figure 63: Risk management is important due to application

Page 152 of 163 12 Appendix

Figure 64: Risk management is important due to application

Figure 65: Risk management is important due to application

Page 153 of 163 12 Appendix

12.2 Evaluation score in connection with choosing the best concept

The Concept Phase, where the best concept has to be chosen can be explained along a short instructive example: Building a house.

Figure 66: Concept Phase – Example: Building a House (1/4)

Figure 67: Concept Phase – Example: Building a House (2/4)

Page 154 of 163 12 Appendix

Figure 68: Concept Phase – Example: Building a House (3/4)

Figure 69: Concept Phase – Example: Building a House (4/4)

Page 155 of 163 12 Appendix

12.3 Flowcharts of risk management processes

In the following , flow charts for the core processes for the risk management developed in this thesis are represented in standard flow charts which are used in connection with process management in a corporate environment.

E:= trifft notw end. Entscheidung Scope: Abbreviation Terms / definitions D:= Kümmerer für Durchführung CRS:= customer requirement spec M:= es besteht TRS:= technical requirement spec Mitw irkungspflicht USP:= unique selling point I:= ist immer zu informieren E D M I risk matrix Document Comment CRS Fill in the requirements using the basic legal regulations structure of the Excel file. requirements to be market requirements identified branch regulations Excel file basic structure requirements 1. classification along w ith Kano model Excel file 2. define USP requirements basic structure 3. identification of functional or non- classified functional requirement (see Value Analysis)

TRS Potential cause can be based on: Excel file • technology is not under controlled potential causes basic structure conditions or filled in • a module or component has no stable design

no complete?

yes table: occurrence evaluate potential risk for potential effect table: severity (severity) and potential cause risk Excel file (occurrence) => RPF for technology evaluation y

g When RPF > 25 or occurrence (O) > 7 the o Excel file l

o expected risk to high. Therefore some

n high risk? investigation is necessary.

h no

c (RPF > 25 or RPN > 25 is a common level (no standard,

e O > 7) t no specification); just 2 times medium risk

r (5x5=25). o f

yes

n e.g. feasibility study, testing, investigation, o i

t research. studies a If there is no chance for risk reduction, the u

l performed and risk technology may not be the best fit. a mitigation potentials v e

evaluated k s i

R portfolio Accepted technology should be documented in a (internal) portfolio; incl. the test results / description. approved technology registered

Figure 70: Flowchart of product development: risk evaluation for technology (E:= makes decision, D:= execution, M:= contribution, I:= to be informed)

Page 156 of 163 12 Appendix

n table: occurrence evaluate potential risk for potential effect i (severity) and potential cause m table: severity r (occurrence) => RPF for each concept. e dynamical matrix t risk

e Compare risk level by dynamical matrix. evaluated Excel file d

t p e c

n dynamical matrix the determined risk level is just an indicator

o Excel file for the decision. It´s not the one and only C criterion. May me a more risky concept is decision on concept the favourite due to e.g. time to market. made

Figure 71: Flowchart of product development: concept determination

E:= trifft notw end. Entscheidung Scope: Abbreviation Terms / definitions D:= Kümmerer für Durchführung CRS:= customer requirement spec M:= es besteht TRS:= technical requirement spec Mitw irkungspflicht USP:= unique selling point I:= ist immer zu informieren E D M I risk matrix Document Comment Excel file to start FMEA process only results RPF > 25 [S x O] or O > 7 w ill be transferred into the FMEA form. high risk? no accepted risk, no (RPF > 25 or RPF > 25 is a common level (no standard, further action required O > 7) no specification), just 2 times medium risk (5x5=25). yes Veri-Vali-plan If the test is appropriate to detect the potential cause it´s a verification; if the test is regarding the failure mode, it´s a tests validation. defined Bringing all tests together, a verification- validation-plan is generated!

table: detection RPN = RPF x D = S x O x D is evaluated.

detection evaluated A E

M RPN > 125 is a common level (no standard,

F no specification) high risk? no (RPN > 125 or O > 7)

yes Excel file Risk mitigation can be done by choosing a more efficient test method or by use of another more stable technology. risk mitigation performed

dynamical matrix starting product development the risk level is set; the risk level at the end is also defined. At the planned quality gates the progress dynamical matrix provides a range of risk. monitored Thus the progress of the product design is highlighted.

Figure 72: Flowchart of product development: FMEA – risk evaluation

Page 157 of 163 12 Appendix

12.4 New Product Development Process at Dräger

Page 158 of 163 12 Appendix

Figure 73: New Product Development Process (Dräger, German)

Page 159 of 163 12 Appendix

12.5 Feedback from users

Figure 74: Feedback from users (1/2)

Page 160 of 163 12 Appendix

Figure 75: Feedback from users (2/2)

Page 161 of 163 12 Appendix

12.6 Acknowledgment

For the last 3 years+ I have used the opportunity to put a cap stone on my working life. In a way, this has been “back into the future”. I got the benefit from my professional experience I gathered throughout my working life as an engineer, application engineer and quality manager. It was like a patchwork putting things together to a bigger picture, from pieces which appeared to be isolated before.

In the end, I moved back to the beginning: My first experience with risk evaluation was a training at Volkswagen which contained the FMEA method - the FMEA method has fascinated me until the present day. Therefore, it was a godsend to find partners to put everything together for a dissertation. The partners, Jacobs University, Prof. Dr. Wer- ner Bergholz, and Dräger Safety, Dr. Bernd Siemensmeyer, gave me the opportunity to do so.

For me it was a pleasure to work with both partners. Numerous discussions, and various inputs which resulted from such intensive discourses contributed to make this thesis happen. Many thanks!

Special mention deserves the protracted discussion with my friend Rainer Haberl who gave me motivation and perspectives for my dissertation. He very regrettably died in 2015 and I miss him and our discourses.

Many thanks to my friend Werner Bergholz as an excellent motivator, as an always available sparring partner with a huge range of knowledge. I thank you for all the in- spiring debates we had about technical and human aspects of risk management.

I would also like to thank Professors Julia Bendul, Jens Froese and Wilfried Lux for their valuable contributions and support to make my PhD project successful.

And there is significant number of people who provided me with their knowledge and helped me to learn:

Bernd Siemensmeyer, Oliver Harnack, Peer Groß, Thomas Pernot, Thomas Rode- waldt, Michael Dietrich, Stefan Barten, Mathias Dehmke, Eric Kiel, Steffen Rittemann, Andrea Schröder, Stefan Wagner, Peter Schüler from the Dräger Company.

Page 162 of 163 12 Appendix

Maybe I forgot to mention someone, please accept my thanks to all the support I received.

And at the end I want to say thanks to my family. They accepted that I had to spend a lot of time on this PhD thesis. The spare time has been just too little in the last 3 years. Many thanks for all your patience!

Page 163 of 163