Design and validation of a comprehensive model for risk ...

Computer Science & Electrical Engineering

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

by

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


Prof. Dr. Julia Bendul Professor of Logistics


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

0 Statutory Declaration

of 163

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 ___________________________________________________________

0 Abbreviations

of 163

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

0 Abbreviations

of 163

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

0 Abbreviations

of 163

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

jektgestaltung

0 Glossary

of 163

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 opera-

tions (internal customers) or the end customer experience (external cus-

tomer).“

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 occur-

rence 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 organ-

ization 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 require-

ments“

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 charac-

teristics, deadlines and cost“

Control Board (Dräger 2012, page 15): The Control Board is - if necessary - a com-

mittee from the project sponsor that takes over for the project, the project man-

agement tasks and responsibilities of the project principal. The members of

0 Glossary

of 163

the Control Board are selected so that they represent the most important peo-

ple 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)"

0 Table of figures

of 163

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

0 Table of figures

of 163

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

0 Table of figures

of 163

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 66: Concept Phase – Example: Building a House (1/4) ............................... 154



0 Tables

of 163


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



0 Abstract

of 163

Abstract

Shorter development time of new products and a shift from complicatedness to com-

plexity (see Glossary: complex vs. complicated) requires new thinking in product de-

velopment.

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, or-

ganization.

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 technol-

ogy 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 de-

crease 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

0 Abstract

of 163

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

0 Abstrakt

of 163

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 wer-

den. 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

0 Abstrakt

of 163

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

0 Contents

of 163

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

0 Contents

of 163

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

0 Contents

of 163

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

0 Contents

of 163

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

1 Motivation and Problem Description

of 163


1.1 General consideration regarding the differentiation between re-

search and development

The objective of this PhD project has been the development of an innovative risk man-

agement 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 prod-

uct development:

1. "Product Maturity": quantifiable, reproducible maturity metrics in projects to as-sess 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 eve-ryday 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 po-

tentially most relevant theories for this decision step in the risk management process


of 163

• 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 prob-

ability 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 dan-

ger, 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


of 163

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.


of 163

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 mate-

rialized.

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 devel-

opment, it has been the primary concern that a new product has the desired function-

ality and project management has been focused almost exclusively on the technical

aspects (Vieregge / Haberl 2008, page 30, 5.2). In addition to the technical develop-

ment 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.


of 163

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.

Figure 1: List of risks

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.

Inition Kind of riskViolation of existing

lawSignificant effect Risk occurrence Risk severity Risk level

very low very high medium

medium medium medium

high very high very high

very

high1 0 1 2 0

very

high4

very

high0

very

high0 0 0 0 0

very

high0

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

low 0 3 0 0 0very

low 6very

low 8very

low 1 4 2 0 0very

low 9

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

Risk level after corrective

action

occurrence =>

seve

rity

=>

occurrence =>

seve

rity

=>

Initial evaluationRisk level at initial

evaluation

Expected risk level after

correctiv actionEvaluation after corrective action


of 163

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 fi-

nancial) 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 ac-

tions.

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 associ-

ated 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 re-

producible and traceable and that it facilitates derivation of corrective actions to miti-

gate unacceptable risks.


of 163

The following section describes well-known and industry practiced standardized ap-

proaches 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 manage-

ment, 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 initi-

ation, definition, planning, control and completion of projects")

The product development has the goal of developing an outcome that meets the ob-

jectives of the technical specifications (which describes the quality (set of characteris-

tics) 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 develop-

ment 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 ac-

count 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 man-

agement, 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 de-

pendent on the tools used and the manner of control during this initial step and not only


of 163

on the appropriate project management during the course of the actual product devel-

opment. 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 devel-

oped 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)


Teil 2: Prozesse, Prozessmodell“ (processes, process model)

• DIN 69901-3: :2009-01 “Projektmanagement - Projektmanagementsysteme -

Teil 3: Methoden“ (methods)


Teil 4: Daten, Datenmodell“ (data, data model)


Teil 5: Begriffe“ (terms)

• ISO 10006:2003-06 “Quality management systems - Guidelines for quality man-

agement in projects”

• ISO 21500:2012-09 “Guidance on project management”


of 163

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 spe-

cific 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 / avoid-

ance 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.


of 163

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 man-

agement 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 sig-

nificant 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 compli-

cated 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 prod-

uct development is about mastering the complexity of projects, not the complicated-

ness. 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 com-

plicated 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 deci-

sions 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).


of 163

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 com-

plexity 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 organiza-

tional 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 com-

plexity, which according to the author’s perception are particularly important in the con-

text 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 de-

velopment, 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-


of 163

System certified by this standard), or ISO/TS 16949). As mentioned earlier, the indus-

try 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 de-

velop a method to assess also the organizational risks in a more quantitative and there-

fore traceable and reproducible way.

A major problem that often occurs in the product development is the discrepancy be-

tween the planned objectives for the project costs and project times and the develop-

ment 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 com-

prehensive 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 there-

fore far too narrow for the objective of this work.

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

Technical

risks

Project

risks

e.g.

scheduling

risk

cost risk

quality risk


of 163

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.)


of 163

For completeness, we mention that software development has a special role in project

management. The common risk assessment tool for software development in our opin-

ion 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 manage-

ment 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 man-

agement, 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 struc-

tured 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.


of 163

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

no. Publication Scope including Risk Identification Risk Analysis

mentioned in

this thesis

Qual ity/

Techno

logy

Project Organi-

zation

cost /

time

Market FMEA Analytical

Hirarchy

process

Game Th expecte

uti li ty

theory

control

charts, fuzzy

logic

Real

Options

Theory

Monte Carlo,

Baysian N

etc

yesPorananond

2013yes yes yes ? yes yes yes yes yes yes yes

yes Hosseini 2014 yes yes yes yesyes,

RFMEA

yesPorananond

2014yes yes yes yes yes

yes Carbone 2004 yes yesyes,

RFMEA

Hil lson 2006 yes yesyes,

strateg

Seyedhoseini

2009yes yes

Seyedhoseini

2009yes yes

Marmier 2012 yes yes

yes Koivu 2014 yes yes

Laurent 2012 yes

Hassanzadeh

2012

yes Badri 2012 yes yes yes

yes Profit 2014FMECA,

Petri

petrinet &

simulation

yes Gourc 2006 yes own math

yesAbrahamsen

2012yes

yes Takalo 2014 service qu.

yes Hu 2012 yes yes

Aven 2006

yesde Azevedo

Degen 2010yes yes

yes Kutsch 2005 yes

yes Oehmen 2010 yes yes yesyes

valueyes

yesArundachawat

2012yes yes yes

Mourato 2011 yes yes

yesMastroianni

2011yes yes yes yes RFMEA

Ab Rahman

2015

yes Hamza 2009 yes

yesCetindamar

2013yes

yes Kaplan 2001 yes

Kujawski 2002

yes Alhassan 2013 yes yes yes

yesHuchzermeier

2001yes

yes McNeil 2005 financ RM

Hampe 2015

Sanchez 2009

yes Hil lson 2005 yes yes

Hossen 2015

Bonnal 2002 yes yes

Renn 2008

Schmitt 2011 yes yes yes? yes iFMEA

Cooper 2014

yes Summer 2000

Sherer 1995 yes yes environ

m.

yesGunther

McGrath 2004yes

yesMurray-Webster

2010yes

yes Verdu 2012 yes

yes Hughes 2009 yes

Murray-Webster

2010

Adner 2002 yes

yesMurray-Webster

1999yes

yesMurray-Webster

1997yes

yes Benaroch 2002 yes

yesSegismundo

2008yes yes yes

Cagno 2008

Marques 2010

Hil lson 2003

Jonen 2007

yesHadi-Vencheh

2012yes

yes Zhang 2011 yes yes


of 163

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

no. Publication Risk Disposition/mitigation/reduction blue type=lietrature review

