Application of Lean in Prod Develop

Title:
Application of Lean
Methods in Product
Development Testing
A Case Study from the Politécnica de Madrid
Manufacturing Industry
Master Thesis by:
Daniel Walew Politecnico di Milano
Tutor name: Prof. Alberto Portioli Staudacher,

Politecnico di Milano
Prof. Sergio Terzi,
University of Bergamo
Case Company: MWFL, USA Royal Institute of Technology,
Stockholm
Thesis ID: 2013:143
8th edition, 2011 - 2013
Como, June, 15th, 2013

This page is intentionally left blank.
I Abstract iii
I. Abstract
A broad research foundation exists on Lean management in the manufacturing
context. Furthermore, the implementation of Lean in product development is
discussed by an increasing number of publications. Yet, little documentation of the
specific application in product development testing has been published. This master
thesis provides insights into the specific environment of product development testing
and the application of Lean methods.
Utilizing a systematic literature research, the beginning of this work elaborates

principles of case study research, the context of testing as part of product
development and the Lean management framework. The findings are synthesized
into a priori construct for the case research. Main pillar for this construct is the value
stream mapping method. It combines the analysis of the current state, the
development of the future state and a strategy for the implementation of
improvements.
Central part of this thesis is the in-depth case study of a global operating
manufacturing company in the off-highway machinery market. Three product
development testing sites were visited by the author in order to apply the previously
defined case study framework. Through cross case analysis common process
characteristics of the current state are derived. From a micro level perspective the
relations within and across the testing process are shown.
Needs, values, wastes, interruptions and other process parameters are

systematically analyzed; improvements are elaborated and prioritized to develop a
common future state for the testing process. A partial takt time driven test process
could be developed. To visualize the process task boards were introduced and the
value stream map was digitalized and connected to a management information
system.
The systematic understanding of information needs is a major part of the future state.
A possible implementation strategy is presented in this thesis.
II Acknowledgements iv
II. Acknowledgements
At this point I would like to express my gratitude to all individuals and organizations
who have supported my endeavor that led to this thesis.
First and foremost, I would like to thank all people and the three universities:
Universidad Politécnica de Madrid (UPM), Madrid, Spain
Instituto Politecnico di Milano (POLIMI), Milan, Italy
Royal Institute of Technology (KTH), Stockholm, Sweden
who enable the International Master of Industrial Management (IMIM) program.

This master thesis is the concluding part of a two year intense learning experience in
a truly international context, in class and among class mates, which was an
invaluable opportunity for me.
I would like to express my gratitude to my academic tutors, Prof. Alberto Portioli

Staudacher and Prof. Sergio Terzi, for the support and patience they provided during
the elaboration of this thesis. Their professional advices gave me the possibility to
balance the academic insights gained from this thesis with the solution orientated
company internal work.
I gratefully acknowledge the generous support of the case company. Foremost,

I would like to thank the global director of product testing for the trust and excellent
mentorship provided. I am deeply indebted to the global planning manager who did
not only offer key insights to the case but also arranged an ideal work environment in
the United States headquarters of the case company. Additionally I would like to
thank all individuals who provided their time for interviews and meetings.
Finally, I owe special thanks to my family and friends. My two year international
studies required enduring patience and I am more than grateful knowing that I could
count on you.
III Table of Contents v
III. Table of Contents

I. Abstract .............................................................................................................. 3
II. Acknowledgements ........................................................................................... 4
III. Table of Contents .............................................................................................. 5
IV. List of Tables ..................................................................................................... 8
V. List of Figures .................................................................................................. 10
VI. List of Acronyms and Specific Vocabulary ................................................... 12
1 Introduction ..................................................................................................... 13
1.1 Background ................................................................................................. 13
1.2 Research Objectives and Research Questions ........................................... 14
2 Research Methodology ................................................................................... 15
2.1 Case Study Research Process .................................................................... 15
2.2 Data Collection ............................................................................................ 19
2.2.1 Literature review ................................................................................... 20
2.2.2 Interviews .............................................................................................. 20
3 New Product Development and the Role of Testing..................................... 25
3.1 Product Development Process .................................................................... 25
3.2 Product Testing as Part of New Product Development................................ 30
3.3 Major Consideration for Product Testing Operations ................................... 35
3.3.1 Planning of Product Testing .................................................................. 35
3.3.2 Basic Overview on Different Test Types ............................................... 39
3.4 Summary ..................................................................................................... 43
4 Current State of Lean Product Development in Literature .......................... 44
4.1 Lean Thinking and Where It Came From ..................................................... 44
4.2 Existing Lean Frameworks for Product Development .................................. 45
4.2.1 System Boundaries for Product Development – Lean Framework........ 45
4.2.2 Value and Waste Definition ................................................................... 46
4.2.3 Value Stream in Product Development ................................................. 51
4.2.4 Lean Tools and Principles ..................................................................... 54
4.3 Lean in Product Development Testing......................................................... 57
5 Summary and Research Question Refinement ............................................. 61
6 Case Presentation ........................................................................................... 63
6.1 Company and Industry Background ............................................................ 63
6.2 General Product Development Organization ............................................... 64
6.3 Role of Product Testing Functional Unit ...................................................... 66
III Table of Contents vi
7 Case Analysis – Overview and Methodology ................................................ 67

7.1 VSM as Methodology and Priori Construct .................................................. 67
7.1.1 Current State Analysis .......................................................................... 68
7.1.2 Future State Analysis ............................................................................ 73
7.1.3 Implementation of the future state ......................................................... 74
8 Case Analysis – Current State ....................................................................... 75
8.1 Analysis of Legacy Data .............................................................................. 75
8.1.1 Data Source - Analysis of Legacy Data ................................................ 76
8.1.2 Demand Rate for Test Tasks ................................................................ 76
8.1.3 Process- and Lead Time of Test Tasks ................................................ 78
8.1.4 Summary - Analysis of Legacy Data ..................................................... 80
8.2 Visit of Site A - VSM Workshop, Current State ............................................ 82
8.2.1 Identification of Current Customer Needs – SIPOC .............................. 82
8.2.2 Current State Value Stream Map .......................................................... 82
8.2.3 Summary............................................................................................... 87
8.2.4 Result Limitation ................................................................................... 89
8.3 Visit of Site B - without VSM Workshop ....................................................... 90
8.3.1 Major Findings ...................................................................................... 92
8.4 Visit of Site C - VSM Workshop, Current- and Future State ........................ 94
8.4.1 Identification of Current Customer Needs – SIPOC .............................. 94
8.4.2 Current State Analysis .......................................................................... 95
8.4.3 Following a Test Setup ......................................................................... 99
8.4.4 Summary of Current State Site C........................................................ 101
8.5 Current State - Cross Case Analysis ......................................................... 102
8.5.1 Customer Needs ................................................................................. 102
8.5.2 Cross Case Analysis – Process Steps in Order .................................. 103
8.5.3 Process Matrices and Data Attributes ................................................. 104
9 Case Analysis – Future State and Implementation..................................... 107
9.1 Future State Development ......................................................................... 107
9.1.1 What does the customer really need? ................................................. 107
9.1.2 How often will we check our performance to customer needs? .......... 111
9.1.3 Which steps create value and which steps are waste? ....................... 112
9.1.4 How can we flow work with fewer interruptions? ................................. 116
9.1.5 Workflow Control and Leveling of Workload ....................................... 118
9.1.6 Summary of the Future State and Required Kaizen Activities............. 121
III Table of Contents vii
9.2 Implementation of Future State ................................................................. 126

9.2.1 Review of Test Task, Understanding of Information Needs ................ 126
9.2.2 Setup Test and Machine – Implementation of Visual Management .. 131
10 Reflections and Main Contribution of Research Achievements................ 133
10.1 Answering the Research Questions ....................................................... 133
10.1.1 Processes Assessment ................................................................... 133
10.1.2 Application of Lean Principles in Product Testing ............................ 134
10.1.3 Continuous Improvement ................................................................. 135
10.1.4 Application of Value Stream Mapping in Product Testing ................ 137
10.2 Contribution of the Work......................................................................... 138
10.3 Limitations .............................................................................................. 139
10.4 Further Research ................................................................................... 139
11 References ..................................................................................................... 141
12 Appendix ........................................................................................................ 147
12.1 Semi Structured Interview Sheets .......................................................... 147
12.2 Structured Observation Sheet ................................................................ 148
12.3 Data sources for current state analysis overview ................................... 151
12.4 Online Checklist implemented in Share Point ........................................ 152
12.5 Checklist points for test review – Data gathering overview .................... 152
12.6 Kaizen: Checklist for Observation writing ............................................... 153
12.7 Table used for Waste Assessment ......................................................... 153
IV List of Tables viii
IV. List of Tables

Table 2-1, Process of Building Theory from Case Study Research and
application in this thesis .......................................................................... 16
Table 2-2, Data collection methods used in the thesis ............................................. 19
Table 2-3, Interview, Basic Overview ....................................................................... 20
Table 2-4, Interviewing, possible pitfalls and problems ............................................ 21
Table 3-1, “Fundamental elements of new product development” ............................ 26
Table 3-2, Stage activities and gate deliverables of a typical Stage-Gate®
System .................................................................................................... 28
Table 4-1, Value attributes of product development task .......................................... 47
Table 4-2, Value assessment for product development testing ................................ 48
Table 4-3, Product Development Waste ................................................................... 49
Table 4-4, Waste assessment framework as FMEA approach ................................. 50
Table 4-5, Major Lean tools used in production environment ................................... 54
Table 4-6, Lean PD approaches ............................................................................... 56
Table 7-1, Steps of case study research .................................................................. 67
Table 7-2, Possible data matrices by Locher (2008, p.26) and application in the
case study ............................................................................................... 69
Table 7-3, Tools for value stream walk through ........................................................ 71
Table 7-4, Overview on the future state analysis steps used in this case study
work ........................................................................................................ 73
Table 8-1, Average demand for new test tasks per day ........................................... 76
Table 8-2, Most time consuming test activities combined from P/T and L/T for
FP and FH Platform ................................................................................ 81
Table 8-3, Summary of information sources across the three visited test sites ...... 102
Table 8-4, Identified internal / external customers and the required outputs of
the visited product testing sites A and C. .............................................. 102
Table 8-5, Value Stream Process Step Cross Case Overview ............................... 104
Table 8-6, Matrices of each site in comparison ...................................................... 105
Table 9-1, Value aspect of the process steps “Approve test requirement” and
“Write test task” ..................................................................................... 107
Table 9-2, Value aspect of the process step “Review Draft Test Task” .................. 108
Table 9-3, Waste aspect of the process step “Writing Test Task” and “Review
Draft Test Task” .................................................................................... 110
IV List of Tables ix
Table 9-4, Kaizen Ideas collected for the process steps: “Writing TT” and
“Review Draft TT”.................................................................................. 111
Table 9-5, Required Kaizen to enable constant performance to customer needs. . 112
Table 9-6, High priority waste aspects leading to workflow interruptions ................ 116
Table 9-7, List of required Kaizen activities for the future state of MWFL testing
process, part 1 ...................................................................................... 122
Table 9-8, List of required Kaizen activities for the future state of MWFL testing
process, part 2, 48 waste aspect were sorted out due to a priority
index less than 12 as assessed in 9.1.3. .............................................. 124
Table 9-9, Direct time reduction from process improvement .................................. 125
Table 12-1, Structured observation sheet, page 1, basic information, time data,
input flow ............................................................................................... 148
Table 12-2, Structured observation sheet, page 2, output, critical drivers, rough
value assessment ................................................................................. 149
Table 12-3, Structured observation sheet, page 3, value and waste assessment .. 150
Table 12-4, Overview, data sources for current state analysis ............................... 151
Table 12-5, Table used to assess waste priority in the VSM .................................. 153
V List of Figures x
V. List of Figures
Figure 3-1, An overview of the Stage-Gate® System ............................................... 27
Figure 3-2, Product development process ................................................................ 28
Figure 3-3, Spiral development - a series of "build-test-feedback-revise"
iterations in parallel to a Stage-Gate® process....................................... 31
Figure 3-4; Spiral model of software development ................................................... 32
Figure 3-5, The basic V-model of the Systems Engineering Process ....................... 33
Figure 3-6, “Total time variation due to variation in process milestones” .................. 37
Figure 3-7, “Theoretical product development cost versus reliability curve” ............. 38
Figure 3-8; Life cycle cost methodology flow for testing planning ............................. 38
Figure 3-9, Relation between design verification ranges .......................................... 41
Figure 4-1, “System Boundaries of the product development system“ ..................... 45
Figure 4-2, “The Value Creation Process” ................................................................ 46
Figure 4-3, 13 Lean PD principles of Morgan and Liker (2006) and number of
literature sources with comparable findings ............................................ 55
Figure 6-1, Typical forest harvester machine............................................................ 64
Figure 6-2, Product development process at MWFL ................................................ 65
Figure 6-3, Simplified product development organigram of MWFL and case
study focus shaded ................................................................................. 65
Figure 7-1, Initial process order assessment in VSM Workshop .............................. 69
Figure 7-2, Process matrices for an individual process step used in the VSM of
this thesis ................................................................................................ 70
Figure 8-1, FP Platform - Demand rate for new test tasks per day ........................... 77
Figure 8-2, FH Platform - Demand rate for new test tasks per day ........................... 77
Figure 8-3, Boxplot of process time (P/T) of test for the Forest Harvester (FH)
Platform in days for coded test types ...................................................... 79
Figure 8-4, Calculated contribution to the overall accumulated test time for each
coded test type group of the Forest Harvester (FH) Platform ................. 79
Figure 8-5, Histogram of process time for the Forest Planter (FP) platform tests ..... 80
Figure 8-6; SIPOC framework created during the VSM workshop at Site A ............. 82
Figure 8-7; Current State map of product testing site A of MWFL ............................ 85
Figure 8-8, Current State map of product testing site B of MWFL ............................ 93
Figure 8-9; SIPOC framework created during the VSM workshop at site C.............. 95
Figure 8-10, Current State map of product testing site C of MWFL .......................... 97
V List of Figures xi
Figure 8-11, Task board to follow the test setup ..................................................... 100
Figure 9-1, Part of current state VSM of site A with waste highlighted ................... 109
Figure 9-2, Waste priority, severity and value of the process steps in the product
testing value stream .............................................................................. 113
Figure 9-3, Value aspects identified and their summarized assessment value....... 114
Figure 9-4, Waste aspects identified, summarized in priority index PI .................... 114
Figure 9-5, Decoupling point Lab Task List in Product Testing............................... 117
Figure 9-6, Product testing operational value stream using takt time and task
board..................................................................................................... 119
Figure 9-7, Future state value stream map for MWFL product testing operations .. 123
Figure 9-8, Improvement and Kaizen schedule for test task review ....................... 127
Figure 9-9, Information areas required for test task definition and review
checklist derived from case research, ................................................... 127
Figure 9-10, Results of rough comparison of IT tools available at MWFL, Target:
find a system that allows an implementation of shared checklists. ....... 128
Figure 9-11, A3 report of the implementation of visual management for test and
machine setup....................................................................................... 132
Figure 12-1, Semi structured interview sheet, example .......................................... 147
Figure 12-2, Online Checklist implemented in MS Share Point .............................. 152
Figure 12-3, Data gathering overview, Number of sources per Checklist Item
identified ............................................................................................... 152
Figure 12-4, A3 summary report for Kaizen: “Improve Quality and Time of
Observation Writing” ............................................................................. 153
VI List of Acronyms and Specific Vocabulary xii
VI. List of Acronyms and Specific Vocabulary

Acronyme Explanation
5S Workplace organization method
BOM Bill of material
CHE Chief Engineer
D. Eng. Design Engineers
EOQ Economic Order Quantity
ETF Economic Test Frequency
EU European Union
FH Forest Havester (Product Platform of MWFL)
FMEA Failure Mode and Effect Analysis
FP Forest Planter (Product Platform of MWFL)
GES Global Engineering System
GTS Global Test System
KBS Knowledge-based system
L/T Lead Time
LCC Life cycle cost
LTE Leading Test Engineer
MS Microsoft Corporation
MWFL Mid Western Forest and Lawn Ltd
(Diguised Case Company Name)
NPD New Product Development
NVA Non Value Added5
P/T Process Time
PD Product Development
PDCA Improvement cycle: Plan, Do, Check, Act
PDMA Product Development & Management Association
PDVSM Product Development Value Stream Map
PE Program Engineer
PT Product Testing
PT Product Testing (Functional Unit in Case Organization)
PT Site Mngt Product Testing Site Manger
SAP ERP System
SIPOC Supplier-Input-Process-Output-Customer framework
Takt Time period used to syncronize activities
TDB Test Date Base
TE Test Engineer
Tech Assist Blue Collar Test Technician
TP Global Test Planning Manager
TPDS Toyota Product Development System
TPM Test Project Manager
TPS Toyota Production System
TSM Test Site Manager
TT Test Task
VISIO Microsoft Visio 2013, visualisation software
VSM Value Stream Map
1 Introduction 13
1 Introduction
The global competition in manufacturing industries is leading companies to closely
examine all areas of business operations. New product development is a major driver
of the value a company can provide to the customer. However, the development time
and required resources to achieve products fulfilling customer needs are major
investments.
To meet the challenges of the increased market competition, the implementation of
Lean in product development is discussed by an increasing number of publications.
Yet, little documentation of the specific application in product development testing
has been published.
Testing is often the first realization of design in a real world product or system and
therefore a critical element for a successful product release. Although computer
aided engineering analysis has become a powerful tool to meet the product
development challenges, physical testing remains an important part of new product
development processes with changing requirements.
This master thesis provides insights into the specific environment of physical product
development testing and the application of Lean methods. Literature research
provides a set of analytical tools to analyze the process and to elaborate
improvement strategies. The framework is applied on a case study, involving three
product testing sites of a global operating manufacturing company in the off-highway
machinery market.
1.1 Background
In various cases early phase product development projects contain design problems
leading to mismatch with customer needs, technical errors, problems regarding
manufacturing and maintainability of the product (Thomke & Bell 2001). Testing,
Verification and Validation, as methods to detect and resolve these problems, have a
central role in new product development process (Cooper & Edgett 2008; Ulrich &
Eppinger 2004; Wheelwright & Clark 1992b)
Physical testing as a part of new product development has to be clearly distinguished

from repetitive testing as part of a manufacturing process quality control. This thesis
focuses on the new product development testing which delivers information for a
1 Introduction 14
product development process in order to ensure a product that meets customer

requirements. The case introduction chapter will clarify the different deliverables of
testing and the interrelation with the new product development process.
The thesis work was performed in a context of an industrial manufacturing company
operating on a business to business market. Hence, the findings of this thesis have to
be distinguished from testing in software development, pharmaceutical development
or other non-manufacturing companies.
1.2 Research Objectives and Research Questions

The intention of this thesis is to provide case based insights about the application of
Lean management principles in the context of testing as part of new product
development.
Various approaches towards process assessment and improvement are discussed in
the literature. New product development processes are a heavily researched field of
management science due to their strategic importance for a company. For the
specific area of product testing, however, the literature base is less dense. The
applicability of Lean management principles in testing is underrepresented. In this
thesis the author has the objective to provide further evidence on the applicability of
Lean management.
1. How can the internal process of testing as part of new product development be
assessed in a manufacturing company?
2. To which extend are Lean principles able to improve the performance of a
testing process?
3. How can process improvements be part of a continuous improvement effort?
The more specific objectives can be stated as following:
- Define the role of testing as part of a new product development process and
elaborate measures that define the performance of the testing process.
- Find methods that allow a process analysis and improvement in the context of
testing.
- Apply the most suitable method in a company case study, generate results and
discuss the findings.
- Reflect on the insights gained from the case study research.
2 Research Methodology 15
2 Research Methodology
This thesis is mainly qualitative in its nature. Quantitative data is partly used for the
exploratory case study.
The research view of this thesis regards the business processes in product
development mainly as information and knowledge exchange between individuals
and groups in an international business environment; hence an exploratory,
interview-based case study design was found to be a disciplinary convention (Barratt
et al. 2011; Piekkari et al. 2009). Some of the most widely-cited accounts for the
inductive case study research method (Yin 2003) and (Eisenhard 1989) were
followed but needed some adaptation in order to server the predefined single case
setting. The main target of the case study is to provide insights into the application of
Lean thinking in the testing part of a new product development process.
2.1 Case Study Research Process

The eight step Process of Building Theory from Case Study Research of (Eisenhard
1989) was used and slightly adapted in order to fit the research goal. Table 2-1
shows the comparison of the individual research process steps, the applied methods
and in which chapter of the thesis they can be found. It was planned to perform at
least two iterations of step 1 to step 6 due to the complexity of the research topic and
the low likelihood of developing fully satisfactory prior constructs and instruments for
the field data collection. The iterative process of case study research is also
mentioned in (Tan 2011) as a way to improve the “theoretical confidence” in
exploratory case research.
Research Process Research process

Methods Used Chapter
Eisenhard in this Thesis
1 Getting Started Background and Literature Review 3
Definition of research initial framework VSM Guideline 4
question Research Question 5
Possibly a priori
construct
2 Selecting Case Predefined Single - -
Case,
3 Crafting Instruments - VSM as Framework Literature Review 7
and protocols - Interview structure Interview
Multiple Data - Observation Legacy Data
Collection Methods structure Screening
Qualitative/Quantitative
4 Entering the Field 2 VSM Workshops VSM 8.2
Overlap data collection Semi Structured Interview 8.3
and analysis Interview/ Observation 8.4
Flexible and Observation
Opportunistic data
collection
5 Analysing of Data Within Case Analysis Interview 8.5
Within-case analysis Quantitative data
Cross Case pattern review
search
6 Shaping Hypotheses Future state definition Application of Lean 9
Iterative tabulation of for the case company principles on future
evidence state of testing.
Replication, not Implementation plan Value, Waste
sampling, logic across for future state Assessment and
cases Prioritization
Search evidence for
“why” behind
relationships
7 Enfolding Literature Answering and Case Review, 10.1
Comparison with discussion of Literature review
conflicting literature research question
Comparison with
similar literature
8 Reaching Closure Contribution, 10.2
Limitation and 10.3
Further Research 10.4
Table 2-1, Process of Building Theory from Case Study Research and application in this thesis, based
on (Eisenhard 1989)
Following a more detailed description of the individual steps:
1. Getting Started and 2. Selecting Case

Before the beginning of this thesis work, the research topic was specified by a project
definition in the case study company. For that reason the case selection of step 2
was pushed forward. This phenomenon has been reported as being a common issue
for young researchers and could also be called Step 1: access negotiation
(Tan 2011). It has to be admitted that the limitation to a single case, clearly reduces
the possibility of building theory from the case study. Nevertheless, the structured
process of case study research was chosen, to allow comparison with similar
research in other cases.
To achieve a foundation for the formulation of a research question a basic
investigation of the topic background, the fundamental aspects of process implication
in the case company and relevant boundaries were worked out. The Lean product
development framework was found to be an applicable priori construct in order to
focus attention and structure the gained knowledge. Also Value Stream Mapping
(VSM) provided an initial starting point. However, with the given constraints in the
case company adaptations to the framework were needed, which were partly
contradicting the Lean product development framework. As a result of this initial
learning process, the research questions were updated after the literature review in
chapter 5.
3 Crafting Instruments and Protocols

As stated by (Eisenhard 1989) typically multiple combined case data collection
methods are used. A disciplinary convention is that interviews are the very dominant
source of data collection in case studies published in international business- and
information systems journals (Dube´ & Pare´ 2003; Piekkari et al. 2009). Hence,
interviews were selected to be a major pillar of the conducted research combined
with observations. Eisenhard (1989), however, pointed out the “highly synergetic”
combination of qualitative and quantitative data sources. For that reason and to serve
the specific research question “To which extend are Lean principles able to improve
the performance of a testing process?” legacy data was also analyzed.
To focus the attention of the research and to facilitate the data collection of the field
work, a value stream mapping (VSM) workshop was prepared. All instruments and
protocols will be presented more in depth in the following chapters.
4 Entering the Field

“A striking feature of research to build theory from case studies is the frequent
overlap of data analysis with data collection. “(Eisenhard 1989) The selected VSM
method gave the possibility to assess a basic framework of the process that was
under investigation from a management perspective, followed by specific semi-
structured interviews and observations of relevant process activities and participants
in order to validate and improve framework. It became clear that certain process
steps had different characteristics depending on the point of view of the interviewee.
In these situations the VSM method allowed quick adaptation and emphasis on
critical aspects without losing the connection to a broader view. The possibility to
make adjustment during the data collection process turned out to be a key feature of
the field work as mentioned by (Eisenhard 1989). A daily log of the field work was
maintained to support the subsequent data analysis.
5 Analyzing of Data
The first step of the within case data analysis was a write-up of the interview and
observations performed. In parallel the different draft versions of value stream maps,
which were created during the field work in paper and pencil technique, were merged
into an overall value stream map. Especially qualitative information on process flow
from the interviews was integrated into the value stream map. When observations of
complete process steps were available, specific matrices could be measured.
However, the low number of samples did not allow validating all relevant matrices of
the value stream map in general. A second and third field visit was made to broaden
the case understanding.
6 Shaping Hypotheses
Eisenhard suggests a two-step process of shaping hypotheses. In the first step a
refined definition of the priori construct is needed for which evidence can to be built
by measurement. In the second step the constructs need to be evaluated against the
results derived from each case.(Eisenhard 1989)
Main focus of this thesis is answering the research questions through case study
research. The possibility for generalized hypothesis shaping and verification is limited
by the mainly qualitative data, the limitation on one case company and the five month
duration of the complete thesis project. Cross case comparison or long term
longitudinal study should be addressed in following work. The in-depth insight the
presented thesis offers on the product testing environment builds a foundation for
further research.
7 Enfolding Literature
“An essential feature of theory building is comparison of the emergent concepts,
theory, or hypotheses with the extant literature. This involves asking what is this
similar to, what does it contradict, and why.”(Eisenhard 1989, p.544)
After the actual case study research the research questions are answered. Each
question is discussed considering supporting and contradicting literature where
applicable.
8 Reaching Closure
A major limitation for the thesis work was the limited time range of 5 months. So the
step of iteration between data analysis and theory building was given by external
boundary. However, the target of the thesis was to reach a level of acceptable
theoretical saturation. Since the definition of “acceptable“ is not exact a detailed
review of limitation and suggestions for further research is included in this thesis.
2.2 Data Collection

During the different phases of the work the data collection methods and tools were
selected depending on the applicability, availability of data and the highest
significance of results. The following Table 2-2 gives an overview on the data
collection methods applied in the different parts of the presented master thesis.
Chapter 2 3 4 5 6 7 8 9 10
Literature Review x x x x x x x x
Interview x x x
Observation x
Data Analysis x x
Table 2-2, Data collection methods used in the thesis
2.2.1 Literature review

Major parts of this thesis are derived from intensive literature research. Literature was
used to provide a basic foundation for the research and to perform derived results
with the extant literature. In addition, the academic methods used were derived from
literature review in order to align with the rigor of case study research. The literature
was initially searched by key words in Google Scholar. Further related sources where
either taken from the resource section of sighted articles or by following related
reading suggestions of the journal publisher.
Sources of literature search were:

- POLIMI, KTH and UPM libraries by using their online catalogs of journals
- Google Scholar
- Elsevier, Sage, JSTOR and other journal publishers as required
2.2.2 Interviews
The central importance of interviews for successful case study research was shown
by a review of leading operations management and international business journals
(Barratt et al. 2011; Piekkari et al. 2009). The basic information about the interviews
conducted for this work can be found in Table 2-3.
Number of Interviews: 30 (during site visits: 21, during Preparation: 7)
Who conducted the Interview: The author
Who was interviewed: Test management local and global, Test planning
manager, leading test engineers, design
engineers, test project manager, test engineers,
test technicians
Type of Interview Semi structured
Table 2-3, Interview, Basic Overview
Although interviews appear often as a straight forward research method and an

excellent method of data gathering, difficulties, problems and pitfalls are likely to be
underestimated (Myers & Newman 2007). Myers and Newmann summarized the
possible pitfalls and problems from the work of (Webb et al. 1966) in Table 2-4.
Artificiality of the interview

Interrogating with a stranger under time pressure is an artificial situation that the
researcher should be aware of.
Lack of trust
Information that is considered “sensitive” by the interviewee might not be disclosed.
In this case the data gathering remains incomplete.
Lack of time
If the time is not sufficient to gather all relevant information, the interview remains
incomplete. A further effect can be that the interviewee gets into a stressful
situation under which opinions are made up. In this case the data gathered is not
reliable.
Level of entry
This pitfall warns the researcher about the difficulty to conduct interviews with
senior managers if the company is entered in a lower level.
Elite bias
By interviewing solely high level employees the researcher might fail to gather data
of the broader situation (Miles & Huberman 1994). In addition, the risk is given to
overweight data from high status, well-informed interviewees and to undervalue
data from less articulated, lower status ones (Heiskanen & Newman 1997).
Hawthorne effects
A change of the object of investigation can happen due to the presence of the
researcher. The intrusive character of qualitative interviews can lead to interference
with peoples’ behavior (Fontana 2000).
Constructing knowledge
If an interviewer triggers reflection on the side of the interviewee, by asking specific
but open formulated questions about issues that were never actively considered by
the interviewee, knowledge is actively constructed. Although reflection is a
declared target for the interview, a risk is given that interviewees construct logical
and consistent, but unrealistic stories, to appear knowledgeable and rational.
Ambiguity of language
‘‘Asking questions and getting answers is a much harder task that it may seem
at first. The spoken or written word has always a residue of ambiguity, no matter
how carefully we word the questions or how carefully we report or code the
answers’’(Fontana 2000, p.645).
Interviews can go wrong
Situations that lead to one of the named problems and pitfalls in very strong way or
even end up with emotional conflict situations might be abandoned.
Table 2-4, Interviewing, possible pitfalls and problems, (Myers & Newman 2007; Webb et al. 1966)
The listed potential problems and pitfalls of interviews show the importance to
understand the required interview skills as good as possible before entering the field
in order to gain confidence on the acquired results.
For that reason, the interviews conducted for this thesis were designed according a
seven ‘Guidelines’ recommendation for qualitative interviewing by (Myers & Newman
2007). In following Myers and Newman’s interview guidelines (in italic) are compared
to the actual application in this thesis.
1. Situating the researcher as actor

