design and validation of a comprehensive model for risk
TRANSCRIPT
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
Jacobs University Bremen
Prof. Dr. Julia Bendul Professor of Logistics
Jacobs University Bremen
Prof. Dr. Wilfried Lux Professor of Financial Management and Controlling
University of Applied Sciences St. Gallen (CH)
Dipl.-Chem. Dr. Bernd Siemensmeyer Centre of Competence Accessories & Consumables Dräger Safety AG & Co. KGaA
Date of Defense: January 12th, 2016
0 Statutory Declaration
Page 3 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
Page 5 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
Page 6 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
Page 7 of 163
VDI-GSP Verein Deutscher Ingenieure - Gesellschaft Systementwicklung und Pro-
jektgestaltung
0 Glossary
Page 9 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
Page 10 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
Page 11 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
Page 12 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
Page 13 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 63: Risk management is important due to application ................................. 152
Figure 64: Risk management is important due to application ................................. 153
Figure 65: Risk management is important due to application ................................. 153
Figure 66: Concept Phase – Example: Building a House (1/4) ............................... 154
Figure 67: Concept Phase – Example: Building a House (2/4) ............................... 154
Figure 68: Concept Phase – Example: Building a House (3/4) ............................... 155
0 Tables
Page 14 of 163
Figure 69: Concept Phase – Example: Building a House (4/4) ............................... 155
Figure 70: Flowchart of product development: risk evaluation for technology (E:=
makes decision, D:= execution, M:= contribution, I:= to be informed) .................... 156
Figure 71: Flowchart of product development: concept determination ................... 157
Figure 72: Flowchart of product development: FMEA – risk evaluation .................. 157
Figure 73: New Product Development Process (Dräger, German) ......................... 159
Figure 74: Feedback from users (1/2) .................................................................... 160
Figure 75: Feedback from users (2/2) .................................................................... 161
Tables
Table 1: Table of papers for discussion (1/2)............................................................ 37
Table 2: Table of papers for discussion (2/2)............................................................ 38
Table 3: Extract of Literature Analysis; Method´s Impact to Use .............................. 43
Table 4: Overview to what degree the main 4 demands of ISO 9001 for risk
management mentioned above can be addressed by each of the relevant quality
management and engineering techniques used in technology development and
industrial production ................................................................................................. 47
Table 5: Methods, models and systems as inputs to the risk management tool for
product development, the core objective of this thesis ............................................. 73
Table 6: used sources .............................................................................................. 76
Table 7: generic approach for "severity" and “occurrence” (AIAG 2008) .................. 80
Table 8: Example for risk by maturity of technology (occurrence) ............................ 81
Table 9: Risk by maturity of technology (occurrence) - decoded .............................. 82
Table 10: Example for risk by maturity of technology (severity) ................................ 83
Table 11: Risk to market success (severity) – decoded ........................................... 84
Table 12: Comparison of “RAPIDO“ and the concept of this thesis ........................ 128
Table 13: Evaluation of Percentage RPF < 25 for the Dräger Alcotest 3820 .......... 131
Table 14: Evaluation of Percentage RPF < 25 ....................................................... 132
Table 15: Evaluation of Percentage RPF < 25 ....................................................... 133
Table 16: Evaluation of Percentage RPF < 25 ....................................................... 134
0 Abstract
Page 15 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
Page 16 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
Page 17 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
Page 18 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
Page 19 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
Page 20 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
Page 21 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
Page 22 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
Page 23 of 163
1 Motivation and Problem Description
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
1 Motivation and Problem Description
Page 24 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
1 Motivation and Problem Description
Page 25 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.
1 Motivation and Problem Description
Page 26 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.
1 Motivation and Problem Description
Page 27 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
1 Motivation and Problem Description
Page 28 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.
1 Motivation and Problem Description
Page 29 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
1 Motivation and Problem Description
Page 30 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)
• DIN 69901-2:2009-01 “Projektmanagement - Projektmanagementsysteme -
Teil 2: Prozesse, Prozessmodell“ (processes, process model)
• DIN 69901-3: :2009-01 “Projektmanagement - Projektmanagementsysteme -
Teil 3: Methoden“ (methods)
• DIN 69901-4:2009-01 “Projektmanagement - Projektmanagementsysteme -
Teil 4: Daten, Datenmodell“ (data, data model)
• DIN 69901-5:2009-01 “Projektmanagement - Projektmanagementsysteme -
Teil 5: Begriffe“ (terms)
• ISO 10006:2003-06 “Quality management systems - Guidelines for quality man-
agement in projects”
• ISO 21500:2012-09 “Guidance on project management”
1 Motivation and Problem Description
Page 31 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.
1 Motivation and Problem Description
Page 32 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).
1 Motivation and Problem Description
Page 33 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-
1 Motivation and Problem Description
Page 34 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
1 Motivation and Problem Description
Page 35 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.)
1 Motivation and Problem Description
Page 36 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.
1 Motivation and Problem Description
Page 37 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
1 Motivation and Problem Description
Page 38 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
1 Motivation and Problem Description
Page 39 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.
1 Motivation and Problem Description
Page 40 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)
1 Motivation and Problem Description
Page 41 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.
1 Motivation and Problem Description
Page 42 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)
1 Motivation and Problem Description
Page 43 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
1 Motivation and Problem Description
Page 44 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
Page 45 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
Page 46 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
Page 47 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
Page 48 of 163
• portable or transferable,
• relevant and
• beneficial
for the users.
3 Theoretical background and common practice for risk management in product
development
Page 49 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-
3 Theoretical background and common practice for risk management in product
development
Page 50 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?
3 Theoretical background and common practice for risk management in product
development
Page 51 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
3 Theoretical background and common practice for risk management in product
development
Page 52 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).
3 Theoretical background and common practice for risk management in product
development
Page 53 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
3 Theoretical background and common practice for risk management in product
development
Page 54 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
3 Theoretical background and common practice for risk management in product
development
Page 55 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:
3 Theoretical background and common practice for risk management in product
development
Page 56 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.
3 Theoretical background and common practice for risk management in product
development
Page 57 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
3 Theoretical background and common practice for risk management in product
development
Page 58 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
3 Theoretical background and common practice for risk management in product
development
Page 59 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.
3 Theoretical background and common practice for risk management in product
development
Page 60 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
3 Theoretical background and common practice for risk management in product
development
Page 61 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
3 Theoretical background and common practice for risk management in product
development
Page 62 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
3 Theoretical background and common practice for risk management in product
development
Page 63 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
3 Theoretical background and common practice for risk management in product
development
Page 64 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.
3 Theoretical background and common practice for risk management in product
development
Page 65 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:
3 Theoretical background and common practice for risk management in product
development
Page 66 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.
3 Theoretical background and common practice for risk management in product
development
Page 67 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.
3 Theoretical background and common practice for risk management in product
development
Page 68 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)
3 Theoretical background and common practice for risk management in product
development
Page 69 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]
Functional Requirement
Functional Requirement
Functional Requirement
3 Theoretical background and common practice for risk management in product
development
Page 70 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
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Technologie oder Komponenten / technology or components / TRS [A]
vs.
Kunden- oder Marktanforderungen / Customer- or market requirements / CRS [B]
3 Theoretical background and common practice for risk management in product
development
Page 71 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:
3 Theoretical background and common practice for risk management in product
development
Page 72 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
3 Theoretical background and common practice for risk management in product
development
Page 73 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
Page 75 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
Page 76 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
5 Quantification of Risk Scoring for Technical Product Development Risk
assessment
Page 77 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
5 Quantification of Risk Scoring for Technical Product Development Risk
assessment
Page 78 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
5 Quantification of Risk Scoring for Technical Product Development Risk
assessment
Page 79 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:).
5 Quantification of Risk Scoring for Technical Product Development Risk
assessment
Page 80 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
3 Belästigung Annoyance
4 Belästigung Annoyance
5
Ausfall oder
Verschlechterung von
Sekundärfunktion
Loss or Degradation of
Secondary Function
6
Ausfall oder
Verschlechterung von
Sekundärfunktion
Loss or Degradation of
Secondary Function
7
Ausfall oder
Verschlechterung von
Primärfunktion
Loss or Degradation of
Primary Function
8
Ausfall oder
Verschlechterung von
Primärfunktion
Loss or Degradation of
Primary Function
9
Verletzung von
Sicherheits- / gesetzli-
cher Bestimmungen
Failure to Meet Safety
and / or Regulatory
Requirements
10
Verletzung von
Sicherheits- / gesetzli-
cher Bestimmungen
Failure to Meet Safety
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
Page 81 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:
10 Sehr oft Very High
> 1
in 1
0
Am Markt / in der Wissenschaft neue, nicht
beherrschte Technologie
Technology at theoretical level
6 Risk assessment tool for continuous monitoring of product development risk
Page 82 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
Occurrence / Auftreten / TRS
Likelihood of Failure
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
10 Sehr oft Very High
> 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
Occurrence / Auftreten / TRS
Likelihood of Failure
6 Risk assessment tool for continuous monitoring of product development risk
Page 83 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
Sicherheits- / gesetzli-
cher Bestimmungen
Failure to Meet Safety
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
6 Risk assessment tool for continuous monitoring of product development risk
Page 84 of 163
Table 11: Risk to market success (severity) – decoded
[S]
[B]
1 Keine Auswirkung No effect
2 Belästigung Annoyance
3 Belästigung Annoyance
4 Belästigung Annoyance
5
Ausfall oder
Verschlechterung von
Sekundärfunktion
Loss or Degradation of
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
Severity / Bedeutung / CRS
Severity of Effect on Product
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
Verschlechterung von
Sekundärfunktion
Loss or Degradation of
Secondary Function
7
Ausfall oder
Verschlechterung von
Primärfunktion
Loss or Degradation of
Primary Function
8 gravierend serious
9
Verletzung von
Sicherheits- / gesetzli-
cher Bestimmungen
Failure to Meet Safety
and / or Regulatory
Requirements
10
Verletzung von
Sicherheits- / gesetzli-
cher Bestimmungen
Failure to Meet Safety
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
Bedeutung groß, funktionelle
Beeinträchtigung oder Sicherheitsmängel
High severity, impact to vital function, safety
aspects
Severity / Bedeutung / CRS
Severity of Effect on Product
6 Risk assessment tool for continuous monitoring of product development risk
Page 85 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).
6 Risk assessment tool for continuous monitoring of product development risk
Page 86 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.
6 Risk assessment tool for continuous monitoring of product development risk
Page 87 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
Page 89 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).
7 The Risk Management Model: Complete Design demonstrated
Page 90 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.
7 The Risk Management Model: Complete Design demonstrated
Page 91 of 163
Figure 26: Process “New Product Development” at Dräger Safety AG (Dräger 2012, 2.2) (previous version)
7 The Risk Management Model: Complete Design demonstrated
Page 92 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
7 The Risk Management Model: Complete Design demonstrated
Page 93 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”
7 The Risk Management Model: Complete Design demonstrated
Page 94 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
Technologie oder Komponenten / technology or components / TRS [A]
vs.
Kunden- oder Marktanforderungen / Customer- or market requirements / CRS [B]
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
Bedeutung groß, funktionelle
Beeinträchtigung oder Sicherheitsmängel
High severity, impact to vital function, safety
aspects
7 The Risk Management Model: Complete Design demonstrated
Page 95 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
Technologie oder Komponenten / technology or components / TRS [A]
vs.
Kunden- oder Marktanforderungen / Customer- or market requirements / CRS [B]
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
7 The Risk Management Model: Complete Design demonstrated
Page 96 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
Technologie oder Komponenten / technology or components / TRS [A]
vs.
Kunden- oder Marktanforderungen / Customer- or market requirements / CRS [B]
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
7 The Risk Management Model: Complete Design demonstrated
Page 97 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
7 The Risk Management Model: Complete Design demonstrated
Page 98 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
7 The Risk Management Model: Complete Design demonstrated
Page 99 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.
7 The Risk Management Model: Complete Design demonstrated
Page 100 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.
green = 90; yellow = 60; red = 50 => total = 200
green = 90; yellow = 180; red = 500 => total = 770
The dynamic matrix is a moving target which is adapted the development process, as
knowledge increases. It starts with a target value for number of green, red and red
quadrant in the matrix of severity and occurrence. The question behind this method:
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
7 The Risk Management Model: Complete Design demonstrated
Page 101 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 [%]
7 The Risk Management Model: Complete Design demonstrated
Page 102 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
7 The Risk Management Model: Complete Design demonstrated
Page 103 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]
7 The Risk Management Model: Complete Design demonstrated
Page 104 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
Technologie oder Komponenten / technology or components / TRS [A]
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
High severity, impact to vital
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
7 The Risk Management Model: Complete Design demonstrated
Page 105 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.
7 The Risk Management Model: Complete Design demonstrated
Page 106 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
High severity, impact to vital
function
8
Customer / market
requirement 2
120
Funtion 1.1
5
Verification 1
3
Bedeutung groß,
funktionelle
Beeinträchtigung oder
Sicherheitsmängel
High severity, impact to vital
function, safety aspects
9
Customer / market
requirement 5
108
Funtion 1.2
3
Validation 1
4
mögliche FehlerursachePotential Cause(s)
VermeidungsmaßnahmenPreventive Actions
AO
EntdeckungsmaßnahmenCurrent Design Controls
ED
mögliche FehlerfolgePotential Effect(s) of Failure
BS
möglicher FehlerPotential Failure Mode
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
7 The Risk Management Model: Complete Design demonstrated
Page 107 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.)
Produktvalidierung (Zuverlässigkeitsprüfung,
Entwicklung- oder Validierungstests) vor dem
Designfreeze unter Verwendung von Test auf
Ausfall (z. B. bis Lecks, Ausbeute, Risse usw.)
Product validation (reliability testing,
development or validation tests) prior to
design freeze using test to failure (e.g., until
leaks, yields, cracks, etc.)
Produktvalidierung (Zuverlässigkeitsprüfung,
Entwicklungs- oder Validierungstests) vor dem
Designfreeze mit Pass- / Fall-Tests (z. B.
Akzeptanzkriterien für Leistung,
Funktionsprüfungen usw.)
Product validation (reliability testing,
development or validation tests) prior to
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.).
Produktprüfung / Validierung nach dem
Designfreeze und vor dem Start mit Pass- / Fall-
Tests (Subsystem oder Systemprüfung mit
Akzeptanzkriterien wie Fahr- und Handling,
Versandbewertung etc.).
Product verification / validation after design
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
Produktprüfung / Validierung nach dem
Designfreeze und vor dem Start mit
Degrationstest (Subsystem oder Systemtest
nach Abbauprüfung, z. B. Funktionskontrolle).
Product verification / validation after design
freeze and prior to launch with degration
testing (Subsystem or system testing after
degradation test, e.g., function check).
7 The Risk Management Model: Complete Design demonstrated
Page 108 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
Page 109 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
Page 110 of 163
Figure 46: Dräger Safety Checklist “Kick-off”
8 Project Maturity
Page 111 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
Page 113 of 163
9 Validation of the concept
In the context of validation, the step “determination of technology” is demonstrated for
the example of an alcohol tester using the breathed-out air (“breathalyzer”), or Alco
Screener. For further clarification of the product in the context of this thesis, the Dräger
description for the product is reproduced below:
9.1 Determination of technology
The determination of technology is demonstrated for an alcohol screening device.
Figure 48: DRÄGER Alcotest 7510: “The Dräger Alcotest® 7510 represents the market’s most 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.
9 Validation of the concept
Page 114 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
Technologie oder Komponenten / technology or components / TRS [A]
vs.
Kunden- oder Marktanforderungen / Customer- or market requirements / CRS [B]
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
Behaviour in certain situations? [B] 6
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
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Functional Requirement
Functional Requirement
Functional Requirement
Functional Requirement
DisplayMaintenanceEnergy supplyTechnologie oder Komponenten / technology or components / TRS [A]
vs.
Kunden- oder Marktanforderungen / Customer- or market requirements / CRS [B]
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%
9 Validation of the concept
Page 115 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
Behaviour in certain situations? [B] 6
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]
Performance / Efficiency [B] 9 x 72 x 54
Operation / Environmental Conditions [B] 9 x 54 x 72
Maintainability / Alterability [B]
Portingability / Transferability [B]
Safety Requirements [B]
Correctness [B]
Flexability [B]
Scalability [B]
Boundary Conditions [B]
Approval [B] 10 x 80 x 60Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Functional Requirement
Functional Requirement
Functional Requirement
Functional Requirement
DisplayMaintenanceEnergy supplyTechnologie oder Komponenten / technology or components / TRS [A]
vs.
Kunden- oder Marktanforderungen / Customer- or market requirements / CRS [B]
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%
9 Validation of the concept
Page 116 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
Behaviour in certain situations? [B] 6
FA Ba alarm indicates a positiv alcohol test 7
FA Le user reminded when calibration period is expired 5
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]
Performance / Efficiency [B] 9 x 36 x 45
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
Maintainability / Alterability [B]
Portingability / Transferability [B]
Safety Requirements [B]
Correctness [B]
Flexability [B]
Scalability [B]
Boundary Conditions [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
Functional Requirement
Technologie oder Komponenten / technology or components / TRS [A]
vs.
Kunden- oder Marktanforderungen / Customer- or market requirements / CRS [B]
Housing
7 7
21
Design SizeWeight Handling
5 6
48
Stability
3
Functional Requirement
Functional Requirement
42 49
42
Functional Requirement
Non-Functional Requirements
Non-Functional Requirements 49
Non-Functional Requirements 17
Non-Functional Requirements
Non-Functional Requirements 27
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
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
Behaviour in certain situations? [B] 6
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
Maintainability / Alterability [B]
Portingability / Transferability [B]
Safety Requirements [B]
Correctness [B]
Flexability [B]
Scalability [B]
Boundary Conditions [B]
Approval [B] 10
NFA Ba CE certificate 10
Functional Requirement
Technologie oder Komponenten / technology or components / TRS [A]
vs.
Kunden- oder Marktanforderungen / Customer- or market requirements / CRS [B]
Functional Requirement
Functional Requirement
Functional Requirement
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements
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
9 Validation of the concept
Page 117 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
High severity, impact to vital
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
Middle severity, little to
middle impact to function,
reduction of comfort options5
breath alcohol value not
displayed
Maintenance: firm ware
update by user 6 30
17 5Maintenance: display
service request 7 35
18 5Display: alarm for positive
test 6 30
19 AA 3
20High severity, impact to vital
function 7breath specimen not
accepted
Housing: Handling6 42
21 7Energy supply: Alarm low
battery 4 28
22 7Energy supply: Stable
current 5 35
23 7Energy supply: Measuring
at low temperature 6 42
24 7Maintenance: no mainte-
nance required 4 28
25 7Maintenance: firm ware
update by user6 42
26 7Maintenance: display
service request7 49
27 7Maintenance: display cali-
bration requ.5 35
28 AA 4
What should the product provide to the user?
mögliche FehlerursachePotential Cause(s)
VermeidungsmaßnahmenPreventive Actions
AO
AxBSxO
Nr. noacmögliche Fehlerfolge
Potential Effect(s) of Failure
BS
möglicher FehlerPotential Failure Mode
Which services should be provided?
Input - Processing - Output
Behaviour in certain situations?
9 Validation of the concept
Page 118 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
High severity, impact to vital
function, safety aspects 8level of breath alcohol not
indicated
Housing: Handling
6 48 48
3 8Energy supply: stable
current5 40 40
4 8Energy supply: Measuring
at low temperature6 48 48
5 8Maintenance: display cali-
bration requirements5 40 40
6 8Maintenance: battery
exchange4 32 32
7 8Display: readable at dark
condition4 32 32
8 8Display: readable at bright
condition5 40 40
9 8Display: alarm for positive
test6 48 x 1
redundant system8 2 16
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 30
12 5Maintenance: display
service request7 35 35
13High severity, impact to vital
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
Middle severity, little to
middle impact to function,
reduction of comfort options5
breath alcohol value not
displayed
Maintenance: firm ware
update by user 6 30 30
17 5Maintenance: display
service request7 35 35
18 5Display: alarm for positive
test6 30 30
19 AA 3
20High severity, impact to vital
function7
breath specimen not
accepted
Housing: Handling6 42 42
21 7Energy supply: Alarm low
battery4 28 28
22 7Energy supply: Stable
current5 35 35
23 7Energy supply: Measuring
at low temperature6 42 42
24 7Maintenance: no mainte-
nance required4 28 28
25 7Maintenance: firm ware
update by user6 42 42
26 7Maintenance: display
service request7 49 49
27 7Maintenance: display cali-
bration requ.5 35 35
28 AA 4
Which services should be provided?
Input - Processing - Output
Behaviour in certain situations?
Nr. noacmögliche Fehlerfolge
Potential Effect(s) of Failure
BS
möglicher FehlerPotential Failure Mode
MaßnahmeRecommended
action(s)
BS
AO
RPZRPN
What should the product provide to the user?
mögliche FehlerursachePotential Cause(s)
VermeidungsmaßnahmenPreventive Actions
AO
AxB
SxO
Ko
rr A
xB
lfd
Nr.
9 Validation of the concept
Page 119 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
High severity, impact to vital
function, safety aspects 8level of breath alcohol not
indicated
Housing: Handling
6 48 48Usability test
x 2 96
3 8Energy supply: stable
current5 40 40
Durability testx 2 80
4 8Energy supply: Measuring
at low temperature6 48 48
Cold Chamber testx 2 96
5 8Maintenance: display cali-
bration requirements5 40 40
Durability testx 3 120
6 8Maintenance: battery
exchange4 32 32
Handling testx 3 96
7 8Display: readable at dark
condition4 32 32
Usability testx 2 64
8 8Display: readable at bright
condition5 40 40
Usability testx 2 80
9 8Display: alarm for positive
test6 48 x 1
redundant system8 2 16 0
10 AA 2 0
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 x 2
alarm for firm ware
update 5 4 20 0
12 5Maintenance: display
service request7 35 35
Usability testx 2 70
13High severity, impact to vital
function7
mouth piece not changeable Housing: Handling6 42 x 3
easy use clip
system7 3 21 0
14 7Housing: Size
7 49 49Handling test
x 3 147
15 7Maintenance: no
maintenance required4 28 28
Usability testx 2 56
16
Middle severity, little to
middle impact to function,
reduction of comfort options5
breath alcohol value not
displayed
Maintenance: firm ware
update by user 6 30 x 2
alarm for firm ware
update 5 4 20 0
17 5Maintenance: display
service request7 35 35
Usability testx 2 70
18 5Display: alarm for positive
test6 30 x 1
redundant system8 2 16 0
19 AA 3 0
20High severity, impact to vital
function7
breath specimen not
accepted
Housing: Handling6 42 42
Usability testx 2 84
21 7Energy supply: Alarm low
battery4 28 28
Usability testx 2 56
22 7Energy supply: Stable
current5 35 35
Durability testx 2 70
23 7Energy supply: Measuring
at low temperature6 42 42
Cold Chamber testx 2 84
24 7Maintenance: no mainte-
nance required4 28 28
Usability testx 2 56
25 7Maintenance: firm ware
update by user6 42 x 2
alarm for firm ware
update 5 4 20 0
26 7Maintenance: display
service request7 49 49
Usability testx 2 98
27 7Maintenance: display cali-
bration requ.5 35 35
Usability testx 2 70
28 AA 4
What should the product provide to the user?
Veri ValiED
RPZRPN
mögliche FehlerursachePotential Cause(s)
VermeidungsmaßnahmenPreventive Actions
AO
AxBSxO
Ko
rr A
xB
lfd
Nr.
MaßnahmeRecommended
action(s)
BS
AO
RPFRPF
Veri
Va
li
EntdeckungsmaßnahmenCurrent Design Controls
Nr. noacmögliche Fehlerfolge
Potential Effect(s) of Failure
BS
möglicher FehlerPotential Failure Mode
Which services should be provided?
Input - Processing - Output
Behaviour in certain situations?
9 Validation of the concept
Page 120 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
High severity, impact to vital
function, safety aspects 8level of breath alcohol not
indicated
Housing: Handling
6 48 48Usability test
x 2 96
3 8Energy supply: stable
current5 40 40
Durability testx 2 80
4 8Energy supply: Measuring
at low temperature 6 48 48Cold Chamber test
x 2 96
5 8Maintenance: display cali-
bration requirements 5 40 40Durability test
x 3 120
6 8Maintenance: battery
exchange 4 32 32Handling test
x 3 96
7 8Display: readable at dark
condition 4 32 32Usability test
x 2 64
8 8Display: readable at bright
condition 5 40 40Usability test
x 2 80
9 8Display: alarm for positive
test 6 48 x 1redundant system
8 2 16 0
10 AA 2 0
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 x 2
alarm for firm ware
update 5 4 20 0
12 5Maintenance: display
service request7 35 35
Usability testx 2 70
13High severity, impact to vital
function7
mouth piece not changeable Housing: Handling6 42 x 3
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
maintenance required4 28 28
Usability testx 2 56
16
Middle severity, little to
middle impact to function,
reduction of comfort options5
breath alcohol value not
displayed
Maintenance: firm ware
update by user 6 30 x 2
alarm for firm ware
update 5 4 20 0
17 5Maintenance: display
service request7 35 35
Usability testx 2 70
18 5Display: alarm for positive
test6 30 x 1
redundant system8 2 16 0
19 AA 3 0
20High severity, impact to vital
function 7breath specimen not
accepted
Housing: Handling6 42 42
Usability testx 2 84
21 7Energy supply: Alarm low
battery 4 28 28Usability test
x 2 56
22 7Energy supply: Stable
current 5 35 35Durability test
x 2 70
23 7Energy supply: Measuring
at low temperature 6 42 42Cold Chamber test
x 2 84
24 7Maintenance: no mainte-
nance required 4 28 28Usability test
x 2 56
25 7Maintenance: firm ware
update by user 6 42 x 2alarm for firm ware
update 5 4 20 0
26 7Maintenance: display
service request 7 49 49Usability test
x 2 98
27 7Maintenance: display cali-
bration requ. 5 35 35Usability test
x 2 70
28 AA 4
MaßnahmeRecommended
action(s)
BS
AO
ED
RPZRPN
What should the product provide to the user?
Veri ValiED
RPZRPN
mögliche FehlerursachePotential Cause(s)
VermeidungsmaßnahmenPreventive Actions
AO
AxBSxO
Ko
rr A
xB
lfd
Nr. Ko
rr lfd
Nr.
MaßnahmeRecommended
action(s)
BS
AO
RPFRPF
Veri
Vali
EntdeckungsmaßnahmenCurrent Design Controls
Nr. noacmögliche Fehlerfolge
Potential Effect(s) of Failure
BS
möglicher FehlerPotential Failure Mode
Which services should be provided?
Input - Processing - Output
Behaviour in certain situations?
10 Discussion, Conclusions and Outlook
Page 121 of 163
10 Discussion, Conclusions and Outlook
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).
10 Discussion, Conclusions and Outlook
Page 122 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),
10 Discussion, Conclusions and Outlook
Page 123 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
10 Discussion, Conclusions and Outlook
Page 124 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:
10 Discussion, Conclusions and Outlook
Page 125 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.
10 Discussion, Conclusions and Outlook
Page 126 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.
10 Discussion, Conclusions and Outlook
Page 127 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.
10 Discussion, Conclusions and Outlook
Page 128 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.
10 Discussion, Conclusions and Outlook
Page 129 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
10 Discussion, Conclusions and Outlook
Page 130 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
10 Discussion, Conclusions and Outlook
Page 131 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.
10 Discussion, Conclusions and Outlook
Page 132 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
22% of ratings need no additional evaluation of detection.
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.
10 Discussion, Conclusions and Outlook
Page 133 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
Table 15: Evaluation of Percentage RPF < 25
71% of ratings need no additional evaluation of detection.
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.
10 Discussion, Conclusions and Outlook
Page 134 of 163
In addition, evaluations on the next product component level were performed: instru-
ment case, printed circuit board.
Table 16: Evaluation of Percentage RPF < 25
40% (instrument case) / 46% (printed circuit board) of ratings need no additional
evaluation of detection.
The implication of this result is, that the effort for FMEA will be reduced significantly, of
the order of a factor of 2 (see 10.4 feedback). Meaningless discussions for topics with
low risk are thus avoided. Rather, the discussions remain focused on the critical 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]
10 Discussion, Conclusions and Outlook
Page 135 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
10 Discussion, Conclusions and Outlook
Page 136 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?
10 Discussion, Conclusions and Outlook
Page 137 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
Page 139 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
Page 140 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
Page 141 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
Page 142 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
Page 143 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
Page 144 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
Page 145 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
Page 146 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
Page 147 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
Page 148 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
Page 149 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)
DIN 69901-2:2009-01 “Projektmanagement - Projektmanagementsysteme - Teil 2:
Prozesse, Prozessmodell“ ("processes, process model")
DIN 69901-3: :2009-01 “Projektmanagement - Projektmanagementsysteme - Teil 3:
Methoden“ („methods“)
DIN 69901-4:2009-01 “Projektmanagement - Projektmanagementsysteme - Teil 4:
Daten, Datenmodell“ („data, data model“)
DIN 69901-5:2009-01 “Projektmanagement - Projektmanagementsysteme - Teil 5:
Begriffe“ („terms“)
VDA Band 4 2011; ‚Sicherung der Qualität in der Prozesslandschaft‘
11.3 Internet sources
Stern 2012, ‚…. deutschlands-schlimmste-skandalbauten‘, www.Stern.de
Netzzeitung 2005, ‚BMW will Entwicklungszeiten reduzieren‘, www.Netzzeitung.de
philognosie 2008, ‘Complexity vs. Complicatedness’, www.philognosie.net
Kano model 2015, ‘About the Kano Model’, www.kanomodel.com/about-the-kano-
model/
12 Appendix
Page 151 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
Page 152 of 163
Figure 62: Risk management is important due to application
Figure 63: Risk management is important due to application
12 Appendix
Page 153 of 163
Figure 64: Risk management is important due to application
Figure 65: Risk management is important due to application
12 Appendix
Page 154 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)
Figure 67: Concept Phase – Example: Building a House (2/4)
12 Appendix
Page 155 of 163
Figure 68: Concept Phase – Example: Building a House (3/4)
Figure 69: Concept Phase – Example: Building a House (4/4)
12 Appendix
Page 156 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
Page 157 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.
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 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).
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 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
Page 158 of 163
12.4 New Product Development Process at Dräger
12 Appendix
Page 159 of 163
Figure 73: New Product Development Process (Dräger, German)
12 Appendix
Page 160 of 163
12.5 Feedback from users
Figure 74: Feedback from users (1/2)
12 Appendix
Page 161 of 163
Figure 75: Feedback from users (2/2)
12 Appendix
Page 162 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
Page 163 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!