mentioned in

this thesis

treatment

of critical

risk

ISO

31 000

own process comment

yesPorananond

2013yes yes

more knowledge to support the risk mgmt process than a

new theory, existing tools are too complicated for users

Mainly literature reviews

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

yesPorananond

2014yes

case study food industry FMEA based

yes Carbone 2004case study electronics industry

Hil lson 2006tactical vs strategic threats

Seyedhoseini

2009yes

equal weight risk analysis and risk response

Seyedhoseini

2009yes

same paper as D06

Marmier 2012 yesdecision support system satel lite development,

complicated math, software tool

yes Koivu 2014 yes supply chain, mainly process risks analyzed FMEA based

Laurent 2012 portugiesisch

Hassanzadeh

2012yes

risk from human factor, case study Ski resort

yes Badri 2012 yes focus on safety gaps

yes Profit 2014 yessupply chain risks

yes Gourc 2006 französisch, sehr theoretisch

yesAbrahamsen

2012yes

Environmental risks focus

yes Takalo 2014 yes bank in Iran case study

yes Hu 2012 yes far too theoretical and complicated

Aven 2006 theoretical discussion about risks

yesde Azevedo

Degen 2010

portugiesisch FMEA based

yes Kutsch 2005 Interviews in the IT industry

yes Oehmen 2010 yes Yes return vs risk lean product development MIT good literature review Mainly literature reviews

FMEA based

yesArundachawat

2012des. Rew. Red

Thesis on the reduction of design rework FMEA based

Mourato 2011 yesProceedings quality in education, one paper on risk

management in H E

yesMastroianni

2011yes

Master Thesis 4 case studies!

Ab Rahman

2015

SPC for SMEs, development not mentioned

yes Hamza 2009 yes SPC for man hours cost to alert to risks in development FMEA based

yesCetindamar

2013

Chapter 6 and 12 relevant but very theoretical

yes Kaplan 2001 hologr model Holographic modell ing, very theoretical FMEA based

Kujawski 2002 yes risk reactionmathematical paper on risk reaction according to risk vs

benefit

FMEA based

yes Alhassan 2013 yes yesMaster thesis with case study medical company, claims

comprehensive model

FMEA based

yesHuchzermeier

2001math tool

mathematical treatment, general not very practical real options theory

yes McNeil 2005 Financial risk management history, mathematical

Hampe 2015 yesInfo from consultant, relation risk in ISO 9001 and ISO

31000

Sanchez 2009 Review paper risk managments in projects, very general

yes Hil lson 2005yes,

others

Comprehensive l it review, emphasis on RM standards Mainly literature reviews

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 model ling, too complicated

Cooper 2014 book on ISO 31000 and IEC.. On RM in projects

yes Summer 2000Risks in implementing ERP according to existing business

processes

Mainly literature reviews

Sherer 1995Risks in software developemennt

yesGunther

McGrath 2004

Real options an pharmaceutical R&D very theoretical real options theory

yesMurray-Webster

2010

hol istic planning and control of R&D projects, very

theoretical

real options theory

yes Verdu 2012claim to improve innovation by real options theory, very

theoretical

real options theory

yes Hughes 2009 TRL and REThoptimum vendor selection based on mathematical tool to

connect real options to technological readiness level

real options theory

Murray-Webster

2010

Risk and human behavior, very general real options theory

Adner 2002limits of appl icabi li ty of real options, very general ,

depends on company strategy

real options theory

yesMurray-Webster

1999

real option applied to fai lure, very theoretical real options theory

yesMurray-Webster

1997

real options theory and technological positioning, very

theoretical

real options theory

yes Benaroch 2002 real options applied to risks iin IT system invest real options theory

yesSegismundo

2008yes

wel l structured from automotive with case study FMEA based

Cagno 2008 risk cube very general treatment with risk cube model FMEA based

Marques 2010 3D Performance multidimensional process performance metric FMEA based

Hil lson 2003 yes RBS Consultant paper on Risk breakdown structure FMEA based

Jonen 2007 semantic analysis of the term risk FMEA based

yesHadi-Vencheh

2012data envel An.

Data Envelope analysis appl ied to FMEA FMEA based

yes Zhang 2011 RM & FTAgeneral investigation of RM and Future technology analysis


of 163

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 iden-

tification (technical, project, organization, cost, time, market) and the use of standard-

ized risk analysis and risk mitigation and risk management (FMEA, EFQM model, Qual-

ity function deployment) tools, including fulfilling the prescriptions of the risk manage-

ment 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 / mitiga-

tion based on those detailed inputs (compared to methods that do not employ stand-

ardized QM tools but heavily rely on interviews, unstructured expert input amalgama-

tion, surveys and other non-standardizes and / or more complicated methods).

Although most of those methods (as discussed above) employ more rigorous mathe-

matical 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 reli-

able 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.


of 163

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 pro-

jects.

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 pro-

duction. 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 trans-

lation 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)


of 163

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 introduc-

tion 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 num-

ber 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.


of 163

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 con-

ference 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 with-

out 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 meth-

ods can be found in the open literature (in addition to those in company internal docu-

ments, Source: W. Bergholz, private communication)


of 163

1.7 Research Gaps and the objectives for this PhD project

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.

MethodProduct

Maturity

Project /

Product

Corrective

Action

Everyday

BusinessComment

Monte Carlo Simulation - - o -

Monte Carlo Simulation is normally used in case of

Mathematical Problems and for Production Flow

Analysis

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

Decisions

Control Charts / Fuzzy Logic o o + oControl Charts are used for Statistical Process Control /

Fuzzy Logic in the Automatic Control Engineering Field

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

Application

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

Application

Analytical Hierarchy

Processo - + -

Analytical Hierarchy Process is used for Decision Making

Support

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

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


of 163

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.

2 Risk Management

of 163

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 miti-

gation 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 man-

agement – 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 satis-faction

2. Enhancement of results concerning new products, new production or other pro-cesses, 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 pro-

cesses

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.

2 Risk Management

of 163

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 develop-

ment of the comprehensive risk management technique in connection the development

of technical products.

KANOValue

AnalysisFMEA

IM:PULS

PDCAUSP

DPEA

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.

2 Risk Management

of 163

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 pro-

jects

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 mak-

ing. 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 risk assessment and risk management

48

Empirical Survey, interview, case study, experimental, exploratory based on empirical use and indus-trial case

68

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

51

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:

2 Risk Management

of 163

• portable or transferable,

• relevant and

• beneficial

for the users.


development

of 163

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 tech-

nology 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 expe-

rience 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 infor-

mation 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 consid-

ered 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 manage-

ment (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 organiza-

tion including ALL aspects, in particular technical, logistic, organizational and eco-


development

of 163

nomic facets. Here, the term quality is understood in a very broad sense (i.e. in partic-

ular, 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 inher-

ent 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 fulfil-

ment 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?


development

of 163

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 manage-

ment. 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.

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

1. Erfüllung von Spezifikationen

In welchem Maße glauben uns die Menschen, dass die versprochene Qualität sich in ihrer Praxis bewährt?

2. Abgrenzung

Inwiefern rechnen die Menschendiese Qualität uns zu und sehen sich außerstande, ohne Tausch selber in deren Besitz zu gelangen?.

3. Vertrauen

Welche Bedeutung hat diese Qualität für die Menschen?

4. Begehrlichkeit

Wieviel weitere Anbieter dieser Qualität können die Menschen mit vergleichbarem Aufwand finden?

5. Einzigartigkeit

Was müssen wir für fremde Leistungen bezahlen und wieviel verbleibt uns für Zukunftssicherung, Risikovorsorge, Kapitalkosten sowie Erzeugung

und Vermarktung der geforderten Qualität?

7. Rentabilitätsanspruch

Welche Kooperations- und Zahlungsbereit-schaft erzeugt die wahrgenommene Einzigartigkeit bei den Menschen und sind sie fähig, sie tatsächlich zu leisten?

6. Zahlungsfähigkeit

wirtschaftlich relevante Qualität


development

of 163

Figure 11: Deming Cycle

Closed loop control is an engineering principle, where the difference between the tar-

geted 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).


development

of 163

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.

Set objectives to be achieved

Plan

Do

Assessing and improving

Learning and new objectives set

Act Plan

Check Do

Result

Approach

Deployment

Assessment &

Refinement


development

of 163

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


development

of 163

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 pro-

cess) and to find necessary changes (=cost and time risks) through continuous learn-