In this part of the framework the interviewer “situates” him selves in a social context
to the interviewee.
The author of the presented thesis conducted the interviews as a sole researcher,
however, with specific management assignment to investigate process reality in
operations. As such, he was an unknown colleague from the headquarters of the
case company, not a consultant. Being a graduate student with specific work
experience in the industrial field of the case company, was another characteristic of
the researcher. This is how the researcher was presented to the group during a
morning briefing at the first day. An unstated, but noticeable aspect of the role was
being male, around late 20’s, foreigner of German origin.
2. Minimize social dissonance

The interviewer has to avoid all aspects of social dissonance by managing first
impression, following a dress code and using the appropriate language and
terminology.
Asking the headquarters management about the dress code in the site turned out to
be very valuable. Since the interviews were conducted in the workshop area offices,
appropriate safety equipment was brought to the meeting. Not only to be save, but
also to avoid the social dissonance of not fulfilling safety regulations. A preview of
current projects and major documented workflows gave a good foundation to
understand the terminology during the interviews. Specific technical pre knowledge
allowed formulation of questions with practical relevance. To avoid distracting the
interviewees from their normal activities, the interviews were conducted at their desk
or in some cases during an activity that required low attendance. In this case the
interview had a strong observational component.
3. Represent various “voices”

This point is also known as “triangulation of subjects” and an important consideration
to avoid elite bias. Informants can be differentiated as guides, stars or gatekeepers.
During the field work an initial value stream mapping event was held by the author.
Together with a manager the different process steps were summarized, arranged
according to the workflow and matrices defined. Having this VSM as guidance
allowed organization of further interviews with the responsible process owners. The
interviews were conducted with the site management, technical experts, lab
engineers and technicians, with particular attention to process owners from
connected process steps. That way, statements about information flow could be
triangulated from a sender and receiver perspective.
4. Everyone is an interpreter
Mayer and Newman used this guideline to create awareness about the interpretive
nature of interviews from the side of the researcher, the interviewee and the audience
reading the results.
In this aspect the lack of recording possibilities has to be mentioned, which was not
allowed due to the behavioral code of conduct. However, although the error of data
gathering due to interpretation increases, a recording would have increased the
social dissonance error. By using semi structured interviews and notes the data
quality could be improved. In any case, an interview team with a role for asking
questions and observing behavior and a role to take notes would have been first
choice. (See: 7.1.1, page: 71 for further detail)
5. Use Mirroring in questions and answers

To avoid the impact of the interviewer by asking leading questions or other pitfalls
related to the question formulating, (Myers & Newman 2007) suggests using certain
questioning frameworks.
Some informal questions and topics were usually used to open the information flow
and to create a positive environment. The questions of the semi-structured interview
where arranged in blocks related to the research questions beginning with a simple
reflection of roles and tasks.
6. Flexibility
The method of semi-structured and unstructured interviewing requires flexibility and
improvisation in order to follow the most interesting lines of information. Surprises
should be expected.
For the interviews of this research a semi-structured approach was followed. A

question sheet was prepared (12.1) with questions that were formulated according to
the information required to complete the current state VSM. The sheet, however, was
equipped with space for additional notes. The flexible adaptation of the sheet made it
possible to follow only questions of areas where the interviewee was knowledgeable.
It turned out to be an invaluable advantage for the field work to have a prepared
question sheet with the flexibility of adaptation, because it enabled a large number of
interviews often triggered by the advice of a previous informant without losing the
focus of the research. Marschan and Piekkari (2004) referred to this effect as “snow-
ball” sampling.
7. Confidentiality of disclosure
Researcher transcripts, record and technology have to be kept confidential and
secure.
Although the non-disclosure agreement was part of the basic assessment negotiation
for the research in the case company, the confidentiality of the interview was
explained to the interviewees during the introductory phase. In one case the
interviewee even asked for a reinsurance of the confidentiality after the interview. The
hierarchical pressure made the disclosure of information obviously uncomfortable for
the lower level employee.
3 New Product Development and the Role of Testing 25
3 New Product Development and the Role of Testing
3.1 Product Development Process

Before selecting and applying methods of process analysis and improvement in this
thesis, a definition of a product development system is derived in this chapter. The
chapter does not intend to provide a holistic overview on existing product
development process concepts, but defines the context in which the main area of this
research is set.
Several definitions of new product development (NPD) are present in the academic
literature and the practitioner context of the industry.
For the Product Development & Management Association (PDMA) a NPD process is
a set of tasks and steps that describe the repetitive conversion of ideas into salable
products or services (PDMA 2006).
An only slightly more specific definition for new product development is given by
Ulrich and Eppinger who underline the starting point of NPD as ‘perception of market
opportunity’ and the end as ‘production, sale and delivery of a product’
(Ulrich & Eppinger 2004).
Oppenheimer addressed the wide definition space by writing: “Product Development
(PD) is a broad term that includes all conceivable tasks involved in the design
of technology-based objects or missions which provide value to the product
stakeholders”(Oppenheim 2004, p.353).
In fact, the stream of articles on NPD published in leading journals has grown in
absolute number and percentage from 1989 to 2004 (Page & Schirr 2008). Although
a review of 815 scientific articles could identify “encouraging signs of a maturing
discipline”(Page & Schirr 2008, p.232), growing sophistication of NPD models and
changing market environment make NPD research still highly valid.
Loch and Kavadias underline the evolutionary character of new product development
by stating that “no ‘theory of NPD’ exists, and there is no consensus on whether one
can and should exist.”(Loch & Kavadias 2008, p.1)
Although several models for new product development management have been
developed the basic sequence of activities during the development process are
similar (Ulrich & Eppinger 2004). The early phase of the new product development
processes evaluates the concept in terms of market opportunity and customer needs.
A selection process compares different concepts and choses the most promising.
After the selection a detailed design phase begins which has to ensure that product
or services can be offered to customers. Table 3-1 lists the fundamental NPD
process phases as identified by Loch and Kavadias (2008).
Fundamental elements of new product development
A variant Identifies new combinations of technologies,
generation process processes, and market opportunities with the potential
to create economic value.
Variants are generated by directed search and ‘blind’
combination of unrelated elements (creativity)
A selection process Chooses the most promising among the new com-
binations for further investment (of financial,
managerial, physical, and/or human resources)
according to consistent criteria.
A transformation Converts (‘develops’) opportunities into
process economic goods and codified knowledge (embodied in
a design) – products or services to be offered to
customers.
A coordination process Ensures the information flow, collaboration,
and cooperation among multiple parties, involved in the
NPD activities
Table 3-1, “Fundamental elements of new product development”(Loch & Kavadias 2008, p.4)
The possibility to distinguish different phases of a product development made stage

models of NPD early a highly researched topic. However, by reviewing 815 journal
articles between 1989 and 2004 Page and Schirr found that stage process research
has decreased and research streams like “Strategy”, “Integration”, “Teams” and
“Radical” became top four research streams (Page & Schirr 2008, p.243).
Although the research interest in ‘stage-gate’ product development processes has

decreased they still have a primary role in the practical application, often referred to
as ‘Phased Project Planning’, ‘Gate Systems’, ‘Stage-Gate Systems’ or ‘Phase-Gate
Systems’. The process might also use company specific terminology.
Their common process characteristic are stages in which activities are performed and
gates in which results are reviewed to take a go, kill, hold or recycle decision
(Cooper 1990). Figure 3-1 gives an overview of a typical stage-gate system.
Figure 3-1, An overview of the Stage-Gate® System (Cooper 1990)
Since multiple projects of new product development can pass the staged process in
parallel as part of an overlapping or concurrent project design (PMI 2011), the
individual project leader has to ensure that activities are performed during the stages
and has to present specified deliverables during the gate screening. In the following
Table 3-2 the major activities of each stage and gate as suggested by Cooper 1990
are summarized.
Stage or Gate Activities and Deliverables
Idea New product idea.
Gate 1 Initial screen: first decision to commit resources to the project
Also considered are ‘must meet’ and ‘should meet’
criteria like strategic alignment, project feasibility, magnitude of
the opportunity, differential advantage, synergy with the firm’s
core
business and resources, and market attractiveness.
Financial criteria are not measured.
Stage 1 Preliminary assessment to determine:
- Project’s technical facts
o development and manufacturing feasibility
o cost and time of executing
- Project’s market facts
o market size, market potential, likely market
acceptance
Gate 2 Second Screen: similar to gate 1, in addition different
‘should meet’ criteria, dealing with sales force and
customer reaction, a simple financial calculation is assessed.
Stage or Gate Activities and Deliverables

Stage 2 Definition: still a stage prior to product development in which:
- Detailed project definition
- Market and customer ‘s needs are identified and transferred
to technical and economical values
- Manufacturability, costs- and investment required are
investigated
- A detailed financial analysis is conducted
Are elaborated.
Gate 3 Decision on Business Case:
Results of financial analysis are assessed with ‘must meet’
criteria due to the heavy spending in the following stage.
Further decisions concern the product concept, the product
features, attributes and specifications, the preliminary operations
and marketing plans.
Stage 3 Development: development of the product and detailed testing,
marketing and operations plans.
Gate 4 Post-Development Review: check of the product characteristics,
quality of development work and financial review, based on new
and more detailed data.
Stage 4 Validation: test variability of the project considering product,
production process, customer acceptance and economic aspects.
Gate 5 Pre-Commercialization Decision:
Final point where a project could be killed, Results of previous
stage and financial projections are reviewed.
Stage 5 Commercialization: execution of operations- and marketing
launch plans
Post- A review of the project ends the Stage-gate model. Strengths and
Implementation weaknesses of the project are highlighted, if possible learning is
Review implemented.
Table 3-2, Stage activities and gate deliverables of a typical Stage-Gate® System (Cooper 1990)
Not all stages are required to be performed. Maylor reduces Coopers model to a
three stages and four gate process (Maylor 2010). Ulrich and Eppinger presented a
new NPD process consisting of six phases which include feedback processes within
each phase rather than a gate screening (Ulrich & Eppinger 2004).
Figure 3-2, Product development process (Ulrich & Eppinger 2004)
Several other new product development processes have been developed with
different number of stages, phases, gates or other structuring elements.
Providing a holistic picture on these would exceed the research intend of this thesis.
However, each of these processes tries to provide a strict model to manage risk and
increase efficiency (Veryzer 1998).
The importance of a clearly defined and implemented NPD process gets apparent
when group- or organizational boundaries are crossed. The typical NPD process
differences like timing and number of stages or gates, combined with an anticipation
that other groups would understand and accommodate the own structure, was found
to be a major sources of delay during a design projects (Yassine et al. 2003).
The problem Yassine et al. investigated fits into the more general NPD research
stream of “Teams-Integration” which was identified as top research stream across
815 articles selected from ten leading marketing management, NPD and R&D
journals. Other major streams of NPD research are “External Alliances”, “New
Product Development Strategy”, “Development Speed”, “Radical Products”, “Ideation
and Creativity”, “Success-Failure Factors” and “Stage Process” (Page & Schirr 2008,
pp.232, 241). To give an overview on this range of research is far beyond the focus
of this thesis.
However, according to a meta-analysis Henard and Szymanski performed across 60
empirical studies of NPD in 2001 and confirmed by Page and Schirr 2008, more
examination of product characteristics, marketplace characteristics, strategy synergy
and product quality is required in order to predict new product performance more
accurately (Henard & Szymanski 2001; Page & Schirr 2008).
Likewise, the main deliverables of product testing are examination of product

characteristics and ensuring product quality during a NPD. The testing activities
during NPD do also contribute to the speed of a development and require interaction
between different groups. Hence, the topic of this thesis work on testing as part of a
new product development process has a strong mandate to be investigated.
In the following chapter the specific role of testing as a part of a new product
development process will be elaborated from the literature.
3.2 Product Testing as Part of New Product Development

After the previous introduction into new product development the following section
will lead to the scope of this work, the product testing as a part of a new product
development.
In this work the term ‘testing’ is used as a general description of activities performed
to verify and validate products and as functional unit within the new product
development organization. For validation and verification the following definitions
were applied:
Validation: “The assurance that a product, service, or system meets the needs of
the customer and other identified stakeholders. It often involves acceptance and
suitability with external customers. Contrast with verification.”(PMI 2011, p.452)
Verification: “The evaluation of whether or not a product, service, or system
complies with a regulation, requirement, specification, or imposed condition. It is
often an internal process. Contrast with validation.” (PMI 2011, p.452)
As discussed in the previous chapter an essential phase of most product

development processes is testing. Being often the first realization of design in real
world product or system, makes the testing phase a critical element for a successful
product release. A central problem of NPD management is the timing and frequency
of conducting tests. Early studies have shown that the effort related to testing can
contribute almost fifty percent to the overall development effort (Shooman 1983).
The high cost and resources related to testing, especially if physical prototypes are
involved, leads to the ‘not unusual’ scenario of receiving prototypes late in the
program and single big “killer” testing (Reinertsen 1997).
A major value of testing is defined by its inherent function to reduce technical
uncertainty combined with the serious economic impact late problem discovery can
have during a product development (Thomke & Bell 2001).
It has to be underlined that in order to remain competitive products need to be
introduced expeditiously without compromises on quality (Chakravarty 2001) and
testing is still regarded essential to identify design problems and increase product
quality (Loch & Kavadias 2008).
To ensure the delivery of functional requirements in a specified duration, predefined

testing strategies are common industrial practice. The testing strategy has to define
the number and kind of required prototypes as well as the scheduling of test with
each of them (Zakarian 2010).
In an environment where product requirements are changing, designs become more

complex and the available development time is reduced, performing and managing
the required testing becomes more challenging. Thomke and Bell 2001 pointed out
that “the academic literature provides some help in formulating optimal testing
strategies”(Thomke & Bell 2001, p.308). They referred to solely two sources and
hence argued that further research of test strategy and planning would be required.
Khalaf and Yang (2006) as well argued that rich scientific literature on the overall
product development process is available. Planning and execution of downstream
product optimization and testing, however, is treated less frequent in the literature
(Khalaf & Yang 2006). The planning aspect of NPD testing became a more
investigated research stream in the last years and will be presented in chapter 3.3.1
of this thesis. The managerial aspect of test execution instead remained less treated
and will be focus of the case investigation.
The emerging focus on test planning and execution as part of a NPD process can
also be seen at Coopers work, founder of the stage-gate® process (Cooper 1990).
He observed that iterative testing became a key factor of success for development
teams. Handling unstable product specifications and project scope creep, Cooper
and Edgett documented a spiral development process in parallel to a stage-gate®
process. (Cooper & Edgett 2008).
Figure 3-3, Spiral development - a series of "build-test-feedback-revise" iterations in parallel to a

Stage-Gate® process (Cooper & Edgett 2008, p.9)
The Spiral development process of Cooper and Edgett shows similarities with the
regular schedule of prototype builds called “periodic prototyping” proposed by
Wheelwright and Clark(1992).
Even earlier concepts of spiral development exist. Boehm (1988) described an

iterative waterfall process of software development in which each step consists of:
 Determining objectives
 Identification and resolve risk
 Development and test
 Plan the next iteration
Through each iteration of the development steps the product is further developed and
enhanced which creates the spiral of the model. Figure 3-4 shows the phases of
Boehms development model. The strategic importance of test planning and execution
(also referred to as validation and verification) were fundamental part of Boehms
model.
Figure 3-4; Spiral model of software development (Boehm 1988)

A further popular model of product development and systems engineering is the

V-Model (Clark 2009; S. Eppinger & Browning 2012). As well as Boehms spiral
model it is often referred to as a software development process model. It found,
however, also application as visualization for development project in general
(Forsberg et al. 2005).
Figure 3-5, The basic V-model of the Systems Engineering Process

(Forsberg & Mooz 1991; Forsberg et al. 2005)
A top-down development process described by the V-Model starts in the upper left
and ends in the upper right. A decomposition and definition phase starts with the
understanding of user requirements, a basic system or product concept and a testing
plan, allowing the measurement of performance. Steps of specification, design and
build, lead to the fabrication, assembly and software coding of a prototype
(Forsberg & Mooz 1991). The V shape of the model allows visualizing the relation
between development steps and verification steps.
Forsberg et al. underline the need to have a planned process of verification by
stating: “Many very expensive systems have failed after deployment due to built-in
errors. In every case, there were two failures. First the failure to build the system
correctly and second the failure of the verification process to detect the defect.”
(Forsberg et al. 2005, p.366)
Various adaptation of the V-Model have been made to match specific needs of
development project management (FHWA 2009; IABG 2009). The central role of
verification and validation testing in the V-Model are similar to the approaches of
Boehm (1988) and Cooper (2008). The execution of iterative software development
summarized Boehm (2002) as a contrast between low planning agile methods and
detail planned milestone plan-driven methods.
The agile methods were summarized in a shared value proposition called the
“Manifesto for Agile Software Development” (Beck et al. 2001) as:
- individuals and interactions over processes and tools,
- working software over comprehensive documentation,
- customer collaboration over contract negotiation,
- responding to change over following a plan.
Agile development was a reaction on corporate bureaucracy and other dis-
advantages of detailed plan driven development. The practitioner driven methods of
Extreme Programming, Scrum and others could be summarized under the name of
agile software development (Boehm 2002; Highsmith & Chckburn 2001). It would
exceed the frame of this thesis to go into details, but the agile methods are an
important pillar of today’s software development projects (Estler et al. 2012).
Several applications of agile methods in non-software related product development

have been documented. The knowledge base, however, is much less developed as
for software development (Carlson & Turner 2013; Mazzani 2012).
Thomke and Bell (2001, p.309) underlined that although “the empirical evidence
suggests that early and frequent testing is desirable in some projects, it will
certainly not be the most effective strategy for all projects and for all design
problems.” A statement that summarizes the variability of context in which testing can
be part of a new product development process.
The chapter showed the importance of testing as part of a new product development
process. An increased requirement of fast feedback loops was elaborated from
different NPD models. The following chapter will present the different aspects of
product development testing in order to provide an understanding for the problem
setting of the case work.
3.3 Major Consideration for Product Testing Operations

This section aims to give an overview on the different aspect of product testing
relevant for the case study research. As structure for the research the activities of a
testing and refinement phase according to (Ulrich & Eppinger 2004) were chosen:
reliability- and life testing, performance- and functional testing, obtaining regulatory
approvals, implementation of design changes. The aspect of test planning and
execution was added to provide a connection to the NPD process discussed in the
previous chapter.
Focus was put on research from manufacturing industry perspective.
Pharmaceuticals development, pure software development, service industry or other
non-related field of research were excluded from the review. However, it should be
noted that further insights could be expected even from these industries, especially
through the organization of services and the interaction within expert organizations,
which could be addressed by further studies.
3.3.1 Planning of Product Testing

Chapter 3.2 identified verification and testing as essential phases or stage in various
product development process models. The planning effort, however, was not
particularly mentioned by various authors in the past (Cooper 1990; Pahl & Beitz
1996; Ulrich & Eppinger 2004; Wheelwright & Clark 1992a). Whereas the effort to
manufacturing planning was given a high focus as: “Assess production feasibility”,
“Define final assembly scheme”, “Begin procurement of long lead tooling” (Ulrich &
Eppinger 2004). As discussed in chapter 3.1 some authors referred to this lack of
research (Khalaf & Yang 2006; Thomke & Bell 2001). The NPD models: spiral
development, V-Model and agile with a higher focus on test planning and execution
were also discussed in chapter 3.1.
Independent of the general NPD model discussion an increasing number of authors

have discussed the planning and execution of testing. Wheelwright and Clark(1992)
proposed a regular schedule of prototype builds called “periodic prototyping” as
alternative to often observed delayed prototype testing.
Thomke and Bell (2001) have proposed a model to define optimal test strategies.
They incorporated several variables like increasing cost of redesign, the cost of test
as function of fidelity and the sequential test correlations. Similar to the model of
economic order quantity (EOQ) Thomke and Bell (2001) developed a model to define
the optimal number of tests, called Economic Testing Frequency or ETF (Equation 1).
ETF :
Economic Test Frequency
n* :
Number of tests
dv/2 :
Avoidable costs
√ m(f) :
Cost of test as function of test fidelity
f :
Fidelity of test measures the fraction
of cumulated problems detected
Equation 1, Economic Test Frequency (Thomke & Bell 2001)
According to Thomke and Bell the ETF model provides a “robust solution to the
question of how many tests to order. The only situation in which more tests are in fact
economical is when the fixed cost component of a test is low and the tests partially
overlap.” (Thomke & Bell 2001, p.320) Focus of the work by Thomke and Bell was
the optimization of test strategies from economic perspective. They do not consider
the managerial aspect of testing execution. However, Thomke and Bell see
interesting further research on how testing impacts coordination and communication
within companies.
A micro level approach, based on design for six sigma, axiomatic design, Failure
Mode and Effect Analysis (FMEA) and robust design was presented by Khalaf &
Yang to gain a “Lean approach to validating a product” (Khalaf & Yang 2006, p.18).
In a resource constrained case their objective was the reduction of completion time.
By developing a mathematical model and conducting different optimization
approaches Khalaf & Yang concluded that late in program design and manufacturing
changes should be avoided. Furthermore they suggest a test planning in a sequence
that allows studying “families of failure modes” in contrast to ‘ad hoc’ testing
(Khalaf & Yang 2006).
Among other aspects Khalaf & Yang worked out the role of variation in a testing
process, the within variation of each time contributing factor of testing and the
variation of the milestones in a NPD program (see: Figure 3-6).
An in-depth analysis of reasons for variation in product testing execution was not
provided.
Figure 3-6, “Total time variation due to variation in process milestones” (Khalaf & Yang 2006, p.22)
Zakarian attested in 2010 that “companies in a variety of industries that develop

complex products have well-defined processes for developing product testing plans
(to determine the number and types of prototypes needed for new product
development) and test plans (to determine how tests are scheduled on each
prototype)” (Zakarian 2010, p.370) The large number of requirements combined with
the high cost of prototypes and testing resources require test plans to balance the
tradeoffs between cost, testing lead-time and requirements validated. Zakarian
underlines the uncertainty involved in product validation and testing, impacting test
execution times and availability of prototypes most heavily (Zakarian 2010). He
developed an analytical bases approach for analysis and optimization of test
schedules, providing manager and engineers with a tool to examine critical tradeoffs.
The work of Zakarian provides a method for uncertainty driven test planning to:
- Evaluate tradeoff between: number of prototypes, percentage of completed test
procedures and reward gained from testing
- Compare the impact of additional prototypes and extended test plan lead time
(Zakarian 2010, p.390) Again an in-depth analysis of sources of variation in product
testing execution was not provided.
Kleyner and Sandborn (2008) applied an analysis of Life cycle cost (LCC) to guide
the tradeoff during test planning. They compare warranty and service cost with the
cost of development to minimize the total LCC. (Figure 3-7)
Figure 3-7, “Theoretical product development cost versus reliability curve”

(Kleyner & Sandborn 2008, p.798).
Validating requirements can improve the quality of the product, if the information
about problems is fed back into the design process. It also allows a more accurate
reliability prediction. Both with a descending effect on the warranty cost curve. The
development costs, however, are ascending due to the test equipment cost of
ownership, the test duration and the cost for the prototype samples
(Kleyner & Sandborn 2008).
Figure 3-8; Life cycle cost methodology flow for testing planning (Kleyner & Sandborn 2008, p.800)
Kleyne and Sandborn develop a methodology that allows evaluating the efficiency of
product testing from life cycle cost point of view. The emphasis was put on validation
and product warranty cost (Kleyner & Sandborn 2008).
A further method considering an overlapped design processes of test planning has

been discusses in the literature. In this method downstream activities are started
before upstream activities are completed in order to shorten the overall development
time (Krishnan et al. 1998; Qian et al. 2010; Tahera et al. 2013). Based on a model
Krishnan et al. (1998) showed the tradeoff between upstream evolution and
downstream sensitivity. In this model a fast evolution describes an activity that
reaches the final values early in the process, whilst slow evolution provides late final
values. A low sensitivity describes a downstream process that can cope with
upstream changes easily, in other words is flexible. A high sensitivity, in contrast, is
characteristic for activities that require high amount of rework in case of upstream
changes (Krishnan et al. 1998). As analytical result Krishnan et al. conclude that low
sensitivity and fast evolution activities are well suited for overlapped planning.
Tahera et al. pointed out that “it is observed that engineering companies overlap
testing and design as essential practice; regardless of the situation with respect to
evolution, sensitivities and resolution” (Tahera et al. 2013, p.202). The impact on
communication and workflow has to be well understood.
The literature research on the topic of test planning and execution has shown several
different approaches. A focus has been found on the area of planning and integration
into a design process. Several modeling efforts are focused on finding optimal
solutions considering different boundaries and parameters. The lead time and
variability of test execution and the related internal process, however, are viewed as
given constraints.
3.3.2 Basic Overview on Different Test Types

The following chapter will give a basic overview on different test types in order to
show the portfolio of different activities required in product development testing of a
manufacturing company.
Reliability testing and life testing
Reliability verification has to prove that a design will meet specified requirements
over time, hence, failure rate or frequency of repair have to stay under acceptable
values. A proven mean time between failure (MTBF) are verification results.
Life testing, as form of reliability testing, seeks to find and quantify ultimate design life
before wear out or failure. As a result, a design margin is known and quantified.
In cases where real time replication testing would exceed time or cost boundaries
acceleration can be achieved by increasing load level or frequency
(Forsberg et al. 2005). The acceleration of life testing requires an in-depth knowledge
about load and stress factors for the design on the one hand, but also knowledge
about expected failure modes. In particular designs that suffer erosion, chemical or
electrical reactions, vibration, static and thermal stress in combination, life testing
provides highly valuable knowledge about critical failure modes. Klyatis (2012) refers
to the complexity of proper reliability testing as a source for inaccurate prediction of
product reliability resulting in recalls and high life cycle cost. He argues that
accelerated test approaches like vibration testing, corrosion testing, step-stress
testing, thermo shock testing, highly accelerated life testing (HALT), highly
accelerated stress screening (HASS), accelerated aging, mechanical crack
propagation and growth testing and environmental stress screening (ESS) isolate
only few influencing failure factors, hence, do not account for complicated
interactions in products and systems. In his book Klyatis presents a framework for
accelerated reliably testing (ART) and accelerated durability testing (ADT), that
combines various types of accelerated tests together with human and safety factors
in a systematic way (Klyatis 2012). The focus is to identify and quantify problems in
order to allow design engineers to work on solutions.
Also the Lean literature refers to the learning about failure or testing to failure as the
major value adding compared to testing to specification (Millard 2001). “A Lean
design engineer wants to test to failure because more can be learned through
failure.” (Locher 2008, p.51)
Although reliability and life testing are major contributors to the time and budget of an
overall product testing, they are not sorely able to ensure customer satisfaction, a
working system and fulfilling of regulatory requirements. Hence, further testing
methods are discussed in the following paragraphs.
Performance and functional testing
Derived from customer requirements and transferred to technical requirements that

allow a measurable performance assessment, various product and sub system
performance aspects have to be verified in order to ensure the fulfillment of the
customer requirements (Zakarian 2010). Functional testing confirms that a design
performs entirely according to a specification, meaning that all positive aspects and
events of the specification are fulfilled and negative events are absent. Functional
testing is also referred as verification in general (Forsberg et al. 2005). In case of not
fulfilling requirements design corrective actions have to be addressed.
It is important to notice that design verification and performance testing are usually
performed with prototype products under nominal conditions in preselected
environments. However, the impact of variability has to be considered resulting in
design margin verification. Figure 3-9 shows that the resulting proven margin of the
design has to exceed the quality verification range during production and the
expected operational range during the life cycle of the product (Forsberg et al. 2005).
Figure 3-9, Relation between design verification ranges (Forsberg et al. 2005, p.370)
An important aspect of performance and functional testing of complete products is

the role of the tester itself. Aspects of the design that might not have been fully
specified as customer value might cause dissatisfaction from a customer point of
view. Although traditionally the proof of customer satisfaction or testing appears at
the end of development projects, more recent development process relay on
in-process testing (Forsberg et al. 2005). Hence, the phase of functional and
performance testing should be also considered aspects of user satisfaction
regardless of whether they have been specified or not.
A method of dealing with unexpected test outcomes or side effects is anomaly- or
discrepancy management (Weigel 2000). In a structured process anomalies have to
be investigated, ranked according to their criticality, root causes have to be
understood and corrective actions have to be taken (Forsberg et al. 2005).
Obtaining regulatory approvals
Regulatory approvals are often referred to as certification, compliance or