ing 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 re-

quirements 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 speci-

fied 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 con-

cept 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:


development

of 163

“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 imple-

mented the more satisfaction they bring to the user / customer of the product.

Conversely, the worse they are implemented, the more dissatisfaction they cre-

ate. 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 de-

signed 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” be-

cause 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.


development

of 163

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 organiza-

tional 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 men-

tioned 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


development

of 163

intervals in a defined process with the participation of experts from industry and aca-

demia 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 organiza-

tion, 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


development

of 163

• 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 poten-

tials can be derived directly from the evaluation scores.

Since the feedback principle is integrated into the RADAR process, including the re-

quirements 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.


development

of 163

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.

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 in-

stead 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 activ-

ities. These aspects will lead to a base for success in terms of risk detection, risk miti-

gation 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.

19

35

84

126

16

34

60

90

0

20

40

60

80

100

120

140

Year 0 Year 1 Year 2 Year 3

Mean % Growth in Share Value

Award Winning Companies Comparison Companies


development

of 163

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 use-

ful”

4. „No concrete implementation model “

The questions to be answered within the context of this project (and before its applica-

tion) 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 appli-

cation 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 man-

agement 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 quan-

tified 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


development

of 163

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 assess-

ment 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


development

of 163

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 quan-

tified in a similar manner, based on the risk priority figure in simple manner by assigning


development

of 163

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 / pre-

vention 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 rela-

tively 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 clas-

sification has been proven to be extremely useful, efficient and effective for many dec-

ades. 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.


development

of 163

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 develop-

ment 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 stand-

ard ISO 31000 (ISO 31000:2009-11) was published. Due to this well-organized devel-

opment 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 de-

sign 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:


development

of 163

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 man-

agement 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 devel-

oped based on the EFQM excellence model. It aims to evaluate ex post already com-

pleted 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.


development

of 163

Similar to the RADAR algorithm, an analysis is carried out, which leads to a final eval-

uation 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 man-

agement 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 devel-

opment 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.


development

of 163

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)


development

of 163

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 stand-

ardized 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 func-

tionality 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 require-

ments, 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.

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.

What should the product provide to the user? [B] 7

Which services should be provided? [B] 7

Input - Processing - Output [B] 7

Behaviour in certain situations? [B] 7

Functional Requirement

Technologie oder Komponenten / technology or components / TRS [A]

vs.

Kunden- oder Marktanforderungen / Customer- or market requirements / CRS [B]





development

of 163

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 eval-

uation 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.

Reliability [B] 7

Look & Feel [B] 7

Useability [B] 7

Performance / Efficiency [B] 7

Operation / Environmental Conditions [B] 7

Maintainability / Alterability [B] 7

Portingability / Transferability [B] 7

Safety Requirements [B] 7

Correctness [B] 7

Flexability [B] 7

Scalability [B] 7

Approval [B] 7Non-Functional Requirements

Non-Functional Requirements












vs.



development

of 163

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 re-

quirements

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 require-

ments / 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 man-

ner.

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:


development

of 163

Type

System [Sy] /

Method [Me] /

Model [Mo]

Used characteristic Contribution

Me Total Quality Man-

agement [TQM]

Coverage of all company

sections and members

Inclusion and of all rele-

vant Quality Manage-

ment tools

Me IM:PULS Control and feedback of ac-

tivities – improved version

of the PDCA-concept

Control and feedback of

activities and pro-

cesses, improvement of

the input and learning

Mo

Me

Kano-model Classification of customer

requirements

improved determination

of the CRS

Mo European Founda-

tion for Quality

Management

[EFQM]

RADAR evaluation proce-

dure

Determination of the

level of maturity of prod-

uct development depart-

ment and other organi-

zation parts involved in

the product develop-

ment process

Me Failure Mode and

Effect Analysis

[FMEA]

Reliability assessment; rat-

ing scheme for risks

Determination of the

product maturity, project

maturity by application

of SPC, quasi continu-

ous assessment of the

development status

Sy Risk Management

according to ISO

31000 [RM]

Basic concept for risk man-

agement

Guideline/template for

approach to the tech-

nical risk management


development

of 163

Sy Deutscher Project

Excellence Award

[DPEA]

Evaluation procedure for

???

Level of maturity of pro-

ject management

Sy Technical Risk

Management [TRK]

Basic approach to technical

risk management

Focus on and applica-

tion to our technical risk

management concept

Me Value Analysis [VA] Definition of functionalities Differentiation between

functional and boundary

condition / non-func-

tional requirements

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

4 Overall approach to the risk management process developed in this

thesis

of 163

4 Overall approach to the risk management process devel-

oped in this thesis

Up to this point, the foundations for developing the new more comprehensive and in-

tegrated risk management model and process have been covered. The methods, mod-

els, 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 en-

vironmental 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 lit-

erature, 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 manufac-

turer of innovation products. To fulfil market and customer requirements Dräger Safety

is operating an extensive product development commensurate with the potential prod-

uct 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

4 Overall approach to the risk management process developed in this

thesis

of 163

Therefore, the management of R&D launched a project to redesign the product devel-

opment 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-land-

scape (Dräger 2012).

In addition to the scientific and technical literature, and the corporate information sys-

tems of the Dräger company, more sources have been used as inputs for this thesis,

an overview is given in the following table.

Table 6: used sources

Corporate-

brochure

Corporation info x x

Method x x x x x

Market x x x

Technology x x x x x

Desk research Field research

Literature Internet Online Expert Case


assessment

of 163

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 con-

cept 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 pro-

ject.

To meet the requirement for traceability and reproducibility of quantifiable risk assess-

ment, 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 stand-

ardized 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 insur-

ance 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


assessment

of 163

mitigate by additional measures to an acceptable size. So, FMEA is targeting at com-

prehensive assessment of potential causes of failure and defines a third factor for risk

determination / assessment, which is not used in the financial and insurance method-

ology 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


assessment

of 163

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 de-

velop 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 frame-

work 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:).


assessment

of 163

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 “se-

verity” and “occurrence” and are used in the proposed risk management method:

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 devel-

opment of the risk management tool, which is the centerpiece of this thesis.

[S]

[B]

1 Keine Auswirkung No effect

2 Belästigung Annoyance



5

Ausfall oder

Verschlechterung von

Sekundärfunktion

Loss or Degradation of

Secondary Function

6

Ausfall oder


Sekundärfunktion


Secondary Function

7

Ausfall oder


Primärfunktion


Primary Function

8

Ausfall oder


Primärfunktion


Primary Function

9

Verletzung von

Sicherheits- / gesetzli-

cher Bestimmungen

Failure to Meet Safety

and / or Regulatory

Requirements

10

Verletzung von


cher Bestimmungen


and / or Regulatory

Requirements

Severity / Bedeutung / CRS

Severity of Effect on Product

[O]

[A]

1 Sehr selten Very low

2 Selten Low

3 Selten Low

4 Mäßig Moderate

5 Mäßig Moderate

6 Mäßig Moderate

7 Oft High

8 Oft High

9 oft High

10 Sehr oft Very High

Occurrence / Auftreten / TRS

Likelihood of Failure

6 Risk assessment tool for continuous monitoring of product development risk

of 163

6 Risk assessment tool for continuous monitoring of

product development risk

In this chapter the generic quantification of potential effects and causes will be trans-

lated 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:

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:


> 1

in 1

0

Am Markt / in der Wissenschaft neue, nicht

beherrschte Technologie

Technology at theoretical level


of 163

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

[O]

[A]

1 Sehr selten Very low

Failu

re e

lem

inat

ed

2 Selten Low

< 1

in 1

.00

0.0

00

3 Selten Low

1 in

10

0.0

00

4 Mäßig Moderate

1 in

10

.00

0

5 Mäßig Moderate

1 in

2.0

00

Technologie in anderen Produkten bereits

angewandt

Technology is applied for serial production

Technologie im eigenen Hause beherrscht

Technology is under controlled conditions for

internal production

Technologie im eigenen Haus bekannt

technology is known in-house



Technologie ist beherrscht und bewährt;

geringe Reklamationen aus dem Feld

Technology is under controlled Conditions;

marginal claims from the market

Technologie in Großserie angewandt

Technology is applied at mass production

[O]

[A]

6 Mäßig Moderate

1 in

500

7 Oft High

1 in

100

8 Oft High

1 in

50

9 Oft High

1 in

20


> 1

in 1

0

Technologie noch im wissenschaftlichen

Stadium

Technology is at academic level

Am Markt / in der Wissenschaft neue, nicht

beherrschte Technologie

Technology at theoretical level

Anbieter am Markt mit Anwendungserfahrung

There are vendors providing technology with

application experience

Anbieter am Markt mit theoretischer

Technologiekenntnis, ohne

Anwendungserfahrung

Vendors available with know how, but

without application experience

Erste Pilotanwendungen vorhanden

Pilot application known




of 163

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:

Table 10: Example for risk by maturity of technology (severity)

The complete standardize table for evaluation of the effect of failure is presented be-

low:

10

Verletzung von


cher Bestimmungen


and / or Regulatory

Requirements

Gefährdung, Verstoß gegen Gesetze, Gefahr

für Leib und Leben

Danger, effecting legal regulations, danger to

life or physical condition


of 163

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

[S]

[B]

1 Keine Auswirkung No effect




5

Ausfall oder


Sekundärfunktion


Secondary Function

Bedeutung gering, keine funktionelle

Beeinträchtigung, Geringfügige Aussehens-

oder Geräuschbeeinträchtigung

Minor severity, no impact to function, little

impact to appearance and noise

Bedeutung mittel, optische oder geringe

funktionelle Beeinträchtigung Aussehens-

oder Geräuschproblem

Middle severity, little impact to function,

apperance and noise

Bedeutung mittel, geringe bis mittlere

funktionelle Beeinträchtigung, Minderung

einer Komfort- oder Zusatzfunktion

Middel severity, little to middle impact to

function, reduction of comfort options



Bedeutung äußerst gering, keinerlei

Beeinträchtigung

No impact to customer

Bedeutung sehr gering, lediglich optische

Beeinträchtigung, Kaum erkennbare

Aussehens- oder Geräuschentwicklung

Marginal severity, marginal impact on

appearance and noise

[S]

[B]

6

Ausfall oder


Sekundärfunktion


Secondary Function

7

Ausfall oder


Primärfunktion


Primary Function

8 gravierend serious

9

Verletzung von


cher Bestimmungen


and / or Regulatory

Requirements

10

Verletzung von


cher Bestimmungen


and / or Regulatory

Requirements

Schwerwiegende funktionelle

Beeinträchtigung und Sicherheitsmängel

High severity, impact to vital function

Gefährdung, Verstoß gegen Gesetze, Gefahr

für Leib und Leben

Danger, effecting legal regulations, danger to

life or physical condition

Mittlere funktionelle Beeinträchtigung,

Verlust einer Komfort- oder Zusatzfunktion

Middle severity, lost of comfort options

Bedeutung groß, funktionelle

Beeinträchtigung verminderte Primärfunktion

High severity, fuctional interference


Beeinträchtigung oder Sicherheitsmängel

High severity, impact to vital function, safety

aspects




of 163

6.3 Classification of customer, legal, market = external require-

ments

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 competi-

tor’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).


of 163

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 require-

ments are finalized and “embedded” in the excel tool, in this manner the first essen-

tial 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.


of 163

6.4 Risks in product development: Effect of failure related to inter-

nal 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 de-

sign.

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 as-

sociated 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.

7 The Risk Management Model: Complete Design demonstrated

of 163

7 The Risk Management Model: Complete Design demon-

strated

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 man-

agement 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 solu-

tion 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 develop-

ment time (see Figure 25).


of 163

68,4 % Frühes Einbinden der (relevanten) Abteilungen

(Integration of (relevant) departments at an early stage)

52,9 % Effectives Projektmanagement

(effective project management)

46,3 % Intensive Planung

(Intensive planning)

39,0 Pragmatismus statt Over-Engineering

(Pragmatism instead of over engineering)

27,9 % Gute Kommunikation

(good communication)

26,5 % Parallelisierung des Konstruktionsprozesses

(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 develop-

ment 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 de-

velopment projects.


of 163

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


of 163

7.2 Optimization along the New Product Development Process

As part of the complete product development process, set up by Dräger, it is consid-

ered 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


of 163

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 function-

alities. 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 require-

ment 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”


of 163

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 re-

search 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 re-

quirements. 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.

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

FA Ba x 8 x 24

NFA Le 8 x 24 x 32 x 40

Be x 8

8

6

8 x 24

8

8

8

8


vs.


Function 1 Function 2 Function 3

3 4 5

1

2

3

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

8 gravierend serious


Beeinträchtigung oder Sicherheitsmängel

High severity, impact to vital function, safety

aspects


of 163

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 tech-

nology depends on the Kano categories and if the functional requirement is a USP.

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.

FA Ba x 8 x 24

NFA Le 8 x 24 x 32 x 40

Be x 8

8

6

8 x 24

8

8

8

8

3 4 5


vs.


Function 1 Function 2 Function 3

1

2

3

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

3 selten rarely

Technologie in anderen Produkten bereits

angewandt

Technology is applied for serial production


of 163

Figure 31: Evaluation of risk for technology

Generally speaking, all activities for a high score level have to be listed and risk miti-

gation 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 accepta-

ble.

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 gener-

ated. 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.

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


vs.


Function 1 Function 2 Function 3 Function 4 Function 5 Function 6

3 4 5 6 7 8

"Customer / market requirement 1" willbe effected by "Function 1" => marked

Risk to high; S x O > 25

Risk to high; O > 7


of 163

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


of 163

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 technol-

ogy 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) [se-

verity] 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


of 163

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.


of 163

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.



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:

10

9

8

7

6

5

4

3

2

1

1 2 3 4 5 6 7 8 9 10

Severity [S]

Occ

ure

nce

[O

]

No compelling need for action,

appropriate measure necessary

No action

Immediate action


of 163

“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 pro-

cesses.

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 prod-

uct.

Occurence [O]

1 2 3 4 5 6 7 8 9 10

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 7 16 18 10

0%

14%

86%

Target Actualmin. 80%

max. 15%

max. 5%

0

1

6

Actual [%]


of 163

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


of 163

This phase will end up with Gate 5 / PR1-milestone. The project team commit them-

selves 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 fail-

ure mode.

7.5.1 Transformation of Concept Matrix into FMEA form

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 con-

cept evaluations at a low risk level will be eliminated for FMEA analysis from this stage

onwards.

Concept Matrix FMEA formfuntional requirement potential failure mode

S [severity] S [severity]

function potential cause

O [occurence] O [occurence]


of 163

Thus, the efficiency of the risk assessment by FMEA will be reduced significantly and

potential frustration of the team members analyzing “peanuts” is reduced.

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 con-

structed and built, right?” This covers all tests versus the internal specifications

(TRS).