homologation testing. A signed certificate has to prove that one or several standards
are met (Forsberg et al. 2005). An example is the certification according to
Conformité Européenne (CE), which indicates a product’s compliance with EU
legislation and is required to sell a product on the European market. By performing
checks and tests the manufacturer has to ensure the conformity of the product
(EUCommission 2011).
Virtual Prototyping and Simulation Model Validation
A major effort to reduce the product development time and to allow fast learning
cycles for the development of more sophisticated and higher performance designs
and systems is the development of simulation models and virtual prototypes (Thomke
& Bell 2001). The models have to return the ability to evaluate different designs and
scenarios rapidly, hence, to allow optimization and robustness studies in a high pace
(Kokkolaras et al. 2013; Tahera et al. 2013).
The presence of uncertainty in both simulation models and test data requires a model
validation as basis of product testing (Kokkolaras et al. 2013). Out of a wide design
space with a large number of input variables a systematic model validation can help
to reduce the total number of require test data, hence safes cost and test time.
Although such a model validation does not necessarily create or specify customer
value and could be considered as waste in Lean framework (Bauch 2004; Locher
2008; McManus 2005) the risk reducing aspect and the increased confidence in
resulting designs represents an enabling value (Chase 2001; Kato 2005).
By performing model validation testing off the critical path of NPD projects the
workload in a testing facilities can be effectively leveled. The impact on design
confidence and speed of learning during new product development are the return of
model testing. An aspect that is often underestimated in new product development
processes.
3.4 Summary
In the previous chapter the important role of product testing as part of NPD was
elaborated. Methods of planning- and process integration were studies in detail and a
basic overview on different areas of test types was given and can be summarized as:
New product development process overview:
- Main research streams are: Teams-Integration, External Alliances, New Product

Development Strategy, Development Speed, Radical Products, Ideation and
Creativity, Success-Failure Factors, Stage Process
- To better predict new product success additional research is required:
Product characteristics, Marketplace characteristics, Strategy synergy and
Product quality
Product Testing is contributing to development speed, requires team integration and
is a provider of product characteristics and product quality data, hence a high level
research requirement could be identified.
Product testing as part of new product development:
- The chapter showed the importance of testing as part of a new product

development process. An increased requirement of fast feedback loops from
testing was elaborated from different NPD models: Spiral Model, V-Model, Agile
Methods.
- Depending on the stage of development verification or validation are
differentiated. In the further work the term of testing is used as generalization.
Major Consideration for Product Testing Operations
- Different methods for the operational planning could be identified:

Sequential Planning and Economic Test Frequency (ETF), Overlapped test
planning, Variability in test planning, Resource Allocation (People, Prototypes)
and Warranty cost driven planning
- A basic overview on test types was provided conserving:
Reliability- and life testing, performance- and functional testing, obtaining
regulatory approvals, implementation of design changes
Operational insights that drive testing internal: variability, time and rework were not
figured out from the literature research. The following chapter will study the role of
testing in the Lean product development research field.
4 Current State of Lean Product Development in Literature 44
4 Current State of Lean Product Development in Literature

In the following chapter the concept of Lean Thinking is described. A basic overview
on the origin, the goals and the principles of Lean Thinking allows the reader to follow
the paths of thought that led to the recent trend of Lean Product Development. In
addition, the possible problems and pitfalls of Lean in product development are
discussed. The specific aspect of Lean product testing is derived from the literature in
order to provide a priori framework for the case study of this master thesis.
4.1 Lean Thinking and Where It Came From

The Lean management framework, was mainly developed at Toyota Corporation in
Japan by Taiichi Ohno and is the basis for the Toyota Production System (TPS)
(Womack et al. 1990). One of the first applications of the word “Lean” in the field of
management was published in 1988 by John Krafcik (Krafcik 1988). In his paper
“Triumph of the Lean production systems” Krafcik differentiates between Lean and
buffered production.
Womack et al. created the term “Lean” as a new paradigm for conducting business
operations in the book “The Machine that Changed the World” (Womack et al. 1990).
The book is based on a five-year-study of various international automotive
companies. This study showed that Toyota’s production processes were
fundamentally different from western mass manufacturing and outperformed the
western companies in terms of defect rate, use of resources, lead time and plant
productivity.
Various studies of the application of Lean in industrial production were conducted, in
which the Toyota Production System (TPS) was a major point of investigation
(Adler 1993; J. K. Liker 1996; Rother & Shook 1999; Spear 1999). They found the
TPS as a result of constant organizational learning which started after World War 2
and was maintained until recent days at Toyota.
The further development of a general framework for the application of Lean was the
book “Lean Thinking”. In it Womack and Jones (1996) created a structure of five
points along their understanding of Lean:
1. Specification of customer value
2. Identification of the value stream
3. Creation of a continuous flow
4. Pull of the value
5. Striving for perfection
The relative simplicity of the developed frameworks and the publication in popular
literature led to application of Lean Thinking in a variety of businesses of different
industries and services.
An application of Lean in Product Development was followed by several researchers
and will be discussed in the following chapter.
4.2 Existing Lean Frameworks for Product Development

The definition of product development from a process point of view was discussed in
chapter 3.1. In order to apply the concept of Lean Thinking the system boundaries in
the context of a company are discussed in this chapter, the special meaning of value
and waste in the product development context are presented 4.2.2 and the value
stream is further specified 4.2.3.
4.2.1 System Boundaries for Product Development – Lean Framework

Two major principles of Lean thinking are Specification of customer value and
Identification of the value stream (Womack & Jones 1996). Product development in
particular has a major role in specifying customer values and enabling the company
to deliver a value to the customer. The delivery of physical products or the
management of orders, however, doesn’t belong to the role of product development.
Hoppmann (2009) gave a high level overview on the information and material value
flows in a company and the area of product development involvement (Figure 4-1).
Figure 4-1, “System Boundaries of the product development system“ (Hoppmann 2009, p.13)
4.2.2 Value and Waste Definition

The definition of value in product development was the key questions of the work of
Chase (Chase 2000). The reason for that specific interest lies in the complexity of
value in product development as a creation of information rather than a material- or
service value provided to a customer.
Product Development Value
One aspect of complexity is the missing single customer. As shown in Figure 4-1,
product development is serving the final customer but also various internal
customers, ranging from the production organization over sales and marketing to the
suppliers of raw material, parts and knowledge (Hoppmann 2009; Oppenheim 2004).
Chase formulated more general the complexity of value in product development as
something that “is seen differently by the business customer, end user, shareholder,
employee, and environment.”(Chase 2000, p.6)
Independent of Lean thinking value is usually elaborated in an initial project phase
from the context of market, company and economy and is expressed in a list of
requirements or target specifications. (Pahl & Beitz 1996; Ulrich & Eppinger 2004)
However, the value contribution of individual process steps in product development
towards the predefined requirements is often “harder to see” or might even “emerge”
during the process of development (McManus 2005; Womack & Jones 1996). For
that reason Chase has proposed a value framework for product development that
considers the creation of information and the reduction of risk (Chase 2000). The
information enables a company to deliver a product to a customer at a low risk of
missing the customer requirements as shown in Figure 4-2.
Figure 4-2, “The Value Creation Process” (Chase 2000, p.9)

Furthermore Chase (2001) developed a set of ten value attributes of product

development tasks which were originally proposed by McManus (Chase 2001;
McManus 2000).
Table 4-1, Value attributes of product development task (Chase 2001, p.59; McManus 2005, p.32)
Millard (2001) developed a data collection sheet for the value stream analysis which,
however, excluded V5, V8 and V9 (Table 4-1) from the value assessment. Millard’s
proposal was based on site visits at aircraft industry companies, research data
reduction and reference literature (Millard 2001).
In 2005 McManus pointed out that V1 to V3 in green shade are directly value adding
activities in product development. Value attributes V4, V6 and V 10 shade in blue can
provide value whereas V5, V7 and V9 fall into the group of non-value-added
activities. McManus underlined however, that the specific value aspects have to be
adapted to the case under investigation (McManus 2005).
For the value analysis in this case study the assessment proposal of Millard (2001)
was utilized. During the preparation of the priori construct for the case work and after
the first iteration of current state analysis the value assessment was adapted to
match the situation of product development testing. The following adaptation were
made:
- “Lessons Learned” ( V8 in Table 4-1) was added as value aspect
In a ‘test for failure’ setting learning is a major value. Also unexpected failures or
observations create value and learning if documented.
In addition, is the capability of the testing organization to run specific tests
effective and efficient a major value to the internal customer. Documents like test
procedures or best practices, or more general applicable knowledge, are the
output of such learning.
- “Definition of Process to Deliver Product” (V2 in Table 4-1) was removed
although testing activates can provide information on the possibility to assemble,
test or deliver the product to the final customer the definition will be made by
design or production engineering.
- “Definition of End Product with desired Functional Performance”(V1 in Table 4-1)
was renamed into “Output Relevant for Final Customer”
- The rating scale with five steps was reduced to three steps. For a rating during
value stream mapping workshop, an observation or an interview, the three step
rating was quicker to assess.
The value assessment used in this case study is summarized in Table 4-2.
Value
3 Direct Specification of Customer Value 3 Flows easily into program milestone
Output
Relevance Direct Specification of minor Customer Value/ Form of
2 2 Flows into next task with some changes
for Final Indirect Specification of major Customer Value Output
Customer
1 Indirect Specification of minor Customer Value 1 Form has to be copy pasted manually
3 Major Risk, Greatly reduced, Eliminated 3 Major checkpoint preventing further work
Reduction Enabling
2 Significant Reduction of risk 2 Task is needed to continue work
of Risk Activities
1 Minor Reduction of risk 1 Task checks quality
Lessons Learned, Major Program, Directly & Major improvement over historical
3 3
Long-term Applicable predecessor
Lessons Time/Cost
Learned Lessons Learned, Directly/ Saving
2 2 Minor Improvement over predecessor
Long-term Applicable
1 Lessons Learned, Long-term Applicable 1 Possible improvement over predecessor
Table 4-2, Value assessment for product development testing, based on: (Millard 2001)
Product Development Waste
Taiichi Ohno (1988) claimed that 95 percent of all costs in a production environment
are waste. He identified seven common waste types as classification (Ohno 1988).
Considering the relation between the created value and the input required in form of:
time and resources, makes the component of waste apparent to explain the variation
of performance in the industry as shown in (McManus 2005; Womack et al. 1990).
The investigation of nature and source of waste in product development has been the
focus of various researchers. A seven waste model was developed, which adapted
known production waste to fit the product development environment (McManus &
Millard 2002; Rother & Shook 1999; Womack et al. 1990). From an in-depth analysis
of the Toyota Product Development Process Liker & Morgan (2006) added an eighth
waste type “Unused Employee Creativity”. Further waste factors were identified by
case study research or by literature research (Bauch 2004; Kato 2005; Morgan 2002;
Rossi et al. 2011). In the following chapters of this thesis the waste assessment is
limited to eight waste types as shown in Table 4-3.
Waiting
People wait for information or Information wait for people
Inventory
Too much and uncontrolled information; possibly redundant, outdated or “just in
case" provided information
Excessive Processing
Information processing beyond requirements of internal and final customer
Over Production
Producing and distributing more information as required, push instead of pull
Transportation and Information Handoffs
Unnecessary movement of information between people, organizations or systems
Leading to system incompatibility, communication failure and security issues
Unnecessary Motion
Lack of direct access, Unnecessary human movement between tools or systems
Defects
Erroneous data, information, reports or misunderstanding
Unused Employee Creativity
Demotivation, lack of knowledge sharing, miss-management of capabilities
Table 4-3, Product Development Waste based on: (McManus 2005; Morgan & Liker 2006)
A practitioner orientated waste assessment method for product development was

presented by (Rossi et al. 2011). Based on FMEA (Failure Modes and Effects
Analysis) this waste assessment method allows effective integration into common
new product development process, enabling constant improvement and focus on
value creation. The methodology of Rossi et al. (2011) was applied in the case study
of this thesis, even though slight modifications were required.
If a waste aspect from Table 4-3 was identified in the testing process, severity,
occurrence and avoidability of the waste were assessed. As for the value
assessment, a three step rating was applied. The aspect of waste detectability, as
suggested by Rossi et al.(2011), was not used because all wastes were actually
identified from the case study. Table 4-4 shows the waste assessment framework.
Waste Criteria Value Criteria
Severity Impact on Time and 1 Low Impact
(S) Quality of a test 2 Medium Impact
3 High Impact
Occurrence How often does the 1 Less than 1% of tests
(O) waste occur? 2 Between 1% and 20% of tests
3 Between 20% and 100% of the tests
Avoid- How complex or 1 Complex, implementation
ability simple is avoiding the > 6 month, high cost
(A) waste? 2 Medium, implementation < 6 Month,
or low cost
3 Simple, Fast and Low Cost
Table 4-4, Waste assessment framework as FMEA approach, adaptation of (Rossi et al. 2011)
By multiplying the different waste assessment values a priority factor PI was derived
following the framework of Rossi et al. (2011).
To allow a comparison with the value assessment the priority factor PI was
normalized to the range between 1 and 3.
In production applied Lean thinking a clear focus on waste reduction is present,

whereas a Lean approach in product development requires a balanced vision of
waste and value. The wide range of values that product development provides to the
organization and to the final customer plus the ability to drive innovation reach
beyond the combating of waste (Oppenheim 2004).
4.2.3 Value Stream in Product Development

The value stream in a production process is defined by a material flow through
working stations which add value to a product and an information flow to control the
process. One can follow the value creation like a physical path and apply the value
and waste concept in measurable physical units (Rother & Shook 1999).
In product development, however, the dominant value stream is the flow of
information between processes that create information and reduce risk (Chase 2000;
McManus & Millard 2002). This value stream is much harder to observe than physical
flows due to the various ways of verbal, paper based or electronic information
exchange. Maleyeff (2006) classifies product development as part of a general
internal service system. He found common structural characteristics including focus
on information processing, work across functional areas, information hand-offs,
hidden costs and benefits. Critical managerial insights on the system performance
that Maleyeff found in a cross review of 60 case studies are the cross functional
importance and the critical role people play (Maleyeff 2006).
However, different methods have been proposed to map the value stream of the
product development process (Locher 2008; McManus 2005; Oppenheim 2004) in a
similar way as in the popular “learn to see” value stream map (VSM) method of
Rother & Shook (1999). The outcome of such an effort in product development is
also called value stream map (VSM) although fundamental differences can be found
in the goals, time units, processes steps and repetition of work.
Goal
The general goal of a value stream is the delivery of value adding activities and the
minimization of non-value adding activities, from order to delivery for the production
value stream and from concept to launch for the product development value stream
(Marchwinski et al. 2008). Underling the enabling character of product development
to deliver higher company performance and better products, McManus argues that
simply fast process execution with minimal resource spent is not the final goal of a
Lean product development value stream (McManus 2005). He formulate the more
general requirement to:
“Produce the required outputs, without defects, as efficiently as possible, and

at the right time.“ (McManus 2005, p.28)
McManus advises that the required output has to:

 specify products that fulfill performance criteria and meet constraints
 enable downstream processes
 guarantee and document acceptable risk and certainty