What should the product provide to the user? RPF 25

FA Ba Customer / market requirement 1 x 20

FA Be x Customer / market requirement 2 x 40 x 24

FA Ba Customer / market requirement 3

FA Le Customer / market requirement 4 x 15

FA Be x Customer / market requirement 5 x 27

RPF > 25

4

8

3

5

9

FA [B] 30 22


vs.

Kunden- oder Marktanforderungen / Customer- or market

requirements / CRS [B]

Component 1

[A]

Function 1.1 Function 1.2

5 3

AA_1 0

Bedeutung groß, funktio-

nelle Beeinträchtigung oder

Sicherheitsmängel

High severity, impact to vital

function

8

Customer / market

requirement 2

nvb

Funtion 1.1

5

Bedeutung groß,

funktionelle

Beeinträchtigung oder

Sicherheitsmängel


function, safety aspects

9

Customer / market

requirement 5

nvb

Funtion 1.2

3

< >

mögliche FehlerursachePotential Cause(s)

VermeidungsmaßnahmenPreventive Actions

AO

mögliche FehlerfolgePotential Effect(s) of Failure

BS

möglicher FehlerPotential Failure Mode

RPZRPN


of 163

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 re-

quirements (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, valida-

tion 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.


of 163

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?”.

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

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]

AA_1 2

Bedeutung groß, funktio-

nelle Beeinträchtigung oder

Sicherheitsmängel


function

8

Customer / market

requirement 2

120

Funtion 1.1

5

Verification 1

3

Bedeutung groß,

funktionelle

Beeinträchtigung oder

Sicherheitsmängel


function, safety aspects

9

Customer / market

requirement 5

108

Funtion 1.2

3

Validation 1

4



AO

EntdeckungsmaßnahmenCurrent Design Controls

ED

mögliche FehlerfolgePotential Effect(s) of Failure

BS


RPZRPN

< >

Prüfungsmethode

Testing Method

obere Toleranz

Upper Tolerance

Merkmal

Characteristic

untere Toleranz

Lower ToleranceVerification 1 10,01Thickness 9,99Validation 1Durability

Val

idie

run

g

Val

idat

ion

Ver

ifiz

ieru

ng

Ver

ific

atio

n

Nominal

Nominal

Dokumentation

Documentation

x 10,0 mm testform b

x 99,83 HV 10 testform a


of 163

Figure 45: Standard table for detection scores 1…10

[D]

[E]

1 Almost Certain

Det

ecti

on

no

t ap

pli-

cab

le;

Failu

re p

reve

nti

on

2 Very High

Vir

tual

An

alys

is -

Co

rrel

ated

3 High

Pri

or

to D

esig

n F

reez

e

4 Moderately High

Pri

or

to D

esig

n F

reez

e

5 Moderate

Pri

or

to D

esig

n F

reez

e

Detection

Likelihood of Detection by Design Control

Fehlerursache oder Fehlerart kann nicht

auftreten, da sie durch Konstruktionslösungen

(z. B. bewährtes Designstandard, Best Practice

oder übliches Material usw.) vollständig

verhindert wird.

Failure cause or failure mode cannot occur

because it is fully prevented through design

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

practice or common material, etc.)

Designanalyse / Entdeckungsmaßnahme

haben eine starke Erkennungsfähigkeit; Die

virtuelle Analyse (z. B. CAE, FEA etc.) ist in

hohem Maße mit tatsächlichen oder

erwarteten Betriebsbedingungen vor dem

Designfreeze korreliert.

Design analysis / detection controls have a

strong detection capability; Virtual Analysis

(e.g. CAE, FEA, etc.) is highly correlated with

actual or expected operating conditions prior

to design freeze.

Produktvalidierung (Zuverlässigkeitsprüfung,

Entwicklungs- oder Validierungstests) vor dem

Designfreeze unter Verwendung von

Degradationstests (z. B. Datentrends, vorher /

nachher Werten usw.)

Product validation (reliability testing,

development or validation tests) prior to

design freeze using degradation testing (e.g.,

data trends, before / after values, etc.)


Entwicklung- oder Validierungstests) vor dem

Designfreeze unter Verwendung von Test auf

Ausfall (z. B. bis Lecks, Ausbeute, Risse usw.)



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

leaks, yields, cracks, etc.)


Entwicklungs- oder Validierungstests) vor dem

Designfreeze mit Pass- / Fall-Tests (z. B.

Akzeptanzkriterien für Leistung,

Funktionsprüfungen usw.)



design freeze using pass / fall testing (e.g.,

acceptance criteria for performance, function

checks, etc.)

[D]

[E]

6 Low

Po

st D

esig

n F

reez

e an

d

pri

or

to la

un

ch7 Very Low

Po

st D

esig

n F

reez

e an

d p

rio

r to

lau

nch

8 Remote

Po

st D

esig

n F

reez

e an

d p

rio

r to

lau

nch

9 Very Remote

No

t lik

ely

to d

etec

t at

an

y st

age

10 Almost Impossible

No

det

ecti

on

op

po

rtu

nit

y

Produktprüfung / Validierung nach dem

Designfreeze und vor dem Start mit Test

Versagen (Subsystem oder Systemtests bis

zum Ausfall, Prüfung von Systeminteraktionen

etc.).

Product verification / validation after design

freeze and prior to launch with test to failure

testing (Subsystem or system testing until

failure occurs, testing of system interactions,

etc.).


Designfreeze und vor dem Start mit Pass- / Fall-

Tests (Subsystem oder Systemprüfung mit

Akzeptanzkriterien wie Fahr- und Handling,

Versandbewertung etc.).


freeze and prior to launch with pass / fall

testing (Subsystem or system testing with

acceptance criteria such as ride and handling,

shipping evaluation, etc.).

Designanalyse / Entdeckungsmaßnahmen

haben eine schwache Erkennungsfähigkeit.

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

nicht mit den erwarteten tatsächlichen

Betriebsbedingungen korreliert.

Design analysis / detction controls have a

weak detection capability; Vitual Analysis (e.g.

CAE, FEA, etc.) is not correlated to expected

actual operating conditions.

Keine aktuellen Entdeckungsmaßnahmen;

nicht erkennen oder nicht analysiert.

No current design control; cannot detect or is

not analyzed.

Detection

Likelihood of Detection by Design Control


Designfreeze und vor dem Start mit

Degrationstest (Subsystem oder Systemtest

nach Abbauprüfung, z. B. Funktionskontrolle).


freeze and prior to launch with degration

testing (Subsystem or system testing after

degradation test, e.g., function check).


of 163

The risk limit for the RPF has been defined earlier at RPF > 25, in line with this “phi-

losophy” 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 detec-

tion. Thus, the risk as measured by the RPN is reduced in a more timely and cost

efficient manner.

8 Project Maturity

of 163

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 prod-

uct development is halted and the results are reviewed against the project goals.

8 Project Maturity

of 163

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

8 Project Maturity

of 163

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 re-

duced 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.

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 be-

ginning 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.

Occurence [O]

1 2 3 4 5 6 7 8 9 10

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 7 16 18 10

PR1 PR2 PR3 PR4 PR5 Act

25% 50% 70% 80% 90% 0

50% 35% 25% 15% 10% 1

25% 15% 5% 5% 0% 6

Target

max. 10%

max. 0%

Actual

11%

1%

0%

min. 90%

9 Validation of the concept

of 163


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 ad-

vanced 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.


of 163

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 ex-

plained:

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

NFA Le xInstrument read-out should be ensured at extrem lighting

conditions (bright, dark)6 x 24 x 12 x 48

4 2 8


vs.


Backlight (fix);

contrast adjustableBacklight (fix)

Backlight adjustable,

contrast adjustable

4m

anch

mal

som

eti

me

s

Tech

no

logi

e im

eig

en

en

Hau

se b

eh

err

sch

t

Tech

no

logy

is u

nd

er

con

tro

lle

d c

on

dit

ion

s fo

r

inte

rnal

pro

du

ctio

n

2se

hr

selt

en

very

rar

ely

Tech

no

logi

e in

Gro

ßse

rie

an

gew

and

t

Tech

no

logy

is a

pp

lie

d a

t m

ass

pro

du

ctio

n

8se

hr

oft

very

oft

en

Erst

e P

ilo

tan

we

nd

un

gen

vo

rhan

de

n

Pil

ot

app

lica

tio

n k

now

n

6b

ed

eu

ten

dsi

gnif

ican

t

Mit

tle

re f

un

ktio

ne

lle

Be

ein

träc

hti

gun

g,

Ve

rlu

st e

ine

r K

om

fort

- o

de

r Zu

satz

fun

ktio

n

Mid

dle

se

veri

ty, l

ost

of

com

fort

op

tio

ns

[A] 4 [A] 5 [A] 6 [A] 7

What should the product provide to the user? [B] 8 x 32 x 40 x 48 x 56

Which services should be provided? [B] 6 x 24 x 30 x 36 x 42

Input - Processing - Output [B] 8 x 32 x 40 x 48 x 56


Reliability [B] 6 x 24 x 30 x 36 x 42

Look & Feel [B] 7 x 28 x 35 x 42 x 49

Useability [B]

Performance / Efficiency [B] 9 x 36 x 45

Operation / Environmental Conditions [B] 9 x 45 x 63

Maintainability / Alterability [B]

Portingability / Transferability [B]

Safety Requirements [B]

Correctness [B]

Flexability [B]

Scalability [B]

Boundary Conditions [B]

Approval [B] 10 x 40 x 50Non-Functional Requirements

















DisplayMaintenanceEnergy supplyTechnologie oder Komponenten / technology or components / TRS [A]

vs.


HousingOccurence [O]

1 2 3 4 5 6 7 8 9 10

1 0

2 0

3 0

4 0

5 0

6 2 2 2 2 48

7 1 1 1 1 28

8 2 2 2 2 64

9 1 2 1 36

10 1 1 20

Severity [S]

0 0 0 28 40 30 42 0 0 0

Target Actual Actual [%]min. 80% 0 0%

max. 15% 0 0%

max. 5% 17 100%


of 163

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 evalua-

tion 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 re-

duction for further investigation of 42 values.

[A] 8 [A] 6 [A] 6 [A] 8

What should the product provide to the user? [B] 8 x 64 x 48 x 48 x 64

Which services should be provided? [B] 6 x 48 x 36 x 36 x 48

Input - Processing - Output [B] 8 x 64 x 48 x 48 x 64


Reliability [B] 6 x 48 x 36 x 36 x 48

Look & Feel [B] 7 x 56 x 42 x 42 x 56

Useability [B]


Operation / Environmental Conditions [B] 9 x 54 x 72




Correctness [B]

Flexability [B]

Scalability [B]


Approval [B] 10 x 80 x 60Non-Functional Requirements

















DisplayMaintenanceEnergy supplyTechnologie oder Komponenten / technology or components / TRS [A]

vs.


HousingOccurence [O]

1 2 3 4 5 6 7 8 9 10

1 0

2 0

3 0

4 0

5 0

6 4 4 48

7 2 2 28

8 4 4 64

9 2 2 36

10 1 1 20

Severity [S]

0 0 0 0 0 78 0 104 0 0

Target Actual Actual [%]min. 80% 0 0%

max. 15% 0 0%

max. 5% 10 100%


of 163

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

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.

[A] 4 [A] 5

What should the product provide to the user? [B] 8 x 32 x 40

FA Le level of breath alcohol indicated 8 x 48 x 24 x 40 x 48

Which services should be provided? [B] 6 x 24 x 30

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

Input - Processing - Output [B] 8 x 32 x 40

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


FA Ba alarm indicates a positiv alcohol test 7

FA Le user reminded when calibration period is expired 5

Reliability [B] 6 x 24 x 30

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

Look & Feel [B] 7 x 28 x 35

NFA Be x shirt pocket size 7 x 49 x 21

NFA Be modern design 7 x 49 x 21 x 28 x 42

Useability [B]


NFA Be x 12 month measuring performance (certified) 9 x 27 x 27 x 45 x 54

Operation / Environmental Conditions [B] 9 x 45

NFA Le not condensing (operation at 10 to 100% rel. humidity) 9 x 27 x 45




Correctness [B]

Flexability [B]

Scalability [B]


Approval [B] 10 x 40 x 50

NFA Ba CE certificate 10 x 70 x 50 x 60 x 70 x 30 x 50 x 60



vs.


Housing

7 7

21

Design SizeWeight Handling

5 6

48

Stability

3



42 49

42



Non-Functional Requirements 49











60 70Non-Functional Requirements 50

Energy supply Durability

24

15

23

17

21

27

27

70

40 48

3 4 5 6 3

Alarm low

batteryStable current

Measuring at low

temperature

Accu

exchangeable

31 38 48 24

20 25 15

30 36

28 42

45

45 54

30 50 60

[A] 6 [A] 7

What should the product provide to the user? [B] 8 x 48 x 56

FA Le level of breath alcohol indicated 8 x 40 x 32 x 24 x 32 x 40 x 48

Which services should be provided? [B] 6 x 36 x 42

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

Input - Processing - Output [B] 8 x 48 x 56

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


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

Reliability [B] 6 x 36 x 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

Look & Feel [B] 7 x 42 x 49

NFA Be x shirt pocket size 7 x 21 x 28 x 35 x 42

NFA Be modern design 7 x 35 x 28

Useability [B]

Performance / Efficiency [B] 9

NFA Be x 12 month measuring performance (certified) 9

Operation / Environmental Conditions [B] 9 x 63

NFA Le not condensing (operation at 10 to 100% rel. humidity) 9 x 27 x 36 x 45 x 54




Correctness [B]

Flexability [B]

Scalability [B]


Approval [B] 10

NFA Ba CE certificate 10



vs.


















Maintenanceno mainte-

nance required

firm ware

update by user

31 46

23 34

4 6 7 5 4 4

display service

request

display cali-

bration requ.

battery

exchance

opening for

service eng.

23 30 35 25

40 32

25

54 38

35 28

35 25 20 20

DisplayAccu status

displayed

readable at dark

condition

24 32

23 28

21 28

3 4 5 6

readable at

bright condition

alarm for

positive test

15 20 25 30

40 48

28 35 42

35 42

21 28 35 42

35 42

27 36 45 54


of 163

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.

1 AA 1 11

2


function, safety aspects 8level of breath alcohol not

indicated

Housing: Handling

6 48

3 8Energy supply: stable

current 5 40

4 8Energy supply: Measuring

at low temperature 6 48

5 8Maintenance: display cali-

bration requirements 5 40

6 8Maintenance: battery

exchange 4 32

7 8Display: readable at dark

condition 4 32

8 8Display: readable at bright

condition 5 40

9 8Display: alarm for positive

test 6 48

10 AA 2

11

Middle severity, little to

middle impact to function,

reduction of comfort options5

breath alcohol value not

printed

Maintenance: firm ware

update by user 6 30

12 5Maintenance: display

service request 7 35

13High severity, impact to vital

function 7mouth piece not changeable Housing: Handling

6 42

14 7Housing: Size

7 49

15 7Maintenance: no

maintenance required 4 28

16





displayed


update by user 6 30


service request 7 35


test 6 30

19 AA 3


function 7breath specimen not

accepted

Housing: Handling6 42

21 7Energy supply: Alarm low

battery 4 28

22 7Energy supply: Stable

current 5 35


at low temperature 6 42

24 7Maintenance: no mainte-

nance required 4 28

25 7Maintenance: firm ware

update by user6 42


service request7 49


bration requ.5 35

28 AA 4