To specify the right time McManus underlines that “as fast as possible” is only one
aspect, especially true for bottleneck processes. He uses the phrases of “intellectual
inventory” to depict the risk of obsolescence information have. Hence, the goal of a
Lean process is, that information are handed off in the moment they are needed by
the downstream process, or at the right time. (McManus 2005)
Time Units
The first Lean guideline of “Learning to see” (Rother & Shook 1999) is to produce
according to required takt time. The concept of takt time synchronizes the production
pace with the pace of sales, as a symphony orchestra is synchronized by the
metronome takt visualized by a conductor.
Since product development is serving mainly company internal customers in order to
enable production according to market demand for new products, the time units are
significantly larger as for the production of individual units. However, the production
pace and the product development pace are not directly related to each other. The
key characteristic of a demand for new products has been described as duration of
product life cycle, by many authors (Martin et al. 2009). Mass products with high
production pace can have high development pace, like smart phones, or low product
development paces, like light bulbs. Fischer (1997) used the duration of product life
cycle to differentiate functional products with longer life cycles and innovative
products with short life cycles (Fisher 1997).
In general the time units for the information transformation in product development is
relatively long and usually measured in hours, days, months or years. A specific
demand rate for new products in the market has to be well understood in order to
describe the value stream in product development. Short product life cycles require
“fast track” product development value streams (Martin et al. 2009).
Process Steps
Rother & Shook (1999) distinguish processes steps of a door to door production
value stream if separate machining processes with inventory between them or a
transfer in batches is present.
In the value stream of a product development, however, information flows between
people who work on tasks. The tasks can be distinguished by major information
which are required to perform the task and by piles of work representing information
inventory (Locher 2008; McManus 2005). The strong relation on human labor,
creativity and communication is illustrated by the considerable uncertainty, iterative
and cyclic character of product development process steps ((McManus 2005; Morgan
2002; Oppenheim 2004).
Repetition of Work
Although concepts of mixed model production or Single Minute Exchange of Dies

(SMED) are part of the Lean tools to increase flexibility and accelerate market
response, the overall concept of highly standardized- and repetitive work processes
is still valid in the production environment.
In contrary (Hoppmann 2009) argues that in product development ideally no
repetition of information generation can be found. As discussed in chapter 4.2.2 the
value framework of Chase (2000) found that creation of information and reduction of
risk are the value adding outputs of product development process steps.
Consequently the repetitive generation of equal information or in other word, creation
of unnecessary information or data, is viewed as waste (Bauch 2004; Kato 2005;
Morgan 2002). In addition, the use of unchanged components and designs in a new
product generation can significantly reduce the cost of development, manufacturing
and sourcing. Hence, the product development has to use past information in a
repetitive way in order to avoid the creation of unnecessary or repetitive information.
A way of practical implication is the use of check-lists, which represent “accumulated
knowledge base reflecting what a company has learned over time about good and
bad design practices, performance requirements, critical design interfaces, critical to
quality characteristics, manufacturing requirements as well as standards that
communize design” (Morgan & Liker 2006).
4.2.4 Lean Tools and Principles

The Lean management framework combines several tools and methodologies.
Merged together these tools have to goal to provide what the customer wants, at the
right time and in the exact amount (Womack & Jones 1996; Womack et al. 1990).
Some major tools of Lean manufacturing are collected in Table 4-5.
Continuous Improvement and Kaizen
“Continuous improvement of an entire value stream or an individual process to
create more value with less waste.” (Marchwinski et al. 2008, p.50)
System or flow Kaizen and process Kaizen can be differentiated.
Kanban
“A kanban is a signaling device that gives authorization and instructions
for the production or withdrawal (conveyance) of items in a pull
system.” (Marchwinski et al. 2008, p.52)
Workload Balancing
Working according to a takt time defined as available time divided by customer
demand. Compare and balance the cycle time of each individual process step.
(Rother & Shook 1999)
Single Minute Exchange of Dies (SMED)
“A process for changing over production equipment from one part
number to another in as little time as possible.” (Marchwinski et al. 2008, p.100)
Five S and general visual management
Method of conduction visual control of workplace often translated as: Sort,
Straighten, Shine, Standardize, Sustain.
A3 Report
“A Toyota-pioneered practice of getting the problem, the analysis,
the corrective actions, and the action plan down on a single sheet
of large (A3) paper”.(Marchwinski et al. 2008, p.1)
Value Stream Mapping (VSM)
“A simple diagram of every step involved in the material and
information flows needed to bring a product from order to delivery” (Marchwinski et
al. 2008, p.120)
Table 4-5, Major Lean tools used in production environment based on (Marchwinski et al. 2008;
Womack & Jones 1996)
The listed tools are frequently mentioned in literature and are common practice in
manufacturing companies. Further information can be found in the referred sources.
Lean in product development can use some of the general Lean tools but requires
several additional methods and principles. Morgan and Liker (2006) identified 13
management principles characteristic for the Toyota Product Development System
(TPDS), a widely credited successful case of Lean product development (Hoppmann
2009; Welo 2011). Other authors have developed Lean product development
models with different focus. Common characteristics, however, are recognizable
across many of them (Welo 2011). Figure 4-3 provides an overview on matching
Lean PD characteristics across 12 literatures sources and time span 1996 to 2011
derived by Welo (2010). The analysis shows that ‘customer defined feedback’ and
‘Culture to support excellence and improvement’ are major focus in the literature.
Except Morgan and Likers Lean PD principle of ‘Adapt technology to fit people and
process’ all other principles have a similar communality across the academic
literature.
Figure 4-3, 13 Lean PD principles of Morgan and Liker (2006) and number of literature sources with
comparable findings, based on (Welo 2011, p.330)
“In sum, a multitude of different approaches to Lean PD have been described in

literature. So far, none of these approaches has found wide-spread and general
acceptance.” (Hoppmann 2009, p.21)
Hoppmann (2009) derived a summary of 11 Lean PD approaches (Table 4-6), from a
similar cross literature analysis as Welo (2010) did. To validate the different Lean
approaches Hoppmann (2009) used an industrial survey which could gather 113
respondents. Hence, his synthesis was driven by the requirement to provide fast
recognition of Lean PD characteristic independently of context or literature
background.
Strong Project Manager or Chief Engineer

Product development projects are led by an experienced project leader, who is largely
responsible for defining customer value and securing the success of the project.
Process Standardization
When planning, executing and documenting projects, standardized processes, tools and
methods are used.
Set-based Engineering
When developing a product module, a large number of alternative solutions are considered
early in the process. The set of solutions is subsequently narrowed based on simultaneous
development and testing of the alternatives.
Specialist Career Path
Engineers are given the opportunity to advance in their technical domain, based on
personal coaching and frequent feedback by their superiors.
Product Variety Management
Achievement of scale effects through designated use of commodities, reuse of parts,
definition of modular components with standardized interfaces and development of product
platforms.
Workload Leveling
Required and available resources are planned on a cross-project basis. Workload
allocations and capacities are flexibly adapted during the project based on frequent
comparisons of planned versus actual capacity requirements.
Supplier Integration
Suppliers of critical parts are identified early in the project, integrated into the development
and process and actively supported to improve their performance.
Responsibility-based Planning and Control
Development engineers are locally responsible for planning, execution and control of
detailed product development activities.
Cross-project Knowledge Transfer
Successful methods, designs and tools as well as areas for improvement are documented
on a cross-project basis and actively used and refined in subsequent projects.
Rapid Prototyping, Simulation and Testing
For a fast and reliable evaluation of concepts and drafts, rapid prototyping technologies,
computer aided simulation and methods for fast physical modeling are used.
Simultaneous Engineering
Representatives from production, quality assurance and purchasing departments are
integrated into development activities at an early stage. The design of production
processes and facilities is conducted in parallel to the development of the product.
Table 4-6, Lean PD approaches, based on (Hoppmann 2009, p.21 ff.)
Companies use the 11 Lean PD approaches simultaneously. Hoppmann (2009)

found a strong positive correlation across the use of the individual components in
Table 4-6 from an industrial survey with 113 participants. The wide definitions of 13
Lean PD principles by Morgan and Liker (2006), which cover all the approaches that
Hoppmann summarized, are supported by these findings. In the following part of this
thesis the synthesis of Hoppmann (2009) will be used.
In addition to the general use of Lean PD concepts several researchers and

practitioners have spread the Lean thinking into various parts of the product
development environment. It would exceed the frame of this thesis to detail the
review, but the specific application of Lean in product development testing will be
investigated in the following chapter.
4.3 Lean in Product Development Testing

This section aims to provide an overview on the current representation of testing as
part of the Lean product development literature. It summarizes the current state of
testing in a context between Lean production and Lean product development.
The focus on the specific area of testing is contradictory to the general approach of
Lean PD as discussed in 4.2. Especially Womack & Jones (1996) requirement for
continuous flow in a Lean thinking environment does not promote the specific focus
on a functional area like testing. The cross functional integration, with suppliers,
supply chain and production are a more common approaches in Lean product
development (Morgan & Liker 2006).
On the other hand, testing combines the major focus on information handling, known
from product development, with the job shop like material flows in the laboratory
environment, known from production environment. For this reason the specific
application of Lean on the area of testing is reasonable.
The major focus of the literature related to Lean testing product development found
during the research were:
Rapid Prototyping, Simulation:
Lean prototyping uses early stage iterative investigation of virtual and limited physical
prototypes (Jönsson 2004; Tahera et al. 2013).
Cross-project Knowledge Transfer:
Based on knowledge management techniques unnecessary tests can be avoided.

Target is to capture the relations between design changes, required physical test and
historical data (Al-Ashaab et al. 2012). Furthermore, minimizes upfront planning of
test schedules redundancy and non-required testing (Khalaf & Yang 2006).
Specialist Career Path and Process Standardization:
Testing as part of product development in manufacturing companies is a well-studied

engineering discipline with specific knowledge. With over 15000 papers in the
portfolio of the SAE group “Test and Testing” and topics ranging from: data
acquisition, test procedures, performance testing, test equipment and others, a deep
knowledge base is available in the industry (SAE 2013). A rough overview on
different test types was provided in chapter 3.3.2.
Schulte et al. (2005) characterized the people involved in laboratory testing as
college graduated, salary employed and flexible working staff.
Workload Leveling:
As discussed in 3.3.1 a focus of research investigated the planning concepts of

product development testing. The majority of literature sources seek to optimize
planning of resources, number of prototypes or the sequence of activities (Khalaf &
Yang 2006; Thomke & Bell 2001). Due to the long lead time and high cost of physical
prototypes this focus is plausible. Schulte et al. (2005) described that constraint
management had to be expanded to a quantified skill management in order to enable
flexible staff allocation and identify training requirements.
The sources of test lead time and its variability are rarely publicized in detail from a
test execution perspective.
Strong Project Manager:
As part of the general product development organization testing operations provide a

specific recourse for a project management. This standard knowledge of a matrix
organization stands in contrast with the current state Schulte et al. described in their
case study at Visteon, a Fortune 500 automotive supplier. Their test engineers saw
themselves “as collaborators with the product development engineers”, working with
“a craftsman-like mentality persisted with a bent toward investigative testing.”(Schulte
et al. 2005, p.4) In their case development timing, as a strong project manager would
focus on, was lacking attention before a Lean training.
Other Lean Product Development Approaches:
The Lean PD approaches of Responsibility-Based Planning and Control,

Simultaneous Engineering, Supplier Integration, Variety Management and Set Based
Engineering were not found as a topic solely applied to product development testing.
The concepts are clearly cross functional and a specific view from testing perspective
would only partly express their core Lean concept.
Test Execution - Specific Considerations:
The laboratory environment of PD testing has common elements with a

manufacturing job shop. Low volume customer orders, high variable demand rate
and jobs with specific process routing are processed. Lean manufacturing methods
like value stream mapping (VSM), visual management with 5S, standardization of
tools and processes in Kaizen methodology are applicable (Schulte et al. 2005). As
part of the product development organization this is a unique hybrid role. The
intangible product, information, derived from physical inputs makes the value
assessment of laboratory work hard. Non visibility of information queues and other
wastes make the assessment of waste similar to product development environment
(Schulte et al. 2005). Carreras (2002) presented a case study across seven aircraft
flight testing programs. He applied a value creation framework and discussed Lean
thinking in the context of aircraft flight testing. Carreras found that Lean thinking is
applicable in the specific context, mainly through process improvements (Carreras
2002, p.71). However, more recent publications on Lean methodologies show that a
structured assessment of waste and more in-depth visualization using VSM are
missing in the work of Carreras (2002). Furthermore, requires the specific focus of
Carreras (2002) on the aircraft and defense industry examples from other industries
as this thesis provides.
Problems as result of testing
A major pillar of the Lean production philosophy is the detection of problems and the
structured improvement through methods like Plan, Do, Check, Act (PDCA).
Combined with the Kaizen method continuous improvement can be achieved.
One deliverable of product development testing is the detection of problems during
the design phase. Weigel (2000) has investigated the nature of problems in testing of
space crafts and referred to them as ‘discrepancies’.
Based on statistical analysis of over 23 000 discrepancies, Weigels major findings

were that only one third of the problems in system level integration were actually
related to the system under test. The majority of problems had their root cause in
subcomponents or test equipment. Furthermore, Weigel (2000) identified that human
errors are major contributor to the detected problems. In less than 50% of the cases
these human errors were related to the complexity of design, software or material of
the system under test. In addition, Weigel underlined “that the percentage of human
error-caused discrepancies per spacecraft has remained more stable over the past
thirty years than percentages of the other root cause categories, based on
observations of the data used in this research.” (Weigel 2000, p.173)
The findings of Weigel (2000) show, that the testing internal value stream can
produce erroneous information. The reasons for these human errors or the test
equipment errors are not explored by Weigel. Further investigation is required and
will be addressed by the case study in this thesis.
A thorough literature research was conducted for the specific application of Lean in
PD testing before, during and after the actual case analysis work. Nevertheless, only
few sources could be identified treating the topic specifically. The case study report of
Schulte et al (2005) was found after the case study work during a literature
retrospective. Rich literature could be found for the application of Lean testing in
software development, medicine-, health- and biology-context. These terms were
excluded from the literature search, due to the focus of this thesis on product
development of manufacturing companies.
The statement: “little is documented about how Lean can apply in a product
development test laboratory” (Schulte et al. 2005, p.3) remained true and underlines
the relevance of this thesis work.
5 Summary and Research Question Refinement 61
5 Summary and Research Question Refinement

The previous literature review presented the context from which the following case
study work was defined. A major discussion point was new product development
processes and the role of testing as part of product development. Traditional stage
gate models as well as more recent product development models with increased
attention on testing as learning loops were discussed.
From general literature the specific area of test planning and a general overview on
different types of tests was performed. Operational insights that drive testing internal:
variability, time and rework were not figured out from the literature research.
In the following chapter the Lean management framework was summarized from
leading literature sources. The specific application of Lean in product development
was presented and put into contrast to the Lean manufacturing framework.
Lean management and its application to product development testing was studied,
however, the available literature was found to be less dense. The testing environment
was found to combine product development- but also production aspects in a hybrid
environment.
The initial research question were partly answered but remained valid for the case
research:
1. How can the internal process of testing as part of new product development be
2. To which extend are Lean principles able to improve the performance of a
testing process?
3. How can the process improvement be part of a continuous improvement
effort?
After the literature research the following research question were added:
4. Is value stream mapping (VSM) an effective tool to conduct case study
research in product testing environment of a global operating manufacturing
company?
5 Summary and Research Question Refinement 62
VSM for production processes as presented by Rother and Shook (1999) is a paper
and pencil tool. “Drawing by hand means you will focus on understanding the flow
(…) of information and material.”(Rother & Shook 1999, p.25)
In literature on Lean product development and in a single case about Lean testing,
VSM was given a prominent role for the understanding and transformation towards a
Lean product development (Loch & Kavadias 2008; McManus 2005; Oppenheim
2004; Schulte et al. 2005).
As discussed, for product development the value adding flow is mainly an information
flow. The understanding of the flow requires in-depth knowledge and information,
which is usually not available for the value stream manager. Locher (2008)
recommends an in-depth preparation phase and a VSM team event of 3 days with six
to ten participants. Hoppmann (2009), however, found the effort to create a VSM to
be of low impact on the implementation of a Lean product development (Hoppmann
2009, p.122). He interpreted the findings as outcome of the waste identification focus
of VSM and undervaluation of value-enhancing characteristics in product
development.
The author decided to use the VSM method as a guiding framework for the case
study research. The effectiveness of the approach will be discussed in the reflection
part of this thesis.
6 Case Presentation 63
6 Case Presentation
The following chapter presents the company in which the case study research was
performed over a period of five months. The in-depth case analysis was used to
provide empirical data analyzed in this thesis. Due to a non-disclosure agreement,
the company name and critical data are disguised. However, the author carefully
ensured that the analytic results of this thesis remained valid.
6.1 Company and Industry Background

Midwestern Forest and Lawn Machinery N.V. (MWFL) is a US-based, global
operating manufacturing company. It is specialized on lawn mowers and forest
machines which are products for the Off-Highway machinery market for professional
customers. The operational scope of MWFL includes integrated engineering,
manufacturing, marketing and distribution of their equipment on five continents.
Globally approximately 5500 dealers in 165 countries, achieved a net sales of
USD 8.9 billion in 2012. MWFL’s operations are organized in three business
segments: lawn mowers which represent 75 percent-, forest machines with 18
percent- and financial service with 7 percent of net sales. MWFL is listed on the
Stock Market and presents its financial results quarterly according to U.S. Generally
Accepted Accounting Principles (GAAP). MWFL has approximately 15 000
employees, operates 21 manufacturing facilities and 16 research and development
centers (MWFL 2013a; MWFL 2012).
Due to the size of the case study company a scope limitation was defined before
conduction the research. The case study was performed in the forest machines
business unit which runs a separate product development organization. Figure 6-1
shows a forest harvester which is a major product line in the business unit.
As a manufacturing company for final customers which use the products as

professionals, the product development is industrial customer focused. The products
are sold worldwide with specific market adaptations. Products are usually used in
remote locations with limited access for service. Hence, customers put strong focus
on the reliability in tough working conditions.
Figure 6-1, Typical forest harvester machine (MWFL 2013a)
MWFL operates at relatively low vertical integration, meaning that several supplier
parts like the diesel engine, hydraulics, drive line or controls have to be purchased.
Major product development effort is the component- and system specification, the
structural design, supplier coordination, integration of all subcomponents into a final
product, enabling manufacturing and ensuring the fulfillment of the market
requirements.
The following section will describe the product development structure of MWFL and
scope the area of research.
6.2 General Product Development Organization

In this section the product development environment of the case study company will
be described. A basic overview will be given to allow the reader an understanding of
the environment in which the case study was conducted.
According to the company homepage heavy investments in research and

development to offer innovative products are part of the MWFL profile. Publically
advertised targets for the development in general are power increase, fuel economy,
improved reliability and low down-time. The “right price” and technology suitable for
all climatic conditions are expected to lead to an eco-sustainable result. The 16
research and design centers are located on four continents in order to provide best
locations to develop, improve and test new products (MWFL 2013a).
For the case study research in the business unit of forest machines 4 North
American, one South American, three European and one Asian R&D center were
relevant.
A new product development process (NPD) as described by PDMA as a set of tasks

and steps that describe the repetitive conversion of ideas into salable products or
services (PDMA 2006) is defined and standardized at MWFL. The presented case
study focuses on the NPD Execution. The NPD Execution process at MWFL is
organized as a decision-stage model. It follows mainly the six-phase process
elaborated by Ulrich and Eppinger (2004) as shown in Figure 6-2.
Figure 6-2, Product development process at MWFL (Ulrich & Eppinger 2004)
Between the different development phases the MWFL management holds milestone
review meetings. The milestones represent gates in which go/kill/hold/recycle
decisions are made and next phase action items are approved. The gate aspect
carries similarities to the stage-gate® process (Cooper 1990).
MWFL’s business unit for forest machines has a separate product development
organization as shown in the high level functional organigram Figure 6-3. Major
reason for the separation are the different markets and customer requirements
relevant for the product lines.
PD
Management
Forest
Lawn Mowers Finance
Machines
Vehicle Design Product Testing Design Analysis Vehicle Design Product Testing Design Analysis
10 Differnt 7 Locations, 5 Countries Differnt

Product Product 9 Locations
Platforms single or multiple Products Platforms
Figure 6-3, Simplified product development organigram of MWFL and case study focus shaded
The applicability of early feedback, virtual- and rapid prototyping as discussed in

chapter 3.1, seems to be less feasible in the forest machine market of the case
company. Customer expectation are mainly focused on power increase, fuel
economy, improved reliability and low down-time (MWFL 2013a), which are usually
characteristics of long lead time engineered systems, rather than individual part or
software characters. In some aspects like cabin ergonomics or user interface,
however, the spiral development could be applicable.
6.3 Role of Product Testing Functional Unit

The following case analysis was focused on the functional area of forest machine
product testing (Figure 6-3) and Phase 4 – “testing & refinement” of the PD process
(Figure 6-2) at MWFL.
For the complete machine or individual systems product testing has to:
- Plan and manage internal testing operations in order to support all
development projects
- Perform reliability- and life testing
- Support the initial specification with physical data
- Evaluate performance- and functionality
- Obtain regulatory approvals
- Implement design changes in coordination with the development group
For an average machine development program 100-300 tests are required.
7 Case Analysis – Overview and Methodology 67
7 Case Analysis – Overview and Methodology

This section presents the application of the literature research on the in-depth case
study of MWFL forest machine product testing process. Table 7-1 shows the different
steps of case study research and gives an overview to the reader. It is important to
notice that step 4, 5 and 6 were iterated with each field data collection.
Research Process Chapter P.
3 Crafting Instruments 7.1 VSM as Methodology and Priori Construct 67
and protocols 8.1 Analysis of Legacy Data 75
4 Entering the Field 8.2 Visit of Site A - VSM Workshop, Current State 82
8.3 Visit of Site B - without VSM Workshop 90
8.4 Visit of Site C - VSM Workshop, Current- and 93
Future State
5 Analyzing of Data 8.5 Current State - Cross Case Analysis 102
Within case data analyzes was performed during
and after the value stream mapping events and
are integrated in the relevant chapters.
6 Shaping 9 Case Analysis – Future State and 106
Hypotheses Implementation Future State 126
Table 7-1, Steps of case study research
7.1 VSM as Methodology and Priori Construct

As major case study tool value stream mapping (VSM) for product development was
selected from the literature research. In the end of each section the practical
application is described in a short manner.
The basic value stream map steps are:
- Current state - As Is map of the current process
- Future state - To Be map of the desired process
- Planning and Implementation
This simple but effective approach presented by Roth and Shook (1999) made value
stream mapping a successful tool for production process improvement and is also
suggested to be used for product development value stream mapping (Locher 2008;
McManus 2005; Oppenheim 2004).
7.1.1 Current State Analysis

To assess the current state Locher (2008) suggests a six step approach:
1. Identify current customer needs.
2. Identify main processes in order.
3. Select process metrics (or data attributes).
4. Perform value stream walk-through and fill in data boxes.
5. Establish how each process prioritizes work.
6. Calculate value stream summary metrics such as lead time, process time,
first pass yield, cost, and other measures that the mapping team deems
important.
The basic steps of Locher (2008) were utilized to conduct the current state
assessment, some aspects however, were adapted for the needs of this case study.
Identify current customer needs
The Supplier-Input-Process-Output-Customer framework (SIPOC) was selected to

determine the current customer needs. Although Locher (2008) recommends to
create the SIPOC before the value stream workshop, which was done as well, the
SIPOC creation in a brainstorming fashion was used as starting point of the current
state mapping workshop. The view of process owners and participants on the SIPOC
shows awareness about their role in an overall process of product development. This
was expected to be important information for the current state assessment, especially
due to the limitation of this case study research to product testing activities.
Identify main processes in order
As suggested by Rother and Shook (1999) the initial step of process understanding
is the clarification of process boundaries. For a production process these are
customer and suppliers. Starting from the customer demand and shipping of goods
Rother and Shook suggest walking the value steam backwards, always searching for
the origin of value.
In contrast Millard suggested to start at the input and follow the value stream down to
the customer, asking the participant “What happens next?” (Millard 2001, p.70). His
opinion is mainly a conclusion from the intangible flow of information in product
development value streams. McManus suggests to follow both concepts as required,
referring the practical background of his PDVSM Manual (McManus 2005).
For the value stream map in product testing the boundaries were predefined between
the input of test requirements and the output of test reports and data to the internal
customer. This limitation was made to allow the desired micro level approach this
thesis intended and the case selection allowed. As a result, the level of detail could
be higher as in the overall value stream maps as McManus (2005) and Locher (2008)
suggested without expanding to an overwhelming format.
An introductory process order definition was done at

each site with a local manager and partial support of test
engineers. The steps were edited on whiteboards in the
first VSM workshop and with preprinted from cards on
paper walls in the second VSM workshop (Figure 7-1).
The workshop participants joined actively the process
definition; however, a leading role by the author was
required because all participants were unfamiliar with
value stream mapping. The results were documented
with pictures and summarized in a digital format of the
Figure 7-1, Initial process order
VSM using MS Visio. assessment in VSM Workshop
Select process metrics or data attributes
In this case study work the data matrices were predefined in coordination with the
stake holding managers.
As Locher (2008) suggested there are several possible matrices and data attributes
that should be considered for conducting value stream mapping (Table 7-2).
Possible data matrices by Locher (2008) This Case Study
Process time (P/T) Yes
Lead time (L/T) Yes
Number of people involved Yes
In addition roles/skills
Batch size or Frequency Yes
Number of iterations Yes
Complete and Accurate (C&A) Yes
Inventory Yes
Information technology used Data In / Data Out
Available Time/Demand Rate Yes
Rework or revisions Yes
Table 7-2, Possible data matrices by Locher (2008, p.26) and application in the case study
Figure 7-2 shows the notation of matrices relevant for an individual process step.
Inventory Process/Analysis of Process Name:

18
Test data Verb+Noun
Process and TE@ 50%, LTE
Leadtime
I P/T [h] 1-40 Roles Involved
L/T [d] 1-14
C&A [%] high
Batch 1 x week
Rework/ Complete and
Iteration Raw Data Test Plots,
0.3 Software, Pictures, PPT/ Accurate
Pictures, Notes Word/Excel,
Data In E-Mail
Batching
add L/T 1.5
Number of
People Data Out
Waiting Time 1-7 1-14 Process and

in Queue 1-40 Leadtime
Figure 7-2, Process matrices for an individual process step used in the VSM of this thesis
McManus (2005) listed several further possible matrices, but underlines the effort of
collection and the risk of overwhelming data.
The focus of the improvement effort in this case study was put on time. Process time
(P/T) and lead time (L/T) were acquired, to visualize the difference between actual
work and waiting. There are no compromises on testing data quality possible due to
the involved product, project and legal risks. However, this focus on final data- and
report quality forces rework if process steps aren’t done correctly. For this reason a
complete and accurate (C&A) matrices was selected.
The cost structure is mainly driven by long term assets like test stands and
equipment but also staff costs. As discussed in chapter 3.3.1 Planning of Product
Testing cost analysis is a major consideration in test planning and discussed in the
literature. Number of required tests and prototypes are derived in close relation to
NPD program planning. The area was out of scope of the case setting. For this
reason the effort of acquiring detailed cost data was excluded from the VSM mapping
workshops.
In addition the information on involved data exchange formats was included to
visualize handover and data formatting waste. Finally the number of items in queues
and the iterations between process steps were assessed.
Perform value stream walk-through and fill in data boxes
Visiting and observing the actual work place, or “gemba” in Japanese, is one of the
main pillar of the Lean methods (Rother & Shook 1999; Womack & Jones 1996) and
is also applicable to the product development (Locher 2008; McManus 2005; Millard
2001). However, requires the product development environment specific methods to
observe the actual work, due to the often intangible flow of information as discussed
in 4.2. Table 7-3 lists the prepared tools to visit the actual work place in product
testing.
Tool prepared Link for example
VSM with process overview as pencil and paper version -
Semi structured Interview sheets 12.1
Observation forms 12.2
Table 7-3, Tools for value stream walk through
The initial process overview from step Identify main processes in order was copied
to an A3 paper format to facilitate discussion about the workflow. Blank sheet for
notification of new process flows were also carried.
Interviews were not recorded due to company policy but also to avoid the social
dissonance effect during interviewing as discussed in chapter 2.2.2 Interviews. As the
identification of waste in the operational process was a major focus of the research,
the absence of voice recording allowed to interview and observes normal work
process at all levels of product testing operations with reduced Hawthorne effect
error.
Semi structured Interview sheets were prepared to avoid information loss during and
after interviewing. The sheets were kept with large space for individual notes
(Examples see: 12.1). Page 1 of the interview template contains a header with basic
information followed by pre formulated questions. The questions were adapted to the
individual interview and information focus. Page 2 was added to allow instant
observation notes related to the questions and the reaction of the interviewee. If
applicable, information relevant to the research objective could be classified by the
author on page 2. Page 2 was filled in during or right after the interview. In that way
the information loss due to not recording the interview was reduced to a minimum.
Interviews were prepared for:

- Product Testing site managers (PT Site Mngt.)
- Leading Test Engineers (LTE)
- Design Engineers (D.Eng.)
- Test Project Manager (TPM)
- Test Engineers (TE)
- Blue Collar Test Technicians (Tech Assist)
- Test Planning Manager (TP)
The sampling was selected to cover the micro level scope of the case research. It
was also the clear intention to avoid management bias as discussed in chapter 2.2.2.
Preparation interviews were conducted during the legacy data research in order to
gain basic process understanding and to trial some forms of interview sheets.
Observation forms were prepared to collect structured information about:

- Process matrices
- Process Inputs and Outputs, how they are transferred, and how useful they
seem
- Critical drivers
- Value aspects of the process steps
- Waste aspects of the process steps
The observation sheet was initially intended as a general data collection sheet as
suggested by Millard (2001) and McManaus (2005). It turned out that the sheet,
however, was too rigid for an interview with process owners. Nevertheless, for noting
structured observations, especially during meetings, the sheet proved to be highly
valuable. An example can be reviewed in 12.2.
Following Locher (2008) the understanding of work prioritization at each process step
was part of the interview questions and observation points. Summary matrices
calculation was not part of a prior framework, in order to maintain a flexibility of data
processing.
7.1.2 Future State Analysis

Prior to the VSM workshops a future state analysis framework was derived from the
literature in chapter 4 and customized to the case environment. However, the time
workshop participants could spend on VSM was too limited, to allow a future state
development during the VSM workshop. Furthermore, the current state assessment
in the product testing environment was complex and time consuming.
A seven step, question driven approach as suggested by Locher (2008, p.55) was
followed by the author. Table 7-4 provides an overview and the specific sub
questions that were followed during the case study research of this thesis.
What does the customer really need?
Evaluation of the current state results, focus on test task definition phase
Value, Waste and Flow assessment, summary of Kaizen in this area
How often will we check our performance to customer needs?
How often is the performance checked?
Which process matrices are checked?
Is a use of takt time concept applicable?
Which steps create value and which steps are waste?
Value and Waste assessment framework as derived from the literature in 4.2.2
Classification of finding from the current state analysis
Prioritization of Waste items in order to derive major Kaizen needs
How can we flow work with fewer interruptions?
All areas of information inventory and waiting have to be reviewed, visualization is
required. Where can pull systems replace queues?
Are decoupling point needed to separate activities? How to implement the
decoupling of information flows?
Can we establish single piece flow in some area of the value stream?
How do we control work between interruptions, and how will work be triggered and
prioritized?
Can a decoupling of the value stream help to create sequential flow?
How can we visualize and control queue sizes? Where can we apply visual
management in general?
Can a takt time concept be established?
How will we level the workload and/or different activities?
Are demand peaks present in the current state and how do they impact the test
operations? What are the reasons for demand peaks?
Should we reduce demand peaks or should we plan them?
What process improvements will be necessary?
Summary of the future state in a future state map
List of required Kaizen activities as prioritized in previous points.
Table 7-4, Overview on the future state analysis steps used in this case study work. Partly based on
(Locher 2008; McManus 2005)
7.1.3 Implementation of the future state

The reporting of VSM results in form of a current state map for each visited site and
the future state map are important measures of implementation. Nevertheless,
documents like A3 Reports or functional prototypes of the intended improvements
have to be developed to convince the management and the process participants
about the necessity of change. The unfamiliarity with Lean thinking and perception as
manufacturing management method makes implementation in product development
testing challenging (Schulte et al. 2005).
8 Case Analysis – Current State 75
8 Case Analysis – Current State
8.1 Analysis of Legacy Data

In the following chapter a short overview on an analysis on legacy project data is
given. The analysis was done before the VSM workshops and had three major
reasons.
First, by analyzing the legacy data the basic structure of activities, the terminology as
well as people and roles involved could be understood. It turned out to be an in
introductory task with major benefits for the following field studies.
Secondly, project and process management is not new for the MWFL product testing
operations. The ability to base the case study research on statistical evidence of
legacy data is tempting, especially with regard to the influence of variability in product
development processes as discussed in chapter 8.1. However, McManus
recommends: “exploit existing process information resources, cautiously” (McManus
2005, p.38) meaning that databases or reports might have different purpose than
feeding a process value stream map. Hence, a major output of the legacy data
analysis should also be a statement about the usability of the data for further
research. The ability to find and use legacy data in order to estimate future project
efforts, to understand the process and to learn from past experience, is a major part
of a Lean enterprise. Locher (2008) listed the ability to distinguish between
knowledge reuse and creation as first- and the general process focus as fourth-Lean
principle. Hence, the legacy data analysis shows the current state of process
knowledge management at MWFL product testing operations.
The third aspect of the legacy data analysis was to find test activities or processes
that contribute highly to the overall performance of product testing process and lead
time. A data based evidence to focus on certain area of test processes and activities
would increase the impact of the derived results.
8.1.1 Data Source - Analysis of Legacy Data

The main data source for the analysis is the Test Data Base (TDB) of MWFL.
The TDB is mainly a content data base for test tasks, test reports and observations,
which is web based and accessible from all MWFL locations. It contains also a
workflow of test definition, approval and documentation of reports. A date field for the
initiation of the test task, the test period start and the closure of the work flow is
given. Since all time data is given in date format the highest resolution for test time is
1 day. The mass data retrieval from the TDB for analysis purpose is not normal
practice at MWFL forest machinery testing. A special request was issued to the
system administrator by the author.
8.1.2 Demand Rate for Test Tasks

To get a basic understanding of the demand rate relevant for the test sites the
number of new test task per day were considered. All tests were counted
independently of their workflow status. Table 2-1 shows the average demand rate for
new test tasks for product platforms, forest harvester and forest planters.
Platform Forest Planter Forest Harvester
Number of Test Task 2232 5329
Period Start 23-Aug-2004 5-Mar-2001
Period End 23-Jan-2013 23-Jan-2013
Days 3075 4342
Workday 2198 3103
Average demand for new test tasks 1.02 1.72
per day
Table 8-1, Average demand for new test tasks per day
Figure 8-1 and Figure 8-2 show that the demand rate for new tests per workday
fluctuates (blue line). Demand peaks more than ten times higher as the average are
frequent. The red line presents a moving average of five days in order to symbolize
the average daily demand rate of one working week. Even the moving average
shows that demand rate is frequently more than four times higher compared to the
average demand. For the FH platform frequent demand peaks are visible around Nov
2010 for FP platform demand peaks have increased since 2007.
The presence of demand peaks as input to the product testing shows that upstream
processes of product development work in batches. Several possible reasons could
be named, like program schedules, trade fairs or new international standards.
Figure 8-1, FP Platform - Demand rate for new test tasks per day
Figure 8-2, FH Platform - Demand rate for new test tasks per day
The legacy data analysis creates awareness about the demand fluctuation and can
be used to facility a discussion with the different process participants. For the
following VSM effort the average value and the fluctuation of more than ten times will
be used as sufficient process matrices.
8.1.3 Process- and Lead Time of Test Tasks

Raw data for closed test tasks was loaded from the TDB database.
Product Platform, Period and Data amount:
 Forest Planter (FP) Platform: 23 Aug 04 – 23 Jan 13, 1611 Test tasks
 Forest Harvester (FH) Platform: 05 Mar 01 – 24 Jan 13, 1448 Test tasks
Major matrices for the case study research are the process time (P/T) and the lead
time (L/T) of test activities. To analyze the data a column for process time and lead
time of each test task was added. The time was calculated as:
[ ] ( )
[ ] ( )
The calculation of lead time L/T showed that 157 test workflows were initiated after
the actual test was finished. This is an indication for very urgent tests or lack of
planning. These 157 tests were filtered out, 1327 test tasks remained for analysis.
To focus the attention of the research, test activities with highest time contribution to
a development project needed to be identified. The test time contribution was
calculated by multiplying the median value of the process- or lead time with the
number of tests which were performed for each test type.
The analysis was done with the statistical software Minitab 16.
Following analysis methods were performed:

 Boxplot of process- and lead time in relation to the test type
 Basic descriptive statistics
 A calculated contribution to the overall accumulated test time, which was
shown in a Pareto Chart.
The analysis of process- and lead time in relation to test type definition showed that
the test time was not normal distributed. Many statistical tools could not be applied
for that reason.
Results – P/T and L/T Analysis of Legacy Data
From the median values printed on each box in Figure 8-3 one can see that the
process time of tests varies between the different test types and that the distribution
is rarely centered within each test type group. The size of the boxes shows the range
of different process times within each test type group and the stars show outliers.
One can see that test type specific process time characterizes are present. It is
important to notify that tests without defined test type are collected in group “*”. In this
group the majority of test is short, median 7 days, with relatively low variance in
process time.
Figure 8-3, Boxplot of process time (P/T) of test for the Forest Harvester (FH) Platform in days for
coded test types (MWFL 2013b)
Figure 8-4 shows that tests without test type information are with 38% the highest
contributor to the overall test time.
Figure 8-4, Calculated contribution to the overall accumulated test time for each coded test type group
of the Forest Harvester (FH) Platform (MWFL 2013b)
The Analysis was repeated in the same way for lead time and for Forest Planter (FP)
Platform. The qualitative results of box plot and Pareto Chart were the same. For the
FP platform a histogram analysis of process time showed that the majority of tests
have a very short duration of 0-2 days and follow a Weibul distribution (Figure 8-5).
Figure 8-5, Histogram of process time for the Forest Planter (FP) platform tests (MWFL 2013b)
The reason for this characteristic can either lie within poor data recording, in which
test workflows are started and closed in the TDB system the same day following a
batch work principle. Or very short test tasks are a common practice.
The second option would differ from the hypothesis that certain test types with high
complexity and duration have to be improved in terms of process time. The high
frequency of short tests would require a higher focus on the handling of test rather
than the actual process time. Both possibilities have to be clarified during the field
investigation phase.
8.1.4 Summary - Analysis of Legacy Data

An average demand rate of 1 and 1.7 new test tasks per day was identified from the
legacy data analysis for the forest harvester and forest planter platform. High demand
peaks were identified, which exceed the average demand by more than ten times.
Demand peaks show a batching characteristic of the upstream product development
process.
A time contribution ranking of test types was derived by summing up their

contribution to total test time. The results for process and lead time were combined
for both analyzed platforms FP and FH.
Table 8-2 shows the most time consuming test types at MWFL. The field - and
endurance testing activities were out of the scope for this case study research and
were there for not considered further investigation.
1 Field Testing
2 Stress Strain Testing
3 Endurance Testing
4 Performance
5 Sound Testing
6 Engine Approvals
Table 8-2, Most time consuming test activities combined
7 Software Testing from P/T and L/T for FP and FH Platform (MWFL 2013b)
The ranking is a starting point or hypothesis, requiring further research with

interviews and experience based data, due to the following limitations of the legacy
data analysis:
 It has to be admitted that the quality of data in the Test Data Base (TDB) is low
in terms of time information in relations to type of test and area of machine. In
many cases the test type attribute is not defined for tests so that these were
not counted in the following analysis. The data in the database has a higher
value in terms of the technical reports related to it.
 For a particular design project in a period of 1,5 years the two different data
sources TDB and Project Database showed different timing results.
 The using habits of each site staff combined with the ability to enter faulty or
incomplete data lower the confidence of the conclusions drawn from the data
analysis.
The legacy data analysis served the primary intention to focus the attention on
certain test activities and processes. It also provided an in-depth understanding of
the basic structure of test activities, the applied terminology and the people and roles
involved. It did however, not serve as a statistical evidence for the process time and
lead time values for individual test process steps due to the limitation of input data
quality. The drawbacks of legacy data for value stream mapping efforts as discussed
in the introduction of this section can be confirmed. Furthermore did the high effort
required to retrieve and analyze legacy data from the TDB data base show that
process and organizational learning from past projects is underutilized in the case
company.
8.2 Visit of Site A - VSM Workshop, Current State

The Product Testing site of MWFL in Denver, Colorado, USA was visited for 4 days
with the goal to investigate facts on the workflow of testing activities. The impact of
recent structural changes on the workflow of testing was major focus. To facilitate the
investigation, the Value Stream Mapping tool (VSM) was used in form of a current
state analysis.
8.2.1 Identification of Current Customer Needs – SIPOC

A SIPOC chart was created in brain-storming technique as starting point for the
current state analysis. The resulting SIPOC shows the point of view of the
participating test engineers and the site manager
Supplier Input Process Output Customer
Design FMEA Install Parts on Test/Installation/ Design

Prototype Observation
Manufacturing Machines Report Manufacturing
Test Requirement
Check Resources:
Supplier Prototype Final Customer
Machine, Staff,
Installations for
Field Issue Parts
further Legal Department
Tracking investigation
Product Run Test/
Program Plan
Management Analyze Data Schedule/Budget Product
Plan Management
Figure 8-6; SIPOC framework created during the VSM workshop at Site A
8.2.2 Current State Value Stream Map

For the VSM (Figure 8-7) a circular process layout was chosen by the mapping team
because the internal customer design group creates test requirements and receives
the test results. Internal Customers are on the right side and suppliers of test
equipment, prototypes machines and parts from external and internal suppliers are
on the left side. The process steps were roughly grouped into administrative and
planning tasks, technical value adding or enabling tasks and quality checking tasks.
A color code legend in the lower left area was added to allow a simple visual
understanding. It should be noted that this assessment does not show the value or
waste of a process step. The value and waste identification was part of the future
state assessment in chapter 9.1.3.
The upper area of the map shows the process of test preparation and administration
leading to list of activities called lab task list. The list assigns responsible line
manager, estimated timing and priority. The lab task priorities are influenced by the
overall testing plan which is discussed in the Rebalance Test Plan meeting involving
different managing stakeholders. In parallel to the preparation and administration
workflow a “high priority” work flow was explained by the interviewees. This flow is
not specified in the circulation process descriptions but found to be important for the
value stream analysis. According to the testing-site manager the urgent tests are
“taking up to 50% of the lab capacity”. According to an interviewed design engineer it
is fairly simple and un-bureaucratic to push tests into the lab if needed. “Things can
get started within 3h” without the normal approval and review process but with the
required technical reviews if management requires so. An interviewed leading test
engineer (LTE) said that these urgent tests sometimes disturb the work in the lab.
Started jobs have to be stopped often resulting in time wasted for the prior
installations. The LTE also said that he and his colleagues are sometimes frustrated
when the work process defined by the management is bypassed by the management
it selves.
The interviews during the value stream walk revealed that a high amount of flexibility
is required to handle certain urgent tests, which is not defined in the normal workflow.
The fact that flexibility is required from the demand side, but not managed by the
process, leads to frustration among the staff. For these reasons the additional high
priority test flow was a major insight from the VSM current state workshop, interviews
and observations at site A.
A push flow connects the administrative and planning side, the lab task list and the
LTE who coordinates and partly participates to the actual testing work in the lower
area of the VSM. The push system was identified because the LTE is assigned to the
task already during at the “review draft TT”, a predefined timeline and priority is
assigned to the task so that the LTE has to work on what is pushed towards him.
A comment of the site manager showed that the pushing of information is preferred
since it reduces the effort of information search for the LTE. Especially between the
Write Test Task and Review Draft Test Task process this push has to be done by
e-mail. This observation of the process revealed, that the Lean principle of pull
instead of push is not obvious to the product development environment, since it can
lead to waste like information search and waiting for information. The future state
definition has to address these problems and come up with solutions that avoid or at
least trade off both waste types (see chapter: 9).
In the lower left area (E-B,8; Figure 8-7) the supply of test equipment & material,
production machines & parts and Prototype Parts is shown. The supply side was
differentiated to show that different processes are required to order, receive and
account for. In reality the supplier base is even more differentiated, but the three
basic ways of ordering: Internal “Order as needed”, “SAP-Purchasing process” and
“Engineering Order” for internal prototype part manufacturing shows the complexity of
the current state.
The different materials and machines are shipped into storage areas and a machine
parking yard from which Setup Test and Setup Test Machine retrieve as required.
Some waste factors like searching for the right material or overlapping of resource
schedules, which also results in waiting, were reported by the interviewees.
Especially shop floor staff like LTE, TE and Tech Assists reported about difficulties in
this area, a major benefit of the micro level approach this case study had. Due to the
experience in the product testing environment the author could overcome social
dissonance and elite bias as discussed in 2.2.2.
Since, several 5S activities were in progress in this area of the value stream during
the period of the case research, the area was not further investigated by the author.
However, several interview comments and observations revealed Kaizen ideas in this
area which were noted and assessed according to the prior defined framework. The
derived information were presented to the Kaizen and 5 S responsible, with positive
feedback.
The following activities of Setup and Conduct Test as well as Process and Analyze of
test data are characterized by high variability. Complete actives could not be
observed due to the time limitation. However, with interviews and observations
different drivers of variability and waste could be identified.
A large portion of experiential knowledge is required for a reliable assessment of
process time. Learning curves leading to 50% time reduction for a second setup of a
complex test were reported by one test engineer.
It was also observed that questions like “how long does this setup usually take?”
made interviewees think about a process time. Asking about possible interruptions,
waiting or concurrent work showed that these drivers of lead time are usually not
considered.
8 7 6 5 4 3 2 1
1-7 1-7 1-7 1-7 1-7 1-7 0-6 1-7 0-2 1-7 1 1-7 9-28
0.5 0.6 0.8 0.5-2 0.5-2 0.5-1 3.4-6.9
1.5
H Rebalance Test Plan Set Priority of TT Review TT Review Draft TT Write Test Task (TT) Approve Test H
4 32 6 I 1.5 Requirement
PT Site Mngt, LTE, PM, PE on Program Management., D.Eng
TPM, Ch. Eng., PT Site Mngt TPM, Ch. Eng., PT Site Mngt LTE, D. Eng, TE if needed D. Eng
demand
P/T [h] 0.5 I P/T [h] 0.6
I P/T [h] 0.8
I I
P/T [h] 0.5-2 P/T [h] 0.5-2 P/T [h] 0.5-1
L/T [d] 1-7 L/T [d] 1-7 L/T [d] 1-7 L/T [d] 1-7 L/T [d] 1-7 L/T [d] 1-7
C&A [%] medium C&A [%] medium C&A [%] medium C&A [%] high
Batch 3-10; 1/week C&A [%] medium C&A [%] medium
Batch 3-10; 1/week Batch 3-10; 1/week Batch 1; 1/week Batch 1 Batch 1-5; 1/week
Standard test
Project Plan, E- Lab List Lab List, Project Lab List, TDB Office, Lab List, 0.7 TDB, Lab List TDB, E-Mail, 2 TDB, E-Mail Program Plan, 1 Office Program Plan, From Legacy Data
Mails,
1 Plan, Rough TDB Lab List CAD, FEA, CAD, FEA,
G Lab List Management Resource Plan Office, FMEA, Office, FMEA, G
Meetings add add add field issues add field issues
2 2 3 2
L/T L/T L/T L/T
6.0 9.0 9.3 5.0 1.0 3.0 Inpu t: 30 projects/year,
P New Average 1 task per day

WA
(0-17.5 per day fro m peek)
Check TMS, be in meeting
61 Demand in batches d ue to
Consult LTE
program, high variability
OXOX
F Rejected F
Lab Task List High
~50% of IP Priority I
No Worklaod Leveling workload L/T:
Track Status of Test: 0.5-1d
Test
Higher
New, WA, P, IP, RP, RA, TC
Supply: Management
Test Customer: Design
0.7
Equipment & PV Admin For iterative Problem Solving
Pass
Material Write Observation tests process
E I cycle of 1 d is E
TE@ 50%, LTE add L/T desired also used
Setup Test 18 P/T [h] 0.5-2 for legal aspect and
IP L/T [d] 0.2-2 Search of old tests,
TE, Tech Assist
LTE C&A [%] 60 Frequency of use
Batch unknown
P/T [h] 1-80 I
L/T [d] 1-30 Lab Software,
TE 1 Picture on TMS, Office,
C&A [%] medium
Batch TE 2 Camera, Paper E-Mail
Test TDB, Drawings, ... 1.5 Notes TDB
Pictures, Talk to TE
Equipment Guidelines, Notes,
Verbal Sub View Test Status
D D
Figure 8-7; Current State map of product testing site A of MWFL

Supply: Tasks, Test
Production Software/ TC
1
Hardware RA
Machines & RP
1.5
Parts for Test I
Machines Review Test Conduct Test Process/Analysis of Review Test Results Create Test Report 60 Approve Test report
18 20
on Yard 5 5
Setup Test Machine 1 Setup TE, Tech Assist Test data LTE, D. Eng, TPM TE, LTE @ 50%
Tech Assist TE, LTE @ 50% TE@ 50%, LTE PT Siter Manager
add 1. I I I P/T [h] 0.5-2
I P/T [h] 1-7
I
L/T 6 P/T [h] 1-4 P/T [h] 1-80 P/T [h] 1-40
L/T [d] 0.5-3 L/T [d] 1-30 L/T [d] 1-14 L/T [d] 1-7 L/T [d] 1-14
C P/T [h] 1-80 C&A [%] medium C&A [%] medium C
C&A [%] high C&A [%] high C&A [%] high P/T [h] 0.2
Supply: L/T [d] 1-30 Batch Batch Batch Batch Batch 1-5
C&A [%] medium L/T [d] 1-7
Prototype Batch TDB, Raw Data Plots, Pictures, Word/Excel, C&A [%] high
Raw Data Test Plots, Plots, Pictures,
Experienc TDB, Procedure Test 0.3 0.7 PPT/Word/ PDF, TDB, E- 2
Parts Software, Pictures, PPT/ PPT/Word/ Batch
TDB, Drawings, TDB Reports, e Documents Software, Excel, E-Mail, Mail
Pictures, Notes Word/Excel, Excel, E-Mail, E-Mail
Parts Pictures Pictures, Verbal TDB, E-Mail TDB
E-Mail Verbal Comments
in Stock Notes
1 add L/T
add
2 add L/T
2.0 1.5 add L/T 1.5 3.0 L/T 1.5 1.0
Work day: 250 @ 8h add L/
1.5 T
80%, 20% Admin, Absent
B B
Staff: 20
1-30 1-30 0-5 0.5-3 1-30 1-30 1-7 1-14 1-5 1-7 1-5 1-14 1-5 1-7 6.5-105
Total available: 32 000h
1-80 1-4 1-80 1-40 0.5-2 1-7 0.2 5.5-293
Admin/Planning
Technical Value 1-30 1-30 Comments: Low Statistical Evidence, All data disguised, Use Layer to view all Infomation VSM PT Denver File:VSM_1_ALLState_Neutral_1_2
Add/Enabling Internal
MWFL
1-80 IP Start: Right Up, End: Right Bottom, Matrices Data from 9 meeting observation, interview, TT Date: 28 Feb 2013 .vsd Forest Harvester
Quality Check
“milestone” Testing
Status in Stock is based in Lab Sheet, 22. Feb. 13; Presented to PM, Site Mngt: 22 Feb. Status: Current State Author: Daniel Walew
85
A A
8 7 6 5 4 3 2 1
Hence, the initial time information gathered from interviews is very subjective. The
information is mainly of qualitative nature. For these reasons the author decided to
track time information of the lab task list for the following research time and evaluate
the results as quantitative data. The issue is further discussed in the future state
chapter 9.
According to the interviewed product testing staff a high variation of process- and
lead time is a fact in product testing due to the variability of tasks especially in new
product development. The interviewees named drivers of variability like the absence
of a clear test specification and procedures for new tests and systems, mal
functioning tools and lack of experience. The assessment of time planning, hence, is
largely based on experience and mentorship. For that reason the author decided to
collect and tag information from interviews according to factors driving duration and
variability of test (example: 12.1). The initial assessment of legacy data in 8.1 with the
attempt to correlate process and lead time with test types was by far too limited.
According to the interview data far more influencing factors have to be considered. In
the future state chapter 9 these points will be summarized.
A side effect of the actual test work are observations or problems related to the
design under test but also other performance criteria of the part or product (center,
Figure 8-7). Documented observations are the starting point of a cross functional
problem solving process. This process is well defined and was not scope of the VSM
work shop. However, in the current state VSM the writing of observations was
included because it is a major deliverable of a test from customer point of view. In
addition it consumes resources that are usually not planned.
It was observed during a cross functional problem solving team meeting that several
observation were not understandable for the audience. In this meeting 30% of the
observations were rejected due to missing information. Like a defective part in
production this is a major waste source for the downstream problem solving process
but also a rework effort for the test engineers. However, it was also not very clear
which information was really required to define an observation properly, which is a
lack of information pulling. This area was also considered in the future state analysis
in chapter 9.
The lower right area of the VSM (Figure 8-7) contains a review of test results which is
a meeting with the relevant test engineers to discuss the results of the test. An
interviewed design engineer said that this is “what really matters” to him. Results and
data to take decisions about a new design are needed, especially if iterative testing
with different setups is required. The iterative part is shown as a dotted line leading to
a high priority test.
The time-consuming writing of a formal test report, required to get an approval of the
responsible testing site manager was not well appreciated by the interviewed design
engineer. The initial SIPOC analyses showed, however, that from a knowledge-,
project management- and legal-point of view final test reports are required. These
have to be in a high quality, according to the site manager, which requires the 100%
review and approval of the site manager before the process can be closed. Hence,
relatively high inventories could be found in front of the report writing and approval
process step.
8.2.3 Summary
An initial meeting effort of 6 hours with one manager was spent to get a basic
process overview, following a current state VSM approach. In addition the process
was “walked” by the author observing 9 meetings and conducting 11 interviews with
different level managers, engineers and technicians.
Since meetings are a major part of the product testing workflow, a structured
observation sheet was used to capture the matrices defined in the initial VSM. Also
value- and waste-drivers were noted during the meeting observation, according to a
predefined framework. Interviews were conducted in a semi structured way focusing
on the individual test process participation, planning efforts, knowledge management
and experience about critical drivers. The interviews were conducted in the normal
work environment of the interviewee. Interviews and meeting observations were
transcribed from initial notes and the statements were assessed according to
matrices discussed in paragraph 7.1.
During the interviews and observations individual aspects of value and waste, Kaizen
ideas, process issues and aspects driving the duration and variance of testing
activities were noted.
The items on the Kaizen list were characterized current situation and desired future
state and assessed according to implementation impact, effort, time and required
steps, in order to prioritize further implementation. Since the future state was not
focus of the initial VSM workshop, the Kaizen list was not part of an overall futures
state map at this point. The future state analysis is discussed in chapter 9.
Major Findings:
A general willingness to work according to a defined process by design and testing
employees was observed. However, different forms of process descriptions were
circulating among the employees, showing that the process communication was
weak. Although process work was preferred by the employees a large amount of
work was bypassing the normal process due to urgency. One manager said that
“50 percent of the total workload requires very flexible, short term handling.” And the
urgency is communicated directly by the higher management. In contrast, the global
testing manager estimated a maximum of 25 percent of urgent work during a VSM
review discussion, but agreed on the general presence of urgent work. In any case,
quantitative evidence for the volume of urgent demand is not available.
Although a central document database allows sharing of a project task list with
integrated priorities, the update and discussion is done with various spreadsheets.
The user-friendliness and readability during meetings is not provided by the central
database, which was reported as major reason for the behavior.
The internal data management is advanced but lacks integration with global systems.
Best practices are likely to be found but have to be promoted to user groups at other
sites. During the initial phase of test task definition a high rework ratio was reported in
interviews. One test engineer made use of checklists which he shared with the test
requestors. In the checklist basic information requirements were noted in order to
structure the discussion during a test task review meeting.
The current state VSM and the Kaizen list with 27 items give a more structured result
overview if compared with the initial process definition.
8.2.4 Result Limitation

The quantitative time data required to create a value stream map was of low quality
or not existing when derived from interviews. The interviewees made only very
relative time estimation like “that depends totally on the test task” pointing out that the
actual test task has a big impact on the time. Limitation of quantitative time data is a
common problem in PD VSM (McManus 2005; Montoro-Lopez 2012)
For that reason it was decided to invest time of this case study research into a
continuous time data and testing using the input information into the lab task list. The
tracking of quantitative time data is part of the future state results in Table 9-8, p.124.
It has to be admitted that the available time of the local team was very low. That
limited the possibility to conduct a full, cross functional VSM workshop. Nevertheless,
it gave the author the possibility to observer normal working conditions.
The recent process changes at the visited site lead to a limitation of the current state
result.
8.3 Visit of Site B - without VSM Workshop

The Product Testing site of MWFL in Old Town, Nebraska, USA was visited for 3
days with the goal to investigate facts on the workflow of testing activities and
receiving management feedback on the research progress. Five semi structured
interviews were conducted; general and VSM related observations were made and
documented. Three Kaizen ideas were documented and added to the general list of
Kaizen ideas from this research.
During the site visit urgent test activities where ongoing which made a VSM
workshop unfeasible. However, it was possible to observer the work of a cross
functional team that performed fast learning cycles with data driven feedback from
test engineers, analysis with design- and system engineers and subjective feedback
from machine operators. Due to the importance of the development project
management was also directly present at the test site. A big room was used to host
all people required to control the flow of activities. In the literature this kind of room is
often referred to as “Obaya”, “warroom” or “program room” (J. Liker 2003;
Oppenheim 2004; Rebentisch 2005). The purpose for “Obaya”, easy information
management and fast decision making as presented by Liker (2003) were main
purpose of the “Obaya” in this case. Especially the advantage of short ways to avoid
walking to conference rooms as shown by (Lindlof & Soderberg 2011) required
moving the “Obaya” temporarily to the testing area which is remotely located.
However, no VSM was attached to the walls as Oppenheim (Oppenheim 2004)
suggested as major driver of Lean implementation effort, but Gantt charts were used.
For the coordination of the actual workflow the verbal and whiteboard based
communication management were used.
Since site B of MWFL is operating according to the same predefined process as

site A, the VSM from site A served as a guideline to focus the attention of the author
during the interviews. The interviews were conducted in a semi structured way.
Interview partners were the testing site manager, a leading test engineer, a test
engineer and a test technician.
The site manager was asked about the major steps in their workflow in which he
listed in general the same process steps as in the VSM of site A. A second review of
test tasks, however, is not required according to the site manager. Trust in the work
of the LTE in the first review and a short verbal presentation during the “Set Priority of
TT”-meeting made the second review needless.
Although the site manager underlined the stability and usefulness of the current
process, especially for well-defined standard tests, he complained that for critical
tests the approval process with weekly meeting schedule is too long.
“It takes about two weeks to get the approval” (Site Manager).
This is a major reason why some tests bypass the process and go directly to the “Lab
task list” as high priority. Fast learning cycles, with high variability related to the tasks
require a more flexible process path, from the site manager’s point of view.
The site manager underlined the importance of progress visualization for his team.
“The visualization of progress and improvement is important for all levels” he said
and referred to the “old” process in which inbox piles did never reduce because work
was pushed directly to the test engineers desk. This statement was independently
supported by a leading test engineer who liked the ability to focus on a job because
the “Lab task list” gave a clear prioritization and answerers the basic question “what
to do next”.
Other Process matrices Information

The process step of writing observations is done in a data base only. To allow a good
information flow the LTE participates in the downstream problem solving process.
The site manager pointed out the benefit of a cross functional view for the LTE, which
reaches beyond the simple review of test tasks.
The site manager also pointed out that a relative high effort is needed to gather all
information needed to write reports. The information flow from the initial “Write Test
Task” processes to the “Setup Test/Machine”-, “Conduct Test”- and
“Process/Analysis of Test data”- processes are not streamlined. Often test engineers
would prefer to start the next test after reviewing the results with the relevant design
engineers without writing a formal report. The waste due to the various data handoffs
is a major barrier in writing the reports.
An important insight about the replenishment of test equipment was given by a test
engineers who also selects and orders instrumentation if required and within a
budget limit. A flexible and fast replenishment process which, however, does not
support cross locational learning. On the other hand the test engineer confirmed a
“steep learning curve” for the test setup activity. Especially instrumentation relevant
issues can increase the process time of the test setup by up to 100 percent,
compared to a repeated setup with known instrumentation, according to the test
engineer.
An interviewed technician also underlined the importance of the lab task list with
priorities. At the time of the interview the technician was working on four separate test
tasks and had “about three to five” tests waiting for processing. This information gives
one data point for the information inventory matrices.
8.3.1 Major Findings

- The current state “Lab task List” is already a good practice from the process
participant’s point of view.
- No second review is done after a test has been reviewed by an LTE.
- The approval process usually takes about 2 weeks and is bypassed if needed.
- Team interaction is done in a big room or “Obaya” close to the product if
critical project phase requires so.
- Feedback about progress is given by LTE directly not via an administrative
staff.
- Various data handoffs during the testing phase make the report writing difficult
and time consuming.
The major findings of the research at site B were entered into the current state VSM
of site A and marked in yellow (Figure 8-8).
8 7 6 5 4 3 2 1
1-7 1-7 1-7 Lead Time1-7 1-7

according to site manger: 2 weeks due1-7 0-6
to weekly frequency of meetings 1-7 0-2 1-7 Value:
1 LTE 1-7 9-28
involved,
0.5 0.6 0.8 0.5-2 0.5-2 0.5-1 3.4-6.9
awareness
1.5
H Rebalance Test Plan Set Priority of TT Review TT Review Draft TT Write Test Task (TT) Approve Test H
4 32 6 I 1.5 Requirement
PT Site Mngt, LTE, PM, PE on Program Management., D.Eng
TPM, Ch. Eng., PT Site Mngt TPM, Ch. Eng., PT Site Mngt LTE, D. Eng, TE if needed D. Eng
demand
P/T [h] 0.5 I P/T [h] 0.6
I P/T [h] 0.8
I I
P/T [h] 0.5-2 P/T [h] 0.5-2 P/T [h] 0.5-1
L/T [d] 1-7 L/T [d] 1-7 1-7
L/T [d] Not Done in L/T [d] 1-7 L/T [d] 1-7 L/T [d] 1-7
C&A [%] medium C&A [%] medium C&A [%] medium C&A [%] high
Location B C&A [%] medium C&A [%] medium
Batch 3-10; 1/week Batch 3-10; 1/week Batch 3-10; 1/week Batch 1-5; 1/week
Batch 1; 1/week Batch 1 Standard test
Interaction Project
in Plan, E- Lab List Lab List, Project Lab List, TDB Office, Lab List, 0.7 TDB, Lab List TDB, E-Mail, 2 TDB, E-Mail Program Plan, 1 Office Program Plan, From Legacy Data
Mails,
1 Plan, Rough TDB Lab List CAD, FEA, CAD, FEA,
Room”
“Obaya”/”BigManagement Office, FMEA,
G Lab List Resource Plan Office, FMEA, G
Use of Gantt Chart
Meetings add add add field issues add field issues
2 2 3 2
L/T L/T L/T L/T
6.0 9.0 9.3 5.0 1.0 3.0 Input: 30 projects/year, 150
IP P validation tas ks/year

New
Average 1.6 task per day
Check TMS, be in meeting
New 0-25 task per day span
Demand in batches due to

OXOX
program, high variability

Order By Test
F Not mentioned F
Engineer or LTE Lab Task List High
with % value
~50% of IP Priority
Good Priority,
No Worklaod Leveling workload L/T:
But sometimes
Update 1/week
Track Status of Test: 0.5-1d
Test
needed to pas Higher
New, WA, P, IP, RP, RA, TC
Supply: “slow” approval Management
Test 4 for one Not Done in Customer: Design
Location B 0.7
Equipment & TE 18 PV Admin For iterative Problem Solving
Pass
Material Direct Write Observation tests process
E I cycle of 1 d is E
I Feedback by TE@ 50%, LTE desired also used
Setup Test add L/T
LTE P/T [h] 0.5-2 for legal aspect and
TE, Tech Assist L/T [d] 0.2-2 Search of old tests,
LTE C&A [%] 60 Frequency of use
Batch unknown
P/T [h] 1-80
TE 1 Picture on TMS, Office,
C&A [%] medium
Batch TE 2 Camera, Paper E-Mail
Test TDB, Drawings, ... 1.5 Notes TDB
Pictures, Talk to TE
Verbal Sub View Test Status
Figure 8-8, Current State map of product testing site B of MWFL

D Supply: D
Tasks, Test
Production Software/
1 TC
Hardware
Machines & 1.5
Parts for Test I
Machines Review Test Conduct Test Process/Analysis of Review Test Results Create Test Report 60 Approve Test report
18 20
on Yard18
1 Setup 5 Test data 5
Setup Test Machine TE, Tech Assist LTE, D. Eng, TPM TE, LTE @ 50%
add 1. I I I P/T [h] 0.5-2
I P/T [h] 1-7
I
I L/T 6 P/T [h] 1-4 P/T [h] 1-80 P/T [h] 1-40
Experienc TDB, Procedure Test 0.3 0.7Waste:PPT/Word/ PDF, TDB, E- 2
TDB, Drawings, TDB Reports, e Documents Software, Various
Excel, Data
E-Mail, Mail
Parts Pictures Pictures, HandoffsVerbal TDB, E-Mail TDB
in Stock Notes
1 add L/T
add
2 add L/T
2.0 1.5 add L/T 1.5 3.0 L/T 1.5 1.0
1.5 T
80%, 20% Admin, Absent
B B
Staff: 20
1-30 1-30 0-5 0.5-3 1-30 1-30 1-7 1-14 1-5 1-7 1-5 1-14 1-5 1-7 6.5-105
Total available: 32 000h
1-80 1-4 1-80 1-40 0.5-2 1-7 0.2 5.5-293
Admin/Planning
Technical Value 1-30 1-30 Comments: Low Statistical Evidence, All data disguised, Use Layer to view all Infomation VSM PV Old Town File:VSM_1_ALLState_Neutral_1_2
Add/Enabling Internal MWFL
IP Start: Right Up, End: Right Bottom, Matrices Data from 9 meeting observation Date: 13 Mrc 2013 .vsd Forest Harvester
1-80 “milestone” Testing
93
Quality Check Status: Current State Author: Daniel Walew
A A
8 7 6 5 4 3 2 1
8.4 Visit of Site C - VSM Workshop, Current- and Future State

The Product Testing site of MWFL in Munich, Germany was visited for 4 weeks to
conduct a second VSM workshop. A current state and a drafted future state were
worked out.
For the current state analysis an initial meeting effort of 1.5 hours with one manager
and 2 hours with one manager and two test engineers was spent to get a basic
process overview, following a current state VSM approach. In addition the process
was “walked” as discussed in 7.1 by observing four meetings and conducting five
interviews with managers and engineers from different organizational level.
To get a deeper insight and to verify a concept for the future state a test setup was
followed by the author. Due to the authors’ specific knowledge and experience on
experimental stress analysis a stress test was selected.
The focus of the presentation in this thesis was the information flow during a test
setup in which different roles are required and the complexity of the instrumentation
requires specific knowledge and instructions. In addition, sources of waiting waste
could be identified.
Based on the gained knowledge about the value stream in site C a future state value
stream map was drafted. The results and possible implementation steps were
presented to the local team.
The gathered information about current state, following a test setup and future state
draft are merged and analyzed across the three different sites in chapter 8.5.
8.4.1 Identification of Current Customer Needs – SIPOC

As in site A a SIPOC chart was created in brain-storming technique as starting point
for the current state analysis. The resulting SIPOC shows the point of view of the
participating test engineers and the site manager. Major difference to the SIPOC of
site A is that test know how is seen as an output that has to be shared with other test
sites.
Supplier Input Process Output Customer
Design FMEA Install Parts on Test/Installation/ Design

Prototype Observation
Manufacturing Machines Report Manufacturing
Test Requirement
Check Resources:
Supplier Prototype Final Customer
Machine, Staff,
Parts Installations for
Field Issue further
Tracking investigation
Product Run Test/
Program Plan
Management Analyze Data Test Know How All Testing Sites
Figure 8-9; SIPOC framework created during the VSM workshop at site C
8.4.2 Current State Analysis

For the analysis of the current state the same method as presented in 7.1 and
applied in the first VSM workshop was used. The results from site A and B were not
presented previously to the workshop participants in order to avoid knowledge
building error as discussed in 2.2.2. Slight modification in the interview questions
were made to focus the attention on the flowing areas of the value stream.
- Information flow between the test workshop environment and the planning and
administrative environment
- Information flow between the German offshore- and the US based main site
Since the VSM workshop in site A had shown that quantitative time data is highly
dependent on the type of project, test task, complexity and other drivers, the
interviews in site C were not focused on retrieving time data.
Figure 8-10 is the current state VSM of site C. The following pages will discuss the
major new process insight gained in site C.
The major new identified by the VSM of site C were:

 Early involvement of the test engineers into the definition of the test requirement
Due to the specific knowledge about the systems under test and a long experience of
the test engineers in site C, they were involved in the early definition of test
requirements. Although this was useful to allow a cross functional definition of
required tests, the test engineer capacity was deducted from the process steps:
“Setup test”, “Conduct test”, “Process and Analysis of test data” and the “creation of
test reports” which absolutely require the test engineer. While following a test
(presented in chapter 8.4.3) the lack of test engineer capacity was a major driver for
waiting waste.
 Review of the Draft Test Task not done in all cases
Although in the first VSM workshop with the team the review of the draft test tasks
was a required processes step for all tests, a further discussion showed that in some
cases this review is not done and tests are directly discussed in the priority set
meeting. A fixed percentage was not given, but it was assumed that 15 to 50 percent
of the tests bypass the review. This is a similar quantity as the high priority tests in
site A. Furthermore, a second review by the site manager is not conducted. On
demand the site manager can be invited to the initial review. Due to the lower number
of tests that site C has to process and the open office structure that allows flexible
arrangement of meetings and discussion, the site manager can join the discussion
very flexible also for just a couple of minutes
 Local Process Tracking

Although the process tracking with the “Lab Task List” is online available, site C does
not use the tool. Moreover, two individual spreadsheets are used to track the process
of tasks and the budget spending. The test engineers have to update these lists and
have to derive so called “workshop orders” from it. Main reason for the “workshop
order” are the need for additional detailed information to allow the “Setup Machine”
and “Setup Test” processes to be run by technical assistant staff. The technical
assistants are controlled by a fore man or line manager who also balances the
workload among the staff.
In addition the test engineers have to translate tasks and feedback information in
order to update the local and global task list. The updates are usually done in
batches once per week. Information is exchanged three times per week in a lab staff
meeting of 30 minutes with all staff. However, direct contact and discussion between
the technical assistants and the test engineers are common but not controlled by a
process. Due to the lack of local leading engineering- or administrative staff all
updates and communications have to be done by the test engineer, which directly
deducts from the available engineering capacity in the test lab.
8 7 6 5 4 3 2 1
1-7 1-7 0-6 1-7 0-2 1-7 1 1-7 6-28

0.6 0.5-2 0.5-2 0.5-1 3.4-6.9
2 Local Copy of Lab Global Lab Task 0
H OXOX Set Priority of TT Write Test Task (TT) Approve Test H
Task List List 12 I Requirement
2
- Task Tracking - 1/week TPM, Ch. Eng., PT Site Mngt D. Eng Program Management., D.Eng
- Budget Tracking Assumptions:
P/T [h] 0.6 I ~15 to 50% I
P/T [h] 0.5-2 P/T [h] 0.5-1
L/T [d] 1-7
L/T [d] 1-7 L/T [d] 1-7
C&A [%] medium
C&A [%] medium C&A [%] high
Batch 3-10; 1/week Batch 1-5; 1/week
Batch 1 Standard test
Lab List Lab List, Project 2 TDB, E-Mail Program Plan, Office Program Plan,
Plan, Rough Review Draft TT 1 From Legacy Data
CAD, FEA, CAD, FEA,
Resource Plan Office, FMEA, Office, FMEA,
G G
Update Local List add field issues add
LTE, D. Eng, TE if needed 3 field issues
L/T 2
9.0 L/T
1.0 3.0 Input: 10 projects/year, 50
P/T [h] 0.5-2
TE L/T [d] 1-7 validation tas ks/year
New
P/T [h] 6 C&A [%] medium Demand in batches due to
L/T [d] 1-7 Batch 1; 1/week
C&A [%] medium TDB, Lab List TDB, E-Mail, program, high variability
TE
Batch 3-10; 1/week Lab List High
Lab List, Project Plan, E- Priority

Workshop Mails, Global/
F Order by e- 5.0 Test F
Local Lab Task
mail list Higher
Lab Staff
Management
1.0 Meeting
- 3/week, 14 people,
Supply: 0.5h
Test Customer: Design

Work Shop Order 0.7
Equipment & By e-mail For iterative Problem Solving
Pass
Material Write Observation tests process
E 12 I cycle of 1 d is E
TE@ 50%, LTE add L/T desired also used
Setup Test IP P/T [h] 0.5-2 for legal aspect and
TE, Tech Assist I L/T [d] 0.2-2 Search of old tests,
Fore Man C&A [%] 60 Frequency of use
Batch unknown
P/T [h] 1-80
Picture on TDB, Office, E-
C&A [%] medium
Batch Tech Assists Camera, Paper Mail
Test TDB, Drawings, 1.5 Notes TDB
Pictures,
Verbal Sub
D Supply: D
Tasks, Test
Figure 8-10, Current State map of product testing site C of MWFL

Production Software/
1 TC
Hardware
Machines & 1.5
Parts for Test I
Machines Review Test Conduct Test Process/Analysis of Review Test Results Create Test Report Approve Test report
on Yard 16 32
1 Setup 5 TE, Tech Assist 3 Test data 1
Setup Test Machine LTE, D. Eng, TPM TE, LTE @ 50%
add 1. I I I P/T [h] 0.5-2
I P/T [h] 1-7
I
L/T 6 P/T [h] 1-4 P/T [h] 1-80 P/T [h] 1-40
Experienc TDB, Procedure Test 0.3 0.7 PPT/Word/ PDF, TDB, E- 2
TDB, Drawings, TDB Reports, e Documents Software, Excel, E-Mail, Mail
Parts Pictures Pictures, Verbal TDB, E-Mail TDB
in Stock Notes
1 add L/T
add
2 add L/T
2.0 1.5 add L/T 1.5 3.0 L/T 1.5 1.0
1.5 T
TE: 3 , Site Mngt.: 1
B B
Tech Assist: 10
1-30 1-30 0-5 0.5-3 1-30 1-30 1-7 1-14 1-5 1-7 1-5 1-14 1-5 1-7 6.5-105
1-80 1-4 1-80 1-40 0.5-2 1-7 0.2 5.5-293
Admin/Planning
Technical Value 1-30 1-30 Comments: Low Statistical Evidence, All data disguised, Use Layer to view all Infomation VSM PV Munich File:VSM_1_ALLState_Neutral_1_2
Add/Enabling Internal
MWFL
1-80 IP Start: Right Up, End: Right Bottom, Matrices Data from 9 meeting observation Date: 13 Mrc 2013 .vsd Forest Harvester
Quality Check
“milestone” Testing
97
Status: Current State Author: Daniel Walew
A A
8 7 6 5 4 3 2 1
 Supply Side
It was found that the order processes on the supply side of the value stream are
significantly different from site A. Three approval steps are required to order test
equipment. Main reason for the complexity of the process are German accounting
regulations. For the logistics aspect of part- and machine shipment among different
locations within Europe, more than nine different internal service providers were
required. A complexity that has to be considered as administrative workload and has
to be changed in the long term organizational structure.
 Writing Reports and Observations – Language Barrier

Although the flow of activities during setup and conducting tests is comparable to flow
in site A or B and the detailed technical analysis would be a separate project, the
reporting and observation writing have differences. Both have to be translated.
Especially information derived from the machine setup, which is done by German
speaking technical assistant. However, it was observed that the technical assistants
have the ability to read complex technical drawings independently of the language.
Workshop orders are, therefore, often connected to notes in technical drawings.
These information flow easily into the final reports or observations and require low
translation effort representing a reduction of data handoffs.
 Capacity and Task Planning

It was mentioned and known by the site manager that an additional administrative
effort is required by the test engineers to fulfill the planning and review area of the
value stream and to instruct and participate to lab activities. The balance of three test
engineers and ten technical assistants is a constraint of leading to a non-saturation of
the technical assistants. During VSM workshop 12 tests were tracked in progress
with 3 test engineers and 10 technical assistants available. The value stream map
shows the areas of effort spend and improvement points for the future state.
8.4.3 Following a Test Setup

In the following section a test setup process was followed in order to understand the
flow of information and to create a better understanding of the current state.
A stress test was followed during setup phase. The status of the setup was advanced
when the observation started. A workshop order was created by a test engineer to
initiate the setup. The machine setup was finished by technical assistants. In total the
lead time was already four weeks.
Specific instrumentation, data acquisition and processing were needed to be setup
by a qualified test engineer, before the actual test could be performed.
Information flow during the setup

The setup process was partly documented but not fully available. The information
had to be retrieved from a paper folder and different data files on a local server. In
total 14 sub-tasks were identified to finalize the test setup before running the test. A
setup review was included in the setup steps.
There was no tool available to document the setup steps intuitively. For this reason
and to use visual management the author decided to integrate a task board
(Figure 8-11) as documenting tool, a method common in agile scrum management as
discussed in 3.3.1. The task board is shown in on the left “To Do” side the steps
required to setup the test instrumentation were noted on printed templates.
In the middle area “In process” steps were pinned. Different roles A, B, C, D were
integrated, to represent skills like engineering, electrician or mechanical assistant. An
“On Hold” field should give the possibility to signalize an issue with a specific process
step. Pens were available to note as desired on the task sheets.
On the right side “Done” steps were pinned. Using the clock and a calendar the
participants were asked to note the process time on the step cards.
To visualize the progress of activities a progress chart was added in the lower area of
the task board. The task board was placed in the workshop directly next to the test
setup area. The progress was documented by taking pictures of the individual tasks
and the progress over time.
Workshop Order
Test Task
In Process
- 4 person
- Each:
1 x “In Process”
1 x “On Hold”
Progress Chart
Figure 8-11, Task board to follow the test setup
Feedback from using the task board:

 All the lab staff found it easy to understand the task board structure after a short
introduction of five minutes.
 Progress chart showed all participants the urgency of activity but also the
immediate positive feeling of progress
 The technical assistants were willing to do updates on the task board. Since the
normal updating process with the foreman was done in parallel it was not required
for technical assistants. One out of three temporary task owners made use of
reporting progress by moving the task cards.
 The foreman pointed out that the free access to the task board could be exploited
by some technical assistants. He suggested making updates only based on group
discussion, perhaps during the daily briefing that was done anyways each
morning by the fore man.
 The progress chart visualized not only the progress but also the relation between
process- and lead time. Irregular steps at the end of the available setup time show
that the real process time of a task was much lower than the initial assumption.
 During the followed test setup a lack of dedicated capacity was major reason for
slow progress. An insight that was visible right away from the progress chart.
8.4.4 Summary of Current State Site C

In summary various differences could be pointed out in the value stream of site C.
A VSM was created. Major focus for the further analysis and the future state should
be the updating of status information. Since the process is already optically
cumbersome, deviating information flow is very likely. The effort of 6 hours per week
to update the status list shows that information does not flow easily in the process.
The country barrier between the headquarters in the USA and the offshore site in
Germany creates translation and time zone related waiting.
8.5 Current State - Cross Case Analysis

In this section the results of the individual cases of each site are summarized and
compared.
Table 8-3 gives an overview on the accumulated sources across the three different
sites that were visited during the case study research.
Site A Site B Site C
VSM 6h, one manager N/A 4,5h one manager,
Workshop 2h two test
engineers
Interviews 11 5 5
Meeting 9 - 4
Observation
Other General General General
Observations Observations Observations
Test Setup followed
Table 8-3, Summary of information sources across the three visited test sites
8.5.1 Customer Needs

In Table 8-4 one can review the identified main customer, the role of the final
customer and other customers identified. Note that in site B no VSM workshop was
held. Hence, no information is available.
Main Design N/A Design
Customer
Final Indirect for new products N/A Indirect for new products
Customer field issue investigation field issue investigation
Other Manufacturing N/A Manufacturing
Customers Product Management Product Management
Legal Department Other Testing Sites
Output Test/Installation/ N/A Test/Installation/Observations
Observations Reports Reports
Prototype Installations Prototype Installations
Schedule/Budget Plan Test know how
Table 8-4, Identified internal / external customers and the required outputs of the visited product
testing sites A and C.
The customers and required outputs identified during the VSM workshops are
comparable among the sites A and C. Nevertheless; the site manager of site A has
pointed out that test reports are in particular required by the legal department in case
of field problems or regulatory approvals. A view that is true for all sites. The test
engineers in Site C brought in the aspect of cross location test knowledge transfer,
hence, other testing sites as indirect customer of the activities. This is a mindset that
encourages organizational learning as part of the value stream. Standard test
procedures or installation best practices can be the material output of a knowledge
transfer. As additional output site A has put a test schedule and budget plan. This
point is also true for most testing sites but was not named by site C. Perhaps, due to
status of being just an offshore site of the product managing headquarters in the
United States.
8.5.2 Cross Case Analysis – Process Steps in Order

Table 8-5 lists the process steps identified at the different sites. The merged cells
show that there is no difference in the basic process steps. Even though, the steps
can be executed very differently in each site, which is expressed in the matrices of
each individual VSM.
The majority of process steps are comparable among the sites. Questionable are the
second review of test tasks at site A (Step 4: Table 8-5) and the local deviations in
site C. Moreover, the role of “Rebalancing Testing Plan”, which is supposed to be a
workload leveling step, is not clear. In the future state assessment the deviations will
be analyzed in terms of value and waste contribution to the overall process.
1 Approve Test Requirement
2 Write Test Task
3 Review Draft Test Task Review Draft Test Task
(only partial)
4 2. Review Test Task - -
5 Set Priorities Set Priorities
(Off Site in
headquarters, call
conference )
6 Rebalance Testing Unknown Not part of Local Value
Plan (Observed “Obaya”) Stream understanding
(Assumption: part of
priority setting from
headquarters)
7 Lab Task List with priorities and assignment to Lab Task List with
LTE priorities

7.5 High Priority Test Unknown
(Handling was not
observed during VSM
workshop)
8 - Unknown Local Lab Task List
(Contains local
required information)
9 Setup Test/Machine Setup Test/Machine
(In some cases part of
test setup since same
person)
10 Conduct Test
11 Process/Analysis of Test Data
12 Review of test results
13 Writing of Observation Writing of Observation
(Translation Required)
14 Create Test Report Create Test Report
(Translation Required)
15 Approve Test Report
Table 8-5, Value Stream Process Step Cross Case Overview
8.5.3 Process Matrices and Data Attributes

The highest insight about the process under analysis in the visited sites was based
on qualitative data, process issues that were mentioned directly by the process
owners or participants.
The possibility to acquire quantitative process matrices was reduced in all visited
sites. In the appendix (Table 12-4) one can view and compare the data gathered for
each site. A commented comparison of the matrices information across the sites is
given in Table 8-6.
The low available data makes a cross site comparison solely based on matrices
values unreliable. Especially reliable timing data is missing for the process steps; a
lack of data that has to be addressed in the future state in order to allow more
reliable.
The issue of insufficient data for PDVSM was also observed by other authors
(McManus 2005; Montoro-Lopez 2012). McManus (2005, p.100) found that “the hard
data proved key to understanding the problems of the value stream.”
The lack of hard data has to be addressed in the future state.
Selected
Process Site A Site B Site C
Matrices
Number of Large Team, In Large Team, In Smaller meeting
people process step 4, 5, 6 process step 4, 5, 6 team, due to low
involved participate all LTE, staff. The absence
Site Manager and People leave the of LTE requires TE
Administrative Staff room if their topic to be in meetings
has been discussed and reduces
People Wait for available TE
relevant Information capacity for testing.
Batch size or Batching for reviews, No data Batching for
Frequency priority setting reviews,
priority setting
Updating of status
Complete low for test task No data low for test task
and Accurate writing requiring writing requiring
(C&A) rework cycles rework cycles or
downstream
problems / delay
Inventory Medium in process No data High in process
work relative to relative to number
number of test of test engineers
engineers: IP/TE: 12/3=4
IP/TE: 32/12 = 2,6
Data In / Data Diverse Data No data Diverse Data
Out Handoffs Handoffs
Data don’t flow Data don’t flow
easily into next easily into next
process step process step
Available 1 new test / day 1.72 new tests / day 50 new test / year
Time/Demand Range: (0-17.5) Range: (0-25) 1 new test / week
Rate Range: unknown
Rework or High rework for No data No data
revisions review of Draft Test
Task
High rework
observed for
Observation Report
Table 8-6, Matrices of each site in comparison
This page is intentionally left blank.

9 Case Analysis – Future State and Implementation 107
9 Case Analysis – Future State and Implementation
9.1 Future State Development

In this section the development of a future state for the case company MWFL Product
Testing is presented. The future state is derived in a seven step approach as
discussed in section 7.1.2.
9.1.1 What does the customer really need?

The question referrers to the entry level of a test into the value stream of product
testing. The process steps identified during the VSM workshops are “Approve test
requirement”, “Write test task” and “Review Draft test task”. The “approval of test”
requirement was identified as a project statement about the technical and economic
necessity for a test. In the SIPOC analysis of site A and C, also the FMEA and
Program Plan were named as input.
Value:
The following value aspects of the process steps “Approve test requirement” and
“Write test task” were identified during the case study and listed in Table 9-1.
Value Aspect Detail
Value for Can be summarized by the design group and at best a chief
Final Customer engineer as various information sources get integrated in
upstream processes.
Risk Reduction Meeting the customer value with the intended design.
For the design A DFMEA and virtual prototyping was done. Residual risk has
to be reduced by test and testing.
Risk Reduction Structure of test and related activities:
For the test Parts, Machines, People Involved, locations involved.
These aspects have to be clarified in order to reduce the risk
of failure on delivering the test result.
Lessons Learned Have Lessons Learned been checked?
Is the information really new or is it a pure check?
Time/Cost If a simple test perhaps saves high sophisticated analysis,
Saving clears wrong assumption or validates a simulation model that
can be used for fast decision making later on.
A test can also deliver unexpected side effect which are
feedback in form of observation. These can give an early
customer like feedback, even if real customers can’t be
integrated for reasons like safety or disclosure of new content.
Table 9-1, Value aspect of the process steps “Approve test requirement” and “Write test task”
The test task draft review was also identified as major value contributor. In contrast to
the “Approve test requirement” and “Write test task” steps the review conveys a
technical expertise on testing that is one of the core competences of a product
testing group. Therefor the value contributors were listed in the separate Table 9-2.
Value Aspect Detail
Risk Reduction Reduce the risk that a test does not deliver the information
required by the customer. Technical aspects of conducting a
test are core competence of the leading test engineer. Often
the practical limitation of a system under test or simple but
valuable additional information gathering can be defined.
Time/Cost Wrong assumptions at the start of a test can cause waste of
Saving time and budget. The initial review and understanding of
needs is essential to avoid the waste.
Form of Output Output could flow directly into the downstream process and
final report if the information is stored in a way that allows
easy retrieval.
Table 9-2, Value aspect of the process step “Review Draft Test Task”
Waste:
One design engineer answered the question on how much time he spends on writing
a test task as:
“Writing a test task is not the problem. I can do it in half an hour. The problem
is when you receive the results and they have tested something totally
different from what you wanted”
The depicted situation is a clear waste of time and resources, spent on creating non-
required information. This waste could be avoided if the real information need would
be identified at the beginning of the product testing value stream.
Another design engineer showed how to enter a test into the test data based with the
comment: “and now I copy all this and send it by e-mail to the test lab”.
Answering the question “What does the customer really need?” has to be part of the
future state value stream.
Figure 9-1 summarizes wastes related to the first steps of the current product testing
value stream.
Figure 9-1, Part of current state VSM of site A with waste highlighted
From the interview with the design engineer in site A various sources of information
were identified in the phase of “Approve Test Requirements” and “Writing of Test
Task”. All these information have to be reduced into a single format of the TDB data
base. A close review of the TDB test task creation format by the author showed that
only prototype, location and project code are obligatory data and that the procedure,
purpose and acceptance criteria had to be entered into a plain text field.
Valuable information about the analyzed part or system, test type or relation to other
parts is not obligatory and therefore often not entered. In addition the drop down lists
from some menu items are found to be outdated or irrelevant. The same data base
information was analyzed as legacy data in section 8.1 with the results having low
explanatory power in terms of timing information.
A handoff waste is that design engineers have to forward their test task to a LTE or
testing site manager by e-mail in order to get a fast response to their test. Several
other possibilities of misunderstanding on the data entry side and on the review site
lead to high percentage of rework, requirement for second review step in site A and
perhaps faulty information in the downstream process of test setup, conduct or
reporting.
The different waste types identified during the case study research were collected in
Table 9-3.
Waste Detail
Transportation The effort to understand the customer need contains various
and Handoffs data handoffs. Information needs to be re-entered, searched
and Excessive and reduced in order to feed the TDB system. The possibility
processing of data loss is high.
Waiting The information entered into the TDB system needs to be
searched by the LTE or an administrative employee of the
testing department. It was observed and reported that the
tasks are waiting sometimes without notification.
Defect Information is not entered into the TDB system due to lack of
training and weak instruction about which data is required.
Also a lack of checklists for the entry and the review causes a
lack of information leading to downstream waste or even not
delivering the value of a test. The pile of rejected tests shows
that time was wasted on them.
Table 9-3, Waste aspect of the process step “Writing Test Task” and “Review Draft Test Task”
Flow:
In the current state the information is pushed into the testing value stream. Especially
because the test management software (TDB) does not show which information is
needed by the downstream value stream. A pull was only observed by individual
leading test engineers who used a checklist during a review meeting in order to pull
all required information from the design engineer.
Kaizen:
Immediate Kaizen activities were identified either from interviews or observations by

reviewing the structured notes. Table 9-4 lists these Kaizen ideas that were collected
regarding the process steps “Writing Test Task” and “Review Draft Test”.
Kaizen Detail
Single Data Integration of the data sources for program plan, CAD and
Source FEA view, FMEA data, Customer Field Data into a common
data base. This would require a complex PLM solution that
integrates into the product testing process.
Use of Checklists are needed for the approval of the test requirement
Checklists to identify long term structural boundaries, value contribution
and resource requirements.
For writing and reviewing of the actual test requirement,
checklists are needed to capture technical aspect of the
design under test and the technical requirements to perform
the test.
Guideline for the A meeting guideline should contain a checklist, notation of
test task review decision making points and time keeping. The guideline has to
meeting be available in every meeting room and in online work spaces.
Table 9-4, Kaizen Ideas collected for the process steps: “Writing TT” and “Review Draft TT”
This paragraph showed, following the framework for value, waste and possible
Kaizen identification, how the question: “What does the customer really need?” could
be answered in a future state. The other process steps of the current state VSM were
analyzed initially in the same way. In the following paragraph: 9.1.3 and 9.1.6 the
results are summarized.
9.1.2 How often will we check our performance to customer needs?

If a process follows a takt time as in manufacturing the performance check can be
conducted according to it. A sampling will be scheduled according the required
quality management measures.
In the current state of MWFL testing no takt time concept was identified. A weekly
meeting schedule provides a common pace of planning and reviews but does not
control the information output frequency. The current process requires a 100% check
of the output information. Each test report has to be commented by the requesting
design engineer. The design comments are required to close the TDB workflow of a
test. In theory the performance check with the customer is part of the process
closure. However, the information inventory in front of the approval step shows that
these comments are often outstanding.
Moving the design comment collection into the checklist of the result review would
reduce the time gap between receiving the results of a test and receiving a formal
report which needs to be commented a second time by the design engineer. In order
to check a performance the test task review has to provide a reference lead time and
expected information for each test that allows a comparison to final outcome.
Furthermore, is using VSM and its frequent update a good method to check the
actual performance of the value stream.
A takt time concept for product testing will be discussed in 9.1.5.
Kaizen Detail
Result review Add design comment collection to the checklist of the result
including design review. Also collect feedback for result presentation and other
comment points of possible improvement.
collection
Provide initial A target for time and information quality defined at the test
performance task review and verified at the delivery of the test results to the
target and design engineer during the result review. The relative
compare with difference between target and actual performance has to be
result constantly monitored with visibility to all process participants in
order to identify process problems or change of side
conditions.
VSM with Use the visual representation of the VSM to allow the site
periodic updates manager a constant view of their process performance,
bottlenecks and periodic overviews.
Table 9-5, Required Kaizen to enable constant performance to customer needs.
9.1.3 Which steps create value and which steps are waste?
One interesting comment from an interview with an operational planner at site A was
that although value stream mapping is a good tool in a production environment, one
could not just “identify value adding and waste activities” in product development. If
one would do that, “all administration is waste” the operational planner said.
This introductory statement shows the importance of a framework to assess the value
and waste in and between the individual process steps, which was done in section
4.2.2, in order to avoid the elimination of “administrative” process steps that have
information creating value or enable the flow of the process. In this section the results
of the value and waste assessment in the testing process are presented.
Equipped with two VSM workshops, 21 interviews, 13 meeting observations and

several other unstructured observations (view: Table 8-3, 102), 69 waste aspects and
31 value aspects were identified, during the case study research of the current state.
The value aspects of each process step were assessed according to the predefined
framework and ranked as low (1), medium (2) or high (3) by the author.
Likewise, waste factors were assessed and ranked in the three different aspects:
severity of the waste, occurrence of the waste and the avoidability of the waste.
Table 12-5 in the appendix shows the practical implementation for this case study.
The value and waste aspects of each process step were summarized by calculating
the average of each process. Figure 9-2 shows the reader which process steps
contain value and waste aspects and the average assessment according to the
previously described framework.
Waste Priority Index [1-3] Waste Severity [1-3] Value Aspects [1-3]
3 High
2 Medium
1 Low
Figure 9-2, Waste priority, severity and value of the process steps in the product testing value stream
The initial process steps of writing the test task and reviewing it (step 2 and 3) have
high value as well as the setup of test and machine, conduction the test and the
analysis. Waste reduction for these process steps, even if having a lower priority
index, will increase the overall value add of the process.
A more specific view on the individual waste aspects for each process step can be
gained from Figure 9-3 and Figure 9-4 showing the different process steps and the
kinds of waste- and value aspects identified.
Figure 9-3, Value aspects identified and their summarized assessment value
From the visual presentation of value aspects (Figure 9-3 ) one can see that the
steps: “Review Draft TT”, “Set Priority for test”, “Write Observation” and “Create Test
Report” combine several different value aspects. Whereas, the process steps “Setup
of test / machine”, “Review Test Setup” or “Conduct Test” have single value aspects.
This insight has to be part of Kaizen activities in order to avoid compromising a value
aspect by reducing waste.
Figure 9-4, Waste aspects identified, summarized in priority index PI

The visual presentation of the waste aspects of each process step shows that even if
some process steps contain high priority waste aspects, like “Setup Test/Machine” or
“Review TT”, they might also contain rather low priority waste aspects or even have
just few waste aspects identified.
As a summary of this section one could agree with the initially quoted operational
planner, that a simple value or waste statement for each process step is not the
reality in the investigated case. With exception of the step “Review TT”, which is a
second review and checking activity with low value and high priority waste, no
process step can be skipped or individually improved. The interrelation of the value
stream requires further analysis before deciding on a future state and required
Kaizen activities.
9.1.4 How can we flow work with fewer interruptions?

Several interruptions of flow have been identified in the current state of all three
testing sites of MWFL. The major waste aspects leading to interruptions of the flow
are: Inventory, Waiting and Transportation or Handoffs. Table 9-6 lists the identified
wastes of these groups sorted by priority index PI.
Process
Waste PI Detail Kaizen
Step
Waiting 4 18 People wait for Define Meeting
information during Agenda:
People Review meetings. Discuss only topics that
Wait for Test Task It was observed that require interaction with
Information during a test task the group: like
review meeting, 60% of resources or priority.
the LTE time was Let people leave the
waiting. Test tasks meeting when their
were presented but the topic has been
information was only discussed.
relevant for the Eliminate non required
individual LTE and the meetings that have just
Site Manager. checking character but
do not produce group
synergy.
Waiting 7 18 Unavailable Machines Visual Management of
or Test Equipment was Prototype and Material
People wait Setup an often named waiting Resources on the shop
for Material Test/ reason during test- and floor.
and Machine machine setup. Scheduling conflicts are
Prototype Although these visual can be solved
Machines resources are quickly.
considered in the 1. Stage: Paper and
priority setting, the level White Board Based
of detail and flexibility 2. Stage: Connection to
has often extended the data base and
capability of a planning scheduling system to
process. allow cross location
check.
Waiting/ 13 12 Report writing gets Make waiting visual by
Inventory often delayed since counting number and
Information Create results were delivered duration of open
wait for Test already. Information reports. Enable and
people Report gets lost due to waiting. reward work sharing.
Table 9-6, High priority waste aspects leading to workflow interruptions
Although a single piece non

interrupted flow driven by
customer pull would be
ideal the reality of product
testing requires a
decoupling point like the lab
task list (Figure 9-5).
Main reason are limited
resources like prototype
machines, test benches
Figure 9-5, Decoupling point Lab Task List in Product Testing
and test equipment but also
possible long lead items that need to be supplied before a test can start. These
aspects have to be clarified from a project perspective by the “Approve test
Requirement” and “Set Priority” and from a technical perspective by the “test task
writing” and the “review of the draft test task”. Only after this clarification, which can
be done for urgent tests within a single meeting the test is ready to be executed by
the operations of product testing. For the overall test plan of a new product
development test planning as discussed in 3.3.1 has to be done in order to identify
resource requirements, the number of required prototypes and correlations with the
product development process.
Changing priorities were found to be a major interruption factor of the operational

flow. The information from the interviews is supported by the finding from the legacy
data analysis which identified demand fluctuations of more than ten times the
average demand. Frequent changes arrive during the weekly meeting schedule,
which is a takt not related to customer demand but to the information demand of
higher management. Other sources of changing demand are urgent tests, upstream
work batching. This reality of demand fluctuation requires a realistic view and has to
be incorporated in the future state.
First step to handle demand fluctuation is to dedicate resource planning to it. If 50%
urgent tests are common, the operational capacity of the test site should only be 50%
saturated with long term planned project related work. That would reduce the waiting
and interruption of planned work. The remaining capacity should be kept flexible and
work should be pulled according to the demand priority.
Second step is to visualize all test activity in operation by attaching the test task to
the actual work station, like workshop, desk or meeting room. To keep an overview,
one central task board should show every activity that is in a queue, in process or
done. Urgent tasks should be indicated with a red folder and collected at the end of
the progress to visualize the progress on these items. The task board used in
chapter 8.4.3 was trial for this improvement idea.
The visualization would allow the operational team to support each other for example
during waiting time, in order to improve the team or group result, which is not the
case in the current state.
9.1.5 Workflow Control and Leveling of Workload

In section 9.1.1 the understanding of customer needs and requirements was
discussed. One major Kaizen for the understanding of customer needs is the use of
checklists. If these checklists are provided upstream in a product development
process they implement an information pull.
The thesis research showed that several design engineers are not aware about the
requirements the testing group has in order to organize the test work. A data entry
format of the TDB system captures some information but missed other relevant
information. The data entry format was also outdated and not intuitive to use. As a
result, the test task was pushed to the testing group in the current state. The
integration of a checklist and the resulting structured information about the required
test, allows any leading test engineer (LTE) of the testing group to pull new tasks
according to skills and availability.
The second stage of interruption is the priority setting and lab task list. The test tasks
are well defined in terms of project value for the company and technical requirement
to perform the test task. The priority team has to tradeoff capacity, resource
constraints and project priority in order to define a priority in the lab task list. A project
plan has to be the backbone of this priority assessment. Methods of test planning are
discussed in the literature and were summarized in chapter 3.3.1.
The thesis was limited to the flow within product testing, which excludes the overall
project plan. Nevertheless, a clear point of integration with the general product
development process was identified.
Figure 9-6 shows the basic workflow control and leveling concept discussed in this
paragraph. From the decoupling point Lab Task List the LTE has to withdraw tests
according to their priority and posts them on the task board. The standard process
steps of Setup Test / Machine, Conduct Test, Process and Analyze Data, Review
Test Results, Create the Report and Approval have to be defined at the task board.
The executing staff has to estimate and commit to the process time of each step. If
required the task board allows specifying sub tasks in order to distribute work
packages among the team of test engineers (TE). Often the sub-tasks can be directly
taken from standard test procedures or work instructions. If these are not available
the output of the task board documentation can directly flow into a new work
instruction, for example by taking a picture of the task board.
Depending on the available work capacity in a period or takt, tasks can be pulled
from the lab task list until the capacity is saturated. In the investigated case 50% of
the capacity should be saturated in this way, allowing further 50% to be handled as
urgent tasks. The urgent tasks have to be visually outstanding, for example by using
red paper in order to show the team the urgency of the item. During the working
period tasks can be dragged by the test engineers according to their availability. A
limitation of space on the task board shows quickly if certain engineers are
overloaded or are working in parallel on several tasks.
Program Control
Technical Prereview
Lab Task List Takt End:

Check Performance
Takt start:
Check out
To Do Setup & Conduct Data Review & Done
Setup
Review Test Analysis Report Customer: Design
Urgent Item: Instrument
Setup Pass
Problem Solving
process
Not related to X
Instrument
takt X
Supply:
Test
Equipment &
Material
Daily Update: Stand up meeting

Test
Equipment
Supply:
Production Execution, Team 1
Machines &
Parts for Test Execution, Team 2
Machines
on Yard Execution, Team 3
FIFO Reporting
Supply: Reporting
Experimental
Shop & Reporting
Supply
Parts
in Stock
TAKT TIME 1-4 weeks
Figure 9-6, Product testing operational value stream using takt time and task board
Vision for workload across the team is expected to enable peer support, as common
benefit in cell manufacturing. As progress visualization a progress chart has proven
to be a simple but effective tool. The update should be given once a day in a very
short standup meeting. At the end of the period the output should be compared with
the expectations, the results reviewed and the next period scheduled. If possible all
team participants and stakeholder should participate at the start and review of each
period. They should be able to follow the progress be visiting the task board.
However, the different location of the process steps, participants and stakeholders
makes an online collaboration much more desirable. The visual collaborative element
of a task board should not get lost; hence, big screens and visualization have to be a
focus when selecting solutions.
After some trials with the management takt time of one week one should also try to
work with extended takt times for the lab operations. Two weeks takt time for the lab
operations and a shift between two teams in the lab would still provide weekly
updates to the management, but would reduce the effort to plan and review the takt
periods for the test execution team.
To handle long duration tasks with lead time longer as the takt time sub-tasks need to
be defined that fit within the takt time. Again trails with different takt times should be
made to trade off takt planning effort with the benefit of flexibility.
The concept of a takt time as discussed should not be confused with the purely
demand driven takt time of a manufacturing process.
A true statement that summarizes the discussion in this chapter could be:
“Applying the concept of takt time to PD processes requires some creativity.”

(McManus 2005, p.62)
9.1.6 Summary of the Future State and Required Kaizen Activities

In previous sections a future state value stream was elaborated. A seven step
analysis process was used to identify the required changes. Waste, value and ability
to improve the situation with Kaizen activities were considered in prioritization
framework. The results of the analysis are presented in this section. The future state
map (Figure 9-7) and the prioritized list of required Kaizen actives (Table 9-7and
Table 9-8) summarize the results.
The future state value stream decouples the test planning and execution with a
central Lab Task List and Task board.
In the planning area upstream program related work is integrated and provides a
priority of test activities. A technical pre-review is essential to integrate specific test
requirements of the design engineer with the possibilities of testing. The Technical
Pre-Review follows a checklist and meeting guideline in order to cover all information
needs that allow a long term resource and supply planning of the test execution.
Program Control and Technical Pre-Review allow a planning and prioritization of test
tasks. The outcome is a rough scheduled task list with prioritization from which the
operational part of the testing value stream can withdraw tasks. Long lead supplies
are ordered and tracked based on the Lab Task List.
To execute a test, tasks are withdrawn from the Lab Task List according to their
priority and status of supplies at the beginning of a takt period. Initial takt period will
be one week to deliver reports in the frequency as desired by the internal customer.
The lab team defines sub-tasks required to finish the test job and estimates their
process time. The team also withdraw tasks from the Lab Task List until their current
capacity is saturated by 50% the remaining 50% are kept to cover high priority
demand peaks. During the takt period daily reviews are held in a simplistic way to
allow all participants an overview on the current status and the target for the end of
the takt. The daily updated can be used easily as status report for the management.
At the end of each takt period the results are compared with the initial goal. The
documented work steps can be reused as work instruction for upcoming activities.
The responsible design engineers can follow their test activities, interact during the
daily review in order to steer the result achievement. The results are reviewed with a
draft report, design comments have to be collected to allow a closure of the report.
Argumentation why
Process Step PI Kaizen
selected
Review of Test 18 1. Ensure quality of first The second test task
Task review by using review was identified as
checklists. Use Meeting low value high waste
guideline to structure activity and should be
the discussion. deleted. However, prior the
2. Reduce rework by C&A of initial review has to
providing checklist to be increased.
the design engineer. The combination of test
Pull the needed task writing and review is
technical and project an essential step to
relevant information. understand the customer
3. Remove second need and has, therefore,
review. high priority.
Setup 18 Visual Management of Unavailable Machines or
Test/Machine Prototype and Material Test Equipment was an
Resources on the shop often named waiting
floor.
reason during test- and
Use of task board and machine setup.
daily fast updates to allow In current situation visibility
peer support. Visualize of peer work is not given.
progress. Flexibility is required by
demand fluctuation.
Compare performance Lab operations are main
with targets.
driver of lead time.
Setup 18 Include Design Engineer Errors or deviation from
Test/Machine or for review. Colocation is original test intention were
Review Test Setup preferable to ensure identified a sever defect in
testing as design intend.
the test setup. Colocation
in a big room or Obaya
was practiced successfully
at site B.
All process steps 12 Single source of data. All From various checklists,
project and technical upstream process, priority
workflow relevant data decisions and test
needs to be collected operations data needs to
together with the test task. be tracked in a single data
source which allows
integration with PLM
system and flow between
process steps.
Setup 12 5 S for test software and Waste Analysis showed
Test/Machine information flow that in this process step
waiting and excessive
12 5 S for Job Shop processing have high
priority index
Table 9-7, List of required Kaizen activities for the future state of MWFL testing process, part 1
1xChecklist
Technical Pre-Review per test type Program Control
Set Priority of TT Test
Review Draft TT Write Test Task (TT) Frontloading
Priority Program
TPM, Ch. Eng., PT Site Mngt TPM
LTE, D. Eng, TE if needed D. Eng Point of view
I P/T [h] 0.6
P/T [h] 0.5-2 P/T [h] 0.5-2 L/T [d] 1-7
L/T [d] 1-7 L/T [d] 1-7 C&A [%] medium
C&A [%] medium C&A [%] medium Program Mngt
Batch 3-10; 1/week PT Site Mngt
Batch 1; 1/week Batch 1
add L/ Ch. Eng
Program Plan, Lab List, Project
TDB, E-Mail, T TDB, E-Mail
TDB, Lab List CAD, FEA, Lab List Plan, Rough
Lab List
Office, FMEA, Resource Plan
field issues Monitor the Inbox 9.0
5.0 1.0
General Meeting Guideline:
agenda, preparation and
required decisions
Lab Task List
Work Packages, Prioritized,
Simple Capture of
Best Practice, is
part of task board
Standard test
From Legacy Data
All Supply: (old DVP’s)
Single Contact Task Board Customer: Design
Task Board
Work Packages, Detailed Problem Solving
Max. 2 proj./ Pass
Supply: process
D. Eng person
Test
Equipment & Master: TE/LTE Content: Small Tasks, P/T, Resource, Documents
Material
Tech Assist Done by: TE, Workshop Leader, Standup in Workplace
P/T: 15min, L/T:30min, Batch: 1/d
9 Case Analysis – Future State and Implementation
Setup Test
TE, Tech Assist
P/T [h] 1-80 Min 1 x day

L/T [d] 1-30 refresh
All Shipping: C&A [%] medium
also used
Conduct Test Process/Analysis of Review Test Results for legal aspect and
Single Contact Batch
Test Test data TDB Search of old tests,
TDB, Drawings,
Equipment Frequency of use
Guidelines, TE, Tech Assist TE@ 50%, LTE LTE, D. Eng, TPM
Pictures, unknown
Supply: Verbal Sub P/T [h] 1-40
Notes, P/T [h] 1-80 P/T [h] 0.5-2
Tasks, Test L/T [d] 1-14 I
Production L/T [d] 1-30 L/T [d] 1-7
Software/ C&A [%] high
C&A [%] high FIFO FIFO C&A [%] medium Create Test Report Approve Test report
Machines & Hardware
Batch Batch Batch
1.5
Parts for Test Plots, Plots, Pictures,
Pull the setup Raw Data Test Raw Data Test TE, LTE @ 50% PT Siter Manager
Machines Pictures, PPT/ E-Mail PPT/Word/
Software, TDB, Procedure Software,
on Yard by the test. Word/Excel, Comments Excel, E-Mail, P/T [h] 1-7
Setup Test Machine Pictures, Notes Documents Pictures, Notes
E-Mail Verbal L/T [d] 1-14
C&A [%] medium P/T [h] 0.2
1.5 1.5 3.0
Batch 1-5 L/T [d] 1-7
Tech Assist Plots, Pictures, C&A [%] high
PPT/Word/ Word/Excel, PDF, Batch
Figure 9-7, Future state value stream map for MWFL product testing operations
Excel, E-Mail, TDB, E-Mail
P/T [h] 1-80 Checklist, Write Observation Verbal TDB TDB, E-Mail
Supply: L/T [d] 1-30 Mobile, Set Down Test
Experimental C&A [%] medium TE, LTE @ 50%
Simple 1.5 1.0
Parts Batch P/T [h] 0.2 Tech Assist
Shop & Supply in Stock L/T [d] 0.5
TDB Reports, C&A [%] high P/T [h] 1-8
TDB, Drawings, Batch L/T [d] 1-2  Technical
Pictures add L/T
C&A [%] high
Batch Translation Service
1.5 Set down Test Off
TDB TDB, E-Mail  Peer Review
the critical path, TDB TDB, E-Mail
1.0
but included
1.5
TAKT TIME
5S - All Comments: VSM PT File:VSM_1_ALLState_Neutral_

MWFL
Commissioning Start: Right Up, End: Right Bottom, Matrices Data from X meeting observation, Value “0”=no data, Date: May 2013 1_2.vsd Forest Harves ter
Testing
123
as close as possible
Status: Future State Author: Daniel Walew
to the test
Argumentation why
Process Step PI Kaizen
selected
Write Observation 12 Checklist for Observation A high rework rate was
writing that includes all identified during the
required information and current state observations
explanations how to fill in. and in interviews. The
Checklist adapted to user: current system was
Engineer, Technician, reviewed.
Customer… The value of the activity is
Simple Integration of high and the waste from
picture, sketch, file links defect information is
Bring close to workplace, severe.
possible mobile.
Review Test 12 Use Checklist. Outstanding design
Results Design Comments part of comments were found
test result review. major reason for waiting in
Collect the comments on the report approval step.
results during the meeting. To avoid this they should
Decision on follow-up be clarified during or
activities or closure. shortly after the review of
results.
Create Test Report 12 Track the time and volume High number or
of test tasks that have outstanding reports were
open review. found and reported in the
In the current state with current state.
status tracking in the lab The decreasing value of
task list and in the future information over time due
with the task board. to the lack of a formal
report, or “forgetting the
information”, was named
by one test site manager.
Set Down Test 12 Step triggered by review Process Step was not
and approval of results. documented in the Current
Take the set down off the State but existent. Often
critical path. not tracked.
Tools/Equipment in order Waiting for material and
and ready for next test. defects due to non-
checked equipment were
reported as delay creating
in test and machine setup.
All process steps 12 VSM data connected to During the current state
data sources. analysis most matrices
Time, queue other VSM had been estimated by
matrices should be interviewees. The legacy
periodically updated from data analysis showed that
real data. a lack of reliable data.
Table 9-8, List of required Kaizen activities for the future state of MWFL testing process, part 2,
48 waste aspect were sorted out due to a priority index less than 12 as assessed in 9.1.3.
Improvement Quantification - Time Reduction:
The Review TT step was identified as only directly avoidable item from the current
state and is therefore considered in Table 9-9.
Process Step Matrices Unit Min Max Batch Min/TT Max/TT
Review TT L/T d 0,5 7 3-10 0,05 2,3
P/T h 0,4 1 3-10 0,04 0,33
Write/Review TT Rework L/T d 0 3 1 0 3
Write Observation Rework L/T d 0 2 1 0 2
Total P/T h 0,04 0,33
L/T d 0,05 7,3
1
Table 9-9, Direct time reduction from process improvement
P/T: 2 to 20 min reduction per test task; 0,1-0,5% of total P/T.

L/T: 0,05 to 7,3 days reduction per test task; 0,3-5,5% of total L/T.
From the Review TT step time saving with 9 people being part of the step 3,6 to
9 man-hours would be saved per week. People could avoid to whole meeting.
The quantifiable savings in time and resources are relatively low. Due to the lack of
data for the matrices of the current state value stream the improvements are mostly
of qualitative nature. Further quantification has to be addressed by individual Kaizen.
- Increased output quality because test requirement are verified using checklists.
The real requirement of the internal customer is derived in structured way.
- Less waiting, rework execution phase due to clear input data.
- Less waiting of downstream activities due to clear observation data. The
downstream problem solving process is usually on the critical path of a program.
- Visibility across test execution encourages learning and capacity balancing.
- Less rework due to structured set down of test as part of a value stream.
Connecting the VSM with the lab task list is one major Kaizen. In a revision of the
value stream improvements this data can be used to quantify changes and their
impact. Nevertheless, provides the VSM as output an overview on the current
process and the required improvement areas. The improvement quantification has to
be addressed by the individual Kaizen documentation.
1
The minimum time per test task (Min/TT) is derived by assuming the case:
- High batch number combined with low lead- or process time
The maximum time per test task (Max/TT) is derived by assuming the case:
- Low batch number combined with high lead- or process time
9.2 Implementation of Future State

In this section an implementation plan is presented for two Kaizen activities that are
required to achieve the future state. A simple project structure was derived and the
findings were summarized in A3 reports. To document all required Kaizen activities to
achieve the future state would extend the scope of this thesis.
With his broad experience in the application of VSM, McManus gave an important
advice for the implementation plan in the MWFL case:
“It is an irony that the word “Kaizen” is used in the US in a sense almost opposite to
its Japanese meaning. Improvements are concentrated in rapid, work-interrupting
events, with relatively weak follow-up. In most US work cultures, however, it is more
effective to get people’s attention with concentrated events than to hope they will fit
continuous improvements into their busy day-to-day schedules.”
(McManus 2005, p.83)
Furthermore McManus recommends to schedule multiple Kaizen activities for the
same process. Follow up and coordination have to be organized by a single owner,
the value stream manager.
9.2.1 Review of Test Task, Understanding of Information Needs

Locher (2008) states that, typically initial focus of future state achievement is put on
defect waste. Especially in the first stage of the development process in which the
customer needs have to be identified, simple measures like checklists have high
impact (Locher 2008). This strategy is also applicable in the presented case.
The future state analysis (Table 9-8, Page. 124) delivered already the most important
Kaizen activities in this process area:
1. Ensure quality of first review by using checklists. Use Meeting guideline to
structure the discussion.
2. Reduce rework by providing checklist to the design engineer. Pull the needed
technical and project relevant information.
3. Remove second review.
From these basic steps a work break down structure was derived with stages of
multiple Kaizen activities. Figure 9-8 contains a short Gantt view on the improvement
schedule.
Apr 2013 May 2013 Jun 2013 Jul 2013

ID Task Name Duration
31/3 7/4 14/4 21/4 28/4 5/5 12/5 19/5 26/5 2/6 9/6 16/6 23/6 30/6 7/7 14/7 21/7
1 Initial Framework Interview 5d

Kaizen Event Site Manager, Design
2 0d
Manager
Follow Up of Kaizen, Model Checklist,
3 10d
Implement Checklist, Instruction
Trial Phase with 5 local LTE and Design
4 20d
Engineers, Cross Location/Cross Function
5 1 Stage: Quick Kaizen, Role Out to all 0d
Verify C&D value of Test Task Review
6 20d
During second review
7 Remove Second Review 0d
8 Prototype of Online Checklist 5d
Figure 9-8, Improvement and Kaizen schedule for test task review
As part of this thesis two work packages were already performed. At first the
conduced interviews were reviewed to find references for requirements of a checklist
in the test task definition, writing and reviewing phase. As reference was counted:
- direct requirement formulation by the interviewee
- missing information in a downstream process which could have been easily
tracked in the early phase
- information that is required to take priority decisions, like structure and
interrelations or resource requirements
To structure the information a fishbone diagram was selected since it allows in a fast
visual way to separate main groups and subsets of information. Other visualizations
would also be applicable.
Countries Involved
Systems Involved Locations Involved Design
REPRESENTATIVENESS
Functions Involved
Parts Involved People Involved
Possibility for Mock-up/Subsystem Test

Simple Data Check
IF: P/T:Less<8h?
Complexity
Standard Test
Info required from procedure Standard
Report Required?
Number of Channels
(Groups: 1,8,12,16,32,64) Acceptance Criteria
Knowledge About Test
Number of Tests
Priority
Step by Step description
Test Benches/Fixtures
Reduction of Risk
Output relevance for
People/Experts Final Customer
Equipment & Material
Checked after last test Time/Cost Saving
Calibrated
Plug&Play Lessons Learned/
Accuracy Learning
Sampling Rate
Machines/Prototypes
Test Supply Side
Form of Output
CNH Tools
Enabling Activities
DBC Files Prevent Waste
Figure 9-9, Information areas required for test task definition and review checklist derived from case
research, data source summary Appendix:12.5.
In total 14 interviews provided information relevant for the checklist definition. Some
points were stated various times time by interviewees, whereas others were stated
only by single interviewees.
To enlarge the data foundation to legacy project planning reports, one Kaizen
documentation and a user instruction for the data entry in the TDB system were
added to the analysis. The result is a framework should be used for the preparation
of the first Kaizen event.
Beyond the general advantage of using checklists in product development as tool to

reduce rework and to facilitate cross-project knowledge transfer (Locher 2008;
Oppenheim 2004) integration into centralized knowledge-management database can
support cross location and functional learning (Morgan & Liker 2006). Although a
detailed integration plan for the existing TDB system or even a PLM-System is
beyond the scope of this thesis, a prototype of an online checklist was elaborated.
Target was to have a low barrier to enter, retrieve and update the checklist and the
data that are collected with it. Moreover, the digital checklist can control required data
input very efficiently. As described for the Toyota case (Morgan & Liker 2006) the
functional organization should maintain ownership of their part of a centralized
knowledge data base in order to update and maintain the information. Central
processes that require cross functional coordination, however, have to remain fixed.
A rough comparison of IT solutions available at MWFL was made based on
interviews with two operational planners and two planning managers. The results are
summarized in Figure 9-10.
Figure 9-10, Results of rough comparison of IT tools available at MWFL, Target: find a system that
allows an implementation of shared checklists.
The discussed requirements for a prototype of a centralized online checklist were

best fulfilled by Microsoft Share Point 2010 (following: Share Point). Main benefit is
the relatively low entry barrier, the multi user handling, the possibility of data reuse in
downstream processes and the ability to share across functional groups. The
limitation in growth can be compensated by relative simple integration into more
powerful PLM solutions. The Share Point environment is already in use for various
data exchange at MWFL and allows flexible adaption. Also the lab task list was
currently implemented in a Share Point list.
The required checkpoint fields, as identified in the previous case study review, were
implemented into a share point list. For each field possible selection options were
defined using drop down or check box data entry. As in the data entry format of the
TDB system text fields were integrated to allow the user free commenting including
the possibility of formatting and picture integration. Each data entry can be defined as
obligatory or voluntary. A function that has to be selected carefully considering the
lack of information from the legacy data as discussed in section 8.1. A connection to
the lab task list was established by using look up variables, which allows data
integration. To use the checklist like a paper based version, Share Point offers data
entry formats, which were slightly customized using Share Point Designer and HTML
formatting. As a result, the user can create or edit a checklist for a new test via her
internet browser. Please refer to appendix 12.4 to view an example of the checklist
implemented in Share Point.
Results and Advantage of the online checklist:

- fast and simple to use check list, rich data can be integrated using drop down and
other selection formation
- integration with other data on the share point of the functional group
- individual or mass editing possible, several views can be created on the same
data according to the needs of the user group
- simple user administration providing: view, used and editing rights
- information filter for each process step possible to view only relevant information
and to filter critical or open items that need discussion during meetings
- fast collaboration through integration into MS Outlook and other office programs
- mobile application possible for use in the workshop or field environment
Follow up:
The data fields selected for the checklist require a revision of responsible process
owners. There for a Kaizen activity was integrated into the implementation plan.
Based on the results of the Kaizen event changes and adaptation have to be
implemented into the checklist. Checklists for different user groups have to be
defined to avoid overloaded data collection steps.
The usability of the checklists have to be evaluated during a trial phase, the process
of improvement and version control has to be established during this phase.
A short Kaizen has to be scheduled to implement the checklist use among all
responsible process participants and sites. A short training on use, benefits and the
ability to reuse the data in downstream processes has to be presented.
The results of the checklist use have to be tracked by measuring the rework cycles
between the first and the second test task review. If the quality of output from the first
review is sufficient the second review can be removed. The impact on data reuse at
downstream processes is harder to measure and would perhaps require conducting
follow up interviews with process owners.
Observation Writing – Improve Quality and Time
Similar to the discussed checklist further checklist can be developed. As part of this
thesis the method was also applied for the “observation writing” process step. The
information gathered during the case study research and the high priority of the
Kaizen provided applicable improvement measures.
Output of the effort was:

- A visual presentation of the required information the checklist has to collect,
derived from a review of interview and internal work instructions.
- A summary of the current situation and the impact on the downstream problem
solving process. Together with cause and countermeasure analysis.
- A prototype implementation in Share Point, which was tested and improved after
the review of two test engineers, who represent the later user of the tool.
- The improvement plan was documented in an A3 visual report (see 12.6)
9.2.2 Setup Test and Machine – Implementation of Visual Management

The current state analysis has shown that unavailable machines and test equipment
are a common cause of waiting during the test- and machine setup. Even though test
activities are long term scheduled and weekly priority setting- and test rebalance
meetings should discuss the use of all resources, waiting waste occurs due to
various reasons. Furthermore, workload leveling across the lab employees is hard to
accomplish due to the lack of vision across different lab activities and because each
employee has individual schedules assigned by the LTE.
As part of the future state analysis a visual management system for the test
execution phase was elaborated. The handling of test tasks, test equipment and
machines needs to be controlled in a visual manner on the shop floor. Daily fast
update meetings encourage cross team communication and allow handling of
workload peaks as well as urgent issues. Moreover, the task board provides simple
progress visualization, which is especially important for information processing tasks.
To implement the visual management of lab activities a three phase approached was
selected.
The first phase implements the task board as paper- or whiteboard based solution
with one team at one testing site, similar to the approach taken in chapter
8.4.3 Following a Test Setup. Through trials the layout has to be adapted to the
needs of the team, the use of machine and test equipment resources has to be
depicted. By utilizing Kaizen events, the task board has to be implemented at further
test sites and adapted according to the team feedback.
In the second phase, the effort of transferring tasks items from the task list to the task
board has to be streamlined. The management of machines and test equipment, as
well as the connection to other relevant information like specification, drawings or
instructions has to be addressed. To allow fast adaptation and simple integration of
different data sources a prototype was implemented in Share Point. Again, local
Kaizen events are required to collect user feedback and capture a solution that works
in the daily routine of a test site.
In the third phase, integration into the TDB or even a PLM system should be planned.
The scope derived from phase one and two has to be implemented, perhaps through
add-on solutions. Further leverage can be expected through the use of a single data
source, integration of long term project planning and other PLM advantages.
To check the impact of the improvement, process- and lead time has to be measured
throughout the implementation. Furthermore, incidents in which waiting is caused by
incorrect planning of machines, parts or test equipment should be counted. A
constant tracking of user feedback completes the improvement validation.
Figure 9-11 summarizes the implementation of visual management for test- and
machine setup in an A3 report. The improvement quantification is, as discussed
before, difficult due to the lack of quantitative data on the current state. Through the
implementation of task board driven visual management, however, time spend and
waiting waste become more apparent quantitative information.
MWFL Dept: PT
Forest Harvester KAIZEN
Testing Machine/line:
PDCA (Plan-Do-Check-Act)
Area: Test Lab, Test Setup Doc. Nr.
Theme: Test and Machine Setup, Visual Management Cost Center:
Lab Task List Current State: 1. Implementation:

Verbal - Visibility of peer work - Paper/White Board Based
across the lab is not given Task Board for one Team
Individual
Individual - Number of fields Layout
Individual
Schedule
Schedule - Unavailable test
Schedule Verbal - How to integrate machines,
LTE machines and equipment equipment visualization?
are comment cause of - Use different takt time
Wait for Machine/ waiting (although project - How to implement urgent
Equipment
Print Out
scheduling with resource tasks & observation writing
consideration is done) - local Kaizen events
Task - Supporting a co-worker 2. Connection to task list:
Task No Cross
Task Vision is hard because - Transfer task items from
in Lab
schedules are individual task list to task board
No workload
leveling
- Implement additional
information (like setup
instruction, spec sheets,
Lab Task List Takt End:
Check Performance Future State: drawings,...)
- Visual Management of: - Implementation in
Tasks, Machines and SharePoint
To Do Setup & Conduct Data Review & Done
Setup
Instrument
Review
Setup
Test Analysis Report Equipment on the shop 3. Integration into Test Data
X
Instrument
X
floor Base or PLM system
- Use task board to - According to required scope
visualize - Possibility to integrate Task
Daily Update: Stand up meeting
- Daily fast updates board, Long Term Project
Execution, Team 1 - Visualization of progress Schedules, Resource
Execution, Team 2
Management
Execution, Team 3
FIFO Reporting and urgent tasks
Reporting - Agile software development
Reporting - Cross vision on tasks
tools are available, Integration
and resources
TAKT TIME 1-4 weeks
Standardization
- Measure Lead Time, Process Time of test activities
- Count incidents in which machine, part, equipment miscoordination was causing waiting
1. Connect SharePoint to TDB system (Manual/Automatic) - Collect feedback
2. Make SharePoint tool for Observation entry, and fast forward of "Alter"
function
3. Implement into TDB or Even PLM Tool
Resp. Date of
Originator of the improvement. Date: Costs (€) Benefits (€) Results (€ ) Cost/Benefit Verification
Implementation implementation
Daniel Walew 08 Mai 2013
Figure 9-11, A3 report of the implementation of visual management for test and machine setup
10 Reflections and Main Contribution of Research Achievements 133
10 Reflections and Main Contribution of Research Achievements

The presented case study analysis gives a rich insight into the testing part of a new
product development process. It is specific for the case company MWFL but parallels
to similar long life cycle, low volume, complex product development processes can
be expected.
In the following section the research achievements of this thesis are presented. The
research questions are answered and discussed. Furthermore, the contributions of
the work and the limitation of application are summarized leading to suggestions for
further research.
10.1 Answering the Research Questions

The research questions were stated in the introduction chapter 1.2 and laid the
foundation of the research in the presented thesis. Hence, the research questions
gave the direction to select appropriate literature, provide assessment methods and
to open a solution space for the case analysis. After thorough literature research the
research questions were further specified in chapter 5.
10.1.1 Processes Assessment

The first research question was defined in order specify the requirement for the
literature research and to provide a priori theoretical construct for the case study
research:
How can the internal process of testing as part of new product development be
Value stream mapping was found to be an effective method to assess the internal
process in product development testing. Specific adaptations were required to apply
the method. According to the global director of product development testing at the
case company, the findings were significant, new and enable structured improvement
efforts.
Discussion of research question 1:
The literature research showed that testing is an essential step in product

development of manufacturing companies. Through a review of Lean management
literature the importance of testing was also underlined but the documentation was
found to be mainly focused on manufacturing or design based product development.
Value stream mapping (VSM) was found to be a well-developed method to assess

and improve internal processes in manufacturing and a tool of increasing importance
in product development. The application on product development testing, which
incorporates manufacturing specific and product development specific
characteristics, was rarely documented. Through a synthesis of the literature findings
from product development testing, Lean management and case based research, the
VSM method was adapted to work as priori construct of the case research.
In contrast to general requirement to conduct VSM as a team effort (Locher 2008;
McManus 2005; Rother & Shook 1999; Schulte et al. 2005) the presented work was
elaborated solely by the author within five month master thesis project. In total only
12 hours were spent in VSM workshops, due to the lack of time dedicated to the VSM
by the local site teams. This is clear disadvantage for creating a shift of mindset
towards Lean thinking across the different process participants.
Nevertheless, provided the VSM method a very useful framework to research the
current-state through interviews and observations, understand problems and
prioritizes improvement efforts. The effort required for that can be easily combined
with general management tasks. This is a useful insight about VSM in scenarios
where high level management support is not available or requires initial result
estimation in order to invest into a broad application.
10.1.2 Application of Lean Principles in Product Testing

The second research question was:
To which extend are Lean principles able to improve the performance of a

testing process?
Lean principles can be applied to product testing process, quantifiable results

however, require implementation and documentation. Various Lean principles from a
product development perspective but also from a manufacturing perspective can be
applied in product development testing. Considering the hybrid environment of
testing with job shop similarities in the laboratory environment and the major output of
information requires adaptation of Lean methods.
Throughout the case study analysis Lean methods were applied. Major framework
was value stream mapping but the current state, future state and implementation
planning utilized commonly known Lean methods.
The quantification of the VSM future state showed a maximum of 7,5 day or 5,5%
lead time reduction and less than 1% process time reduction. Results which
underachieve the expectations. The low level of quantifiable performance data in the
current state combined with the qualitative nature of various Kaizen proposals show
that further quantifiable improvements can be expected during the implementation of
the future state.
Schulte et al. (2005) documented 5 day or 16% lead time reduction from VSM future
state analysis lasting 3 months. Their major reduction was related to the early
coordination with the product development team, an outcome comparable with the
finding in the presented thesis. Within nine months of broad implementation Schulte
et al. (2005) reported 23% operational cost reduction. In their case actual cost
reductions were derived within individual Kaizen activities by local implementation
coordinators the “Lean Site Leads”.
With just few comparable cases the literature research did not provide evidence for a
generalized answer of the second research question. For the individual case
however, the application of Lean principles in product development testing was
beneficial and future benefits are likely to arise.
10.1.3 Continuous Improvement

Following the fifth Lean principle: striving for perfection the third research question
was formulated as:
How can the process improvement be part of a continuous improvement

effort?
The continuous improvement effort requires management support and dedicated

staff. Combined with a well-defined tool set and possibilities for adaptation a
continuous improvement could be achieved. The sole results from this thesis were
not able to encourage a continuous improvement cycle among the teams that were
visited at the three test sites.
Continuous improvement characterizes the endless process of time, space, cost and
mistake reduction. A previous understanding of value, value stream, flow and pull has
to be established before a policy change can encourage continuous improvement
(Womack & Jones 1996).
The case study work showed that individual VSM analysis and result presentation to
the process owners did not encourage continuous improvement. At site C process
owners and local management didn’t think that a VSM future state is an easily
understandable tool for a broad audience.
True implementation of Lean thinking in order to enable continuous improvement
requires significant training, group events and dedicated staff. Schulte et al. required
eleven workshops, local “Lean Site Leads” and a central Lean management for
coordination. Locher (2008) required a three day workshop for each team and
centralized value stream management. Also other major Lean sources require a
broad team and management support for the implementation of Lean management
(McManus 2005; Rother & Shook 1999).
Hoppmann found no clear evidence for the concept of internal change agents as
drivers of continuous improvement and interpreted: “the challenge of implementing
Lean PD requires the commitment of all employees. A distinct internal change agent
may be seen as an external force, increasing skepticism among the employees
and managers and hindering a bottom-up implementation of the components.”
(Hoppmann 2009, p.121)
The laboratory management at Vesteon has tackled the challenge by naming
dedicated “Lean Site Leads” as change agents but also encouraging open
communication, “town hall” forums and smaller focus groups. In result, 54%
workforce involvement in Lean effort was achieved (Schulte et al. 2005).
These considerations of change management are also required by MWFL in order to

achieve continuous improvement.
10.1.4 Application of Value Stream Mapping in Product Testing

The fourth research question was formulated based on the initial literature research.
Contradictory statements were found about the applicability of value stream mapping
in product development. The specific application on product testing was only found in
few sources. So the research should clarify the question:
Is value stream mapping (VSM) an effective tool to conduct case study

research in product testing environment of a global operating manufacturing
company?
VSM was an effective tool conduct the case study research by an individual
researcher. It provided a structured way of following a solution orientated research in
an unconventional environment. Across all visited sites differences in physical layout,
products under test, people involved or test types could be stripped away and
common processes could be identified.
The identified improvements are related to information- as well as material handling.
Furthermore the improvements were not trivial, new and executable. The product
development VSM method prove to be useful applicable in the testing environment,
especially due to the hybrid character of product development testing between
development engineering and physical lab environment.
Discussion of Research Question 4:
The VSM gave a structure to select interview partners, formulate questions, assort
observations and follow a structured case study research process in a not simple
accessible expert organization.
Similar findings were reported at Visteon where “value stream mapping was effective
as a tool to strip away differences between labs and make plain that all labs shared
the same basic procedural skeleton” (Schulte et al. 2005, p.6). Furthermore Schulte
et al. stated that local complexities and cultures were overcome through the use of
VSM in product testing.
Hoppmann (2009) however, found the effort to create a VSM to be of low impact on
the implementation of a Lean product development (Hoppmann 2009, p.122). The
survey based quantitative result Hoppmann elaborated remains of heavy weight even
if the presented case study research cannot support the finding.
10.2 Contribution of the Work

The case study report provides insights into the very specific environment of product
development testing. The initial literature research showed an underrepresentation of
product development testing in the Lean management knowledge base. The growing
importance of testing as part of product development in general, which was also
derived from literature research, underlines the relevance of in-depth knowledge.
The methodology VSM used to conduct the case study research proved to be an
effective tool to structure and focus the research in a not simple accessible expert
organization. This unusual use of VSM combined with the in-depth documentation in
this thesis contributes to the tool set researches can apply in industrial case study
work.
The VSM elaborated in this work was digitalized and connected to a centralized data
source. Set up this way, the VSM can be used as management dashboard
visualization as part of a management information system. Similar to control
dashboards in manufacturing plants a product development process can be
monitored. This application of VSM was not documented in any of the literature
resources studied for this master thesis.
The future state concept elaborated in this thesis, which decouples the internal flow
of a product development testing process in order to achieve a partial takt driven flow
and the visual control using a task board was not found to be documented for product
development testing before.
Yassine et al (2003) identified feedback delays as severe problem in product

development. “In combination with the interdependency structure, delays are the
main reason why development problems (issues) believed to be solved (closed) tend
to reappear (reopen) at later stages of development.” (Yassine et al. 2003, p.159)
The in-depth case study research identified observation writing as part of the testing
value stream and found waste leading to rework and waiting. Both wastes contribute
to the feedback delays discussed by Yassine et al. and provide case evidence for
root causes of feedback delays.
10.3 Limitations
Although a thorough literature research was conducted further sources related to
Lean application in product development testing might exist. The specific use of VSM
might often not be published due to non-disclosure agreements.
The case study research was conducted in three product testing sites of a single
organization. Cross case analysis and generalized theory building are limited. The
results of this thesis remain mainly descriptive, however, provide in-depth insights for
further cross case or longitudinal studies in the case company.
The mainly interview based case work is of qualitative nature. Quantitative legacy
data was analyzed but had limited explanatory power due to uncontrolled data entry.
Improved data collection from a VSM point of view were and will be implemented but
require time for sufficient data collection.
The complete thesis research and writing was conducted within five months and
within the case company. Hence, time was a limiting factor for the research. In
addition limitations had to be applied to the publication of this thesis due to a non-
disclosure agreement. The author had to disguise or delete information leading to
limitations. However, care was taken to maintain the academic informative value.
10.4 Further Research

The findings of this thesis were presented to the product testing management of the
case company. Implementation measures were agreed upon or will be in the future.
In order to validate the long term effectiveness and identify possible problems of
Lean management in product development testing longitudinal studies in the case
company are encouraged.
To develop general theory about the application of Lean in product development

testing cross case comparison is required.
The case study work of this thesis was limited to the functional area of product
development testing. The general product development organization in the case
company does not follow an explicit Lean product development concept.
It would be of research interest to find out how an organization would react if Lean
management is implemented in a bottom-up approach rather than the common top-
down management driven approach.
The suggested future research streams are complementary or extensional to the

presented thesis. As the Lean management is an endless journey striving for
perfection future research is offered a wide field.
11 References 141
11 References
Adler, P.S., 1993. Time-and-motion regained. Harvard Business Review, 71 (1),
pp.97–108.
Al-Ashaab, A., Molyneau, M. & Doultsinou, A., 2012. Knowledge-based environment

to support product design validation. Knowledge-Based Systems, 26, pp.48–
60.
Barratt, M., Choi, T.Y. & Li, M., 2011. Qualitative case studies in operations
management: Trends, research outcomes, and future research implications.
Journal of Operations Management, 29, pp.329–342.
Bauch, C., 2004. Lean Product Development: Making waste transparent. Master
Thesis: Massachusetts Institute of Technology & Technical University of
Munich.
Beck et al., 2001. Manifesto for Agile Software Development. Available at:
http://agilemanifesto.org, 15.May. 2013.
Boehm, B.W., 1988. A spiral model of software development and enhancement.

IEEE Computer, 21(5), pp.61–72.
Boehm, B.W., 2002. Get ready for agile methods, with care. IEEE Computer, 35 (1),
pp.64–69.
Carlson, R. & Turner, R., 2013. Review of Agile Case Studies for Applicability to
Aircraft Systems Integration. Procedia Computer Science, 16, pp.469–474.
Carreras, C.E., 2002. Opportunities for Lean Thinking in Aircraft Flight Testing and
Evaluation. Master Thesis: Massachusetts Institute of Technology.
Chakravarty, A.K., 2001. Theory and Methodology - Overlapping design and build
cycles in product development. European Journal of Operational Research,
134, pp.392–424.
Chase, J.P., 2000. Measuring Value in Product Development. MIT, The Lean
Aerospace Initiative Working Paper Series.
Chase, J.P., 2001. Value Creation in the Product Development Process. Master
Thesis: Massachusetts Institute of Technology.
Clark, J.O., 2009. System of Systems Engineering and Family of Systems

Engineering From a Standards, V-Model, and Dual-V Model Perspective. IEEE
SysCon - 3rd Annual IEEE International Systems Conference.
Cooper, R.G., 1990. Stage-gate systems: a new tool for managing new products.
Business Horizons, May/June, pp.44–54.
Cooper, R.G. & Edgett, S.J., 2008. Maximizing productivity in product innovation.
Research-Technology Management, 51 (2).
11 References 142
Dube´, L. & Pare´, G., 2003. Rigor in information systems positivist case research:
Current practices, trends, and recommendations. MIS Quarterly, 27(4),
pp.597–635.
Eisenhard, K.M., 1989. Building Theories from Case Study Research. Academy of
Management Review, Vol. 14, No. 4, pp.532–550.
Eppinger, S. & Browning, T., 2012. Design Structure Matrix Methods and
Applications, The MIT Press Cambridge, Massachusetts.
Estler, H.C. et al., 2012. Agile vs. Structured Distributed Software Development: A
Case Study. In Seventh International Conference on Global Software
Engineering.
EUCommission, 2011. CE marking makes Europe’s market yours! Available at:

http://ec.europa.eu/enterprise/policies/single-market-
goods/cemarking/downloads/ce_brochure_en.pdf, 1.Apr.2013.
FHWA, F.H.A. US Dept of Transportation, 2009. Systems Engineering Guidebook for

Intelligent Transportation Systems, Available at:
http://www.fhwa.dot.gov/cadiv/segb/views/process/index.htm, 7.Apr.2013.
Fisher, M., 1997. What is the right supply chain for your product? Harvard Business
Review, March/April, pp.105–16.
Fontana, J.H. A. & Frey, 2000. The interview: from structured questions to negotiated
text. In N. K. Denzin & Y. S. Lincoln (Eds.), Handbook of qualitative research
2, ed., Thousand Oaks, CA: Sage.
Forsberg, K. & Mooz, H., 1991. The ralationship of System Engineering to the Project
Cycle. Proceedings of the First Annual Symposium of National Council on
System Engineering, pp.57–65.
Forsberg, K., Mooz, H. & Howard, C., 2005. Visualizing Project Management Models
and frameworks for mastering complex systems 3., ed., John Wiley & Sons,
Inc.
Heiskanen, A. & Newman, M., 1997. Bridging the gap between information systems
research and practice: the reflective practitioner as a researcher. Paper
presented at the proceedings of the international conference on information
systems, Atlanta, Georgia.
Henard, D.H. & Szymanski, D.M., 2001. Why Some New Products Are More
Successful Than Others. Journal of Marketing Research, 38 (3), pp.362–375.
Highsmith, J. & Chckburn, A., 2001. Agile Software Development: The Business of
Innovation. Computer, 34 (9), pp.120–122.
Hoppmann, J., 2009. The Lean Innovation Roadmap - A Systematic Approach to

Introducing Lean in Product Development Processes and Establishing a
Learning Organization. Master Thesis: Massachusetts Institute of Technology
& TU Braunschweig.
11 References 143
IABG, 2009. V-Modell® XT, Version 1.3. Available at: http://v-

modell.iabg.de/index.php?option=com_docman&task=cat_view&Itemid=&gid=
15&orderby=dmdate_published&ascdesc=DESC, 7.Apr.2013.
Jönsson, A., 2004. Lean Prototyping of Multi-body and Mechatronic Systems. PHD
Thesis, Blekinge Institute of Technology, Karlskrona, Sweden.
Kato, J., 2005. Development of a Process for Continuous Creation of Lean Value in
Product Development Organizations. Master Thesis: Massachusetts Institute
of Technology.
Khalaf, F. & Yang, K., 2006. Product development processes – from deterministic to
probabilistic: a Design for 6-Sigma approach to lean product validation, Part II.
Int. J. Product Development, 3(1), pp.18–36.
Kleyner, A. & Sandborn, P., 2008. Minimizing life cycle cost by managing product
reliability via validation plan and warranty return cost. Int. J. Production
Economics, 112, pp.796–807.
Klyatis, L.M., 2012. Accelerated reliability and durability testing technology, Wiley
series in systems engineering and management.
Kokkolaras, M. et al., 2013. Towards a comprehensive framework for simulation-

based design validation of vehicle systems. Int. J. Vehicle Design, Vol. 61,
Nos. 1/2/3/4,, pp.233–248.
Krafcik, J.F., 1988. Triumph of the lean production system. Sloan Management
Review, 30(1), pp.41–52.
Krishnan, V., Eppinger, S.D. & Whitney, D., 1998. A Model-Based Framework to
Overlap Product Development Activities. Management Science, 43(4),
pp.437–451.
Liker, J., 2003. The Toyota Way: 14 Mangement Principles from the World’s Greatest
Manufacturer 1, ed., McGraw-Hill.
Liker, J.K., 1996. Becoming Lean, Free Press, New York.
Lindlof, L. & Soderberg, B., 2011. Pros and cons of lean visual planning: experiences
from four product development organisations. Int. J. Technology Intelligence
and Planning, 7, pp.269–279.
Loch, C.H. & Kavadias, S., 2008. Handbook of New Product Development
Management 1, ed., Butterworth-Heinemann.
Locher, D.A., 2008. Value Stream Mapping for Lean Development A How-To Guide
for Streamlining Time to Market, 1, ed., Productivity Press, New York.
Maleyeff, J., 2006. Exploration of internal service systems using lean principles.
Management Decision, 44(5), pp.674–689.
Marchwinski, C., Shook, J. & Schroeder, A., 2008. Lean Lexicon - a graphical
glossary for Lean Thinkers 4, ed., Lean Enterprise Institute.
11 References 144
Martin, C. et al., 2009. Value stream classification. Journal of Manufacturing

Technology Management, 20, pp.460–474.
Maylor, H., 2010. Project management 4. Edition, ed., Pearson Education Limited.
Mazzani, G., 2012. Agile in the bathtub - Developing and producing bathtubs the
agile way. Proceedings of the Agile Conference.
McManus, H., 2005. Product Development Value Stream Mapping. The Lean
Aerospace Initiative, 1.
McManus, H., 2000. Value Attributes of Product Development. Unpublished Report.

MIT. Cambridge,.
McManus, H.L. & Millard, R.L., 2002. Value stream analysis and mapping for product
development. ICAS Congress, Toronto Canada, 23.
Miles, M.B. & Huberman, A.M., 1994. Qualitative data analysis: An expanded
sourcebook 2, ed., Newbury Park, CA: Sage.
Millard, R.L., 2001. Value Stream Analysis and Mapping for Product Development.
Mast.
Montoro-Lopez, M.A., 2012. Design Process Modeling and Improvement: a

Comparative Analysis and BPR Application. Master Thesis: Politecnico di
Milano.
Morgan, J.M., 2002. High performance product development. Troy - Design and
Manufacturing.
Morgan & Liker, 2006. The Toyota Product Development System: Integrating People,
Process, and Technology, New York, Productivity Press.
MWFL, 2013a. Company Home Page, (Disguised Information).
MWFL, 2013b. Company Internal Data (Disguised Information),
MWFL, 2012. MWFL 4. Quater Result, (Disguised Information).
Myers, M. D. & Newman, M., 2007. The qualitative interview in IS research:

Examining the craft. Information and Organization, 17, pp.2–26.
Ohno, T., 1988. Toyota production system: beyond large-scale production,

Productivity Press, Cambridge, Massachusetts.
Oppenheim, B.W., 2004. Lean Product Development Flow. Systems Engineering,

7(4).
Page, A.L. & Schirr, G.R., 2008. Growth and Development of a Body of Knowledge:
16 Years of New Product Development Research, 1989–2004. Journal of
Product Innovation Management, 25, pp.233–248.
Pahl, G. & Beitz, W., 1996. Engineering design 2, ed., Springer-Verlag, London.
11 References 145
PDMA, 2006. The PDMA Glossary for New Product Development, PDMA.
Piekkari, R., Welch, C. & Paavilainen, E., 2009. The Case Study as Disciplinary
Convention Evidence From International Business Journals. Organizational
Research Methods, 12 (3), pp.567–589.
PMI, (Project M.I., 2011. IEEE Guide-Adoption of the Project Management Institute
(PMI®) Standard A Guide to the Project Management Body of Knowledge
(PMBOK ® Guide) 4. Edition, ed., The Institute of Electrical and Electronics
Engineers, Inc.
Qian, Y. et al., 2010. Optimal testing strategies in overlapped design process.

European Journal of Operational Research, 206, pp.131–143.
Rebentisch, E., 2005. Lean Product Development. ESD.61J / 16.852J: Integrating

the Lean Enterprise, Massachusetts Institute of Technology, Lecture No. 8.
Reinertsen, D., 1997. Managing the Design Factory, The Free Press, New York.
Rossi, M. et al., 2011. Proposal of a method to systematically identify wastes in New

Product Development Process. Proceedings of the International Conference
on Concurrent Enterprising (ICE 2011), 17.
Rother, M. & Shook, J., 1999. Learning to See - Value Stream Mapping to create
value and eliminate muda 1.2, ed., The Lean Enterprise Institute.
SAE, 2013. Technical Papers, Test and Testing. Available at:

http://papers.sae.org/tests-testing/ , 24.May 2013.
Schulte, K.M., Paruchuri, M.R. & Patel, J.B., 2005. Applying Lean Principles in a Test
Laboratory Environment, SAE International, 2005-01-1051, SAE World
Congress.
Shooman, M., 1983. Software Engineering: Design, Reliability, and Management,

McGraw-Hill.
Spear, S. & Bowen H.K, 1999. Decoding the DNA of the Toyota production system.
Harvard Business Review, 77, pp.96–108.
Tahera, K., Eckert, C.M. & Earl, C.F., 2013. Optimizing Overlap between Testing and
Design in Engineering Product Development Processes. Smart Product
Engineering, LNPE, Springer Berlin Heidelberg, pp.201–210.
Tan, S.L.P.& B., 2011. Demystifying case research: A structured–pragmatic–

situational (SPS) approach to conducting case studies. Information and
Organization, 21, pp.161–176.
Thomke, S. & Bell, D.E., 2001. Sequential testing in product development.

Management Science, 47 (2), pp.308–323.
Ulrich, K. & Eppinger, S., 2004. Product design and development 3rd edition, ed.,
McGraw- Hill, New York, NY.
11 References 146
Veryzer, R.W., 1998. Discontinuous Innovation and the New Product Development
Process. Journal of Product Innovation Management, 15 (4), pp.304–321.
Webb, E.J. et al., 1966. Unobtrusive measures: NonReactive research in the social
sciences. Chicago: Rand McNally.
Weigel, A.L., 2000. Spacecraft System-Level Integration and Test Discrepancies:

Characterizing Distributions and Costs. Massachusetts Institute of Technology.
Welo, T., 2011. On the application of lean principles in Product Development: a

commentary on models and practices. Int. J. Product Development, 13 (4),
pp.316–343.
Wheelwright, S.C. & Clark, K.B., 1992a. Competing through development capability
in a manufacturing-based organization I. 4 Vol. 35, ed. Business Horizons, 35
(4), pp.29–43.
Wheelwright, S.C. & Clark, KB., 1992b. Revolutionizing Product Development:

Quantum Leaps in Speed, Efficiency, and Quality, The Free Press, New York.
Womack, J.P. & Jones, D.T., 1996. Lean Thinking, Simon & Schuster, New York.
Womack, Jones & Roos, 1990. The Machine That Changed The World, Rawson
Associates Sribner.
Yassine, A. et al., 2003. Information Hiding in Product Development: The Design

Churn Effect. Research in Engineering Design, 14(3), pp.145–161.
Yin, R.K., 2003. Case study research: Design and methods 3, ed., Thousand Oaks,
CA: Sage.
Zakarian, A., 2010. A methodology for the performance analysis of product validation
and test plans. Int. J. Product Development, 10 (4), pp.369–392.
12 Appendix 147
12 Appendix
12.1 Semi Structured Interview Sheets

- Page 1 is equipped with a header with basic information followed by pre
formulated questions. The questions were adapted to the individual interview and
information focus.
- Page 2 was added to allow instant notes related to the questions (blue are) and
if applicable tag information relative to the research objective (orange area).
Page 2 was usually filled in during or right after the interview.
- For each interview blank templates were carried to allow notes for evolving
questions which were often required.
- The notes from the interviews were transited into MS Excel. Tagged information
could be identified by using the filter function.
Interviewer Daniel
Date: 13 Mrc 13
: Walew Interview Validation
Interviewe
Duration/Complexity/Risk
Topic:
Inventory of Information
Process Communication
Information to use for
Position: Matrices Information

basic process flow
Value Framework
Years in
Use of lean tool

Location Observations
Rework Loops
MWFL:
Process Issue
Kaizen Idea
Role /
Push/Pull
How long?
Test
What are your major customers and what do they need?
What are the major steps of your workflow?
How do you prioritize the work?
Do you see barriers in using the priority list and what are they?
How do you record observations during testing?
How do you implement priorities?
Where do you see issues in the process as it is?
Figure 12-1, Semi structured interview sheet, example

12 Appendix 148
12.2 Structured Observation Sheet

The format was inspirited by Millard and Mc Manaus (McManus 2005; Millard 2001)
Adaptation was made in the matrices-, the value- and the waste section.
Table 12-1, Structured observation sheet, page 1, basic information, time data, input flow
based on (Millard 2001)
12 Appendix 149
Table 12-2, Structured observation sheet, page 2, output, critical drivers, rough value assessment
12 Appendix 150
Table 12-3, Structured observation sheet, page 3, value and waste assessment
12 Appendix 151
12.3 Data sources for current state analysis overview

Selected Process
Matrices
Process time (P/T) One sample through No data One sample through
Lead time (L/T) meeting observation of meeting observation
Process Step: of Process Step:
3, 4, 5, 11, 12 3, 5, 11, 12
and test setup of one
test
Number of people Observed and reliable No data Observed and reliable
involved estimations for all estimations for all
steps (Budget plan) steps
Batch size or One sample through No data One sample through
Frequency meeting observation of meeting observation
Process Step: of Process Step:
3, 4, 5, 11, 12 3, 5, 11, 12
Number of Only for test task No data No data
iterations review observed
Complete and Qualitative data No data Qualitative data
Accurate (C&A) from observation from observation
Process issues named Process issues
in interviews named in interviews
Inventory Lab Task List 4 internal Low detail, no central
(Detailed overview by “milestones” access
7 internal 3 internal “milestones”
“milestones”)
Data In / Data Out Observation No data Observation
Available Budget Plan/ Legacy Budget Budget Plan/Legacy
Time/Demand Rate Data Plan Data
Rework or Qualitative data No data Qualitative data
revisions from observation from observation
Process issues named Process issues
in interviews named in interviews
Table 12-4, Overview, data sources for current state analysis
12 Appendix 152
12.4 Online Checklist implemented in Share Point
Figure 12-2, Online Checklist implemented in MS Share Point
12.5 Checklist points for test review – Data gathering overview
Figure 12-3, Data gathering overview, Number of sources per Checklist Item identified
12 Appendix 153
12.6 Kaizen: Checklist for Observation writing
MWFL Dept: PT
Forest Harvester KAIZEN
Validation Machine/line:
PDCA (Plan-Do-Check-Act)
Area: OP Creation Doc. Nr.
Theme: Improve Quality and Time of Observation Writing Cost Center:
About 30% of new Observation are rejected due to missing data

Summarize all information from Observation by: 5 W and How
Misunderstanding
Management requires "in as much appropriate detail as possible" Only if very simple, needs review
Things that are easy to access
Select from all location Why From FMEA
Allow edit Customer Location
Temperature,
Location Humidity, Rain
Test Lab
Uncontrolled quality of Observations Where Environment
Dust, Vibration
Fuel
How
- Unclear instructions on how to fill in Soil, Road,...
Manufacturing Operation Standard Operation

from Machine Type
- information for 5 W and How is not pulled TT Link

Subsystem/Bench
Comment on Selection Severity: 100/50/20/6/3 Free Text, Metadata
with pictures
Design Action
Information from Service
Warrantable Failure Observation
Failure Code 5 W+How Description:
Free Text,
Low percentage of useful data on the report Possible Failure, List with
Metadata with
pictures
possible Failures: What
Visual Data only as Link Sub Group, depending
on failure: Leak Class
Leak, Breakage, Function,
Assembly
Attachment
Customer
Yes:
Assembly Worker
Upload PDF, Picture, Excel, Data Available?
Who Manufacturing Engineer
Word
Plant Quality
NO: Operator
Process is slow: What Should be

done
Select from all running tests Design/

Expert Operator
Technical Assistant
Test Engineer
Management requires: "OP’s need to be written in TBD by test engineers within

Development/Test LTE
Select Project
When Date/Time
the same day " PT View Nice To Have Survey Function
Sketch:
Function Under Test/
Yes
Development? Active Guide Line for fill in
Machine Type
Customer View Integration of Online Part
No, it was a Specific Machine Catalog/Simple Picture instead
secondary
failure of Text for machine Location
Machine Area
Wear Time from DB Part Number Machine Function
Current Load old Observation and

modify, Mass process
Data Apr 2013 May 2013 Jun 2013 Jul 2013

ID Task Name Duration
Entry, 31/3 7/4 14/4 21/4 28/4 5/5 12/5 19/5 26/5 2/6 9/6 16/6 23/6 30/6 7/7 14/7 21/7
1 Initial Framework Interview 5d

Green Kaizen Event Site Manager, Design
2 0d
Field Manager
Follow Up of Kaizen, Model Checklist,
3 10d
contain 4
Implement Checklist, Instruction
Trial Phase with 5 local LTE and Design
20d
Engineers, Cross Location/Cross Function
usefull 5 1 Stage: Quick Kaizen, Role Out to all 0d
data 6
Verify C&D value of Test Task Review
20d
During second review
7 Remove Second Review 0d
8 Prototype of Online Checklist 5d
Standardization Create a Prototype: Done with SP survey:http://
Collect Feedback: Open, 1 participant

1. Connect Sharepoint to TDB system (Manual/Automatic) Keep Updating, Make an Easy, intuitive GUI, Collect feedback from sites, Allow Mobile
2. Make Sharepoint tool for Observation entry, and fast forward of "Alter" Access, Have Multi Language Version/Translation Function
function Finalize a Standard
3. Implement into TDB or Even PLM Tool Count number of rejected OP in PDCA Process, measure
time to inform about a new OP
Resp. Date of
Originator of the improvement. Date: Costs (€) Benefits (€) Results (€ ) Cost/Benefit Verification
Implementation implementation
Daniel Walew 30 Apr 2013 525 MH/Year
Figure 12-4, A3 summary report for Kaizen: “Improve Quality and Time of Observation Writing”
12.7 Table used for Waste Assessment

y
PI
n
e
ce
rm
e2
y
lit
ize
us
rit
us
bi
No
ct
As e
Ca
ra
ve
Ka
t
Ca
da
pe
as
cu
Se
PI
oi
W
Oc
Av
Waiting for 2 2 3 12 2.29 People waiting for Meeting Guidelines

People/Information/Material Information
General Meeting Problem:

- missing agenda
- missing preparation and
required decisions
- missing checklist of
materials that are required
- missing time keeping
Excessive Processing 2 3 1 6 1.59 - data of different sources Make part of new Test System
does not flow easily into the
TT
Transportation/Handoffs 1 2 3 6 1.59 Cross location schedules are Central Resource Schedule

not available to balance
capacity for test benches
Table 12-5, Table used to assess waste priority in the VSM

Application of Lean in Prod Develop

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Application of Lean in Prod Develop

Uploaded by

Copyright:

Available Formats

Title:

A Case Study from the Politécnica de Madrid

Daniel Walew Politecnico di Milano

Tutor name: Prof. Alberto Portioli Staudacher,

8th edition, 2011 - 2013

Como, June, 15th, 2013

Utilizing a systematic literature research, the beginning of this work elaborates

Needs, values, wastes, interruptions and other process parameters are

Universidad Politécnica de Madrid (UPM), Madrid, Spain

Instituto Politecnico di Milano (POLIMI), Milan, Italy

Royal Institute of Technology (KTH), Stockholm, Sweden

who enable the International Master of Industrial Management (IMIM) program.

I would like to express my gratitude to my academic tutors, Prof. Alberto Portioli

I gratefully acknowledge the generous support of the case company. Foremost,

III. Table of Contents

7 Case Analysis – Overview and Methodology ................................................ 67

9.2 Implementation of Future State ................................................................. 126

IV. List of Tables

VI. List of Acronyms and Specific Vocabulary

Physical testing as a part of new product development has to be clearly distinguished

product development process in order to ensure a product that meets customer

1.2 Research Objectives and Research Questions

The more specific objectives can be stated as following:

2.1 Case Study Research Process

Research Process Research process

Following a more detailed description of the individual steps:

1. Getting Started and 2. Selecting Case

3 Crafting Instruments and Protocols

4 Entering the Field

2.2 Data Collection

2.2.1 Literature review

Sources of literature search were:

Although interviews appear often as a straight forward research method and an

Artiﬁciality of the interview

1. Situating the researcher as actor

2. Minimize social dissonance

3. Represent various “voices”

5. Use Mirroring in questions and answers

For the interviews of this research a semi-structured approach was followed. A

3 New Product Development and the Role of Testing

3.1 Product Development Process

The possibility to distinguish different phases of a product development made stage

Although the research interest in ‘stage-gate’ product development processes has

Figure 3-1, An overview of the Stage-Gate® System (Cooper 1990)

Stage or Gate Activities and Deliverables

Figure 3-2, Product development process (Ulrich & Eppinger 2004)

Likewise, the main deliverables of product testing are examination of product

3.2 Product Testing as Part of New Product Development

As discussed in the previous chapter an essential phase of most product

To ensure the delivery of functional requirements in a specified duration, predefined

In an environment where product requirements are changing, designs become more

Figure 3-3, Spiral development - a series of "build-test-feedback-revise" iterations in parallel to a

Even earlier concepts of spiral development exist. Boehm (1988) described an

Figure 3-4; Spiral model of software development (Boehm 1988)

A further popular model of product development and systems engineering is the

Figure 3-5, The basic V-model of the Systems Engineering Process

Several applications of agile methods in non-software related product development

3.3 Major Consideration for Product Testing Operations

3.3.1 Planning of Product Testing

Independent of the general NPD model discussion an increasing number of authors

Zakarian attested in 2010 that “companies in a variety of industries that develop

Figure 3-7, “Theoretical product development cost versus reliability curve”

A further method considering an overlapped design processes of test planning has

3.3.2 Basic Overview on Different Test Types