What should the product provide to the user?



AO

AxBSxO

Nr. noacmögliche Fehlerfolge

Potential Effect(s) of Failure

BS


Which services should be provided?

Input - Processing - Output

Behaviour in certain situations?


of 163

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 ex-

tended 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.

1 AA 1 0

2



indicated

Housing: Handling

6 48 48


current5 40 40


at low temperature6 48 48


bration requirements5 40 40


exchange4 32 32


condition4 32 32


condition5 40 40


test6 48 x 1

redundant system8 2 16

10 AA 2

11





printed


update by user 6 30 30


service request7 35 35


function7

mouth piece not changeable Housing: Handling6 42 x 2

easy use clip

system7 3 21

14 7 Housing: Size 7 49 49

15 7Maintenance: no

maintenance required4 28 28

16





displayed


update by user 6 30 30




test6 30 30

19 AA 3


function7

breath specimen not

accepted

Housing: Handling6 42 42


battery4 28 28


current5 35 35




nance required4 28 28


update by user6 42 42




bration requ.5 35 35

28 AA 4






BS


MaßnahmeRecommended

action(s)

BS

AO

RPZRPN




AO

AxB

SxO

Ko

rr A

xB

lfd

Nr.


of 163

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 require-

ments [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 ac-

ceptable level.

1 AA 1 11 AA_1

2



indicated

Housing: Handling

6 48 48Usability test

x 2 96


current5 40 40

Durability testx 2 80



Cold Chamber testx 2 96


bration requirements5 40 40



exchange4 32 32

Handling testx 3 96


condition4 32 32

Usability testx 2 64


condition5 40 40



test6 48 x 1

redundant system8 2 16 0

10 AA 2 0

11





printed


update by user 6 30 x 2

alarm for firm ware

update 5 4 20 0





function7


easy use clip

system7 3 21 0

14 7Housing: Size

7 49 49Handling test

x 3 147

15 7Maintenance: no



16





displayed



alarm for firm ware

update 5 4 20 0





test6 30 x 1


19 AA 3 0


function7

breath specimen not

accepted




battery4 28 28



current5 35 35




Cold Chamber testx 2 84


nance required4 28 28



update by user6 42 x 2

alarm for firm ware

update 5 4 20 0





bration requ.5 35 35


28 AA 4


Veri ValiED

RPZRPN



AO

AxBSxO

Ko

rr A

xB

lfd

Nr.


action(s)

BS

AO

RPFRPF

Veri

Va

li




BS






of 163

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 de-

scribed in 8.1.2 at each quality gate.

1 AA 1 11 AA_1

2



indicated

Housing: Handling

6 48 48Usability test

x 2 96


current5 40 40



at low temperature 6 48 48Cold Chamber test

x 2 96


bration requirements 5 40 40Durability test

x 3 120


exchange 4 32 32Handling test

x 3 96


condition 4 32 32Usability test

x 2 64


condition 5 40 40Usability test

x 2 80


test 6 48 x 1redundant system

8 2 16 0

10 AA 2 0

11





printed



alarm for firm ware

update 5 4 20 0





function7


easy use clip

system7 3 21 0

14 7Housing: Size

7 49 49Handling test

x 3 147 1Check for alternative

housing7 3 3 63

15 7Maintenance: no



16





displayed



alarm for firm ware

update 5 4 20 0





test6 30 x 1


19 AA 3 0


function 7breath specimen not

accepted




battery 4 28 28Usability test

x 2 56


current 5 35 35Durability test

x 2 70


at low temperature 6 42 42Cold Chamber test

x 2 84


nance required 4 28 28Usability test

x 2 56


update by user 6 42 x 2alarm for firm ware

update 5 4 20 0


service request 7 49 49Usability test

x 2 98


bration requ. 5 35 35Usability test

x 2 70

28 AA 4


action(s)

BS

AO

ED

RPZRPN


Veri ValiED

RPZRPN



AO

AxBSxO

Ko

rr A

xB

lfd

Nr. Ko

rr lfd

Nr.


action(s)

BS

AO

RPFRPF

Veri

Vali




BS





10 Discussion, Conclusions and Outlook

of 163


10.1 Approach to the Discussion

The literature survey to identify research gaps and identify useful methods for the de-

velopment of the comprehensive risk management tool in technical development has

identified a significant number of potentially relevant studies. At this stage, the rele-

vance 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 environ-

ment, since they do not describe or apply any of the methods in detail to be instrumen-

tal for application in practice. Nevertheless, these papers are instrumental to be rea-

sonably 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 math-

ematical background for financial risk management, and is also a useful literature re-

view, however with no direct applicability to an organizational R&D environment, since

the data gathering and the mathematics would be too time consuming and compli-

cated.

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 man-

agement 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).


of 163

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 con-

crete 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 anal-

ysis 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),


of 163

(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 con-

sider 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 meth-

ods 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


of 163

combination with the risk priority number RPN is the centerpiece of the tool devel-

oped 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 ex-

pert 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 con-

stitute 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 re-

ported 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:


of 163

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 encour-

aging 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.


of 163

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, there-

fore 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 re-

search 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 technol-

ogy is regularly assessed is the basis for the decision regarding risks and the disposi-

tion of identified risks.


of 163

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 indica-

tors 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 de-

velopment 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 assess-

ment 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 devel-

opment 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 disad-

vantages of using a new unfamiliar technique cannot be concluded at this stage.


of 163

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

RAPIDO ThesisFiled of

Application

Method for determining the degree of maturity in

product development at discrete breakpoints in

the development project.

Method for determining the degree of maturity of

products in the development process.

Personnel Costs It is a method by which a group of experts assess

the risks to meet the requirements of the market /

customer => Qualification of the participants.

The risk is determined by means of the FMEA

valuation, which is introduced and proven in the

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

method, independent of the actual development

system, including training of the participants.

There is no additional training required, according

to the FMEA method.

Integration A risk assessment is carried out by experts outside

the development project. There is not necessarily

a reference or link to the design FMEA.

The degree of maturity is determined by means of

the evaluation results of the design FMEA. Thus,

the result is directly linked to the FMEA results and

can show the level of maturity between the

quality gates in real time.

Comprehensive

assessment of

risks in the whole

value chain

Rapido starts only once all the requirements by the

market/customer have been met

The risk assessment can already be applied when

processing the development roadmap: Which

technologies have to be considered for new

products - which risks are to be expected.

Validity The assessment is based on new (subjective)

factors:

- significance index (B)

- uncertainty of prediction

- uncertainty of requirement/risk control

Continuous employment with the FMEA and the

proven and accepted valuation leads to reliable

results.

Software solution A software solution was developed. Software support is currently provided by a “home-

made” excel solution.

Robustness of the

results

Technology-independent expert team;

Impartiality.

With technology trusted team.

Integrated into the development process -

important aspects are not lost.


of 163

10.4 Feedback from users

This thesis was carried out in close cooperation with Dräger Safety, Lübeck. The qual-

ity management as well as the product development were mainly involved. In the dis-

cussions, 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 ap-

plication 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


of 163

• 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 inte-

gration 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 assur-

ance.

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


of 163

Dräger Alcotest 3820

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

Table 13: Evaluation of Percentage RPF < 25 for the Dräger Alcotest 3820

55% of ratings need no additional evaluation of detection.

10 1 1 1

9

8

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

1 2 3 4 5 6 7 8 9 10

Dräger alcotest 382056 Percentage <25:

24 # evaluations:

65

55%

145

Occ

urr

ence

[O]

Severity [S]

“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.


of 163

1. Oxygen Self Rescuers Oxy 3000

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

Table 14: Evaluation of Percentage RPF < 25


10 11

9

8

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

1 2 3 4 5 6 7 8 9 10

Oxygen Self Rescuers Oxy 300010 Percentage <25:

8 # evaluations:

64

22%

82

Severity [S]

Occ

urr

en

ce [

O]

“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.


of 163

2. Gas detection X-am 8000

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



10 1 3

9

8

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

1 2 3 4 5 6 7 8 9 10

Gas detection X-am 8000 (first level)69 Percentage <25:

17 # evaluations:

35

121

71%

Severity [S]

Occ

urr

en

ce [

O]

“Dräger X-am® 7000 is the solution for the simulta-

neous and continuous measurement of up to five

gases. It is the ideal companion in a variety of appli-

cations where the reliable detection of oxygen, toxic

and combustible gases and vapors are necessary.


of 163

In addition, evaluations on the next product component level were performed: instru-

ment case, printed circuit board.


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 as-

pects 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.

10

9

8

7 2

6

5 2 3

4 2 8

3 4 2

2 1 8 2

1 1

1 2 3 4 5 6 7 8 9 10

X-am 8000 (body)10 Percentage <25:

4 # evaluations:

21

40%

35

Severity [S]

Occ

urr

en

ce [

O] 10

9

8

7

6

5

4 1

3 2 3 4

2 2 4 8

1

1 2 3 4 5 6 7 8 9 10

X-am 8000 (conductor board)8 Percentage <25:

3 # evaluations:

13

46%

24

Severity [S]

Occ

urr

en

ce [

O]


of 163

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 com-

plexity. It appears likely that the method of this thesis can be adapted for software

development:

Severity = Outcome = Customer / Market Requirements for the software appli-

cation

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


of 163

plan should cover a representative sample of projects. They should be performed by

trained and experienced auditors. An audit questionnaire aligned to the proposed eval-

uation 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 sys-

tem. 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 screen-

ing 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?


of 163

10.6.5 Steering Committee

How can the projects be controlled in a more effective and efficient manner? The tra-

ditional 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.

11 Bibliography

of 163

11 Bibliography

11.1 Literature

Ab Rahman, M.N. 2015, ‘Statistical process control: Best practices in small and me-

dium 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 defined 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.

11 Bibliography

of 163

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 develop-

ment. 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

11 Bibliography

of 163

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

11 Bibliography

of 163

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 Effects 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 man-

agement, 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 man-

agement (D55)’, HENRYSTEWART PUBLICATIONS 1472–5967 Journal of Facilities

Management VOL. 2 NO. 1 PP 85 – 97

11 Bibliography

of 163

Hosseini, M.R. 2014, ‘Riskmanagement in research and development (R&D) projects:

The case of South Australia (D02)’, http://www.researchgate.net/publica-

tion/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

11 Bibliography

of 163

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

11 Bibliography

of 163

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

11 Bibliography

of 163

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 com-

pany (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

11 Bibliography

of 163

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 rela-

tionship 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

11 Bibliography

of 163

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 manage-

ment in projects”

ISO 21500:2012-09 “Guidance on project management”

11 Bibliography

of 163

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)


Prozesse, Prozessmodell“ ("processes, process model")

DIN 69901-3: :2009-01 “Projektmanagement - Projektmanagementsysteme - Teil 3:

Methoden“ („methods“)


Daten, Datenmodell“ („data, data model“)


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-kano-

model/

12 Appendix

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

12 Appendix

of 163

Figure 62: Risk management is important due to application


12 Appendix

of 163



12 Appendix

of 163

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)


12 Appendix

of 163



12 Appendix

of 163

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.

Figure 70: Flowchart of product development: risk evaluation for technology (E:= makes decision, D:= execution, M:= contribution, I:= to be informed)

E D M I Document CommentCRS

legal regulations

market requirements

branch regulations

Excel f ile

basic structure

requirements

Excel f ile

basic structure

TRS

Excel f ile

basic structure

no

yes

table: occurrence

table: severity

Excel f ile

Excel f ile

no

yes

portfolio

E:= trif ft notw end. Entscheidung

D:= Kümmerer für Durchführung

M:= es besteht

Mitw irkungspf licht

I:= ist immer zu informieren

Scope: Abbreviation Terms / def initions

CRS:= customer requirement spec

TRS:= technical requirement spec

USP:= unique selling point

risk matrixFill in the requirements using the basic

structure of the Excel file.

Potential cause can be based on:

• technology is not under controlled

conditions or

• a module or component has no stable

design

1. classification along w ith Kano model

2. def ine USP

3. identification of functional or non-

functional requirement (see Value

Analysis)

evaluate potential risk for potential ef fect

(severity) and potential cause

(occurrence) => RPF for technology

Ris

k e

va

lua

tio

n f

or

tec

hn

olo

gy

e.g. feasibility study, testing, investigation,

research.

If there is no chance for risk reduction, the

technology may not be the best f it.

When RPF > 25 or occurrence (O) > 7 the

expected risk to high. Therefore some

investigation is necessary.

RPN > 25 is a common level (no standard,

no specif ication); just 2 times medium risk

(5x5=25).

Accepted technology should be

documented in a (internal) portfolio; incl. the

test results / description.

requirements to be identified

complete?

requirementsclassified

potential causesfilled in

riskevaluation

high risk?(RPF > 25 or

O > 7)

studiesperformed and risk mitigation potentials

evaluated

approved technology registered

12 Appendix

of 163

Figure 71: Flowchart of product development: concept determination

Figure 72: Flowchart of product development: FMEA – risk evaluation

E D M I Document Commentportfolio

concepts

table: occurrence

table: severity

dynamical matrix

Excel f ile

dynamical matrix

Excel f ile

evaluate potential risk for potential ef fect

(severity) and potential cause

(occurrence) => RPF for each concept.

Compare risk level by dynamical matrix.



M:= es besteht







risk matrix

the determined risk level is just an indicator

for the decision. It´s not the one and only

criterion. May me a more risky concept is

the favourite due to e.g. time to market.

Co

nc

ep

t d

ete

rmin

ati

on

Based on the customer / market

requirements, several concepts w ill be

designed for decision.

Applied technology is consistent w ith

accepted risk level (see portfolio).

conceptsdesigned

riskevaluated

decision on concept made

E D M I Document CommentExcel f ile

no

yes

Veri-Vali-plan

table: detection

no

yes

Excel f ile

dynamical matrix starting product development the risk level

is set; the risk level at the end is also

def ined. At the planned quality gates the

dynamical matrix provides a range of risk.

Thus the progress of the product design is

highlighted.

FM

EA

Risk mitigation can be done by choosing a

more efficient test method or by use of

another more stable technology.

RPN > 125 is a common level (no standard,

no specif ication)

If the test is appropriate to detect the

potential cause it´s a verif ication; if the test

is regarding the failure mode, it´s a

validation.

Bringing all tests together, a verif ication-

validation-plan is generated!

to start FMEA process only results RPF >

25 [S x O] or O > 7 w ill be transferred into

the FMEA form.

RPF > 25 is a common level (no standard,

no specif ication), just 2 times medium risk

(5x5=25).



M:= es besteht







risk matrix

RPN = RPF x D = S x O x D is evaluated.

high risk?(RPF > 25 or

O > 7)

accepted risk, no further action required

testsdefined

high risk?(RPN > 125

or O > 7)

risk mitigationperformed

progressmonitored

detectionevaluated

12 Appendix

of 163

12.4 New Product Development Process at Dräger

12 Appendix

of 163

Figure 73: New Product Development Process (Dräger, German)

12 Appendix

of 163

12.5 Feedback from users

Figure 74: Feedback from users (1/2)

12 Appendix

of 163

Figure 75: Feedback from users (2/2)

12 Appendix

of 163

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 vari-

ous inputs which resulted from such intensive discourses contributed to make this the-

sis 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.

12 Appendix

of 163

Maybe I forgot to mention someone, please accept my thanks to all the support I re-

ceived.

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!

Design and validation of a comprehensive model for risk ...

Documents

Transcript of Design and validation of a comprehensive model for risk ...